RAG 与 Agentic Search 生产级落地指南目录核心认知：两种范式的本质差异选型决策框架成熟技术栈选型

版本：2026.03 | 面向：有实际落地需求的工程团队 | 聚焦：成熟可用方案，不谈实验性技术

1. 核心认知：两种范式的本质差异

理解两者的根本区别，是做出正确决策的前提。

传统 RAG 的本质

传统 RAG 是一个单次确定性流程：查询进来，固定检索一次，固定生成一次，结果出去。它的隐含假设是"用户的问题可以被一次向量检索命中"。这个假设在简单问答场景下成立，但在以下情况下必然失败：

多跳推理：答案分散在多个文档中，需要先找到 A，才能知道去找 B
否定与聚合：「哪些产品不支持 X 功能」「统计满足条件的所有条目」——向量相似度天然不擅长否定和全量遍历
时序依赖：需要先确定一个前提事实，再构造第二个查询的场景
模糊起点：用户问题本身表述模糊，直接检索命中率极低

Agentic Search 的本质

Agentic Search 是一个迭代推理循环：LLM 作为决策主体，自主判断"当前信息是否足够"，不足则继续检索，充足则终止。它的核心价值不是"更强的检索"，而是让 LLM 参与检索策略制定。

代价是显而易见的：每轮检索都需要一次 LLM 调用，3 轮检索意味着 3-5 次 LLM 交互，延迟从秒级变为 5-15 秒，成本上升 10-30 倍。

关键判断原则

不要因为 Agentic Search 听起来更先进就默认选它。在生产中，80% 的查询是单跳问题，传统 RAG 在这些场景下速度更快、成本更低、行为更可预测。Agentic Search 应当是针对复杂问题的补充手段，而非替代方案。

2. 选型决策框架

2.1 问题复杂度判断

首先对你的业务查询做抽样分析（取 200-500 条真实查询），按以下维度分类：

单跳问题（传统 RAG 足够）

答案存在于某个具体段落，问法直接
例：「我们的退款政策是什么」「产品 A 的最大功率是多少」「XX 合同的签订日期」

多跳问题（需要 Agentic Search）

答案需要跨越多个文档或推理链
例：「对比 A 方案和 B 方案在高并发场景下的优劣」「找出所有在 2025 年后修订过的合规条款」「张三负责的项目中，哪些超出了预算」

典型生产场景中的比例：企业知识库约 70-75% 为单跳，法律/金融文档分析约 40-50% 需要多跳，通用客服约 85% 为单跳。

2.2 决策树

业务查询类型分布？
│
├── 单跳占比 > 80%
│   └── 传统混合 RAG（方案 A）── 优先选择，覆盖绝大多数场景
│
├── 多跳占比 > 30%
│   └── 智能路由系统（方案 B）── 路由判断后分流，主流生产推荐
│
└── 几乎全部需要深度推理
    └── 纯 Agentic Search（方案 C）── 仅用于专业分析类产品

90% 的生产项目应选方案 B：在入口处做轻量路由判断，简单问题走传统 RAG，复杂问题走 Agentic Search。路由本身用小模型完成，额外延迟 < 200ms，但节省了大量不必要的多轮 LLM 调用。

2.3 不适合 Agentic Search 的场景

以下场景即便问题复杂，也不应使用 Agentic Search：

实时性要求 < 1s：物理上不可能，多轮 LLM 调用无法在 1 秒内完成
高并发 > 500 QPS：每次查询多轮 LLM 调用，成本和延迟都不可接受
知识库内容高度结构化：表格、数据库类内容应用 Text-to-SQL 而非 RAG
问题模板固定、变化少：预生成答案 + 语义匹配更合适

3. 成熟技术栈选型

3.1 各层选型与理由

