这个方案听起来很诱人：将遗留记录输入 LLM，描述目标 Schema，让模型自行找出字段映射。无需手写解析器，无需数月的转换逻辑，也不依赖领域专家。已有团队实践后，在传统 ETL 所需时间的一小部分内达到了 70–97% 的准确率。问题在于，剩余 3–30% 的失败不像失败——它们看起来像是正确的数据。
这种不对称性——错误输出在结构上是合法且合理的——才是让 LLM 驱动的数据迁移在没有正确验证架构时真正危险的根源。本文介绍了那些成功落地的团队实际构建了什么：LLM 在流水线中的适用场景、它静默出错的地方，以及能捕获传统工具无法发现的错误的验证层。
LLM 用于数据迁移的理由是真实存在的
传统 ETL 流水线写好后是确定性且高效的，但前提是有人先理解每一种源格式变体、每个隐式编码决策、每个在不同上下文中含义不同的字段。对于那些早于任何 Schema 规范的遗留系统迁移——扫描文档、CRM 自由文本备注、异构供应商数据——这种理解可能需要数月。
LLM 大幅压缩了这一过程。人工分析师需要阅读 10,000 条样本记录才能枚举"电话号码"字段的格式变体，LLM 一次即可处理完毕。将地址跨 15 种国际格式归一化的解析器需要数周才能写完，而一个提示词完善的模型一个下午就能搞定。Airbnb 将 3,500 个测试文件从一个框架迁移到另一个，六周内达到 97% 的完成度——如果靠人工重写，所需时间会长得多。
行之有效的模式是混合方案：用 LLM 处理语义上困难的工作（从模糊输入中提取、跨异构来源归一化、基于意图的字段映射），用传统 ETL 处理确定性工作（过滤、聚合、数值计算、引用完整性约束）。LLM 不是替代 ETL，而是处理 ETL 无法编写规则的那些案例。
你需要了解的静默失败模式
这正是团队翻车的地方。LLM 在数据转换中的错误不是统计测试能捕获的随机噪声，而是特定领域的合理性错误：输出通过了格式验证、类型检查、行数校验，但就是错的。
迁移金融记录的模型可能正确识别一个字段是"利率"并输出一个小数值——但悄悄地将年利率与日利率搞混，或误解遗留系统对有符号值的编码方式。输出是一个数字，类型正确，下游系统无声地摄入它。三个月后，报表出现偏差。
医疗迁移可能对 99.8% 的记录正确归一化临床术语，然后在含有模糊缩写的记录上，将一个语义上相邻但临床上截然不同的术语替换进去。行数匹配，Schema 验证通过。后来某位统计学家从一个被微妙偏移的分布中得出了错误结论。
这种失败模式在研究文献中有一个名字：解释过度自信。模型不会凭空捏造；它们会添加无根据的描述、将被归因的陈述转化为一般性主张，并应用合理但不正确的领域特定解释。这类错误规避了代码检查、解析和结构验证，只有针对实际业务规则的语义验证才能捕获它们。
MIT 研究人员发现，LLM 是从句法模式而非真正的语义理解进行推理——模型可以正确回答一个概念的问题，但在结构上相同却语义上不同的查询上失败。在数据迁移中，这意味着在金融数据上训练的模型可能正确处理标准案例，然后对未见过的边缘案例应用错误逻辑，而没有任何信号表明它正在这样做。
真正有效的验证架构
成功落地生产的团队至少运行三层验证，而不是一层。
结构验证是基线：行数、类型检查、空值约束、引用完整性。这是基本要求，能捕获格式错误，但无法捕获语义错误。
基于语义审查的抽样检查是大多数团队投入不足的层级。关键在于样本必须针对业务规则而非仅针对 Schema 合规性进行审查。10% 记录的随机抽样需要由理解数据含义的人来评估，而不仅仅是了解其格式的人。Airbnb 的"抽样、调优、扫描"循环——运行所有失败案例，挑选 5–10 个代表性案例，更新提示词，验证修复，再次扫描——是一个有用的模式。这种迭代在做语义工作，而不只是修复格式错误。
统计分布检查能捕获逐条审查会遗漏的细微整体偏移。迁移前后，关键字段的分布应该匹配。值频率、数值范围、字段间的共现模式——如果迁移在语义上是正确的，数据的统计指纹应该被保留（或仅以迁移有意更改的方式发生变化）。在统计层面交叉验证源和目标的自动化 diff 工具，能捕获逐行抽样需要很长时间才能发现的错误。
多轮一致性检查在模型友好的成本下越来越实用。用不同提示词运行两次相同的转换并比较输出。不一致之处将记录标记为人工审查。这在计算上很昂贵，但对于高风险迁移——金融数据、医疗记录、法律文件——它比数据质量事故便宜得多。
基于 Schema 的提示优于自然语言
LLM 驱动的数据转换中最具影响力的单一实现选择，是你如何指定映射。用自然语言描述转换（"将地址字段转换为标准格式"）的团队得到了不一致的结果和脆弱的流水线。提供带有显式类型定义、枚举约束、必填字段和空值处理的 JSON Schema 的团队，得到了更可预测、更易跨模型提供商移植、更易验证的结果。
基于 Schema 的提示激活了模型在结构化数据和代码上的训练，而不是在散文上的训练。它在定义层面消除了歧义，而不是试图在后处理中恢复。它还直接与 Schema 验证库集成——你的验证层可以机械地针对你给模型的同一 Schema 检查输出，而不必为每个字段编写自定义验证。
权衡是 token 成本。指定完整的 JSON Schema 是冗长的。在迁移规模下，这会累积。实际的答案是：对于对业务逻辑和准确性最重要的字段使用基于 Schema 的提示，对于错误成本低的低风险描述性字段使用自然语言。
处理准确性与可审计性的冲突
对于受监管的行业——金融、医疗、法律——LLM 驱动的迁移与合规要求之间存在结构性张力。传统 ETL 是确定性的：相同输入总是产生相同输出，你可以在多年后重现任何转换。LLM 则不然。提示词更改、模型更新和非零温度都意味着重新运行迁移流水线可能产生不同的输出。
这在合规性方面有两方面影响。首先，审计跟踪不仅需要记录发生了什么，还需要能够重现它——而"我们在 2025 年 3 月使用了 GPT-4o"不足以在 2025 年 11 月模型更新后重现结果。其次，监管机构越来越需要记录产生数据的逻辑，而"LLM 决定了"不是文档。
解决方案是将 LLM 流水线视为代码而不是服务。将提示词、模型版本和每个配置参数作为制品进行版本控制。对于合规敏感的迁移，冻结模型版本（使用固定快照，而不是持续更新的在线端点）。将转换逻辑记录为可执行规范——如果 LLM 正在做一个需要可辩护的选择，该选择应该编码在可读、可审查和可重现的后处理规则中。
将开发迭代（优化提示词以提高准确性）与生产合规运行（配置冻结，每个输入、输出和中间状态都被记录）分开。发布到合规敏感生产环境的内容应该更像一个编译制品，而不是一个实时推理请求。
基准测试实际显示了什么
供应商案例研究中的头条数字——处理速度提高 102 倍、迁移时间缩短 80%、开箱即用准确率 70%——是真实的，但需要背景来解读。
多个实现中的 70% 开箱即用准确率意味着 30% 的记录在迁移达到生产安全之前需要人工审查或迭代提示词优化。这不是批评；传统 ETL 在异构遗留数据上的起点通常更低。但这确实意味着 LLM 驱动的迁移不是一次性过程，你需要为迭代循环做好准备。
Airbnb 达到的 97% 是经过六周迭代后的结果，包括对最困难案例的有针对性人工干预。剩余的 3% 需要了解领域的工程师。对于结构化、文档完善的源数据，你可以更快达到这一水平。对于有几十年未记录编码决策的复杂遗留系统，六周可能是乐观的估计。
最近一项对 LLM 代理端到端 ELT 流水线生成的基准测试发现，复杂多步骤任务的失败率高达 96%。这并不矛盾——LLM 作为数据迁移流水线中的组件表现良好，尤其是对于特定转换任务。当被要求在没有人工检查点的情况下自主生成完整、正确的流水线时，它们会遇到困难。教训是在高复杂度步骤上保持人在回路中，而不是将其自动化掉。
不应用 LLM 做的迁移
有些数据迁移中，LLM 增加了成本而没有增加价值，风险状况也不合适。
确定性转换——将 Unix 时间戳转换为 ISO 8601、对两个数值字段求和、按键连接记录——没有 LLM 需要解决的歧义。基于规则的转换更快、更便宜、更易审计。在这里引入 LLM 推理增加了延迟、成本和合理性错误的攻击面。
错误成本是灾难性且记录无法被外部验证的迁移——某些金融审计跟踪、特定医疗记录——需要不同的风险态度。不对称的错误状况（看起来正确的错误）意味着你需要极高覆盖率的人工审查或强有力的独立验证来源。如果无法构建这些，LLM 驱动迁移的效率收益无法证明风险是合理的。
实践起点
对于开始这项工作的团队：从手动解析最困难且出错后果最小的字段开始。在运行第一次 LLM 通过之前先构建语义验证层——事后验证比从一开始就将检查设计进流水线要难。在迁移开始之前将 go/no-go 标准定义为量化阈值（错误率低于 0.01%，统计分布在源数据的 X% 以内），而不是在你已经投入了一次想要发布的运行之后。
基于 Schema 的提示、混合架构和语义验证层不是可选的质量改进，而是迁移能够发布与发布后六个月内悄悄损坏数据之间的区别。
LLM 驱动的数据迁移对于传统 ETL 失败或耗时过长的困难案例确实有用。让它成功的团队将其视为一个工程问题——有明确的成功标准、分层验证和受控迭代——而不是一个提示即发布的自动化。当验证架构就位以捕获其出错之处时，这项技术才在流水线中赢得了它的位置。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
