Mistral 推出 Agentic Search:以多步检索循环打破传统 RAG 局限,准确率最高提升 3 倍
英文标题:Agentic Search. More accurate and efficient results from your AI systems.
Mistral 正式发布面向企业级复杂与敏感数据的 Agentic Search(智能体检索)及配套工具包 Mistral Search Toolkit,现已集成至 Studio 与 Vibe。该技术突破了传统单次 RAG(One-shot RAG)的切片与推理瓶颈,通过 search、open、navigate、read 和 grep 五大类文件系统操作工具构建多步检索与验证循环。在 FinanceBench 金融评测中,Agentic Search 将问答准确率从 26.7% 提升至 86%,同时使 p90 延迟降低 39.6%、Token 消耗减少达三分之一。这一架构让检索质量直接随底层大模型的推理能力提升而进化,为金融、法律等深度文档智能应用提供了全新范式。
123.3 KB
123.3 KB
172.4 KB
221.3 KB
23.8 KB
22.4 KB
710.1 KB
中文
![]()
Mistral Agentic Search 允许模型自主搜索并浏览企业内部最复杂的数据与文档,从而帮助企业从 AI 系统中获得更优的结果。无论数据存储在何处,Agentic Search 都能引入多步检索循环,在各类数据源中查找、检查并验证信息。Agentic Search 可通过 Mistral Search Toolkit 获取,并已内置于 Studio 和 Vibe 的 Libraries 中,带来以下核心优势:
- 支持敏感的领域特定数据:Mistral 便携且开放的工具集可助你在云端或本地部署中释放数据价值,绝不跨越你的隔离边界。
- 显著改进搜索结果:你的模型可以超越简单召回的分块(chunks),在冗长、密集的文档内部或跨多个数据源进行深入搜索与导航浏览。
- 无缝对接现有索引:Agentic Search 基于你现有的搜索索引构建,提供五大工具:
search、open、navigate、read和grep。 - 更高的准确率:在 FinanceBench 基准上,Agentic Search 在金融申报文件问答中的正确率提升至 3 倍(从 26.7% 跃升至 86%);在高度依赖表格和多文档问题的 OfficeQA Pro 基准测试中,我们测得了 +45.6 个百分点的提升(从 6.3% 提升至 51.9%)。
- 更低的延迟与 Token 消耗:精准的定向导航使 Agentic Search 的 p90 延迟降低高达 39.6%;更少的不必要重复搜索将 Token 消耗降低了多达三分之一。
数据构筑竞争优势
竞争优势建立在多年的实际业务运营之上——即你的数据、流程与行业专识。专有知识不仅对业务成功至关重要,而且高度机密,这意味着它们往往存在于隔离边界、分段部署及私有化托管平台之后。这些数据沉淀在财务报表、法律合同、内部资料及政府记录中——这些冗长且密集的文档是传统搜索方法无法有效导航浏览的。
具备持续学习与改进能力的 Agent 可以助你成倍放大竞争优势,但出于安全考虑,这些 Agent 往往与机密数据及专有知识相互隔离。要想让 AI 产生真正的业务价值,就必须将前沿模型的推理能力与能够安全触达敏感资产的检索工具结合起来。
传统 RAG 的局限性
传统的单次 RAG(One-shot RAG)仅检索一组固定的文本块,并要求模型在单次传递中给出答案。当答案正好出现在最靠前的检索结果中时,这种方式很有效;但当模型必须通读长篇报告、追踪引用来源、对比多份文档或验证底层证据时,它就会力不从心。
在处理密集、复杂的长文档时,这一限制更加明显。回答某个问题所需的信息可能分散在多份文档中,或者深藏于某张特定表格、脚注或法律条款内。基于单次 RAG 的搜索由于以下三个原因,无法发挥前沿 AI 的全部实力,也无法提供可靠的答案:
- 检索缺乏推理(Retrieval without reasoning):模型必须根据初次检索挑选出的文本块进行回答,即使这些切片不完整或不相关也是如此。模型在作答前无法自主判定是否需要另一份文档、另一章节或更多上下文,这极大限制了模型推理能力的作用。
- 切片级限制(Chunk-level limit):核心数据往往保存在复杂的多模态文档中。当被问及*“该公司第三季度的实际有效税率是多少?”*时,索引或许能找到正确的文档,但无法将其打开、定位到对应表格、阅读周边上下文或核对验证答案。
- 缺乏迭代过程(No iteration):许多复杂问题需要多次检索传递才能得出正确答案。模型可能需要调整搜索关键词、检查有希望的文档、顺着引用深入查阅、对比多个数据源、记录已知信息,并在首轮结果不充分时尝试新路径。单次 RAG 完全没有提供采取这些后续步骤的机制。
未使用 Agentic Search(单次检索)
提问:严格仅使用 1953 年所有单独日历月份的报告值,美国国防及相关活动支出的总和是多少(以百万名义美元计)?
轨迹:1 次 tool_call(仅 search)
search("national defense expenditures monthly 1953") → 10 条结果:分散的月度公报(表 3),每份均按财年划分,仅涵盖 1953 年的部分月份。
回复:我找到了 1953 年 1 月至 6 月的数据。但我还需要 1953 年 7 月至 12 月的月度数值来计算最终结果。
使用 Agentic Search
提问:严格仅使用 1953 年所有单独日历月份的报告值,美国国防及相关活动支出的总和是多少(以百万名义美元计)?
轨迹:3 次 tool_calls(2 次 search → read)
search("national defense expenditures monthly 1953") → 月度公报(仅包含部分年份)
search("…1953 November December 1954 to date") → 检索到 treasury_bulletin_1954_02.pdf 第 15 页(表 3,涵盖 1953 年全部 12 个月)
read(treasury_bulletin_1954_02.pdf, p.15) → 调取完整的表 3
1953 年各月数值(表 3,单位:百万美元):
| 一月 | 二月 | 三月 | 四月 | 五月 | 六月 | 七月 | 八月 | 九月 | 十月 | 十一月 | 十二月 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 3,632 | 3,501 | 3,789 | 3,891 | 3,746 | 4,056 | 3,890 | 3,519 | 3,787 | 3,647 | 3,540 | 3,465 |
总和 = 44,463。
Agentic Search 的工作原理
Mistral Search Toolkit 提供了开放模块,用于在云端或本地对关键且复杂的数据进行数据接入(ingesting)、向量嵌入(embedding)和构建索引(indexing)。Agentic Search 基于该索引,为模型提供了类似于熟悉的文件系统操作的五大工具:
search:使用现有索引在整个语料库中查找相关文档。open:打开指定文档。navigate:跳转到文档内的特定页面、章节或区域。read:读取该位置的具体内容。grep:在已打开的文档中匹配查找模式/关键字。
模型无需仅根据最初返回的 top-k 个切片作答,而是可以检查发现的内容、改进检索词、打开相关文档、导航至特定章节,并在给出最终答案前细读源材料。索引负责锁定可能的数据来源;Agentic Search 则负责决定在这些来源内部及之间检查什么内容。
单次 RAG(One-shot RAG)

