LLM应用越改越糟？三步构建有效评估体系

每次调整提示词或更换模型，总有些回答变好，另一些却变差——这是许多LLM应用开发者共同的痛点。在Reddit上，一位开发者发帖求助："每次我们改提示词或模型，别的地方就出问题。一个回答变好了，两个变差了。我们只有等用户抱怨才知道。你们会跑评估吗？智能体给出坏答案时，怎么一步步追踪它在做什么？现在我们只能读日志，太耗时了。"

这条帖子引发了广泛共鸣。它暴露了一个核心问题：LLM应用的迭代缺乏可靠的反馈闭环。本文将结合社区讨论与工程实践，拆解如何系统性地回答"我的应用是在变好还是变坏"。

为什么LLM应用的"好"与"坏"难以判断

传统软件有明确的通过/失败标准，但LLM的输出是开放性的。一个回答变好，可能只是碰巧覆盖了某个边缘场景；两个回答变差，却可能影响核心用户体验。更棘手的是，这种变化往往在用户抱怨时才被发现——此时损失已经发生。

Reddit帖主描述的"读日志"方式，本质上是事后调试。日志能告诉你智能体执行了哪些步骤，但无法告诉你"这一步是否正确"。当智能体在10步推理链的第7步走偏，日志只会忠实记录这个错误，而不会指出错误发生在哪里、为什么发生。

社区中多位开发者指出，问题的根源在于缺乏基准数据集和自动化评估。没有固定测试集，每次改动的影响就只能靠感觉；没有自动化评估，回归测试就无从谈起。

构建评估体系：从测试集到自动化流水线

建立代表真实场景的测试集

评估的第一步是收集一组有代表性的输入-输出对。这些样本应覆盖核心功能路径、常见边缘场景和已知的历史故障案例。Reddit讨论中有人建议：从生产日志中抽样，优先选择用户反馈差的案例和调用频率高的场景。

测试集不需要很大，初期50-100个高质量样本就能暴露大部分回归问题。关键是每个样本都要有明确的期望输出或评分标准——可以是精确匹配、关键信息包含，或由另一个LLM按评分标准打分（LLM-as-judge）。

每次改动前跑回归测试

有了测试集，就可以在每次修改提示词或模型后自动运行评估，对比新旧版本的通过率。这类似于传统软件的单元测试，但评估的是语义正确性。

一位开发者分享的做法是：将测试集分为"必须通过"的核心用例和"尽力覆盖"的边缘用例，核心用例的任何失败都会阻止发布。这种分级策略在保证质量底线的同时，避免过度束缚迭代速度。

用LLM-as-judge扩展评估规模

人工标注成本高，LLM-as-judge可以在较大规模上自动评分。具体做法是用一个能力更强的模型（如GPT-4级别）根据详细评分标准对输出打分。社区经验表明，judge的评分标准越具体（如"回答是否包含三个关键事实"），评分越稳定。

但也要警惕judge本身的偏差：它可能偏好冗长或格式化的回答。因此，judge的评分结果应与人工抽检定期对齐。

LLM-as-judge 的常见偏差与缓解手段

除了偏好冗长和格式化输出，judge 模型还存在位置偏差（倾向于选择先出现的回答）、自我偏好（对自己生成的答案打分偏高）和权威偏差（更认可语气肯定的内容）。实践中可通过以下方式缓解：一是随机交换待比较回答的顺序，二是使用与生成模型不同系列的模型作为 judge，三是在评分标准中显式要求 judge 先列出判断依据再给分，四是对同一批样本用两个不同 judge 交叉验证，当两者评分差异较大时转人工复核。

评估指标的选取

回归测试的指标不应只有单一通过率。建议同时记录：精确匹配率（适用于有确定答案的场景）、关键事实召回率（回答是否覆盖了必需要点）、以及拒答率与幻觉率（回答是否编造了不存在的信息）。多指标并看能避免“通过率上升但回答变得更保守/更啰嗦”这类隐性退化。

追踪智能体行为：超越日志的步骤级可视化

帖主问的第二个问题同样关键：智能体给出坏答案时，如何逐步追踪？

纯日志的问题在于信息过载和缺乏上下文。更好的做法是结构化追踪：记录每一步的输入、输出、工具调用和状态变化，并以可视化时间线的形式呈现。这样你可以直接定位到"第几步的哪个决策导致了错误"。

开源工具如LangSmith、Phoenix等提供了这类追踪能力。它们的核心价值不是记录更多日志，而是把执行链组织成可查询、可比较的结构。比如，你可以筛选出所有在"检索"步骤超时的案例，或对比两个版本在相同输入下的步骤差异。

更进一步，可以将追踪数据与评估结果关联：当某个测试用例失败时，直接跳转到对应的执行轨迹，查看是哪一步偏离了预期。这种"评估-追踪"联动能大幅缩短调试时间。

OpenTelemetry 与 LLM 追踪的标准化

结构化追踪的底层理念与分布式系统可观测性一脉相承：把一次智能体运行视为一个 trace，每一步推理、工具调用作为 span 记录起止时间、输入输出和元数据。近年 OpenTelemetry 的 GenAI 语义约定正在推动 LLM 追踪字段的标准化，使不同框架（LangChain、LlamaIndex、自研 Agent）产生的轨迹可以用同一套后端采集和查询，避免被单一厂商工具锁定。采用标准化的另一个好处是能把 LLM 调用与已有的 APM 系统打通，在同一视图中看到“模型延迟升高”与“下游服务超时”之间的关联。

建立持续反馈闭环

评估和追踪不是一次性工作。一个健康的LLM应用需要把用户反馈、生产监控和自动化评估串成闭环：

• 生产端：收集用户显式反馈（点赞/点踩）和隐式信号（重试、放弃、编辑）。
• 评估端：定期将生产中的失败案例加入测试集，保持测试集与真实分布同步。
• 追踪端：对失败案例自动保存完整执行轨迹，供根因分析。

Reddit讨论中反复出现的一个共识是：不要等用户抱怨才行动。把评估作为发布流程的固定环节，把追踪作为调试的默认工具，才能让每次迭代都真正朝着"变好"的方向前进。

回到最初的问题——如何知道应用在变好还是变坏？答案不是靠感觉，而是靠一套可重复、可度量、可追踪的工程体系。这需要前期投入，但它换来的是迭代速度和质量的兼得。