为什么你的 RAG 系统在生产环境中失效？如何构建持续评估体系

想象一下这个场景：你的工程团队围绕公司的内部政策文档构建了一个检索增强生成（RAG）聊天机器人。在最初的演示中，一位利益相关者问道：“我们有多少天育儿假？”机器人回答正确，并准确引用了福利 PDF 的页码。另一位询问差旅费限制，回答同样正确。在十个问题和十个完美的回答之后，团队欢呼雀跃，并直接将系统推向了生产环境。

三个月后，一名员工询问其合同工身份是否有资格获得健康津贴。机器人给出了一个自信的“是”，而这个答案是根据去年已被废弃的旧政策文档生成的。该员工提交了报销申请，结果被 HR 拒绝。

开发团队中没有人能准确指出该系统是从什么时候开始产生这些错误回答的。系统没有抛出任何异常，延迟没有飙升，数据库也没有报错。RAG 管道默默地失效了，因为没有评估机制来持续测量其准确性。团队将 Demo 演示当成了评估，而 Demo 是 RAG 系统最不容易失败的一种测试。

生产环境中 RAG 的静默失效模式

传统的软件架构在失效时会发出警报。损坏的数据库查询会抛出 500 错误；糟糕的部署会触发健康检查失败；失败的单元测试会让构建流水线变红。然而，RAG 的退化不会触发任何这些机制。即使你更换了嵌入模型、调整了分块大小或更新了文档索引，系统依然会返回流畅、格式良好且带有自信引用的回答。这些回答是否真正基于当前事实，在标准的应用程序监控中是完全不可见的。

这并非个案。在 CAIN 2024 的一项针对三个 RAG 案例研究（涵盖研究、教育和生物医学领域）的经验报告中，研究人员归纳了七个常见的失效点：

1. 内容缺失 (Missing Content)：源语料库中不存在所需的信息。
2. 未能检索到高排名文档 (Missed Top-Ranked Documents)：信息存在，但检索步骤未能将其排在 Top-k 结果中。
3. 整合流失 (Lost in Consolidation)：信息已被检索到，但由于模型上下文窗口的限制，在上下文组装过程中丢失。
4. 未成功提取 (Failure to Extract)：信息存在于上下文中，但 LLM 未能将其提取出来。
5. 格式错误 (Wrong Format)：模型忽略了格式化指令。
6. 粒度不当 (Wrong Specificity)：回答过于笼统或过于详细。
7. 回答不完整 (Incomplete Answers)：模型仅回答了多跳查询的一部分。

该研究的作者得出了一个明确的结论：只有在系统运行期间，对 RAG 系统的验证才是可行的；RAG 系统的鲁棒性是逐步演进的，而不是在开始时就能完全设计好的。你无法在发布前完全验证 RAG 系统。因此，评估套件是一个核心的架构要求。

“无幻觉”检索的幻觉

许多团队之所以跳过评估，是因为他们认为检索天然地解决了幻觉问题。最强烈的反例来自对准确性要求极高的法律科技领域。法律研究软件供应商曾宣传其 RAG 产品可以“消除”或“避免”幻觉，甚至保证提供“无幻觉”的引用。

然而，当斯坦福大学的 RegLab 对这些工具进行首次预注册实证评估时，他们发现来自主流供应商的旗舰产品有 17% 到 33% 的概率产生幻觉。虽然与裸模型相比，检索减少了幻觉，但仍有六分之一到三分之一的回答包含虚假信息。如果由庞大资源构建、基于高度整理的法律数据库的专业级系统都会出现这种错误率，那么你的企业内部聊天机器人显然更加脆弱。

解构 RAG 评估：检索与生成

要构建有效的 RAG 评估流水线 (RAG evaluation pipeline)，首先必须理解 RAG 系统可能在两个独立的地方失效。将它们混为一谈会使优化工作失去方向。

1. 检索失效 (Retrieval Failures)：传递给 LLM 的文本块不包含正确答案。这可能是因为文档未被索引、嵌入模型未能捕获语义，或者检索查询构建不当。提示词工程无法解决这个问题；你必须更改分块策略、嵌入模型或检索算法（例如引入混合检索或重排）。
2. 生成失效 (Generation Failures)：正确的答案存在于检索到的上下文中，但 LLM 忽略了它、与其相矛盾，或者凭空捏造了外部信息。调整向量数据库检索参数无法解决这个问题；你必须修改系统提示词、更换生成模型或引入输出护栏。

RAGAS (Retrieval Augmented Generation Assessment) 框架通过为这两个步骤引入不同的指标，实现了这种评估维度的分离：

构建评估套件的逐步实施指南

构建一个最小可行评估套件并不需要专门的研究团队。你可以通过三个核心组件来实现：黄金数据集、LLM 裁判评分脚本以及回归网关。

第一步：定义黄金数据集 (Golden Dataset)

整理一个包含 50 到 100 个真实问题的测试集。不要完全依靠 LLM 来生成这些问题；应从用户搜索日志、支持工单和业务专家处收集。每个条目应遵循以下结构：

