WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=RQi7x-navxU

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/RQi7x-navxU.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:12.680 --> 00:00:13.680
I think we can get started.

s3
00:00:13.680 --> 00:00:22.040
Hey everyone, I'm Jerry, co-founder and CEO of LlamaIndex, and today I'm excited to uh give a talk called building the document context layer for AI agents.

s4
00:00:22.040 --> 00:00:26.200
Um really uh big shoutout to the AI Engineer World Fair for hosting.

s5
00:00:26.200 --> 00:00:39.520
Um and if you've seen some of my earlier talks from the previous uh AI Engineer conferences, uh we've kind of traced through a lot of the evolution of how, you know, um agent advances have correlated with uh you know, how you inject context into evolving applications.

s6
00:00:39.520 --> 00:00:43.240
Um and so today, in 2026, we'll kind of talk about three main topics.

s7
00:00:43.240 --> 00:00:46.200
One is, you know, what is RAG in 2026?

s8
00:00:46.200 --> 00:00:51.120
Um two, uh basically that basically decomposes into an agent harness plus a context layer.

s9
00:00:51.120 --> 00:00:59.360
So kind of going into the modern document context layer for agents, um and giving you a little bit of sense of kind of some of the core capabilities today, um especially uh unlocking,

s10
00:00:59.360 --> 00:01:04.160
you know, the vast trove of document-based data today, and giving you a glimpse of what's next.

s11
00:01:04.160 --> 00:01:04.920
All right.

s12
00:01:04.920 --> 00:01:06.080
RAG in 2026.

s13
00:01:06.080 --> 00:01:09.480
But before that, just a little bit about the company, and I'll kind of get on with the main talk.

s14
00:01:09.480 --> 00:01:11.160
Um you might have seen us as a RAG framework.

s15
00:01:11.160 --> 00:01:17.240
We started in 2023, got pretty popular, um kind of created a lot of techniques around like advanced RAG, that type of stuff.

s16
00:01:17.240 --> 00:01:21.040
Um today, we're basically the main document infrastructure for AI agents.

s17
00:01:21.040 --> 00:01:32.640
Um we deliver the best platform for agents to actually read and operate over documents, and we see ourselves as unlocking basically the vast troves of document context even as agents and models themselves get better.

s18
00:01:33.000 --> 00:01:33.600
All right.

s19
00:01:33.600 --> 00:01:40.680
So, what does RAG actually mean in 2026, and how are agents actually inhaling and addressing context today?

s20
00:01:40.680 --> 00:01:49.880
This is a snapshot from um actually 3 years ago, um when I first gave a talk on this, and naive RAG was basically just building a simple chatbot over your private corpus of data.

s21
00:01:49.880 --> 00:02:01.040
If you flash back all the way to January of like 2023, um you know, this technique basically consisted of you have some corpus of documents, um you chunk it up, embed it, and put it into a vector database.

s22
00:02:01.040 --> 00:02:05.160
You do some naive top K retrieval, and then you generate some stuff with an LLM.

s23
00:02:05.160 --> 00:02:06.320
All the steps are fixed.

s24
00:02:06.320 --> 00:02:14.560
You use kind of like a fixed set of techniques, and then with that you actually get some basic application results by just being able to chat over a corpus of documents.

s25
00:02:14.560 --> 00:02:19.760
Of course, the agent landscape has changed quite a bit and quite dramatically since then.

s26
00:02:19.760 --> 00:02:27.320
One is agent loops and tool use have gotten a lot a lot better, especially as both the models and agent harnesses have increased.

s27
00:02:27.320 --> 00:02:33.000
And there's basically a cleaner separation now between agent reasoning and how they actually interact with context.

s28
00:02:33.000 --> 00:02:43.720
If you look at what I call kind of the modern generalized agents, which includes, you know, all your favorite applications and tools out there from Claude Code, Claude Code Work, Open Claw, Codex, and a few others,

s29
00:02:43.720 --> 00:02:48.000
you know, the retrieval complexity has started to get baked into the agent layer.

