提示词工程

提示词工程(Prompt engineering)是使用 LLM 时最实用的技术之一。它允许你引导模型行为、提高输出质量,并构建可靠的应用程序,而无需修改模型本身。

什么是提示词工程?

提示(Prompt)就是你发送给 AI 模型的输入。模型能够推理并生成文本,但它依赖提示来理解:

它应该执行什么任务
答案应该遵循什么格式
它必须遵守哪些约束

提示词工程是以引导模型得到你想要结果的方式,来组织指令、示例和上下文的实践。对于许多推理工作负载来说,更好的提示是获得更好结果的最简单途径。

例如,这两个提示会产生截然不同的结果:

# Basic prompt
Summarize this article.

# Improved prompt
Summarize the article in three bullet points.
Focus on key technical insights.
Do not include opinions or marketing language.

第二个提示给了模型明确的期望,这能带来更有意义的输出。

为什么提示词工程对推理很重要

LLM 的提示词工程与推理的工作原理密切相关。

在推理期间,模型不会改变权重。它只是根据收到的输入生成 token。这意味着提示成为应用程序与模型之间的主要接口。你的提示设计直接影响模型在运行时的行为。

token 使用与成本

每个请求都包含输入 token(提示)和输出 token(生成的响应)。更长的提示会增加模型必须处理的 token 数量。这会影响到:

延迟(Latency): 更多 token 需要更多预填充(prefill)阶段的计算
GPU 利用率: 更多 token 需要更多的计算和内存带宽
推理成本: 基于 token 的定价或基础设施成本随 token 用量增长

对于高吞吐的推理系统,提示长度成为一个重要的优化因素。

KV 缓存使用

LLM 推理高度依赖 KV 缓存(键值缓存)来加速生成。

在预填充阶段,模型处理整个提示并将中间注意力状态存储在 KV 缓存中。在解码期间,模型复用这个缓存,而不是为之前的 token 重新计算注意力。

然而,KV 缓存的大小会随着提示中 token 的数量而增长。这意味着更长的提示会导致:

更大的 KV 缓存内存占用
更高的 GPU 显存消耗
每张 GPU 上更少的并发请求

对于大型模型或长上下文工作负载,提示大小会直接影响吞吐量和系统可扩展性。

模型可靠性

在生产推理系统中,模型必须在成千上万甚至数百万个请求中保持一致的行为。

结构不佳的提示可能导致:

输出不一致
格式不正确
意外的推理路径

精心设计的提示可以降低这些风险。通过清晰地定义任务、输出格式和约束,你让模型在推理期间的行为更可预测。

当 LLM 被用于自动化工作流、API 或智能体系统时,这一点尤其重要。

运行时控制层

在许多 AI 部署中,提示词工程成为控制模型的第一层。开发人员无需修改模型本身,而是调整提示来:

强制输出结构(JSON、markdown 等)
控制语气或风格
限制行为
引导推理

由于提示是请求负载的一部分,它们可以在不重新训练模型或更改服务基础设施的情况下快速更新。这使提示成为在生产中引导模型行为的灵活方式。

提示词工程通常与推理参数一起调整。提示定义任务和约束,而 temperature、top_p 和 max_tokens 等参数控制模型如何采样以及如何限制响应。

提示角色

大多数现代 LLM API 将提示分成不同的角色。最常见的类型有:

系统提示
用户提示
助手消息

系统提示

系统提示定义模型的整体行为。它就像一套操作指令,指导模型应该如何响应。

示例:

You are a technical assistant that explains LLM inference concepts clearly.
Use short paragraphs and simple language.
Avoid unnecessary jargon.

对于开发者来说,系统提示通常用于:

定义助手的角色或人设
强制响应格式(如 JSON)
限制话题或行为
提供任务特定的指令

对于使用聊天界面的个人用户,系统提示通常存在于幕后。它由应用开发者配置,有助于确保不同用户之间行为一致。

用户提示

用户提示包含用户或应用程序发送的实际请求。

示例:

Explain what a transformer model is in simple terms.

对于个人用户,这其实就是他们在聊天界面中输入的提问或指令。

对于开发者来说,用户提示通常由应用程序动态生成。它可能包括:

用户输入
从数据库检索到的文档
对话上下文
结构化的任务指令

例如,在文档问答系统中,用户提示可能如下所示:

Answer the question using the context below.

Context:
{retrieved_documents}

Question:
{user_question}

在生产推理系统中,用户提示通常会在发送给模型之前以编程方式组装。

提示模板

在生产系统中,提示很少每次手动编写。相反,开发者使用插入动态数据的提示模板。

模板示例:

You are a helpful assistant.

