从 Trace、Feedback、Triage、Labeling、Regression、Prompt / RAG / Fine-tuning / Guardrail 改动到灰度发布，理解 AI 系统怎样从失败样本里持续变好
| 环节 | 它回答什么 | 缺失时会怎样 | 关键产物 |
|---|---|---|---|
| Trace | 这次请求到底经历了什么 | 只能说“模型答错了”，无法定位是哪层坏 | Prompt 版本、检索命中、工具调用、模型输出、后处理 |
| Feedback | 哪里被用户、业务或安全系统认为有问题 | 线上失败无法沉淀，只在聊天记录里消失 | 点踩、人工审核、用户纠错、投诉、业务失败事件 |
| Triage | 问题应该归因到模型、数据、检索、工具还是产品 | 团队不断改 Prompt，却解决不了真实根因 | 错误分类、严重程度、责任层、优先级 |
| Dataset | 这个坏例怎样变成可复用资产 | 同类问题反复出现，每次都像第一次遇到 | 回归集、边界集、红队集、训练候选集 |
| Change | 应该改哪一层 | 把所有问题都误判为“模型不够强” | Prompt 改动、RAG 调整、工具修复、护栏规则、微调数据 |
| Release | 改动是否真的变好且没有副作用 | 修了一个坏例，引入十个回归 | 离线对比、灰度实验、回滚记录、复盘结论 |
AI 反馈闭环不是“收集更多用户数据”，而是把失败变成可定位、可评测、可改动、可回归的工程资产。
| 来源 | 信号是什么 | 优点 | 偏差 |
|---|---|---|---|
| 用户显式反馈 | 点赞、点踩、纠错、重新提问、投诉 | 贴近真实体验 | 用户只反馈一小部分，且情绪和期望会影响判断 |
| 业务结果 | 任务完成率、转化、人工接管、工单关闭、撤销操作 | 更接近真实价值 | 归因复杂，常有滞后和外部变量 |
| 人工审核 | 质检标签、风险等级、修正答案、拒答复核 | 质量高，适合定标 | 成本高，口径需要训练和复核 |
| 自动评测 | Judge 分、规则校验、schema 检查、引用一致性 | 可规模化，适合高频监控 | 评分器会漂移，也会被系统学会讨好 |
| 系统指标 | 延迟、成本、超时、工具失败、检索空召回、重试次数 | 稳定客观，适合告警 | 只能说明链路异常，不一定说明答案质量 |
| 红队与安全演练 | 越狱、提示注入、越权工具、隐私泄露、误拒误放 | 主动暴露高风险边界 | 样本分布和真实用户不完全一致 |
反馈本身也是有噪声的代理指标。用户点踩、Judge 低分、业务转化下降都只是线索，不是自动改动依据。先把反馈放回 trace 和任务语境里看，才能避免被局部噪声带偏。
| 错误类型 | 常见根因 | 优先改哪层 | 不要先做什么 |
|---|---|---|---|
| 答案事实错 | 知识过期、检索漏召回、模型幻觉、证据冲突 | RAG 语料、检索评测、引用约束、不可回答策略 | 直接微调一批正确答案 |
| 格式不稳定 | Prompt 模糊、schema 太复杂、采样随机性高 | 结构化输出、解析修复、格式回归集 | 换更大模型赌稳定 |
| 工具调用错 | 工具描述不清、参数约束弱、权限状态不可见 | 工具 schema、执行协议、权限检查、失败恢复 | 只在系统提示里加一句“仔细调用工具” |
| 拒答误伤 | 安全策略口径粗、上下文缺少用途判断 | 安全切片、误拒样本、策略边界和人工升级 | 简单降低所有拒答阈值 |
| 回答迎合 | 偏好数据奖励顺从，缺少纠错样本 | 偏好数据、事实校验、澄清策略 | 只用用户满意度当唯一指标 |
| 成本过高 | 上下文膨胀、重试过多、大模型路由过宽 | 模型路由、缓存、上下文压缩、预算阈值 | 只限制输出长度 |
一个坏例至少要回答三件事：错在哪里、哪一层导致的、修复后用什么回归样本证明它不会再回来。
| 样本去向 | 适合什么问题 | 如何使用 | 风险 |
|---|---|---|---|
| 回归集 | 已经修过、不能复发的问题 | 每次模型、Prompt、RAG 或工具改动前后跑 | 过度围绕固定坏例调参 |
| 红队集 | 安全、隐私、越权、注入、误拒误放 | 作为上线闸门和安全回归 | 如果只看攻击成功率，可能忽略正常可用性 |
| 偏好集 | 多个答案都可行但质量不同 | 用于 DPO、Judge 校准或人工评审训练 | 偏好口径漂移会被模型放大 |
| SFT 候选集 | 稳定格式、任务协议、标准流程 | 用于模型定制或协议稳定化 | 把暂时性产品流程写进模型权重 |
| 知识更新队列 | 知识过期、资料缺失、权限材料不全 | 进入文档治理、RAG 索引和引用检查 | 误把知识问题当模型问题 |
| 阶段 ID | 由谁生成 | 必须继承 | 下一跳 |
|---|---|---|---|
| feedback_item_id | 用户反馈、人工审核、告警或事故预检 | request_id、feature、risk_tier、user_signal、review_label | triage_ticket_id |
| triage_ticket_id | 问题分流 owner | error_taxonomy、root_cause_layer、severity、owner、due_date | eval_case_id、artifact_change_id 或 incident_id |
| eval_case_id | 评测 / 数据团队 | 输入、期望行为、rubric、脱敏状态、来源 trace、风险标签 | eval_run_id、regression_slice_id |
| artifact_change_id | 应用、RAG、工具、安全或模型 owner | 被修复的错误类型、目标 artifact、变更说明、回滚目标 | change_id、release_gate_id |
| release_gate_id | 发布闸门 | 修复前后评测结果、灰度范围、停止条件、风险豁免 | canary_cohort_id、fixed_version |
| fixed_version | 发布 / 资产登记系统 | 修复资产版本、回归通过证据、线上验证指标 | 关闭反馈项，保留为长期回归样本 |
一个坏例真正闭环，必须能看到它从 feedback_item_id 被分流、被转成 eval_case_id、触发了哪个 artifact_change_id、通过哪个 release_gate_id 上线，并在 fixed_version 里验证没有复发。
| 资产化节点 | 必须记录的字段 | 避免什么问题 |
|---|---|---|
| 脱敏与授权 | privacy_review_id、redaction_state、consent_scope、retention_policy | 把用户反馈直接塞进训练或评测，造成隐私、合规和保留周期风险 |
| 样本归类 | asset_candidate_type、error_label、expected_behavior、risk_label、owner | 所有坏例都被误送去微调，而忽略 RAG、工具、Prompt 或产品修复 |
| 数据生产 | label_task_id、synthetic_variant_id、gold_case_flag、negative_case_pair | 只保存失败输入，不保存期望行为、反例和判断口径 |
| 资产落库 | dataset_version、eval_set_version、artifact_registry_id、lineage_trace | 修复样本散落在表格和工单里，无法进入可复现流水线 |
| 长期回归 | regression_suite_id、recurrence_count、fixed_version、reopen_condition | 同类问题反复修、反复坏，却没有成为长期闸门 |
| 改动路径 | 适合什么 | 验证重点 | 相邻页面 |
|---|---|---|---|
| Prompt / 上下文 | 指令不清、格式约束弱、角色边界不稳 | 格式合法率、任务完成率、回归坏例 | Prompt / 上下文 |
| RAG / 知识库 | 事实错、引用错、内部知识缺失 | 召回率、引用忠实度、不可回答识别 | RAG / 知识检索 |
| 工具 / Agent 协议 | 工具选错、参数错、权限错、执行失败 | 工具选择准确率、参数合法率、端到端成功率 | Tool Calling |
| 安全护栏 | 越权、注入、隐私、危险操作、误拒误放 | 攻击成功率、误拒率、人工升级率 | AI 安全 / 护栏 |
| 微调 / 偏好优化 | 长期稳定的任务风格、协议和偏好问题 | 训练收益、通用能力回归、安全边界 | 微调 / 对齐 |
| 产品交互 | 用户目标不清、确认不足、反馈入口缺失 | 澄清率、撤销率、人工接管率、用户理解成本 | AI 产品 / UX |
同一个坏例可能表面上像模型错误，但真实根因是检索漏召回、工具权限不清、产品没有让用户确认，或评测指标把系统带偏。成熟的反馈闭环会先做问题分流，而不是直接把所有坏例丢进训练集。
| 闸门 | 检查什么 | 失败时动作 | 为什么必要 |
|---|---|---|---|
| 质量回归 | 核心任务、历史坏例、关键人群是否退化 | 阻止发布或回到误差分析 | 防止修小坏例破坏主能力 |
| 安全回归 | 越狱、注入、隐私、误拒误放、越权工具 | 补护栏、降级能力或人工升级 | AI 改动常常有安全副作用 |
| 成本回归 | token、工具调用次数、重试率、模型路由 | 改路由、加缓存、压上下文或回滚 | 质量变好但成本失控也不能算成功 |
| 线上灰度 | 真实流量里的完成率、投诉、接管、延迟 | 分人群回滚或继续小流量观察 | 离线 Eval 永远不能完全代表线上 |
| 复盘归档 | 改了什么、为什么改、用什么证据证明有效 | 补齐记录后再扩大影响面 | 让未来团队能理解这次改动 |
如果没有上线闸门，反馈闭环会变成“哪里痛改哪里”的局部优化。AI 系统特别容易出现修复某类坏例后，另一类任务、安全边界或成本指标悄悄退化。
| 角色 | 负责什么 | 关键产物 |
|---|---|---|
| 产品 / 业务 | 定义任务成功、用户反馈入口、人工接管和业务风险 | 任务定义、成功标准、用户反馈标签 |
| AI 应用工程 | 定位链路问题，改 Prompt、RAG、工具和编排逻辑 | Trace 分析、修复 PR、回归结果 |
| 数据 / 标注团队 | 把坏例变成可训练、可评测、可复核的数据 | 标注规范、样本集、rubric、质量报告 |
| 评测 / LLMOps | 维护回归集、Judge、灰度实验和可观测面板 | Eval 报告、发布闸门、指标监控 |
| 安全 / 合规 | 维护红队样本、策略边界、审计和人工升级 | 风险标签、安全回归、审计记录 |
| 平台 / Infra | 保障模型路由、日志、权限、成本、回滚和版本治理 | 网关策略、版本快照、成本归因、回滚机制 |
坏例来自用户和生产现场，修复可能落在数据、模型、产品、工具、检索或安全层。没有跨团队责任分工，反馈系统很容易变成“收集了很多问题，但没人真正闭环”。
如果说模型评测页解释“怎样判断系统有没有变好”，LLMOps 页解释“线上怎样看见系统行为”，评测到发布闸门页解释“评测证据怎样变成上线或回滚决策”，发布变更页解释“改动怎样灰度、回滚和审计”，AI 数据工程页解释“数据资产怎样生产和治理”，那么本页解释这些东西怎样串成持续改进闭环。它是从一次请求失败走向长期系统变稳的桥。