s30
00:02:48.000 --> 00:03:01.800
So, instead of coming up with a variety of hacks to really work around the limitations of naive top K retrieval, you can start getting the agent to really reason about, for instance, the best key best keyword to search for, best like, you know, search term to actually get back good results.

s31
00:03:01.800 --> 00:03:09.560
Even if the retrieval tools are basic, the agent can input the right queries to basically loop upon itself and help solve the task at hand.

s32
00:03:09.560 --> 00:03:12.360
Number two, context is moving up the stack.

s33
00:03:12.360 --> 00:03:21.640
There's been a lot of conversations, I think, for the first two and a half years of Gen AI of how do you actually manage the agent context window, make sure it doesn't overflow, that type of thing.

s34
00:03:21.640 --> 00:03:37.040
But, I think as, you know, a lot of the evolving techniques, compaction, long contexts have evolved, I think more and more of the conversation is actually how do you just hook up the right MCP servers and skills and tasks to the agent to enable it to do various types of tasks.

s35
00:03:37.040 --> 00:03:39.959
And so, that also applies to agent orchestration, right?

s36
00:03:39.959 --> 00:03:42.239
Coding agents have gotten better.

s37
00:03:42.239 --> 00:03:49.880
Abstractions of actually defining what types of tasks and programs you want to build have moved a little bit upwards towards English as opposed to through code.

s38
00:03:49.880 --> 00:03:57.920
And so, maybe in 2023 to 2025, you define programs and you still build stuff via like importing Python, using TypeScript through code.

s39
00:03:57.920 --> 00:04:08.240
It's pretty clear these days more and more people are just building stuff using English, whether you're a software engineer or you're a non-technical function like go-to-market marketing.

s40
00:04:08.240 --> 00:04:15.240
And you're defining runbooks through English and kind of like defining the right goals and making sure the AI is aligned on the right task.

s41
00:04:15.240 --> 00:04:19.120
And we see that carrying over going forward as well.

s42
00:04:19.359 --> 00:04:26.520
So, in terms of just like general evolving knowledge work patterns, and this kind of forms a foundation for what we how we think about the context layer.

s43
00:04:26.520 --> 00:04:32.640
You know, in the past maybe you could use AI to just like ask simple questions, get it resolved.

s44
00:04:32.640 --> 00:04:45.440
Today, you're starting to be able to define and solve more end-to-end like tasks just through English and also use English to start compiling repeatable programs to actually execute something at scale.

s45
00:04:45.440 --> 00:04:55.000
Obviously, there's been a lot of discussion on how this will evolve even more, and we do see AI agents as behaving even more autonomously through solving long horizon tasks,

s46
00:04:55.000 --> 00:04:57.400
looping upon themselves to be able to achieve a goal.

s47
00:04:57.400 --> 00:05:10.840
So, the future will move towards a state where you actually might not even have to define the task in English, but actually more of the goal and a scoring rubric, and then the agent will use all available context available to it to actually solve the task.

s48
00:05:10.840 --> 00:05:25.919
So, with that overall framing, let's talk about what kind of what is a pretty core focus for us as a company, which is basically helping to unlock unstructured context to basically feed into these agents even as they get really, really good both in terms of the core model capabilities

s49
00:05:25.919 --> 00:05:27.480
as well as the agent harness.

s50
00:05:27.480 --> 00:05:34.560
And we'll focus a lot on our core focus area, which is document context, but of course there's plenty of other sources of context as well.

s51
00:05:34.560 --> 00:05:38.480
In fact, we do think context really is everything.

s52
00:05:38.480 --> 00:05:51.520
In the end, you could have a infinitely smart agents, but your ability to actually get value out of this infinitely AI agent um, able to do more and more stuff end to end, is actually, you know, giving it the right things to do.

s53
00:05:51.520 --> 00:06:01.080
Um, and the right things to do include the actual task, uh, the goal, um, but also access to the vast troves of organizational context available to it.

