补齐大模型三大短板：知识、计算与工具调用

文章正文

当我们让大模型解答一道常识题——「高尔夫得分越高越好吗？」，它可能会毫不犹豫地回答「是」。但事实完全相反：高尔夫是杆数越少越好。这个看似简单的错误，暴露了大模型的一个根本性局限：它的脑子里未必有货，就算「想得再稳」，答案也可能是错的。

这种局限有其深层原因。大模型存储的是参数化知识（Parametric Knowledge）——世界知识被压缩编码进数十亿个神经网络权重中，而非存放在可精确检索的结构化知识库里。在训练过程中，神经网络通过反向传播将语料中的统计规律编码进这些浮点数权重，这一过程类似于有损压缩：频繁出现的模式被强化，低频信息则可能在权重更新中被覆盖或稀释。

参数化知识的本质是一种分布式编码——同一个事实可能散布在数百万个权重维度中，而非存储在某个确定的地址。这与人类大脑的联结主义记忆机制颇为相似，但也因此具备同样的脆弱性：在频繁强化的模式面前表现稳健，面对罕见或边缘知识则容易失真。

与之形成对比的是非参数化知识（Non-Parametric Knowledge）——例如检索增强生成（RAG）系统中的向量数据库，它将知识以可寻址的形式存储在模型外部，检索时通过余弦相似度或近似最近邻算法（ANN）定位相关条目，无论信息出现频率高低，只要被正确索引，均可被精确召回，且可随时增删更新，不影响模型本身的参数。理解这两类知识的边界，是选择「生成知识提示 vs. RAG 外部检索」的决策基础：当知识本身偶发且高价值（如实时新闻、企业私有数据），非参数化方案更可靠；当知识模糊且分布广泛（如常识性推理），参数化知识的泛化能力反而是优势。这种压缩天然有损：低频知识容易被遗忘，训练截止日期后的信息完全缺失，而某些常识（如高尔夫规则）可能因训练语料中正向与反向表述的比例失衡而产生系统性偏差。换言之，模型的错误往往不是随机的，而是有规律的偏斜。

本文是提示工程系列的第五期。上一期我们讨论了自我一致性与链式提示，让 AI「想得更稳」、把大任务拆开处理。但推理能力再强，如果知识本身有缺、计算本身不准、信息本身过期，一切都是白搭。这一期，我们聚焦三种解法：生成知识提示、编程语言推理、工具调用——分别对应大模型在知识、计算和外部能力上的三块短板。

三招的定位：从轻量 Prompt 到重装 Agent

先把这三招的关系理清楚。它们要解决的是同一个核心问题：大模型自身能力有短板，怎么补？ 但补的方式截然不同，从轻到重可以排成一条清晰的谱系。

生成知识提示是最轻量的一招，纯 Prompt 工程，不依赖任何外部系统，两段 Prompt 就能搞定，门槛最低。编程语言推理要接一个 Python 解释器，但要注意——接的是「执行器」而非「知识源」，用于解决算不准的问题。工具调用则是工程代价最高的一招，需要接入搜索引擎、计算器、翻译 API 等外部服务，由模型自己判断何时调用，但也补得最全。

这三条路对应不同层级的短板：计算不准，让代码来算；知识过期，让搜索引擎来查；模型自身知识调不对，让它先把知识写出来。选哪招，取决于短板出在哪里。

第一招：生成知识提示

模型在常识题上犯错，往往不是因为它「笨」，而是隐性知识调错了、调偏了。解法很巧妙：与其指望模型自动调对，不如让它先把知识写出来，再看着知识作答。

具体分两步。第一步，用 Few-shot 演示驱动模型生成知识——给几个「输入-知识」的范例，引导它对新问题产出相关知识条目。Few-shot（少样本学习）是大模型的核心能力之一，由 GPT-3 在 2020 年的论文中系统性证明：在 Prompt 中提供少量输入-输出示例，模型通过上下文学习（In-Context Learning）理解任务模式，无需更新权重即可泛化到新输入。

