检索增强生成已成为企业 AI 应用的默认架构。随便问一家用 LLM 做开发的公司，他们多半正在构建一套 RAG 系统。
但这里有个令人不适的事实：大多数在演示中可用的 RAG 系统在生产中都会失败。
演示是从一个精心整理的测试集中检索出 3 篇相关文档；生产则是从 1000 万篇嘈杂文档中检索出 3 篇不相关的文档。模型产生幻觉。用户失去信任。项目失败。
我审计过数十套生产级 RAG 系统。其失败模式高度一致——也高度可修复。
根本性的权衡
每一套 RAG 系统都处在精确率与召回率之间的某一点上：
高精确率：检索到的文档高度相关，但你可能漏掉一些好的。 高召回率：你能囊括大多数相关文档，但也会夹带一些不相关的。
LLM 能在一定程度上过滤掉不相关的上下文——但代价是延迟与准确率。恰当的平衡取决于你的用例：
- 客户支持：偏向精确率。错误答案会摧毁信任。
- 法律取证：偏向召回率。漏掉一篇相关文档是不可接受的。
- 通用问答：两者兼顾。用户能原谅偶尔的不精确。
分块策略
你如何把文档切分成块，对检索质量影响巨大。核心张力在于：
- 更小的块（100—256 个 token）能更精确地匹配查询，但会丢失周边上下文。
- 更大的块（1024+ 个 token）能保留上下文，但会稀释嵌入中的相关性。
递归分块
最稳健的通用方法。先用高层分隔符（段落、章节）切分，若块仍然过大则递归地继续切分。研究表明，以 100 个 token 为基础大小的递归式按 token 分块，始终优于其他方案。
语义分块
按语义而非结构切分。分析句子相似度，并在话题发生转移处生成块边界。它保留了语义，但需要额外的嵌入计算。
结构感知方法
对于结构化文档（带有清晰标题的 Markdown、HTML、PDF），使用结构感知的切分器。这往往是你能做出的单项最大改进——标题提供了天然的语义边界。
何时不该分块
那些篇幅短小、聚焦、能直接回答用户问题的文档，也许根本不需要分块。对这类文档做分块反而会损害检索效果。
嵌入选型
你的嵌入模型把文本映射为向量。这一映射的质量决定了检索质量。
通用选项
- OpenAI text-embedding-3-large：性能强劲，依赖云端
- Cohere embed-v3：多语言能力出色，质量具竞争力
- BGE-large-en-v1.5：开源、可自托管、质量出色
领域专属微调
对于专业化领域——法律、医疗、技术——在领域数据上微调嵌入能显著提升检索效果。即便只有 10,000 个领域专属样本，也能切实改善性能。
多语言考量
如果你的文档跨越多种语言，你就需要多语言嵌入。Cohere 的多语言嵌入或 BGE-M3 等选项能很好地胜任。
检索策略
仅靠向量检索还不够
语义检索很强大，但也有盲点。它可能漏掉姓名、代码与罕见术语的精确匹配。混合检索——把向量相似度与 BM25 关键词匹配结合起来——既能捕捉语义相关性，又能捕捉精确匹配。
重排序
初始检索快但不够精确。重排序模型（Cohere Rerank、ColBERT）会取出 top-k 结果并按相关性重新排序。这在计算上代价高昂，但能显著提升精确率。
元数据过滤
在语义检索之前，先用元数据缩小检索范围。如果你知道用户问的是 2024 年的合同，就先过滤出 2024 年的合同。这能提升精确率并减少计算量。
生产架构
缓存
缓存高频查询。如果有 100 个用户都在问休假政策，那就只检索一次。缓存失效策略很重要——要在时效性与成本之间取得平衡。
异步处理
对于非实时应用，异步处理检索。把查询入队、批量处理，再通过回调返回结果。
监控
监控一切：
- 按分位数（p50、p95、p99）的查询延迟
- 检索相关性（若你有反馈信号）
- 单次查询的 token 消耗
- 缓存命中率
- 错误率
没有监控，你就无法优化。
优雅降级
检索失败时会发生什么？LLM API 超时时呢？设计好兜底行为——缓存的响应、人工升级、透明的错误提示。
常见的失败模式
过度检索
检索过多的块会把上下文窗口塞满勉强相关的信息，从而稀释了真正有用的内容。先从较少的块（3—5 个）起步，仅在需要时才增加。
糟糕的查询预处理
用户查询往往含糊、拼写有误，或带有口语化。在检索之前先预处理查询——展开缩写、纠正拼写、改写为陈述句。
忽视文档质量
RAG 检索的，正是你放进去的东西。如果你的文档语料满是过时、自相矛盾或写得糟糕的内容，你的 RAG 系统就会信誓旦旦地去引用它。文档筛选往往比检索优化更重要。
一刀切
不同类型的查询受益于不同的策略。事实性查找需要精确率，探索性问题需要广度。可考虑把查询路由到不同的检索配置。
通往生产之路
第 1 步：构建评估数据集
在优化之前，先弄清楚“好”是什么样子。构建一个包含 100+ 组问答对、附带人工核验正确答案的数据集。每一次改动都对照这个数据集运行。
第 2 步：建立基线指标
度量当前性能：精确率、召回率、延迟、成本。你无法改进你不度量的东西。
第 3 步：系统化地迭代
一次只改动一件事。度量影响。保留有效的，舍弃无效的。抵制一次性改动一切的诱惑。
第 4 步：在生产中监控
生产数据不同于评估数据。持续监控检索质量。构建反馈回路以识别失败案例。
第 5 步：持续改进
RAG 系统会随文档语料的演变而退化。安排定期重建索引与重新评估。
归根结底
RAG 并非一个已被解决的问题。要构建在生产规模下可靠运行的 RAG 系统，需要在分块、嵌入、检索与监控各环节做细致的工程。
好消息是：这些技术已被充分理解。难的是系统化地把它们落地，而不是寄望于演示能自行扩展到生产。