层次	生产推荐	备选	核心选型理由
文档解析	Docling	Unstructured	PDF 表格、多列布局、扫描件处理最准确；IBM 开源，社区活跃
Embedding 模型	BGE-M3（中文/多语言场景）	text-embedding-3-large（纯英文）	BGE-M3 同时支持密集向量、稀疏向量、多粒度检索，一个模型替代三种
向量数据库	Qdrant	Weaviate	Rust 实现性能最优；原生支持混合检索；Apache 2.0 无商业限制
关键词搜索	Elasticsearch 8.x	OpenSearch	BM25 生态最成熟；中文需加 IK 分析器插件；运维工具链完善
Reranker	BGE-Reranker-v2-m3	Cohere Rerank API	可本地部署，无调用费用；中英文效果均达到商业水准
LLM	Claude Opus 4.6（复杂推理）/ Sonnet 4.6（生成）	—	Tool Use 能力最强；长上下文（200k）稳定；中文理解优秀
编排	直接使用 Anthropic SDK	LangGraph	最少依赖，行为最可预测；LangGraph 适合有复杂状态管理需求时
评估	RAGAS	自定义脚本	四大核心指标开箱即用；可对接 CI/CD 做回归测试
缓存	Redis（语义缓存）	内存缓存	生产必备；相似问题复用答案，降低 60-80% 重复查询成本

3.2 关于框架选择的特别说明

不推荐 LangChain 作为生产核心框架：抽象层过深，出现问题难以定位；版本迭代频繁导致升级成本高；隐藏了太多关键行为，生产调试困难。适合原型验证，不适合长期维护的生产系统。

LangGraph 的适用边界：当你的 Agentic 流程有复杂的状态机需求（多个 Agent 协作、有条件分支的工作流）时使用。简单的单 Agent 多轮检索，直接用 Anthropic SDK 的 Tool Use 更清晰。

4. 传统 RAG 生产方案详解

4.1 整体流程与每步的设计考量

用户查询
   │
   ▼
【查询预处理层】
   ├── HyDE 查询扩展（提升召回率 15-30%）
   └── 意图识别（决定是否需要元数据过滤）
   │
   ▼
【并行混合检索层】
   ├── 向量检索（Qdrant）→ Top-20（语义相关）
   └── BM25 检索（Elasticsearch）→ Top-20（关键词精确匹配）
   │
   ▼
【RRF 融合排序】
   └── 综合两路结果，输出 Top-40 候选集
   │
   ▼
【Reranker 精排层】
   └── Cross-Encoder 重新打分，取 Top-5
   │
   ▼
【上下文组装 + 生成】
   └── Claude Sonnet 4.6 生成最终答案

4.2 为什么必须做混合检索，不能只用向量

向量检索擅长语义理解，但有一个致命弱点：对专有名词、产品型号、人名、合同编号等精确字符串不敏感。当用户搜索「合同 KH-2024-0893」时，向量检索可能返回完全无关的其他合同；BM25 则能精确匹配。

反过来，BM25 对同义词、语义变体完全无感——用户说「怎么退货」，文档里写的是「退款流程」，BM25 召回率极低，向量检索则轻松处理。

两者互补，通过 RRF（倒数排名融合）合并结果，是目前最成熟、效果最稳定的生产方案。RRF 不依赖两个系统的分数可比性，只依赖排名，鲁棒性强。

4.3 HyDE 查询扩展的原理与适用边界

原理：用户的原始问题往往很短（5-20 字），而文档片段通常是完整的段落（100-500 字）。直接用问题的向量去匹配文档向量，存在语义空间不对称的问题。HyDE 的做法是：先让 LLM 生成一段「假想的答案文档」，用这段文档的向量去检索，因为向量空间更接近，召回率显著提升。

适用场景：知识密集型查询、专业领域问答、文档较长的知识库。

不适用场景：查询本身就是关键词搜索（如精确编号查询）；知识库内容时效性极高（HyDE 生成的假想文档可能基于 LLM 的旧知识）。

成本控制：HyDE 扩展使用小模型（Haiku），一次调用仅约 $0.0001，可以接受。

4.4 Reranker 是不可跳过的环节

许多团队为了省事跳过 Reranker，直接用向量相似度排序后取 Top-5。这是一个常见的错误。

向量检索使用的是 Bi-Encoder 架构：查询和文档分别独立编码，再计算余弦相似度。这样速度快，但精度有损失。Reranker 使用 Cross-Encoder 架构：将查询和文档拼接后联合编码，能够捕捉更细粒度的交互信息，精排准确率提升 20-40%。

代价是速度慢（不能用于全量检索），因此 Reranker 只对 Hybrid 检索后的 Top-40 候选集做精排，取 Top-5 送入生成阶段。这个「粗排 + 精排」的两阶段设计是工业界的标准做法。

4.5 上下文窗口的使用策略

不要把所有检索到的 chunk 都塞进上下文。LLM 存在「迷失在中间」现象：当上下文超过 4000 tokens 后，中间部分的信息被严重忽视，只有开头和结尾部分得到充分注意。

