從簽約到上生產線 90 天:一個金融業 RAG 知識系統的交付時程實錄

先講結論,再回去看過程。

這個 RAG 上線時程案例,從簽約到系統掛在生產環境、法遵放行、第一線人員每天真的打開來用,總共 90 天。中間真正寫檢索與生成邏輯的時間，大概只佔三分之一。其餘的日子都花在一件事上：把「Demo 看起來會動」變成「合規部門敢簽字、業務願意用」。

客戶是一家中型金控的財富管理事業群。痛點很具體：理專回答客戶關於商品條款、費用結構、法規適用性的問題時，得翻十幾份 PDF、問三個部門，平均一題要 40 分鐘。他們要的不是聊天機器人，是一個能引用正確條款、附上出處、而且錯了要能被追查的知識系統。

第 1 到 2 週：資料盤點，也就是第一個卡點

我們沒有先寫程式。第一件事是把「知識到底住在哪裡」畫出來。

結果盤出來的東西比想像中亂。核心商品文件有 1,400 多份，散在三個系統：一個老舊的文件管理平台、一個共用磁碟機、還有一部分只存在資深理專的信箱裡。更麻煩的是版本問題——同一份商品說明書有 2022、2023、2024 三個版本同時流通，沒有人能一眼分辨哪份是現行有效。

這裡我們踩了一個雷，老實講。一開始想用 OCR 全量掃進去就好，跑了兩天才發現，有將近 15% 的文件是掃描檔加浮水印，OCR 出來的條款數字會錯位。金融文件裡一個數字錯位，就是一次合規事故。所以我們退回來，先建了一套版本標記與人工抽查流程，把「哪份文件可以進 RAG」這件事本身變成一個可控的閘門。

資料乾不乾淨，決定了後面 60 天順不順。這一點沒有捷徑。

第 3 到 5 週：檢索管線與第一版可用系統

進到大家比較熟悉的部分。這三週我們做了切塊策略、embedding、向量庫、以及檢索加重排（re-ranking）的管線。

金融文件不能用固定字數切塊。一段條款切到一半，語意就斷了，檢索回來的內容會缺前提。我們改成依文件結構切——以條、款、附註為邊界，並且在每個 chunk 上掛 metadata：商品類別、文件版本、生效日期。這讓後面可以做「只檢索現行有效版本」的過濾，直接解掉第 1 週那個版本混亂的問題。

第 5 週結束時，我們有了第一版能問能答的系統。內部測下來，檢索命中率約 78%。聽起來還行，但對金融場景，這個數字離「能上線」還很遠。

第 6 到 8 週:準確率、幻覺控制與合規要的東西

這是整個專案最硬、也最容易被低估的階段。RAG 上線時程真正會延誤的地方，通常不在工程，在這裡。

法遵部門提了三個不可退讓的要求：每個回答必須附可點擊的原文出處；系統不確定時要明確說「查無」而不是硬掰；所有問答要留完整稽核軌跡。

為了把幻覺壓下去，我們做了三件事：在 prompt 層強制模型只能根據檢索到的內容作答、無來源就拒答；加一層答案與來源的一致性檢查，比對生成內容是否真的出現在引用段落裡；再對高風險問題類型（費用、保證收益、法規適用）設白名單，一律走人工複核。

下面是這階段前後的實際變化。

回應時間變慢了，我們接受。在金融場景，慢一秒換來的是可稽核與零幻覺，這個取捨划算。

第 9 到 11 週：法遵放行與試點

第 9 週把系統送進法遵與資安審查。這一關我們準備了資料流圖、留存政策、以及一份「模型會拒答哪些問題」的清單。因為前面幻覺率壓到 0.3%、出處到 99.4%，審查只來回兩輪就放行。前面的苦，這裡回收。

接著找了 12 位理專做兩週試點。第一週使用率只有 12%——不是系統不好，是人習慣問旁邊的資深同事，比開一個新工具快。我們的工程師直接坐到營業廳，看他們怎麼問、卡在哪，把問句預設、常見商品捷徑、以及一鍵複製出處這些細節補上去。第二週使用率爬到 41%。

第 12 到 13 週：正式上線與交接

第 90 天，系統正式掛上生產環境，開放給該事業群 140 位理專。上線一個月後，日活躍使用率穩定在 63%，單題平均處理時間從 40 分鐘降到 6 分鐘。

我們最在意的其實不是這些數字，是我們撤場後系統還能不能活。所以最後兩週的重點是交接：把 chunk 策略、prompt 規則、拒答白名單、以及「新文件如何進 RAG」的維運流程，全部寫成客戶內部團隊能自己跑的手冊，並陪跑了兩輪新文件上架。

回頭看，90 天裡真正在寫檢索邏輯的只有大概 25 天，其餘都在處理資料、合規、跟人的使用習慣。這也是我們一直說的：Demo 很美不算數，上線且有人天天在用才算數。我們做 RAG 交付，工程師是進場坐到現場、把系統扛到有人採用為止的，不是交一份跑得動的原型就走。