402 篇博文 含有标签「llm」

2025 年 6 月，一名研究员向一位 Microsoft 365 Copilot 用户发送了一封精心编写的邮件。没有点击链接。没有打开附件。邮件送达后，Copilot 在执行例行的总结任务时读取了它，短短几秒钟内，AI 便开始从 OneDrive、SharePoint 和 Teams 中外泄文件——通过将数据编码进它请求“渲染”的图片 URL 中，悄无声息地将内容传输到了攻击者控制的服务器上。受害者对此一无所知。

从传统意义上讲，这并不是一个新奇的零日漏洞（Zero-day）。没有缓冲区溢出，也没有 SQL 注入。该漏洞是架构性的：系统结合了三种能力，这些能力单独看起来像是理所应当的产品功能。但结合在一起，它们就构成了现在所谓的“致命三要素”（Lethal Trifecta）。

你的监控栈能告诉你关于请求率、CPU 和数据库延迟的一切。但它几乎无法告诉你你的 LLM 是否刚刚幻觉出了一个退款政策，为什么一个面向客户的智能体在回答一个简单问题时循环调用了三次工具，或者你的产品中哪个功能正每天悄悄烧掉 800 美元的 Token。

传统的可观测性是围绕确定性系统构建的。LLM 在结构上完全不同 —— 每次都是相同的输入，不同的输出。故障模式不再是 500 错误或超时；而是一个听起来自信且合理、但恰好错误的答案。成本也不再稳定可预测；当一个配置错误的 Prompt 遇到流量高峰时，成本会激增。调试也不再是“在堆栈跟踪中查找异常”；而是“重建为什么智能体在周二凌晨 2 点选择了这条工具路径”。

这正是 LLM 可观测性（Observability）所要解决的问题 —— 而这一领域在过去 18 个月里已经显著成熟。

大多数初次发布 LLM 应用的团队都会犯同一个错误：他们将上下文窗口视为免费存储。模型支持 128K tokens？太好了，塞满它。模型支持 1M tokens？更棒了——把所有东西都扔进去。接踵而至的是在产品真正跑通前三周就提前到达的账单冲击。

上下文不是免费的。它甚至一点也不便宜。除了成本之外，盲目填充上下文窗口实际上会让你的模型变得更糟。一个精简的 300 token 上下文通常优于一个松散的 113,000 token 上下文。这不是极端情况——而是一个有明确名称的文档化失效模式：“中间迷失”（lost in the middle）。管理好上下文是你对 LLM 产品做出的最高杠杆的工程决策之一。

在生产环境中的某个阶段，每个由 LLM 驱动的应用都需要停止将模型输出视为散文，而开始将其视为数据。当你尝试从语言模型中可靠地提取 JSON 对象——并将其输入到下游的数据库、API 调用或 UI 中时——你会发现这有多少种出错的方式。模型会将 JSON 包裹在 Markdown 栅栏中。它会生成一个有效的对象，但遗漏了必填字段。它在多次调用中格式化日期的格式不一致。它会幻觉出枚举值。这些失败中的任何一个都会静默地破坏下游状态。

结构化输出已经从一个事后才考虑的问题演变成生产级 LLM 系统的一等公民。这篇文章介绍了强制执行结构化输出的三种主要机制、各自失效的场景，以及如何在约束下设计高质模式（Schema）。

大多数工程师将提示词（prompts）视为咒语——稍微修改一下措辞，寄希望于它能奏效，然后就此作罢。这在演示阶段（demos）没问题。但在生产环境中，这会导致系统表现不稳定：没人知道为什么模型在周二的表现与周一不同，一次常规的模型更新可能会悄无声息地破坏掉三个功能。正确的提示工程是一门学科，而不是一种仪式。本文涵盖了全栈内容：何时使用每种技术、基准测试（benchmarks）实际显示了什么，以及陷阱在哪里。

当 GPT-4o、Claude 3.5 Sonnet 和 Llama 3.1 405B 在 MMLU 上的得分都在 88–93% 之间时，这个数字究竟能告诉你该部署哪种模型？令人不安的答案是：几乎什么也说明不了。曾经能区分优秀模型与平庸模型的基准测试已经饱和。每个前沿模型都能在测试中取得优异成绩，但它们在生产环境中的表现却大相径庭。基准测试表现与实际效用之间的差距从未如此之大，理解其中的原因对于任何基于 LLM 构建的工程师来说都至关重要。