s54
00:06:01.080 --> 00:06:19.600
Whether that is web search, web context, whether that is connectors through, you know, like tools and skills and MCP servers, whether it's connectors through Snowflake or Databricks warehouses, um, or for us, whether it's access to the vast trove, like the 90% of documents that are stored within SharePoint, Box, Dropbox, S3,

s55
00:06:19.600 --> 00:06:24.120
um, you know, all the unstructured, uh, data that's locked up within document containers.

s56
00:06:24.120 --> 00:06:31.720
Um, and so for us, you know, we care a lot about how do you actually build the right tools and unlock the right context here.

s57
00:06:31.720 --> 00:06:35.560
We see documents as universal containers for unstructured context.

s58
00:06:35.560 --> 00:06:42.120
Uh, there's over 10 trillion plus pages of human native knowledge locked up within PDFs, PowerPoints, Word documents, and Excel sheets.

s59
00:06:42.120 --> 00:06:51.080
And at the same time, agents are also starting to generate exponentially more data in terms of, you know, more agent native formats in terms of markdown and HTML.

s60
00:06:52.320 --> 00:06:57.200
For us, building an agent native document platform contains three main pieces.

s61
00:06:57.200 --> 00:07:15.160
Uh, it contains the document parsing layer, actually digitalizing, um, the vast troves of PDFs, PowerPoints, and Word documents into kind of accurate token efficient context, um, and feeding it, you know, either markdown, metadata, and other forms that actually enable agents to do stuff over your documents.

s62
00:07:15.160 --> 00:07:22.880
The next is actually what we call the semantic and storage layer, um, which is kind of like this concept of document management for humans and agents.

s63
00:07:22.880 --> 00:07:31.960
Instead of humans opening up Microsoft Word, using your file system or file storage, how do you create some sort of agent interface that actually captures, stores all your documents,

s64
00:07:31.960 --> 00:07:36.080
and enables agents to actually manage and operate over them in various ways.

s65
00:07:36.080 --> 00:07:46.840
Um, and then there's still a room for actually kind of repeatable document workflows is agent layer they can actually encode within the uh within like this type of platform, too.

s66
00:07:46.840 --> 00:08:02.720
If there is a repeatable workflow, like invoice processing, KYC, or claims, instead of always offloading it to a generalized agent, how do you actually develop some sort of specialized workflow for it and really carefully tune cost and accuracy to make sure that you achieve your goal.

s67
00:08:03.520 --> 00:08:12.480
So, when we talk about like the concepts today in in terms of these three layers, uh we'll talk about this concept of document OCR, which is one of the core concepts of this track,

s68
00:08:12.480 --> 00:08:16.120
um to document extraction, document search, and document workflows.

s69
00:08:16.120 --> 00:08:26.280
There's still a variety of topics yet left unsolved from agent native document formats, document versioning, document editing, you know, hill climbing as a service, and just like a wide set of

s70
00:08:26.280 --> 00:08:35.919
uh kind of remaining concepts to actually create a comprehensive piece of software where agents and humans can collaborate on documents and actually do work over them.

s71
00:08:35.960 --> 00:08:41.440
So, we'll start with the first section um and maybe start kind of with uh the document OCR RP.

s72
00:08:41.440 --> 00:08:45.200
Um first off, uh you know, document OCR is hard.

s73
00:08:45.200 --> 00:08:49.680
Um some of you might have seen a blog post that we put out a few months ago related to this topic.

s74
00:08:49.680 --> 00:08:58.240
But, the reason this problem even exists is an agent cannot actually take the like the raw PDF like file binary and make sense of it.

s75
00:08:58.240 --> 00:09:09.800
Um that's because the like the way PDFs are actually stored as a format is it's rendered for kind of like display purposes um and not really for uh you know, machine consumption in an interpretable manner.

s76
00:09:09.800 --> 00:09:12.040
Um they're designed for printing.

