智能问数如何还原历史归属：慢变维度、追溯更正与时态关联验收

三个合理问题，不能共用一个默认归属

第一种问题是“交易发生时，华东负责的客户贡献了多少收入”。它用交易时刻选择客户区域。第二种是“今天华东负责的客户，去年贡献了多少收入”。它用当前客户组合重算历史事实。两者可能都合理，但支持的是历史责任评价与当前经营规划两种不同决策。

第三种是“上次月报发布时，我们当时知道的华东收入是多少”。这不仅需要业务有效时间，还需要记录何时进入系统、何时被更正。后来获知一项区域调整追溯生效，不应悄悄改变已经发布报告的原始证据。

智能问数的指标契约应同时声明事实日期、维度归属时点和修订口径。开票日期、收款日期与订单日期不能混用；“按交易时归属”也应注明使用最新更正后的历史，还是保留某次已发布版本。用户问题存在歧义时，系统可列出明确选项，不能由模型自行猜一个并隐藏选择。

本文限定每个客户在任一业务时刻只有一个区域归属。若业务允许联合负责或比例分摊，需要单独的关系与权重模型，不能把合法多归属当成数据重复，也不能借慢变维度替代分摊规则。

慢变维度保存的是版本，而不是更多相同客户

慢变维度通常简称 SCD，用于管理客户、员工等对象属性随时间的变化。Microsoft 的星型模型指南区分覆盖旧值的 Type 1 和保留版本的 Type 2；后者用版本标识与有效期支持历史关联。[1] 是否保留历史应按字段与业务需求决定，不是所有电话号码更正都必须生成新的经营归属版本。

构造客户 C17：版本 V1 属于华东，业务有效区间为 2026 年 1 月 1 日至 7 月 1 日之前；版本 V2 属于华北，自 7 月 1 日开始有效。客户业务键仍是 C17，但版本键 V1、V2 各自唯一。旧订单关联哪个版本，应由所选事实时间确定。

若 6 月 30 日订单金额为 100 元，7 月 1 日订单为 200 元，按交易时归属得到华东 100、华北 200；按当前归属重算则是华北 300。两种结果总额都为 300，因此仅检查总额守恒无法发现口径错误。

建议采用左闭右开的有效区间：开始时刻包含在内，结束时刻不包含。这样相邻版本在 7 月 1 日交接时只有 V2 匹配。不能用两端都包含的条件使边界事实同时匹配两版；时区、日期粒度和源系统生效时刻也必须一致。

最小维度记录包括客户业务键、唯一版本键、归属属性、业务有效起止、来源与变更依据。当前版本可用明确的开放终点表示，但空终点不等于任意缺失终点都合格。还应区分真实持续有效、缺少结束记录和已删除对象。

快照记录看到的变化，不会补回从未捕获的历史

dbt snapshots 能对可变表保存 Type 2 历史；timestamp 与 check 策略分别依赖更新时间或指定字段变化，删除处理也需要明确配置。[2] 使用前必须检查实际版本与适配器，不能仅因为字段叫 valid_from 就认定它表示业务生效时间。

例如 CRM 在 7 月 3 日才录入“7 月 1 日转区”。更新时间描述录入或修改时刻，业务生效时间是 7 月 1 日；采集系统首次看见这条变更可能更晚。把三个时钟折叠为一列，会导致历史归属或报告复现至少有一种语义丢失。

dbt 的选型文档明确，定时快照只能捕获运行时可见的值，无法恢复两次运行之间已被覆盖的中间变化。[3] 若一天内先从 A 改到 B、再改到 C，而快照只看见 A 与 C，就没有证据证明 B 的起止时间。增加频率可以缩小盲区，却不能保证捕获所有变化。

历史要求较高时，应评估源系统变更日志、CDC 或带业务有效期的事件记录，并核对断点、删除与重放完整性。若只能拿到当前表，则从可证明的时间开始保存历史，对此前区域标为未知；不能把今天的归属批量回填到过去，再称其为真实历史。

成本取舍也应明确：周期快照容易起步，但扫描与存储成本随数据量增长；完整变更链需要更强的接入与运维能力。只需当前客户清单时可保留当前视图；需要审计旧报表时，单一当前表通常无法满足。

追溯更正需要区分业务时间与记录时间

