別讓模型自己編數字——Kepler 的 Vinoo Ganesh

Kepler 執行長 Vinoo Ganesh 主張，金融 AI 的架構必須做到讓模型引用數字、卻永遠不自行寫出數字——而一般的 RAG 流程在這項要求上徹底不及格。Ganesh 在這場對談中花了大部分時間說明 Kepler 的架構：一套建構在 SEC 申報檔案與內部檔案之上的確定性引用登入庫（citation registry）、在 turbopuffer 中執行的 BM25 加向量混合檢索、交叉編碼器重新排序，以及一道會剔除任何無法追溯數字的後處理過濾器。標題的警告是全場主軸，但整場演講主要是技術導覽，說明檢索與驗證堆疊如何組裝，最後再簡短預告另一場主舞臺演講，主題是 AI 時代的基本面投資。

Ganesh 在這裡的可信度來自基礎設施經歷，而非金融研究：他曾在 Palantir 帶領運算層、創辦過一家資料即服務（data-as-a-service）公司，創立 Kepler 之前則是 Citadel 的業務工程主管。以下簡報涵蓋他對天真 RAG 的失敗分類、引用登入庫的設計、檢索流程、租戶隔離模型，以及他引用的評估數字——其中包括一項說法：在 Kepler 的評估中，原生 LLM 加 RAG 的組合被拒絕了約 11,000 筆引用，其中約 3,810 筆單純就是錯誤的數字。

天真 RAG 會在三種特定錯誤上失手，而解法在架構

Ganesh 的核心論點是：事後才附上來源，並不能讓 LLM 的輸出變得可驗證。他點出三種失敗模式。第一，來源錯誤：模型從一份半相關的檔案檢索——他舉的例子是一篇 Seeking Alpha 貼文，或「Vinoo 隨便寫的 YOLO 部落格」宣稱 Palantir 每股將值 10 萬美元。第二，來源正確但數字錯誤：10-K 裡的一個「17」可能是 1,700 萬美元、170 億美元、1,700 萬日圓、出現在 2025 年申報檔案中的 2023 年數字，或只是頁碼。第三，心算：成長率、毛利率與估值倍數，而「模型本身根本沒有在做數學運算」，沒有任何方式能確保忠實度。

他提出的架構解方——他說這正是 Anthropic 在深入剖析 Kepler 時所記錄的做法——是分工：檢索負責找到正確來源，由人類預先寫好的確定性程式碼負責運算，後處理過濾器則移除任何無法驗證的內容。模型負責規劃；每一個數字，更廣泛地說每一個事實，都交給確定性軟體處理。

「我們最後必須開發出的架構，是讓模型引用數字，但永遠不自行寫出數字。」

他對取捨講得很明白。因為 Kepler 會剔除沒有引用的數字，所以「如果你依賴模型幻覺，它就不是個特別好用的工具」——它不會推測、不會做預測，也不會當你的創意思考夥伴。他坦承這讓產品不如使用者期望的那麼「神奇強大」，並表示某些金融工作流程並不適合（他點名投銀業務，那裡的工作是推銷一個方案，而不是建立可追溯的 DCF）。

約 2 萬個錨點的引用登入庫，讓每個數字都能點回來源

Kepler 預先處理了完整的 SEC 語料庫——Ganesh 說有「3,000 多萬份檔案」——並登入他所謂的引用：從申報檔案中擷取出的確定性數值事實，包括營收數字、損益表、資產負債表，以及人工撰寫的 MD&A 陳述，例如「我的營收成長了 37%」。他提到約有 2 萬個這類錨點，並說有「三項個別申報事實」被揭露為可引用的錨點——這句話在逐字稿中顯得混亂；實際的重點是：每個數字都能點選追溯回核心檔案。

每一項事實都帶有唯一識別碼，支援實體辨識與解析，另有儲存在確定性引擎中的中繼資料：數值、單位、尺度、期間，以及一個顯示值，讓平臺能以千美元、日圓或其他單位呈現。他陳述的不變式是：平臺上每一個數字與事實都能點選回其來源，這同時帶來冪等性保證——同一個查詢無論在哪裡執行，都回傳相同結果。

他反駁一個常見的反對意見，也就是 XBRL 已解決擷取問題：據他估計，XBRL「大約有 10% 的時候是錯的」，而且無論如何，多數投資決策依據的是內部資料——OneDrive、Box、SharePoint、Egnyte、Outlook、投資備忘錄——不只是公開申報檔案。因此 Kepler 的設計是：有結構的資料就予以結構化，沒有結構的就套用搜尋，兩者在同一個 turbopuffer 名稱空間中結合。

檢索先在 turbopuffer 大範圍搜尋，再用交叉編碼器重新排序

Ganesh 在他那張「神奇投影片」上畫出的流程，是在一個 turbopuffer 名稱空間內執行混合搜尋——對 1,280 維嵌入做近似最近鄰（ANN）搜尋，外加 BM25——接著做倒數排名融合（reciprocal re-ranking）取回約 60 份檔案，再做第二道以信任度加權的重新排序，然後經過交叉編碼器，結果才回傳給模型。他說他不擔心揭露這套設計，因為「這是個非常難的問題，而且變化很快。」

