我搭建了一个“金融分析师智能体”，你猜怎么着？

上次国产AI模型测评后，大模型糟糕的联网信息搜索能力令人耿耿于怀。

看起来很简单的信息获取和四则运算，AI一本正经给出的答案全是胡编乱造。

“联网搜索”功能一开，人工智能秒变“人工智障”。

要想让AI提供可靠的信息与结论，就得老老实实地把财报喂给它。

但是，财务分析，不可能每次只看一篇财报。

很明显，AI的“饭量”是有限的，上下文窗口的存在意味着不可能将一摞财报全都丢给AI。

何况，即便是能上传多篇财报，也会导致分析处理过程的“消化”时间大大延长。

“智能窘境”当前，我们开始探索新的路径——试图通过为大模型外挂“RAG知识库”的方式，打开新世界。

一番测试下来，你猜怎么着？

一、致命的幻觉

首先需要明确的一点是，AI自带的知识储备是有时限的。对于某一时间点以后的数据，AI是完全不知情的。

有些诚实的模型会告诉我们：“对不起，我暂时无法获取到某年某月某日以后的数据。”

图：Hunyuan-T1获取2025年第1季度财务指标

而有些“机制”的模型则会用各种方法试图给我们创造答案，毕竟，编造数据和假设数据对于AI完全是小菜一碟。这就是我们常说的AI的“幻觉”。

然后，AI联网搜索的信息来源可谓是五花八门。毕竟，互联网上假消息远比真消息多。

点开模型的深度思考和网页搜索界面就可以看到，参与评测的模型能够找到比较靠谱的信息来源，通常是各大网站的财经作者发布的文章，比如东方财富网、雪球、网易、新浪和腾讯等。

但是，也有一些模型的信息来源看着就很不靠谱，比如股吧评论。

总之，没有任何一个模型能够获取最权威的财报原文，这就是联网搜索的最大弊端之一。

最后，上下文窗口的长度是每个AI大模型产品在发布时都会强调的重点，它代表着AI的短期记忆能力。

作为上次评测材料的美团季度财报，仅一篇就长达30页，模型能够不出错实属不易。

若上传多篇财报，AI的“脑容量”瞬间告急，好比最后一天才想起写假期作业的学生，结果可想而知，大概只能靠胡编乱造了。

二、可能的破局之法

解决信息质量差和记忆力不足的方法其实不难。

上大学的时候，每次一门新课的开头，老师都会告知学生这门课的考试形式。每次“开卷考试”四个字一出，教室里总有一大群人长出一口气。

在开卷考试的情况下，如果书上有标准答案，学生自然不会去网上找些不靠谱的答案，更不必去死记硬背课本，而AI也可以使用这个办法来应对“考试”，即：

RAG：Retrieval-Augmented Generation，检索增强生成。

简单的来说，就是让AI先从知识库中检索相关内容，再基于内容生成答案。

因此，首先需要把所有的财报PDF上传到同一个地方，也就是我们的“知识库”。当然，这个知识库中并不局限于PDF文件，相关的Excel统计表格、Word文档也可以一并放入，成为AI存放了大量教科书的专属图书馆。

如此，AI在回答时就必须先来这个“图书馆”寻找答案。接下来，我们分步来看看RAG的具体工作流程。

数据准备阶段（离线）：

Step1. 文本切分

在这一步，我们需要解决财报篇幅过长的问题。前面说过，美团的一篇财报就足足有30页，通读全文对于AI来说实在是强人所难。

因此，需要“快刀斩乱麻”，把财报的全篇内容分解成意义明确的小型段落。

Step2. 文本向量化

事实上，AI并不能直接阅读人类语言，因为计算机能够看懂的只有数字。

这时候，就需要借助一个“嵌入模型”（Embedding Model）来把文本转化成我们熟悉的另一个概念——向量。

图：EmbeddingModelLeaderboard -https://huggingface.co/spaces/mteb/leaderboard

众所周知，向量就是一串数字，AI就是用它来获取文本中的语义信息。

一大堆向量聚在一起，就构成了向量空间。而意思接近的文本，在向量空间中的距离会更近。

Step3. 向量存储

文本切割为小型段落后，将会和对应的向量一起被存储于向量数据库。

目的也很简单，在经过特殊优化后，向量数据库中就可以进行大规模的向量相似度检索。

应用阶段（在线）：

Step4. 查询向量化

假设用户提出了问题：“流动比率是什么？”

上面已经说过，AI无法直接阅读文字，因此用户提出的指令也需要转化成向量。

需要注意的是，对知识库使用的嵌入模型与对用户指令使用的嵌入模型必须是同一个。

只有这样，才能保证两者处于同一个向量空间中。也只有在同一个向量空间中，才能比较和查询文本向量的相似度。

Step5. 向量检索

在获得用户指令对应的向量后，就可以去向量数据库中检索与之“距离最近”的文本段落对应的向量，也就是计算向量之间的相似度。