Agentic Search

这些工具不需要微调或针对特定模型进行训练。随着模型推理与工具调用能力的演进,无需变更底层基础设施,检索表现就会同步增强。这是一个核心特性:检索质量将直接随模型能力增强而扩展,不再被固定的切片策略(chunking strategy)所束缚。
Agentic Search 适用场景
- 超长文档:财务报表、法律合同、技术手册、规格说明书和研究报告,答案可能出现在特定页码、某张表格、某项条款、图表或脚注中。
- 跨多数据源问答:需要在得出结论前跨多份文档查找、比对或核实证据的研究任务。
- 必须验证的事实与答案:财务数据、法律条款、监管合规引用与运营数据,其最终答案必须在文档的确定位置留有稳定且明确的引用来源。
- 表格与结构化文档:财务报表、政府记录和扫描版 PDF,其语义高度依赖行、列、页面位置或上下文环境,而非仅凭叙述性文本即可表达。
传统索引检索(Indexed Retrieval)更适合作为起点的场景
- 直接查阅(Direct lookups):简短、干净的文档,答案很可能就出现在前几个检索切片中。
- 高并发搜索(High-volume search):只需返回相关段落,而不需要在段落之上进行推理或层层导航的关键词检索或语义检索。
- 简单且预期明确的问题:答案的可能来源和位置提前已知,进一步的检索步骤不太可能改变或提升结果。
对于上述场景,单次 RAG 通常已经足够。但当问题要求模型超越初次检索结果、对源材料进行深入探查时,便需要引入 Agentic Search。在这两种模式下,配置合理的索引底座都是关键基石。
更相关的结果,更快的响应速度
我们在两项行业标准基准上对 Agentic Search 进行了评估,均使用开箱即用的 Mistral Search Toolkit 技术栈:默认分块、默认重排、未经特定微调。这些测试结果代表的是性能底线而非上限,意味着通过针对特定业务场景的定向调优,质量还可进一步提高。
在这些基准测试中,我们使用 Mistral Search Toolkit 测试了两个模型:Mistral Medium 3.5(MM 3.5)和 Z.ai GLM-5.2(GLM-5.2),分别展示了较小体量模型(MM 3.5)与较大体量模型(GLM-5.2)的表现。
基准测试结果呈现出高度一致性:智能体检索循环带来了实质性的质量跃升,而导航工具在提高准确率的同时,大幅减少了无谓的 Token 消耗、交互轮次和请求延迟。我们在第一方与第三方模型上观察到了完全相同的性能提升模式,这表明 Agentic Search 具备模型通用性(model-agnostic),搜索质量将伴随新模型的演进而持续增强。
FinanceBench:368 份 SEC 申报文件,150 个问题
FinanceBench(Islam 等人,2023)测试了针对 368 份 SEC 申报文件(10-K / 10-Q / 8-K)的金融问答能力,平均每份文件约 147 页,语料库总计约 53,900 页,属于极长且高密度包含表格的金融文件。答案由经过人类标注校准的 LLM Judge 进行评判打分。
测试模型:
- Mistral Medium 3.5
- GLM 5.2
测试结论:
- 仅包含 search 的 Agentic 循环是最大的质量杠杆:从单次 RAG 切换到纯 search 的循环,MM 3.5 的准确率提升了 +47.3 个百分点,GLM-5.2 提升了 +52.6 个百分点——两个模型的准确率均实现约 3 倍的增长。因为模型能够迭代搜索,所以能够从质量欠佳的初始结果中恢复过来、细化查询词,并将索引作为主动工具使用。
- 导航工具进一步拉升准确率:加入 open、navigate、read 和 grep 工具后,准确率再次显著上涨(MM 3.5 增加 +8.7 个百分点,GLM-5.2 增加 +6.7 个百分点)。这证明在复杂文档中,定向钻取式搜索显著优于反复的粗粒度泛搜索。
- 更优的检索工具有效提升 Token 与性能效率:相较于纯 search 循环,配备 Navigation 的完整闭环在正确回答更多问题的同时,消耗的 Token 显著更少(MM 3.5:Token 消耗减少 23.9%,GLM-5.2:减少 33.7%)。这些检索工具不仅没有增加额外开销,反而通过精准定位替代了徒劳的重复搜索重试。
- 在关键瓶颈上显著缩短延迟:在整个 FinanceBench 测试中,引入导航检索工具有效降低了响应延迟:p90 延迟从 255 秒下降至 154 秒,平均延迟从 108 秒下降至 71 秒。通常情况下,纯 search 循环会执行多轮反复的泛化检索,而导航工具能帮助模型更快锁定证据。
OfficeQA Pro:696 份财政部公报,133 个问题
OfficeQA Pro 是针对历史美国财政部公报(U.S. Treasury Bulletins)的可验证数值问答基准,涵盖 696 份文档、约 89,000 页密集的扫描版政府金融 PDF。我们汇报了针对 133 题 "Pro" 子集的初次评估成绩。
测试模型:
- Mistral Medium 3.5
- GLM 5.2
测试结论:
- Agentic Search 及“智能体循环 + 导航”在更严苛的可验证基准上表现优异:OfficeQA Pro 涉及精确数值答案、扫描件 PDF 及深层表格查找。即便面对如此棘手的场景,完整 Agentic 闭环相比单次 RAG 依然实现了实质性跃升:GLM-5.2 达到 51.9%(提升 +45.6 个百分点),MM 3.5 提升了 +27.1 个百分点。
- 导航功能在提高质量的同时大幅降低浪费:使用完整闭环(Agentic 循环 + Navigation)让准确率提升最高达 35.6%(MM 3.5 提升 +7.5 个百分点;GLM-5.2 提升 +8.3 个百分点,增幅 19.0%),同时降低了 Token 消耗。交互轮次也降低了多达 7.0%(MM 3.5 降低 7.0%,GLM-5.2 降低 2.3%)。
- 基准测试难度越高,检索循环就越发重要:OfficeQA Pro 围绕扫描版表格密集型文档中的数值答案构建。单次 RAG 在此场景下寸步难行,而 Agentic 循环能够赋予模型迭代搜索与核验证据的能力,实现精度的跨越式增长。
- 工具技术栈对文档智能与搜索性能产生决定性影响:根据 Kimi 的研究,在 OfficeQA Pro 基准上,使用 Claude Code harness 的 GLM-5.2 得分为 41.4%,而使用 Mistral harness 则达到 51.9%——在完全相同的底层模型下实现了高达 +10.5 个百分点的提升。
开始使用
欢迎查阅 官方文档 深入了解 Agentic Search。你可以通过以下任一方式在云端或本地环境中快速上手:
- Mistral Search Toolkit:将 Agentic Search 集成到你自有的 Agent、工作流和客户部署场景中。
- Libraries:在 Studio 和 Vibe 中开箱即用 Agentic Search,无需从零搭建底层检索系统。
测试 Search Toolkit 最快的方法是使用 Search Starter App。它能借助默认配置直接为你的语料库构建本地索引,即使你不是搜索专家也能即刻上手体验 Agentic Search。当你准备好根据特定场景进行深度定制时,你可以:
- 配置数据接入(Ingestion):为你的数据与文件类型选择适宜的解析器、分块策略、向量嵌入模型及提取器。
- 调优索引与排序(Indexing & Ranking):管理 Vespa schemas、索引行为与相关性偏好配置。
English / 原文
![]()
Mistral Agentic Search helps enterprises get better results from their AI systems by letting models search and navigate their organization’s most complex data and documents. Agentic Search introduces a multi-step retrieval loop for finding, inspecting, and verifying information across data sources, wherever it is stored. Agentic Search is available through Mistral Search Toolkit, built into Libraries in both Studio and Vibe, and gives you:
-
Support for sensitive domain-specific data. Mistral’s portable and open tooling helps you unlock value from your data without crossing your isolation boundaries in the cloud or on-premises.
-
Improved search results. Your models can search and navigate your data beyond retrieved chunks–inside long, dense documents or across multiple sources.
-
Access to existing indexes. Agentic Search builds on your existing search index using five tools:
search,open,navigate,read, andgrep. -
Higher accuracy. Agentic Search delivers to 3x correctness on financial filings, from 26.7% to 86%, based on FinanceBench. On table-heavy, multi-doc questions of the OfficeQA Pro benchmark, we measure a +45.6 point gain (6.3% to 51.9%).
-
Lower latency and token use. Targeted navigation enables Agentic Search to reduce p90latency up to 39.6%. Fewer repeated searches reduce token consumption by up to one-third.
Data creates competitive advantage
Competitive edge is built upon years of real-world operations–your data, your processes, and your domain expertise. Proprietary knowledge is both critical to your success and highly confidential, meaning it lives behind isolation boundaries, segmented deployments, and self-hosted platforms. It accumulates in financial filings, legal contracts, internal resources, and government records–long, dense documents that traditional search methods can’t navigate effectively.
Agents that learn and improve continuously can help you compound your competitive advantage, but these agents are often separated from confidential data and proprietary knowledge for security reasons. Getting real impact from AI means pairing frontier reasoning with retrieval tools that can safely reach your most sensitive material.
Traditional RAG falls short
Traditional, one-shot RAG retrieves a fixed set of text chunks and asks a model to answer in a single pass. This works when the answer appears in one of the top results, but falters when the model must navigate a long report, follow references, compare multiple documents, or verify the underlying evidence.
The limitation is more pronounced on dense, complex data and documents. The information needed to answer a question may be spread across documents or buried in a particular table, footnote, or clause. One-shot RAG-based search fails to use the full power of frontier AI and to provide reliable answers for three reasons:
-
Retrieval without reasoning: The model must answer from the chunks selected during the initial retrieval, even when they are incomplete or not relevant. It cannot decide that it needs a different document, another section, or more context before responding, which limits the impact of the model’s reasoning.
-
Chunk-level limit: Critical data is often held in complex multi-modal documents. When asked, “ What was the company’s effective tax rate in Q3?” an index may find the correct document but cannot open it, navigate to the table, read the surrounding context, or verify the answer.
-
No iteration: Many questions need more than one retrieval pass to get the correct answer. The model may need to refine its search, inspect a promising document, follow a reference, compare multiple sources, keep track of what it has seen, and try a new route when the first results are insufficient. One-shot RAG provides no way to take these next steps.
Without Agentic Search (one-shot retrieval)
Using specifically only the reported values for all individual calendar months in 1953, what is the total sum of these values of expenditures for U.S. national defense and associated activities (in millions of nominal dollars)?
Trajectory 1 tool_call (search only)
search("national defense expenditures monthly 1953") → 10 hits: a scatter of monthly bulletins (Table 3), each framed fiscal-year, covering only part of 1953.
I found January–June 1953 data. But I need July–December 1953 monthly values to compute an answer.
Using specifically only the reported values for all individual calendar months in 1953, what is the total sum of these values of expenditures for U.S. national defense and associated activities (in millions of nominal dollars)?
Trajectory 3 tool_calls (2× search → read)
search("national defense expenditures monthly 1953") → per-month bulletins (partial year)
search("…1953 November December 1954 to date") → surfaces treasury_bulletin_1954_02.pdfp.15 (Table 3, all 12 months of 1953)
read(treasury_bulletin_1954_02.pdf, p.15) → pulls the complete Table 3
Monthly Values for 1953
Table 3, in $millions
| Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 3,632 | 3,501 | 3,789 | 3,891 | 3,746 | 4,056 | 3,890 | 3,519 | 3,787 | 3,647 | 3,540 | 3,465 |
Sum = 44,463.
How Agentic Search works
Mistral Search Toolkit provides open modules for ingesting, embedding, and indexing critical and complex data in the cloud or on-premises. Agentic Search builds on this index by giving the model five tools that resemble familiar file-system operations:
-
searchfinds relevant documents across the corpus using the existing index. -
openopens a specific document. -
navigatemoves to a page, section, or region within it. -
readretrieves the content at that location. -
grepfinds a pattern within an open document.
Rather than answering only from the initial top-k results, the model can inspect what it finds, refine its search, open relevant documents, navigate to specific sections, and read the source material before answering. The index identifies likely sources; Agentic Search determines what to inspect within and across them.
One-shot RAG

