CASE SOP / AI OPERATIONS

AI 应用故障诊断 SOP

从 RAG 质量下降、成本翻倍到用户拒答，快速定位根因的标准流程。

个人整理 · 基于 AI 工具、长任务评测和 RAG 应用实践

问题诊断分层排查证据保留

本 SOP 基于个人 AI 应用实践经验整理，适用于产品运营、技术运营和评测岗位参考；不涵盖底层模型训练或算法优化。

适用场景

当 AI 应用出现问题时的标准诊断流程。

RAG 答案质量突然下降
用户投诉"AI 有时候拒答"
API 成本突然翻倍
生成结果不一致

不适用：底层模型训练（需要算法团队）、硬件故障（需要基础设施团队）。

问题 1

RAG 答案质量突然下降

现象

用户反馈："AI 答非所问" / "答案不准确" / "没有引用来源"

诊断流程：4 步分层排查

第一步：检查召回（Retrieval）

目标：确认是否返回了正确的文档。查看召回的文档列表，人工判断这些文档是否包含答案。

✅ 正确文档在列表里 → 进入第二步
❌ 正确文档不在 → 召回失败（关键词不匹配、Embedding 模型问题、文档库未更新）

第二步：检查排序（Ranking）

目标：确认正确文档是否排在前面。查看召回文档的排序分数和正确文档的排名。

✅ 正确文档排在前 3 位 → 进入第三步
❌ 正确文档排在后面 → 排序失败（相似度计算不准确、重排模型问题）

第三步：检查上下文装配

目标：确认正确文档是否真的被送给了模型。查看最终发给模型的 Prompt，确认文档内容是否完整，检查 Token 长度是否超限。

✅ 正确文档完整送达 → 进入第四步
❌ 文档被截断或丢失 → 上下文装配失败（Token 超限、拼接逻辑错误）

第四步：检查模型输出

目标：确认模型是否根据文档正确生成答案。查看模型的原始输出，对比文档内容和模型答案。

✅ 模型正确引用了文档 → 不是 RAG 问题，可能是用户期望问题
❌ 模型没有使用文档或编造答案 → 模型幻觉（Prompt 不够明确、Temperature 太高）

真实案例（示例）

问题：用户提问"公司 Q3 财报的营收是多少？"，AI 回答了错误的数字。

诊断过程：

检查召回：✅ 召回了正确的财报文档
检查排序：✅ 财报文档排第一
检查上下文装配：❌ 发现问题 — 文档被截断，只保留了前 500 字，营收数据在第 800 字
根因：Token 限制导致文档被截断
修复：优化文档切块策略，确保关键数据不被截断

问题 2

API 成本突然翻倍

现象

月度账单显示 API 调用成本翻倍，但业务量没有明显增长。

诊断流程：3 层检查

第一步：检查 Token 用量

目标：确认是单次请求变大，还是请求次数变多。查看 API 日志，统计总请求次数、平均 Input Token 数、平均 Output Token 数，对比上个月数据。

请求次数翻倍 → 业务逻辑问题（可能有重复调用、死循环）
单次 Token 数翻倍 → 进入第二步

第二步：检查 Prompt Cache 命中率

目标：确认是否因为缓存失效导致成本增加。查看 Prompt Cache 命中率，对比上个月的命中率。

✅ 命中率正常（> 80%） → 进入第三步
❌ 命中率下降 → 缓存失效（请求间隔超过 TTL、Prompt 前缀不一致、系统提示词频繁变化）

第三步：检查上下文长度

目标：确认是否因为上下文变长导致成本增加。统计最近一周的平均上下文长度，分析哪些内容占用了 Token。

可能原因：文档库扩充召回的文档变多、对话历史变长（多轮对话场景）、RAG 返回了过多无关文档。

真实案例（示例）

问题：成本从 $500/月涨到 $1200/月。

诊断过程：

检查 Token 用量：请求次数没变，但平均 Input Token 从 2000 涨到 5000
检查 Prompt Cache：命中率从 85% 降到 20%
发现问题：开发团队在系统提示词中加了一句"请确保答案准确"，导致每次请求的前缀都不一样，缓存全部失效
根因：Prompt 前缀不一致
修复：把"请确保答案准确"移到 Prompt 的最后，恢复缓存命中率

问题 3

用户投诉"有时候拒答"

现象

用户反馈："AI 说它做不了这个" / "AI 让我换个问法"

诊断流程：定位拒答类型

找到用户的原始请求，查看 AI 的完整回复，判断是哪一层拒绝的。

类型 A：安全策略拒绝

特征：AI 回复"我不能帮你做这个"、"这违反了使用条款"

根因：触发了模型的安全策略

修复：优化用户输入的引导，避免敏感词汇

类型 B：权限层拒绝

特征：日志显示"Permission denied" / "Unauthorized"

根因：权限检查不通过

修复：检查权限配置，确认用户有访问权限

类型 C：超时 / 工具调用失败

特征：日志显示"Timeout" / "Tool execution failed"

根因：后端工具执行失败，但 AI 没有正确处理

修复：优化错误处理，让 AI 能重试或给出更友好的提示

真实案例（示例）

问题：用户反馈"AI 经常说它做不了这个"。

诊断过程：

检查日志：发现 20% 的请求被拒答
定位拒答类型：80% 是类型 C（工具调用失败）
发现问题：外部 API 偶尔超时，AI 收到错误后直接告诉用户"我做不了"
根因：错误处理不当
修复：让 AI 能重试 1 次，优化错误回填，区分"工具失败"和"任务无法完成"

通用原则

诊断的 4 个核心原则

1. 先看日志，别猜

不要凭感觉判断，先查日志定位问题层级。

2. 分层诊断

用户输入 → 前端处理 → 召回/检索层（RAG）→ 模型调用层 → 工具执行层 → 结果返回层 → 用户看到的结果。每一层都可能出问题，逐层排查。

3. 只改一个变量

一次只修一个地方，再测试。不要同时改 Prompt、模型、检索策略。

4. 保留证据

保存问题请求的完整日志，记录修复前后的对比数据，方便下次遇到类似问题。

附录

常用日志字段

RAG 日志应该记录什么

{
  "request_id": "唯一请求ID",
  "user_query": "用户原始问题",
  "retrieved_docs": [
    {
      "doc_id": "文档ID",
      "score": "相似度分数",
      "rank": "排名",
      "snippet": "文档片段"
    }
  ],
  "final_context": "最终发给模型的上下文",
  "model_response": "模型原始输出",
  "timestamp": "时间戳"
}

API 调用日志应该记录什么

{
  "request_id": "唯一请求ID",
  "model": "claude-opus-5-5",
  "input_tokens": 2000,
  "output_tokens": 500,
  "cache_hit": true,
  "latency_ms": 1200,
  "cost_usd": 0.05,
  "timestamp": "时间戳"
}

使用建议

关于这份 SOP

版本：v1.0
最后更新：2026-09-27
适用范围：AI 产品运营、模型评测、AI 应用运维

局限性

这是通用流程，具体问题需要结合实际业务
不涵盖底层模型训练、算法优化
适合产品运营、技术运营、评测岗位参考

使用建议

面试时可以展示这份文档，说明你懂 AI 应用的真实问题
入职后可以根据实际业务调整和扩展
遇到新问题时，记得更新这份 SOP

这份 SOP 基于我在 AI 工具开发、长任务评测和 RAG 应用中的实践经验整理。

返回首页 →