相似度的计算方法是使用某个函数，对用户指令对应的向量与向量数据库中的向量进行运算，将得出的结果按顺序排列，提取前N个结果。

而函数的形式是多样化的，如常用的余弦相似度等方法。

根据提取到的结果，对应的文本段落可能是：

“流动比率是流动资产对流动负债的比率。”

“流动比率可以衡量企业流动资产在短期债务到期以前可变为现金用于偿还负债的能力。”

“流动比率越高，说明企业资产的变现能力越强，短期偿债能力亦越强。”

Step6. 构建增强提示词

在检索到相关知识（相似度最高的一些向量对应的文本段落）后，还要再加上用户的指令，打包成一个新的提示词（Prompt），发送给大语言模型，例如：

请根据以下提供的上下文信息，来回答用户的问题。如果上下文中没有相关信息，请直接说你不知道。

[上下文信息]:

- 流动比率是流动资产对流动负债的比率。

- 流动比率可以衡量企业流动资产在短期债务到期以前可变为现金用于偿还负债的能力。

- 流动比率越高，说明企业资产的变现能力越强，短期偿债能力亦越强。

[用户问题]:

流动比率是什么？

Step7. 生成答案

大模型收到增强的提示词，相当于学生在开卷考试中在书里找到了答案，可以根据自己的语言组织能力正式开始作答。

图：RAG工作流程示意图

三、实战：使用腾讯元器搭建AI财报分析助手

理论看起来很完美，实践效果如何？使用腾讯元器上手试一试。

腾讯元器——混元大模型团队推出的智能体开放平台，可通过插件、知识库和工作流等方式构建低代码式的智能体。

第一步，创建知识库。

在实际测试中，我们选定6家公司：美团、京东、百度、腾讯、谷歌、阿里。

为每家公司单独创建一个知识库，选择文本类型，并上传自2023年第一季度至2025年第一季度的财报。

第二步，创建工作流。

事实上，要使用腾讯元器的智能体，工作流并非必要。

但是，由于工作流是一套预设好的、固定的流程，使用工作流构建智能体可以更直观地展现工作流程，杜绝联网搜索的可能性。

工作流的设计采用“路由分发”模式：先用一个大语言模型节点来识别用户指令中提及的公司实体和分析任务，然后根据识别结果动态地调用相应的知识库进行查询，最后再由一个汇总节点整合所有检索到的信息，生成一个全面、精准的回答。

图：工作流结构图

首先，工作流的开始节点用于接收用户输入的指令，将之命名为query。

此后，以阿里为例，使用一个LLM节点和条件分支节点来判断用户的指令中是否包含阿里及其别称。

图：“Ck_Alibaba”节点的系统提示词

若包含，则需要调用阿里的财报知识库进行查询。

先使用LLM节点进行查询改写，该节点共设置两项任务：

若用户指令中包含多家公司，则该节点只会输出与阿里相关的查询任务。

若用户指令中采取阿里的别称，统一转化为“阿里”进行查询。

图：“查询改写_Alibaba”节点的系统提示词

查询改写节点输出的就是直接明了的查询任务，直接连接知识库检索节点即可。

若不包含，表明此时无需调用阿里的财报知识库。

由于工作流不允许条件分支节点的else分支置空，需要连接一个空输出LLM节点。

图：“Em_Alibaba”节点的系统提示词

最后，将各公司对应的知识库检索节点和空输出LLM节点统一与一个LLM节点连接，用于汇总全部信息，与输出节点连接即可。

第三步，创建智能体。

在智能体配置页面，需要通过“切换创建方式”，改为使用工作流模式，并配置上文中创建的工作流。

智能体每次回复时，一定会运行该工作流。

图：工作流模式的财报分析助手智能体

四、实验结论：理想还难以照进现实 

经过测试，我们很遗憾地发现，无论是腾讯元器、海外的Coze还是开源的Dify，当前阶段的低代码式RAG应用在处理复杂的财报分析任务时，效果均不尽如人意，与理论上的完美表现存在差距。

以在腾讯元器上构建的智能体为例：

对于查询一家公司的一项财务指标时，智能体大概率能够给出准确的答案；

但是，有时也会产生一些错误，例如询问季度数据却回答财年数据：

图：查询阿里2025Q1的成本

在查询多家公司的一项财务指标时，回复质量也已经开始下降：

图：查询多家公司的一项财务指标

其中，智能体对于谷歌、美团和京东的回答均正确，但对于阿里却没有找到数据。

此外，京东的数据明显来自于文本段落的叙述，而非表格中的确切数字。

唯一令人欣慰的是，由于知识库和工作流的存在，智能体不会像一些大模型一样假设和编造数据，信誓旦旦地给出错误答案了。

我们推测，RAG智能体的表现不佳可能有如下原因：

1. 检索失败

“开卷考试时，课本被撕碎了，而查字典时近义词又太多。”

一方面，在文档解析与分块这一环节，RAG存在先天不足。

