一行系统提示修改将模型质量从84%降至52%。人们在生产环境中如何监控语义质量？

几周前，我在一次部署中修改了系统提示的一行。一切看起来正常： * 错误率保持正常 * 延迟看起来没问题 * 请求都返回200 但回答质量明显变差，我直到11天后才因为用户投诉发现。说实话，这感觉很奇怪，来自常规后端工程，那里的失败通常很快就会显现。对于LLM应用，感觉你可能会有一个技术上健康但一直在给出错误答案的系统。例如：支持机器人开始自信地说退款有效期为60天而不是30天。没有抛出异常，没有触发告警，一切看起来都是绿色的。 那次事件之后，我开始构建一些内部工具来监控语义质量，而不仅仅是基础设施指标。最终被证明有用的主要事项： * 对采样响应进行后台评估 * 检查幻觉与检索上下文 * 统计比较提示版本而不是目测输出 * 在响应看起来可疑时重试/标记 * 聚类失败以发现重复模式 让我感到惊讶的一件事：LLM-as-judge评分比我预期的要嘈杂得多。在相同的输入上多次运行同一个评判者有时会得到截然不同的分数，所以我开始聚合多次运行的结果，而不是信任单次输出。 好奇其他人在生产环境中是如何处理这个的。大多数团队只是在部署前运行评估吗？人工审核？影子流量？自定义评判管道？感觉“我们从用户投诉中发现”仍然是许多LLM应用的默认监控策略。