Effective LLM

主题

Chapter 2 · 识别可解、可缓解、不可解的失败模式 ​

承接 Chapter 1：知道 LLM 是个"概率函数"以后，下一个问题是——这个函数错的时候，我能不能修？ 把这个问题答好的工程师才不会浪费三个月在一个根本不该用 prompt 解决的问题上。

Item 4：在写 Prompt 之前先判断它是 A / B / C 哪一档问题 ​

写 prompt 之前先做的事，是判断 prompt 该不该被写。

引子 ​

接到需求"让模型回答这个问题准确率提升"时，第一反应不应该是"我去优化 prompt"，而应该是：

  1. A 档？ —— 是不是有个确定性系统能直接接管？算术 → 计算器；查事实 → RAG；返回 JSON → Schema。
  2. B 档？ —— 不能根治，但能不能多采样 / 跨视角校验 / 长度归一？
  3. C 档？ —— 是结构性缺陷？反转诅咒、组合墙、否定盲——业务侧避开。

反例 vs 正例 ​

text
# Bad — 用 prompt 修一切
"用户最后登录时间戳 1719292800，换算成东八区是几月几日几点？跨夏令时怎么办？"

# Good — 直接走工具
datetime.fromtimestamp(1719292800, tz=ZoneInfo("Asia/Shanghai"))
# → 2024-06-25 14:00:00+08:00
text
# Bad — 用 prompt 强行让 LLM 学反向
# 用客服记录 fine-tune，数据全是 "工单 #1234 属于客户 张三"。
# 问 "客户张三有哪些工单" → 答不出，加 system prompt 也无效。
# 反转诅咒：单向 fine-tune 学不出反向关联。

# Good — 业务侧避开
# 入库时把 "工单 → 属于 → 客户" 与 "客户 → 拥有 → 工单"
# 双向写入；反向查询走 KG / DB，不走 LLM 直问。

Things to Remember ​

  • 决策顺序固定为 A → B → C：先看确定性系统能不能接管；用不了，再看能不能多采样摊薄；都不行，才考虑业务侧绕开。
  • 用 prompt 修 A 档是浪费，修 C 档是自欺。
  • 看到 LLM 失败案例，第一动作是打 A/B/C 标签——不是直接写 prompt。

Item 5：不要试图用 Prompt 解决训练侧问题 ​

你能用 prompt 安抚一头大象，但你不能用 prompt 让它变成一头熊。

核心 ​

谄媚（Sycophancy）、CoT 不忠、Token Bias、RLHF length bias——这些都根植于训练数据和 RLHF 偏好分布。Prompt 能让它们少发作 30%-50%，但不能消除。真正的解药是训练侧（合成对抗数据 + 偏好重学），但那不在大多数应用工程师的可行域内——所以工程上的正确选择是 识别 + 摊薄 + 监控。

Things to Remember ​

  • 把 "Be confident and disagree if you have evidence" 写进 system prompt 能降低改答率，但不能归零（arXiv:2310.13548）。
  • 训练侧问题的工程解只能是统计手段——多采样、跨家族、长度归一。
  • 看到一个失败案例时，先问"这是分布问题还是参数问题"——分布问题该上 prompt，参数问题该上 B/C 档手段。

Effective LLM