1. 从“感觉还行”到“心中有数”为什么有状态LLM系统需要量化评测最近和几个做AI应用的朋友聊天发现一个挺普遍的现象大家花大力气搭了个RAG系统或者AgentDemo跑起来效果不错能回答几个预设问题就觉得“成了”。但一旦放到真实业务流里或者让更多用户来用问题就接踵而至——回答时准时不准、上下文偶尔“失忆”、处理长文档时速度慢得离谱甚至同一个问题多问几次答案都不完全一样。这时候开发者往往陷入一种“盲人摸象”的状态只能凭感觉去调参、加规则效果好不好全看运气。这背后的核心问题就在于我们面对的是一个有状态的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( premisetest_case.context, hypothesissystem_response.answer ) metrics[faithfulness] faithfulness_score # 使用LLM裁判计算相关性和有用性 llm_judge_score llm_judge.evaluate( questiontest_case.question, contexttest_case.context, answersystem_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, threshold0.5) return report5. 实战中的挑战与应对策略理论很美好但一上手就会遇到各种坑。下面分享几个我趟过的雷区。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系统做量化评测是一个从混沌走向清晰、从感性走向理性的过程。它开始可能很繁琐需要你投入精力去定义指标、构造数据、搭建流水线。但一旦运转起来它就会成为你系统开发中最值得信赖的“副驾驶”让你每一次代码提交、每一次架构调整都底气十足。 有状态LLM系统量化评测：从RAG到Agent的工程实践指南
1. 从“感觉还行”到“心中有数”为什么有状态LLM系统需要量化评测最近和几个做AI应用的朋友聊天发现一个挺普遍的现象大家花大力气搭了个RAG系统或者AgentDemo跑起来效果不错能回答几个预设问题就觉得“成了”。但一旦放到真实业务流里或者让更多用户来用问题就接踵而至——回答时准时不准、上下文偶尔“失忆”、处理长文档时速度慢得离谱甚至同一个问题多问几次答案都不完全一样。这时候开发者往往陷入一种“盲人摸象”的状态只能凭感觉去调参、加规则效果好不好全看运气。这背后的核心问题就在于我们面对的是一个有状态的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( premisetest_case.context, hypothesissystem_response.answer ) metrics[faithfulness] faithfulness_score # 使用LLM裁判计算相关性和有用性 llm_judge_score llm_judge.evaluate( questiontest_case.question, contexttest_case.context, answersystem_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, threshold0.5) return report5. 实战中的挑战与应对策略理论很美好但一上手就会遇到各种坑。下面分享几个我趟过的雷区。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系统做量化评测是一个从混沌走向清晰、从感性走向理性的过程。它开始可能很繁琐需要你投入精力去定义指标、构造数据、搭建流水线。但一旦运转起来它就会成为你系统开发中最值得信赖的“副驾驶”让你每一次代码提交、每一次架构调整都底气十足。