720 篇博文 含有标签「llm」

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

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

模型卡显示代码生成准确率为 89%。你的团队在实际代码库上只得到了 28%。模型卡显示有 100K token 的上下文窗口。而在你的文档工作负载下，性能在 32K 时就大幅下降。模型卡通过了红队安全评估。但在上线后的 72 小时内，针对用户的提示词注入攻击就出现了。

这种差距并不罕见。这已成为常态。在 2025 年对 1,200 个生产部署的分析中，42% 的公司在生产集成阶段放弃了他们的 AI 计划 —— 高于前一年的 17%。他们中的大多数都仔细阅读过模型卡。

问题不在于模型卡撒谎。而在于它们衡量的内容与你需要了解的内容不同。准确理解这一差距 —— 并构建内部基准测试套件来弥补它 —— 是交付可靠 AI 的团队与交付懊悔的团队之间的分水岭。

你接手了一个基于 GPT-4-turbo 构建的 AI 功能。该模型即将被弃用。你的经理希望通过切换到更新、更廉价的模型来降低成本。你快速跑了一遍测试，指标看起来还过得去，于是就上线了——结果一周后，核心用例的准确率下降了 22%。支持工单不断攀升。你现在面对的是一场危机式迁移，而非有计划的操作。

这就是模型可移植性税：每当你将应用逻辑与某个特定基础模型紧耦合时，就会累积的隐性工程成本。每个团队都在为此买单，大多数人直到账单到来时才意识到数字有多大。

你的 LLM 通过了你投喂的所有评估。延迟很稳定，准确率看起来不错，团队充满信心。然后一个开罗的用户提交了一个 bug：结构化提取返回了格式错误的 JSON。首尔的一名开发者注意到，助手在几轮对话后就开始忽略复杂的指令。孟买的一名产品经理意识到，聊天机器人的摘要是完全错误的——虽然微妙，但始终是错误的。

这些都没有在你的基准测试中显现出来，因为你的基准测试是用英语进行的。

这就是多语言质量悬崖：一种剧烈的、系统性的性能下降，而且对于发布 AI 产品的团队来说，这种下降几乎普遍是不可见的。差距并不微小。在长多轮对话中，阿拉伯语和韩语用户在任务中的准确率约为 40.8%，而英语用户则为 54.8%——这 14 个百分点的差距会随着每一轮对话而叠加。对于结构化编辑任务，同样的差距会扩大到灾难性的程度：32–37% 的准确率，而英语表现则是可接受的。用户能感觉到这一点。你的仪表盘却感觉不到。

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

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

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

当团队部署 AI 安全过滤器时，对话几乎总是集中在它拦截了什么。它是否拦截了越狱攻击？它是否标记了仇恨言论？它能检测提示词注入吗？对于召回率（Recall）来说，这些都是正确的问题。但它们几乎从未与另一个同样重要的问题挂钩：它错误地拦截了哪些不该拦截的内容？

答案通常是：很多。由于大多数团队在发布时都使用供应商的默认阈值，并且从未在生产环境中对误报（False Positives）进行监测，他们直到用户开始抱怨时才会发现——或者直到用户停止抱怨，因为他们已经停止使用该产品了。

大多数团队将LLM隐私视为一个二元选择：要么将数据发送到云端并承担风险，要么在本地运行所有内容并承担成本。这两种框架都是错误的。实际上存在一个风险特征和工程预算差异显著的方法光谱——大多数团队在这个光谱上的位置是错误的，却浑然不知。

研究人员最近证明，他们可以以每条记录0.012美元的成本，以48.9%的成功率从3912人中提取真实PII。这个统计数字往往被当作学术威胁建模而被忽视，直到安全审计或合规审查落到你的桌上。问题不是是否要关注LLM隐私，而是哪些控制措施真正能改变局面，以及每种措施的实施成本。

你的 AI 功能在内部测试中表现出色。工程师拍手叫好，产品经理竖起大拇指，评估套件在基准测试中显示了 94% 的准确率。然后你上线了，两周之内，用户就遇到了你从未见过的故障模式——错误的答案、混乱的输出，以及让模型显得极为糟糕的边缘情况。

这就是生产分布差距（production distribution gap）。这不是一个新问题，但对 AI 系统来说，它比确定性软件严重得多。理解其背后的原因——并制定具体的解决方案——是决定 AI 功能悄然侵蚀用户信任还是随着使用不断改进的关键分水岭。

当你的团队第一次启用提示缓存时，感觉就像凭空得到了钱。几小时之内，token成本下降了40–60%，延迟也随之缩短。工程师们欢欣鼓舞，然后继续前行。三个月后，有人注意到成本悄悄地爬回去了。从72%起步的缓存命中率现在只剩18%。没有人故意破坏它，没有人注意到。

这是生产LLM部署中最常见的轨迹：缓存只被启用一次，从不被监控，随着代码库的演进而悄然退化。缓存命中率是LLM技术栈中最具影响力的成本杠杆，但大多数团队把它当作一次性的设置任务，而非生产指标。

三个词。就这么多。

一个团队在现有 prompt 中添加了三个词，目的是改善"对话流畅性"——这个调整在 playground 里看起来无害。几个小时内，结构化输出错误率急剧攀升，一个创收工作流停止运作，工程师们争相还原 prompt 改动前的内容。没有版本历史，没有回滚机制，只有一条 Slack 消息，来自某个"大致记得"内容的人，以及一份与 Google 文档中过时副本的 diff。

这不是假设场景，而是几乎每个规模化交付 LLM 功能的组织都在重复经历的模式。Prompt 从应用代码中的字符串起步，经过非正式编辑演化，积累了无文档记录的微小调整，最终到达无人确信生产环境里运行着什么、也不知道为何如此表现的状态。

解决方案不是一个新工具，而是对团队一直以配置文件方式对待的东西施加工程纪律。

询问大多数工程师为什么在生产环境中使用 Few-shot 提示词，你会听到类似这样的回答：“它看起来效果更好。” 询问他们为什么要加入思维链（Chain-of-thought），答案通常是：“我读到过它有助于推理。” 这些回答并不完全错误。但它们只是披着工程外壳的惯例。关于每种提示词技术何时真正胜出的证据已经足够具体，你可以系统性地做出决定——而正确的选择可以将 Token 成本降低 60–80%，或者防止你甚至没察觉到的性能退化。

以下是研究结果，以及如何将其应用到你的技术栈中。

你花了数周时间调优嵌入模型。检索精度看起来不错。分块大小、重叠、元数据过滤器——一切都已调整到位。然而用户不断反映，系统"忽略"了它明明能访问的信息。相关段落每次都出现在 top-5 检索结果中，模型就是不用它。

罪魁祸首往往是位置偏差（position bias）：语言模型倾向于过度依赖上下文窗口开头和结尾的信息，而对中间内容的注意力显著不足。在受控实验中，将相关段落从 20 篇文档上下文中的第 1 位移至第 10 位，准确率会下降 30-40 个百分点。你的检索器找到了正确的内容，但排序毁了它。