低成本检查全部，只调查真正需要的少数

设想一批 10,000 条联系人更新。你可以把每条记录送给模型，让它重新判断字段。这样就会把一次映射决策变成 10,000 次重复决策。

先问一个成本更低的问题：这条记录是否符合已批准映射的已知条件？用代码检查字段是否存在、数据类型、模式版本以及明确的同意要求。把失败或仍有歧义的记录交给范围更窄的审核。

这是设计示例，不是 Tajo 的基准测试。真正值得关注的数字不是初筛放行了多少记录，而是它错误地放行了多少重要问题。

一场关于专业领域工作流的讨论先广泛区分正常与异常，再深入分析标记出的案例。该领域与营销数据的风险和证据不同。来源只支持分阶段决策这一点，并未证明首个算法的成本或确定性。在集成中，成本较低的确定性检查可以覆盖已知条件，再把不确定的案例送去仔细审核。

初筛应解决常规案例

好的初筛会提出代码能凭现有证据回答的问题。“源字段存在吗？”是一个；“这个值符合目标系统声明的类型吗？”是另一个；“这是映射获批时使用的模式版本吗？”是第三个。

规则可以应用于每一行，无需逐行创造新解释，还能说明原因。被拒绝的一行可以明确指出：目标系统的 birthday 字段要求日期，源系统却提供了自由文本。这比“AI 置信度低”有用。

Tajo 的Brevo 连接器指南解释了目标系统的属性定义为何重要。连接器即使收到成功的 HTTP 响应，接收系统仍可能忽略未声明的属性。写入前检查已声明字段能抓到一类错误，之后读回能抓到另一类。这两者都不能与模型觉得某个联系人“看起来没问题”混为一谈。

目标不是消除判断，而是把判断留给真正需要判断的问题。

1. 新的同步批次

2. 首先

   检查已知规则

   • 身份、字段类型和账户范围
3. 然后

   确定明确结果

   • 放行常规记录，保留已知失败
4. 仅在需要时

   审核未解决案例

   • 检查规则无法确定的证据

5. 已检查的结果或明确保留

昂贵的审核应收到正确的案例

假设示例中的 10,000 条记录有 9,800 条通过初筛，另外 200 条接受更细致的检查。这听起来高效。但在抽查那 9,800 条并检查另外 200 条的结果前，无法据此判断正确性。

初筛有两类错误：把常规案例标记出来，白白耗费审核时间；更严重的是放行本应停止的案例。哪种错误代价更大，取决于工作流。缺少可选标签和缺少营销邮件发送许可，不该使用同一道阈值。

合理的质疑是：“如果模型能理解每条记录，为什么信任脆弱的规则？”因为反复询问模型并不会自动让普通记录更正确。规则的弱点清晰可见：源系统或目标系统的契约改变后，前提会过时。因此要监控契约并抽查放行案例，而不是把所有稳定检查替换成没有界限的判断。

升级处理也可以比全面人工审核更窄。已知供应商错误可能只需按文档修复；真正新颖的字段含义可能需要代理提出映射；同意状态不明则可能需要负责人决定。初筛应将每个案例交给能解决它的最小权限层级。

如何集成多个业务工具先确定权威来源和触发条件，再选择工具。这些决定了哪些异常值得关注。一个下游流程不用的字段出现不一致，也许可以等待；用于选择营销受众的字段出现不一致，则不能等待。

衡量漏检率，而不只看节省

分阶段系统可以生成漂亮的图表：大量案例低成本处理，少量案例继续审核。但图表仍不完整。还要衡量初筛放行的案例中，有多少在后续目标系统检查或独立抽样审核时失败。

指标要与实际工作相连。如果目标是保持联系人一致，就检查目标系统的联系人状态；如果目标是维持受众，就检查谁被纳入、谁被排除。没有分母和下游影响的错误数，容易让人庆祝，却难以信任。

实际试验可以从小处开始。保存一组经过审核的常规和异常记录，对其运行低成本规则，逐一检查漏掉的异常。然后在实时流量上影子运行，不允许它批准新的行为。只有理解漏检情况后，才让规则决定哪些案例可以跳过深入审核。

反向 ETL 指南介绍了这类工作背后的重复数据移动。分流问题紧邻流水线：哪些观察能告诉我们，原本稳定的规则已不再稳定？

把仔细审核用在广泛检查无法确定的地方。