構建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智能體是一個系統工程，涉及數據管道、基礎設施、用户體驗和風險評估的深度結合。分享這些經驗教訓，希望能幫助更多同行少走彎路。