通用与垂直：BOUND 原则的诞生

这是「从炼丹到通用」系列的第三篇。

第一篇复盘了 2024 年的 DGI 项目——一个深度图学习的工程实践。第二篇分析了 LLM 崛起对 DGI 项目的冲击——哪些被颠覆，哪些幸存。这篇要回答的问题是：从 DGI 的”硬编码规则”到 BOUND 的”概率性边界”，认知是怎么进化的？通用能力和垂直约束，到底该怎么融合？

不是”通用模型万能”，也不是”垂直模型不可替代”。是两者如何在工程层面找到各自的位置。

注：BOUND（Boundary-Orchestrate-Validate-Narrow-Diversify）是笔者在《从控制到引导：AI 时代的架构师进化论》（2026-06-06）中提出的概率性系统治理框架。本文是其工程落地的延伸。

一、从”模型中心”到”系统中心”

2024 年的 DGI 项目，核心思路是**“模型中心”**——让模型尽可能强大，用工程手段补偿模型的不足。模型不理解语义？加标注。模型不可解释？加决策树。模型零样本能力差？加反馈闭环。整个 pipeline 的设计逻辑是：模型是主角，工程是配角。

2026 年的认知是**“系统中心”**——模型只是系统的一个组件，系统的可靠性不取决于任何一个组件的完美，而取决于组件之间的边界和衔接。DGI 擅长实时嵌入，LLM 擅长语义理解，规则引擎擅长确定性校验——每个组件做自己擅长的事，边界清晰，衔接可控，系统就可靠。

这个转变不是技术选择，是哲学选择。2024 年我们相信”更好的模型能解决更多问题”，2026 年我们知道”更好的边界能让更多模型共存”。

二、BOUND 原则在 DGI 场景下的落地

BOUND 五个字母，每一个都对应 DGI 项目里的一个具体教训。这些教训在第一篇《炼丹笔记》中已经详细展开，这里不再重复技术细节，只聚焦BOUND 原则如何在 DGI 场景下具体落地——不是通用理论，是垂直实践。

B - Boundary：DGI 嵌入服务的确定性契约

DGI 的嵌入输出是概率性的——同样的图结构，模型版本不同，嵌入可能不同。但下游组件（向量搜索、聚类、规则引擎）需要确定性输入。

DGI 场景下的契约设计：

契约维度	DGI 具体承诺	违约时系统响应
Schema	输出 `embedding`（512 维 float32 数组）、`node_id`、`timestamp`	Gateway 校验失败 → 返回空嵌入 + 告警，下游用空嵌入走降级路径
延迟	99.9% 分位 < 100ms（A100 上单图推理）	超时 → 熔断，后续请求直接返回”无法判断”，转人工队列
版本	生产环境锁定版本，输出包含 `model_version`	版本不匹配 → 拒绝服务，强制回滚到锁定版本
审计	每次推理记录输入图摘要、输出嵌入、耗时、版本	轨迹缺失 → CI 拦截，禁止部署

关键洞察：DGI 的嵌入是概率性的，但嵌入服务的接口行为是确定性的。下游不需要知道 DGI 内部用了什么 GCN 结构，只需要知道”调用这个接口，100ms 内要么拿到 512 维嵌入，要么拿到空嵌入 + 告警”。

O - Orchestrate：DGI 训练流程的状态机约束

DGI 的日级专家模型训练是概率性流程——每天的数据分布不同，训练收敛速度不同，模型质量波动。但整个训练 pipeline 的编排必须是确定性的。

DGI 场景下的状态机设计：

[数据抽取] → [图构建] → [DGI 训练] → [嵌入验证] → [模型发布]
    ↓            ↓           ↓            ↓            ↓
  超时1h      超时30min    超时2h      嵌入区分度    人工审批
  告警+跳过   告警+跳过    告警+重试    < 0.6 拒绝   未通过拒绝

关键洞察：DGI 训练本身是不可控的（数据分布漂移、收敛不稳定），但训练流程的编排是可控的。第 15 天的数据有问题？状态机自动跳过，不影响第 16 天。训练发散？自动重试，3 次失败转人工。嵌入区分度不足？拒绝发布，不污染生产环境。

U - Validate：DGI 嵌入输出的分层校验

DGI 的嵌入输出不能直接用于决策——它是概率性的，没有 ground truth。需要分层验证来确认”这个嵌入是否可靠”。

DGI 场景下的验证流程：

层级	校验方式	确定性	DGI 场景具体做法
L1	Schema + 数值校验	100%	嵌入维度 512？数值范围 [-1, 1]？无 NaN/Inf？
L2	嵌入质量指标	100%	聚合度（同类节点距离 < 0.3）、区分度（异类节点距离 > 0.6）
L3	下游任务验证	概率性	用历史标注样本验证：已知异常样本的嵌入是否偏离正常分布？

