構建AI金融智慧體的經驗教訓

在金融服務領域構建AI智慧體，我花了兩年時間積累了大量經驗。這篇文章將系統性地分享這些教訓，涵蓋從沙箱到監控的方方面面。

金融服務的嚴苛性

這個領域不容許任何錯誤。數字至關重要——錯誤的收入數字、曲解的業務指引、不準確的DCF假設，都可能導致專業投資者做出百萬美元級別的錯誤決策。使用者是金融界最聰明、時間最緊迫的人群，他們能瞬間識別出紕漏。這迫使我對每一個細節都近乎偏執：每個數字都要複核，每個假設都要驗證，每個模型都要經過壓力測試。這種對錯誤的恐懼，反而成了我們最好的品質。

在LLM的應用歷程中，我們早期做出了一些大膽的基礎設施選擇，事後證明是正確的。例如，當Claude Code推出以檔案系統為先的智慧體化方法時，我們立即採納——這並非顯而易見的決定，而是對架構的一次大規模重構。當時整個行業（包括Fintool自己）都在構建複雜的RAG管道，使用向量資料庫和嵌入。在反思資訊檢索的未來後，我寫了“RAG訃告”，Fintool全面轉向智慧體搜尋，甚至退役了寶貴的嵌入管道。人們曾認為我們瘋了，但如今許多初創公司都在採納這些最佳實踐。

沙箱不是可選項

2023年剛啟動Fintool時，我曾以為沙箱是多餘的。“只是執行Python指令碼而已”，我這樣告訴自己。結果證明一切皆有可能出錯——當LLM第一次試圖在伺服器上執行rm -rf /（為了“清理臨時檔案”）時，我成了沙箱的堅定信徒。

智慧體需要執行多步操作：專業投資者要求DCF估值，這不是單次API呼叫。智慧體需要研究公司、收集財務資料、在Excel中建立模型、執行敏感性分析、生成複雜圖表、迭代假設。這涉及幾十個步驟，每個步驟都可能修改檔案、安裝包、執行指令碼。沒有程式碼執行就不可能實現，但在伺服器上執行任意程式碼是瘋狂的。每個聊天應用都需要沙箱。

如今，每個使用者都有自己的隔離環境。智慧體可以在其中為所欲為——刪除所有檔案、安裝奇怪的包——這是使用者的沙箱，盡情享受。架構包含三個掛載點：/private（讀寫，使用者個人檔案）、/shared（只讀，組織檔案）、/public（只讀，全域性資源）。關鍵在於憑證：我們使用AWS ABAC（基於屬性的訪問控制）生成限定於特定S3字首的短期憑證，使用者A物理上無法訪問使用者B的資料。我們還實現了沙箱預熱——使用者開始輸入時，後臺即啟動沙箱，等使用者按下回車時沙箱已就緒。

上下文即產品

智慧體的好壞取決於它能訪問的上下文。真正的工作不是提示工程，而是將來自數十個來源的混亂金融資料轉化為清晰、結構化的上下文，供模型使用。這需要工程團隊具備深厚的領域知識。

金融資料以各種格式呈現：SEC檔案（HTML巢狀表格）、財報電話會議記錄（說話者分割文本）、新聞稿、研究報告（PDF）、市場資料（資料庫）、新聞、另類資料（衛星影像、網頁流量）、券商研究、基金檔案等。每個來源都有不同的模式、更新頻率和質量水平。智慧體需要的只有一件東西：可推理的乾淨上下文。