这背后的机制至今仍是学界活跃的研究议题。主流假说之一认为，大模型在预训练阶段已经隐式习得了「元学习」能力——当 Prompt 中出现输入-输出对时，模型通过注意力机制在上下文窗口内完成一种「梯度下降的近似」，将任务分布映射到其权重中已有的相关知识子空间。另一个来自 Anthropic 的理论则将 ICL 解读为「贝叶斯推断」——模型在上下文中看到示例，实际上是在更新其对任务分布的后验概率估计，而非执行任何形式的权重更新。值得注意的是，斯坦福的研究发现，示例的「标签正确性」对 ICL 效果的影响，远不如「输入空间覆盖」和「格式一致性」重要——这意味着示例的多样性覆盖往往比追求每条示例的答案绝对正确更能提升性能。

从实践角度看，Few-shot 示例的设计有几个关键原则值得注意：输入分布覆盖要尽量贴近真实任务分布，而非只覆盖简单典型案例；格式一致性（标点、换行、字段顺序）比内容正确性更影响模型对模式的识别；示例数量通常 3-8 个即可饱和，过多示例会压缩有效上下文空间，对长任务反而有害。整个生成知识的过程完全发生在推理阶段，零训练成本。

第二步，把生成的这条知识和原问题一起塞进 Prompt，让模型基于知识作答。回到高尔夫的例子：先生成「高尔夫的目标是以最少杆数打完」，再回答，答案就从「是」翻转成了「否」。

Lilian Weng 把这招称为「内部检索」——相对于查询外部向量库的「外部检索」，内部检索就是让模型查自己的知识库，省掉了向量数据库的工程复杂度。

这一「内部 vs. 外部检索」的对比，在工程选型上有清晰的分界线：当知识域较稳定、属于通用常识或领域内的主流认知时，内部检索（生成知识提示）的工程成本优势明显；当知识需要精确到具体数字、实时更新或涉及私有数据时，外部检索（RAG）不可替代。两者并非互斥，在某些场景下可以串联使用——先用生成知识提示激活模型的领域背景知识，再用 RAG 补充精确的事实细节。

但要警惕一个风险：生成的知识本身可能就是错的。 一旦模型生成错误知识，再基于错误知识作答，就是错上加错。因此在生产环境中，不能生成一条就直接用，而应该多条采样、质量筛选，把明显错误的知识过滤掉。

第二招：编程语言推理（PAL / PoT）

大模型的算术能力常年不稳，一旦涉及小数、除法、多步混合运算，翻车率层层攀升。根本原因在于：它不是计算器，每个数字都是逐 token 生成的，而不是逐位计算的。

更深层地说，大模型处理数字的方式本质上是「语言模式匹配」而非「算术计算」。在 Tokenization 层面，大多数主流分词器（BPE、WordPiece）将数字按字符级别分割，「1234」可能被切分为「12」和「34」两个 token，这意味着数字的位值结构在输入阶段就已被破坏。在注意力计算层面，模型通过学习大量算式的统计模式来「猜测」答案，而非执行确定性的进位运算。这就解释了为什么模型对「2+2」几乎不出错（训练语料中见过无数次），却对「17.83 × 94.7」频繁翻车——前者是高频模式，后者超出了模式记忆的覆盖范围。

2022 年，两个团队几乎同时想到同一个解法——别让模型自己算，让它写代码，交给 Python 解释器去算。这就是 PAL（Program-Aided Language Models） 和 PoT（Program of Thoughts）。PAL 由卡内基梅隆大学提出，PoT 由马里兰大学独立发表，两者核心思路一致，区别在于 PoT 更强调将复杂多步推理完整映射为含循环、条件判断的程序结构，而 PAL 更聚焦简单算术场景。

在基准测试上，两者表现均十分亮眼。GSM8K（Grade School Math 8K）是由 OpenAI 于 2021 年发布的小学数学应用题基准，包含约 8500 道需要 2 至 8 步推理的题目，是评估模型数学推理能力最广泛使用的基准之一。在 GSM8K 上，标准思维链准确率约为 56%-63%（GPT-3 规模），而 PAL 可将其提升至 72% 以上；在难度更高、涵盖竞赛级数学七个子类别的 MATH 基准上提升幅度更为明显。整体来看，相比纯思维链可将准确率提升 10-20 个百分点。这一提升的根本原因在于：Python 解释器对浮点数运算的精度是 IEEE 754 标准保证的，与模型规模无关，只要模型能正确建模问题的计算逻辑，数值结果就不再是瓶颈。值得注意的是，这两种方法对模型的代码生成能力有基础要求——对于规模较小的模型，代码生成质量可能成为新的瓶颈。