s77
00:09:12.040 --> 00:09:16.920
So, basically text are represented as almost like individual glyphs with coordinates.

s78
00:09:16.920 --> 00:09:27.120
Um tables are not represented as tables, they're represented as like typically line segments uh drawn with various types of borders, and also text drawn at certain cell positions.

s79
00:09:27.120 --> 00:09:37.440
And so, if you're kind of an agent that's trying to make sense of this like document, you're going to have a really hard time actually trying to reason about what character and what shapes like map to what.

s80
00:09:37.440 --> 00:09:45.200
Um so the whole point of document OCR, um, you know, it's been around for like 20 plus years, is to really try to create some sort of, uh, digitalized

s81
00:09:45.200 --> 00:09:51.360
well-interpretable, uh, representation um, that's both interpretable to humans, um, as well as AI agents.

s82
00:09:51.360 --> 00:10:01.640
Also, reading order itself, if you have a multi-column layout, there is no, uh, guarantee that the way it's represented in the PDF, um, actually corresponds to the typical ways that humans would read it.

s83
00:10:01.640 --> 00:10:07.440
Cuz again, it's basically just an arbitrary sequence of characters drawn with uh, coordinate positions.

s84
00:10:07.880 --> 00:10:10.920
Related to this, you know, even Word doc, uh, parsing is hard.

s85
00:10:10.920 --> 00:10:18.360
Um, they're a little bit more structured than PDFs, but they're in kind of like this, uh, custom bespoke XML format, and this applies to PowerPoints as well.

s86
00:10:18.360 --> 00:10:22.800
Um, it contains more structural information, but still there's a ton of like fluff.

s87
00:10:22.800 --> 00:10:27.960
Like you don't actually need to ingest all the tags to actually have the agent make sense of the Word document.

s88
00:10:27.960 --> 00:10:30.960
It still needs to infer a bunch of structure from it.

s89
00:10:30.960 --> 00:10:36.840
It needs like the right, uh, kind of to lift the right metadata around like formatting, semantics, that type of stuff.

s90
00:10:36.840 --> 00:10:43.360
But also being able to ignore the tags and actually be able to render the document so that the agent can see the overall structure of the page.

s91
00:10:43.360 --> 00:10:54.960
Um, it's still generally hard problem, and there's a lot of uplift you can get by actually parsing it into a more interpretable format instead of just using the native, uh, OXML and feeding that to an agent.

s92
00:10:55.240 --> 00:11:00.560
Um, if you're familiar with document understanding, um, you know, it's been around for quite a bit of time.

s93
00:11:00.560 --> 00:11:14.640
Um, there's a lot of these like heuristic and pipeline-based approaches, which, uh, focused on kind of more, uh, I guess like human-driven, hand-handwritten like techniques to analyze like kind of various pieces of text, group them into clusters, and identify tables,

s94
00:11:14.640 --> 00:11:19.480
paragraphs, and be able to kind of like, uh, generate some sort of output representation.

s95
00:11:19.480 --> 00:11:29.760
Um, a lot of basic techniques if you use open-source libraries like PyPDF, PyMuPDF, um, and of course like some of the, uh, more recent approaches, um, basically use this type of approach.

s96
00:11:29.760 --> 00:11:37.440
There's also, of course, using a VLM to one-shot a document um, into text, uh, that's what we call like a vision-based approach.

s97
00:11:37.440 --> 00:11:39.080
This works decently well.

s98
00:11:39.080 --> 00:11:47.840
Obviously, you know, I think there's kind of a lot of uplift you can get by being able to read the visual structure, but there's a lot of sub-optimal pieces about it.

s99
00:11:47.840 --> 00:11:50.240
It can hallucinate on text-only pages.

s100
00:11:50.240 --> 00:11:58.720
It costs a ton of money, and also it still lacks a lot of the semantics and grounding that you typically expect with some sort of document processing tool.

s101
00:11:58.720 --> 00:12:10.120
And so for us, we really think about combining both the pipeline-based approaches of deeply understanding the file containers and binaries with the vision-based approaches to help generate, you know, kind of

