更好的搜索如何让智能体准确率从 36% 升至 98% | Aamir Shakir，Mixedbread

简要说明Brief Description

更好的搜索让这个 AI 智能体的准确率从 36% 提升至 98%——Aamir Shakir，MixedbreadBetter Search Took This AI Agent From 36% to 98% Accuracy - Aamir Shakir， Mixedbread

目录Table of Contents

• Mixedbread 简介
  Intro to Mixedbread
• 股票分析师问题
  The equity analyst problem
• 关键瓶颈
  The key bottlenecks
• “弗兰肯斯坦式技术栈”：OCR、分块与向量
  The "Frankenstein stack": OCR, chunking and vectors
• 为什么“只需添加一个向量数据库”还远远不够
  Why "just add a vector database" falls short
• 瓶颈在于对数据的访问能力
  The bottleneck is access to your data
• 检索方式的演变
  How retrieval has evolved
• 演示：搜索英特尔财报报告
  Demo: searching Intel earnings reports
• 客户成果：准确率从 36% 提升至 98%
  Customer result: 36% to 98% accuracy

Mixedbread 简介Intro to Mixedbread

先简单介绍一下 mixread 和我们正在做的事，然后我再开始讲有趣的内容。mixread 最初是一个专注于检索的研究实验室，因为我们对这个领域的发展现状感到非常失望。过去两年半，我们一直在研究如何让检索变得非常出色，最终打造出一款产品：你可以导入任何类型的数据，并让智能体能够搜索这些数据，包括 PDF、电子表格、图像、视频和音频，支持 100 多种语言。这是真正的多模态、多语言搜索，而我们拥有自己的模型。我们从零开始构建这些模型，专门用于搜索。So quickly about mixread and what we're doing before I jump into the interesting things. So mixread started as a research lab around retrieval since we were really sad about the state how the space was evolving. So we have been doing research for the two and a half years over how we can make retrieval really really good and we come ended up with a product where you can ingest any kind of data and make it searchable for agents meaning PDF, spreadsheets, images, video, audio in over 100 languages. So it's a true multimodel multilingual search where we are owning the models. So we built the models from scratch specifically for search.

我们构建了自己的数据库，这样就能实现零数据留存，并满足你需要的所有隐私要求。我们还构建了数据注入管道，这样你就不用费心管理数据注入、管理 OCR，也不用琢磨该怎么做；你只要把数据放进去，依靠我们的模型来处理就行。这样你就能构建非常、非常强大的智能体。过去三个月我真的很高兴——我们上线已经五个月了，而在过去三个月里，我们让银行和对冲基金接入了 Mixread，并开始使用它来处理数十亿份文档。主要原因是我们完全符合 ISO 标准，而且有“自带存储桶”模式，这意味着我们确实能在零数据留存的前提下，满足你所需的所有安全要求。所以说到证据层，或者使用非常、非常强大的智能体，对吧？归根结底，大多还是要处理你的数据。那么，如果你有……哦，抱歉，接下来该怎么推进？假设你正在构建一个智能体，或者你有一位股票分析师。这里有个示例查询，因为英特尔昨天发布了新款 GPU 显卡，对吧？We build our own database so we can provide zero data retention and all the privacy privacy requirements you need and also we build injection pipeline so you don't have to hustle to managing injection managing OCR and knowing what to do and instead you just dump your data into it rely on our models working good enough and you know so you can build really really powerful agents and I'm really happy that over the last three months like we're live since 5 months but over the last three months we onboarded banks and hedge funds into mixread and alive with it with billions of documents and the main reason is we are so ISO compliant and we have this bring your own bucket mode meaning that we can really offer all the security requirements you need with zero data retention so when we talk about evidence layer or using really really powerful agents right it mostly comes down to working on your data so if you have like oh sorry um how to move this forward so assume that you're building an agent or you have an equity analyst this is just like an example query because Intel yesterday released their new GPU cards, right?

股票分析师问题The equity analyst problem

