上次國產AI模型測評后，大模型糟糕的聯網信息搜索能力令人耿耿于懷。

看起來很簡單的信息獲取和四則運算，AI一本正經給出的答案全是胡編亂造。

“聯網搜索”功能一開，人工智能秒變“人工智障”。

要想讓AI提供可靠的信息與結論，就得老老實實地把財報喂給它。

但是，財務分析，不可能每次只看一篇財報。

很明顯，AI的“飯量”是有限的，上下文窗口的存在意味著不可能將一摞財報全都丟給AI。

何況，即便是能上傳多篇財報，也會導致分析處理過程的“消化”時間大大延長。

“智能窘境”當前，我們開始探索新的路徑——試圖通過為大模型外掛“RAG知識庫”的方式，打開新世界。

一番測試下來，你猜怎么著？

01

致命的幻覺

首先需要明確的一點是，AI自帶的知識儲備是有時限的。對于某一時間點以后的數據，AI是完全不知情的。

有些誠實的模型會告訴我們：“對不起，我暫時無法獲取到某年某月某日以后的數據。”

圖：Hunyuan-T1獲取2025年第1季度財務指標

而有些“機制”的模型則會用各種方法試圖給我們創造答案，畢竟，編造數據和假設數據對于AI完全是小菜一碟。這就是我們常說的AI的“幻覺”。

然后，AI聯網搜索的信息來源可謂是五花八門。畢竟，互聯網上假消息遠比真消息多。

點開模型的深度思考和網頁搜索界面就可以看到，參與評測的模型能夠找到比較靠譜的信息來源，通常是各大網站的財經作者發布的文章，比如東方財富網、雪球、網易、新浪和騰訊等。

但是，也有一些模型的信息來源看著就很不靠譜，比如股吧評論。

總之，沒有任何一個模型能夠獲取最權威的財報原文，這就是聯網搜索的最大弊端之一。

最后，上下文窗口的長度是每個AI大模型產品在發布時都會強調的重點，它代表著AI的短期記憶能力。

作為上次評測材料的美團季度財報，僅一篇就長達30頁，模型能夠不出錯實屬不易。

若上傳多篇財報，AI的“腦容量”瞬間告急，好比最后一天才想起寫假期作業的學生，結果可想而知，大概只能靠胡編亂造了。

02

可能的破局之法

解決信息質量差和記憶力不足的方法其實不難。

上大學的時候，每次一門新課的開頭，老師都會告知學生這門課的考試形式。每次“開卷考試”四個字一出，教室里總有一大群人長出一口氣。

在開卷考試的情況下，如果書上有標準答案，學生自然不會去網上找些不靠譜的答案，更不必去死記硬背課本，而AI也可以使用這個辦法來應對“考試”，即——

RAG：Retrieval-Augmented Generation，檢索增強生成。

簡單的來說，就是讓AI先從知識庫中檢索相關內容，再基于內容生成答案。

因此，首先需要把所有的財報PDF上傳到同一個地方，也就是我們的“知識庫”。當然，這個知識庫中并不局限于PDF文件，相關的Excel統計表格、Word文檔也可以一并放入，成為AI存放了大量教科書的專屬圖書館。

如此，AI在回答時就必須先來這個“圖書館”尋找答案。接下來，我們分步來看看RAG的具體工作流程。

數據準備階段（離線）：

Step.1 文本切分

在這一步，我們需要解決財報篇幅過長的問題。前面說過，美團的一篇財報就足足有30頁，通讀全文對于AI來說實在是強人所難。

因此，需要“快刀斬亂麻”，把財報的全篇內容分解成意義明確的小型段落。

Step.2 文本向量化

事實上，AI并不能直接閱讀人類語言，因為計算機能夠看懂的只有數字。

這時候，就需要借助一個“嵌入模型”（Embedding Model）來把文本轉化成我們熟悉的另一個概念——向量。

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

眾所周知，向量就是一串數字，AI就是用它來獲取文本中的語義信息。

一大堆向量聚在一起，就構成了向量空間。而意思接近的文本，在向量空間中的距離會更近。

Step.3 向量存儲

文本切割為小型段落后，將會和對應的向量一起被存儲于向量數據庫。

目的也很簡單，在經過特殊優化后，向量數據庫中就可以進行大規模的向量相似度檢索。

應用階段（在線）：

Step.4 查詢向量化

假設用戶提出了問題：“流動比率是什么？”

上面已經說過，AI無法直接閱讀文字，因此用戶提出的指令也需要轉化成向量。

需要注意的是，對知識庫使用的嵌入模型與對用戶指令使用的嵌入模型必須是同一個。

只有這樣，才能保證兩者處于同一個向量空間中。也只有在同一個向量空間中，才能比較和查詢文本向量的相似度。

Step.5 向量檢索

在獲得用戶指令對應的向量后，就可以去向量數據庫中檢索與之“距離最近”的文本段落對應的向量，也就是計算向量之間的相似度。

相似度的計算方法是使用某個函數，對用戶指令對應的向量與向量數據庫中的向量進行運算，將得出的結果按順序排列，提取前N個結果。

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

根據提取到的結果，對應的文本段落可能是：

“流動比率是流動資產對流動負債的比率。”

“流動比率可以衡量企業流動資產在短期債務到期以前可變為現金用于償還負債的能力。”

“流動比率越高，說明企業資產的變現能力越強，短期償債能力亦越強。”