s102
00:12:10.120 --> 00:12:14.960
a hybrid approach that we think is at the Pareto frontier of cost and accuracy.

s103
00:12:15.920 --> 00:12:30.440
A quick note on this, I'll probably just like skim the high level, but the Pareto frontier for document OCR will always be like much more accurate and cheap compared to the Pareto frontier for, you know, wherever the frontier models are in terms of document understanding.

s104
00:12:30.440 --> 00:12:47.080
It's because it's a very specific data type, and there's always ways to kind of like distill the latest visual understanding capabilities from, you know, Gemini, GPT, Opus into kind of a carefully tailored workflow that's able to process your documents at scale and in a highly accurate manner.

s105
00:12:47.080 --> 00:12:49.480
To some extent, that's exactly what we do.

s106
00:12:49.480 --> 00:12:55.000
You know, we both optimize underlying like PDF engines plus like Word, PowerPoint, and others.

s107
00:12:55.000 --> 00:13:09.560
We have an agentic harness that's like carefully tuned for auto routing between cheaper specialized models to frontier models, and also kind of specialized fine-tuned document VLMs that are parameter efficient and focus on specific classes of documents,

s108
00:13:09.560 --> 00:13:13.200
elements like tables, charts, and others.

s109
00:13:14.680 --> 00:13:19.040
That's our commercial service called LlamaParse, which I'll talk about in a bit.

s110
00:13:19.040 --> 00:13:29.840
But I think in general, you know, we're extremely committed to advancing the frontier of just document understanding cuz basically if you're within an enterprise organization and you have a massive long tail of documents

s111
00:13:29.840 --> 00:13:38.960
across financial services, insurance, manufacturing, legal, government, and a bunch of others, there's just a lot of complexity in a lot of these document types.

s112
00:13:38.960 --> 00:13:44.200
And if you're actually trying to unlock context at scale, most of the models are not up for the task.

s113
00:13:44.200 --> 00:13:50.440
And so, we've created this thing called ParseBench, which is a comprehensive enterprise document benchmark for agents.

s114
00:13:50.440 --> 00:13:54.320
We we think about it as the most comprehensive enterprise document benchmark.

s115
00:13:54.320 --> 00:13:57.360
You know, it contains 2,000 human-verified pages.

s116
00:13:57.360 --> 00:14:01.720
It measures tables, charts, content faithfulness, semantic formatting.

s117
00:14:01.720 --> 00:14:09.160
And it's optimized for just how AI agents are actually able to understand these documents instead of like syntactic correctness.

s118
00:14:09.160 --> 00:14:15.640
We've If you look at parsebench.ai, which is, you know, kind of the it's a fully public page on the internet.

s119
00:14:15.640 --> 00:14:18.600
It's also available on Hugging Face and Kaggle.

s120
00:14:18.600 --> 00:14:23.840
We benchmark probably like 50 different frontier models, open weight models, specialized OCR solutions.

s121
00:14:23.840 --> 00:14:33.600
And you really want the Pareto curve to kind of be towards the left and up in terms of accuracy, like extremely high accuracy, but also extremely low cost.

s122
00:14:33.600 --> 00:14:40.640
And there's just so many different types of documents, where some are a little bit simpler, maybe some are a little bit more complex.

s123
00:14:40.640 --> 00:14:46.960
And ideally, you want to cover all the points on the curve to deal with the dynamic distribution of various types of documents out there.

s124
00:14:46.960 --> 00:14:55.839
It's pretty clear, even if you look at this graph, that it's like you can increase the complexity of the benchmark, and that document understanding is definitely not a 100%

s125
00:14:55.839 --> 00:14:56.600
solved.

s126
00:14:56.600 --> 00:15:06.720
But, you know, you fundamentally need to kind of advance a lot of the core capabilities to make sure they're able to process, unlock the vast trove of enterprise context out there.