就像 D270 一样，不知怎么回事，它的设计很奇怪，竟然用了大量 LPDDR5 内存。所以，你知道，假设你是一名分析师，坐在那里想：英特尔为什么要发布这个，对吧？为什么它会用这么多 LPDDR5，而不是 HBM 内存？于是，你可能会向系统提问：“嘿，新的英特尔 D270 为什么使用 LDR5 内存？”而且，你们大概在金融行业工作，手头有很多数据经纪商和数据提供商。他们会给你们发送播客、访谈、各种资料、研究材料，等等。Like the D270 and somehow it has a really weird design that it's using a lot of LPDDR5 memory. So, you know, like you're an analyst sitting there and what the Why is Intel publishing this, right? Why why does it have so much LPDDR5 and not HBM memory? So, it would ask your system a question like, hey, why does the new Intel D270 use LDR5 memory? And since you guys probably as you're working in finance, you have a lot of data brokers and data providers. They send you the podcast, they send you interviews, they send you materials, research uh stuff and so on and so forth.

所以，你现在有了这个庞大的知识库，分析师也提出了这个问题，对吧？当你使用 Claude Code 或 Claude Cowork 时，如果摄取的数据存储在本地，它通常会通过终端进行类似 grep 的词法搜索，找出诸如 ADDPR5、Intel 和 GPU 之类的关键词，进而判断哪些文档最接近、最相关。但当你有大量 PDF、文档和访谈记录时，搜索结果就会很多，却没有相关性排序，你也不知道该从哪里着手。于是模型最终会把每份文档都读一遍。这样一来，你的 token 成本就会不断攀升；文档越多，每次查询的成本最终可能高达 10 或 20 美元，只为了回答一个非常基础的问题。So you have this huge knowledge base and now your analyst is asking this question, right? So when you use cloud code or cloud cowwork, what it normally does when you have your ingest data locally, it uses the terminal and basically uh lexical search like grab to figure out, hey, where do we find terms like ADDPR5 or Intel and GPUs to just figure out, hey, what documents can be the closest and the most relevant ones? And as you have a lot of PDFs and a lot of documents and interviews, you will get a lot of hits and you have no relevancy and you don't know where to look into. So what the model will end up doing is reading every document and like this, you know, like your token cost will just go up and up and up and the more documents you have, you will end up with per query costing 10 or $20 to just ask a really basic question.

第二个缺点是，很遗憾，大多数 PDF 都不太容易解析，因为它们有时是二进制格式，里面有扫描件和图片，所以你很难利用其中的多模态数据，让它们为你所用。这些就是主要的瓶颈。接下来你可能会想：大家都在做什么？以前人们在这个领域都做过什么？有多少人听说过 RAG，也就是检索增强生成？请快速举个手。And the second downside of that is also that most PDFs sadly are not really grapable because you know like there are binary formats sometimes there are scans in there images in there so you can't really exploit this multimodel data relying in there to work for you. So these are like the key bottlenecks and then you think okay what are people doing and what people have done previously in the spade space who's familiar with the term rack retrie augmented generation just hands up really quickly.

关键瓶颈The key bottlenecks

所以我想，大多数人……呃，我想接下来要说的内容你们会有共鸣。然后我们就想，好，那我们来构建一条复杂的流水线，让所有这些数据对我们来说真正变得非常有用。我们有数十亿份 PDF、播客之类的内容。所以我们做的第一件事就是解析，对吧？所以如果你有……So I think most people so uh I think you will it will resonate what I'm going to say now. So then we were like okay good let's let's build a sophisticated pipeline where can make all this data really really usable for us. So we have this billions of PDFs podcast whatsoever. So first thing we do is we do parsing right. So if you have

“弗兰肯斯坦式技术栈”：OCR、分块与向量The "Frankenstein stack": OCR, chunking and vectors

