RAG系统评估实战：RAGAS+LangSmith量化提升回答质量

你的RAG系统真的答对了吗？先别急着拍胸脯。我在接手某电商知识库的RAG项目时，产品经理拿着几个用户反馈说"回答质量不稳定，但不知道差在哪"。当时最头疼的事情不是调模型，而是根本没法量化地告诉团队：到底哪个环节出了问题。后来我把RAGAS和LangSmith组合用的那套流程跑通之后，才真正明白什么叫"用数据说话"。这篇文章就聊聊这个组合方案的核心逻辑、实操步骤和我踩过的坑，给正在做RAG评估的开发者一个能直接参考的落地路径。

1. RAG评估为什么让人头大：先搞懂要解决什么问题

1.1 "看起来靠谱"和"真的可靠"之间的鸿沟

RAG系统上线后，你大概率会遇到这类现象：人工抽测10个问题，9个回答得都不错，于是觉得可以交付了。结果用户在实际使用中总能问出测试集里没覆盖的刁钻问题，回答就开始跑偏。原因很简单，RAG系统的输出质量取决于两个松散耦合的环节：检索端能不能捞回有效上下文，生成端能不能基于上下文给出正确回答。任何一端波动，最终答案质量都会受影响。

更麻烦的是，LLM生成答案天然带有"流畅的幻觉"。它可以把一段完全无关的上下文，编织成一条逻辑通顺、语气笃定的回答。肉眼判断这种错误需要逐条对照引用来源，在少量样本上可以做，但一旦进入批量回归、持续迭代的场景，人工评审根本跟不上节奏。我见过一个团队用人工标注了200条样本，花了两周时间，结果模型一换版本，标注结论全部作废——评估成了纯粹的体力活。

1.2 传统指标为什么在RAG场景失灵

很多从NLP背景过来的同学，第一反应是用ROUGE、BLEU这类指标评估生成质量。我在项目初期也试过，结果非常迷惑：ROUGE-L分数能到0.7以上的答案，实际上可能把答案里最关键的数值给说错了；而一些语义完全正确、但措辞和参考答案差异较大的回答，ROUGE反而给了低分。原因在于这类指标基于词面重叠，对"语义等价"几乎没有感知能力。

那个真实案例让我印象很深：参考回答里写的是"退款将在1-3个工作日内到账"，模型回答写的是"退款通常需要1至3个工作日左右到账"。措辞不同，语义完全一致，但ROUGE分数已经掉了十几个百分点。如果拿这种指标做版本对比，研发团队会被误导得像无头苍蝇一样乱调参数。所以在RAG评估里，必须用理解语义的评估方式，而不是数重复词的多少。

1.3 LLM-as-Judge模式让规模化评估成为可能

用大模型评估大模型，这几年在行业内已经成为主流思路。RAGAS正是这一思路在RAG场景下的体系化实现。它把"评估"这件事拆解成一组可独立计算的指标，每个指标都通过LLM对答案、上下文和问题进行推理打分，从不同角度衡量质量。

LLM-as-Judge并非没有争议，但我自己的体会是：它的稳定性虽然和评估模型本身强相关，但只要控制好提示词、选对模型版本、做足抽样次数，给出的分数趋势是足够支撑工程决策的。比起人工逐条标注，它的成本和效率优势是代差级别的。

2. 为什么是RAGAS + LangSmith：方案选型背后的逻辑

2.1 RAGAS解决"评估什么"：一套为RAG量身定做的指标体系

RAGAS（Retrieval-Augmented Generation Assessment）的价值不在于它是一个评估工具，而在于它把RAG系统的评估维度做了专业切分。它不是问"回答好不好"，而是分别问你："检索到的上下文到底相不相关？""生成结果有没有忠实于上下文？""答案本身对用户问题有没有实际帮助？"

这三个问题对应RAG链路的不同环节，让定位问题成为可能。比如，假设某次评测中忠实性得分低，那问题大概率出在生成端——模型没按检索内容作答，或者它过度依赖自身参数记忆产生了幻觉。如果是上下文相关性得分低，说明检索端召回的质量不行，光调生成端的提示词是没用的。

我在实际项目中，就靠这种指标区分功能成功避免过一次无效调优。当时我花了两天时间优化生成提示词，想提升某个类目的回答质量，结果指标纹丝不动。后来仔细看上下文相关性，发现检索器把内部产品编码片段当成主要上下文排到了前面，真正的产品描述被挤到后面。问题在检索链路，不在生成链路。这种定位能力，是传统单一质量分完全给不了的。

2.2 LangSmith解决"怎么跑"：评估工程化的关键底座