做法很直接：把思维链中的自然语言推理换成 Python 代码。模型不再写「4 乘以 30 等于 120」，而是写 time = 30 * 4，代码扔进解释器一跑，结果是精确的，而非「概率上大概率对」。

这里的关键洞察是解耦「计算」与「推理」：LLM 擅长语义理解（知道「4 倍时间」对应乘 4），解释器擅长精确计算（输出结果永远精确）。各司其职，数学题基本可以做到零出错。

代价是需要一个安全的代码沙箱。直接在生产服务器上运行模型生成的代码存在严重安全风险——模型可能生成访问文件系统、发起网络请求甚至执行系统命令的代码。工业实践中有几种主流方案：Docker 容器方案通过 Linux 的 cgroup 和 namespace 机制实现资源隔离，可通过 seccomp 配置文件精确控制可用系统调用白名单（例如屏蔽 execve、fork 等危险调用），但冷启动延迟在百毫秒量级；E2B 等专用代码执行云服务通过预热实例池将执行延迟压缩至数十毫秒，并支持有状态会话，适合需要多步迭代计算的 Agent 场景；WebAssembly（WASM）沙箱则是新兴方向，浏览器侧运行 Python 解释器（如 Pyodide）天然隔离，无需服务端资源，但对 NumPy 等 C 扩展库的支持尚不完整。

值得补充的是，代码沙箱的选型不只是安全问题，还涉及状态管理的设计决策。无状态沙箱（每次执行开启新进程）简单可靠，但无法在多步 Agent 任务中保留中间变量；有状态沙箱（如 Jupyter Kernel 模式）支持变量持久化，但带来会话管理和内存泄漏风险。在 PAL/PoT 的典型单步计算场景中，无状态方案足够；在需要多轮迭代、探索式计算的 Agent 场景中，有状态沙箱的价值才真正显现。此外，模型也得具备基本的代码生成能力。

第三招：工具调用与 ReAct

前两招各有天花板：生成知识提示补不了最新新闻，编程语言推理补不了翻译、搜索、查日历。工具调用的核心思想是承认 LLM 不是万能的，给它接上外部工具，让它自己判断何时求助外源。

在训练层面，有两条代表性路线。TALM 让模型反复与工具 API 互动，做得好就记住，扩充训练集，松散地模拟强化学习。Toolformer 则更优雅——由 Meta AI 于 2023 年提出，采用自监督方式，其精妙之处在于自我标注的三阶段流程：第一阶段，利用 Few-shot 提示在原始文本中插入潜在的 API 调用候选；第二阶段，执行这些调用并填入结果；第三阶段，计算插入调用前后模型对后续 token 的交叉熵损失差值——仅当调用结果使损失降低超过阈值时，该样本才进入微调数据集。

这一「因果筛选」机制直接用「预测后续文本的困难程度」作为「工具是否有用」的代理指标，无需人工标注「这个 API 调用是否正确」，从而实现了完全自监督的数据集构建——这与强化学习中的「奖励塑造」思想异曲同工，但绕开了 RL 训练的采样效率和稳定性问题。这种以「是否有用」作为筛选标准的机制，使模型学会了只在真正需要时才调用工具，避免过度依赖外部 API，同时保留了在不需要工具时直接回答的能力。Toolformer 覆盖了计算器、问答系统、搜索引擎、翻译系统、日历五类工具，各补一块短板。值得注意的是，这一筛选机制对「工具有用性」的判断是局部的（仅看调用后的若干 token），对于需要长距离推理才能体现价值的工具调用，可能存在系统性低估。

从 Toolformer 的工程落地角度看，它揭示了一个关键洞察：工具调用能力不必完全依赖大规模人工标注。这一思路在后续工作中被广泛延伸——例如 ToolBench（2023）通过 ChatGPT 自动生成工具调用的指令-回答对来构建训练数据，本质上是用更强模型为弱模型「蒸馏」工具调用能力，将 Toolformer 的自监督思路推广到了指令微调范式。

