43 篇博文 含有标签「prompt-engineering」

大多数基于 LLM 构建产品的团队都多付了 60%–90% 的费用。这并不是因为他们使用了错误的模型或提示词效率低下，而是因为他们在每次请求中都在重复处理相同的 Token。提示词缓存（Prompt caching）可以解决这个问题，且只需大约 10 分钟即可实现。然而，它仍然是生产级 LLM 系统中利用率最低的优化手段之一。

实际情况是：每次你向 LLM API 发送请求时，模型都会对提示词中的每一个 Token 运行注意力机制（Attention）。如果你的系统提示词（System prompt）有 10,000 个 Token，且每天处理 1,000 个请求，那么你每天仅为提示词中的静态部分（即永不变化的上下文）就要支付 1,000 万个 Token 的处理费用。提示词缓存会存储中间计算结果（即 Key-Value 注意力状态），以便后续请求可以完全跳过这部分工作。

一个团队在客服提示词中增加了三个词，为了让它“更具对话感”。几小时内，结构化输出错误率激增，一条创收流水线停滞。工程师们花了将近一整天的时间调试基础设施和代码，才有人想到去检查提示词。没有版本历史。没有回滚机制。这三个词的修改是由一位产品经理直接在配置文件中内联完成的，他完全没理由认为这会有风险。

这是一个典型的生产环境提示词事故。类似的戏码在各种规模的公司中上演，其根源几乎总是一样的：提示词被视作临时配置，而不是软件。

大多数构建 LLM 系统的人最初几周都会沉迷于优化提示词。他们进行 A/B 测试，争论该使用 XML 标签还是 JSON，并不断迭代系统提示词，直到模型输出看起来正确的内容。然而，一旦进入生产环境，加入真实数据、记忆和工具调用——模型就会开始出现各种提示词调优无法解决的异常行为。问题从来都不在提示词上。

生产级 LLM 系统的真实瓶颈在于上下文——即模型输入中包含什么信息、以何种顺序排列、信息量有多少，以及这些信息是否与模型即将做出的决策相关。上下文工程是将该输入空间作为系统首要关注点进行设计和管理的学科。它包含了提示工程，就像软件架构包含了变量命名一样：较小的技能依然重要，但它并不能大规模地决定最终成果。

这是一个在采用 AI 编程智能体的团队中不断上演的模式：一位开发者发现 Claude 违反了某条规则，于是他们在 CLAUDE.md 中添加了一个更清晰的版本。Claude 违反了另一条不同的规则，于是他们也把那条加上。几周后，这个文件达到了 400 行，而 Claude 忽略的规则比以往任何时候都多。解决方案反而让问题变得更糟。

发生这种情况是因为指令文件的一个基本属性，而大多数开发者从未将其内化：超过一定规模后，添加更多指令会导致模型遵循的指令变少。 正确编写指令文件与其说是追求完整性，不如说是进行无情的筛选 —— 知道该包含什么、该删除什么，以及如何构建其余部分。

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

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

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

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

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