知识图谱如何帮助映射 3,500 万行大型机代码

Stephen Chin 说，现代银行应用背后往往是老旧大型机，运行着夜间批处理、业务规则和数据契约。当周边依赖不清楚时，修改一行代码都有风险。

Chin 回忆数十年前将 COBOL 迁移到 Java 的经历：项目耗时数年，不完整的测试让边界问题难以发现。他请 Blitzy 的 Neeraj Deshmukh 介绍另一种方法。

Deshmukh 以公开的 AWS CardDemo 系统和利息计算为例。批处理调用程序，程序使用 copybook 和布局并写入 VSAM 数据；结果取决于所有这些关系，而不仅仅是公式。

如果只要求 AI 将 COBOL 公式翻译成 Java，它可能生成看似合理的代码，却漏掉记录精度、账户更新、交易输出和批处理契约。问题在于缺少系统上下文，而不只是语法转换。

Chin 认为，更大的上下文窗口或相似度搜索不一定能找回变更所需的全部依赖。图可以沿多层关系检索相连信息；两位讲者将其作为模型的补充。

他说模型可能只能有效利用标称上下文的一部分，因此应用应提供准确、相关的证据。他在演讲中的数字是经验判断，不是所有模型或任务的统一上限。

Deshmukh 将作业、程序、copybook、字段和数据存储映射为知识图谱。每条关系保留仓库、版本、符号和来源证据；图谱随代码变化而更新。

每个 agent 收到针对任务的上下文包，其中包括相关源码片段、约束、证据和未解决问题。目标是在需要时获取正确信息，而不是把整个代码库放进一个提示词。

Blitzy 将其流程称为企业编译器：逆向理解系统，提取工作流和业务逻辑，结合用户需求生成 agent 行动计划，再由人审阅计划后生成代码。

agent 在整个过程中生成并验证代码，产出拉取请求和证据文档。Deshmukh 说，访问仓库与构建环境还使系统能够观察运行时行为，而不只依赖静态分析。

该架构把数千个 agent 共用的计划与持续测试结合起来。Deshmukh 说，Blitzy 用于测试的计算资源多于代码生成，而人在重要检查点保留决策权。

行动计划定义改造范围及必须保留的行为。讲者提出的控制措施包括系统上下文、持续验证、安全与治理护栏，以及人工监督。

一致性包括金额精度和舍入、余额、交易记录、失败情况及运行行为。已有缺陷也需要明确决定：悄悄修改它们可能改变业务结果。

团队用相同输入比较旧系统与新系统的返回值、持久状态、交易输出和错误。Deshmukh 说，验证贯穿单元、集成、数据和端到端测试，而不是留到最后。

舍入示例说明了原因：Java 翻译结果可能可以编译、看起来正确，却与 COBOL 行为相差一美分。讲者说一致性测试发现了差异；在大规模交易中，微小差异可能累积。

Deshmukh 展示一家银行的交易入账案例：单体系统被转换成使用 PostgreSQL 和多种语言的六个模块。他称项目耗时 18 天、编写了 4,000 多项测试，而客户原估计为 18 个工程师周。

他称，在此前系统集成工作耗费数月之后，Blitzy 用四天映射了约 3,500 万行大型机代码。这是供应商的案例说法；映射系统与迁移每一行代码是不同的工作。

对于另一个 2,500 万行的保险平台，Deshmukh 报告了九倍速度提升，并给出自动完成与生产接纳比例。演讲没有独立证明这些结果是否具有普遍性。

讲者说，现代化完成后，同一知识层还可以支持新功能、安全工作和合规证据。例如，促销利率功能可以复用更新后的图谱、治理规则和扩展测试。

Chin 最后介绍了将业务规则和流程连接到系统的知识层。他认为，除了最初的现代化任务，它还可能用于监管合规和欺诈分析。

两位讲者推荐知识图谱课程和包含公开 CardDemo 示例的沙盒，邀请团队用自己的代码探索这种方法。