智能体评估为何比RAG更难？金融财务分析实战拆解

智能体评估正在成为大模型落地过程中最被低估的环节。马式教育专门讲大模型的老师在B站直播中，以正在讲授的第12个项目——基于Langfuse的智能体评估平台——为背景，系统拆解了智能体评估与RAG评估、传统软件测试之间的本质差异。这场分享并非泛泛而谈的方法论，而是建立在一个真实运行的金融财务分析智能体之上：采集了9300多条全球上市公司财务报告数据，用SQLite轻量级数据库存储，智能体基于这些公开财报回答金融、基金、股票相关的分析问题。

智能体评估的三个关键认知

认知一：概率模型决定了100%准确率不存在

智能体的底层是大模型，而无论是DeepSeek^广告、OpenAI还是Anthropic的模型，本质上都是概率模型——基于上一个token通过概率计算推出下一个token。注意力机制虽然能让模型理解语义和逻辑，但概率模型的本质决定了它很难做到100%准确。

做评估的目标是让智能体的结论或操作结果(趋近于)100%，而不是(达到)100%。这位讲师在项目中反复强调：不管做多少层评估，智能体大概可以做到99.9%，但永远无法真正达到100%。这个认知直接决定了评估体系的设计思路——不是追求绝对正确，而是建立一套能持续逼近上限的追踪机制。

什么是token与自回归生成

要理解概率模型为何无法达到100%准确，需要先理解token与自回归生成机制。token是模型处理文本的最小单位，可能是一个词、一个子词甚至一个字符。所谓自回归，是指模型每次只预测下一个token，然后把预测结果拼接到输入序列末尾，再基于扩展后的序列预测下一个token，如此循环往复，直到生成结束符。每一步预测都来自一个概率分布，模型从中采样或取概率最高的token。这意味着即便输入完全相同，在温度参数大于0的采样策略下，多次运行也可能产生不同的token序列，进而走向不同的工具调用路径和推理过程。这种内在的随机性正是概率模型无法保证100%确定性的根本来源，也是评估体系必须围绕分布与趋势而非单点判定来设计的原因。

认知二：智能体评估≠大模型评估

大模型评估的逻辑是：提出一个问题，让模型生成答案，根据答案评估模型能力。这个过程相对直接。

智能体评估则完全不同。智能体不仅有最终回复，还有工具调用链路、数据读取过程、中间推理步骤。评估对象从单一输出变成了整个执行链路，复杂度自然上升一个量级。

什么是工具调用与执行链路

智能体区别于普通大模型的核心能力是工具调用（Tool Calling）。智能体在推理过程中可以决定调用外部函数或API，例如执行SQL查询、读取文件、进行数值计算，再把工具返回的结果作为新的上下文继续推理。一次完整的智能体执行会形成一条包含多个节点的链路：用户提问、意图理解、选择工具、生成参数、执行工具、读取返回、二次推理、生成答案。链路上的每一个节点都可能出错，例如选错工具、参数填错、时间范围过滤不当。评估大模型只需考察最终文本输出，而要评估智能体，就必须还原并检查整条执行链路，这也是两者复杂度相差一个量级的直接原因。

认知三：智能体评估≠传统软件测试

很多人误以为智能体评估就是测试软件能不能正常运行。这个类比从根本上就是错的。

传统软件测试关注功能是否按预期执行，结果是确定性的。智能体评估面对的是概率性输出，同样的输入可能产生不同的工具调用路径和推理过程。用一个确定性框架去评估一个概率性系统，本身就是错配。

财务分析智能体的评估难在哪里

一个例子说明问题

假设问智能体：“鑫河制造这家公司按年五年营业收入比按年四年增长了多少？”智能体回答“20%”。

传统思路是直接看答案对不对——如果标准答案是20%，就判定正确。但这种判断方式存在两个致命漏洞：

第一种情况，智能体碰巧计算错了，但结果歪打正着等于20%。答案对了，过程全错。

