華爾街程序員把PDF丟給AI，3天后發現省了47%人工

凌晨兩點，某投行后臺的實習生還在手動核對一份47頁的經紀商對賬單。表格嵌套三層，數字和腳注混成一團，他第4次把行號搞串了。這種場景在金融圈不算新聞——直到有人把多模態AI（同時處理文字、圖像、表格的混合模型）接進了PDF流水線。

問題從來不是"讀不懂"，而是"讀不對"

光學字符識別（OCR，將掃描圖像轉為可編輯文字的技術）在金融文檔上栽了十幾年。多欄布局被壓成一串亂碼，表格邊框消失后數字集體"漂移"，配圖里的注釋直接蒸發。開發者拿到的常是一坨扁平化的純文本，后續分析根本無從談起。

大語言模型的多模態能力改變了游戲規則。LlamaParse這類平臺把傳統文字識別和視覺解析嫁接在一起，讓模型"看見"文檔的空間結構——哪里是標題，哪里是跨頁表格，哪塊是頁腳的小字注釋。

實測數據顯示，經過專門的數據預處理和閱讀指令調優，復雜表格的提取準確率比直接扔給模型處理高出13-15個百分點。這個數字背后，是無數份原本需要人工復核的報表。

經紀商對賬單：AI的"地獄級"考場

如果說普通發票是小學閱讀理解，經紀商對賬單就是金融領域的文言文考試。文件里塞滿嵌套表格、動態布局、專業術語縮寫，還要區分"市值"和"已實現盈虧"這類易混淆字段。

金融機構的實際需求很明確：讀文檔、抽表格、用模型解釋數據、輸出給客戶能看懂的風險提示。整個鏈條的容錯率極低——一個數字錯位，可能就是幾百萬的合規風險。

Gemini 3.1 Pro目前是這個場景的首選底座。它的上下文窗口足夠吞下整份年報，且原生支持空間布局理解。換句話說，模型知道"左上角的數字屬于哪個表格"，而不是把所有內容攪成一鍋粥。

關鍵設計在于"結構化輸入"而非"扁平化文本"。視覺分析疊加定向數據攝取，讓下游應用拿到的是帶層級關系的上下文，而非一串丟失格式的字符串。

雙模型架構：貴的事給貴的做，快的事給快的做

工程團隊在落地時面臨經典權衡：精度要Gemini 3.1 Pro，成本想壓到Gemini 3 Flash的水平。最終方案是把流水線拆成四段——

PDF提交給引擎；解析完成觸發事件；文字提取和表格提取并行跑；最后生成人類可讀的摘要。兩個提取步驟監聽同一事件，天然并發，延遲被壓到最低。

更細一層的分工是：復雜布局理解交給Gemini 3.1 Pro，最終摘要生成扔給Gemini 3 Flash。這種"雙模型"設計不是炫技，是算力賬算清楚后的務實選擇。

事件驅動的狀態管理讓架構自帶彈性。團隊后續加新的提取任務，只需多掛一個監聽器，不用重構主干流程。

接進生態只是第一步，喂什么數據才是命門

技術實現上，LlamaCloud和Google的GenAI SDK提供了現成的連接層。但再漂亮的管道，也依賴輸入數據的質量。垃圾進，垃圾出——這條定律在AI時代沒被推翻，只是換了個更快的處理器。

治理層面，金融場景的AI部署有額外紅線。模型會犯錯，且錯得自信滿滿。任何輸出在用于專業決策前，必須經過人工復核。這不是免責聲明，是運營者的實際責任。

那位凌晨兩點核對報表的實習生，現在收到的是AI預標注過的結構化數據。他只需要抽查標紅的高風險字段，而不是逐行死磕。省下的時間，夠他學會寫Prompt了。