这是「从炼丹到通用」系列的第一篇。
2024 年，团队花了三个月构建了一个基于 DGI（Deep Graph Infomax）的金融交易异常检测系统。12 个步骤、15,000 行代码、从数据生成到反馈闭环的完整 pipeline。2026 年回头看，这个项目像一座精心修筑的城堡——每一块砖都砌得工整，但城堡本身建在了即将漂移的地基上。
这篇不是技术教程，也不是项目宣传。这是一次工程复盘：用今天的眼光，冷静地记录当时的认知状态，看看那些”工程完备”的设计，如何既成就了它，也预示了它的局限。
一、当时为什么要做这个项目
2024 年的背景很简单：支付平台的财务对账团队每天面对十亿级交易流水，从中寻找记账错误、重复扣款、资金挪用。规则引擎能抓住已知的坏模式，但新型异常——比如”把应收款挂到待处理科目里拖延入账”——规则写不出来，因为攻击者也在学习规则。
深度学习的思路很自然：让模型自己学习”正常交易长什么样”，然后标记偏离正常的样本。
选择图神经网络（GNN）而不是传统表格模型，是因为交易数据天然是图结构——一笔支付从用户账户流出，经过渠道账户，最终到达商户账户。节点是会计科目+实体（如”应付用户_张三”），边是资金流动。图结构比表格更能捕捉”资金流向异常”这种关键信号。
选择 DGI（Deep Graph Infomax）而不是有监督的 GNN，是因为异常标签太稀缺了。真实的异常交易可能只占 0.1%，而且标注需要资深会计师逐笔审核。DGI 是无监督的：它不需要”这是异常”的标签，只需要学习”正常图的嵌入分布是什么样的”，然后假设偏离这个分布的就是异常。
这个思路在 2024 年不算激进，但也不算保守。它代表了那个时代的主流认知：数据不够，用自监督；结构复杂，用图网络；模式漂移，用日级专家模型。
二、系统全貌：12 步 pipeline 的 engineering obsession
项目的完整 pipeline 有 12 个步骤，从数据生成到模式发现，环环相扣。
数据层：从数据仓库到图结构
原始数据来自支付平台的数据仓库——每天十亿级交易流水，通过 Spark SQL 抽取记账分录。字段很标准：凭证号、会计科目、借贷方向、金额、币种、业务实体、上游事件类型、时间戳。
但原始数据不能直接喂给模型。需要理解业务语义：一笔支付成功会触发什么分录？退款执行涉及哪些科目？结算打款的资金流向是什么？这些知识来自财务团队，不是写在数据字典里的。
数据清洗的第一步是校验借贷平衡——同一凭证号下借方金额必须等于贷方金额。这是会计恒等式的底线，也是第一道异常筛选：借贷不平衡的凭证，本身就是系统漏洞或人为篡改的信号。
2024 年的日常：每天跑 Spark SQL 抽数，和财务团队对口径，处理数据仓库里的脏数据（科目编码不一致、金额单位错误、时间戳时区混乱）。数据准备占了整个项目 40% 的时间。
2026 年的感慨：当时觉得”理解业务语义”是核心竞争力——要知道支付成功是 DR 应收渠道 / CR 应付用户，要知道退款涉及存款减少和银行打款。这些知识来自财务团队的口传心授，不是写在数据字典里的。今天回头看，这种”业务浸泡”的成本确实很高，但它产出的不是知识本身，而是对数据质量、口径一致性、异常模式的直觉——这些直觉，任何模型都替代不了。
图构建：把会计分录变成资金流向图
ETL 层的核心是把记账分录转换为图结构。按凭证号分组，校验借贷平衡，然后把每笔分录配对成有向边——贷方（资金流入）指向借方（资金流出）。
这里有一个关键的设计取舍：节点类型单一化。
真实的支付网络里，节点类型是多样的——用户账号、商户账号、支付渠道、交易订单、甚至设备指纹。每种类型有自己的属性：用户有注册时长、历史交易额；商户有行业分类、结算周期；渠道有费率、对接方式。
但我们选择了单一节点类型：所有节点都是”会计科目_实体”，比如 2201_U000270 表示”应付用户_张三”，1122_WECHAT 表示”应收渠道_微信支付”。
为什么不做异构图？因为十亿级数据下，异构图的复杂度是灾难性的。用户节点可能有十亿个，商户节点百万个，交易节点百亿个——不同类型之间的边关系指数级膨胀。Spark SQL 抽数已经够慢了，再做多类型关联，ETL 跑不完。
单一节点类型的代价也很明显：模型永远不知道”用户”和”商户”是两种不同的东西。一个用户账号和一个渠道账号，在图里只是两个不同的字符串 ID，它们的语义差异被抹平了。
边特征用了 Hash-Hot 编码——mmh3 哈希取模到 512 维，一个位置置 1。选择 Hash-Hot 而不是 One-Hot 是因为无需维护全局字典，新交易类型自动处理，没有 OOV 问题。
2024 年的考虑：单一节点 + Hash-Hot，都是为了”能跑起来”。十亿级数据下，复杂度和可扩展性是第一约束，语义丰富度是第二约束。
2026 年的发现：Hash-Hot 把”微信支付”和”支付宝”编码成两个随机的 512 维向量，模型永远不知道它们都是”支付渠道”。语义信息在编码阶段就丢失了，后面花再多力气也补不回来。
一个更深层的问题：整个图构建过程，从分录到图边，每一步都是人工设计的规则和取舍。节点类型单一化、贷方指向借方、Hash-Hot 编码——这些选择把业务知识硬编码进了数据结构，同时也把业务的复杂性压缩掉了。2026 年回头看，这些规则本身就是系统的脆弱点：业务变了，规则就要改，模型就要重训。
当时不是不知道异构图更好，是知道但做不了。
模型与训练：日级专家 + 月度融合的执念
模型层本身不复杂——2 层 GCN 编码器 + DGI 无监督预训练。真正的 engineering 密度在怎么让训练跑完。
POC 阶段的惨痛教训：一开始全部串行——一天的数据训完再训下一天。结果一个星期过去，只跑完了 3 天的模型。按这个速度，一个月的数据要训两个月。
问题出在哪？不是模型复杂，是数据加载和图构建太慢。每天十亿级流水，Spark SQL 抽数、分组、校验、转图——这些前置步骤占了 90% 的时间，GPU 大部分时间都在等数据。
第一个优化：并行化。把 30 天的训练任务拆成 15 个 batch，每个 batch 处理 2 天的数据，15 个 batch 并行跑。不是模型并行，是数据并行——每个 worker 独立加载自己的数据、构建自己的图、训练自己的模型。
第二个优化：做减法。DGI 原始实现里有很多”学术完整”但”工程累赘”的组件——聚类层、embedding 可视化、中间结果持久化。POC 阶段全部砍掉，只保留 encoder + discriminator。训练速度提升了 3 倍。
第三个优化：预构图。把图构建从训练时移到训练前，提前生成 PyG 的 Data 对象序列化到磁盘。训练时直接 load，省掉实时的 ETL 开销。
这三个优化做完，30 天的模型从”两个月”压缩到”两天”。
日级专家模型的架构是在这个基础上长出来的：每天独立训练一个 DGI 模型，30 个模型并行跑。月底用知识蒸馏融合为 1 个月度模型，Student 学习 30 个 Teachers 的 soft target。下个月的热启动用上月月度模型初始化。
2024 年的自信：从串行到并行，从两个月到两天——这是工程能力的体现。当时觉得”能跑起来”就是胜利。
2026 年的质疑：优化方向是对的，但目标本身有问题。我们优化的是”怎么更快训练 30 个日模型”，但从来没问过”为什么要训 30 个”。日级模型的训练数据只有一天，样本量小，模型本身就不稳定。30 个不稳定的模型融合成一个，不是”集思广益”，是”集体幻觉”。
另一个问题：知识蒸馏的暗知识前提是 Teachers 有知识可传。如果 30 个日模型对某种新型模式都没有概念，蒸馏只是把”无知”平均化。30 个模型输出 0.51，Student 也输出 0.51——这不是知识传承，是无知的一致性。
评估：为无监督模型发明一套”分数”
DGI 不直接输出异常分数，这是最大的工程挑战。我们设计了完整的无监督评估框架：
参考分布法：在训练数据上建立正常样本的嵌入分布（均值 μ、标准差 σ），新样本计算马氏距离——距离越远越异常。
多指标验证：AUC-ROC 验证区分能力，Precision@K 验证 Top-K 命中率，Recall@K 验证覆盖率。模拟数据上的 baseline：AUC 0.7956，R@100 = 100%。
2024 年的现实：评估是项目最纠结的环节。因为推理场景当时还没完全想清楚。
DGI 是无监督的，不输出异常分数。那训练出来的嵌入质量怎么衡量？我们退而求其次，用两个更基础的指标：
聚合度——同类交易图的嵌入应该聚在一起。比如同一商户的多笔支付，嵌入距离应该很近；同一渠道的收款，应该聚成一团。
区分度——异类交易图的嵌入应该明显分开。比如支付和退款，嵌入分布应该有清晰的边界；大额交易和小额交易，不应该混在一起。
具体指标包括：Silhouette Score（轮廓系数）、k-NN Accuracy（最近邻准确率）、ADR（聚合度/区分度比率）。这些指标不依赖异常标签，只依赖业务标签（event_type、channel_id）——而业务标签是数据本身就有的。
但这里有个根本问题：聚合度和区分度评的是”嵌入质量”，不是”异常检测能力”。嵌入聚得好，不代表异常抓得准。就像一个学生字写得漂亮，不代表作文写得好。
我们也用 golden 标签算过 AUC——找财务团队人工标注了一批样本，AUC 0.7956。但 golden 标签的问题是：标注的是”已知的异常”，而我们要检测的是”未知的异常”。用已知验证未知，逻辑上就不闭环。
但换个角度看，聚合度和区分度恰恰给后面的推理提供了泛化能力。
嵌入聚得好，意味着相似的图在向量空间里距离近。这直接支撑了三种推理方式：
向量相似度搜索——新交易进来，算嵌入，在向量库里找最近的邻居。如果距离太远，就是异常。不需要预定义异常规则，“像不像正常”就是规则。
层次聚类检测——第一层聚出交易大类（支付、退款、结算），第二层在大类里按金额、渠道细分。一个交易如果落在”支付类→微信支付→小额”这个子簇里，但行为却像”大额”，就是异常。
模式时序检测——同一商户的嵌入序列应该稳定。平时都是小额支付，突然来一笔大额，嵌入跳变，触发告警。不需要知道”大额是多少”，只需要知道”和平时不一样”。
2026 年的重新理解：当时觉得评估是”薄弱环节”，是因为我们用”异常检测准确率”来要求它。但如果把 DGI 看作”通用图嵌入引擎”，聚合度和区分度恰恰是它最核心的能力——它不负责”判断异常”，它负责”把相似的图放在一起，把不相似的图推开”。异常检测只是这个能力的一种用法。
2024 年的我们，不是连”好”的定义都没确定。是我们确定的定义——“异常检测准确率”——太窄了。
反馈闭环：理想丰满，现实骨感
反馈机制在文档里写得很完整，但实际落地比设计脆弱得多。
运营人员的日常工作确实是给异常打标。但这里的”异常”有两种：进行时异常（交易流程卡住了，还没完结）和终态异常（交易完结了，但结果有问题，比如资金没到账）。两种异常的标注逻辑完全不同，但当时没有严格区分。
硬反馈的理想：确认异常的样本降权或丢弃，让模型”只学正常，不学异常”。
硬反馈的现实：标注本身就可能出错。运营人员每天面对海量告警，疲劳标注、误判、标准不统一——这些”错误标注”如果被当作”真实异常”降权，模型反而在学”错误的正常”。
更麻烦的是，异常的定义本身就是流动的。今天认为是异常的”凌晨大额转账”，下个月可能是正常的”跨境电商结算”。硬反馈把昨天的”异常”永久降权，可能恰恰丢掉了明天需要学习的”新模式”。
软反馈和漂移反馈也面临同样的问题：k-NN Accuracy 下降，到底是模型变差了，还是业务本身变了？KL 散度升高，到底是分布漂移了，还是节假日促销导致的正常波动？
2024 年的自豪：文档里三种反馈各司其职，构成了自适应系统。
2026 年的清醒：反馈闭环的设计是合理的，但反馈数据的质量是不可控的。标注错误、定义漂移、业务变化——这些噪声被反馈系统放大，反而让模型越学越偏。
更深层的困境是业务变化的速度远超模型更新的速度。支付行业半年一次大改版是常态：新支付渠道上线、老渠道下线、结算周期调整、费率结构变化——每一种变化都会让”正常”的定义偏移。半年前训练的模型，面对今天的交易模式，可能已经完全不认识了。
当时的解法是用”最近三个月的数据”做冷启动重训——丢弃更早的历史，只保留近期的样本。但这带来两个新问题：
样本量骤减。三个月的数据可能只够训练一个粗糙的模型，区分度和聚合度双双下降。AUC 从 0.79 掉到 0.65，不是模型变差了，是”没吃饱”。
周期性的模式丢失。有些异常是季节性的——年底商户集中结算、春节红包提现高峰——这些模式在三个月的数据里根本不会出现。冷启动重训把”没见过”当成”不存在”， seasonal 的异常反而漏掉了。
当时花了很大力气设计反馈机制，但花在”如何让标注更可靠”上的精力，远远不够；花在”如何让模型适应业务变化”上的思考，也远远不够。
聚类与模式发现：用复杂性补偿语义缺失
步骤 8-12 本质上是在做同一件事：DGI 不理解业务语义，我们用工程手段补回来。
向量相似度搜索是最直接的用法。把每笔交易的图嵌入直接导入 Elasticsearch，新交易进来时算嵌入，搜索最近的邻居。如果最近邻距离超过阈值，就是异常。不需要预定义规则，“像不像正常”就是规则。
但 Elasticsearch 的向量搜索在十亿级数据下面临性能瓶颈。为了解决这个问题，我们尝试了向量 Hash 化——把高维嵌入映射到低维 Hash 桶，用 LSH（局部敏感哈希）加速近邻搜索。Hash 化后搜索速度提升了 10 倍，但代价是精度损失：两个原本距离 0.1 的嵌入，Hash 后可能落到不同桶里，变成”查不到”。
时序模式分析是另一个方向。同一商户的嵌入序列应该稳定，突然跳变就是异常。我们把嵌入按时间序列排列，计算滑动窗口内的均值和方差，超出 3σ 就告警。但问题是：商户的行为本身就在变化——新商户没有历史基线，大促期间波动剧烈，季节性模式让”正常”的定义漂移。
层次聚类试图解决语义缺失。第一层 K-Means 发现交易大类（支付、退款、结算），第二层按金额、渠道细分。自动标注用簇内多数 event_type 投票。但聚类的质量严重依赖初始中心点，K-Means 对高维嵌入的效果并不稳定——同样的数据跑两次，簇的划分可能完全不同。
多维度标注从 6 个维度给交易打标签，试图构建完整的语义描述体系。验证用聚类结果 vs GROUP BY 对比，证明图级聚类比记录级 GROUP BY 纯度高。实验性方法尝试了决策树聚类、嵌入空间决策树——但都没有进入主流程。
2024 年的逻辑：DGI 给了嵌入，相似度搜索给了检测，Hash 化给了性能，时序分析给了动态监控，聚类给了结构，标注给了语义。层层补齐，系统就完整了。
2026 年的直白：这些尝试都能”跑起来”，但效果并不特别理想。向量搜索在十亿级数据下延迟高，Hash 化损失了精度，时序分析对基线依赖严重，聚类不稳定。每一种方法解决了一个问题，又引入了新的问题。
这不是设计失误，是技术栈的局限。2024 年没有现成的向量数据库能扛住十亿级实时搜索，没有时序模型能自动适应业务漂移，没有聚类算法能保证高维嵌入的稳定性。我们是在给 DGI 打补丁，但补丁摞补丁，系统越来越复杂，效果却没有线性提升。
2026 年回头看，这些补丁的价值不是”解决了问题”，而是**“证明了问题的存在”**——DGI 的嵌入是好东西，但怎么用好它，2024 年的工具链不够。Elasticsearch 做向量搜索是权宜之计，LSH Hash 化是性能妥协，时序分析是基线困境，聚类是语义缺失的代偿。每一个补丁都指向同一个结论：嵌入能力本身有价值，但 2024 年的工具链没有给它合适的舞台。
三、当时为什么这样选
站在 2024 年的视角，这个项目的每一个设计都有它的理由。不是盲目跟风，是在具体约束下的务实选择。理解这些选择，才能理解为什么它们既成就了项目，也埋下了换路的种子。
日级专家 + 月度融合：数据时效性的妥协
金融交易模式随时间漂移，这是共识。但 2024 年的约束是：全量历史数据训练，早期数据过时；只用近期数据，样本量又不够。日级模型 + 月度融合是在这个约束下的折中——用并行化解决训练速度，用蒸馏解决部署成本。
当时不是没想过更简单的方案。比如直接用滑动窗口：最近 30 天数据训一个模型，每天滚动更新。但问题是：30 天的数据分布本身就在变化，模型学的是一个”混合分布”，区分度会下降。日级模型至少保证了每个模型内部的分布一致性。
2026 年回头看，这个架构的代价被低估了：30 个不稳定模型的融合，不是”集思广益”，是”集体幻觉”。但当时没有更好的选项——在”数据时效性”和”模型稳定性”之间，我们选择了前者，因为业务方对”漏掉新模式”的容忍度低于”模型偶尔不准”。
反馈闭环：标注稀缺倒逼出来的设计
三种反馈不是一开始就设计好的，是被标注成本逼出来的。
真实的异常标签稀缺——0.01% 的比例，会计师逐笔审核。招人标注？成本太高，且标注质量不稳定。用规则引擎生成伪标签？规则能覆盖的异常，模型学来也没用。完全无监督？评估无从谈起，上线没信心。
硬反馈、软反馈、漂移反馈，本质上是在”没有足够标注”的约束下，用工程手段制造”替代信号”。硬反馈用人工审核的少量样本清洗数据，软反馈用评估指标驱动自动调优，漂移反馈用分布监控触发重训——三者互补，构成了一个”弱监督”系统。
2026 年回头看，这个设计的聪明之处在于：它承认了标注的稀缺性，没有假装问题不存在。但它的局限也在于此：反馈系统的质量上限，取决于反馈数据的质量上限。标注错误、定义漂移、业务变化——这些噪声被系统放大，而不是被系统过滤。
无监督评估：没有 ground truth 时的权宜之计
DGI 不输出异常分数，怎么知道它学得好不好？这是项目最纠结的问题。
聚合度和区分度不是”最佳实践”，是没有办法时的办法。有 ground truth 就用 AUC，没有 ground truth 就只能找 proxy。同类样本聚得紧、异类样本分得开——这个 proxy 不完美，但至少可计算、可比较、可优化。
2026 年回头看，这个权宜之计有一个意外的收获：它让我们把注意力从”异常检测准确率”转移到了”嵌入质量”。聚合度和区分度评的是嵌入本身，不是嵌入的某种下游用法。这个视角的转换，为后来的向量搜索、时序分析、聚类检测提供了基础——评估指标定义了你能看到什么。
模拟数据：可控的真实
异常标签稀缺，这是硬约束。模拟数据不是”偷懒”，是在”没有足够真实标签”的情况下，验证系统能力的务实手段。
关键的设计原则是：模拟数据必须基于真实业务逻辑。会计科目体系来自真实系统，业务事件来自真实流程，异常类型来自真实风控场景。不是随机生成数字，是在可控条件下复现真实。
2026 年回头看，这个选择的价值被低估了：它让我们能在上线前，系统地测试”已知异常能否被抓到”。模拟数据不是”假的”，是边界测试的工具——它定义了系统能力的下限，而不是上限。
四、2026 年回头看：那些”对”里埋着的”错”
这个项目的 engineering 质量——模块划分、数据流设计、评估体系、反馈闭环——在 2026 年依然值得尊重。但尊重的不是”它做对了”，而是”它怎么一步步走到该换路的岔口”。
确定性思维的惯性
整个 pipeline 假设”正常”有一个稳定的定义。支付成功就该是 DR 应收渠道 / CR 应付用户，这个分录规则是确定的、不变的。
但真实业务里，“正常”本身就是流动的。新支付渠道上线（比如数字人民币），科目体系要新增；结算周期调整，月末的分录规则要变；跨境电商业务扩展，币种和税务处理跟着改。DGI 学的是一个”平均正常”，但真实世界里没有平均正常，只有条件正常——对什么商户、在什么时间、用什么渠道，“正常”各不相同。
反馈闭环的设计——硬反馈让模型”只学正常”——隐含了一个假设：正常的模式是有限且可穷举的。但支付行业的业务模式迭代速度，远超任何模型的学习周期。今天的新业务，明天就是常态；昨天的异常，今天可能是合规创新。“只学正常”在理论上成立，在业务上不成立。
工程补偿的陷阱
12 个步骤、5 种反馈、3 层聚类、4 种评估策略——这个系统的复杂度不是为了解决业务问题，是为了补偿模型能力的不足。
DGI 不理解业务语义，所以需要多维度标注来补。DGI 无法解释为什么异常，所以需要决策树聚类来补可解释性。DGI 对新型异常零样本能力差，所以需要硬反馈持续清洗数据。向量搜索延迟高，所以加 LSH Hash 化。时序分析基线漂移，所以加滑动窗口动态调整。
每一步补偿都是合理的，但补偿摞补偿，系统越来越重，核心问题始终没解决——模型本身不理解它在看什么。
这不是 DGI 的错。DGI 的设计目标就是”学习图结构的嵌入表示”，它从未承诺过”理解业务语义”或”解释异常原因”。我们给它加了一层又一层的补偿，不是因为它失败，而是因为我们对它的期望超出了它的能力边界。
2026 年的理解：嵌入能力、实时性、结构化推理——这些 DGI 擅长的东西，今天依然有价值。问题不是”DGI 该被什么替代”，而是”DGI 该做什么、不该做什么”——这个边界，2024 年的我们没有划清楚。
模拟数据的边界
AUC 0.7956 在模拟数据上很漂亮，但模拟数据的异常是”设计好的”——5 种类型、固定比例、明确标签。真实生产环境的异常从来不是设计好的：新型欺诈每天都在进化，内部人员的挪用手段比模拟数据复杂十倍，系统 bug 导致的异常连攻击者自己都预料不到。
模拟数据给了我们”可控的异常”，但也给了我们虚假的掌控感。我们用 5 种异常类型训练了评估体系，但生产环境第 6 种异常出现时，整个体系没有预警机制——因为”第 6 种”不在设计范围内。
这不是模拟数据的问题，是怎么用模拟数据的问题。当时把它当作”真实”来验证，而不是当作”边界测试”来探查。模拟数据应该用来验证”已知异常能否被抓到”，而不是用来证明”系统能抓到所有异常”。
知识蒸馏的幻觉
月度融合用知识蒸馏保留 30 个日模型的”暗知识”——soft target 里的概率分布。当时觉得这个设计很精妙，但 2026 年回头看，暗知识的前提是 Teachers 有知识可传。
如果日模型本身对某种新型模式没有概念，蒸馏只是把”无知”平均化了。30 个模型对同一个样本都输出 0.51 的置信度，蒸馏后 Student 输出 0.51——这不是知识传承，是无知的一致性。
更根本的问题：日级模型训练数据只有一天，样本量小，模型本身就不稳定。30 个不稳定的模型融合成一个，不是”集思广益”，是”集体幻觉”。热启动传递的不只是知识，还有偏见。
五、不是忏悔，是认知的地层学
写这篇不是为了否定 2024 年的工作。恰恰相反，这个项目的价值不再是”一个异常检测系统”，而是**“一个时代的标本”**。
它标本化了 2024 年深度学习工程师的集体认知：
- 我们相信”无监督学习”能解决标注稀缺问题——不是因为无监督最好，是因为标注成本太高、周期太长
- 我们相信”知识蒸馏”能融合多个专家的智慧——不是因为蒸馏最优雅，是因为 30 个模型部署不起
- 我们相信”反馈闭环”能让系统自适应进化——不是因为闭环最科学，是因为人工标注跟不上业务变化
- 我们相信”工程完备性”能补偿模型能力的不足——不是因为工程比模型重要，是因为模型确实做不到
这些信念在 2024 年都是合理的。它们不是”错误的选择”，是在具体约束下的最优解。标注稀缺、部署成本高、业务变化快、模型能力有限——这些约束今天依然存在，只是解法变了。
2026 年回头看，这个项目的真正价值不是”它做对了什么”，而是**“它为什么只能这样做”**。理解约束，才能理解选择；理解选择，才能理解局限。
不是 DGI 错了，是问题的定义方式变了。2024 年我们问”如何让模型学习正常模式”，这个问法本身隐含了一个假设：模型学习到了，就能解决问题。2026 年我们知道，嵌入表示只是中间产物，怎么用它、在什么场景下用、和什么能力配合——这些才是问题。
当时的每一个务实选择，都定义了系统的能力边界。 日级模型选择了时效性，就放弃了稳定性；Hash-Hot 选择了可扩展性，就放弃了语义丰富度；反馈闭环选择了自动化，就接受了噪声放大。这些权衡不是失误，是工程的本质——在约束条件下做选择，然后承担选择的代价。
2026 年回头看，这个项目的真正收获不是”它做错了什么”，而是**“它让我理解了约束的重量”**。理解标注稀缺，才能理解为什么无监督是务实的；理解部署成本，才能理解为什么蒸馏是必要的；理解业务变化，才能理解为什么反馈闭环是脆弱的。
不是 DGI 过时了，是我对问题的理解更深了。 2024 年我问”如何让模型学习正常模式”，2026 年我问”嵌入表示在什么场景下最有价值、和什么能力配合最有效”。同一个项目，不同的问题，不同的答案。城堡还在那里，但我学会了在它周围画边界。
六、预告：这个系列还有三篇
这篇是炼丹笔记——复盘 2024 年的工程选择。
下一篇是**「一夜变天」**——2024 到 2026 年，LLM 如何从”玩具”变成”基础设施”。我的 DGI 项目哪些部分被一夜颠覆，哪些部分意外幸存。具体来说：DGI 的实时性优势为什么依然有价值？DGI 的语义理解短板如何被 LLM 补齐？以及一个反直觉的发现——LLM 让某些”过时”的技术反而变得更重要了。
第三篇是**「通用与垂直」**——BOUND 原则的诞生，本质上是在回答”通用能力 + 垂直约束”如何融合。从 DGI 的”硬编码规则”到 BOUND 的”概率性边界”，是个人认知的进化，也是整个行业从”模型中心”到”系统中心”的缩影。
第四篇是**「温故知新」**——如果用 2026 年的认知重做这个项目。不是用 LLM 替代 DGI，而是 DGI + LLM 的融合架构：DGI 做实时特征提取和结构化推理，LLM 做异常解释和新型模式发现。具体设计，具体代码，具体权衡。
四篇连读，从”我当年怎么想的”到”我今天会怎么做”——但真正的收获，可能在于中间那条认知跃迁的路径。
“2024 年的我，用 12 步 pipeline 对抗不确定性。2026 年的我，用 5 个字母（BOUND）管理不确定性。不是因为我变懒了，是因为我理解了——不确定性不是敌人，是系统的原生约束。”
“DGI 项目像一座城堡，每一块砖都砌得工整。但城堡建在了即将漂移的地基上。2026 年我不是拆掉了城堡，而是在城堡周围画了一条新的边界。”
“技术考古的价值，不是证明过去错了，而是证明——当时的’对’，已经包含了’错’的种子。”
本文首发于「谢先生的 AI 深析札记」