单次检测只出基线，验收靠同批题、同参数、同平台的三次记录。这件事说起来一句话，工程上最难的是"落库"：三次采样产生的原始回答、引用链接、位次状态分散在时间轴上，没有一套合理的数据结构，验收就只能靠人工翻记录。本文给出一份可直接套用的落库设计与告警阈值方案，以健身场馆这类本地服务业为背景——它的特殊性在于：会员问 AI 的入口正被产品化 AI（训练计划、虚拟前台）快速接管，场馆的可及性窗口比一般行业更窄。
一、先想清楚验收要回答的四个问题
落库结构由问题倒推。验收环节真正要回答的是：
- 同一道题，位次变了多少？（配对差值）
- 有没有场馆从"在名单里"掉到"不在"？（状态转移，最危险信号）
- AI 引用我的页面构成变了吗？（信源结构迁移）
- 变化是不是随机的？（显著性）
国际上行业 SaaS 已经把"对比"做成了默认能力：2026 年 9 月，Mindbody、ClassPass 母公司 Playlist 发布 AI Insights，用超 11 万家场馆的匿名化数据给经营者做同品类、同地区的基准对比，并预测流失客户，宣称使用该功能的企业月均 GMV 高约 1400 美元。同行基准正在从咨询话术变成软件自带功能——这也意味着自建数据结构的场馆，至少要在自己的三次记录里回答"我相对上次的我，变了多少"。
二、三层落库结构
raw_answers 原始回答层（不可变，append-only）
│
snapshots 采样快照层（逐题×平台×批次的结构化抽取）
│
retest_views 验收视图层（配对差值、状态转移、信源迁移）
原则 1：原始层 append-only。 每条 AI 回答原文、响应 ID、时间戳、参数指纹全部保留，任何下游统计都能退回原文复核。禁止在原始层做更新——发现错抽就新增一条修正记录，用 view 取最新。
原则 2：快照层带唯一键。 (snap_id, qid, platform, segment) 唯一，重复插入即管线故障告警，不做 upsert——静默合并会掩盖采样重复。
原则 3：视图层只算不改。 差值、转移、迁移全部用 SQL 视图实现，同一份底层数据，报表口径永远可复现。
三、告警阈值设计
验收不是只出报表，in_out（提及变消失）这类信号要主动告警。阈值参考：
| 信号 | 阈值 | 动作 |
|---|---|---|
| in_out 占比 | > 10%（同一批次同平台） | P0 告警，逐题人工复核 |
| 配对改善率 | < 0 且样本 ≥15 对 | 写入"未见改善"，触发方案复盘 |
| 参数指纹不一致 | 任何一条 | 管线中止，禁止出报告 |
| 采样响应重复 | 同响应 ID 出现 2 次 | 管线故障，本轮作废 |
| 引用信源类迁移 | 某一类占比变化 > 15pp | 标注，作为内容策略输入 |
阈值不要拍脑袋定死：10% 的 in_out 在 20 题样本里就是 2 道，足以说明环境异动；但季节切换期（健身的 5 月/11 月）问法分布漂移本身会制造伪信号，阈值应按季节层/核心层分开校准。
四、一个容易漏的字段：采样窗口
同一天上午与深夜，部分平台的答案分布不同。sampled_at 不能只存日期，要连同窗口定义一起进参数指纹：
def window_of(ts) -> str:
h = ts.hour
if 8 <= h < 12: return "AM"
if 14 <= h < 18: return "PM"
if 19 <= h < 23: return "EVE"
return "OTHER" # OTHER 窗口采样不参与配对
基线与复测窗口不一致的配对，宁可不比，也不要混进均值。
五、两个踩过的坑
坑 1：季节层混进核心层。 复测时顺手多测了几道当季热门题，差值统计没分层，"改善率"被季节题拉高 9 个点。修法：快照层加 tier 字段，视图按层过滤，核心层才有资格进配对母本。
坑 2：引用去重没做域名归并。 一条回答挂 8 个引用链接，其中 3 个是同一本地媒体的子路径，直接计数会把信源结构算歪。修法：落库前按域名归并，同类信源合并为一条并保留子链接列表。
六、边界
这套结构验的是信息环境的变化，不构成对"值不值得续约"的最终判断——转化数据、竞品动作、平台迭代都在它之外。数据结构做得再好，也别忘了三次记录之外的那一步：把逐题原始回答人工抽检一遍，尤其是触发 P0 告警的样本。
你们的落库结构里，原始回答是存全量还是只存摘要？评论区聊聊。