嗯，音频我们会做转录；如果是 PDF，我们会做 OCR。每一步都会引入噪声。所以，如果你不能正确处理表格，也不能正确传递图表，就会丢失信息。然后你再进行分块。也就是说，如果表格没有正确传递，或者字符没有正确处理，你就已经丢失了信息，接着又要进行分块，对吧？如果有图、表格和页面，分块边界究竟在哪里？这会引入更多噪声。然后你把内容交给一个纯粹的嵌入模型。你知道，这种模型会接收这些信息，然后试着在空间中找一个点，来表示这些信息所代表的内容。既然信息已经丢失了这么多，你得到的这个点也会因此受到影响。于是，从如此丰富的信息变成“嘿，这里只有一个点”，整个过程就会造成极大的信息损失。接下来你把这个点放进向量数据库，进行检索和重排序。um audio we do transcription um if you have PDF we do OCR and what every of the step does it introduces noise. So if you can if you don't process tables properly, if you don't pass diagrams properly, what will happen is that you will just lose information and then you do the chunking. So you already lost information because your table is not passed properly or characters are not processed properly, then you do some chunking, right? So if you have figures, table, pages, where's really the chunk boundary? So you're introducing more noise and then you're giving it to a pure embedding model which you know like takes this information and then tries to guess a point in the space to you know like what this information represents and since it already lost so much information you are losing then having this point right and this is then a super lossy process from going from this really rich information to hey here's just a point and then you put it into a vector database do some retrieval and rerank.

所以，由于每一步都是有损的，而且每个环节都得引入一家供应商，最后你就会开始问：什么 OCR 最好？什么分块策略最好？什么嵌入模型最好？呃，什么向量数据库最好？什么排序方法最好？于是，你就得花六到八个月评估各种供应商、让他们通过安全审查，才能正式上线；而且你还得安排四到五个人来做这件事，只是为了搭建一个在我看来超级基础、最终却行不通的东西，因为这类方案本身就存在一些固有局限。我们内部把它叫作“弗兰肯斯坦式技术栈”。其实有一些论据能说明为什么单向量模型，或者只是把所有这些信息都放进嵌入模型、用一个点来表示，实际上并不管用。如果你们感兴趣，我们之后可以讨论；我也可以详细吐槽一番，解释得更深入一些。 不过，这确实是目前大家在用的最先进方案。这也是我刚才描述的那些瓶颈的原因，也解释了为什么 RAG 实际上一直没能奏效。你们应该都还记得当初的承诺：“嘿，这里有 Pinecone，或者任何一个向量数据库，放进去就能用。”但结果从来没有真正如愿。归根结底，每一步都存在严重的信息损失，而且我们现有的模型——也就是嵌入模型——以及它们目前采用的技术还不够好，所以你们没法真正有效地利用这些信息。 而我谈到这些嵌入模型的缺点时，你们得想象一下它们是怎么工作的：比如你有一条信息“我喜欢面包”，把它输入模型，模型就会取出这个句子，把它放到空间中的某个位置。之后，如果你问“谁喜欢面包？”，我们也会把这个问题输入模型，把它放到空间中的某个位置，然后就在附近搜索这个查询。So since every step is lossy and you have to add a vendor for every process, you will end up hey what is the best OCR? What is the best chunking strategy? What is the best embedding model? Uh what is the best vector database? What is the best ranking? So you will just evaluate it for six or eight months different vendors run through security to just go live and you have to allocate four to five people to that to just build something from my perspective super basic which won't work in the end because there's some inherent limits of how this things are done and we internally call it the Frankenstein stack and there like some proofs why you know like the single vector models or like just putting all this information into embedding model and one point actually doesn't really work and we can discuss it later if you guys are interested why and I can go on a rant and explain it a bit more in depth but this is actually right now the state-of-the-art what people use and this is also the reason like all the bottlenecks I described right now why rack actually never worked so you know like I think you all remember this promise of hey here's spine cone or here's any vector database just put it in and it will just work but it never really worked out and it comes down to that every step is super lossy and that also the models we have the embedding models with the technologies they're using at the moment are not good enough so you you can't really use this information properly and the downside when I talk about this embedding models is you have to imagine like how this embedding model work right you have an information like I love bread you put it into a model and then it just takes this sentence and puts it somewhere in the space and later if you ask hey who loves bread we'll put also into the model and we'll put it somewhere into space as well and then just search around the query.