flowchart TD
    Q["使用者提問"] --> P["LLM 依工具知識建立計畫"]
    P --> S["在 turbopuffer 混合搜尋，ANN 1280 維加 BM25"]
    S --> R1["倒數排名融合，約 60 份檔案"]
    R1 --> R2["信任度加權重新排序，消解來源衝突"]
    R2 --> CE["交叉編碼器重新排序"]
    CE --> A["在 Postgres 對每個命中重新授權"]
    A --> M["模型收到結果"]
    M --> F["後處理引用過濾"]
    F -->|已驗證| O["附可點選引用的輸出"]
    F -->|無法驗證| X["剔除數字或送交修復"]

有兩項設計限制推動這一切。第一，當新資訊進來時，嵌入必須能低成本地重新產生；Ganesh 指出，自行架設嵌入模型會讓這件事又貴又難，所以策略是大範圍搜尋再重新排序，而不是窄範圍索引。第二，彼此矛盾的來源被視為訊號而非雜訊：法說會逐字稿中講者陳述的營收與 10-K 衝突，這「不是 bug，而是 feature」——這是兩筆不同的資訊，必須消解衝突，而不是把它們併成一筆。

每個檢索命中都在 Postgres 重新授權，把 alpha 留在公司內部

租戶隔離是內建在檔案層，而不是事後外掛。Ganesh 的舉例很傳神：「如果 Citadel 一號桌看到 Citadel 二號桌的研究，那會非常不幸。」中間查詢回傳的每一個命中，都會在 Postgres 中重新授權，針對每一項運算檢查引用、數值與檔案。查詢路徑上的每個建構器都會再加一層過濾，因此複雜的過濾堆疊會隨時間累積，防止資料不慎跨來源外洩。只有授權服務能簽發具範圍限定的 token 來查詢資料，而使用者與組織身分則來自簽署過的裝置。

他把這點連結到關於 alpha 的更大論點：在人人都有 LLM 可用的世界裡，差異化來自對公司自有語料庫的專屬檢索，而這正是隔離模型所保護的東西。

約三分之一的引用是模型根本沒做過的運算

Ganesh 最具體的生產環境統計：當 Kepler 跑完整個語料庫時，「我們所有引用中有三分之一，是模型沒做的運算。」這些引用來自網頁結果、試算表與申報檔案附件，每一筆都必須在推論時解引用（dereference）——他把 LLM 描述成在解引用一個指標，再由登入庫查詢提供可追溯性。當查無對應時，數字就會被剔除。

他特別點出歷史資料的一項風險：2005 年的營收數字很可能存在模型的訓練語料中，但從那裡檢索出來，無法保證它是從正確的年度與正確的範圍取得，也無法保證它可被追溯。這就是為什麼登入庫、而非模型記憶，是唯一可採信的來源。

他也承認有一條修復路徑——即時以代理方式判定某個無法追溯的數字確實來自某個來源——並刻意對細節語焉不詳，稱這是 Kepler 維護其智慧財產的一部分。

在 Kepler 的評估中，原生 LLM 加 RAG 被拒絕約 11,000 筆引用

評估數字是整場演講最犀利的部分。以過濾器對照原生模型行為——「就像直接在 Claude 或 ChatGPT 上跑」——Kepler 的評估拒絕了 10,981 筆引用，其中約 3,810 筆是「單純就錯的數字」。Ganesh 稱這對「做金融分析的人來說，是史上最可怕的事」，並下結論：把 Claude 或 OpenAI 的模型接上原生 RAG 工具或向量資料庫，對需要數值準確性與可稽核性的工作來說並不夠。他把這點延伸到實質上只是 ChatGPT 包裝的新創，講得很直白而非嘲諷：「這就是我們現在的現實。」

他也提到，Kepler 將在演講當天登上 Gemini 4 的部落格文章，並有新款模型發布——這個細節把這場對談定位在發布期間，並未增添任何架構上的主張。

這些保證有其邊界，而 Ganesh 自己點了出來

Kepler 所宣稱的保證：模型引用數字而非自行寫出；每一筆引用都經過驗證；算術在運算層執行，而非模型層；租戶彼此隔離；召回率有被測量。他說，這並不代表一個能取代分析師的全規模對沖基金。他的結語框架是：AI 應該去做人們不想做的工作——從 S-1 裡挖出數字、把 PDF 資料搬進 Excel 儲存格，他說「這條街上的」分析師現在就在做這些事——而人類則保留發想的工作。

未解的張力正是他自己提出的：讓輸出值得信賴的那道過濾器，同時也讓產品在開放式探索上不那麼好用，而緩和這項取捨的修復機制，正是他不願多談的部分。引用修復能否規模化，而不重新引入過濾器本來要攔截的那些錯誤，是 Kepler 把 SEC 語料庫搬上 turbopuffer 時值得觀察的問題——他說兩家公司希望「很快」就能著手進行。