生产中的上下文组装策略：

控制 chunk 数量：Reranker 精排后取 Top-3 至 Top-5，不超过 5 个
控制单个 chunk 大小：512 tokens 左右，总上下��不超过 4000 tokens
高相关性优先：相关度分数最高的 chunk 放在上下文最前面
来源标注：每个 chunk 标注来源文档和章节，方便 LLM 引用，也方便用户验证

5. Agentic Search 生产方案详解

5.1 核心设计原则

Agentic Search 的本质是给 LLM 一个「搜索」工具，让它自主决定搜什么、搜几次、什么时候停止。设计这个系统时，以下原则至关重要：

原则一：工具定义决定 Agent 行为质量

工具描述写得模糊，Agent 就会做出糟糕的搜索决策。好的工具描述应当告诉 Agent：何时使用这个工具、如何构造有效的查询词、一次调用能期望得到什么类型的结果。

原则二：每轮检索必须有明确的子目标

不好的 Agent 行为：直接用用户的原始问题反复检索，每轮结果雷同，浪费 token。好的 Agent 行为：第一轮检索大背景，第二轮针对第一轮发现的关键点深挖，每轮检索有清晰的子目标。System Prompt 的设计需要引导 Agent 做分解再检索，而非重复检索。

原则三：必须设置硬性终止条件

不设迭代上限的 Agentic Search 在生产中是危险的。当 LLM 在某个问题上陷入循环或无法找到答案时，它可能无限循环检索，导致单次查询耗时数分钟、费用数美元。生产中最大迭代次数设为 3-5 次，覆盖 95% 的场景。

原则四：并行工具调用是降低延迟的关键

Claude 支持在单轮中并行调用多个工具。当 Agent 分解出多个独立子问题时，应当同时发起多个检索，而非串行等待。这能将多跳查询的延迟降低 40-60%。

5.2 查询分解策略

对于复杂问题，在进入 Agentic 循环之前，先做显式的问题分解效果更好：

分解维度：

信息点分解：「比较 A 和 B」→「A 的特征」+「B 的特征」+「比较维度」
时序分解：「分析事件的原因和影响」→「事件背景」+「直接原因」+「后续影响」
实体分解：「张三和李四分别负责什么」→「张三的职责」+「李四的职责」

分解后的子问题可以并行检索，大幅提升效率。分解工作本身用 Haiku 完成（成本极低），主推理用 Opus。

5.3 迭代终止的判断逻辑

Agentic Search 需要 LLM 自己判断「信息是否足够」，这个判断的质量直接影响系统表现：

信息足够：已检索到的内容能够完整回答用户问题的所有关键点，继续检索只会带来冗余
信息不足：某个关键子问题还没有答案，或者已有信息之间存在矛盾需要进一步核实
无法找到：多次针对性检索后仍无相关内容，知识库不包含该信息

第三种情况在生产中很常见，System Prompt 必须明确告诉 Agent：当知识库确实不包含相关信息时，直接告知用户，不得编造，不得无限检索。

5.4 与传统 RAG 的降级策略

Agentic Search 超时（建议设置 15s 超时）或达到最大迭代次数但未找到满意答案时，应当降级到传统 RAG：

将用户原始问题直接走混合检索
用已收集到的所有检索结果（即便不完整）组装上下文
在答案中标注「信息可能不完整，建议进一步确认」

用户体验上，一个不完整但诚实的答案好过超时或错误。

6. 知识库构建规范

6.1 文档解析：不能用简单 PDF 提取

许多项目在文档解析阶段就埋下了质量隐患，典型问题：

表格被解析为乱序文本：PDF 中的表格按视觉布局提取，行列关系完全错乱
多列布局串行：双栏排版的 PDF，左右两列内容混在一起
页眉页脚污染内容：每个 chunk 都携带「第 X 页，公司名称，机密」等无效信息
扫描件完全无法处理：直接返回空内容

生产推荐方案：Docling（IBM 开源）。它使用 DocLayNet 模型做版面分析，正确识别表格、图片、标题、正文的边界，然后再做内容提取。对表格会保留结构，导出为 Markdown 表格格式，后续分块和检索时能正确处理。

6.2 分块策略：结构优先，不要纯按字数截断

错误做法：按固定 512 字符截断，不考虑语义完整性。这会导致一句话被截成两个 chunk，检索时两个 chunk 都召回不到有效信息。