为什么“只需添加一个向量数据库”还不够Why "just add a vector database" falls short

嘿，那个类似的点在哪里？基本上我们可以用它来描述这一点。不过现在我们来想想一份财务报告，比如 SEC 文件。如果里面有复杂的表格，包含各种不同的信息，比如净利润、收入等等，那么这个点到底代表什么？对吧？它可能代表有关英伟达的信息。也就是说，这是英伟达的财报，对吧？但如果你看的是 1996 年、2000 年和 2026 年的财报，这些点看起来会非常、非常相似。这就是为什么当你有大量看起来非常相似的信息时，RAG 和所有这些向量数据库方法都不起作用。我们看到，很多客户采用传统方法时，如果只有少量文档，比如几十到几百份，效果还不错；但随着规模扩大并投入生产，答案质量就会显著下降，因为这种向量搜索和这类技术无法真正区分这些细粒度的信息。问题在于，你的智能体能力很差，对吧？而它其实是想真正帮你的。Hey, where's the similar point to basically describe that but now let's think about a financial report like a sec filling. If you have like complex tables with all this different information like net income, revenue yada yada yada what does this point actually represent? Right? So maybe it uh represents information about Nvidia. So it's Nvidia's earnings report, right? But if you have the earnings report from 1996 or 2000 and 2026 the points will look really really similar. That's why when you have a lot of information which look very similar rack and all this vector database approaches don't work and we see with a lot of customers in their classic approach if you have just few documents let's say tens of hundreds of documents the quality is pretty good but as you start scaling and going into production the answer quality will just degrade significantly because this type of vector search and this type of technology is not able to really distinguish between this fine grained information and the issue is you have a pure a poor agent, right, who wants to really help you.

他会竭尽全力为你服务，为你做任何事。那么这个智能体会开始做什么？它只会不断发起大量查询，还会启动几十个子智能体。嗯，查询会越来越多。所以你知道，它只会不断占满上下文窗口，让每次查询都变得很昂贵。你可以像这样应对：多派一大群智能体去处理。但问题是，你真的想用这种方式投入生产吗？再想想，未来某个时候，你的基金或风险投资机构也许大部分都由智能体运营，智能体流量会不断增加，那么运行这些系统的成本就会飙升。He he will do everything his to serve you and do everything for you. So what will this agent start doing? It will just query aggressively. It will spin up tens of sub agents. Um we'll do more and more queries. So you know it will just fill up the context window and every query will become expensive. You can answer it like this by just putting a lot of agents on that. But the question is hey is it really the way you want to go into production? If you also imagine at one point that maybe your fund or your VC will be mostly run by agents and the volume of agent traffic will just increase. So the cost of running the systems will just skyrocket.

瓶颈在于对数据的访问能力The bottleneck is access to your data

所以，这就是为什么我们在与客户合作时，很早就得出了这样的结论：智能能力并不缺乏，真正的瓶颈其实在于能否访问你的数据和知识。我们相信，智能能力与数据将会逐渐解绑：你可以在不同的智能模型之间进行选择，但要充分发挥这些智能模型的作用，你需要确保它们能够正确访问你的数据。为此，我们打造了 Mixbread。正如我刚才提到的，Mixbread 最初是一个研究实验室。这张图非常有意思，它展示了下周即将推出的内容。嗯。So this is why we came to the conclusion pretty early when we're working with our customers that intelligence is there but the real real bottleneck is actually access to your data and to your knowledge and we believe that we will see a unbundling of intelligence and data where you have intelligence where you can choose between different intelligence models but you need to have the right access for this intelligence for your data so you can make the most of that and for this we built um mix bread. So as I mentioned mixread started as a research lab and this is a really interesting graphic and this is a preview of what's coming next week. Um

