程序辅助语言模型 (Program-aided language models, PAL)
1 LLM 的数学能力局限
- 本质原因：LLM 预测下一个最可能的 token，并不执行真正的数学运算。
- 常见问题
- 简单算术都可能出错，数字越大、步骤越多越不可靠。
- 错误后果：账单金额计算错误、配方比例出错等。
- 链式思考（CoT）只能部分缓解：即便推理步骤正确，单个计算仍可能失误。
2 用外部程序弥补：Python 解释器
- 思路：让 LLM 负责“写程序”而不是“做运算”，把计算交给擅长数学的环境（如 Python）。
- 优势：保证数值正确性，避免人工校对。
3 Program-Aided Language Model（PAL）框架
3.1 核心思想
让 LLM 生成可执行的 Python 脚本 + 外部解释器执行脚本 = 正确答案
- 首创：Carnegie Mellon University Luyu Gao 等人在 2022 年提出。
- 两个关键组成
- 链式思考 + 代码：在推理文字旁插入 Python 代码行。
- 解释器执行：Orchestrator 将代码送入解释器并取回结果。
3.2 提示（Prompt）结构
示例问题
# 推理步骤（注释）
x = 300 # 直接赋值
y = 300 // 3 # 计算
...
return x - y # 输出
"""
新问题：……- 注释行 #：供人类阅读，Python 会忽略。
- 代码行：声明/计算/返回变量。
- Few-shot 示例：用 1-2 个完整示例教 LLM 输出相同格式。
3.3 工作流程（Inference Pipeline）
- 准备 Prompt：示例 + 待解问题。
- LLM 生成脚本：包含推理文字和 Python 代码。
- Orchestrator 调用解释器：运行脚本得到答案。
- 把答案追加到 Prompt：形成“含正确答案”的上下文。
- LLM 输出最终回应：保证答案准确。
3.4 例子：面包房库存
- 问题：烤 120 个 → 上午卖 30 → 下午卖 20 → 超市退回 4 → 还剩？
- 脚本变量：baked = 120, sold_morning = 30, sold_afternoon = 20, returned = 4
- 计算：remaining = baked – sold_morning – sold_afternoon + returned
- 解释器结果：74。
4 Orchestrator（编排器）的角色
- 信息流：LLM → Orchestrator → 解释器/数据库/…… → Orchestrator → LLM。
- 决策逻辑：
- 解析 LLM 计划或工具调用指令。
- 管理多步骤、分支、校验等复杂流程。
- 在 PAL 中：流程简单，只需执行 Python。现实应用往往需要接多种外部资源。
5 PAL 适用场景
| 场景 | 为什么适用 PAL |
|---|---|
| 大数运算、财务结算 | 金额误差容忍度低，需严格数值正确性 |
| 科学计算、统计分析 | 依赖库函数或浮点精度 |
| 需要微积分/三角函数 | 超出 LLM token 预测能力 |
| 多步逻辑 + 复杂分支 | 容易把逻辑与计算拆分，代码更清晰 |
6 使用 PAL 的实践要点
- 示例要高质量：清晰标注注释与代码，变量命名一致。
- 限制 LLM 只写脚本：避免让它直接给数值答案。
- 安全沙箱：运行生成代码时要隔离环境，防止潜在安全风险。
- 监控与回退：脚本执行失败或超时时要有兜底策略。
- 可扩展性：随着需求增长，可让 Orchestrator 解析多种“工具调用”而不仅是 Python。
7 与更复杂系统集成
- ShopBot 示例：处理退货需
- 查订单数据库（SQL/RAG）
- 业务逻辑判断
- 触发物流 API
- 思路：把每个外部操作封装成“工具”，LLM 产生计划，Orchestrator 按序执行并回写上下文。
- 多工具框架：可以借鉴 PAL 的“代码 + 执行”理念，扩展到 SQL、REST、函数调用等。
结论
PAL 让 LLM 专注于“自然语言 → 代码/计划”，把精确运算交给程序执行，从而显著提升复杂数学和流程自动化场景的可靠性。要发挥其优势，必须设计良好提示、搭建安全执行环境，并用 Orchestrator 统筹多工具交互。