LLM 应用上线后收到业务反馈和 badcase，如何建立问题归因、数据回流、Prompt/模型迭代和回归评估闭环？｜字节跳动算法面经解析

60 秒回答模板

LLM 应用收到业务反馈和 badcase 后，我会按“收集、归因、修复、评测、上线、回流”建立闭环。第一步是把反馈结构化，记录用户输入、上下文、模型版本、prompt 版本、检索证据、工具调用、输出结果、用户期望、严重程度和是否可复现，避免只留下一个截图。第二步做问题归因，不要一上来就改 prompt。badcase 可能来自需求边界不清、输入缺字段、RAG 没召回、排序把证据排错、prompt 指令冲突、上下文超长被截断、模型能力不足、工具返回错误、安全策略误伤或产品交互引导不足。第三步按根因选择修复方式：数据问题补知识库、切分和元数据；检索问题改召回和重排；prompt 问题调整指令、格式、示例和拒答策略；稳定重复模式可以做 SFT、偏好优化或规则后处理；高风险场景增加人工审核和兜底。第四步把 badcase 沉淀成评测集，按类型打标签，覆盖正常样本、边界样本、无答案样本和历史回归样本，用自动指标、LLM-as-judge 和人工评审结合评估。第五步上线前做 A/B 或灰度，看修复率、旧样本回归、幻觉率、格式通过率、延迟、成本和用户满意度。第六步建立版本管理和监控：prompt、模型、数据索引和工具都要有版本，反馈持续进入样本池，定期复盘高频问题。核心原则是先归因再改动，先用最小有效修复验证，再决定是否进入模型级训练。

考点 先记录上下文

难度 真实面经题

回答目标 让候选人能说明 LLM 线上反馈闭环的完整机制：结构化收集、分层归因、选择修复手段、沉淀评测、灰度上线和持续监控。

深入解析

反馈要结构化成可复现样本

业务反馈如果只是一句“不好用”或一个截图，很难定位。需要记录完整上下文：用户问题、会话历史、输入数据、模型和 prompt 版本、RAG 召回结果、工具调用参数和返回、最终输出、期望输出、业务影响、发生时间和用户标注。这样才能复现问题、判断严重程度，并把反馈转成后续评测样本。

问题归因必须分层

LLM badcase 的根因可能在很多层。输入层可能信息不足或用户意图歧义；数据层可能知识库缺失、过期或权限错误；检索层可能没有召回正确证据；排序层可能把无关证据放前面；prompt 层可能指令冲突或格式约束弱；上下文层可能超长截断；模型层可能推理能力不足或幻觉；工具层可能 API 返回错；产品层可能用户预期被引导错。先分层归因，才能选对修复手段。

Prompt 迭代适合修边界和输出契约

Prompt 修改适合解决指令不清、格式不稳定、拒答边界弱、示例缺失、角色和优先级冲突等问题。改 prompt 时要有版本记录，说明改动目标和影响范围，并用固定评测集回归。不能为了一个 badcase 加一条非常具体的补丁，因为这可能破坏其他问题；更好的做法是抽象出通用规则，例如证据不足时拒答、冲突信息要列出来源、输出必须符合 schema。

数据和模型迭代要看问题规模

如果 badcase 集中在知识缺失、文档过期或检索不到，优先改数据、索引和 RAG；如果是固定业务格式、专业术语、输出风格或领域判断长期不稳定，可以考虑 SFT、偏好数据、领域词表或轻量分类器辅助；如果只是少量边界 case，模型训练可能成本过高且引入回归风险。模型级迭代应建立数据标注规范、训练/验证/测试拆分、版本对比和回滚方案。

评测集要覆盖正常、边界和历史问题

闭环的关键是把 badcase 变成可重复验证的样本池。样本要按问题类型标注，例如幻觉、漏答、格式错误、证据不匹配、工具调用错误、拒答不当、上下文遗忘、token 超限。评测不能只看平均分，还要看高风险类型、历史问题修复率、旧样本回归率、无答案拒答率、结构化输出通过率、延迟和成本。对开放答案可以结合自动规则、LLM-as-judge 和人工抽检。

上线闭环要灰度和监控

每次改 prompt、模型、索引或工具都要能追踪版本，并通过灰度或 A/B 比较线上效果。监控指标包括投诉率、点赞点踩、采纳率、二次追问率、人工修改率、失败率、幻觉告警、响应时延、token 成本和工具错误率。严重问题要有止损方案，例如回滚版本、降低自动化权限、转人工或临时关闭高风险能力。反馈闭环不是一次修复，而是持续运营。

易错点

收到反馈就直接改 prompt，没有记录模型版本、检索结果、工具调用和用户期望，导致问题不可复现。
把所有 badcase 都归因成模型能力差，忽略数据缺失、召回失败、排序错误和产品引导问题。
为单个样本硬加特例规则，不抽象通用边界，结果修好一个问题又引入新回归。
没有把 badcase 沉淀成评测集，只靠人工感觉判断新版本是否更好。
只看平均满意度，不单独关注幻觉、拒答、格式错误、权限错误和高风险场景。
微调前没有做数据清洗、标注规范和测试集隔离，导致训练污染或学到错误偏好。
缺少版本、灰度和回滚机制，线上改动出问题后无法定位是哪一层变化造成的。

面试官追问

如何判断一个 badcase 应该改 prompt 还是改模型？

如果问题来自指令不清、输出格式、拒答策略或少量边界，优先改 prompt 并做回归；如果大量样本都体现稳定的领域知识、风格、判断标准或复杂格式能力不足，且 prompt 已难以解决，再考虑 SFT、偏好优化或专门模型。模型迭代成本更高，必须有数据集和评测闭环。

业务反馈很主观，怎么转成可评测样本？

先让反馈包含原输入、实际输出、期望输出和不满意原因，再把原因标签化，例如事实错误、漏答、语气不合适、格式错误、无法执行、风险高。对主观质量可以制定 rubric，由人工或 LLM-as-judge 按一致标准评分。

如何处理幻觉类反馈？

先判断是无证据硬答、证据召回错误、证据理解错误还是用户问题超出范围。对应措施包括补检索、改重排、要求引用证据、证据不足拒答、生成后事实校验和高风险转人工。不能只在 prompt 里写一句“不要幻觉”。

Prompt 频繁迭代会带来什么风险？

风险是版本不可追溯、修一个 case 破坏其他场景、输出格式漂移、延迟和 token 成本增加。解决方式是 prompt 版本管理、变更说明、固定回归集、灰度发布和线上监控。

badcase 数据能直接拿去训练吗？

不能直接粗暴训练。要先清洗隐私和敏感信息，确认标注质量，区分训练集、验证集和测试集，避免把错误期望或重复样本放进去；还要保留一部分历史 badcase 只做回归测试，防止评测被训练污染。