检索的演变How retrieval has evolved

检索技术从 1994 年到现在是怎么变化的？这大概有 32 年了吧，我心算没错的话。所以我们最初用的是 BM25。这就是 Elasticsearch 所采用的做法，也就是简单的关键词匹配。后来我们开始想出更聪明的方法。真正优秀的嵌入模型最早是在 2022 年发布的。也就是说，这个领域花了 27 年，才找到一种比 BM25 更好的文本搜索方法。但从那以后，我们看到的改进基本上是线性的。这也是我们说 RAG 效果不佳的原因：它从未出现过像 ChatGPT 等技术那样的阶跃式变化。我们在去年年底完成了第一个模型的训练，并于今年年初发布。它表现相当不错；但我们下周要发布的模型，我们已经让许多客户在使用了，我们认为它会带来阶跃式的变化，克服我之前提到的大多数挑战。简单来说，这个模型采用的是一种晚期交互模型。也就是说，你的文档不再只有一个嵌入向量，而是有多个嵌入向量；查询也有多个嵌入向量，就像这样。is that retrieval how it changed like over the last from 1994 to now it's like what 32 years I think my if my mental math is not wrong. So we started with BM25. This is what elastic search is doing like simple keyword matching and then we just started coming up with smarter method. So the first really good embedding models were published in 2022. So it took the space 27 years to come something up for text search better than BM25. But since then we have more like a linear um like improvement. And this is also what we meant with rack not working because there was never a step function change like we saw with chatbt and so and so forth and we published our first model by beginning uh we finished the training at end of last year published it beginning of this year it was pretty solid but the thing we're publishing next week and we already live with a lot of our customers we think is a step function change which overcomes most of the challenges I described before just in short what this model does is it's a late interaction model Meaning instead of having just one embedding, you have multiple embeddings for your documents and you have multiple embeddings for your queries like this.

你确实可以在页面上描述非常细粒度的信息。回到英伟达不同年份的 SEC 文件，对吧？模型会为净利润、净营收等等生成嵌入向量；但由于这些信息是一次性生成的，它也知道内容讲的是英伟达。因此，每个嵌入向量都带有上下文。再加上与你相关的信息，以及所有这些技术、模型规模的扩大和更好的数据，质量就有了显著提升。这让我们能实现一些很酷的功能，也让我们能够构建 Mix 这个产品：你只要上传数据，Mix 就会为你完成索引，比如按照页面的原貌逐页处理，因为它是多模态的。我会解释这是什么意思。然后，你只要让智能体访问 MixRead，智能体就会替你查询、阅读、抓取所有内容。你只需专注于有趣的部分，真正构建应用，真正构建 RARI。好吧，我来给你们看看这是什么意思。这是 MixRead。我在这里上传了一些 Intel 报告。等一下，具体在哪儿来着？比如，我上传了 Intel 的一些财报材料。在 Mix 里，你只要上传页面就行。You can really describe fine grained information on a page. So going back to the SEC filling for Nvidia for different years, right? So you would have the model would figure out an embedding for net income for net revenue etc etc but since it's like creating it in one pass it also know it's about Nvidia. So every embedding is contextualized and with the information which are relevant to you and all this technique and scaling up the model and better data gives us significant jump in quality uh which allows to do some cool things which allows to actually build this product uh mix where you just upload your data mix takes care of indexing it for you like every page as it looks because it's multimodel I will show what it means and you then just can give it agent access to mixread and the agent does the querying the reading the grabbing everything for you and you can just focus on on what's fun actually building the real application and actually building real RARI right so um let me show you what it means so this is mixre and what I did here is I uploaded some um Intel um wait hold on where is it exactly so I uploaded some Intel reports here for example the Intel earning stack so what you do in mix is just upload the uh page.

演示：搜索英特尔财报Demo: searching Intel earnings reports

