AI 应用的用户反馈数据怎么采集，怎么用起来？
面试怎么回答
反馈分两类：显式反馈是点赞点踩、原因选择、评分和用户编辑，信号明确但量少有偏差；隐式反馈从行为推断，比如换说法重问、重新生成、复制导出、采纳 SQL 并执行、中途放弃或转人工、事后手工修改，量大但有噪声。建模上把反馈和调用链路关联：会话表、轮次表记录问题、回答、模型提示词版本、检索文档和工具调用，反馈事实表关联到具体轮次，再派生各场景、各版本的负评率、重问率、采纳率和转人工率。用法上监控版本对比、定位负评集中的问题类型、把失败案例加入评测集、修正知识库、把编辑和被采纳的回答作为训练数据来源。采集时入口简单、原因具体，注意隐私和授权，统一隐式反馈的判断规则。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
AI 助手上线后，大家都想知道「用户觉得好不好用」。产品加了点赞点踩按钮，三个月后发现：只有不到 2% 的回答被评价，而且点踩的原因五花八门，没法用。面试官问这题，想看你能不能设计一套有用的反馈数据体系，这正是数据团队的强项。
显式反馈：用户主动给的
- 点赞 / 点踩；
- 点踩后的原因选择（答错了、没回答问题、太长、格式不好、有安全问题）和文字说明；
- 评分；
- 对回答的编辑、纠正。
特点：信号明确，但量少、有偏差（不满意的用户更愿意反馈，或者只有极端情况才反馈）。
隐式反馈：从行为中推断
- 追问和重问：用户换个说法再问一遍，可能说明上一次没答好；
- 重新生成：点击「重新生成」；
- 复制、导出、采纳：复制了回答、导出了报表、采纳了 SQL 建议并执行；
- 会话结束方式：问题解决后自然结束，还是中途放弃、转人工；
- 后续行为：根据 AI 给出的 SQL，用户是否又手工修改了。
特点：量大、覆盖全，但含义需要推断，有噪声。
数据建模
把反馈和 AI 的调用链路关联起来：
- 会话表、轮次表：每轮的问题、回答、使用的模型和提示词版本、检索到的文档、调用的工具；
- 反馈事实表：反馈类型（显式/隐式）、具体动作、原因、时间，关联到具体轮次；
- 派生指标：每个场景、每个版本的负评率、重问率、采纳率、转人工率。
这样才能回答：「新版本的提示词上线后，SQL 采纳率有没有提升？」「哪类问题的重问率最高？」
怎么用起来
- 监控：按版本、场景看指标趋势，新版本上线后对比；
- 找问题：负评和重问集中的问题类型，优先分析；
- 扩充评测集：典型的失败案例修正后加入评测集；
- 改进数据：负评原因指向检索问题时，补充或修正知识库；
- 训练数据：编辑后的回答、被采纳的回答，可以作为微调或偏好数据的来源（注意隐私和授权）。
采集时注意
- 反馈入口简单，原因选项少而具体；
- 隐私：对话内容可能包含敏感信息，采集和使用要符合用户协议，存储要脱敏和控制权限；
- 隐式反馈的定义要统一，比如「重问」的判断规则写清楚，否则指标不可比。