ChatBI 回答错了一个关键数字，事后怎么追溯和复盘？
面试怎么回答
前提是每次问答都留痕：原始问题和上下文、改写结果、检索到的指标定义、生成的 SQL 和参数、查询原始结果、最终回答，以及模型、提示词和语义层版本。拿到记录后按链路定位：是口径理解错、用错表、SQL 逻辑错、数据本身有问题，还是查询对了但回答时转述错了。处理上先通知使用者更正，再针对根因修复：语义层补定义和同义词，临时表降权，问题加入评测集回归，回答里的数字由程序从查询结果填入。产品上展示口径、来源和时间范围，非标准口径标注仅供参考，重要场景要和正式报表核对。最后按数据事故的方式复盘，并统计同类错误的发生率。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
业务负责人在周会上引用了 ChatBI 给出的「上月复购率 32%」，后来发现真实值是 26%。老板问：怎么错的？以后怎么避免？面试官问这题，想看你有没有为 AI 回答设计可追溯的链路，以及怎么像处理数据事故一样处理 AI 的错误。
先能追溯：每个回答都要留痕
要回答「怎么错的」，前提是每次问答记录了完整的链路：
- 用户、时间、原始问题、对话上下文；
- 问题改写和意图识别的结果；
- 检索到的元数据、指标定义；
- 生成的 SQL 或调用的指标接口及参数；
- 查询返回的原始结果；
- 最终的回答文本；
- 模型版本、提示词版本、语义层版本。
没有这些记录，就只能靠猜。
定位错误发生在哪一环
拿到记录后，按链路逐段检查：
- 理解错了：「复购率」被理解成「重复下单用户占比」，而公司口径是「30 天内再次购买的用户占首购用户的比例」；
- 找错指标或表：用了一张未认证的临时表；
- SQL 逻辑错：时间范围、过滤条件、分母错误；
- 数据本身有问题：表在那天的数据延迟或者有质量问题；
- 回答呈现错：查询结果是对的，但模型在生成回答时写错了数字或单位。
修复和预防
- 立即：通知使用了这个数字的人，给出正确值和原因；
- 针对根因：
- 口径理解错：在语义层补充指标的定义和同义词，「复购率」只能映射到标准指标；
- 用错表：给临时表降权或排除，核心指标只能走认证的数据；
- SQL 错：把这个问题加入评测集，对相关场景回归；
- 呈现错：回答中的数字必须由程序从查询结果填入，而不是让模型「转述」；
- 产品设计：
- 回答里展示使用的指标口径、数据来源和时间范围，让用户能自己判断；
- 对没有被认证口径覆盖的问题，标注「非标准口径，仅供参考」；
- 重要场景（经营会议、对外汇报）的数字需要从正式报表核对。
复盘的形式
像数据事故一样复盘：时间线、影响范围、根因、改进项（有负责人和截止时间）。同时统计一段时间内类似错误的发生率，判断是个例还是系统性问题。