基准测试之所以显得严谨，是因为它们产生了数字。数字看起来像测量，而测量看起来像真理。但基准测试分数的合法性完全取决于它所测量内容的有效性——而这种有效性往往会以排行榜上鲜有提及的方式崩溃。

当你的智能体在放弃之前，第三次默默地重试同一个损坏的工具调用时，你就会意识到，“仅仅添加工具”并不是一种生产环境的策略。工具调用解锁了真正的能力——外部数据、副作用、保证格式的输出——但使其工作的智能体循环（agentic loop）具有在演示中不会表现出来的尖锐边缘。

这篇文章将探讨这些边缘：循环实际上是如何运行的，悄悄破坏并行执行的格式规则，如何编写能让模型做出正确选择的工具描述，以及如何处理错误以让模型恢复而不是陷入死循环。

大多数 LLM 延迟建议往往会陷入以下两种失败模式之一：要么关注错误的指标，要么推荐的优化过于依赖特定硬件，除非你运行自己的推理集群，否则难以应用。如果你是基于托管 API 或受管推理提供商进行构建，那么这类建议中的大部分都是噪音。

本文专注于真正能产生影响的因素 —— 无论你是否控制整个技术栈，这些技术都适用，且基于生产数据而非基准测试的实验室条件。

这里有一个会让团队措手不及的数学问题：如果你堆叠五个防护栏，且每个的准确率都是 90%，那么你的系统整体正确率并不是 90%——而是 59%。堆叠十个同样准确率的防护栏，正确率会降至 35% 以下。这种复合误差问题意味着，“添加更多防护栏”可能会让系统比添加更少但经过更好校准的系统变得更不可靠。大多数团队只有在搭建了庞大的内容审核流水线，并眼睁睁看着误报率攀升到用户无法忍受的程度后，才会意识到这一点。

对于生产环境的 LLM 应用来说，防护栏并非可选项。在正常条件下，现实世界中大约 31% 的 LLM 回答会出现幻觉，而在法律和医学等受监管领域，这一数字会攀升至 60%–88%。针对现代模型的越狱攻击成功率从 57% 到接近 100% 不等，具体取决于攻击技术。但是，如果将防护栏仅仅视为一种附加的合规复选框，而不是精心设计的子系统，团队最终得到的系统将不断拦截合法请求，却仍然漏掉对抗性攻击。

大多数 LLM 质量问题并非提示词（Prompt）问题。它们是上下文（Context）问题。

你花了数小时打磨完美的系统提示词。你添加了 XML 标签、思维链指令和精细的人设定义。你在一些输入上进行了测试，效果看起来很棒。然后你上线了产品。两周后，你盯着一个工单发呆：智能体一本正经地告诉用户错误的账户余额 —— 因为它检索到了前一个用户的交易记录。模型完美理解了指令，它只是拿到了错误的输入。

这就是提示词工程（Prompt Engineering）与上下文工程（Context Engineering）之间的核心区别。提示词工程问的是：“我该如何措辞？”上下文工程问的是：“模型现在需要知道什么，以及我如何确保它准确获得这些信息？”前者是文案写作，后者是系统架构。

大多数团队在发布他们的第一个 LLM 功能后，会在生产环境中因糟糕的输出而受挫，然后紧急加上护栏进行损害控制。结果是一个脆弱的系统，它会阻止合法的请求，减慢响应速度，并且在关键的边缘情况下仍然失效。护栏值得做好——但天真的方法会以你意想不到的方式伤害你。

以下是实际的权衡取舍，以及如何构建一个不会悄悄破坏你产品的护栏层。

大多数团队在微调的时机上不是太早就是太晚。过早进行微调的团队会花费数周时间在训练管道上，结果却发现一个更好的系统提示就能解决问题。而等待太久的团队则在数百万个重复任务上运行昂贵的 70B 推理，同时接受着一个微调后的 7B 模型能以十分之一的成本击败的准确性。

决策的关键不在于哪种技术“更好”。而在于根据你的具体限制条件——数据量、延迟预算、准确性要求以及任务定义的稳定性——选择合适的工具。下面将介绍如何进行思考。