Agentic Search

These tools do not require fine-tuning or model-specific training. As models get better at reasoning and tool use, retrievals get better without infrastructure changes. This is a key property: retrieval quality scales with model capability instead of being capped by your chunking strategy.
Use Agentic Search for
-
Long documents. Filings, contracts, manuals, technical specifications, and reports where the answer may appear on a particular page or in a specific table, clause, figure, or footnote.
-
Questions across multiple sources. Research that requires the model to find, compare, or reconcile evidence from several documents before reaching an answer.
-
Answers that must be verified. Financial figures, legal clauses, regulatory references, and operational data, where the response can be referenced in a stable and specific document location.
-
Tables and structured documents. Financial statements, government records, and scanned PDFs where meaning depends on rows, columns, page position, or surrounding context–not narrative text alone.
Indexed retrieval is the right starting point for
-
Direct lookups. Short, clean documents where the answer is likely to appear in one of the first retrieved chunks.
-
High-volume search. Keyword or semantic lookups that need to return relevant passages without reasoning over or navigating through them.
-
Simple, predictable questions. Use cases where the likely source and location of the answer are known in advance and additional retrieval steps are unlikely to improve the result.
One-shot RAG is often sufficient for these searches. Add Agentic Search when questions require the model to move beyond the initial results and investigate the source material. A well-configured index remains the right foundation in both cases.
More relevant results, faster
We benchmarked Agentic Search on two industry-standard evaluations, using the out-of-the-box Mistral Search Toolkit stack: default chunking, default ranking, no tuning. These results are floors, not ceilings,**** meaning you can further improve result quality with use-case-specific tuning.
With these benchmarks, we tested two models using the Mistral Search Toolkit: Mistral Medium 3.5 (MM 3.5) and Z.ai GLM-5.2 (GLM-5.2), showcasing performance of a smaller model (MM 3.5) and a larger model (GLM-5.2).
Benchmark results are consistent: the agentic loop delivers substantive quality improvements and navigation tools increase accuracy while reducing wasted tokens, turns, and latency. We observe the same performance patterns across first- and third-party models, which indicates that Agentic Search is model-agnostic, and that search quality should improve with new models.
FinanceBench: 368 SEC filings, 150 questions
FinanceBench (Islam et al., 2023) tests financial question-answering over 368 SEC filings (10-K / 10-Q / 8-K), averaging ~147 pages each, ~53,900 pages total: long, table-heavy financial documents. Answers scored by an LLM judge calibrated against human labels.
-
Mistral Medium 3.5
-
GLM 5.2
We found:
-
The search-only Agentic loop is the biggest quality lever. Moving from one-shot RAG to a search-only loop lifts accuracy by +47.3pp for MM 3.5 and +52.6pp for GLM-5.2–a ~3x improvement for both models. Because models can search iteratively, they can recover from weak first results, refine queries, and use the index as an active tool.
-
Navigation adds accuracy. Adding open, navigate, read, and grep lifts accuracy again (+8.7pp for MM 3.5, +6.7pp for GLM-5.2). This means a targeted drill-in search beats repeated broad search in complex documents.
-
Token and performance efficiency improve with better retrieval tools. The full loop with Navigation answers more questions correctly while using fewer tokens than the search-only loop (MM 3.5: -23.9% token usage , GLM-5.2: -33.7%). The retrieval tools are not additional overhead–they replace wasted search retries with precise navigation.
-
Latency goes down where it matters. Across FinanceBench, adding navigation retrieval tools improves latency: p90 drops 255s → 154s and mean latency drops 108s → 71s. In general, we see the search-only loops conduct repeated broad searches, while navigation helps the model identify evidence more quickly.
OfficeQA Pro: 696 Treasury Bulletins, 133 questions
OfficeQA Pro is a verifiable numeric benchmark over historical U.S. Treasury Bulletins: scanned, table-heavy government-finance PDFs across a 696-document, ~89,000-page corpus. We report the first pass for the 133-question "pro" subset.
-
Mistral Medium 3.5
-
GLM 5.2
We found:
-
Agentic Search and the Agentic loop + Navigation are successful against a harder, verifiable benchmark. OfficeQA Pro has numeric answers, scanned PDFs, and deep table lookups. Even here, the full agentic loop lifts accuracy materially from one-shot RAG, reaching 51.9% for GLM-5.2 (+45.6pp) and increasing +27.1pp for MM 3.5.
-
Navigation improves quality while cutting waste. Using the full loop (Agentic loop + Navigation) improves accuracy byup to 35.6%(+7.5pp, MM 3.5; +8.3pp, 19.0% GLM-5.2), while reducing token consumption. Turns declined by up to 7.0% (MM 3.5, 2.3% GLM-5.2).
-
The harder the benchmark, the more important the retrieval loop becomes. OfficeQA Pro is built around numeric answers in scanned, table-heavy documents. One-shot RAG barely gets started, while the agentic loop allows the model to search iteratively, inspect evidence, and deliver substantial accuracy improvements.
-
The tooling stack drives substantial impact on document intelligence and search performance. Per Kimi research, GLM-5.2 scores 41.4% on OfficeQA Pro with the Claude Code harness, compared with 51.9% on the Mistral harness–+10.5pp on the same underlying model.
Getting started
Learn more about Agentic Search in the documentation. You can get started across cloud and on-premises deployments using either:
-
Mistral Search Toolkit. Integrate Agentic Search into your own agents, workflows, and customer deployments.
-
Libraries. Use Agentic Search out-of-the-box in Studio and Vibe, without building the retrieval system yourself.
The fastest way to test Search Toolkit is with the Search Starter App. It creates a local index for your own corpus using a default configuration, so you can try Agentic Search without needing to be a search expert. When you’re ready to configure your use case, you can:
-
Set up ingestion. Select parsers, chunking strategies, embedding models, and extractors for your data and file types.
-
Tune indexing and ranking. Manage Vespa schemas, indexing behavior, and relevance profiles.
-
Extend retrieval. Add query rewriting, reranking, or hybrid retrieval to the search pipeline.