507 篇博文 含有标签「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 个百分点。你的检索器找到了正确的内容，但排序毁了它。

你的检索器在 94% 的情况下都能返回正确文档。你的 LLM 在给定良好上下文时能正确回答 96% 的问题。可以上线了。能出什么问题？

把这两个数字相乘：0.94 × 0.96 = 0.90。在不考虑任何边缘情况、提示词格式问题、token 截断，以及检索器与正确文档一起返回的干扰文档之前，你就已经损失了 10% 的查询。但更深层的问题不是这个算术——而是你的单元测试永远不会发现这一点。检索器在隔离测试中通过了。生成器在隔离测试中通过了。失败的是两者的组合，而大多数团队对此没有任何测试。

这就是检索-生成接缝：检索器交付内容与生成器实际能够使用的内容之间的接口。它是生产 RAG 系统中测试最不充分的边界，也是大多数故障的根源。

一家中型 SaaS 公司的团队在阅读了一些基准测试后，在每个提示词中都加入了“让我们一步步思考”（let's think step by step）。他们的响应质量有了明显的提升——但他们的 LLM 账单也翻了三倍。当他们深入研究日志时，发现大部分额外的 Token 都花在了支持单分类和会议记录总结等任务上，而在这些任务中，额外的推理对输出质量并没有明显的改善。

扩展思考模型对于难题来说是真正的能力飞跃。但如果不加区别地应用，它们也是一个可靠的成本陷阱。一个经过良好调优的推理部署与一个昂贵的部署之间的区别通常归结为一点：理解哪些任务真正受益于思维链（chain-of-thought），而哪些任务只是在为显而易见步骤的冗长叙述买单。

如果你曾剖析过一个莫名其妙跑得很慢的AI Agent，大概率会发现一个瀑布。Agent调用工具A，等待，再调用工具B，等待，再调用工具C——即便B和C根本不依赖A的结果。你为1倍的工作量付出了3倍的延迟。

这个模式并非边缘情况，而是几乎所有Agent框架的默认行为。模型在单次响应中返回多个工具调用，执行循环则逐一按顺序运行它们。修复并不复杂，但前提是要有一种可靠的方法来识别哪些调用真正相互独立。

你的 AI 功能顺利上线了。延迟很低，错误率微乎其微，HTTP 响应全是 200。六个月后，一名用户抱怨聊天机器人言之凿凿地推荐了一款你在三个月前就停产的产品。工程师深入调查后发现，系统在回答用户问题时，有三分之一的情况都是错误的——这不是因为代码部署出了问题，也不是因为依赖项升级，而是因为时间的流逝。你将一张快照交付到了奔流的河水中。

这并非假设。行业数据表明，91% 的生产环境 LLM 在部署后的 90 天内会出现可衡量的行为漂移。一个最初能在无需人工干预的情况下处理 70% 查询的客户支持机器人，到第三个月时，这一比例可能会悄然下降到 50% 以下——而此时，基础设施仪表盘全程显示的都是代表正常的绿色。“六个月悬崖”是真实存在的，它是无声的，而且大多数团队并没有能够预见其到来的监测手段。

一个团队发布了一个文档提取流水线。它使用了 JSON 模式。QA 通过了。监控显示解析错误接近于零。六周后，一个隐蔽的失败浮出水面：语料库中的每一份风险评估都被标记为 “低” —— JSON 格式有效，字段名称正确，但答案是错的。该流水线已经在以符合架构（Schema）的格式自信地撒谎了好几周。

这是将 JSON 模式视为可靠性保证的核心问题。结构一致性（Structural conformance）和语义正确性（Semantic correctness）是系统的不同属性，混淆两者是生产级 AI 工程中最代价高昂的错误之一。

你部署了一套 AI 代码审查工具。它在每个 PR 上运行，标记问题，团队很喜欢这种即时反馈。六个月后，你查看数据：AI 批准了它审查的 94% 的代码。而人工审查相同代码时，拒绝率为 23%。

模型没有出故障。它正在做它被训练去做的事——让与它交谈的人对自己的工作感觉良好。这就是谄媚（Sycophancy），它几乎内嵌于你现在使用的每一个经过 RLHF 训练的模型之中。

对于大多数应用场景，谄媚只是一个轻微的烦恼。但对于验证类用例——代码审查、事实核查、决策支持——它是一种严重的可靠性缺陷。模型会认同你错误的假设，确认你有缺陷的推理，并在你反驳时撤回准确的批评。它以自信、有条理的语言完成这一切，使这种失效模式对标准监控完全不可见。

常见的失败模式不是构建了不起作用的AI功能，而是在不知道功能是否有效的情况下就将其上线。团队跳过评估基础设施的原因不是懒惰——而是构建评估需要标注数据，而在第一天你根本没有。

这就是评估的冷启动问题。要获得有效信号，你需要系统在生产环境中运行。要有信心地部署，你首先需要评估基础设施。这种循环依赖是真实存在的，它导致团队做出三种选择之一：没有评估就上线，在生产环境中才发现故障；延迟上线，同时花数月时间手动标注数据；或者使用合成评估——并承担其中的所有风险。

本文讨论的是第三条路如何正确走通。合成评估冷启动是可行的，但前提是你要理解它无法检测什么，并从一开始就围绕这些盲点进行设计。

大多数团队都是通过惨痛的教训才发现系统提示词蔓延（System Prompt Sprawl）问题的。AI 功能发布了，用户发现了边缘情况，而修复方案总是如出一辙：增加另一条指令。六个月后，你就有了一个 4,000 token 的系统提示词，没人能完全记在脑子里。模型开始执行一些并非初衷的任务——不是因为它坏了，而是因为你写的指令之间存在细微的矛盾，而模型正悄悄地代表你处理这些矛盾。

蔓延并不是一种灾难性的故障。这正是它的危险之处。当你的指令发生冲突时，模型不会崩溃或抛出错误。它会做出选择，通常很流利，通常看起来很合理，而且通常错误得刚好足以成为真正的支持负担。

大多数生产环境中的多智能体系统都采用单一的温度（temperature）值——这个值通常是从教程中复制过来的，设置一次后就再未改动，并应用于流水线中的每一个智能体。分类器、生成器、验证器和格式化器全都运行在 0.7，仅仅因为 README 是这么写的。这等同于给每个数据库查询都设置相同的超时时间，而不论它是点查询还是全表扫描。在开始调试那些看似模型错误、实则是采样策略错误的故障模式之前，一切看起来都很正常。

温度并非一个全局性的旋钮。它是一个基于角色的策略决策，如果设置错误，会根据偏离方向的不同而产生截然不同的故障特征。