LLM应用上线翻车记：5条badcase三轮回血，附线上真实打法

你辛辛苦苦搞了个LLM应用上线第一天用户就反馈答非所问“编造事实”“格式混乱”。你打开日志一看满屏的翻车记录但根本不知道从哪开始修。今天这篇文章我从一个真实的场景切入5条badcase如何通过三轮迭代清零再对比线上生产环境是怎么做这件事的。不是理论是手敲代码跑通的。先说结论LLM应用的质量问题本质上是个闭环问题不是一次性解决的事。核心就五个字发现-分析-修复-验证-确认。你把这个闭环跑起来质量就会螺旋上升跑不起来就是在bug堆里打地鼠。场景5条badcase的来历假设你跑了一遍Agent ChatBot的测试发现5个问题用户问Java的垃圾回收机制有哪些RAG没召回G1相关文档用户问G1回收器特点LLM直接编造G1不支持堆压缩Agent调用天气API把北京传成了beijingAPI不认用户正常问推荐一本书被InputGuard误判为Prompt注入拦截了LLM返回的JSON缺少summary字段Schema校验挂了这5条badcase覆盖了LLM应用最常见的5种失败类型检索失败、生成幻觉、工具调用错误、安全误判、格式不规范。第一步别急着修先收集大部分人的第一反应是赶紧改Prompt试试。错。先收集把badcase结构化存下来。我设计了5种失败类型枚举和4级严重程度CRITICAL HIGH MEDIUM LOW每条badcase用Builder模式构建BadcasebcnewBadcase.Builder(G1回收器有什么特点,G1回收器不支持堆压缩只能用于实验环境。,FailureType.HALLUCINATION).expectedOutput(G1支持堆压缩是生产级回收器).severity(Severity.CRITICAL).source(AgentJudgeEvaluator).description(LLM完全编造了错误信息).build();为什么用Builder因为线上badcase的字段会不断增加trace_id、model_version、token_count…Builder模式加字段不破坏已有代码。收集器支持按类型/严重程度/来源三个维度过滤还能按严重程度降序排序。CRITICAL排最前面先修最致命的。第二步分析找出先修哪个收集完不是按顺序修是按优先级修。优先级怎么定我算了一个得分优先级 严重程度 × 10 同类型出现频率。为什么加频率因为如果幻觉问题出现了10次就算单条是MEDIUM也值得优先修–说明Prompt或模型本身有系统性问题。分析器还会针对每种失败类型给出具体建议检索失败- 增大Top-K 引入Rerank重排序生成幻觉- System Prompt加约束仅基于上下文回答 启用幻觉检测器工具调用错误- 参数Schema校验 工具描述加参数示例安全误判- 收窄InputGuard正则 加白名单机制格式不规范- JSON Schema强校验 缺字段自动补默认值5条badcase分析完修复队列长这样#1幻觉(CRITICAL) - #2检索失败(HIGH) - #3工具调用错误(HIGH) - #4安全误判(MEDIUM) - #5格式问题(LOW)。第三步闭环改一轮测一轮这是最关键的一步。改完不算完得验证改了有没有用。我设计了一个五步闭环REGISTER拍快照- ANALYZE分析- FIX实施改进- RETEST重新测试- COMPARE对比决策。每轮迭代前后各拍一个快照记录badcase总数、各严重程度数量、回归测试通过/失败数。改进后badcase减少且回归全通过 - 确认发布否则 - 回滚换方案。三轮迭代的结果迭代1: 修复CRITICAL幻觉 - 5→4 badcase ✅确认 迭代2: 修复HIGH检索工具 - 4→2 badcase ✅确认 迭代3: 修复MEDIUM安全LOW格式 - 2→0 badcase ✅确认5条badcase三轮清零回归测试全程29/29通过。这就是闭环的力量。线上真实打法教学版的壳 vs 生产级的核教学版教你的是思维模型线上多出来的是工程化外壳。我直接说差异。采集方式完全不同。教学版手动add线上靠三个通道用户点按钮自动落库、隐式信号同一问题问两次以上第一次没答好、LLM-as-a-Judge抽样巡检1%~5%对话自动评分。存储不是内存List是ES全链路trace包含model_version、retrieved_docs、tool_calls、latency、token_count等几十个字段。分析不是跑一次main。线上是Airflow每天凌晨定时跑结果推Grafana看板看趋势。CRITICAL突增超阈值直接触发PagerDuty告警半夜也得起来看。根因分析不是简单按类型统计是下钻到具体原因–是换了模型版本某条Prompt改了知识库更新引入的验证不是simulatePass。线上拿几百到几千条badcase数据集真实重跑跑回归套件用LLM-as-a-Judge重新评分对比改进前后准确率/召回率/幻觉率/满意度。验证通过后不直接发布是灰度5%流量切新版观察1~3天指标好就全量差就回滚。一个真实案例。某团队上线RAG问答系统用户反馈回答不准。他们做的第一步不是改Prompt是加埋点收集badcase一周攒了200多条。分析发现70%是检索失败根因是Embedding模型对中文支持差。换了个中文Embedding模型后召回率从62%提到85%。灰度5%跑了两天badcase率降了60%全量发布。整个过程一周数据驱动每一步决策。设计模式不是装逼是真有用这三步代码用了三个设计模式每个都有实际理由Builder模式构建Badcase线上badcase字段会从10个涨到30个Builder加字段不改调用方代码。如果用构造函数加一个参数所有new的地方都得改。策略模式定义FixAction不同badcase的修复逻辑完全不同策略模式让你每个修复方案独立演进不互相耦合。备忘录模式做Snapshot每轮迭代的指标快照需要持久化存储方便回溯历史趋势。备忘录模式让快照本身不可变保证对比数据可信。写在最后LLM应用的质量管理核心不是一次性做到完美是持续发现并修复。闭环跑起来每一轮迭代都让badcase少一点质量就螺旋上升。教学版的五步闭环REGISTER-ANALYZE-FIX-RETEST-COMPARE是骨架线上的自动采集、定时调度、灰度发布是肌肉。骨架你已经在Day6搭好了剩下的工程化能力在实际项目里逐步补齐就行。下一篇我们搞Day7实战把这个闭环接到真实的Agent ChatBot项目上跑一个能用的迷你版自动化测试评估Pipeline。一起从Java后端转型大模型应用开发。有问题评论区聊。