用户反馈闭环
1. 定义与边界
用户反馈闭环是把用户评价、人工接管、投诉、二次联系和业务结果回流到 trace、失败案例库、评测集和产品改进中的机制。它不是简单收集点赞点踩。
2. 为什么重要
离线评测不可能覆盖所有真实问题。用户反馈能发现长尾表达、业务规则变化、体验问题和假成功。没有闭环，线上错误只会变成一次性噪声。
3. 核心机制
反馈类型：
| 类型 | 价值 |
|---|---|
| 显式反馈 | 点赞、点踩、评分、文字说明 |
| 隐式反馈 | 重新提问、放弃、转人工、二次联系 |
| 业务结果 | 工单重开、退款失败、代码测试失败 |
| 人工标注 | 客服或专家给出的原因标签 |
4. 工程实现
{
"feedback_id": "fb_001",
"trace_id": "tr_001",
"user_hash": "u_hash",
"feedback_type": "thumbs_down",
"free_text": "答非所问，没有处理退款",
"business_outcome": "ticket_reopened",
"triage_label": "task_not_completed",
"added_to_regression": true
}
失败标签建议：
- misunderstanding：理解用户目标失败。
- tool_error：工具调用或返回失败。
- policy_error：业务规则或权限判断失败。
- unsafe：安全策略失败。
- latency：耗时过长。
- ux：交互体验问题。
5. 生产实践
- 反馈入口必须能绑定 trace_id，否则只能做粗粒度分析。
- 对点踩样本抽样复核，避免把用户不满意都归因到模型。
- 将高频反馈转成产品改进、工具改进或评测样本。
- 对用户自由文本进行脱敏后再进入分析系统。
6. 常见反模式
- 只统计点赞率，不分析失败原因。
- 用户反馈无法关联具体版本和 trace。
- 反馈只给产品看，没有进入工程回归。
- 把所有负反馈都归因给提示词。
7. 评测方法
| 指标 | 用途 |
|---|---|
| Feedback Link Rate | 反馈能关联 trace 的比例 |
| Negative Feedback Triage SLA | 负反馈完成分类的时间 |
| Regression Conversion Rate | 负反馈转回归样本比例 |
| Repeat Issue Rate | 同类问题再次出现比例 |
| Feedback Agreement | 用户反馈与人工评审一致性 |
8. 安全与治理
用户反馈可能包含隐私和攻击样本。进入分析和评测前要脱敏、权限隔离，并保留用户删除或合规处理路径。
9. 权威资料
- LangSmith feedback and annotation docs: https://docs.langchain.com/langsmith/observability （核对日期：2026-05-09）
- OpenAI Evals guide: https://platform.openai.com/docs/guides/evals （核对日期：2026-05-09）
- NIST AI RMF: https://www.nist.gov/itl/ai-risk-management-framework （核对日期：2026-05-09）
10. 二次精修：反馈事件结构
用户反馈要能从“有人点了差评”变成可诊断、可评测、可回归的工程信号。
{
"feedback_id": "fb_123",
"run_id": "run_456",
"trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
"user_id_hash": "sha256:abc",
"feedback_type": "negative",
"reason_code": "wrong_tool_result",
"free_text_ref": "secure_blob://feedback/fb_123",
"agent_version": "1.8.2",
"prompt_version": "refund.system@2026-05-09.3",
"triage_status": "needs_review",
"created_at": "2026-05-09T10:30:00Z"
}
| 反馈来源 | 优点 | 风险 |
|---|---|---|
| 点赞/差评 | 成本低 | 偏置大 |
| 投诉/工单 | 信号强 | 滞后 |
| 人工质检 | 标注质量高 | 成本高 |
| 行为信号 | 覆盖广 | 解释不唯一 |
| 安全事件 | 风险明确 | 需要保密 |
11. 闭环流程
12. 分诊标签
| 标签 | 含义 | 后续动作 |
|---|---|---|
wrong_answer | 最终答案错 | 检查证据和 judge |
wrong_tool | 工具选择或参数错 | 补 tool eval |
missing_context | 上下文缺失 | 修会话/记忆 |
unsafe | 越权、泄露、注入 | 安全响应 |
too_slow | 延迟不可接受 | 查工具和队列 |
too_expensive | 成本异常 | 查 token 和重试 |
13. 指标与治理
| 指标 | 用途 |
|---|---|
| Feedback Link Rate | 反馈能关联 trace 的比例 |
| Triage SLA | 分诊及时性 |
| Fix Conversion Rate | 反馈转成修复的比例 |
| Regression Added Rate | 反馈进入评测集的比例 |
| Repeat Complaint Rate | 是否复发 |
| PII Redaction Failure | 反馈文本泄露风险 |
治理要求：自由文本反馈默认是敏感数据；进入训练、评测或报告前必须脱敏。用户删除请求要覆盖反馈记录和派生样本。安全反馈不得进入普通产品分析池。
14. 补充权威资料
- LangSmith annotation queues: https://docs.langchain.com/langsmith/annotation-queues （核对日期：2026-05-09）
- LangSmith feedback: https://docs.langchain.com/langsmith/observability （核对日期：2026-05-09）
15. 主控验收清单
- 是否每条反馈能关联 run_id 和 trace_id。
- 是否反馈有 reason_code，而不只是自由文本。
- 是否有分诊 SLA 和 owner。
- 是否能区分产品体验、模型错误、工具错误、安全问题。
- 是否将高风险反馈进入安全流程。
- 是否对自由文本脱敏和访问控制。
- 是否把有效反馈转成回归样本。
- 是否跟踪修复后复发率。
- 是否校准用户反馈和人工质检之间的偏差。
- 是否支持用户删除请求级联反馈数据。
- 是否防止攻击样本污染普通训练数据。
- 是否按版本聚合负反馈。
- 是否有反馈到发布决策的闭环报告。
- 是否把低置信反馈进入 annotation queue。
- 是否保留反馈处理历史和决策理由。
- 是否把投诉和差评分开统计。
- 是否对重复反馈做去重。
- 是否记录用户是否重新提问或转人工。
- 是否能按任务类型聚合反馈。
- 是否对安全相关反馈设置更长保留期。
- 是否明确哪些反馈不能用于训练。
- 是否把反馈样本的来源写入 eval dataset。
- 是否对人工标注者做一致性检查。
- 是否定期抽查“已修复”反馈是否复发。
- 是否在重大版本发布后重点观察负反馈切片。