HHUAN Lab技术教程 / 项目实践 / 阅读笔记
返回文章列表
8 分钟阅读技术教程知识笔记卡

生产级 RAG 不只看召回：评估、重排与引用闭环

整理 RAG 从能答到可信的工程路径：用评估集定位问题，用重排改善上下文，用引用闭环降低幻觉风险。

RAGEvaluationLangSmithLlamaIndexPinecone

RAG 项目最常见的错觉是：向量库能召回内容，模型能生成答案，系统就已经“可用了”。但真实生产环境里，问题通常不是“有没有答案”，而是答案是否来自正确文档、是否引用可核对来源、是否在上下文不足时保持克制。

本文基于 LangSmith 的 RAG 评估教程、LlamaIndex 的评估文档、Pinecone 的重排说明，以及 OpenAI 工具与结构化输出文档，整理一个生产级 RAG 的检查框架。[rag-001][rag-002][rag-003][rag-004][rag-005]

RAG 的质量问题要拆开看

一个 RAG 回答失败，可能来自不同层：

  • 检索失败：正确文档没有进入候选集。
  • 排序失败：正确文档在候选集里，但排在太后面。
  • 压缩失败：上下文太长，关键段落被截断或稀释。
  • 生成失败：模型忽略证据、过度推断或没有承认不知道。
  • 引用失败：回答看似正确，但用户无法回到来源核对。

LangSmith 的 RAG 评估教程把 RAG 应用放在数据集、运行结果和评估指标的框架里处理，这提醒我们不要只看单次主观体验，而要用测试集持续观察系统行为。[rag-001] LlamaIndex 的评估文档也把评估作为 RAG 系统的重要模块，覆盖检索、响应和数据相关的评估方向。[rag-002]

生产级 RAG 的目标不是让回答更长，而是让回答更可追踪、更可比较、更容易被发现问题。

建一个最小评估集

评估集不需要一开始很大，但要覆盖真实问题类型。可以从下面四类开始：

  1. 直接事实题：答案明确存在于某篇文档。
  2. 跨文档综合题：需要组合两到三篇文档。
  3. 边界题：文档里没有答案，系统应该说不知道。
  4. 相似干扰题：多个文档很像，只有一个来源真正相关。

评估数据可以先用表格或 JSON 管理：

[
  {
    "question": "当前博客的 MDX 渲染流程是什么？",
    "expected_sources": ["mdx-rendering-stack-rehype-remark"],
    "answer_policy": "必须引用渲染管线文章，不允许编造部署细节"
  },
  {
    "question": "有没有文章解释数据库迁移命令？",
    "expected_sources": [],
    "answer_policy": "如果知识库没有证据，应说明未找到"
  }
]

这个结构只是概念示例。关键是把问题、期望来源和回答约束写下来。之后每次改 chunk、embedding、topK、重排或提示词，都能用同一批问题做回归。

重排解决的是“候选质量”问题

向量检索擅长从大规模文档里找相似内容，但相似不等于最适合回答。Pinecone 的 rerank 文档说明了在初始搜索结果后使用重排模型重新排序结果的做法，目标是把更相关的结果推到前面。[rag-003]

工程上可以把检索拆成两段：

用户问题
  -> 粗召回：向量搜索或混合搜索，取 top 20
  -> 重排：用 reranker 对候选段落重新排序
  -> 上下文选择：取 top 4 到 top 8
  -> 生成回答：要求引用来源并说明不确定性

这样做的收益是：召回阶段追求覆盖，重排阶段追求精确。代价是多一次模型或服务调用，延迟和成本会增加。因此重排不应该盲目全量开启，可以优先用于长文档、相似文档很多、错误引用代价高的场景。

引用闭环要进入输出协议

很多 RAG 系统会在提示词里写“请引用来源”，但没有把引用变成结构化输出。OpenAI 的结构化输出文档说明了让模型按 JSON Schema 生成结果的能力，适合把答案、引用、置信说明拆成固定字段。[rag-005]

一个 RAG 输出可以设计成：

{
  "answer": "正文回答",
  "citations": [
    {
      "source_id": "mdx-rendering-stack-rehype-remark",
      "quote_summary": "用于支持回答的段落摘要",
      "confidence": "high"
    }
  ],
  "missing_evidence": []
}

这不是说所有前端都要展示 JSON，而是后端应该先拿到结构化结果，再渲染成用户可读的答案。这样可以单独检查引用是否为空、来源是否存在、回答是否在无证据时仍然强答。

一个可运行的评估流程

生产级 RAG 可以按以下节奏迭代：

  1. 固定评估集：从真实用户问题里挑 30 到 100 个代表性问题。
  2. 记录检索结果：保存每个问题召回了哪些 chunk、排序如何。
  3. 评估回答质量：检查是否回答问题、是否使用正确来源、是否过度推断。
  4. 比较变更：每次只改一个变量，例如 chunk size、topK、reranker 或提示词。
  5. 观察失败样本：不要只看平均分，要看最差案例。
  6. 上线后抽样：把用户真实问题继续回流到评估集。

LangSmith 和 LlamaIndex 的评估资料都强调了用数据集和指标观察 RAG 行为，而不是只靠人工随手试问。[rag-001][rag-002] OpenAI 的工具文档则提醒开发者可以把检索、文件搜索等能力纳入工具体系，让模型围绕外部知识执行回答流程。[rag-004]

实践建议

如果你正在维护一个个人博客知识库，可以从小处开始：

  • 先给每篇文章生成稳定的 source_id。
  • 每个 chunk 保存文章标题、slug、heading 和更新时间。
  • 回答必须返回引用列表，没有引用时前端显示“未找到足够证据”。
  • 对热门问题维护一个轻量评估集。
  • 只有在相似文章多、误召回明显时再加 reranker。

综合这些来源可以推断：RAG 的可靠性来自“检索、排序、生成、引用、评估”的闭环，而不是某一个模型或向量库单点能力。这是工程综合判断，具体实现仍要根据数据规模、延迟预算和错误成本取舍。

参考资料

  1. [rag-001] LangChain Docs, “Evaluate a RAG application”, https://docs.langchain.com/langsmith/evaluate-rag-tutorial
  2. [rag-002] LlamaIndex Docs, “Evaluating”, https://docs.llamaindex.ai/en/stable/module_guides/evaluating/
  3. [rag-003] Pinecone Docs, “Rerank results”, https://docs.pinecone.io/guides/search/rerank-results
  4. [rag-004] OpenAI Developers, “Tools”, https://developers.openai.com/api/docs/guides/tools
  5. [rag-005] OpenAI Developers, “Structured Outputs”, https://developers.openai.com/api/docs/guides/structured-outputs