修炼AI技能
AI 教程 / Prompt 工程 / 提示调试：当模型答不对时怎么改

提示调试：当模型答不对时怎么改

提示写得不对，模型就会稳定地错——不是偶尔抽风，而是每次都错在同一类地方。提示调试就是像调代码一样，把「错的输出」一步步变成「对的输出」。它有一套可复制的排查流程，而非靠灵感硬猜：先定位问题类型，再提出假设、小步改动、用固定用例对照验证。把提示当成「程序」来维护，它才会像程序一样可预测、可回归。

先定位是哪类问题

  • 理解错误：模型没读懂任务，答案完全跑偏，往往是因为指令含糊、目标互相冲突，或示例与指令不一致。
  • 格式错误：内容对，但结构不符合要求，如漏了 JSON 字段、多了多余解释、换行错位、把代码块包进了不该有的标记。
  • 覆盖不足：只答对部分，遗漏了规则里的边界情况（如「为空时返回 null」「负数取绝对值」这类分支）。
  • 幻觉：编造不存在的引用、数据或结论，常见于事实性、长尾或检索不到的问题；温度越高越易出现。
  • 一致性差：同一输入多次跑结果飘忽，通常与温度过高或缺乏约束有关。

定位时建议先看失败样本本身，再决定改哪。把失败归类（格式类 / 理解类 / 幻觉类）比笼统说「答得不好」更有行动指导意义。

调试流程

  • 复现：固定输入与模型参数（温度、种子、系统提示），先确认错误稳定出现，而不是随机抖动——只有稳定复现的 bug 才值得修。
  • 假设：猜测根因是任务描述不清、缺约束、缺示例，还是上下文被截断、检索召回了错误文档。
  • 小改动：一次只改一处，例如把「总结」改成「用三句话总结，每句以要点开头」。多改并行会让你分不清哪一处真正生效。
  • 对照验证：用同一组测试用例跑改动前后，逐条对比差异，而不是凭「感觉更好了」。

常见有效的改动

  • 加约束：明确长度、格式、语气、禁止项，例如「只输出 JSON，不要任何解释文字」。
  • 给示例：少样本（few-shot）示例往往比抽象描述更稳，因为模型更擅长模仿具体范式；示例要覆盖典型与边界情况。
  • 拆分任务：把复杂任务拆成多步，先分步推理再汇总；研究已表明显式逐步推理（如 “Let’s think step by step”，Kojima 等, 2022, arXiv:2205.11916）能提升多步推理表现。
  • 追问自检：让模型先复述任务或列出假设，再作答；或在输出前自评一遍「这个结论有依据吗」。
  • 控制温度：事实类、格式类任务调低温度（如 0），减少随机波动；创意类任务才适度放开。
  • 看 logprobs：当模型在几个 token 间犹豫（如是否加负号、选 A 还是 B），用 logprobs 查看各候选概率，能区分是「真错」还是「只是不太确定」。

常见误区

  • 提示越长越好：冗长提示反而稀释注意力，模型可能忽略中间指令（所谓 “lost in the middle” 现象）。先精简，再按需补约束。
  • 指令互相矛盾：同时要求「详尽」又「一句话回答」，模型无所适从，先统一目标。
  • 只改表面不查根因：模型答非所问，有时是上下文被截断或检索召回了错误文档，改提示只是治标——先用追踪工具看完整轨迹。
  • 忽视复现：没固定参数就断言「改好了」，往往只是这次随机抽到了好结果。
  • 过度堆砌技巧：一个提示里同时塞 CoT、少样本、角色扮演、自我反思，反而互相干扰；技巧要按需叠加，逐一验证。

建一组「回归用例」

  • 把典型好输入、边界输入、易错输入收集成固定用例集，像单元测试一样长期维护，建议用结构化格式保存：
[
  {"input": "用户问退款政策", "expect": "引用第3条", "type": "边界"},
  {"input": "空列表求和", "expect": "返回 0", "type": "边界"}
]
  • 每次改动提示都跑一遍，防止「修好这个、坏了那个」——这正是回归测试的价值。
  • 用例集沉淀下来，就是团队的提示回归测试；配合 LangSmith 等追踪工具，还能看到每条用例的逐步轨迹，定位是哪一步走偏。
  • 何时该重构而非调试：当提示已塞满补丁、改动一处牵动全身时，与其继续打补丁，不如重写结构（明确角色、步骤、输出契约），再用回归用例验收。

小结

提示调试的核心是「小步快跑、对照验证」。先稳定复现并定位问题类型，再一次改一处，用固定用例集验收，并避开常见误区。把这套习惯固化成回归用例，提示质量才会持续、稳定地提升，而不是靠每次临场发挥。

参考与延伸阅读

本文累计阅读 — 次