关键洞察：DGI 的嵌入没有 ground truth，但嵌入的质量是可验证的。L1 保证格式正确，L2 保证结构合理（同类聚、异类分），L3 保证业务有效（历史异常能被检测到）。三层验证通过，嵌入才能进入生产环境。

N - Narrow：DGI 的能力白名单

DGI 的设计目标是”学习图嵌入”，不是”理解业务语义”。但在 DGI 项目中，我们让它做了太多超出能力范围的事——检测异常、解释原因、触发告警。

DGI 场景下的白名单设计：

DGI 能做的	DGI 不能做的	谁来做
图构建、GCN 推理、嵌入生成	语义判断、异常解释、业务规则	LLM
嵌入相似度计算	硬性约束校验（借贷平衡、金额限制）	规则引擎
参考分布维护	告警触发、人工通知	独立告警服务

关键洞察：DGI 的”不能做”不是技术限制，是责任边界。让 DGI 做异常解释？它只会说”这个节点和那个节点距离 0.45”——对人类毫无意义。解释是 LLM 的战场，校验是规则引擎的战场，DGI 只负责”把图变成向量”。

D - Diversify：DGI 模型的冗余策略

DGI 依赖单一模型架构的风险在 DGI 项目中暴露无遗——供应商静默更新，误判率从 3% 飙到 12%。

DGI 场景下的冗余设计：

冗余层级	DGI 具体策略	裁决机制
模型级	主模型（DGI v2.1）+ 备用（GraphSAGE）	嵌入不一致时，取距离参考分布更远的（更保守）
版本级	生产锁定版本，新版本跑 7 天评估集	评估集通过率下降 > 5% → 自动回滚
时间级	日级模型 + 周级融合模型	日模型不稳定时，用周模型兜底
人工级	嵌入偏离度 > 3σ 的交易	自动转人工，不赌模型判断

关键洞察：DGI 的嵌入是概率性的，但模型选择的裁决是确定性的。不是”哪个模型更准”（不知道），是”哪个模型更保守”（可以确定）。规则：距离参考分布越远 → 越异常 → 越安全。

三、融合架构：DGI + LLM + 规则引擎的工程实现

BOUND 原则不是抽象理论，是可以落地的工程框架。下面是一个具体的融合架构设计，基于 DGI 项目的真实场景——不是概念图，是可以运行的系统。

系统架构

API Gateway（契约校验 + 路由 + 熔断）
- 校验请求格式（Schema L1）
- 路由到实时层 / 近实时层 / 离线层
- 超时熔断（100ms / 5s / 1h）

实时层（< 100ms）：DGI + 规则引擎
- DGI 嵌入生成（50ms）
- 向量相似度搜索（Milvus，10ms）
- 规则引擎硬性校验（5ms）
- 99% 交易在此层完成，直接返回"正常"或"拦截"

近实时层（< 5s）：LLM 深度分析
- 接收实时层标记的"可疑"交易（1%）
- 语义分析：交易描述 + 上下文 + 历史模式 → 异常概率 + 解释
- 输出：高风险（人工复核）/ 中风险（告警 + 审计）/ 低风险（放行）

离线层（小时级）：人工复核 + 模型微调
- 运营人员审核近实时层的告警队列
- 自然语言反馈 → LLM 更新知识 → DGI 微调参考分布
- 每周评估集回归测试 → 模型版本锁定 / 回滚

数据层：图数据库 + 向量数据库 + 审计日志
- Neo4j：交易图存储（节点、边、属性）
- Milvus：嵌入向量索引（十亿级，实时检索）
- ClickHouse：审计日志（结构化查询，合规追溯）

数据流：一笔 50 万元跨境支付的具体处理

输入：POST /api/v1/transaction/check

{
  "transaction_id": "TXN_20260608_001",
  "amount": 500000,
  "currency": "CNY",
  "from_account": "U000270",
  "to_account": "M_ABC_HK",
  "channel": "WECHAT_CROSSBORDER",
  "event_type": "PAYMENT_SUCCESS",
  "journal_entries": [
    {"dr": "1122_WECHAT_CROSSBORDER", "cr": "2201_U000270", "amount": 500000},
    {"dr": "6001_M_ABC_HK", "cr": "1122_WECHAT_CROSSBORDER", "amount": 500000}
  ],
  "timestamp": "2026-06-08T14:30:00Z"
}

Step 1：Gateway 契约校验（5ms）

