AI 应用失败样本 库
AI 应用项目最常见的问题不是“完全不能运行”,而是看起来能跑,但在某些输入下不稳定。失败样本库的作用是把这些问题分层记录下来,帮助你知道应该回到哪一层排查。
这个页面不是替代具体章节,而是一个索引。遇到问题时,先判断失败属于 LLM API、Prompt、RAG、Agent、工具、安全还是部署,再回到对应章节细查。
怎么记录一个失败样本
建议每个失败样本至少包含这些字段:
| 字段 | 说明 |
|---|---|
| 用户输入 | 触发失败的真实问题或任务 |
| 预期结果 | 系统本来应该输出什么或执行什么 |
| 实际结果 | 系统实际怎么回答或怎么行动 |
| 失败层级 | LLM API / Prompt / RAG / Agent / Tool / Safety / Deploy |
| 相关日志 | request_id、trace、retrieved_docs、tool_call 等 |
| 初步原因 | 你认为最可能的问题点 |
| 修复动作 | 准备改什么 |
| 回归测试 | 如何确认以后不会再犯 |
一个失败样本如果没有日志,就很难复盘;一个失败样本如果没有回归测试,就很容易下次再出现。
LLM API 层失败
| 现象 | 优先排查 | 修复方向 |
|---|---|---|
| 请求偶发失败 | timeout、rate limit、网络错误、服务端错误 | 增加超时、有限重试、错误分类和 fallback |
| 成本突然升高 | prompt_tokens、completion_tokens、上下文长度 | 压缩上下文、减少重复历史、记录 usage |
| 延迟明显变慢 | 模型选择、top-k、重试次数、网络状态 | 限制重试、缓存结果、拆分同步和异步任务 |
| 输出为空或格式异常 | raw output、错误码、响应解析逻辑 | 保留原始响应,统一响应结构 |
| 不知道哪次调用出了问题 | request_id 和日志字段缺失 | 统一记录 model、prompt_version、latency、error |
API 层失败通常先看日志,而不是先改 Prompt。如果连请求是否成功、用了多少 token、耗时多少都不知道,后面很难定位。
Prompt / 结构化输出失败
| 现象 | 优先排查 | 修复方向 |
|---|---|---|
| JSON 解析失败 | 是否有额外解释文字、括号是否闭合 | 要求只输出 JSON,增加解析失败重试 |
| 字段缺失 | schema 必填项是否清楚 | 在 Prompt 中列出 required 字段 |
| 字段类型不稳定 | 数字、布尔、数组是否被写成文本 | 明确类型和示例,增加校验器 |
| 分类标签漂移 | 枚举值是否固定 | 给出允许值,禁止自造分类 |
| 改了 Prompt 后旧样本变差 | 没有固定测试集 | 建 Prompt 版本和回归测试样本 |
Prompt 问题不要只靠“再写清楚一点” 解决。更稳的做法是:schema、示例、校验、失败样本和回归测试一起做。
RAG 层失败
| 现象 | 优先排查 | 修复方向 |
|---|---|---|
| 知识库有答案但没命中 | chunk、query、embedding、关键词匹配 | 调整切块、加混合检索或 query rewrite |
| 正确资料排得靠后 | top-k 原始结果、score、rerank 前后对比 | 增加 rerank,调整混合检索权重 |
| 命中了资料但回答漏条件 | context packing、prompt、答案格式 | 保留关键条件,要求逐条引用 |
| 引用和答案对不上 | source_refs、引用片段、claim | 做 citation check,禁止无证据结论 |
| 版本或来源错 | metadata filter、source_origin、日期字段 | 加过滤条件和来源优先级 |
RAG 失败最重要的是分清:是没有找对,还是找对了但没有用好。前者看检索日志,后者看 context 和生成约束。
Agent / 工具层失败
| 现象 | 优先排查 | 修复方向 |
|---|---|---|
| Agent 选错工具 | 工具名、description、候选工具数量 | 改 schema,减少无关工具,加入工具选择日志 |
| 工具参数错误 | arguments、参数校验、错误返回 | 增加校验器和结构化错误 |
| Agent 一直循环 | max_steps、停止条件、observation 是否重复 | 设置最大步数、无新增信息时停止 |
| 工具失败后直接崩溃 | safe_dispatch、retryable、fallback | 区分可重试和不可重试错误 |
| 最终结果无法解释 | trace 缺失 | 记录 goal、step、action、arguments、observation、next_decision |
Agent 失败不要只看最终答案。真正要看的,是每一步为什么这样行动,以及观察结果如何影响下一步。
安全与权限失败
| 现象 | 优先排查 | 修复方向 |
|---|---|---|
| Agent 执行了不该执行的动作 | 工具权限、风险分级、人工确认 | 高风险工具默认确认或禁用 |
| 外部文档诱导越权 | 是否把外部内容当成指令 | 标记外部内容不可信,工具层做权限限制 |
| 日志泄露敏感信息 | 日志字段、脱敏策略 | API key、隐私数据和内部资料脱敏 |
| 用户没有真正确认风险 | 确认文本是否清楚 | 展示动作、对象、参数、风险、回滚方式 |
| 出问题后无法追责 | audit_log 缺失 | 记录 request_id、工具名、参数、确认人、结果 |
安全问题不能只靠模型自觉。系统应该用权限、白名单、确认、审计和回滚来保证边界。
部署与线上运行失败
| 现象 | 优先排查 | 修复方向 |
|---|---|---|
| 本地能跑,线上失败 | 环境变量、依赖版本、路径、权限 | 写清部署配置,使用 .env.example |
| API key 失效或泄露 | 密钥管理、日志、前端暴露 | 后端代理调用,日志脱敏,轮换密钥 |
| 高并发下不稳定 | 限流、队列、超时、重试 | 加 rate limit、异步任务和降级策略 |
| 线上成本不可控 | token 统计、缓存、用户配额 | 成本监控、请求限额、模型分级 |
| 用户反馈无法进入改进 | 没有反馈字段和样本收集 | 保存 thumbs、纠错文本和失败样本 |
部署失败通常不是单纯代码问题,而是配置、权限、运行时和监控共同决定的。
失败样本复盘模板
## 失败样本标题
### 用户输入
### 预期结果
### 实际结果
### 失败层级
### 相关日志
### 初步原因
### 修复动作
### 回归测试
### 是否已解决
建议每个阶段项目至少保留 3 个失败样本。作品集级项目最好能展示:修复前是什么,修复后指标或样例怎样变化,还有哪些失败没有解决。