有状态LLM系统量化评测：从RAG到Agent的工程实践指南-平芜编程栈

1. 从“感觉还行”到“心中有数”：为什么有状态LLM系统需要量化评测

最近和几个做AI应用的朋友聊天，发现一个挺普遍的现象：大家花大力气搭了个RAG系统或者Agent，Demo跑起来效果不错，能回答几个预设问题，就觉得“成了”。但一旦放到真实业务流里，或者让更多用户来用，问题就接踵而至——回答时准时不准、上下文偶尔“失忆”、处理长文档时速度慢得离谱，甚至同一个问题多问几次，答案都不完全一样。这时候，开发者往往陷入一种“盲人摸象”的状态，只能凭感觉去调参、加规则，效果好不好全看运气。

这背后的核心问题，就在于我们面对的是一个有状态的LLM系统。它不再是那个你扔进去一段Prompt，它吐出来一段回答的“黑箱”模型。一个典型的有状态系统，比如基于LangChain或LangGraph构建的Agent，或者一个复杂的RAG（检索增强生成）工作流，它的内部状态可能包括：

对话历史：不仅仅是上一轮问答，可能是一个精心维护的、经过总结或筛选的长期记忆。
工具调用历史：Agent调用过哪些API、得到了什么结果、这些结果如何影响了后续决策。
检索到的文档片段及其来源：RAG系统从知识库里捞出了哪些“证据”，这些证据的排序和相关性得分。
工作流的中间状态：比如一个多步骤任务，当前执行到哪一步了，生成了哪些中间结果。

这种“状态”让系统变得智能和连贯，但也让它变得极其复杂和难以评估。你无法再用单一模型的准确率、BLEU分数来简单衡量。你说它“效果好”，到底是指它检索的文档准？还是生成答案的忠实度高？还是它规划任务的能力强？抑或是它在十轮对话后还能记得第一轮的用户偏好？

所以，给有状态LLM系统做一套量化评测，不是为了追求一个漂亮的分数，而是为了把“感觉还行”变成“心中有数”。它能帮你：

定位瓶颈：是检索模块拖了后腿，还是LLM生成时总爱胡编乱造？是Agent的规划逻辑有漏洞，还是状态管理出了问题？
衡量迭代效果：你换了新的嵌入模型、调整了检索策略、给Agent增加了新工具，这次改动到底是进步了还是退步了？不能靠“我觉得快了”，得靠数据说话。
设定性能基线：为系统在准确性、速度、成本、稳定性等方面建立可接受的底线，确保上线后不会崩盘。
驱动持续优化：评测本身就是一个“探针”，能持续发现系统在各类边缘场景下的脆弱点，指导后续开发重点。

接下来，我们就抛开空泛的概念，直接进入实战，看看如何一步步搭建起这套评测体系。

2. 拆解系统：定义你的评测对象与核心指标

动手之前，必须先把你那个“有状态系统”拆解明白。不同的架构，评测的重点天差地别。我们结合几个典型模式来说。

2.1 识别你的系统类型

多轮对话机器人（Chatbot with Memory）：这是最常见的有状态系统。它的核心状态是对话历史。评测重点在于上下文理解与维持能力。比如，用户在第5轮对话中说“我还是喜欢第一个方案”，系统能否正确关联到第1轮对话中提到的几个方案？
检索增强生成（RAG）系统：它的状态通常包括用户问题、检索到的文档块集合、以及可能的对话历史。评测必须分为两层：
- 检索层：找得“准”吗（召回率、准确率）？找得“全”吗（召回率）？找得“快”吗（延迟）？
- 生成层：基于找到的文档，答案“对”吗（忠实度）？“好”吗（相关性、有用性）？有没有“瞎编”（幻觉率）？
智能体（Agent）系统：这是最复杂的。状态可能包括目标、已执行的动作序列（工具调用）、工具返回的结果、以及内部的工作计划。评测维度更广：
- 规划能力：步骤合理吗？有效率吗？
- 工具使用能力：调用的工具对吗？参数传对了吗？
- 状态管理能力：能根据工具结果正确更新状态并决定下一步吗？
- 最终目标达成度：任务最终完成得怎么样？

2.2 制定核心量化指标

指标不在多，在于精准命中你的业务目标。下面这个表格可以作为你制定指标的参考框架：

