LLM 驱动的数据迁移：大规模实践中真正有效的方法
这个方案听起来很诱人：将遗留记录输入 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 工具，能捕获逐行抽样需要很长时间才能发现的错误。
多轮一致性检查在模型友好的成本下越来越实用。用不同提示词运行两次相同的转换并比较输出。不一致之处将记录标记为人工审查。这在计算上很昂贵，但对于高风险迁移——金融数据、医疗记录、法律文件——它比数据质量事故便宜得多。