User question:
{question}

Provide a concise answer in three bullet points.

提示模板可以更容易地:

跨应用程序标准化提示
保持一致性
在一个地方更新行为

LangChain、LlamaIndex 以及许多推理平台都支持模板化提示。

助手消息

助手消息表示模型在对话早期轮次中生成的响应。它们主要有两个用途:

之前的模型输出
被开发者用来引导或约束未来的响应

由 API 返回

在大多数聊天 API 中,模型会返回一个角色为 assistant 的消息。在构建多轮对话时,应用程序通常会将这些早期消息包含在下一个请求中。

示例:

messages = [
  {"role": "system", "content": "You are a helpful assistant."},
  {"role": "user", "content": "Who won the world series in 2020?"},
  {"role": "assistant", "content": "The Los Angeles Dodgers won the World Series in 2020."},
  {"role": "user", "content": "Where was it played?"}
]

通过包含早期消息,模型可以维持连贯的对话。

然而,从模型的角度来看,这些消息并不会被特殊对待。在推理期间,整个对话历史只是被转换成一系列 token,并作为输入提示的一部分进行处理。

对于大型推理系统,长对话会降低吞吐量并增加基础设施成本。为了管理这一点,AI 团队通常实施如下策略:

消息截断,只保留最近的轮次
对话摘要,压缩较旧的上下文
前缀缓存以复用共享的提示片段
KV 缓存卸载以便在需要时将缓存数据移至低成本存储

由开发者注入

助手消息并不总是需要来自模型本身。开发者也可以插入合成助手消息来引导模型行为。

这种技术有时被称为助手预填充(assistant prefilling)或响应前缀(response prefixing)。

由于 LLM 是自回归的(它们根据所有之前的 token 预测下一个 token),模型并不关心"Assistant"角色中的词是它自己生成的还是你输入的。它只是把这些词视为已经确立的开头,然后从这里继续。

这让开发者能够引导响应或强制执行结构。例如,你可以引导模型生成有效的 JSON 输出:

messages = [
  {"role": "user", "content": "Show me a list of popular open-source llms in JSON."},
  {"role": "assistant", "content": "Here is the JSON list you need:\n{"}, # The model continues from here
]

备注

大多数现代聊天式 LLM API 都支持助手预填充。然而,确切的 API 结构以及该行为的可靠性可能因提供商和模型而异。

写出更好提示的实用技巧

几个简单的做法可以显著改善结果:

要明确

告诉模型你到底想要什么。

不好:

Explain this.

更好:

Explain this concept to a beginner using simple language and one example.

指定输出格式

如果你的应用程序期望结构化输出,要明确说明。

示例:

Return the answer in JSON format with fields:
- summary
- key_points
- confidence

保持提示聚焦

带有无关指令的长提示会让模型困惑。保持指令清晰且针对任务。

测试各种变体

微小的措辞变化有时会带来巨大差异。提示词工程通常需要实验。

在构建真实系统时,你很可能会将 LLM 提示词工程与其他技术结合起来,如结构化输出、工具调用和微调。理解提示如何影响模型行为,是构建健壮 LLM 应用的第一步。

常见问题

什么是零样本、一样本和少样本提示?

这些术语描述提示中包含多少示例来引导模型。

零样本(Zero-shot)提示意味着提示只包含指令,没有示例。

Classify the sentiment of the following sentence as Positive or Negative.

Sentence: I really enjoyed this movie.

模型必须仅基于指令来执行任务。

一样本(One-shot)提示使用一个示例来演示预期的行为。

Classify the sentiment of the following sentences.

Sentence: This restaurant is amazing.
Sentiment: Positive

Sentence: The service was terrible.
Sentiment:

这个示例帮助模型理解它应该遵循的模式。

少样本(Few-shot)提示在实际输入之前提供多个示例。借助这些示例,模型可以更好地识别模式并产生更可靠的结果。

Classify the sentiment of the following sentences.

Sentence: This restaurant is amazing.
Sentiment: Positive

Sentence: The service was terrible.
Sentiment: Negative

Sentence: I really enjoyed the meal.
Sentiment:

下面是一个并排对比:

类型	含义	示例用途	权衡
零样本提示	提示只包含指令,没有示例。	摘要或翻译等一般性任务。	提示短、token 成本低,但模型可能误解格式或预期。
一样本提示	提示包含一个示例,展示期望的输入输出模式。	教模型特定的格式或风格。	提示稍长,但有助于澄清任务。
少样本提示	提示在实际输入之前包含多个示例。	分类、结构化输出或领域特定的格式化。	通常能提高可靠性,但会增加 token 用量和推理成本。