在将检索增强生成 (RAG) 流水线从 Jupyter notebook 迁移到在线服务的四个月后，作者总结了五个具体的选择，这些选择将一个演示用的 Demo 转变为一个用户真正可以依赖的系统。这种差异体现在数据上：对文本切分方式的一个简单更改，将检索命中率从 61% 提升到了 83%，而一个包含 200 个真实查询的规模适中的评估集，现在可以在问题影响到客户之前捕捉到大多数回归问题。

为什么这很重要

RAG Demo 看起来令人印象深刻——它们能在几秒钟内检索出段落并生成看似合理的答案。但在生产环境中，同样的方法往往会返回过时的事实、遗漏错误代码或产生破碎的句子，从而削弱用户信任。瓶颈很少在于语言模型；而在于内容摄取、索引和提供服务的方式。优化流水线可能意味着产品是创造价值还是成为负担。

1. 停止使用固定大小的分块

许多原型会将每个文档切分为 512 个 token 的块。这对于短文本有效，但会使技术手册、支持线程和代码片段变得支离破碎。句子会被切断，标题会消失，检索引擎无法匹配用户预期的上下文。

转向结构感知分块（在标题、对话边界或代码块处进行切分）以保留语义单元。在作者的系统中，仅此一项就将找到相关段落的查询比例从 61% 提高到了 83%。这种改进源于数据格式的变化，而底层模型保持不变。

2. 使用混合搜索

纯向量搜索（基于嵌入的相似度）擅长寻找意思相同的段落，但在处理错误代码、版本号或专有名词等精确标识符时会遇到困难。寻找诸如“ERR-XXXX”错误代码的用户可能会得到一个语义相似但完全不包含该代码的段落。

混合搜索将密集向量索引与传统的 BM25 索引（基于词频）相结合。通过对这两个分数进行加权，系统可以检索出既在语义上接近又包含用户输入的精确术语的项目。对于生产环境，混合搜索是基准要求，而不是锦上添花的附加功能。

3. 处理过时数据

过时的价格表、政策文档或固件发布说明会迅速破坏可信度。以下三个实际步骤可以保持索引的新鲜度：

  • 为每个文档添加版本戳或时间戳。
  • 在评分时应用时效性提升 (recency boost)，使较新的项目排名高于旧版本。
  • 运行每晚增量重新索引，以从源系统中提取更改。

这些保障措施可以防止系统提供上季度有效的价格或已被取代的政策。

4. 使用重排序而非升级模型

升级嵌入模型只能带来微小的质量提升，而添加交叉编码器 (cross-encoder) 重排序器则能以更低的成本带来更大的飞跃。

生产流程使用混合搜索获取 20 个廉价候选对象，然后通过重排序器筛选出前五个。这种两阶段方法能以升级完整模型极小部分的成本，实现更大的质量飞跃。

5. 构建真实的评估集

无法衡量就无法改进。作者组建了一个包含 200 个真实用户查询的测试套件，每个查询都配有一个专家编写的答案。每次代码更改都会针对该套件运行；任何回归问题都会在部署前被发现。

当用户报告答案错误时，立即将该查询添加到评估集中，将现实世界的失败转化为未来的保障。对每个生成的答案进行持续记录，可以为评估循环提供数据，使系统与实际使用保持一致。

生产流水线实践

  • 摄取 (Ingest)：结构感知分块保留标题、代码块和对话轮次。
  • 索引 (Index)：同时存储密集嵌入 (dense embeddings) 和 BM25 词项统计数据。
  • 检索 (Retrieve)：混合搜索返回 20 个候选对象，平衡语义相似度和精确术语匹配。
  • 重排序 (Rerank)：交叉编码器将列表缩小到最有希望的五个段落。
  • 生成 (Generate)：LLM 接收这些顶层分块及其元数据，以构建最终答案。
  • 评估 (Evaluate)：记录每个响应；将失败案例反馈到 200 个查询的测试集中。

风险与权衡

A well-tuned pipeline reduces hallucinations, improves answer relevance, and cuts the cost of over-provisioned models. The upside is higher user satisfaction and lower support overhead. Ignoring these steps yields a brittle service that erodes brand trust and forces costly firefighting.

What to watch next

As open-source embeddings and vector databases mature, the line between “dense” and “sparse” retrieval will blur, but the principle of combining semantic and exact matching remains.

Takeaway: In a RAG system the language model is rarely the choke point. The real work lies in how you slice, index, and surface the underlying content. Getting those decisions right turns a flashy demo into a dependable product.