18 篇博文 含有标签「data-engineering」

你的 RAG 系统存在一个不会抛出异常的 Bug。它不会拉高错误率，不会在延迟仪表盘上留下痕迹。相反，它会悄悄地给出听起来自信、合理却错误的答案——而没有人在数周内察觉。

这就是 RAG 中的数据契约问题：你的摄取管道是下游所有环节的事实来源，但它没有 Schema 校验、没有新鲜度保障，也没有在外部世界的形态悄然改变时发出告警。每当上游数据源新增字段、分块参数发生偏移，或者嵌入模型被更新，检索质量就会无声地退化。

80% 的企业级 RAG 项目在生产环境中会遭遇严重故障，而其中最隐蔽的那些故障从不宣告自身的存在。

AI 功能拥有仪表板。提示词（Prompt）有版本控制。评估套件（Eval suite）有轮值表。然后是一个写于 2022 年的上游定时任务（cron job），由一个在两次重组前就退出了分析部门的团队负责，它生成了构建你的检索索引所需的 CSV 文件。那个定时任务没有 SLA。那个 CSV 没有 Schema 契约。负责它的团队根本不知道它正在为一个 AI 功能提供数据。当它发生变化时——它一定会变——AI 团队将花费三周时间去调试一个完全没有出错的提示词。

你即将追踪的 AI 质量回退几乎从来不是 AI 问题。它是一个穿着 AI 外衣的 ETL 问题。需要落实的规范是两者之间的衔接点——契约、血缘（lineage）、新鲜度信号、成对的轮值——而没有将其正式化的团队，所交付的 AI 功能的可靠性将受限于公司里最不受待见的定时任务。

两年前，一个团队将他们的检索索引指向了 Wiki、Zendesk 导出文件以及公共文档的快照。上周，同一个索引返回了一个已弃用的运行手册（runbook），告诉 SRE 去重启一个已不存在的服务。该运行手册已经废弃了 18 个月。没人负责它的下线工作，所以没人把它删掉。Agent 自信地引用了它。模型没有错；错的是语料库（corpus）。

这是检索评估（retrieval evals）中不会出现的故障模式：语料库被视为一次性的工程决策，而实际上它是一个持续的治理问题。负责初始摄取（ingestion）的团队早已解散。本应标记出客户机密 PDF 的法律审查从未发生，因为没人告诉法务部门存在这个流水线（pipeline）。“新鲜度策略”（freshness strategy）只是一个在第三季度离职的人留下的 Slack 消息。检索索引变成了任何人抓取过的每一份文档的共享收件箱，而纳入标准已逐渐演变为“任何容易摄取的内容”。

这个方案听起来很诱人：将遗留记录输入 LLM，描述目标 Schema，让模型自行找出字段映射。无需手写解析器，无需数月的转换逻辑，也不依赖领域专家。已有团队实践后，在传统 ETL 所需时间的一小部分内达到了 70–97% 的准确率。问题在于，剩余 3–30% 的失败不像失败——它们看起来像是正确的数据。

这种不对称性——错误输出在结构上是合法且合理的——才是让 LLM 驱动的数据迁移在没有正确验证架构时真正危险的根源。本文介绍了那些成功落地的团队实际构建了什么：LLM 在流水线中的适用场景、它静默出错的地方，以及能捕获传统工具无法发现的错误的验证层。

你手写的 ETL 管道处理了 95% 的记录。那些边界情况——带有逗号的货币字符串、格式不一致的日期、不统一的国家代码——流向了你的数据仓库，并悄悄地破坏了你的仪表板。直到季度报告看起来不对劲时，才有人注意到。你又在管道中添加了一个特殊情况。循环往复。

LLM 可以解决这个问题。它们能从原始样本中推断模式（schema），处理任何工程师都预料不到的杂乱边界情况，并能以极短的开发时间将非结构化文档转换为结构化记录。已经有几个团队推出了这种方案。其中一些团队也经历过 LLM 悄无声息地将 "$1,200,000" 转换成 1200 而不是 1200000，在结构完全有效的情况下将严重程度分数从 "high" 切换到 "low"，以及以通过了所有模式检查的方式连接了错误的业务外键。

问题不在于 LLM 不擅长数据工程。而在于它们的失败模式对 ETL 来说恰恰是完全错误的：高置信度、不报错、且输出结构有效。

大多数构建 AI Agent 的团队都在花数周时间调整 Prompt 和评估（evals）、基准测试模型选择以及微调 Temperature —— 而他们真正的瓶颈其实在更深的一层：那个为人类开发者而非 Agent 设计的数据访问层。