Schema L1：字段完整？金额 > 0？借贷平衡？（500000 = 500000 ✓）
路由决策：金额 > 10 万 → 走”大额交易”路径（更严格校验）
超时设置：实时层 100ms，超时时返回”待复核”

Step 2：DGI 嵌入生成（50ms）

图构建：节点 2201_U000270（用户存款）、1122_WECHAT_CROSSBORDER（应收渠道）、6001_M_ABC_HK（商户收入）
边构建：资金流动路径 U000270 → WECHAT_CROSSBORDER → M_ABC_HK
GCN 推理：生成 512 维嵌入向量，耗时 45ms

输出：

{
  "node_embeddings": {
    "2201_U000270": [0.12, -0.05, ..., 0.33],
    "1122_WECHAT_CROSSBORDER": [0.08, 0.21, ..., -0.15],
    "6001_M_ABC_HK": [0.45, -0.12, ..., 0.08]
  },
  "graph_embedding": [0.22, 0.04, ..., 0.18],
  "model_version": "dgi_v2.1.3",
  "latency_ms": 45
}

Step 3：向量相似度搜索（10ms）

Milvus 查询：graph_embedding 的最近 10 个邻居
结果：9 个邻居距离 < 0.30（正常），1 个邻居距离 0.45（历史洗钱交易模式）
判定：标记”可疑”，进入下一层
如果全部邻居距离 < 0.30 → 直接返回”正常”，流程结束

Step 4：规则引擎硬性校验（5ms）

借贷平衡校验：借方 500000 = 贷方 500000 ✓
金额超限校验：用户月累计 120 万，限额 200 万 ✓
频次异常校验：过去 7 天跨境支付 3 笔，阈值 5 笔 ✓
合规清单校验：商户 M_ABC_HK 不在制裁名单 ✓
判定：未违反任何硬性规则，进入 LLM 层
如果违反任何一条 → 直接拦截，返回”拒绝” + 具体原因

Step 5：LLM 深度分析（1s）

Prompt 构造（精简版）：

交易：用户张三向香港商户 ABC 支付 50 万元，商品为跨境电商批发订单。
用户历史：过去 30 天平均单笔支付 2-5 万元，跨境支付频率每月 1 次。
商户信息：ABC 商户注册于香港，主营电子产品批发，历史交易记录正常。
异常信号：单笔金额是历史平均的 10 倍，且为首次大额跨境支付。
DGI 嵌入分析：该交易的图嵌入与历史洗钱交易模式相似度 0.45（阈值 0.30）。
规则引擎校验：全部通过（借贷平衡、金额未超限、频次未超限、商户合规）。
问题：这笔交易是否存在异常？如果有，可能是什么类型的异常？建议 action？

LLM 输出：

{
  "anomaly_probability": 0.35,
  "risk_level": "MEDIUM",
  "explanation": "单笔金额突增（10 倍于历史平均）是异常信号，但商户资质正常、商品类型合理、用户在限额内。可能原因是：用户首次进行批发采购，或代购行为。DGI 的嵌入相似度偏高可能是因为大额跨境支付的图结构特征与历史洗钱模式有表面相似（多跳跨境路径），但语义上符合正常业务逻辑。",
  "recommended_action": "AUTO_ALERT_WITH_AUDIT",
  "reasoning": "金额突增 + 首次大额 → 需要监控，但规则引擎全部通过 + 商户资质正常 → 不足以拦截。建议自动告警并记录审计日志，无需人工复核，但需监控该用户后续交易模式。"
}

Step 6：结果路由（5ms）

风险等级：MEDIUM → 自动告警 + 记录审计日志

返回客户端：

{
  "transaction_id": "TXN_20260608_001",
  "status": "APPROVED_WITH_ALERT",
  "risk_level": "MEDIUM",
  "latency_ms": 1075,
  "processing_layer": "LLM",
  "audit_log_id": "AUD_20260608_0142"
}

Step 7：审计日志写入（异步，< 50ms）

ClickHouse 写入完整决策链条：
- Gateway 校验结果、耗时
- DGI 嵌入输出、模型版本、邻居距离
- 规则引擎校验结果、耗时
- LLM 输出、异常概率、解释、建议 action
- 最终决策、路由路径、总耗时

关键设计原则

1. 延迟分层：不是”越快越好”，是”不同延迟对应不同成本和能力”

实时层（< 100ms）：DGI + 规则引擎，确定性计算，处理 100% 的交易，99% 直接返回
近实时层（< 5s）：LLM 深度分析，概率性推理，处理 1% 的”可疑”，成本是实时层的 300 倍
离线层（小时级）：人工复核 + 模型微调，智慧判断，处理 0.1% 的”高风险”