RAGAS解决了评估维度的问题，但如果评估只是在自己本地脚本里运行，输出几个数字，那它离真正工程化还差得远。LangSmith在这里补上了另一块拼图：它提供数据集管理、评估运行编排、链路追踪、结果对比和CI集成能力。

LangSmith最强的能力我认为是trace（追踪）。RAG系统每次请求的处理路径：查询改写做了什么、检索器送回了哪些文档、上下文拼装后长什么样、最终生成的答案是什么，这些中间状态在LangSmith里都被完整记录下来。当某个评估样本得分异常时，点开trace就能看到那个异常回答的完整上下文输入，不需要自己在日志里拼凑。

2.3 两者互补：离线指标和在线监控缺一不可

RAGAS偏离线评估，适合在发布新版本、更换模型、调整检索参数等阶段跑批量评测；LangSmith偏工程平台，既能做离线评测编排，也能通过trace对线上真实请求做采样监控。两者组合起来，恰好覆盖了"发布前把关"和"发布后监控"两个阶段。

我在项目里总结出一个组合节奏：在开发阶段，用RAGAS对构造的测试集跑离线评估，对比不同检索参数、不同模型版本的效果；合入主分支或发版前，把评估任务集成到CI流程中，用LangSmith的数据集管理和自动化评估跑回归；上线之后，通过LangSmith的trace功能定期抽检线上请求，把真实用户的失败问题反哺回离线测试集。这个闭环跑起来后，RAG系统的质量不再是玄学，而是一组可以持续观测的数字。

3. RAGAS核心指标深度拆解：理解它才能用好它

3.1 Faithfulness（忠实性）：最核心的幻觉防线

忠实性衡量的是：生成答案中的每个关键陈述，是否都被检索到的上下文支持。它不是判断答案与标准答案的对错，而是判断生成模型有没有"编造"。计算方式通常是把答案拆解成多个独立陈述句，再逐句判断能否从上下文中找到依据。

实操中，我对这个指标有一个切身体会。有一次我们测试一个新的对话型模型，它对某个不支持的功能会主动说"该功能限额为X"，实际上文档里根本没提这个限额。忠实性打分直接给到0.2以下，比另外两个指标低了一大截。这让我们快速发现是模型在凭训练记忆自嗨，而不是在按文档作答，随后就针对性地在提示词里强化"只能依据给定上下文回答"的约束。

使用这个指标时，有一个细节要特别注意：忠实性不仅仅检查内容是否和上下文一致，对于"上下文没有提到但属于常识性回答"的内容，不同评估LLM的判定尺度也会有差异。如果评估结果不稳定，可以检查是否是这类边缘案例引发的分数波动。

3.2 Answer Relevance（答案相关性）：答非所问的照妖镜

答案相关性评估的是：生成答案对原始问题是否是有用的、切题的回应。它主要关注"问A答B"的问题，而不关心答案的事实正确性。想象一下，用户问"如何使用优惠券"，系统给出了一段关于订单取消的说明，哪怕这段说明文字再通顺，在这个问题下也是零分。

实际评估时，这个指标通常会让LLM根据答案反推问题，然后计算原问题与反推问题的语义相似度。我一般在项目里把答案相关性分数和忠实性分数一起看：如果答案相关性低但忠实性高，说明系统答非所问，但至少没有编造，问题在意图理解或检索排序；如果两者都低，那可能整个链路都需要重查。

3.3 Context Relevance（上下文相关性）：检索质量的直接窗口

上下文相关性关注检索回来的上下文整体有多少比例与问题相关。RAG系统的检索结果往往是多个文档片段，其中可能夹杂大量"开篇介绍""免责声明"等无关文字。这个指标就是用来衡量这种噪声的比例——检索结果是否被无关信息稀释了。

我在搭建某个多租户知识库时，发现检索器经常把"租户A的配置说明"混入"租户B的使用问题"的上下文中。上下文相关性分数几乎稳定低于0.4。后来调整了检索器中的过滤条件，在query改写阶段加上租户标识，分数一下就上来了。所以如果你发现这个指标偏低，优先查检索索引的分区、过滤器和向量检索的TopK设置。

3.4 补充指标组合：从单点到全链路

除了上述三个核心指标，RAGAS还提供Context Precision（上下文精确率）、Context Recall（上下文召回率）、Answer Correctness（答案正确性）等更细粒度的指标，以及一套面向端到端RAG链路的综合度量方式。上下文精确率关注相关上下文是否排在前面，这对真实的"先看top结果"的用户体验影响很大。上下文召回率则关注所有应该被检索到的相关上下文是否都回来了，是偏"漏检"的指标。