正确做法：

第一优先级：尊重文档结构。按标题、章节分块，一个完整的小节作为一个 chunk。如果小节内容较短（< 200 tokens），与相邻小节合并；如果极长（> 1000 tokens），再做内部分割。

第二优先级：语义完整性。分割点选在段落边界，不在句子中间截断。中文按「。！？」等标点识别句子边界，不按字符数。

第三优先级：滑动窗口重叠。相邻 chunk 之间保留约 10% 的重叠内容（通常 1-2 句），防止跨 chunk 的关键信息被分割后两边都无法命中。

关键参数（经验值，根据文档类型调整）：

技术文档、操作手册：chunk_size 512 tokens，overlap 64 tokens
法律合同、政策文件：chunk_size 256 tokens（每条款独立），overlap 32 tokens
新闻、报告：chunk_size 768 tokens，overlap 96 tokens

6.3 元数据设计：检索过滤的基础

每个 chunk 附带的元数据决定了系统能否支持精确过滤。生产中必须包含的元数据字段：

字段	用途	示例
`doc_id`	文档唯一标识，用于去重和溯源	`doc_KH_2024_0893`
`source`	显示给用户的来源描述	`《采购合同管理规定》第三章`
`doc_type`	文档类型，用于分类过滤	`contract / policy / manual / faq`
`created_at`	文档创建时间，用于时效性过滤	`2024-06-15`
`updated_at`	最后更新时间，优先返回最新版本	`2025-11-20`
`section`	所在章节标题，提升 BM25 检索精度	`3.2 付款条件`
`version`	文档版本号，支持多版本共存	`v2.1`

不要把所有内容都塞进一个「metadata」字段，Qdrant 和 Elasticsearch 都支持对独立字段建立过滤索引，结构化字段才能高效过滤。

6.4 双路索引写入策略

向量索引（Qdrant）和关键词索引（Elasticsearch）必须保持数据一致性，使用同一个 chunk_id 作为两边的关联键。索引写入顺序建议：

先写 Elasticsearch（失败则回滚，不继续）
再写 Qdrant（失败则同步删除 Elasticsearch 对应记录）
两边都成功后记录索引日志

更新文档时，以 doc_id 为单位原子更新：先删除旧版本的所有 chunk，再写入新版本的所有 chunk，避免新旧混杂。

6.5 知识库更新的三种模式

模式一：全量重建（适合小知识库，< 5万文档）

停机维护窗口内重新索引全部文档
简单可靠，无增量一致性问题
缺点：期间服务不可用

模式二：增量写入 + 软删除（适合中等规模，日更新量 < 1000 文档）

新文档直接追加索引
旧版本文档标记 is_active=false，检索时过滤
定期（每周）清理失效文档的物理存储
缺点：随时间累积，索引膨胀

模式三：蓝绿索引切换（适合大规模，对可用性要求极高）

维护两套索引（蓝/绿），同时只有一套对外服务
新版本在离线索引上构建完成后，原子切换流量
零停机时间，但存储成本翻倍

7. 评估体系

7.1 四个核心指标

评估 RAG 系统必须区分检索质量和生成质量，两者的问题原因和解法完全不同。

检索层指标：

Context Precision（上下文精度）：检索到的内容中，有多少比例真正与回答问题相关。低精度说明 Reranker 过滤效果差，或者检索策略不准确，导致大量无关内容塞入上下文，干扰生成。
Context Recall（上下文召回）：回答问题所需的关键信息，有多少比例被检索到了。低召回说明分块粒度有问题（答案被分散在多个 chunk 之间），或者 Embedding 模型与领域不匹配。

生成层指标：

Faithfulness（忠实度）：生成的答案中，每个声明是否都有检索内容的支撑。低忠实度就是幻觉，说明 LLM 在检索内容不足时自行补充了不实信息。
Answer Relevancy（答案相关性）：生成的答案是否真正回答了用户的问题（而不是答非所问或过度发散）。

7.2 评估集建设（这是最关键、最容易被忽视的工作）

一个 200-500 条的高质量评估集，比任何技术手段都更重要。建设方法：

Step 1：收集真实查询。从系统上线后的日志（或内测期间的记录）中，抽取用户真实提问，按问题类型分层抽样，确保覆盖各类场景。

Step 2：标注标准答案。由领域专家（不是工程师）写出每个问题的标准答案，以及应当被命中的源文档段落。这一步不能省略，也不能用 LLM 替代（LLM 生成的答案本身就是你要评估的目标）。

