这是「从炼丹到通用」系列的第四篇，也是终章。
第一篇考古了 2024 年的 DGI 项目。第二篇分析了 LLM 崛起后的冲击。第三篇提出了 BOUND 原则在 DGI 场景下的落地。这篇要回答的问题是：如果用 2026 年的认知重做这个项目，系统会长什么样？
不是用 LLM 替代 DGI，是 DGI + LLM + 规则引擎的融合架构。具体设计，具体代码，具体权衡。
一、重做前的三个原则
在画架构图之前，先明确三个原则。这些原则来自前三篇的反思：
原则一：不做无意义的替代
DGI 在实时嵌入、结构化推理、大规模处理上的优势，LLM 替代不了。LLM 在语义理解、异常解释、新型模式识别上的优势，DGI 也替代不了。重做的目标不是”新技术替代旧技术”，是”让各自做各自擅长的事”。
原则二：不重复造轮子
2024 年的 DGI 项目从零构建了数据生成器、Hash-Hot 编码、训练 pipeline、评估框架。2026 年，这些轮子已经存在：向量数据库（Milvus）、图数据库（Neo4j）、LLM 编排框架（LangGraph / Temporal）、模型服务（vLLM / Triton）。重做的系统要尽量用现成工具，把精力花在”怎么组合”上。
原则三：不迷信端到端
LLM 时代最大的诱惑是”端到端”——一个 Prompt 解决所有问题。但这个诱惑在支付风控场景里是危险的。端到端意味着失去确定性边界、失去可审计性、失去成本控制。重做的系统必须保留明确的层次和边界。
二、系统架构：三层 + 两库
2026 版的 DGI 系统，可以简化为三层 + 两库：
应用层
- API Gateway：契约校验、路由、熔断、限流
- LLM 服务：语义分析、异常解释、自然语言交互
- 运营后台：告警审核、反馈标注、规则管理
计算层
- DGI 服务：图构建、GCN 推理、嵌入生成
- 规则引擎：硬性约束校验、合规检查
- 向量搜索：Milvus 相似度检索
数据层
- Neo4j：交易图存储
- Milvus：嵌入向量索引
- ClickHouse：审计日志对比 2024 年的 12 步 pipeline，2026 版的系统把数据生成、ETL、图化、训练、评估、聚类、标注这些步骤，压缩成了三个服务 + 两个数据库。不是功能少了，是基础设施成熟了。
三、核心代码：从 15,000 行到 1,500 行
2024 年的 DGI 项目有 15,000 行代码。2026 年的重做版，核心代码可以控制在 1,500 行左右。下面是几个关键模块的代码骨架。
1. DGI 嵌入服务
2024 年的 DGI 服务需要处理数据生成、ETL、图构建、训练、评估。2026 年的 DGI 服务只做一件事：输入交易数据，输出嵌入向量。
# dgi_service.py
from torch_geometric.data import Data
from models import GCNEncoder, DGIModel
import torch
class DGIEmbeddingService:
def __init__(self, model_path: str):
self.encoder = GCNEncoder(in_channels=512, hidden_channels=256)
self.dgi = DGIModel(self.encoder, hidden_channels=256)
self.dgi.load_state_dict(torch.load(model_path))
self.dgi.eval()
def embed(self, transaction: dict) -> dict:
# 图构建：从交易分录到 PyG Data
graph = self._build_graph(transaction["journal_entries"])
# GCN 前向传播
z = self.encoder(graph.x, graph.edge_index)
# 聚合得到图级别嵌入
graph_emb = z.mean(dim=0)
return {
"node_embeddings": z.tolist(),
"graph_embedding": graph_emb.tolist(),
"model_version": "dgi_v2.1.3",
"latency_ms": 45
}
def _build_graph(self, entries: list) -> Data:
# 节点：科目_实体，边：资金流动方向
nodes = list(set([e["dr"] for e in entries] + [e["cr"] for e in entries]))
node_map = {n: i for i, n in enumerate(nodes)}
edge_index = torch.tensor(
[[node_map[e["dr"]], node_map[e["cr"]]] for e in entries],
dtype=torch.long
).t()
x = torch.eye(len(nodes), 512) # Hash-Hot 编码
return Data(x=x, edge_index=edge_index)关键变化：服务只暴露 embed() 一个方法，不做异常判断，不做语义分析，不做告警触发。职责单一，边界清晰。
2. 规则引擎
2024 年的规则引擎被弃用了，因为”无法适应新型异常”。2026 年的规则引擎重新变得重要，但角色变了：只做硬性约束校验，不做异常模式识别。
# rule_engine.py
from typing import List, Dict, Optional
class RuleEngine:
def __init__(self, rules: List[dict]):
self.rules = rules # 从配置中心加载
def check(self, transaction: dict) -> Dict:
violations = []
# 规则 1：借贷平衡
total_dr = sum(e["amount"] for e in transaction["journal_entries"])
total_cr = sum(e["amount"] for e in transaction["journal_entries"])
if abs(total_dr - total_cr) > 0.01:
violations.append({"rule": "DEBIT_CREDIT_BALANCE", "severity": "CRITICAL"})
# 规则 2：金额上限
if transaction["amount"] > 1_000_000:
violations.append({"rule": "AMOUNT_LIMIT", "severity": "CRITICAL"})
# 规则 3：用户月累计限额
monthly_total = self._get_monthly_total(transaction["from_account"])
if monthly_total + transaction["amount"] > 2_000_000:
violations.append({"rule": "MONTHLY_LIMIT", "severity": "HIGH"})
return {
"passed": len(violations) == 0,
"violations": violations,
"latency_ms": 5
}关键变化：规则引擎只检查”已知的、不可违反的硬性约束”。新出现的业务场景？不归规则引擎管，归 LLM 管。但底线规则一旦被违反，直接拦截，不需要 LLM 确认。
3. LLM 分析服务
2024 年没有 LLM 服务。2026 年的 LLM 服务是新增的，只做语义分析。
# llm_service.py
from openai import OpenAI
import json
class LLMAnalysisService:
def __init__(self, model: str = "gpt-5"):
self.client = OpenAI()
self.model = model
def analyze(self, transaction: dict, context: dict) -> dict:
prompt = self._build_prompt(transaction, context)
response = self.client.chat.completions.create(
model=self.model,
messages=[{"role": "user", "content": prompt}],
response_format={"type": "json_object"},
temperature=0.1 # 金融场景，低温度减少幻觉
)
return json.loads(response.choices[0].message.content)
def _build_prompt(self, transaction: dict, context: dict) -> str:
return f"""
你是一个金融风控专家。请分析以下交易是否存在异常。
交易信息：
{json.dumps(transaction, ensure_ascii=False, indent=2)}
上下文信息：
- 用户历史平均单笔金额：{context['avg_amount']}
- 用户跨境支付频率：{context['cross_border_freq']} 次/月
- DGI 嵌入相似度：最近邻距离 {context['nearest_neighbor_distance']}（阈值 0.30）
- 规则引擎校验：{context['rule_check_result']}
请输出 JSON 格式：
{{
"anomaly_probability": float,
"risk_level": "LOW" | "MEDIUM" | "HIGH",
"explanation": str,
"recommended_action": "AUTO_PASS" | "AUTO_ALERT" | "MANUAL_REVIEW"
}}
"""关键变化：LLM 的输出是”建议”不是”决策”。最终决策由规则引擎（硬性违规）或人工复核（高风险）做出。
4. 编排服务
2024 年的 pipeline 是串行的 bash/python 脚本。2026 年的编排服务用状态机定义整个流程。
# orchestrator.py
from statemachine import StateMachine, State
class FraudDetectionWorkflow(StateMachine):
received = State(initial=True)
dgi_checked = State()
rule_checked = State()
llm_analyzed = State()
completed = State(final=True)
manual_review = State()
check_dgi = received.to(dgi_checked)
check_rules = dgi_checked.to(rule_checked)
analyze_llm = rule_checked.to(llm_analyzed)
complete = llm_analyzed.to(completed)
escalate = llm_analyzed.to(manual_review)
def on_check_dgi(self, transaction):
result = dgi_service.embed(transaction)
nearest_dist = milvus.search(result["graph_embedding"])
transaction["dgi_result"] = result
transaction["nearest_dist"] = nearest_dist
# 如果距离太远，标记可疑，进入规则引擎
return nearest_dist > 0.30
def on_check_rules(self, transaction):
result = rule_engine.check(transaction)
transaction["rule_result"] = result
# 如果违反硬性规则，直接拦截，流程结束
if not result["passed"]:
transaction["final_decision"] = "REJECT"
self.complete(transaction)
return False
return True
def on_analyze_llm(self, transaction):
context = {
"avg_amount": user_history.get_avg(transaction["from_account"]),
"cross_border_freq": user_history.get_freq(transaction["from_account"]),
"nearest_neighbor_distance": transaction["nearest_dist"],
"rule_check_result": "PASSED"
}
result = llm_service.analyze(transaction, context)
transaction["llm_result"] = result
if result["risk_level"] == "HIGH":
self.escalate(transaction)
else:
self.complete(transaction)关键变化：流程是确定性的（状态机），但节点内部是概率性的（DGI 推理、LLM 生成）。状态机保证”卡住能降级”，节点保证”概率性能力”。
四、数据流：从 12 步到 4 步
2024 年的完整 pipeline 有 12 步。2026 年的重做版，一笔交易的审核流程只有 4 步：
交易进入 → DGI 嵌入（50ms）→ 规则校验（5ms）→ LLM 分析（1s）→ 决策输出
↓ ↓ ↓
99% 放行 违规拦截 风险分级Step 1：DGI 嵌入（50ms）
- 输入：交易 + 分录
- 输出：图嵌入 + 最近邻距离
- 99% 的交易在此层被判定为”正常”，直接放行
- 1% 的”可疑”进入下一步
Step 2：规则校验（5ms）
- 输入：可疑交易 + 硬性规则
- 输出：通过 / 拒绝 + 原因
- 拒绝的交易直接拦截，不进入 LLM
- 通过的交易进入下一步
Step 3：LLM 分析（1s）
- 输入：可疑交易 + 用户历史 + DGI 结果
- 输出：异常概率 + 风险等级 + 解释 + 建议 action
- 高风险 → 人工复核
- 中风险 → 自动告警 + 审计
- 低风险 → 放行
Step 4：决策输出
- 输入：LLM 建议
- 输出：最终决策 + 完整审计日志
五、关键权衡
重做的过程中，有几个必须做的权衡。
1. 延迟 vs 能力
2024 年的 DGI 系统，平均延迟 50ms，但只能做结构相似度判断。2026 年的融合系统，99% 的交易延迟 50ms，1% 的交易延迟 1s，但能力覆盖范围大了一个数量级。
权衡：接受 1% 交易的延迟，换取整体能力的提升。不是所有交易都需要 LLM，只需要对”可疑”交易做深度分析。
2. 成本 vs 覆盖
2024 年的纯 DGI 系统，成本 $480/天，但覆盖的异常类型有限。2026 年的融合系统，成本 $2,000/天，但覆盖了新型异常、语义异常、复杂模式。
权衡：成本增加 4 倍，但能力不是线性增加，是指数级增加——因为 LLM 让系统能处理”没见过”的异常。
3. 自动化 vs 人工
2024 年的系统追求”全自动”——反馈闭环自动调优，希望 eliminating 人工。2026 年的系统明确”人工终审”——高风险交易必须人工确认。
权衡：接受人工参与，换取合规安全和责任清晰。不是所有决策都能交给机器。
4. 确定性 vs 灵活性
规则引擎提供确定性，LLM 提供灵活性。规则引擎说”借贷不平衡必须拦截”，LLM 说”这笔交易看起来可疑，但可能是正常业务创新”。
权衡：用规则引擎守住底线，用 LLM 探索上线。底线不可突破，上线可以试错。
六、没有解决的难题
2026 年的重做版能解决很多 2024 年的问题，但也有一些难题依然没有完美答案。
1. LLM 幻觉
即使温度调到 0.1，LLM 仍可能生成看似合理但实际错误的解释。在金融场景里，“解释错误”比”判断错误”更危险——因为错误的解释可能误导人工复核。
当前解法：多模型交叉验证 + 知识图谱约束 + 人工抽查。不是消除幻觉，是控制幻觉的影响范围。
2. 反馈数据质量
运营人员的自然语言反馈仍然可能出错。“这笔不是异常，因为用户签了新合同”——如果这个合同本身是假的，反馈就是错的，LLM 会学到错误的知识。
当前解法：反馈需要双人复核 + 定期评估反馈效果 + 异常反馈追溯。不是信任所有反馈，是管理反馈的质量。
3. 新型异常的评估
LLM 能识别新型异常，但怎么评估它识别新型异常的能力？用已知的异常评估，逻辑上不成立；用未知的异常评估，没有 ground truth。
当前解法：A/B 测试 + 人工标注 + 业务指标跟踪。不是评估”能不能识别所有新型异常”，是评估”上线后业务指标是否改善”。
七、终章：从炼丹到通用，再从通用回到具体
四篇文章写到这里，终于可以画一个完整的圆。
第一篇说：2024 年的 DGI 项目是一座工整的城堡，但城堡建在了即将漂移的地基上。
第二篇说：LLM 的崛起没有让 DGI 过时，它让 DGI 的定位更清晰了——DGI 做结构化推理，LLM 做语义理解。
第三篇说：通用能力和垂直约束的融合，需要 BOUND 原则——边界、编排、验证、收窄、冗余。
第四篇说：如果重做，系统可以更简单，也更强大。不是因为它用了更新的技术，是因为它的设计者更清楚地知道每个组件该做什么、不该做什么。
这个系列的真正主题，不是技术演进，是认知演进。
2024 年的我，相信”模型能力决定系统能力”。2026 年的我知道，系统能力取决于边界设计，而不是单一组件的能力。2024 年的我，追求”用一个模型解决所有问题”。2026 年的我，追求”用多个组件的协作，解决一个复杂问题”。
这不是退步，是成熟。
炼丹时代的工程师，把模型当作火箭，想尽一切办法让它飞得更高。通用时代的工程师，把系统当作机场，想尽一切办法让每个飞机安全起降。
机场没有火箭浪漫，但机场能让更多的人到达更远的地方。
“2024 年的我，用 12 步 pipeline 告诉世界’我很努力’。2026 年的我，用 4 步流程告诉业务’我值得信任’。”
“技术越通用，工程越具体。”
“好的架构不是让最强的组件更强大，是让最弱的组件不拖累全局。”
“从炼丹到通用，再从通用回到具体——这才是工程师的成年礼。”
本文首发于「谢先生的 AI 深析札记」
「从炼丹到通用」系列至此完结。