我在实际评测中会根据评测目标选择组合：如果做常规版本回归，用忠实性、答案相关性、上下文相关性三件套就够；如果做检索链路专项优化，就要切成上下文精确率、上下文召回率；如果团队需要向业务方汇报"准确性"，我会额外引入答案正确性指标，让它和标准答案做事实层面的核对。指标选型没有固定公式，关键是理解每个指标回答什么问题，然后按需组合。

4. 实操：搭建一套可落地的RAG评估流水线

4.1 环境准备：依赖安装与版本选择

先说我用的环境：Python 3.10，评测模型用的是一个通用中英文对话模型（通过OpenAI兼容接口或本地推理均可），嵌入模型用了一个开源的中文向量模型。RAGAS版本建议固定到某个已知稳定版本，避免新版本行为漂移导致的历史结果不可比。

依赖安装通常就一条命令：

bash复制pip install ragas langsmith

如果你的项目里用的是LangChain，还需要安装对应的LangChain生态包。这里提个建议：评估用的LLM和实际RAG生成用的LLM分开配置。评估LLM要选择指令遵循能力强、对中文理解稳定的模型，因为评分的稳定性直接影响评测结论的可靠性。

4.2 构造评测数据集：不用生成大量人工样本也能起步

很多人一想到评测就发怵，觉得得先积累几百条人工标注数据。实际上起步阶段，你只需要准备几十条有代表性的问题就够。关键是覆盖常见问题类型：事实查询、步骤流程、参数配置、异常处理等。参考标准答案可以后期补充，前期先让RAGAS跑起来，把链路打通。

我将测试数据集做成一个列表，每项包含问题、真实回答、检索上下文和标准答案（可选）。下面的示例结构可以直接套用：

python复制eval_dataset = [
    {
        "question": "如何重置用户的登录密码？",
        "answer": "管理员可以在用户管理页面找到目标用户，点击重置密码按钮，系统会生成临时密码并发送至用户邮箱。",
        "contexts": ["管理员可通过用户管理模块重置用户密码。重置后系统将自动生成临时密码并发送至用户注册邮箱。"],
        "ground_truth": "在用户管理页面选择用户，点击重置密码，系统生成临时密码并发送至用户邮箱。"
    },
    {
        "question": "API调用返回429状态码是什么原因？",
        "answer": "429状态码表示请求频率超过限流阈值，建议降低调用频率或联系平台提升限额。",
        "contexts": ["当API请求超过每秒允许的配额时，接口会返回429状态码，表示请求被限流。"],
        "ground_truth": "请求次数超过限流配额，API返回429状态码，需要降低请求频率或申请更高配额。"
    }
]

这两条数据看起来平平无奇，但它在评测中扮演的角色是大树级的基底。后续你采集到线上bad case，持续往这个数据集里补充，它就会变成一个越来越值钱的回归测试资产。

4.3 接入RAGAS离线评估：代码实例与参数说明

评估脚本本身并不复杂，核心是把数据集和指标列表传给RAGAS的evaluate方法：

python复制from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_relevancy,
)

# 这里配置评测用的LLM和Embedding，按需替换为你的模型
# 例如使用ChatOpenAI或本地部署模型的兼容接口
result = evaluate(
    dataset=eval_dataset,
    metrics=[faithfulness, answer_relevancy, context_relevancy],
    llm=eval_llm,
    embeddings=eval_embeddings,
)

# 输出结果
print(result)
print(result.to_pandas())

这里的关键参数就是指标列表和评分模型。我把faithfulness和answer_relevancy放到第一位，是因为这两个指标直接反映用户体验的"靠谱程度"。对于超过几条样本的评测，RAGAS内部会分批调用LLM，耗时较长，建议在异步或后台任务中执行。

如果数据集里有标准答案，还可以加上answer_correctness指标：

python复制from ragas.metrics import answer_correctness

result = evaluate(
    dataset=eval_dataset,
    metrics=[faithfulness, answer_relevancy, context_relevancy, answer_correctness],
    llm=eval_llm,
    embeddings=eval_embeddings,
)

4.4 接入LangSmith：埋点、追踪与结果回传

LangSmith在流程中主要承担"追踪和结果汇聚"的任务。如果你的RAG链是用LangChain写的，接入追踪就很简单：

python复制import os

os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_PROJECT"] = "rag-evaluation-demo"

设置好环境变量后，LangChain在执行链时会自动把每次运行的输入输出、中间检索文档、LLM调用都记录到LangSmith。之后在LangSmith界面上，点击任意一条trace，就能看到完整的链路明细。

更进一步的方案，是把RAGAS的评估结果同步回LangSmith，和trace关联起来。LangSmith支持自定义评估器和数据集评测。你可以把RAGAS当作一个LangSmith evaluator接入：

python复制from langsmith.evaluation import evaluate as ls_evaluate
from langsmith.schemas import Run, Example

