大模型上下文工程之Prefill Response(预填响应)技巧

上一篇文章,我们聊了上下文工程中的Prefix Caching技术。它主要解决Token成本问题,能帮你的AI应用省钱,同时能降低大模型的响应耗时。

今天的这篇文章,我来聊一聊如何让大模型更听话的技巧:Prefill Response(预填响应)

(关于上下文工程系列,感兴趣的读者也可以回顾前两篇:)

一、Prefill Response(预填响应) 是什么?

简单来说,这是一个给大模型"喂招"的技巧。目前主流大模型基本都支持了预填响应的形式。

我们都知道,大语言模型本质上是一个"文字接龙"大师。它根据你给出的上文,来预测下一个最合适的词。

Prefill Response正是利用了这一点。

当轮到大模型回应时,我们可以先"预先填写"一部分它要说的话。大模型看到这个开头后,会认为这是自己已经说出口的,然后自然地接着往下说。

这样,我们就巧妙的引导了它的输出方向。

我们来看一个Claude的例子。假设我们想让它只返回计算结果。

ini 复制代码
# 原始请求
client.messages.create(
    model="claude-opus-4-20250514",
    messages=[
        {"role": "user", "content": "你是一个计算器,请计算:1 + 1,只需输出计算结果"},
    ]
)

即使我们强调了要求,模型也有可能会返回 "当然!1 + 1 的结果是 2" 这样多余的内容。

现在,我们试试Prefill Response

ini 复制代码
# 使用 Prefill Response
client.messages.create(
    model="claude-opus-4-20250514",
    messages=[
        {"role": "user", "content": "你是一个计算器,请计算:1 + 1"},
        {"role": "assistant", "content": "="}  # 在这里预填
    ]
)

这时,模型的输出就只会是2。

我们只是通过assistant角色预填了一个等号 =,就成功框住了模型的思维,让它只能接着我们的思路走。

二、Prefill Response的巧用

上面的例子很简单。我们来看一个更真实的场景。

在做AI应用时,功能可能越加越多,工具箱(Tool集合)也越来越大。一个直接的后果是:AI代理开始出现"选择困难症",经常选错工具。

我们用一个"智能管家"的例子来说明。

假设我们的 AI 管家集成了家里所有设备的控制权,每个操作都是一个独立的工具。

工具箱一览(部分):

  • 灯光类: turn_on_living_room_light、turn_off_living_room_light...
  • 温控类: turn_off_ac、set_hvac_to_away_mode...
  • 安防类: arm_security_system、lock_front_door...
  • 影音类: turn_off_tv、stop_music_playback...
  • 信息类: get_weather_forecast、read_latest_news...

可以看到,工具列表非常庞大。

某天,你出门时对它说:"我准备出门了,帮我处理一下家里。"

如果是人类管家,他知道这时候该关灯、关空调、锁门。但AI面对几十个工具,可能瞬间陷入了混乱。他可能很难将"出门处理一下"这种模糊的指令,准确翻译成一连串正确的工具调用。

一个"看似可行"的错误方案

一个自然的想法是:动态调整工具列表。根据用户意图,按需加载相关的工具(类似于RAG的思路)。

但这种"动态移除"的方案,会带来两个灾难性的问题:

  • 性能灾难:缓存失效。 我在上一篇讲Prefix Caching时有提到,要尽量的去复用前缀缓存来节省token费用。而在我们的Prompt设计中,通常将工具列表的定义放在系统指令和动态上下文之间,因此,对工具集的任何更改可能导致后续的缓存失效。
  • 稳定性灾难:模型困惑。 AI代理的记忆(上下文)中包含了它过往的所有行为和观察。想象一下,代理在第 2 步用了工具A,但第 3 步你把A移除了。代理回看历史时,会发现一个"不存在"的工具记录。这会让它陷入自我矛盾的"精神错乱",大大增加产生幻觉的风险。

更好的方式是:用"遮蔽"代替"移除"

这时,Prefill Response就派上了用场。我们可以用它来实现对工具的"遮蔽",而不是"移除"。

整个过程咱们可以分三步走:

第一步:设计一个状态机

我们的应用需要能感知上下文。比如,当用户说"我准备出门了",应用就将状态切换为LEAVING_HOME

第二步:统一工具命名