继续构造示例：系统原先认为 C17 在 7 月 1 日转入华北，8 月 5 日收到有依据的更正，实际应从 6 月 15 日生效。此时 6 月 30 日的 100 元订单，在最新更正后的交易时口径下应归华北；但 7 月已发布报表可能仍将它计入华东。

若只覆盖 V1、V2 的起止时间，就能得到新的历史解释，却无法回答旧报表为何如此。需要同时保留业务有效时间和系统记录版本：前者描述归属适用于何时，后者描述系统从何时开始采用这套解释。可使用双时态记录，也可对已发布报表保存不可变输入快照及版本清单，按复现要求选择。

查询最新更正历史时，选当前认可的记录版本，再按交易时间匹配业务区间。复现当时已知结果时，则先按报告的信息截止时刻选择那时可见的记录版本，再进行业务时间关联。两个条件不能互相替代。

修订应产生受影响客户、日期范围、事实数量和分组金额变化清单，并记录批准依据。已发布结果是否重述由业务规则决定；不能让数据管道静默覆盖对外报表。若事实表已固化维度版本键，还须按受影响范围重建映射或保留报告版本，不能只改维度就认为所有报表已一致。

双时态会增加存储、查询与解释成本。若需求只是近期经营分析而不要求复现每次认知变化，保留批准后的业务历史与关键报告快照可能足够。应先写清需要回答的问题，再选择复杂度。

让每个事实匹配唯一版本，异常要保留下来

实施时先按指标的状态、币种、权限与事实日期筛选事实；再选择归属模式及修订截止；最后用客户业务键与有效时间寻找维度版本。输出关联前，应按事实唯一标识统计匹配数量：一个是正常候选，零个表示历史缺口，多个表示区间冲突或未定义的多归属。

零匹配不能通过内连接悄悄丢弃，可进入明确的未知归属组或阻止认证结果，具体取决于业务要求。多匹配不能靠任选一行或取最新一行掩盖，应保留冲突记录并停止相关认证路径。若采用未知组，对账总额应包含它，同时单列其金额与原因。

PostgreSQL 18 文档展示了范围排斥约束，可对同一标识防止有效区间重叠；相关能力需要按数据库配置与字段类型实施。[4] 这只能约束某类冲突，不会自动保证区间连续、来源正确或业务生效时间可信。双时态实现还要按记录版本限定约束，避免把合法的历史修订误当重叠。

保存事实到维度版本的映射可以降低高频查询成本，但要求处理晚到事实与追溯更正。查询时做时间关联更灵活，却增加计算负担。两种方式都应记录数据截止与映射版本，不能让缓存继续返回旧分组而页面显示新口径。

历史版本引起的行放大，可结合多表关联的基数与金额守恒验收检查；但本篇还要求逐事实归属和分组预期，因为错误归属完全可能保持总额不变。

用边界、迟到与修订反例验收智能问数

第一组保留前述两笔订单，分别问交易时归属与当前归属，核对华东、华北各自金额，而非只看 300 元总额。加入恰好落在生效边界的订单，确保只贡献一次；再把客户转区时间改为日内时刻，检查日期截断是否误归属。

第二组制造有效区间空洞与重叠。要求输出明确未知或冲突状态，并保留事实编号，不能通过补当前值或任意去重让测试变绿。另加入晚到订单：今天到达的旧交易仍应按选定历史时间口径匹配，而不是按入库日选择区域。

第三组运行追溯更正。最新更正视图应按批准规则变化；冻结旧报告应保持可复现；两者差额应能逐事实解释。若客户删除或合并，检查历史身份映射与保存政策，不能因当前主数据不存在就自动抹去历史事实。

第四组检查语言到口径的映射。“当时归属”“按现有组织重算”“复现上次月报”应进入不同受控路径。含糊问题应显示所用默认口径或请求确认，答案至少带出指标、归属模式、事实期间、修订截止与未知金额。

验收指标可包括零匹配事实数、多匹配事实数、受影响金额、分组差额、修订后待刷新映射数和旧报告复现差异。各指标都要固定范围与分母；业务要求唯一归属时，多匹配应作为失败而非被总体准确率稀释。没有已知历史真值的期间，应报告未验证。

最终交付是维度版本契约、变更依据、受控关联路径、异常明细和反例结果。模型负责理解用户问的是哪一种历史，数据层负责证明这一种历史有证据、有唯一映射，并能解释为什么本次结果与上次不同。