2. 确定性分层：系统可靠性取决于”最笨的组件是否被约束”

100% 确定：规则引擎的硬性校验，不可违反，违反直接拦截
概率性但可控：DGI 的嵌入相似度，阈值可调，但只用于”初筛”不用于”终审”
概率性且灵活：LLM 的语义分析，需要人工兜底，输出只用于”建议”不用于”决策”

3. 成本分层：不是”省钱”，是”把钱花在刀刃上”

DGI：固定成本 $480/天，像”房租”——不管用不用，每天都要付
规则引擎：几乎为零，像”物业费”——嵌入在 DGI 流程里，不额外计费
LLM：按量计费 $1,500/天（实际处理 1%），像”打车”——只在需要时付费
总成本：约 $2,000/天，和纯 DGI 方案接近，但能力覆盖范围大了一个数量级

4. 风险分层：不是”机器替代人工”，是”机器做机器擅长的，人工做人工擅长的”

低风险（99%）：机器全自动，零人工，释放人力
中风险（0.9%）：机器分析 + 自动告警，人工事后抽查
高风险（0.1%）：机器分析 + 强制人工复核，终审权在人

反馈闭环：从告警到模型更新

T+0（交易当天）：

运营人员看到告警队列中的这笔交易，审核后反馈：“这笔不是异常。用户张三是某跨境电商的小老板，昨天刚签了一个大额批发合同。”

T+1（第二天）：

LLM 理解反馈，更新知识库：
- 新增知识：“跨境电商小老板 + 大额批发合同 = 正常业务模式”
- 规则调整：后续遇到类似模式（用户资质 + 金额突增 + 商户类型匹配），异常概率下调 0.2
DGI 参考分布微调：
- 这笔交易的 graph_embedding 加入”正常样本库”
- 更新参考分布的均值和协方差矩阵
- 下次类似交易的最近邻距离预期从 0.45 降到 0.28

T+7（每周）：

评估集回归测试：用过去 7 天的反馈数据验证模型性能
通过率 > 95% → 锁定新版本
通过率 < 95% → 回滚到旧版本，人工分析原因

T+30（每月）：

人工复核统计：误报率、漏报率、处理时效
模型效果报告：DGI 嵌入质量（聚合度、区分度）、LLM 解释准确率、规则引擎拦截率
成本分析：各层资源消耗、总成本趋势

四、认知进化：从”对抗不确定性”到”管理不确定性”

DGI 项目的设计逻辑是**“对抗不确定性”**——用更复杂的模型、更完整的 pipeline、更严格的反馈，试图消除不确定性。日级模型对抗概念漂移，知识蒸馏对抗模型不稳定，反馈闭环对抗标注稀缺。

BOUND 原则的设计逻辑是**“管理不确定性”**——承认不确定性是系统的原生约束，把不确定性预算分配到正确的场景。高风险场景分配更多验证层、更严格的人工检查、更保守的模型参数。低风险场景放宽约束，换取更高的自动化率和更低的成本。

这个转变的本质是：从”追求正确”到”追求可控”。

2024 年我们问”如何让模型更正确”，2026 年我们问”如何在模型不完美的情况下，让系统依然可靠”。第一个问题需要更强大的模型，第二个问题需要更清晰的边界——BOUND 原则就是边界的工程化表达。

五、不是万能药，是分工框架

BOUND 原则不是万能药。它不能解决所有 AI 系统的工程问题，它只是一个思考框架——帮助架构师在通用能力和垂直约束之间找到平衡。

它的价值在于：

不捧 LLM：LLM 有它的战场（语义理解、解释生成），也有它的禁区（实时性、确定性、成本）
不踩 DGI：DGI 有它的战场（实时嵌入、结构化推理、大规模处理），也有它的禁区（语义理解、零样本识别、可解释性）
不迷信规则引擎：规则引擎有它的战场（确定性校验、合规底线），也有它的禁区（新型模式识别、灵活适应）

每个组件做自己擅长的事，边界清晰，衔接可控，系统就可靠。 这不是技术选择，是工程纪律。

“2024 年的我，试图用一个模型解决所有问题。2026 年的我知道，系统的可靠性不取决于最强的组件，而取决于最弱的组件是否被边界保护。”

“BOUND 不是新发明，是软件工程 301 在 AI 时代的翻译——接口契约、状态机约束、分层校验、单一职责、冗余备份。”

“通用能力 + 垂直约束 = 可控的系统。这不是数学公式，是工程直觉。”

本文首发于「谢先生的 AI 深析札记」

下一篇预告：「温故知新」——如果用 2026 年的认知重做 DGI 项目。具体设计，具体代码，具体权衡。