340 篇博文 含有标签「llm」

大多数初次发布 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 模型能以十分之一的成本击败的准确性。

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

大多数工程师学习提示工程都是倒着来的。他们从“发挥创意”和“一步一步思考”开始，反复迭代一个演示直到它奏效，然后在生产环境中发现模型有 15% 的时间在“幻觉”（胡编乱造），他们的 JSON 解析器每隔几小时就会抛出异常。让聊天机器人令人印象深刻的技术，往往不是让生产系统可靠的技术。

在将 LLM 功能部署到真实系统一年后，以下是真正区分有效提示和在负载下仍能保持稳定的提示的关键。

大多数在生产环境中部署的多智能体 LLM 系统，在几周内就会失败 — 失败并非源于基础设施中断或模型退化，而是因为从一开始就存在的协调问题。对七个开源框架的 1,642 条执行轨迹进行全面分析后发现，在标准基准测试中，其故障率在 41% 到 86.7% 之间。这不是模型质量问题，而是系统工程问题。

令人不安的发现是：约 79% 的故障可追溯到规范和协调问题，而非计算限制或模型能力。即使你换一个更好的模型，你的多智能体管道仍然会以同样的方式崩溃。要理解其原因，你需要仔细审视故障分类。