Step.6 構建增強提示詞

在檢索到相關知識（相似度最高的一些向量對應的文本段落）后，還要再加上用戶的指令，打包成一個新的提示詞（prompt），發送給大語言模型，例如：

請根據以下提供的上下文信息，來回答用戶的問題。如果上下文中沒有相關信息，請直接說你不知道。

[上下文信息]:

- 流動比率是流動資產對流動負債的比率。

- 流動比率可以衡量企業流動資產在短期債務到期以前可變為現金用于償還負債的能力。

- 流動比率越高，說明企業資產的變現能力越強，短期償債能力亦越強。

[用戶問題]:

流動比率是什么？

Step.7 生成答案

大模型收到增強的提示詞，相當于學生在開卷考試中在書里找到了答案，可以根據自己的語言組織能力正式開始作答。

圖：RAG工作流程示意圖

03

實戰：使用騰訊元器搭建AI財報分析助手

理論看起來很完美，實踐效果如何？使用騰訊元器上手試一試。

騰訊元器——混元大模型團隊推出的智能體開放平臺，可通過插件、知識庫和工作流等方式構建低代碼式的智能體。

第一步，創建知識庫。

在實際測試中，我們選定6家公司：美團、京東、百度、騰訊、谷歌、阿里。

為每家公司單獨創建一個知識庫，選擇文本類型，并上傳自2023年第一季度至2025年第一季度的財報。

第二步，創建工作流。

事實上，要使用騰訊元器的智能體，工作流并非必要。

但是，由于工作流是一套預設好的、固定的流程，使用工作流構建智能體可以更直觀地展現工作流程，杜絕聯網搜索的可能性。

工作流的設計采用“路由分發”模式：先用一個大語言模型節點來識別用戶指令中提及的公司實體和分析任務，然后根據識別結果動態地調用相應的知識庫進行查詢，最后再由一個匯總節點整合所有檢索到的信息，生成一個全面、精準的回答。

圖：工作流結構圖

首先，工作流的開始節點用于接收用戶輸入的指令，將之命名為query。

此后，以阿里為例，使用一個LLM節點和條件分支節點來判斷用戶的指令中是否包含阿里及其別稱。

圖：”Ck_Alibaba”節點的系統提示詞

若包含，則需要調用阿里的財報知識庫進行查詢。

先使用LLM節點進行查詢改寫，該節點共設置兩項任務：

若用戶指令中包含多家公司，則該節點只會輸出與阿里相關的查詢任務。

若用戶指令中采取阿里的別稱，統一轉化為“阿里”進行查詢。

圖：”查詢改寫_Alibaba”節點的系統提示詞

查詢改寫節點輸出的就是直接明了的查詢任務，直接連接知識庫檢索節點即可。

若不包含，表明此時無需調用阿里的財報知識庫。

由于工作流不允許條件分支節點的else分支置空，需要連接一個空輸出LLM節點。

圖：”Em_Alibaba”節點的系統提示詞

最后，將各公司對應的知識庫檢索節點和空輸出LLM節點統一與一個LLM節點連接，用于匯總全部信息，與輸出節點連接即可。

第三步，創建智能體。

在智能體配置頁面，需要通過“切換創建方式”，改為使用工作流模式，并配置上文中創建的工作流。

智能體每次回復時，一定會運行該工作流。

圖：工作流模式的財報分析助手智能體

04

實驗結論：理想還難以照進現實

經過測試，我們很遺憾地發現，無論是騰訊元器、海外的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模型，而這些模型已經經過了預訓練過程，因此，模型本身已經存在記憶，受到無關信息的干擾。

同時，模型內部的注意力機制導致其對不同詞匯的權重存在一定差異，忽略或錯誤理解用戶指令中的某些細節也就不足為奇了。

05

總結與展望

實測結果表明，除了我們自身的能力因素之外，目前低代碼式RAG平臺的功能還存在一定欠缺。

這些平臺最大的優勢在于便利，允許用戶規避編寫代碼環節來使用AI產品，大大降低了使用門檻。

但平臺也隱藏了大量技術細節，用戶無法根據自身需求進行精細化調整。

例如，騰訊元器中僅僅提供了十個類型的節點，在財務分析的應用中尚有欠缺，提取數據雖然杜絕了編造數據的情況，但也存在遺漏現象。

更不要提計算和分析等功能，因為那已經超出了經典RAG的范疇，將之歸類于“Agentic RAG”或“Tool-Augmented RAG”更加合適。

RAG存在三個核心局限：

一是難以執行精確的計算，即便給出準確的數據，也可能回答錯誤的答案；

二是缺乏深度推理和分析的能力，類似于早期的Chatbot模型，簡單的文本拼接無法構成觀點；

三是難以應對復雜任務，當流程大規模延長并出現迭代和循環時，還是需要代碼來進行處理；而隨著用戶的需求逐漸細化，則需要使用各種形式的插件，但這都已經與“低代碼”和快捷便利等初衷背道而馳。

因此，想要實現更加智能化的財務分析助手，僅僅使用RAG是不夠的。

對于開發者來說，仍然需要掌握一定的編程能力，利用代碼節點和插件節點提升工作流和智能體的業務覆蓋范圍。

理解RAG的局限，善用RAG的優勢，從RAG逐步走向Agentic RAG，才能在AI時代成為“馴獸師”，而非被動的使用者。