# 自定义评估器，内部调用RAGAS指标
def ragas_evaluator(run: Run, example: Example):
    # 从run中取出answer，从example中取出question和contexts
    # 调用RAGAS指标计算分数并返回
    return {"faithfulness": 0.8, "answer_relevancy": 0.9}

这样操作的好处是，所有评测结果都沉淀在LangSmith平台里，可以按数据集、按时间对比，还能直接在trace详情里看到某条高分/低分样例的完整上下文，调试效率提升非常明显。

4.5 把评估写进CI：发布前的回归防线

离线评估不宜只在本地命令行跑，最好把它做成一个可重复执行的CI任务。我在项目里的做法是维护一个评测仓库，写一个eval_suite.py脚本，通过命令行参数控制评测的数据集切片与模型版本。CI里配置一个定时任务或发版前的手动任务，执行如下逻辑：

bash复制python eval_suite.py --dataset regression_v1.json --model chat-model-v2

执行结束后，脚本会把评测结果汇总为一份Markdown报告，并自动上传到LangSmith。如果某个指标低于阈值，CI任务直接失败，阻止不合格版本合入。这里对阈值的设定要谨慎，建议第一轮先跑出基线分数，再根据基线动态设定下降百分比作为红线，而不是拍脑袋定一个绝对分数。

5. 常见问题与排查技巧实录

5.1 LLM裁判分数不稳定怎么办

这个问题是我最常被问到的。RAGAS依赖LLM打分，而LLM天然存在随机性，同一个case反复跑可能得到不同分数。我在项目里试过两个办法：一是把评分模型温度调低，设置为0，减少随机性；二是对同一个case重复评估多次，取平均分或中位数作为最终分数。

还有一点容易忽略：评分模型的版本升级也会带来评分尺度的漂移。某个模型新版本可能评分标准突然变严或变松，导致你的指标历史曲线看起来"断裂"了。因此我建议固定评分模型的版本，不要在生产评测链路上随版本自动升级。

5.2 指标虚高或虚低的排查思路

如果某项指标分数好得离谱，或者差得出奇，先不要怀疑RAGAS本身，按照下面的顺序排查。

首先确认数据集字段映射是否正确。RAGAS要求question、answer、contexts字段保存的内容必须是从真实RAG链路里取出来的，其中answer一定要来自你的RAG系统输出，而不是标准答案。如果你的answer字段误用了ground_truth，那忠实性分数会高得完全没有参考意义。

其次检查上下文是否完整。有时为省时间，我只给数据集塞了一小段被截断的上下文，这会导致忠实性被低估。因为答案里的关键依据确实在上下文里，但被截断掉了，评估器无法找到支撑点。

最后检查题目和答案的语言是否匹配。中英文混合的数据偶尔会让评估模型判断错乱，在评测集里尽量保证question、answer、contexts三者的语言一致。

5.3 一个走查清单：我在上线前必过的六项检查

我把踩过坑的经验整理成一个简单的走查清单，每次跑评测前快速过一遍，能省掉很多无效尝试：

这张表我贴在公司内部wiki里，每次排查问题先照着走一遍，基本能覆盖80%的初级配置问题。

5.4 关于评估集规模的现实建议

很多团队一上来就想构建上千条人工标注评测集，我建议不要这么做。高质量的上千条RAG评测集，标注成本极高，且维护困难。更现实的路径是：先搞一个50条左右的核心回归集，覆盖主要业务场景；然后把重点放在线上bad case的持续挖掘上，每周从LangSmith的trace里挑出用户反馈差或指标异常的case，补进评测集。

这样维护几个月后，你的评测集会自然增长到几百条，而且每条都是"有价值的"。比起一开始就做大规模标注，这种渐进式积累性价比高出很多。

另外一点关于阈值设定：不要把某个指标的绝对分数定成"大于0.8才算合格"。RAGAS的分数受领域、语言、上下文长度、问题复杂度影响极大，不同系统间横向比较没有意义。我习惯的做法是：记录每个版本的三项核心指标，以当前生产版本为基准，允许小幅波动，但禁止关键指标明显下降。

最后分享一点个人感受

如果你正在搭建RAG系统，我强烈建议尽早把评估链路建起来，而不是等项目快上线了才补。早期接入会难受一阵子，因为要额外维护数据、跑评测、盯指标，但从长远看，它给你的迭代效率带来的提升是实实在在的。我第一次完整跑通RAGAS + LangSmith的组合时，给团队交付了一份包含各项指标、线上追踪链路、bad case列表的评估报告，从那之后，围绕"回答质量"的讨论终于不再停留在感觉层面。希望这个方案能帮你少走一些弯路。