你是怎么判断问题主要来自模型幻觉，还是 RAG、Prompt、工具链路本身？
🎯 你是怎么判断问题主要来自模型幻觉，还是 RAG、Prompt、工具链路本身？——基于 Spring AI Alibaba 的 Agent 全链路评测实践
Agent 系统上线之后，一个最容易遇到的问题就是回答错误。然而，大多数团队第一反应都是认为模型能力不足，立即调整 Prompt 或更换模型。事实上，在真实生产环境中，模型幻觉仅仅只是众多问题来源之一，大量错误实际上来自于 RAG 检索、Prompt 设计、工具调用、权限过滤、Memory 污染以及 Agent Workflow 编排等多个环节。如果没有完整的评测体系，就无法准确定位问题来源，更无法持续优化 Agent 的整体效果。
因此，一个成熟的 Agent 系统不能仅仅关注最终答案是否正确，而应建立覆盖整个推理链路的评测体系，将结果评测(Process Evaluation)与过程评测(Result Evaluation)结合起来，通过 Trace 数据、日志回放、自动评分和人工标注共同完成问题定位，并利用评测结果持续反向优化 Prompt、Tool Schema、Memory、Router 以及 RAG 检索策略。
Agent 评测不是简单判断回答是否正确，而是评测每一个执行节点是否正确。生产环境真正需要回答的是："到底是哪一个环节出了问题？"
📌 一、问题背景
假设用户询问："今年公司员工总数是多少？"Agent 返回了错误答案。此时至少存在以下几种可能：
- RAG 根本没有召回对应知识文档。
- RAG 已经召回正确文档，但模型没有正确理解内容。
- Prompt 指令存在歧义，引导模型错误推理。
- Tool 调用了错误接口。
- Tool 参数生成错误。
- Memory 带入了历史错误上下文。
- 权限过滤导致关键数据被过滤。
- Workflow 路由到了错误 Agent。
如果仅凭最终答案判断问题来源，很容易误判。因此生产环境必须建立完整的 Agent Evaluation Pipeline，实现问题快速归因。
🚀 二、核心原理
整个评测体系通常拆分为结果评测（Result Evaluation）和过程评测（Process Evaluation）两个维度。
- 任务成功率（Task Success Rate）
- 答案准确率（Accuracy）
- 模型幻觉率（Hallucination Rate）
- 用户满意度（CSAT）
- 响应延迟（Latency）
- Token 消耗成本（Cost）
- Planner 是否规划合理
- Router 是否选择正确 Agent
- RAG 是否成功召回
- Tool 是否选择正确
- Tool 参数是否合法
- 是否发生重复调用
- 是否触发 HITL（Human In The Loop）
- Memory 是否污染上下文
Spring AI Alibaba 提供了丰富的 AI 抽象能力，可以通过 Advisor、ChatMemory、Tool Calling、Observation、Spring Boot Actuator、Micrometer 等组件，将整个 Agent 生命周期中的关键节点全部记录下来，从而形成完整的评测数据。
💡 三、数据结构分析
为了能够实现问题定位，每一次请求都应该生成唯一 TraceId，并记录整个 Agent 生命周期中的关键数据。
↓
TraceId
↓
User Question
↓
RAG Retrieval Documents
↓
Prompt Template
↓
LLM Request
↓
Tool Calling
↓
Tool Result
↓
Memory Context
↓
LLM Final Answer
↓
Evaluation Score
Spring AI Alibaba 中可利用 Advisor 拦截 Prompt，利用 ToolCallbackInterceptor 记录工具调用，利用 ChatMemoryAdvisor 获取上下文，再通过 Observation 将所有执行数据统一输出至 Trace 系统，例如 Zipkin、SkyWalking 或 OpenTelemetry。
🔥 四、算法与处理逻辑
生产环境中通常不会直接判断"模型回答错误"，而是采用排查树（Troubleshooting Tree）逐层定位问题来源。
第一步：检查 RAG 是否召回
- 未召回相关文档 → 检查 Embedding、向量库、Chunk、Retriever。
- 召回文档数量过少 → 调整 TopK、Hybrid Search、ReRank。
- 召回文档错误 → 检查索引质量。
第二步：检查 Prompt
- Prompt 是否遗漏业务约束。
- Few-shot 是否合理。
- System Prompt 是否冲突。
第三步：检查模型输出
- 文档正确但模型回答错误。
- 模型编造不存在的数据。
- 逻辑推理出现错误。
第四步：检查 Tool Calling
- 是否调用了错误 Tool。
- Tool 参数是否正确。
- Tool 是否超时。
- 接口是否返回异常。
第五步：检查 Memory
- 是否读取了历史错误上下文。
- 是否上下文过长导致截断。
🚀 五、执行流程（Spring AI Alibaba 落地方案）
在工程实现上，可以定义统一 EvaluationService，每次请求结束后自动计算 Accuracy、Hallucination、Tool Success Rate、Latency、Cost 等指标，并将评测结果写入数据库，形成长期评测数据集。
✅ 六、实际案例
某企业知识库 Agent 在回答制度类问题时，准确率只有 72%。团队最初怀疑模型能力不足，但通过 Trace 回放后发现：
- 80% 错误请求没有召回最新制度文档。
- Retriever TopK 设置过小，仅返回 2 篇文档。
- Chunk Size 过大导致关键内容被截断。
- Prompt 未限制"不知道不要编造"。
- Memory 将上一位用户上下文带入当前会话。
随后团队在 Spring AI Alibaba 中分别优化了 VectorStore 检索策略、Prompt Template、ChatMemory 隔离机制以及 Tool Schema，并增加 ReRank 排序模型，最终任务成功率提升至 95% 以上，而模型本身没有发生任何变化。
💡 七、优缺点分析
| 方案 | 优势 | 不足 |
|---|---|---|
| 最终答案评测 | 实现简单 | 无法定位问题来源 |
| 过程评测 | 定位精准，可持续优化 | 日志采集成本较高 |
| 全链路 Trace + Evaluation | 适合生产环境，支持持续演进 | 需要完善监控平台建设 |
🎯 八、面试常见问题
- Agent 为什么不能只评测最终答案？
- 如何区分模型幻觉与 RAG 检索失败？
- Spring AI Alibaba 如何记录 Prompt 与 Tool 调用？
- Tool Calling 应重点监控哪些指标？
- 如何实现 Agent Trace 回放？
- 如何统计幻觉率（Hallucination Rate）？
- Memory 污染如何检测？
- 如何通过评测结果持续优化 Prompt 与 Tool Schema？
- 自动评测与人工评测如何结合？
- 生产环境为什么需要长期维护标准任务集（Golden Dataset）？
📌 九、总结
判断 Agent 问题来源不能依赖经验，更不能简单归因为模型幻觉。成熟的工程实践应首先检查 RAG 是否成功召回；若召回失败，则重点排查向量检索、权限过滤、数据源质量及后处理逻辑；若召回内容正确但模型输出错误，则大概率属于模型幻觉或 Prompt 设计问题；若 Tool 调用异常，则进一步检查工具选择、参数生成及接口返回；若回答受历史上下文影响，则需要分析 Memory 是否发生污染。生产环境应基于 Spring AI Alibaba 构建覆盖 Prompt、RAG、Tool Calling、Memory、模型输出以及最终答案的全链路 Trace，完整记录检索文档、Prompt、模型响应、工具调用和最终结果，并结合标准任务集、Mock 工具环境、自动评分、人工标注、Micrometer 指标、OpenTelemetry 链路追踪及 Dashboard 持续监控失败链路、成本、延迟和异常工具调用，最终利用评测数据持续反向优化 Prompt、Router、Memory、Tool Schema 与检索策略，实现 Agent 系统的闭环迭代与稳定演进。
相关文章
-
你会怎么判断问题来自模型幻觉，还是RAG、Prompt、工具链路本身？
你会怎么判断问题来自模型幻觉，还是RAG、Prompt、工具链路本身？
NEW个对象 2026-06-19
-
工具链问题为何难以直接定位？
工具链问题为何难以直接定位？
NEW个对象 2026-06-19
-
：使用spring alibaba ai实现完整的链路日志结构?
使用spring alibaba ai实现完整的链路日志结构
NEW个对象 2026-06-19