评测维度	核心指标	定义与计算方法	适用系统	工具/方法举例
准确性	答案忠实度	生成答案是否严格基于给定上下文（检索到的文档），有无虚构。	RAG, Agent	基于NLI（自然语言推理）模型判断（如`DeBERTa`），或让LLM（如GPT-4）根据上下文对答案进行评分。
事实正确性	答案本身是否符合世界事实（需要外部知识验证）。	通用	结合知识图谱或权威数据库进行验证，或使用LLM作为“裁判”。
任务完成度	对于有明确终态的任务（如“订一张明天北京飞上海的机票”），是否成功完成。	Agent	检查最终输出是否包含成功的关键信息（如订单号），或通过模拟API的响应来判断。
相关性	答案相关性	答案是否直接回应了用户的问题。	所有	使用LLM（如GPT-4）对“Q-A对”进行相关性评分（1-5分）。
检索相关性	检索到的文档与问题的匹配程度。	RAG	计算查询与文档的嵌入向量相似度（如余弦相似度），或使用交叉编码器（如`bge-reranker`）进行精排评分。
效率	响应延迟	从用户提问到收到完整回答的时间（端到端延迟）。	所有	直接计时。需区分“首字延迟”和“全句延迟”。
吞吐量	单位时间内系统能处理的查询数量。	所有	压力测试工具（如`locust`）。
Token消耗	单次请求消耗的输入/输出Token数，直接关联成本。	所有	从LLM供应商的API响应中获取，或本地模型通过分词器计算。
鲁棒性	幻觉率	生成内容中包含的、无法从上下文中推断出的虚构信息的比例。	RAG, 生成类	在评测集上统计触发幻觉的案例占比。
错误处理	面对非法输入、工具调用失败等情况，系统是否给出合理响应而非崩溃。	Agent, Chatbot	设计包含错误场景的测试用例，检查响应是否包含友好的错误提示或降级处理。
长上下文表现	在对话轮次增多或输入文档极长时，性能（准确度、延迟）的衰减情况。	所有	构造长对话或长文档测试集，进行纵向对比。

注意：不要试图用一个“总分”来概括一切。一个检索满分但生成胡编的RAG系统，和一个生成优美但答非所问的聊天机器人，总分可能一样，但问题本质完全不同。你的评测报告应该是一份多维度的体检表，而不是一张成绩单。

3. 构建评测基准：从“拍脑袋”到“科学化”

有了指标，你需要数据来测。这就是评测基准——一套精心设计的、带有标准答案或评判标准的测试用例集合。

3.1 构建你的测试集

1. 核心场景用例（Must-Have）：这是你的“冒烟测试”。直接来自产品需求文档中最核心的10-20个用户场景。例如，对于一个技术文档问答RAG：

“如何在K8s中部署一个Nginx服务？”
“我们的产品支持哪些认证方式？”
“遇到‘Error 503’应该怎么排查？” 这部分用例确保你的系统基本功能是跑通的。

2. 压力与边界用例（Stress & Corner Cases）：这部分最能体现代码的健壮性，也是评测的价值所在。

模糊查询：“那个…之前说的那个配置项是啥来着？”（测试对话记忆和指代消解）
超长上下文：先进行20轮关于不同主题的闲聊，再问一个需要结合最早信息的问题。（测试长期记忆管理）
检索对抗：提问中包含大量与核心问题无关的噪音词汇。（测试检索系统的抗干扰能力）
工具异常：对Agent，模拟工具返回错误、超时或非预期格式的数据。（测试错误处理与状态回滚）
多跳推理：“我们公司去年营收最好的产品，它的主要竞品是谁？”（需要先检索“去年营收最好产品”，再用该产品名检索“竞品”）

3. 负样本与对抗样本：故意提供错误的前提或矛盾的信息，看系统能否识别并纠正，而不是将错就错。

前提错误：“根据你刚才说的（其实没说过）月球上有水，那么…”
上下文矛盾：在提供的文档中，A处说“参数X默认是1”，B处说“参数X默认是0”。看系统如何应对冲突。

3.2 如何获取“标准答案”？

对于事实性问题，可以组织领域专家编写。但对于开放域、创意性或需要多步推理的任务，“标准答案”可能不止一个。这时可以采用：

参考答案（Reference Answer）：提供1-3个高质量的示例答案。
评分准则（Rubric）：详细定义每个得分等级（如1-5分）对应的答案特征。例如，“5分答案：准确引用文档片段，解释清晰，给出操作步骤；3分答案：答案正确但未引用来源；1分答案：答案错误或无关。”
LLM-as-a-Judge：这是目前的高效做法。使用一个更强的LLM（如GPT-4）作为裁判，根据问题和上下文，对被测系统的输出进行评分。关键是要给裁判模型一个清晰、无偏的评分指令（Prompt），并最好能提供少量示例（Few-shot）。

4. 搭建自动化评测流水线

手动测试几个案例可以，但要想持续迭代，必须自动化。一个基本的自动化评测流水线包含以下组件：

4.1 核心组件设计

测试用例管理器：存储你的测试集（JSON/YAML格式），每个用例包含：唯一ID、问题、上下文（对于RAG）、多轮对话历史（对于Chatbot）、任务描述（对于Agent）、以及参考答案或评分准则。