网速挺慢的。我[嗤笑]希望没事。所以，呃，这里网速很慢，没能加载出来。真的很抱歉。嗯，我本来应该录个视频的。嗯，那我们来做这个。好。所以这里它的作用是，我们有一张幻灯片。拜托，老兄。你看，这里有一个，呃，是有个图形，对吧？The internet is pretty slow. I [snorts] hope it will be fine. So, it's it's failed to load because the internet is slow here. I'm so sorry about that. Um I should have recorded a video. Um so, let's do this. Cool. So, what it does here is so we have a slide. Come on, dude. So, you see there's a uh is there's a figure, right?

通常，如果你只是对图表做 OCR，想知道英特尔 2025 年第二季度的实际营收，那么仅靠 OCR 就会丢失所有信息，根本无法真正匹配到对应页面，因为你需要理解页面上发生了什么。但如果你基于视觉感知来创建 embedding，也就是让模型查看页面截图，并据此创建 embedding，就能去掉我刚才提到的所有无用内容。不过，由于并非所有 LM 都是多模态的，MixRead 仍会提供布局信息和 OCR 结果，供下游流程使用；你可以自行决定是否加入截图或文本，以便正确处理。我们一起来试试看吧。So normally if you would just do OCR and the figure and you want to know the actually the revenue of Intel in Q2 2025 if you just would do OCR you would just all lose all information it would never really able to match the page because you need to understand what's going on there but if you create the embedding on the visual perspection like looking let the model look at the page the screenshot and create the embedding based on that you are getting rid of all this useless stuff I was talking before but since not all LM are multimodel mixread still provides stuff like layout information and OCR for your downstream thing where you can decide to put in the screenshot or the text yourself to do the right thing and let's just try it out together.

比如说，我们想知道：嘿，英特尔代工业务部门在 2025 年第二季度的营业利润率是多少？它就会开始处理。我希望这次能成功。通常不到 200 毫秒，不过你刚才已经看到它运行了。我们看到，嘿，它不知怎么找到了这个页面，这里谈的是代工业务。往下看，来吧，你可以的——好了，这里说的是 2025 年第二季度。它也理解到，嘿，这 somehow 和分部营收有关，并且确实能传递所有这些信息。由于我们有这些视觉布局相关的功能，我们实际上可以用边界框来引用这些内容。当你的分析师或智能体推导出一个决策时，你可以追溯并引用它的出处。我们提供了所有 API 和基础组件，让你可以自己构建这样的体验。如果你有非常非常复杂的查询，比如你想了解一些更偏定性的问题：嘿，英特尔的代工业务盈利能力是在改善吗？推动这一变化的因素是什么？So let's say we want to know hey what was in Intel's foundry segment operation margin in Q2 2025 it goes out I hope it will work now normally it's like sub 200 milliseconds but you saw the thing before um so we see hey it finds somehow this page here which is talking about in Foundry and down here come on you can do it here you go it's talking about Q2 to 2025 and it understands also hey it's somehow about segment revenue and can really pass all this information and since we have this visual layout stuff we can actually reference this with bounding boxes and when your analyst or your agent is deriving to a decision you can actually backtrack and site where it is coming from and we're providing all the APIs and all the primitives for you to build this experience yourself and if you have like really really complex queries for example you want to know like something more qualitative Hey uh is Intel's foundry uh prof uh profitably improving and what is driving it?

所以，如果你只是查询它，比如说，我们的系统会意识到：“嘿，这是一个更复杂的查询，我们来做一次遗传搜索。”遗传搜索是我们训练的一个模型，叫 Toast One。它就像一个代理，可以替你执行多次查询，进行多跳推理；它的效果和 Astra、Fable 一样好，但速度快 40 倍、成本也低 40 倍。它会执行多次查询，真正把所有内容拆解开来，然后带着正确的数据返回。接着，这些数据可以输入 LLM，让它解释到底发生了什么。我们也把它作为一种基础原语开放出来。这只是一个演示，一个展示可能性的游乐场；不过你可以直接使用它，把它交给代理，让代理根据复杂程度决定使用 Grab、普通搜索还是智能体搜索。没错。So if you just query it for example our system realize hey this is a more complex query let's do a genetic search a genetic search is a model we trained toast one it's like a agent which does multiple queries for you multihop reasoning and it's as good as Astra and fable while being 40 times faster and cheaper which then goes out and does like multiple queries um and can really decompose everything and come back with the right data and uh this data can then fed into an LLM to actually explain what what what is happening there and we just also expose it as a primitive. This is just a demo, a playground to show you what's possible, but you can just use it, give it to an agent and let the agent decide if you want to use grab, normal search or the agentic search depending on the complexity. Exactly.