s127
00:15:08.720 --> 00:15:13.360
There's kind of like a few different points on this accuracy cost latency Pareto curve.

s128
00:15:13.360 --> 00:15:30.760
There's what I call like the high accuracy regime, where like, you know, some institutions basically need like 99 to almost 100% accuracy, because basically, the downside of an incorrect extraction is you completely mess up your financial model, you completely, you know, you basically get flagged for fraud or a bunch of other really really bad things.

s129
00:15:30.760 --> 00:15:35.560
In regulated industries like insurance and financial services, we see this a decent amount.

s130
00:15:35.560 --> 00:15:43.040
This typically means you're willing to pay a little bit more money per page for like deeper agent tech reasoning to at least make sure that you get back the the information

s131
00:15:43.040 --> 00:15:44.520
in the right format.

s132
00:15:44.520 --> 00:15:46.400
There's also like the low cost regime.

s133
00:15:46.400 --> 00:15:56.080
Let's say you're just trying to index, you know, the million plus documents per day within your that's you know, being continually updated within your SharePoint just for like rag knowledge base search.

s134
00:15:56.080 --> 00:16:02.480
You know, in these cases, you obviously want it to be not like terribly inaccurate, but even if it's a little bit messed up, it's okay, too.

s135
00:16:02.480 --> 00:16:10.440
Because in the end if you have a sufficiently good agent, it can always dive deeper into the document and surface the right information with the right citations and grounding.

s136
00:16:10.440 --> 00:16:19.800
So for these, you know, being able to create some sort of scalable offline indexing pipeline that has the best like cost constraints is something that is optimal.

s137
00:16:19.800 --> 00:16:25.240
One thing about VLMs based approaches though is that, you know, they're typically not very fast.

s138
00:16:25.240 --> 00:16:34.080
And I think a lot of times if you have like real-time file uploads, let's say you're using Cloud Co-work, you upload a thousand documents and you need to process it within a minute

s139
00:16:34.080 --> 00:16:41.120
a minute, like having a bunch of VLMs process that at scale is really tough for basically every single OCR service out there.

s140
00:16:41.120 --> 00:16:43.120
And and to be fair, that includes ours, too.

s141
00:16:43.120 --> 00:16:55.160
I think in general, there's also some sort of need for an extremely low latency solution so that you can actually process stuff in real-time even if you have like deeper VLM enabled processing

s142
00:16:55.160 --> 00:16:58.440
for kind of like deeper visual inspection and analysis.

s143
00:16:58.440 --> 00:17:01.560
And so that's what I call kind of being in the agent loop.

s144
00:17:01.560 --> 00:17:09.400
So besides Lama Parse, which is kind of our commercial service around like document processing and extraction, we also created this tool called Light Parse.

s145
00:17:09.400 --> 00:17:11.560
It is surprisingly really really good.

s146
00:17:11.560 --> 00:17:16.000
I don't know if you've been following some of the Twitter threads, but it is Rust-based.

s147
00:17:16.000 --> 00:17:18.520
It is the fastest open-source parser out there.

s148
00:17:18.520 --> 00:17:21.439
It is completely free, um, and there is basically no strings attached.

s149
00:17:21.439 --> 00:17:24.000
I think it's like MIT or Apache license.

s150
00:17:24.000 --> 00:17:31.160
Um, and it basically is the most accurate like markdown parser out there that doesn't use a VLM or any sort of kind of like deeper model.

s151
00:17:31.160 --> 00:17:37.480
Um, and so this is kind of nice because you can use it as a default in the assistive agent loop.

s152
00:17:37.480 --> 00:17:45.800
Um, let's say you're uploading a a bunch of documents to Quad Code, Quad Code Work, Codex, and you want it to process like a thousand PDFs extremely quickly.

s153
00:17:45.800 --> 00:17:52.600
You can always do that, um, and then, you know, equip a VLM-based parser like Llama Parser or other frontier models as a tool.