这是一个小技巧,但非常关键。我们可以按需给工具名加不同的前缀。例如,上述"智能管家"的案例中,所有关闭类的工具都以turn_off_开头。这便于我们按组进行管理。(Manus在自己的技术博客中举过一个例子,他们根据不同场景来对工具集进行特定前缀命名,所有与浏览器相关的工具都以browser_开头,命令行工具则以shell_开头

第三步:使用Prefill Response实现"遮蔽"

LEAVING_HOME状态下,状态机判断出,此时只需要用到turn_off_开头的工具。接下来,我们就要"遮蔽"掉其他所有工具的调用可能。

当然,现在一些主流的闭源大模型,提供了直接的API方便开发者在执行任务的过程中,来精确的控制可以调用哪些工具。例如OpenAI和Claude的tool_choice参数,Gemini的tool_config参数。

但是,在许多商业AI应用中,出于成本和定制化考虑,我们往往会选择部署开源模型。这些模型通常没有这些高级 API。

这时,我们可以选择Prefill Response技术来实现动态遮蔽效果。

现在很多开源模型在多轮对话中采用的是OpenAI提出的ChatML(Chat Markup Language)格式。一个ChatML的基本结构由三个部分组成:起始标记角色结束标记

scss 复制代码
<|im_start|>角色 (role)
对话内容 (content)
<|im_end|>

角色一般就是system(系统指令)user(用户指令)assistant(模型回应)。如前文所述,我们可以利用assitant角色来达到Prefill Response的目的。按Manus的用法,一般有三种模式:

  1. 自动模式 - 预填充内容 <|im_start|>assistant
    这是最宽松的模式。我们只是告诉模型可以自由回复,模型可以选择直接回答用户的问题,或者调用一个工具
  2. 必须模式 - 预填充内容 <|im_start|>assistant<tool_call>
    这种模式下,我们通过在assitant角色中指定<tool_call>前缀直接替模型决定了第一步:必须调用一个工具。
  3. 指定模式 - 预填充内容 <|im_start|>assistant<tool_call>{"name": "turn_off_"
    这是限制性最强的模式,我们给模型做出了更具体的指示:接下来不仅要调用工具,而且必须调用一个名字为turn_off_开头的工具,模型接下来的任务就变成了在所有以turn_off_为前缀的工具中选择一个最合适的。

结语

可以看到,Prefill Response通过一种非常巧妙的方式,给大模型套上了一个"紧箍咒"。

它在不改变模型完整工具箱的前提下,引导模型在特定场景下,只能选择特定的行为路径。这使得 AI 代理的行动更加可靠、高效。

这也告诉我们,要设计一个优秀的上下文,有非常多的细节要去考量。

相关推荐
MUTA️10 分钟前
视觉语言模型在视觉任务上的研究综述
人工智能·深度学习·语言模型·多模态
leaf_lucky20 分钟前
机器学习——互信息(超详细)
人工智能·机器学习
度假的小鱼20 分钟前
【源力觉醒 创作者计划】对比与实践:基于文心大模型 4.5 的 Ollama+CherryStudio 知识库搭建教程
人工智能·开源·文心大模型·知识库搭建
新加坡内哥谈技术27 分钟前
谷歌正在美国测试一项基于机器学习的年龄识别技术
人工智能
图灵学术计算机论文辅导29 分钟前
1+1>2!特征融合如何让目标检测更懂 “场景”?
论文阅读·人工智能·经验分享·考研·机器学习·计算机视觉·目标跟踪
NeoFii38 分钟前
论文精读:Hallucination of Multimodal Large Language Model: A Survey
人工智能·多模态大模型·模型幻觉
文火冰糖的硅基工坊1 小时前
[人工智能-综述-17]:AI革命:重塑职业版图,开启文明新篇
人工智能·深度学习·神经网络·架构·信号处理·跨学科融合
vincent&lin1 小时前
Triton源码分析 - 目录
人工智能·ai编程·mlir·llvm
Baihai_IDP1 小时前
构建 AI 护城河的六大常见误区分析
人工智能·面试·llm
金井PRATHAMA1 小时前
分布内侧内嗅皮层的层Ⅱ或层Ⅲ的网格细胞(grid cells)对NLP中的深层语义分析的积极影响和启示
人工智能·深度学习·神经网络·机器学习·自然语言处理·知识图谱