但要讲清一个关键区别：TALM 和 Toolformer 属于「训练侧」的工具调用，会改动模型权重；而工业界目前更主流的是「提示侧」方案，不改模型，靠 Prompt 引导模型决定何时用工具。例如 Claude 就在 System Prompt 里用 XML 标签控制「何时主动行动、何时先等指令」。

这套逻辑的终极形态，就是「思考-行动」循环的 ReAct（Reasoning + Acting，由谷歌 DeepMind 于 2022 年提出）。ReAct 的创新在于将「推理轨迹」与「行动序列」统一在同一个生成流中——它将推理与行动交织成一个三步循环：模型先思考（Thought）分析当前状态，再行动（Act）调用工具，获得观察（Observation）后继续思考，直到任务完成。与传统强化学习 Agent 将策略网络与价值网络分离训练不同，ReAct 用自然语言 Thought 作为隐式的状态表示，使推理过程对人类可解释、可调试。

从信息论视角看，ReAct 的三步循环本质上是一个主动信息获取（Active Information Gathering）过程：每一次 Act-Observe 循环都在减少模型对当前任务状态的不确定性。Thought 步骤扮演的是「信息价值估计」的角色——模型在行动前先推断「调用哪个工具能最大程度降低不确定性」，这与贝叶斯实验设计（Bayesian Experimental Design）中选择「期望信息增益最大」的实验动作在形式上高度一致。这一视角也解释了为什么 Thought 的质量对 ReAct 性能至关重要：思考越精准，行动选择越高效，整个任务所需的循环轮次也越少。

在此基础上，工业级实现（如 LangChain 的 AgentExecutor、Anthropic 的 Tool Use API）进一步增加了若干关键工程扩展：工具调用的 JSON Schema 标准化通过严格的函数签名定义（参数类型、是否必填、枚举值约束等），在执行层拦截格式错误而非将其暴露给推理层；错误处理与重试逻辑的设计哲学是「让模型看到错误信息并自行修正」——当工具返回错误码时，将错误描述作为 Observation 填入下一轮 Thought，利用模型的语言理解能力推断失败原因并调整参数，比硬编码重试策略更具泛化性；最大步骤数限制（通常设为 10-15 步）则是防止模型陷入「工具调用循环」的工程保险；多工具并行调用将串行等待转为并行执行，对于需要多次外部查询的复杂任务可显著缩短端到端响应时间。这些工程层面的扩展是 ReAct 从论文走向生产的关键桥梁，也使其成为当今 AI Agent 的核心骨架。

如何选择：从单点补强到 Agent 架构

三招该怎么选？可以用一个简单的决策逻辑：

• 尝试后老答错 → 用生成知识提示，成本最低；
• 算术老算错 → 用编程语言推理，接 Python 解释器；
• 不知道最新信息 → 用工具调用，接搜索引擎。

如果多个短板同时存在，就直接上工具调用，配置多个 API。而当模型还需要「自主决策何时用哪个工具」时，就演化成了完整的 Agent 架构：ReAct + 工具链 + 记忆系统。

更重要的是，这几招不只是「能一起用」，而是天然就该一起用：思维链负责推理，链式提示拆解任务，自我一致性在关键步骤投票纠错，生成知识提示补偿知识，编程语言推理接管计算，工具调用负责所有外部能力。它们共同标志着一个转向——提示工程不再只是「怎么跟模型说话」，而是「怎么给模型搭一个团队」。

小结：三招各司其职

• 生成知识提示：没把握先补一课，不依赖外部工具，最轻量，代价是可能有幻觉，需筛选；
• 编程语言推理：想好怎么算但别自己算，LLM 想公式、Python 出结果，精度拉满，但要有沙箱；
• 工具调用：自己搞不定就叫外源，从搜索引擎到日历 API，模型自己判断何时用。

从「让 AI 会想」到「让 AI 能查、能算、能动手」，我们完成了从 Vibe Coding 到 Harness 工程的关键一跃。下一期，我们将把这一切搬上生产线，聊聊提示工程的工程化部署。

核心要点

核心要点