Step 3：划分子集。分为验证集（日常评估，约 100 条）和测试集（版本发布前最终评估，约 200 条，平时锁定不使用）。

Step 4：纳入 CI/CD。每次修改分块策略、Prompt、Reranker 参数等，自动运行验证集评估，与上一版本对比，指标下降超过 2% 则阻断合并。

7.3 生产监控体系

离线评估集反映的是「历史上的问题」，在线监控反映「当前真实质量」。两者缺一不可。

必须监控的指标：

指标	含义	警告阈值	严重阈值
Faithfulness	自动采样 LLM 评估忠实度	< 0.85	< 0.70
拒答率	回复「未找到相关信息」的比例	> 15%	> 30%
P50 端到端延迟	中位响应时间	> 2s	> 5s
P99 端到端延迟	长尾响应时间	> 8s	> 15s
用户负反馈率	点踩/投诉/重复提问比例	> 5%	> 10%
检索空命中率	检索结果相关度分数全低于阈值的比例	> 10%	> 20%

用户负反馈是最可靠的信号。当用户对同一问题连续提问两次、措辞变化（「换种方式问」），或者明确点踩，这是系统失败最直接的证据，优先级高于任何自动化指标。

7.4 问题定位流程

当指标下降时，按以下顺序排查：

先看检索日志：对失败案例，检查检索到的 Top-5 文档是否相关。若不相关，是检索层问题；若相关，是生成层问题。
检索层问题：依次检查——分块是否把答案截断、Embedding 是否对该领域词汇有效、Reranker 是否正确精排。
生成层问题：依次检查——上下文是否够长（答案是否在其中）、Prompt 是否有歧义、LLM 是否在知识不足时编造。

8. 部署与成本

8.1 服务架构

用户请求
   │
   ▼
API 网关（限流、鉴权）
   │
   ▼
RAG 服务（水平扩展，无状态）
   ├── 查询预处理
   ├── 路由判断
   └── 结果组装
   │
   ├──────────────────────┐
   ▼                      ▼
传统 RAG 路径        Agentic Search 路径
（Sonnet 生成）       （Opus 多轮推理）
   │                      │
   └──────────┬───────────┘
              ▼
       检索基础设施（共用）
       ├── Qdrant（向量检索）
       ├── Elasticsearch（BM25）
       └── Redis（语义缓存）

RAG 服务本身是无状态的，可以水平扩展。检索基础设施（Qdrant、Elasticsearch）是有状态的，需要独立部署和备份。

8.2 规模与配置对照

规模	文档量	并发 QPS	推荐配置	备注
小型	< 50 万 chunks	< 20	单机 16C32G	Qdrant + ES 同机部署，适合内部工具
中型	< 500 万 chunks	< 100	3 台 32C64G 集群	Qdrant + ES 分别集群化，RAG 服务 × 3
大型	> 500 万 chunks	> 100	分布式架构	考虑向量数据库分片，加 CDN 层缓存热点答案

重要提示：以上配置不含 LLM API 调用的费用和延迟，LLM 调用是整个系统延迟和成本的主要来源。

8.3 成本控制策略

策略一：模型按任务分级

不同任务对模型能力的要求差异极大，用小模型处理简单任务是最直接的降本方式：

任务	模型选择	理由
路由分类（简单/复杂）	Haiku 4.5	二分类，Haiku 准确率已足够
HyDE 查询扩展	Haiku 4.5	文本生成，不需要推理
简单问题生成答案	Sonnet 4.6	平衡质量与成本
Agentic 多轮推理	Opus 4.6	复杂推理必须用最强模型

策略二：语义缓存

Redis + 向量相似度实现语义缓存：新问题进来，先检索缓存库，若与历史问题的语义相似度 > 0.95，直接返回缓存答案。企业知识库场景中，重复或相似问题比例通常在 30-50%，语义缓存可显著降低成本。

策略三：Agentic Search 的 token 预算

对每次 Agentic Search 设置最大 token 预算（建议 20k tokens）。超出预算时，停止继续检索，基于已收集内容生成部分答案并告知用户。防止单次查询失控消耗过多资源。

成本参考（Claude Opus 4.6 定价约 $15/1M 输入 tokens）：

