摘要： Cohere 在 2026 年 10 月 29 日發表一篇教學文章，示範如何用自家的 Embed、Rerank、Parse 模型搭配 Amazon SageMaker AI 與 Amazon Bedrock 上的 Claude，建一個能回答財報問題、且每句主張都附頁級引用的研究助理。對產品團隊來說，重點不只是架構本身，而是它把檢索品質、延遲與成本之間的取捨攤開來講清楚了。
為什麼財務研究特別難自動化
Cohere 的起點很實際：分析師整天的工作，其實是從數百頁的申報文件裡找出一個數字，然後證明它來自哪裡。難處在於這個數字通常不在正文，而是藏在表格、腳註或圖表裡。PDF 轉純文字後，表格的行列關係會消失、多欄版面可能錯序、圖表直接不見。
另一個硬性要求是可驗證。分析師不能在報告裡寫「CET1 比率是 11.9%」卻不註明出自哪份文件的哪一頁、是表格還是圖表。助理給的答案必須讓讀者能快速核對來源。
一個模型一個任務的四段式架構
整個方案用了四個模型，各司其職：Embed 把每頁文件和每個問題轉成向量；Rerank 把候選頁面重新排序，搭配 Context Focus 還能標出每頁真正回答問題的段落；Parse 專門處理掃描頁和表格密集的頁面，輸出保留表格結構的 Markdown；最後由 Claude 寫出答案，並為每個主張標註出處——引用不只給頁碼，還會說明證據是表格、圖表、正文還是腳註，點一下就能打開原頁圖像核對。
底層跑在 AWS 上：Cohere 模型以 SageMaker AI 即時端點部署，向量索引用 Amazon OpenSearch Serverless，其餘 web app、登入、API 和擷取管線都是 serverless 服務。
最值得抄的三個設計決策
索引和查詢用不同等級的模型。 Cohere 用 Embed Pro 做離線索引（每頁只嵌一次，可以選最準的），查詢時用 Embed Fast（每天上千次、要快要省）。兩者共享同一個向量空間，所以 Fast 嵌的問題能直接和 Pro 嵌的頁面比對。這個「一次性花錢買品質、每次查詢買速度」的拆法，很適合任何檢索型產品參考。
向量維度和格式要早點定案。 他們選了 1,024 維 int8——每個向量約 1 KB，一百萬頁約 1 GB，比起 2,048 維 float32 省 8 倍。文章提醒：日後改維度或格式，等於要把整個索引重新嵌入一次。
文字拿來搜尋，圖像留給回答。 因為財報多數是文字品質不錯的數位文件，嵌入時用頁面文字；文字遺漏的圖表細節，則在回答階段讓 Claude 看頁面圖像補回來。如果你的文件多是掃描件或簡報，Cohere 的建議反過來：嵌圖像或兩者融合。
跨語言和其他取捨
Embed 支援超過 100 語言且共用一個向量空間，法文提問可以直接命中英文的 Bank of America 頁面，省掉翻譯步驟，也避免譯錯術語把搜尋帶偏。另外 Rerank 和 Parse 都做成可開關的選配階段，只在有幫助的地方付費。
這套「引用到頁、還標明證據類型」的做法，和先前寫過的 Claude 進軍金融服務的一站式方案 是同一個方向：受監管產業的 AI 產品，賣點不是答案多流暢，而是答案能不能被查核。Cohere 這篇的價值在於它連「為什麼這樣選、什麼情況該換」都寫了出來，還提供 CloudFormation 範本讓你部署到自己的 AWS 帳號實測——有興趣的話，直接跑一次 demo，比讀十篇架構文更有感覺。