{ "id": "rag_fact_001", "type": "factual_qa", "question": "Llama 3模型发布的年份是？", "context": "Meta于2024年4月发布了其最新一代开源大模型Llama 3...", "reference_answer": "2024年", "evaluation_criteria": { "faithfulness": "答案必须严格来自Context，不能自行添加信息。", "relevance": "答案必须直接回答问题。" } }

系统调用器：一个封装好的客户端，负责以统一的方式调用你的有状态系统。它需要能：
- 初始化或加载系统的特定状态（如某个会话）。
- 发送输入（问题/指令）。
- 接收并解析系统的完整输出（包括文本回答、工具调用记录、检索结果等元数据）。
- 维护对话会话（对于多轮测试）。
指标计算器：这是流水线的大脑。针对每个测试用例的输出，调用不同的“计算单元”来得到各项指标。
- 基于规则的计算器：例如，检查答案中是否包含某个关键词（任务完成度），计算响应时间（延迟）。
- 基于模型的评估器：
  - NLI模型：用于忠实度判断。将“假设”（生成的答案）和“前提”（提供的上下文）输入模型，得到“蕴含”、“矛盾”、“中立”的概率。
  - LLM裁判：用于相关性、有用性、创造性等主观指标的评分。需要精心设计Prompt，例如：
```
你是一个公正的评估员。请根据以下标准对助手答案进行评分（1-5分）： 问题：[用户问题] 上下文：[提供的相关文档] 助手答案：[待评估答案] 评分标准： 5分：答案完全正确，清晰引用了上下文，解释详尽。 3分：答案基本正确，但未引用来源或略有模糊。 1分：答案错误或未回答问题。 请先输出分数，然后简要说明理由。
```
结果聚合与可视化器：收集所有用例的指标结果，生成报告。
- 整体报告：各指标的平均分、分位数、分布直方图。
- 维度对比：例如，展示“忠实度”与“相关性”的散点图，帮你发现“答案很相关但不忠实”（爱瞎编）或“很忠实但不相关”（答非所问）的病例。
- 失败案例分析：自动列出所有低分（如忠实度<0.5）的用例，方便你集中排查。

4.2 一个简单的流水线示例（伪代码概念）

# 伪代码，展示逻辑流程 def run_evaluation_pipeline(test_suite, system_client): results = [] for test_case in test_suite: # 1. 调用系统 start_time = time.time() system_response = system_client.query(test_case.question, test_case.context) end_time = time.time() latency = end_time - start_time # 2. 计算各项指标 metrics = {} metrics['latency'] = latency # 使用NLI模型计算忠实度 faithfulness_score = nli_model.evaluate( premise=test_case.context, hypothesis=system_response.answer ) metrics['faithfulness'] = faithfulness_score # 使用LLM裁判计算相关性和有用性 llm_judge_score = llm_judge.evaluate( question=test_case.question, context=test_case.context, answer=system_response.answer ) metrics['relevance'] = llm_judge_score['relevance'] metrics['helpfulness'] = llm_judge_score['helpfulness'] # 3. 记录结果 result_record = { 'case_id': test_case.id, 'question': test_case.question, 'system_answer': system_response.answer, 'metrics': metrics, 'retrieved_docs': system_response.retrieved_docs, # 记录检索结果用于分析 'tool_calls': system_response.tool_calls # 记录Agent工具调用 } results.append(result_record) # 4. 聚合与生成报告 report = generate_report(results) visualize_results(results) save_failure_cases(results, threshold=0.5) return report

5. 实战中的挑战与应对策略

理论很美好，但一上手就会遇到各种坑。下面分享几个我趟过的雷区。

5.1 评测成本控制：LLM裁判很贵怎么办？

用GPT-4做裁判，评测几百个用例成本可能就几十美元。对于日常迭代，这是不可持续的。

策略一：分层评测。不是所有用例都需要动用“终极裁判”。
- 第一层：规则过滤。用正则或关键词匹配先筛掉明显错误（如答案为空、包含“我不知道”但上下文有答案）。
- 第二层：轻量模型。对于事实正确性、忠实度，先用开源的、专门训练的评估模型（如BARTScore,BERTScore的变种，或DeBERTa微调的NLI模型）打分。它们成本极低。
- 第三层：LLM裁判。只对前两层筛选出的、存疑的、或非常重要的用例，才使用GPT-4等昂贵模型进行精细评分和理由生成。
策略二：缓存与抽样。对于确定性较高的评测（如基于固定上下文和问题的忠实度），结果可以缓存。对于大规模回归测试，可以采用抽样评测，只要保证抽样是随机的、有代表性的即可。
策略三：训练自己的评估模型。如果领域垂直，可以收集一批人工标注的（问题，答案，评分）数据，微调一个像Llama 3或Qwen这样的中小型开源模型，让它学会在你的领域内当裁判。初期投入大，但长期成本几乎为零。