这种失配并非细微。像 Hibernate、SQLAlchemy 和 Prisma 这样的 ORM，结合返回分页、单实体响应的 REST API，产生的数据访问模式对自主 AI Agent 来说完全是错误的。其结果是 Token 浪费、速率限制失败、级联的 N+1 数据库查询，以及 Agent 因为无法负担加载所需上下文的成本而产生幻觉。

本文将探讨这一结构性问题，以及一个针对 Agent 优化的数据层究竟是什么样的。

演示每次都能成功。LLM把"显示上个季度收入前十的客户"翻译成完美的SQL，结果瞬间弹出，会议室里所有人都点头认可。然后你把它部署到你实际的数仓上——130张表、1400个字段、十年积累的有机命名惯例——模型开始自信地生成返回错误数字的查询。没有报错，只是答案是错的。

这就是Schema边界问题，也是为什么Text-to-SQL在所有AI能力中，基准测试性能与生产现实之间的差距最大。在Spider 1.0（标准学术基准）上得分86%的模型，在Spider 2.0上准确率下降到约6%，而后者更接近真实企业Schema的复杂度。供应商在干净的玩具Schema上演示，你却要在自己的Schema上部署。

你的RAG流水线正在返回自信、格式良好的答案。大模型的响应看起来很好。然而用户却不断提交工单，说系统给出了错误信息。产品经理调出相关文档——信息六周前就已经更改，但向量索引仍然反映旧版本。没有任何错误抛出，没有任何告警触发。系统只是悄无声息、毫无察觉地给出了错误答案。

这就是嵌入刷新问题，它最终会咬到大多数生产RAG系统。对生产部署的分析显示，超过60%的RAG故障可追溯到知识库中陈旧或过时的信息——不是错误的提示词，不是检索算法失败，而是向量索引中的内容与源数据真实状态之间的简单错位。大多数AI工程师都是吃了亏才发现这个问题的，而大多数数据工程师早就知道如何预防它。

关于生产环境中的 LLM，大多数讨论都围绕着聊天界面、Copilot 和自主代理。但如果你审计企业 LLM Token 的实际消耗去向，你会发现一个完全不同的景象：绝大多数的使用都发生在批处理数据管道（batch data pipelines）中 —— 从文档中提取字段、对支持工单进行分类、规范化混乱的供应商记录、为原始事件添加语义标签。没有人为这个层级编写会议演讲，也没有人认真地对其进行基准测试。而这种沉默正让团队付出真金白银和准确性的代价。

这是从业者最先构建、最后辩护、且监控最少的 ETL 层级。对于大多数组织来说，这也是 LLM 支出杠杆率最高的一层，同时也是产生隐形失败潜力最高的一层。

你的模型精度在某个夜晚突然下降了8%。模型代码没有任何改动，没有发生任何部署，评估套件是绿色的。于是你花了一周时间调整超参数、修改提示词、对比检查点损失——最终有人注意到，三天前特征流水线里落地了一次Schema迁移。一个字段从NULL改成了空字符串。就这样，就是这个变化导致了回退。

这是生产ML系统中最常见的故障模式，与模型质量几乎毫无关系。问题的根源在于大多数团队被坑过之后才会补上的一个结构性缺口：数据版本和模型版本紧密耦合，但它们由不同的工具追踪、归属于不同的团队。

这个 Demo 只需 20 分钟就能构建完成。你粘贴一个 URL，大语言模型（LLM）读取 HTML，结构化数据就从另一端输出了。这感觉就像网页数据提取的未来已经到来。

然后，你以每小时 1,000 页的速度运行它。成本飙升，屏蔽不断积累，提取出的字段开始以一种看起来不像错误的方式发生偏移——它们看起来像正常数据，直到你的下游流水线已经默默地摄取了三周的垃圾。“LLM 读取页面”的模式并没有错，只是它的定价更适合原型的吞吐量。

智能体（Agentic）网页提取确实解决了传统爬虫无法解决的问题。但要将其扩展到概念验证（PoC）阶段之后，需要理解一组与大多数团队预期不同的故障模式。

你的模型表现不佳，于是你开始深入审查训练数据。审查到一半时，你发现两位标注员对同一个边界案例给出了截然相反的标签——而两人都在遵循规范，因为规范本身存在歧义。你修正了规范，重新标注了受影响的样本，重新训练，找回了几个 F1 分数点。两个月后，同样的事情又发生了，只是换了一位标注员和另一个边界案例。

这不是标注供应商的问题，也不是数据质量工具的问题。这是一个基础设施问题——而你还没有把它当作基础设施问题来对待。

大多数工程团队处理标注的方式，就像处理会议室预订系统一样：采购工具、编写规范、雇几名外包人员、交付数据。当你只需要一次性标注数据集时，这套模式还算管用。但一旦标注成为持续驱动线上生产模型的活动——对于几乎所有从原型走向生产的团队而言，这已经是常态——这套模式就会彻底崩溃。