s154
00:17:52.600 --> 00:18:01.640
So, what these agents will do is they'll do like a fast pass over all the documents first, uh, uh, kind of like just scan through all the context extremely efficiently,

s155
00:18:01.640 --> 00:18:13.640
um, and then if actually needs to dive into a page with like tables, with like charts, and actually needs to more deeply understand the values, um, it will use a VLM-based tool, slower processing, to actually make sure it reads the information correctly.

s156
00:18:13.640 --> 00:18:27.480
This is available as a one-click installable skill, um, complements kind of any other deeper VLM-based OCR tool you want to use, um, and we kind of designed to make it as fast as possible and also easy to plug in to your favorite AI agent.

s157
00:18:28.680 --> 00:18:36.040
So, I kind of speed ran through a bunch of this stuff, but basically, you know, uh, we spent a bunch of time on the, uh, parsing layer.

s158
00:18:36.040 --> 00:18:44.440
There's also other, um, general components around like the semantic and storage layer in terms of document extraction and search, and of course like document workflows.

s159
00:18:44.440 --> 00:18:54.920
Um, and due to time, I'll probably kind of just, uh, skip some of the, uh, unexplored areas like agent native document formats, hill climbing as a service, and others, but I'll share the full set of slides online.

s160
00:18:54.920 --> 00:19:05.160
In terms of the semantic and storage layer, you know, besides document parsing, um, a lot of use cases also require actually getting back, uh, structured information at scale from documents.

s161
00:19:05.160 --> 00:19:16.760
Whether you're processing, you know, a million invoices or expense reports or receipts or claims, you need to make sure that, you know, you want to actually get back structured outputs that you can put into a downstream database or system.

s162
00:19:16.760 --> 00:19:27.320
And so, a lot of these use cases basically revolve around the form of, you know, how do you automate a lot of workloads that humans typically do in scanning a lot of paperwork and doing data entry.

s163
00:19:27.320 --> 00:19:32.120
Whether it is kind of, again, invoices, claims, contracts, receipts, or others.

s164
00:19:32.120 --> 00:19:35.720
We kind of created these capabilities within Llama Parse as well.

s165
00:19:35.720 --> 00:19:41.520
A lot of our capabilities are actually tuned towards like low cost while extremely high accuracy.

s166
00:19:41.520 --> 00:19:46.640
And you get back granular citations all the way back to the source document for every extracted output.

s167
00:19:46.640 --> 00:19:56.240
And of course, you can run this in a pipeline at scale with confidence scores and also, you know, being able to actually flag whether or not we're certain about a certain value

s168
00:19:56.240 --> 00:20:00.120
before deciding to put it into some sort of system.

s169
00:20:00.160 --> 00:20:08.880
There's also document search, which is a basically expanded tool set as I mentioned around retrieval, BM25, grep, vector search, reading, and scrolling.

s170
00:20:08.880 --> 00:20:14.320
And so, all these capabilities are available within some of our commercial platforms as well as open source offerings.

s171
00:20:14.320 --> 00:20:18.200
But I also just wanted to paint a picture of the general concepts out there today.

s172
00:20:18.200 --> 00:20:23.280
So, I'll skip this section about kind of what's next and then maybe just go all the way to the end.

s173
00:20:23.280 --> 00:20:24.640
I know I'm a little bit over time.

s174
00:20:24.640 --> 00:20:30.640
So, really appreciate you all spending time today and then let me just how do I get to this part really quick?

s175
00:20:30.640 --> 00:20:32.760
Oh, right.

s176
00:20:33.400 --> 00:20:34.600
I'm going to skip this piece.

s177
00:20:34.600 --> 00:20:36.720
I'll put put this online.

s178
00:20:36.720 --> 00:20:38.840
Our booth is at LG 47.

s179
00:20:38.840 --> 00:20:43.240
If you guys are interested in stopping by and we're hosting a giant pickleball tournament today.

s180
00:20:43.240 --> 00:20:45.824
So, thank you for your time.

s181
00:20:45.824 --> 00:20:47.824
[applause]