5.2 状态管理的评测：如何测试“记忆力”？

这是有状态系统独有的难题。你不能只测单轮。

构造多轮测试脚本：编写一个脚本，模拟真实用户的连续对话。脚本不仅发送问题，还会根据系统回答验证状态是否被正确维护。

# 一个简单的多轮测试思路 history = [] # 第一轮 answer1 = system.chat("我叫小明。", history) history.append(("我叫小明。", answer1)) # 第五轮 answer5 = system.chat("我刚才说我叫什么名字？", history) # 验证 answer5 是否包含 "小明"

设计状态依赖型任务：
- 指代消解：“推荐一款手机。” -> “它电池多大？”（“它”指代手机）。
- 信息累积：“我想去北京。” -> “三天两晚。” -> “预算5000元。” -> “请做个旅行计划。”（系统需综合地点、时长、预算）。
- 偏好记忆：“我不吃辣。” -> 在后续推荐餐厅时，系统应过滤掉川菜馆。
检查内部状态快照：如果系统设计允许，可以在关键对话轮次后，导出其内部的状态表示（如记忆向量、摘要文本），人工检查其是否正确捕捉了关键信息。

5.3 处理非确定性：LLM输出是波动的

同样的输入，LLM可能给出不同的输出，这会导致评测结果波动。

固定随机种子：在评测时，为LLM调用设置固定的随机种子（如果底层API支持），确保每次生成结果一致。这是进行科学对比的前提。
多次采样取统计值：对于需要评估生成多样性的场景（如创意写作），可以多次采样（如3-5次），然后计算指标的平均值和方差。方差本身就是一个重要的评测指标（稳定性）。
区分“错误”和“差异”：一个答案表述不同但意思正确，应该被接受。这就需要你的评估标准（无论是规则还是LLM裁判）具备一定的语义理解能力，而不是简单的字符串匹配。

5.4 当指标冲突时：如何权衡？

系统优化常常面临权衡。比如，为了提高答案忠实度（减少幻觉），你让RAG系统更严格地限制生成内容只基于检索片段，但这可能导致答案不完整（相关性下降）。或者，为了让Agent更可靠，你增加了更多的验证步骤，导致响应延迟上升。

建立业务优先级：和产品、业务方一起确定，哪些指标是硬性底线（如安全性、事实正确性），哪些是优化目标（如延迟、成本）。一切优化都应在不触碰底线的前提下进行。
使用综合评分函数：可以为不同指标赋予权重，计算一个加权总分，用于快速比较不同版本。但务必谨慎，并理解权重设置带来的导向。公式要透明，例如：综合得分 = 0.4 * 忠实度 + 0.3 * 相关性 + 0.2 * (1 - 归一化延迟) + 0.1 * 任务完成度。
进行A/B测试：在指标层面难以抉择时，将不同版本的系统推送给一小部分真实用户，通过核心业务指标（如任务完成率、用户满意度、停留时长）来做最终裁决。

6. 超越基础：将评测融入开发与运维全流程

一套好的评测体系，不应该只是项目上线前的“期末考试”，而应该融入日常开发的“单元测试”和上线后的“健康体检”。

开发阶段：作为“测试驱动开发”的延伸。在实现一个新功能（如给Agent增加一个工具）时，就同时为它编写对应的测试用例和验收标准（指标）。每次代码提交，都自动运行相关的评测子集，确保新功能符合预期且没有破坏旧功能。
集成阶段：作为“回归测试”的守护神。在主干分支上，每天或每次重要合并后，自动运行全量或核心用例的评测。当某个指标（如忠实度）显著下降时，自动阻断合并或发出警报，让开发者第一时间定位问题。
运维阶段：作为“线上监控”的探针。从线上真实用户问题中，定期抽样一部分，匿名化后加入你的评测集。这能帮你发现线上实际发生的、但测试用例未覆盖的“盲点”。同时，可以定期在预发环境用线上流量回放，进行性能和质量回归测试。
迭代阶段：作为“优化导航”的仪表盘。当你尝试一种新的检索算法、一个不同的LLM提示词、一种更优的状态压缩策略时，你的决策不应基于“直觉”，而应基于A/B评测的结果数据。评测报告能清晰地告诉你，这次改动在哪个指标上带来了多少提升或下降，成本变化如何。

最终，给有状态LLM系统做量化评测，是一个从混沌走向清晰、从感性走向理性的过程。它开始可能很繁琐，需要你投入精力去定义指标、构造数据、搭建流水线。但一旦运转起来，它就会成为你系统开发中最值得信赖的“副驾驶”，让你每一次代码提交、每一次架构调整都底气十足。