将检索增强生成 (RAG) 从演示 (demo) 转向生产级服务时，团队会面临一系列决定，这些决定将区分出一个是有用的助手，还是一个充满噪音的助手。五个设计选择——分块 (chunking)、嵌入模型 (embedding model)、向量数据库 (vector store)、混合搜索 (hybrid search) 和评估 (evaluation)——控制着真实用户所体验到的精确度、召回率和延迟。

为什么从原型到生产的跨越至关重要

大多数教程只需几十行代码就能运行起一个 RAG 流水线，但它们往往止步于应对实时流量所需的工程严谨性。

1. 分块策略 —— 第一道质量关卡

分块大小 (Chunk size) 最为关键。过大的分块会用无关文本淹没有效信号；而过小的分块则会剥离模型生成连贯答案所需的上下文。固定大小的切分方式则忽略了源材料的自然结构。

实践经验法则

  • 基于逻辑边界进行切分：文档中的标题、文章中的段落分隔符、代码中的函数定义。
  • 保持分块足够小以实现精确检索，但同时保留较大的父级章节供 LLM 的生成步骤使用。这种“父子”模式 (parent-child pattern) 让检索器能够定位到精准的片段，同时让生成器拥有足够的上下文来保持事实准确性。

2. 嵌入模型 —— 如何判断相似度

嵌入模型将文本转换为向量，以便相似度搜索引擎进行比较。像 OpenAI 的 text-embedding-3-large 这样强大的通用模型可以为大多数领域提供坚实的基础。如果语料库属于高度专业化的领域——如法律意见书、医疗记录、技术规范——请测试特定领域的模型，但前提是必须先在您自己的数据上测量出实实在在的提升。

何时切换

  • 只有当您看到对应用至关重要的相关性评分（例如更高的上下文精确度）出现可衡量的增长时，才进行切换。

3. 向量数据库 —— 扩展存储

选择一个符合您现有基础设施和预期向量数量的向量数据库。

  • pgvector 运行在 PostgreSQL 内部，可以轻松处理约一百万个向量。对于已经在使用关系型数据库并需要低维护解决方案的团队来说，它是理想之选。
  • Qdrant 在 100 万至 1 亿向量的范围内表现出色，能为大规模语料库提供更高的吞吐量和更低的延迟。
  • Pinecone 提供全托管的云服务，消除了自托管的运维负担。

4. 混合搜索与重排序 —— 平衡语义与精确度

纯向量搜索擅长语义相似度，但可能会遗漏用户期望的精确关键词匹配。混合搜索在向量索引之上叠加了传统的 BM25 关键词索引，然后融合这两个结果列表。倒数排名融合 (Reciprocal Rank Fusion, RRF) 根据每个候选结果在两个列表中的排名为其分配分数并进行合并，从而提升在任一列表中排名靠前的项的权重。

重排序 (Reranking) 则增加了最后一层精确度过滤。在混合检索之后，将前 N 个（通常为 50 个）候选结果输入交叉编码器 (cross-encoder) —— 这是一种能够对“查询-文档”对进行联合评分的模型。交叉编码器的评分将取代原始的相似度数值，让您在将片段传递给 LLM 之前，能够挑选出最相关的分块。这一额外步骤通常能显著提升回答质量，尤其是在处理长篇或嘈杂的语料库时。

5. 评估与拒绝回答 —— 衡量关键指标

无法衡量，就无法改进。RAGAS 框架提出了四个指标，共同捕捉 RAG 流水线的健康状况：

  • Context Precision (上下文精确度) —— 检索到的分块中实际包含答案的比例。
  • Context Recall (上下文召回率) —— 所有相关分块中被检索到的比例。
  • Faithfulness (忠实度) —— 生成的答案在多大程度上保持在检索到的上下文中，从而避免幻觉。
  • Answer Relevance (回答相关性) —— 最终答案满足原始查询的程度。

请在能够反映生产流量的滚动测试集上追踪这些指标。

最后一个经常被忽视的保障措施是拒绝回答 (abstention)。与其强迫模型在置信度较低时给出答案，不如为忠实度或相关性评分设置一个阈值，一旦低于该阈值就触发“我不知道”的响应。用户宁愿面对明确的不确定性，也不愿面对一个自信但错误的答案，而且这种回退机制可以降低下游的客服成本。

将这五个领域中的每一个都视为决策点，而非“一劳永逸”的配置，您就能将 RAG 从一个华而不实的演示转变为一个可靠的生产级服务。其回报是：一个响应迅速、切中要点，并且知道何时保持沉默的系统。