场景	每次查询 token 消耗	每次费用
简单 RAG（Sonnet）	约 2,500 tokens	~$0.005
Agentic 3 轮（Opus）	约 9,000 tokens	~$0.14
Agentic 5 轮（Opus）	约 16,000 tokens	~$0.24

实际成本需结合缓存命中率和简单/复杂问题比例综合计算。

9. 常见生产问题与根本解法

问题一：召回率低，明明有答案却找不到

表现：用户投诉「这个问题文档里明明有」，但系统返回「未找到相关信息」。

根本原因排查顺序：

检查文档解析质量——PDF 表格被解析成了乱序文本，导致答案所在的 chunk 内容不完整
检查分块策略——答案恰好在两个 chunk 的边界，被截断，两半都无法独立命中
检查 Embedding 模型——通用 Embedding 模型对专业术语的语义理解有偏差（如医疗、法律领域）
检查 BM25 同义词配置——用户用了文档里没有的同义表达

解法优先级：先修文档解析和分块（成本低，效果显著），再考虑 Embedding 微调（成本高，仅在领域极专业时值得）。

问题二：答案有幻觉，内容与知识库不符

表现：答案听起来合理，但包含知识库中不存在的信息，甚至与知识库内容矛盾。

根本原因：Reranker 筛选后进入上下文的内容与问题相关度仍然偏低，LLM 在无法找到答案时，用自己的参数知识补充了内容。

解法：

提高 Reranker 的相关度阈值——低于阈值的文档直接丢弃，不送入生成阶段，宁可拒答也不要幻觉
在 Prompt 中强制约束引用格式——要求 LLM 对每个声明都标注来源文档，无法标注来源的内容不得出现在答案中
在生成后做 Faithfulness 自动检测——用小模型验证答案中的每个关键声明是否在检索内容中有依据，未通过则返回「信息不足」

问题三：Agentic Search 响应太慢，用户体验差

表现：复杂问题需要 10-20 秒才能返回答案，用户大量流失。

根本原因：多轮 LLM 调用串行执行，每轮至少 2-4 秒，5 轮迭代累计 15-20 秒。

解法：

减少必要轮次：优化 System Prompt，让 Agent 在第一轮就分解出所有子问题，并行发起多路检索，而非逐步发现逐步检索
设置 3 轮上限：大量测试表明，超过 3 轮检索带来的质量提升极其有限，收益递减。3 轮覆盖 90% 以上场景，将 P99 延迟控制在 12s 内
流式返回：Agentic Search 的思考过程和中间步骤可以流式输出给用户，让用户感知到系统在工作，而不是黑屏等待
超时降级：设置 15s 超时，超时后立即切换到传统 RAG，返回部分答案并告知

问题四：知识库更新后，旧答案仍然被返回

表现：文档修订后，系统仍然给出旧版本的答案。

根本原因：向量数据库的更新策略有误——旧版本 chunk 没有被正确删除，或者缓存没有失效。

解法：

更新文档时，以 doc_id 为单位原子操作：先在 Qdrant 和 Elasticsearch 中删除所有属于该 doc_id 的 chunk，再写入新版本的 chunk
清除 Redis 语义缓存中涉及该文档的所有缓存条目（通过 tag 机制实现，更新文档时 invalidate 相关 tag）
建立文档版本日志，每次更新记录版本号，方便追溯

问题五：多语言文档混合场景处理

表现：知识库中中英文文档混合，跨语言检索效果差。

解法：无需将文档按语言分库。BGE-M3 模型的多语言对齐能力已经成熟——中文问题可以直接命中英文文档中的相关段落，反之亦然。

唯一需要注意的是 BM25 部分：中文需要 IK 分析器，英文需要标准分词器，在 Elasticsearch 中可以通过多字段映射（中文字段用 ik_max_word，英文字段用 standard）同时支持两种语言的精确检索。

附录：技术选型速查

向量数据库：Qdrant（推荐自托管）→ docker pull qdrant/qdrant

Embedding 模型：BAAI/bge-m3（Hugging Face，可本地运行）

Reranker：BAAI/bge-reranker-v2-m3（Hugging Face，可本地运行）

文档解析：pip install docling（支持 PDF/Word/PPT/HTML）

评估框架：pip install ragas（需要 OpenAI 或 Anthropic key 作为评估 LLM）

中文分词：Elasticsearch + IK 分析器（analysis-ik 插件，需单独安装）

文档维护：工程团队 | 版本：2026.03 | 适用范围：面向生产落地，不含实验性方案