从评估到可观测性

测试与评估的边界消失

在传统软件中，测试和评估是泾渭分明的两个活动。测试回答"代码是否按规格工作"，评估回答"产品是否满足用户需求"。前者是二值的（通过/失败），后者是连续的（好/一般/差）。

在 LLM 应用中，这条边界正在消失。

当你衡量"LLM 摘要的准确率是否在 85% 以上"时，这是测试还是评估？它有明确的通过/失败判据（>= 85% 通过，< 85% 失败），像测试。它使用统计度量在大量样本上计算，像评估。它可以在 CI 中自动运行，像测试。它的判断标准可能随业务需求变化，像评估。

答案是：在 LLM 应用中，评估本身就是测试。统计度量（准确率、一致性、幻觉率）本质上是一种持续运行的测试套件，每个度量对应一个质量属性，每个阈值对应一个通过条件。将评估指标转化为测试断言，做起来很简单——为每个质量维度定义一个阈值，在评估数据集上计算该维度的指标，判断是否超过阈值。这些测试的特殊性在于：它们需要一个标注过的测试数据集，结果是统计性的，阈值的设定是业务判断。

评估数据集：质量的锚点

评估即测试的质量取决于测试数据集的质量。

代表性。 数据集应该覆盖生产环境中实际出现的输入分布。如果 80% 的生产请求是简单查询，数据集中简单查询的比例也应该接近 80%。

多样性。 在保持代表性的前提下，覆盖已知的边界情况和困难样本。特别是那些曾经导致过生产问题的输入。

标注质量。 每个样本的预期输出（或质量标签）需要准确。低质量的标注会导致评估结果不可靠——系统实际表现很好但因为标注错误而被判为失败，或者实际表现很差但因为标注宽松而通过。

可维护性。 数据集需要随业务变化而更新。新增的业务场景需要新的测试样本，废弃的场景需要移除对应样本。将评估数据集纳入版本控制，像代码一样管理。

从离线评估到在线监控

评估不应该只在版本发布时进行。离线评估（上线前，在固定数据集上）→ 在线评估（上线后，对生产流量抽样）→ 持续监控（实时指标和告警）。三者是同一条线的不同位置。

离线评估是质量门禁——prompt 变更或模型切换在上线前必须通过的检查点。在线评估是生产环境下的真实质量信号——异步对生产流量抽样评估，不影响用户体验，但提供了固定数据集无法捕捉的分布漂移信息。持续监控是最后一道实时防线——当指标跌破阈值时触发告警和回滚。

从离线到在线的关键转变是：离线评估的数据集是固定的，在线评估面对的是真实的、持续变化的输入分布。模型提供商的静默更新、用户群体的变化、上游数据的质量波动——这些因素都可能导致质量漂移，只有在线评估能捕捉。

LLM 应用的可观测性

传统软件的可观测性主要关注性能（延迟、吞吐量）和健康度（错误率、可用性）。LLM 应用在这两个维度之外，还有一个传统系统不存在的维度：输出质量。

一个 HTTP 200 的响应在传统系统中意味着成功。在 LLM 应用中，HTTP 200 只意味着 API 调用没有失败——LLM 返回了格式正确的 JSON，但内容可能是幻觉、可能答非所问、可能忽略了关键约束。要发现这些"成功的失败"，得靠可观测性。

可观测性的三大支柱——日志、追踪、指标——在 LLM 应用中有特殊的实现要求。

日志需要记录完整的调用上下文。 输入的 prompt（包括 system prompt 和用户消息）、LLM 的原始响应、解析后的结构化结果、验证是否通过。这些信息是事后分析质量问题的唯一依据。隐私这个约束绕不开：完整的 prompt 和响应可能包含用户的敏感数据，日志的存储、访问控制和保留策略要满足数据隐私要求。

追踪要串起完整的调用链路。 在多步工作流中，一次用户请求可能触发多次 LLM 调用、多次工具调用和多次数据库查询。分布式追踪将这些操作串联为一条因果链。追踪在 LLM 应用中特别有用，因为它让推理过程可以回溯——当最终输出有问题时，追踪帮助你定位问题发生在哪个步骤：是检索到了无关文档（RAG 步骤），还是 LLM 忽略了关键信息（生成步骤），还是工具返回了错误数据（工具调用步骤）。

指标需要扩展到质量维度。 除了标准的运维指标（延迟 P50/P99、错误率、吞吐量），LLM 应用需要额外的质量指标：结构合规率（LLM 输出通过 Schema 验证的比例）、重试率（需要重试才能获得合规输出的调用比例）、Token 消耗（输入和输出 token 的分布，直接关联成本）、降级率（触发降级逻辑的调用比例）。

维度	传统应用指标	LLM 应用新增指标
性能	延迟、吞吐量	Token 消耗、推理步数
健康度	错误率、可用性	结构合规率、重试率、降级率
质量	（无对应概念）	语义准确率、一致性、幻觉率
成本	计算资源	Token 成本（按模块、按模型）

Prompt 版本与输出质量的关联

可观测性的一个高级应用是将 prompt 版本与输出质量关联。当你修改了一个 prompt 并部署到生产环境，可观测性系统应该能回答：这次修改是否改善了输出质量？

实现方式：在每次 LLM 调用的日志中记录 prompt 的版本标识，在指标系统中按版本分组统计质量指标，对比新旧版本的指标分布判断变更的效果。可观测性就不只是发现问题，还能指导优化——与上一篇讨论的实验管理形成闭环：实验管理提供离线的变更归因，可观测性提供在线的效果验证。

成本可观测性

Token 消耗是 LLM 应用的主要运营成本。成本可观测性意味着能够回答：每个功能模块消耗了多少 token？成本的时间趋势是什么？是否有异常增长？哪些用户或请求类型花钱最多？

做法很简单：每次 LLM 调用后，将 token 消耗记录为按功能模块和模型标注的计数器指标。有了这些数据，就可以按模块归因成本、检测异常增长、识别高消耗的请求类型。

成本监控是必须的。一个没有成本监控的 LLM 应用，就像一个没有限速的 API——迟早会因为意外的流量或使用模式导致账单失控。

评估的成本与收益

诚实地说，高质量的评估和可观测性是昂贵的。构建标注数据集需要领域专家的时间，运行评估测试需要 LLM API 调用的成本，维护可观测性基础设施需要持续的工程投入。

但没有评估更昂贵。在没有量化质量标准的情况下，每次 prompt 修改、每次模型切换、每次架构调整，都是一次盲目的赌博——你不知道它是改善了还是恶化了系统质量。评估的成本可以算出来，但不评估可能付出多大代价，你算不出来。