高级检索与智能体结合
基础 RAG 在文档多、问题复杂时容易露馅：关键词对不上、排在最前的不是最相关的、答案没有出处。本章介绍混合检索、重排、引文溯源等进阶手段，以及把检索交给模型自主调度的 Agentic RAG。
混合检索
向量检索擅长语义相似但抓不住精确词，关键词检索（BM25）擅长精确匹配但不懂同义改写。混合检索把两者结果合并去重，取并集后再排序，兼顾召回与精确：
docs = merge(bm25_search(q), vector_search(q)) # 两种召回取并集
重排 Rerank
召回阶段用轻量方式多取候选（如 top50），再用更强的交叉编码器模型逐条精排，只把 top3~5 送进提示词。重排是性价比极高的一步，能显著提升答案质量：
candidates = retrieve(query, top_k=50) # 粗召回
top = reranker.rerank(query, candidates)[:5] # 精排后取前 5
引文溯源
让答案可核查：检索时给每块附文档 ID 与原文位置，要求模型回答时标注来源编号，产品界面即可"点引用跳原文"。
{"chunk_id": "c_1024", "doc": "员工手册.pdf", "page": 12, "content": "年假按工龄计算……"}
查询改写
用户问题常带口语、指代或太短，直接检索效果差。先让模型把问题改写成适合检索的独立查询（如补全指代、拆出关键词）再检索，可明显提升命中率。
索引策略
按业务拆多个集合（如"产品文档""售后FAQ"分开建索引），命中后按文档类型决定拼接模板；对经常更新的数据做增量索引，避免全量重建。索引设计的本质是"给检索划好地盘"。
RAG 与长上下文：2025 年的取舍
2025 年起超长上下文模型（百万级 token）普及，有人主张"把整本手册直接塞进窗口，不用 RAG"。现实权衡是：
| 方案 | 优势 | 代价 |
|---|---|---|
| 长上下文硬塞 | 简单、无检索丢失 | token 成本高、中间内容注意力易衰减 |
| RAG 检索 | 省 token、可定位出处 | 检索质量影响结果，需工程维护 |
主流实践是二者结合：先检索出关键段落，必要时把相关原文整段放入长窗口，既控制成本又保留细节。具体取舍随模型能力变化，以官方文档与实际评测为准。
Agentic RAG：检索工具化
Agentic RAG 把"检索"本身变成模型可调用的工具，模型按需决定搜什么、搜几次、何时停止，而不是固定一次检索：
- 用户问"报销流程"→ 模型先搜主文档；
- 发现需要子公司细则 → 改写查询再搜子库（多跳检索）；
- 两次结果仍不足 → 主动告知用户"资料有限"而不是硬编。
# 检索工具片段：一次封装，模型可反复调用
def search_kb(query: str, kb: str = "default") -> str:
top = retrieve(query, kb, top_k=5)
return "\n".join(f"[{c.doc}] {c.content}" for c in top)
小结
高级 RAG 围绕"召回更准、答案可查、检索自主"展开：混合检索与重排提精度，引文溯源提可信度，查询改写与索引策略应对真实语料。Agentic RAG 则把检索权交给模型，是检索与智能体融合的进阶方向。