对，嗯，所以这是一个备用方案，以防原来的方案行不通。嗯，智能体可以完成所有事情。这里还有一个小案例研究，我们也会在两周后发布。客户是一家规模非常大的对冲基金。我们大约花了一周半就完成了接入。嗯，因为他们现在有超过 10 亿份文档，而且正在为分析师和基金经理搭建大量内部智能体平台，用来得出定性分析，并判断某个决策是否明智。在此之前，他们采用的是我前面描述的那套方案：文本分块、OCR、随便找个嵌入模型，再加上向量数据库。他们的答案准确率只有 36%——也就是在人工专家知道答案并进行评分的情况下，智能体答对的频率。迁移到 Mixedbread 后，答案准确率升到了 98%。因为问题再次说明，关键不在于智能，而在于能否找到正确的数据。只要为智能体提供好得多的搜索能力，首先就能让它表现得非常出色。嗯，这里展示了多模态和文本问题的细分情况，可以看到，多模态让准确率提升相当显著。其次，使用的 token 也少得多，因此大语言模型的开销降低了 3 倍，因为大多数 token 都耗在查找、解析和读取信息上。And yeah, um so this is uh was as a backup if it wouldn't have worked. Um so the agent can do everything. And here a small case study which we will publish also in two weeks from now. It's like a really big hedge fund. We on boarded within like one and a half weeks. um because they have like over 1 billion documents right now and they are building a lot of internal agent platform for the analyst and for their fund managers to derive qualitative uh analysis and also come up with should we is it a good decision or not and before they have built what I described before this chunking betting OCR some random embedding model some vector database and they had a answer accuracy like how often the agent is right of 36% where the human experts knew the answer and graded And once they move to mix spread the answer accuracy moved to 98% because the again the issue is not intelligence it's again getting the right data and just by providing way better search to your agents you can first make it really good um here's a breakdown on multimodality and text questions and as you can see multimodality is just bumps it quite significantly but second is you use also wafier tokens so the LM spend is going down by 3x because again most of the tokens are used to find, pass, and read information.

客户成果：准确率从 36% 提升至 98%Customer result: 36% to 98% accuracy

而且正如你刚才很好地融入了相关上下文，你知道，这样你所需的 LLM 成本会低得多，LM 也能专注于相关内容。And as you just fit in really good context, you know, like you just need way less LLM cost and the LM can just focus on what's relevant.

嗯，没错。简单来说，这就是我今天演讲的全部内容。嗯，如果你想试试 MixPread，我们在楼下有宣传单可以拿，我觉得它们挺有意思的。嗯，你也可以注册。我们提供免费额度。呃，如果你担心安全问题，可以直接联系我们。我们会在 5 分钟内为所有客户启用自带存储桶功能，然后你就可以开始试用了。如果你有非常大型的语料库，我们还会提供大量免费额度，让你在正式接入之前进行基准测试。Um, exactly. So, this is my talk in a nutshell. Um, if you want to try out MixPread, uh, this we have toast, uh, flyers downstairs, so if you want to take them, I think they're pretty funny. Um, and you can sign up. We have free credits. Uh, if you are concerned about security, you can just write us. We activate bring on bucket within 5 minutes for all of our customers and then you can just start trying it and if you have like really large corpuses we provide a lot of free credits so you can benchmark it before really onboarding it.