[
  {
    "id": "policy_031",
    "question": "Does the health stipend apply to contractors?",
    "expected_answer": "No - eligibility requires full-time employment status.",
    "must_cite": ["benefits-eligibility-2026.pdf"],
    "trap": "superseded 2024 policy still in corpus says yes"
  }
]

其中的 trap（陷阱）字段至关重要。它专门测试系统处理边缘情况的能力，例如过期文档、否定约束，以及正确回答应为“我不知道”的查询。

第二步：实现 LLM 作为裁判 (LLM-as-a-judge) 的脚本

为了在大规模运行中评估生成质量，你可以使用 LLM 作为裁判。虽然人工评估是金标准，但它的速度太慢，无法融入持续集成流程。通过使用像 n1n.ai 这样高性能的 LLM API 聚合平台，你可以轻松调用 Claude 3.5 Sonnet 或 DeepSeek-V3 等先进模型来对你的管道输出进行打分。

以下是一个使用 Python 实现的完整示例，演示如何通过 n1n.ai API 接口，利用 Claude 3.5 Sonnet 评估生成回答相对于检索上下文的忠实度（Faithfulness）：

import json
import requests

def evaluate_faithfulness(question, context, generated_answer, api_key):
    """
    使用 Claude 3.5 Sonnet 通过 n1n.ai 接口评估 RAG 回答的忠实度。
    """
    url = "https://api.n1n.ai/v1/chat/completions"
    headers = {
        "Authorization": f"Bearer {api_key}",
        "Content-Type": "application/json"
    }

    prompt = f"""
    你是一名专业的 AI 评估专家。你的任务是根据提供的上下文判断生成的回答是否忠实于原文。

    上下文：
    {context}

    问题：
    {question}

    生成的回答：
    {generated_answer}

    逐句分析生成的回答。确定每个陈述是否直接由上下文支持。
    最后以 JSON 格式输出，包含两个键：
    1. "reasoning": 你的分析过程的简要说明。
    2. "score": 一个介于 0.0（完全幻觉）和 1.0（完全忠实于上下文）之间的浮点数。
    """

    payload = {
        "model": "anthropic/claude-3.5-sonnet",
        "messages": [
            {"role": "system", "content": "你是一个客观的 RAG 系统评估器，仅根据提供的上下文进行评估。"},
            {"role": "user", "content": prompt}
        ],
        "temperature": 0.0,
        "response_format": {"type": "json_object"}
    }

    response = requests.post(url, headers=headers, json=payload)
    response.raise_for_status()
    result = response.json()

    return json.loads(result["choices"][0]["message"]["content"])

# 示例用法：
mock_context = "第 4.2 节：全职员工有资格获得每年 500 美元的健康津贴。合同工和兼职员工不享受此福利。"
mock_question = "合同工是否适用健康津贴？"
mock_answer = "是的，根据更新后的指南，合同工可以申请健康津贴。"

# 从你的 n1n.ai 控制台获取 API 密钥
API_KEY = "your_n1n_api_key_here"

eval_result = evaluate_faithfulness(mock_question, mock_context, mock_answer, API_KEY)
print(json.dumps(eval_result, indent=2, ensure_ascii=False))

第三步：设置回归网关 (Regression Gate)

将此评估脚本作为部署流水线中的强制步骤运行。如果对代码的修改（如修改提示词或采用新的分块策略）导致评估分数降至预设阈值以下（例如 Faithfulness < 0.90），则必须使构建失败。这可以防止性能退化的代码进入生产环境。

评估裁判模型：LLM 裁判的权衡与选择

在使用 LLM 作为裁判时，必须考虑模型评估中存在的系统性偏见。根据 MT-Bench 的研究，这些偏见包括：

• 冗长偏见 (Verbosity Bias)：模型倾向于给更长、更详细的回答打高分，即使其中包含无关信息。
• 自我提升偏见 (Self-Enhancement Bias)：某些模型倾向于给自家模型生成的回答打出比竞争模型更高的分数。
• 位置偏见 (Position Bias)：向评估器展示选项的顺序会影响最终的评分结果。

为了缓解这些问题，你可以利用 n1n.ai 灵活地将评估任务分发给不同的模型（例如，使用 DeepSeek-V3 进行高性价比的大批量评估，使用 Claude 3.5 Sonnet 处理复杂的推理任务），并定期与人工标注的样本进行相关性校验。

RAG 评估的专业建议

• 隔离向量数据库更新：在更新向量数据库索引时，应先对测试索引运行评估流水线。这可以确保文档格式或分块解析的变化不会在无形中降低检索的召回率。
• 在测量准确性的同时监控延迟：如果一个高准确率的 RAG 管道需要 15 秒才能返回结果，那么它在实际应用中是无法使用的。在评估运行期间，应分别测量检索延迟和 LLM 生成延迟。
• 记录“无法回答”的触发情况：确保你的黄金数据集中包含语料库无法回答的问题。评估应验证系统是否返回了预设的退路消息（例如“在提供的文档中找不到此信息”），而不是尝试胡乱合成一个答案。

总结

一个成功的 RAG 系统部署必须超越最初的 Demo 阶段。通过建立结构化的评估流水线，你可以在退化影响到用户之前及时发现问题，并系统地提升系统的检索与生成质量。

Get a free API key at n1n.ai