最简单也最常见的情况是上下文的割裂现象。

假设用户的指令要求查询某一季度的财务指标，而财报中有一个文本段落专门描述了这一指标的具体情况。

财报的首页可能已经注明这是哪个季度的财报，但当我们抛开上下文只专注于这一段落时，若没有提示，则很难判断所处时期。

文本切分阶段，就很容易产生这种“无头无尾”的知识块，而系统自然也难以将用户的指令和这些知识块进行匹配。

另一种情况是元数据的丢失。

最理想的情况下，我们希望每个知识块都带有“元数据”，例如“XX公司-202X年第X季度财报-XX页”。

但是，平台在解析时，若遇到大量的长篇财报，几乎不可能对每个知识块实现精确的标签标注，而是只能知道某个知识块来自于哪篇财报。

因此，即使是开卷考试，“书本”里也有“答案”，但“学生”也总会遇到不会做的“题”。

另一方面，向量检索存在语义模糊性。

前面讲解RAG工作原理时提到过，向量检索依靠的是“语义相似度”，而非“关键词精确匹配”。

以“2023年第四季度营收”和“2023年全年营收”为例，在我们看来，这两个指令的含义完全不同，人类甚至会因为注意到句式相同而重视其含义不同。

但在向量空间中，这两个指令对应的向量可能距离很近，如果“第三季度”和“全年”两个词的权重判断不够高，检索时就很容易发生段落之间的混淆。

2. 多模态理解失败与检索内容优先级

“学生重文轻理，宁读文字，不看图表。”

财务分析中，最常见的数据展示形式就是报表。

但对于计算机来说，一张存储了分散数据的表格和一段连续的文本存在天壤之别。

这是两种完全不同的数据结构，而后者远比前者易于处理，毕竟大部分RAG流程都是以文本为基础而设计的。

因此，在将文档上传至知识库，系统开始解析PDF时，我们会看到解析结果可能并非一张表格，而是一段冗长且杂乱的文本。

图：美团财报解析结果

如图所示，解析后的文本完全丢失了表格所具有的行列结构，语义完全混乱，不可能将项目与数据一一对应，这部分文本很有可能就变成了一个无用的知识块。

也因此，与上面这段“乱码”比起来，RAG系统更善于处理由完整的文本段落构成的知识块，这些知识块在检索过程中也自然而然地获得了更高的优先级。

从大语言模型和RAG的工作原理来看，其本质就是文本的概率生成。

而部分大语言模型和简单的RAG流程并不具备确认事实和数据精度检验的功能。

因此，在查询京东2024Q4的EBITDA时，智能体优先选择了文本段落中的“125亿元”，而非表格中的“12，529百万人民币”。

或许在智能体看来，这两个答案之间并不存在谁比谁更精确、更权威的关系，只是因为文本段落中的答案更容易匹配。

3. 生成环节失控

“带的参考书太多，看花了眼，抄错了行，好在还有点知识储备？”

由于工作流中的大语言模型节点使用的仍然是国内几个知名厂商推出的AI模型，而这些模型已经经过了预训练过程，因此，模型本身已经存在记忆，受到无关信息的干扰。

同时，模型内部的注意力机制导致其对不同词汇的权重存在一定差异，忽略或错误理解用户指令中的某些细节也就不足为奇了。

五、总结与展望

实测结果表明，除了我们自身的能力因素之外，目前低代码式RAG平台的功能还存在一定欠缺。

这些平台最大的优势在于便利，允许用户规避编写代码环节来使用AI产品，大大降低了使用门槛。

但平台也隐藏了大量技术细节，用户无法根据自身需求进行精细化调整。

例如，腾讯元器中仅仅提供了十个类型的节点，在财务分析的应用中尚有欠缺，提取数据虽然杜绝了编造数据的情况，但也存在遗漏现象。

更不要提计算和分析等功能，因为那已经超出了经典RAG的范畴，将之归类于“Agentic RAG”或“Tool-Augmented RAG”更加合适。

RAG存在三个核心局限：

一是难以执行精确的计算，即便给出准确的数据，也可能回答错误的答案；

二是缺乏深度推理和分析的能力，类似于早期的Chatbot模型，简单的文本拼接无法构成观点；

三是难以应对复杂任务，当流程大规模延长并出现迭代和循环时，还是需要代码来进行处理；而随着用户的需求逐渐细化，则需要使用各种形式的插件，但这都已经与“低代码”和快捷便利等初衷背道而驰。

因此，想要实现更加智能化的财务分析助手，仅仅使用RAG是不够的。

对于开发者来说，仍然需要掌握一定的编程能力，利用代码节点和插件节点提升工作流和智能体的业务覆盖范围。

理解RAG的局限，善用RAG的优势，从RAG逐步走向Agentic RAG，才能在AI时代成为“驯兽师”，而非被动的使用者。

本文来自微信公众号：锦缎研究院，作者：思齐