我們將其統一為三種格式：敘述性內容用Markdown、結構化資料用CSV/表格、可搜尋性用JSON後設資料。分塊策略至關重要：10-K檔案按監管結構（第1、1A、7、8項...）分塊；財報電話會議按說話者輪次分塊；新聞稿通常為一個塊；新聞文章按段落分塊。分塊策略決定智慧體能檢索到什麼上下文——糟糕的分塊導致糟糕的回答。表格是特殊領域：LLM擅長推理Markdown表格，但不擅長處理HTML標籤或原始CSV轉儲。因此標準化層將所有表格轉換為乾淨Markdown表格。後設資料使檢索成為可能：當使用者問“蘋果在上次財報電話會議上關於服務收入說了什麼？”時，系統需要解析股票程式碼、過濾檔案型別、進行時間篩選、定位章節。這正是為什麼每個文件都有meta.json——沒有結構化後設資料，檢索就等同於在草垛裡找針。任何人都可以呼叫LLM API，但不是每個人都有能力將數十年的金融資料標準化為可搜尋、分塊、帶後設資料的Markdown。資料層才是智慧體真正工作的基礎。

解析難題

標準化金融資料佔據了80%的工作量。SEC檔案具有對抗性：它們不是為機器閱讀設計的，而是為法律合規設計的。表格跨越多頁，頁首重複；腳註交叉引用其他腳註；數字出現在文本、表格和附件中（有時不一致）；XBRL標籤常用錯或不完整；不同申報人格式迥異。我們嘗試過現成的PDF/HTML解析器，它們在代理宣告中的多列布局、MD&A部分的巢狀表格（表格中的表格）、水印和頁首侵入內容、掃描附件以及Unicode問題上紛紛失敗。

Fintool解析管道包括：原始檔案 → 文件結構檢測 → 表格提取（保留單元格關係） → 實體提取（公司、人物、日期、金額） → 交叉引用解析 → 財政週期標準化 → 質量評分。表格提取本身值得專題討論：金融表格含義密集——合併標題單元格、腳註標記、負數括號、混合單位、前期重述。我們對每個提取的表格進行評分：單元格邊界準確性、表頭檢測、數字解析、單位推斷。低於90%置信度的表格被標記為人工審查。財政週期標準化至關重要：“Q1 2024”存在歧義——可能是日曆Q1（2024年1-3月）、蘋果的財政Q1（2023年10-12月）或微軟的財政Q1（2023年7-9月）。我們維護了一個包含10000多家公司的財政日曆資料庫，每個日期引用都標準化為絕對日期範圍。這對使用者不可見，但對正確性必不可少。

技能至上與模型迭代

技能是產品核心。基於Markdown的技能——例如透過ReadFile、WriteFile和Bash工具實現的檔案系統操作——使智慧體能夠執行復雜金融工作流。這些技能設計為獨立於模型，以便隨著模型的改進而演進。我們的架構旨在適應未來：當前模型可能擅長某些任務，但下一代模型會更好。因此，我們按“技能”而非按“模型能力”來構建產品。

S3優先架構

使用者資料儲存在S3中，而非資料庫。S3在檔案儲存上遠優於資料庫：它提供無限擴充套件性、強一致性（針對新物件）、強大的訪問控制（ABAC），並且與沙箱環境無縫整合。每個使用者的工作目錄都直接對映到S3字首，使檔案操作既簡單又安全。

Temporal與即時流

Temporal管理長期執行的任務。當使用者啟動一個複雜的分析時（例如，篩選1000支股票），Temporal確保任務可靠執行，支援暫停、恢復和取消——並且取消處理是乾淨利落的，不會留下殭屍程序。即時流透過delta更新實現：智慧體逐步生成結果，使用者介面逐步展示，而非等全部完成才顯示。這創造了流暢的互動體驗。

評估與監控

評估不是可選項。我們構建了領域特定的評估框架：例如，檢查DCF模型中的計算是否正確、表格資料與原文是否一致、法律免責宣告是否被意外刪除。這些評估在使用者發現之前捕捉錯誤。生產監控則依賴於日誌、指標和告警系統。我們追蹤每個工具呼叫的延遲、成功/失敗率，以及使用者反饋（例如，使用者是否刪除了智慧體的輸出？）。這使我們能快速迭代改進。

總之，構建金融AI智慧體是一個系統工程，涉及資料管道、基礎設施、使用者體驗和風險評估的深度結合。分享這些經驗教訓，希望能幫助更多同行少走彎路。