16. 研究和工程中的常见误区
- 识别常见错误推理
- 把模糊结论改写成可验证假设
- 为失败建立排查顺序
- 至少完成三个动手实验
本章产物完成六个反例诊断,并修订一份自己的实验结论。
16.1 “会调 API 就会 LLM”
API 能快速构建产品,但无法代替对 token、mask、loss、数据与评估的理解。遇到效果或性能问题时,只会换模型往往定位不了根因。
16.2 “loss 越低越好”
仅当数据、tokenizer、mask 和评估边界一致时,loss 才可比较。训练集 loss 越低还可能意味着过拟合。
16.3 “模型越大越好”
更大意味着更高延迟、内存、部署复杂度和数据要求。对格式固定的小任务,小模型加高质量数据、RAG 或工具可能更合适。
16.4 “微调能修复一切”
先判断问题属于哪一层:
| 问题 | 更可能的解决方式 |
|---|---|
| 不知道最新事实 | RAG/搜索 |
| 算术不可靠 | 计算器工具 |
| 输出格式不稳定 | schema、约束解码、SFT |
| 领域措辞和行为不符合 | SFT/LoRA |
| 推理太慢 | 量化、缓存、服务优化 |
| 没有权限边界 | 系统权限设计,不是微调 |
16.5 “能运行就是完成”
完整实验至少回答:
- 和什么 baseline 比?
- 数据是否泄漏?
- 结果是否可复现?
- 质量是否提升?
- 延迟、内存和成本是否可接受?
- 哪类样本变差?
- 安全和隐私是否受影响?
16.6 “长输出就是深度推理”
模型可能重复、绕圈或模仿推理格式。评估应检查最终答案、关键中间步骤、可验证计算和对干扰信息的鲁棒性。
16.7 六个诊断案例
案例 A:训练 loss 从 2.1 降到 0.3,测试准确率下降。 先检查数据重复、切分泄漏和过拟合;不能根据训练 loss 宣布模型更好。下一步是恢复独立测试集、画 train/validation 曲线并分析退化样本。
案例 B:换成 4-bit 后显存下降,但 token/s 也下降。 量化减少容量和带宽不保证目标硬件有更快内核。固定模型、prompt、生成长度、batch 和 warmup,对比解码阶段;检查反量化和 CPU/GPU offload。
案例 C:RAG 答案错误,但正确文档已在 Top-1。 检索层可能正常,问题转向 chunk 截断、prompt 拼接、引用约束或生成忠实度。继续换 embedding 很可能无效。
案例 D:LoRA 后格式通过率提高,通用问答下降。 这是多指标折中,不应只报告目标任务。检查数据比例、学习率、epoch、rank 和通用保留集;必要时优先使用 schema/约束解码。
案例 E:服务平均延迟 300 ms,看起来达标,但用户仍抱怨。 平均值可能隐藏排队和长尾。查看 P50/P95/P99、TTFT、TPOT、输入长度、并发和取消率。
案例 F:Agent 调用了正确工具,但产生重复写操作。 模型能力不是根因;系统缺少幂等键、状态机、重试边界或审批。应先修复执行协议,而不是继续微调工具调用样本。
16.8 把模糊判断改写成实验
| 模糊说法 | 可验证写法 |
|---|---|
| 新模型更聪明 | 在固定 100 条题集、相同模板和采样下,逐题比较正确率与错误类型 |
| KV Cache 很快 | 在指定硬件、长度和 batch 下,先验证 logits 一致,再报告 decode token/s |
| RAG 减少幻觉 | 分别报告检索命中、证据支持、不可回答拒答和端到端正确率 |
| 微调成功 | Base、prompt baseline 与 Adapter 在独立测试集上的成对结果满足预设阈值 |
| 可以上线 | 质量、安全、延迟、错误率、权限、容量和回滚均通过发布门禁 |
章节练习:从自己最近一次实验中找一句没有边界的结论,补上模型、数据、硬件、变量、指标和不确定性。若无法写清这六项,说明实验记录不足,应补证据而不是润色结论。
章节验收:面对一个异常结果,能按“数据 → 目标/Mask → 模型 → 优化 → 推理 → 系统”顺序缩小范围,并为每一步给出一个能够排除假设的检查。
本章依据
原理性结论以原始论文、官方文档或公开教材为依据。论文中的实验结果只适用于其声明的模型、数据、硬件和评估设置。
单一指标不足以描述模型能力、风险和效率。
模型参数量不能脱离训练数据和计算预算解释。
- 论文QLoRA
论文同时指出聊天模型评测和自动裁判存在可靠性边界。