第二种情况，上下文信息中恰好提到某公司营业收入增长了20%，但那是“按年三年”的增长，不是“按年五年”。大模型没有识别出年份差异，直接拿了错误范围的数据作为答案。答案看起来对了，数据来源完全错误。

仅凭最终答案判断对错，无法区分“真正理解并正确计算”和“碰巧蒙对”。

评估需要覆盖完整链路

智能体评估必须同时满足三个条件才能判定答案正确：

• 结果合理：最终输出的数值或结论符合预期
• 证据合理：工具调用了正确的数据源，读取的数据范围、时间过滤条件、字段选择都正确
• 工具调用链路合理：从数据查询到公式计算，分子分母选择正确，整个推理链条没有断裂

三个条件缺一不可。这就解释了为什么智能体评估比RAG评估更复杂——RAG评估主要关注检索质量和生成质量，而智能体评估需要追踪工具调用、数据流转、多步推理的完整链路。

什么是RAG评估

RAG（检索增强生成）评估通常聚焦两个核心环节：检索质量和生成质量。检索质量关注召回文档是否相关、排序是否合理，常用命中率、召回率、MRR等指标衡量；生成质量关注答案是否忠实于检索到的上下文、是否回答了用户问题，常用忠实度、答案相关性等指标衡量。相比之下，RAG的链路较短，基本是“检索—拼接—生成”三步，中间没有工具参数构造和外部执行环节。智能体评估则在这三步之外，还要追踪工具选择是否正确、参数传递是否准确、数据范围与过滤条件是否匹配，因此评估维度更多、链路更长，对追踪基础设施的要求也更高。

Langfuse评估平台实战：从数据到追踪

该项目使用Langfuse搭建智能体评估平台，数据层面采集了9300多条全球上市公司财务报告，存储在SQLite数据库中。表名为financial_report，包含公司名称、年份、PDF文件路径、文本内容和表格数据。

这些数据来自公开渠道，是上市公司对外发布的真实财务报告。智能体基于这些数据回答金融分析问题，而评估系统则需要追踪每一次回答背后的完整链路。

这位讲师提到，在讲授这个项目的过程中发现评估环节“挺有意思”，因此专门拿出时间在直播中讨论。项目已接近尾声，还剩约三个小时的内容。

什么是Langfuse与链路追踪

Langfuse是一款开源的LLM应用可观测性与评估平台，专为大模型和智能体应用设计。它提供trace（追踪）、span（跨度）、generation（生成）等核心概念：一次完整的智能体请求对应一个trace，链路中的每个步骤（如一次工具调用、一次模型生成）对应一个span或generation。开发者可以通过SDK埋点，自动记录每一步的输入输出、耗时、token消耗和参数信息。基于这些结构化日志，Langfuse支持定义评估函数、打分、对比实验版本，并把评估结果可视化。在本项目中，它承担的角色正是把智能体的完整执行链路落到可查询、可回溯的记录中，从而让“证据合理”和“链路合理”这两类判断有了数据基础，而不是仅凭最终答案的字符串比对。

智能体评估的工程启示

评估不是智能体开发完成后的附加步骤，而是贯穿开发全程的基础设施。从这位讲师的分享中可以提炼出几条工程实践方向：

评估对象从结果转向链路。 需要记录智能体每一步的工具调用、参数传递、数据读取和中间推理，才能判断最终答案是否真正可靠。

接受概率性本质。 评估指标的设计应围绕“趋近于”而非“等于”，关注分布和趋势而非单点判定。

区分评估层次。 大模型评估、RAG评估、智能体评估是三个不同层次的问题，不能混用同一套方法论。

智能体评估的复杂性来源于系统本身的复杂性。当智能体从简单的问答工具变成能调用工具、读取数据、执行多步推理的自主系统时，评估也必须从答案比对升级为链路追踪。这不是一个可以简化的过程，而是智能体走向生产环境必须跨越的门槛。