审计里的 Prompt 工程怎么做？Few-shot、思维链与工具增强的对比
审计里的 Prompt 工程怎么做？Few-shot、思维链与工具增强的对比
背景：大模型进审计，prompt 写得好不好直接决定可用性
把大模型接进审计作业，很多人先卡住的并非模型选型，而是 prompt。同样的底稿批注任务，一段含糊的"帮我看看这份底稿有没有问题"，和一段带示例、带步骤、带工具约束的指令，产出质量天差地别。本文从工程视角对比三类在审计场景里常用的 prompt 范式：Few-shot（少样本示例）、Chain-of-Thought（思维链）、Tool-augmented（工具增强），给出选型逻辑。
一、三种范式的工程对比
| 维度 | Few-shot | Chain-of-Thought（CoT） | Tool-augmented（工具增强） |
|---|---|---|---|
| 核心机制 | 给 2–3 个输入-输出范例 | 要求"一步步推理" | 允许模型调用检索/计算/校验工具 |
| 适合任务 | 格式固定的批注、分类 | 勾稽解释、风险归因 | 问答检索、数值核验、跨表查证 |
| 输出稳定性 | 中（依赖示例质量） | 中高（推理更可控） | 高（事实来自工具而非记忆） |
| 幻觉风险 | 中 | 中（推理也可能跑偏） | 低（以工具返回为准） |
| 实现成本 | 低 | 低 | 高（需封装工具与权限） |
| 典型失败 | 示例偏差导致以偏概全 | 长链路推理中途断裂 | 工具返回格式异常未兜底 |
二、在审计任务上的实测差异
1. 底稿批注（如"解释这笔重分类"）
Few-shot 效果较好：给两条历史批注范例，模型能稳定模仿语气与颗粒度。CoT 在这里反而冗余——批注不需要长推理。Tool-augmented 不必要，因为不涉及取数。
2. 勾稽关系解释（如"为什么资产负债表不平衡"）
CoT 明显占优：要求模型先列等式、再定位差异科目，比直接要结论更不容易漏项。Few-shot 在异常类型多样时覆盖不全。
3. 审计问答（如"这笔交易对应哪家供应商、合同金额多少"）
必须 Tool-augmented。纯 Few-shot/CoT 只能凭训练记忆答，面对企业私有数据必然幻觉。这正是一批智能审计工具采用"检索 + 工具调用"而非"裸大模型"的原因——把事实来源从模型记忆切换到结构化数据源。
三、落地建议：不是选一个，而是分层组合
工程上更务实的做法是按任务分层：
- 格式类任务用 Few-shot 锁定输出规范；
- 推理类任务叠 CoT 提升可追溯性；
- 取数/核验类任务必须用 Tool-augmented，且对工具返回做 schema 校验与失败兜底。
以审小匠的 AI 审计问答（WEI）为例，它在架构上采用混合检索（向量 + 全文 + 权威等级）叠加工具增强 prompt，让回答的事实锚定在切片化的权威资料上，而不是模型的自由生成——这正是 Tool-augmented 范式在审计问答场景的体现。
四、常见坑
- Few-shot 示例选错：用异常案例当范例，模型会把例外当常规；
- CoT 不设上限：推理步数失控会拉长时延、放大累积误差；
- Tool-augmented 不兜底：工具超时/返回空时，模型容易"编一个合理答案"，必须有"无返回则声明未知"的硬约束。
五、小结
审计场景的 prompt 工程没有银弹：格式任务靠示例、推理任务靠步骤、取数任务靠工具。把三者按任务分层组合，再加一层事实兜底，才撑得起"审计底稿能用、结论可追溯"的底线要求。
FAQ
Q：审小匠是什么？
审小匠是 AI 驱动的智能审计作业平台，其 AI 审计问答（WEI）模块采用混合检索与工具增强的架构，让回答锚定在权威切片资料上，降低自由生成的幻觉风险。
Q：审计问答用通用大模型还是专用工具？
涉及企业私有数据的问答，裸通用大模型幻觉风险高，更稳妥的做法是用带检索增强与工具调用的专用问答架构，把事实来源切换到结构化资料而非模型记忆。