選模型 + 怎麼切

先講為什麼這一步這麼關鍵。RAG 的最後一步是把撈到的段落交給 AI 生成,但如果你撈回來的本身就是爛料 —— 切得亂七八糟、或向量算不準 ——那後面的 AI 再聰明,也只能拿爛料硬湊一個答案。更麻煩的是,這一步是「建索引」時做的,做一次;一旦錯了,整個庫要重切、重算,成本很高。所以值得在這裡多花點心思。

這一步其實就是兩個決定。第一,用哪顆 embedding 模型,把文字算成向量。第二,你的文件要怎麼切成一段一段。這兩個決定會一起決定「撈得準不準」。我先講選模型,再講切塊,最後講一個大家最容易忽略、但會直接毀掉品質的坑。

先看這一步落在整個流程的哪裡。這張是 build 階段,也就是建索引。原始文件進來 —— 數位的直接用,掃描檔要先 OCR 轉成文字;接著切塊,把長文件切成一段一段;每段再用 embedding 模型算成向量;最後連同文字跟出處,一起存進向量庫。這一整條只做一次,而它做得好不好,就靠我接下來要講的兩個決定:選模型,跟怎麼切。

選 embedding 模型,第一個條件最基本、也最容易踩:語言。如果你的手冊是中文、或中英夾雜,你就必須選一顆「本來就支援中文」的模型。拿一顆只吃英文的模型去算中文,它算出來的向量是歪的,「溫度異常」跟「機器過熱」在它眼裡可能一點都不像,那 RAG 的語意檢索就整個失靈。所以第一步永遠先確認語言支援,再去比其他規格。

第二個條件,如果你的資料是內部的、不能出門,那模型必須能在你自己的機器上離線跑,不能是那種只能連雲端 API 的。還有一個鐵則:算文件的模型,跟之後算「問題」的模型,一定要是同一顆。因為每顆模型的座標系都不一樣,用 A 算文件、用 B 算問題,座標對不上,就等於亂找。也因為這樣,一旦換模型,整個庫都得用新模型重算 —— 換模型是大決策,不是隨手換。

第三,很多人一上來就想用最大最強的模型,這其實不一定對。模型越大,算得越慢、越吃資源,地端還可能跑不動。正確的順序是先問「這顆對我的文件夠不夠準」,夠了,再看它的速度、成本、能不能離線。常常一顆小一號、但跑得動又夠準的模型,才是最適合你的選擇。追規格之前,先想清楚你到底需要多少。

接下來講切塊,原則一句話:一段大約講一件事。切得太長,一段裡塞了五個主題,你撈回來一大坨不相關的,還把 prompt 塞爆。切得太短,一句話被攔腰切斷,撈回半句,AI 看不懂。剛剛好的粒度,是「這一段單獨拿出來讀,也能自己成立」——通常對應一個小節、一條操作程序、一個代碼的說明。

那到底照什麼切?最好的答案是:順著文件本來的結構。手冊如果有目錄、有清楚的章節標題,就照章節邊界切,一節一段,這最貼近人查手冊的習慣。如果文件沒有標題、就是一大片文字,那就退而用固定字數切,但要小心別剛好把一句話、一個表格切成兩半。總之,不要無腦地每 N 個字硬切,盡量順著結構走。

這裡有個大家最常忽略的坑:表格。手冊裡很多是表格,你如果把整張表當一段切下去,撈回來 AI 常常讀不懂哪格對哪格。正確做法是把表格「壓平」成一問一答。比如一張故障排除表,就把每一列拆成一小段:「症狀是這個,處置是那個」。保養表也一樣,每一列變成「這個項目,多久保養一次,做什麼」。壓平之後,每一段才撈得準、AI 才讀得懂。

還有一個小技巧:讓相鄰的兩段,重疊一小部分,英文叫 overlap。為什麼?因為有時候一個完整的意思,剛好跨在兩段的邊界上,你硬切下去,兩邊都只拿到半截。讓段跟段之間重疊幾十個字,那條邊界上的內容,兩段都涵蓋到,檢索時就不會因為切在錯的地方而漏掉答案。這是很便宜、但很有效的一招。

最後講一個會直接封死品質天花板的坑:掃描檔。很多舊手冊根本是掃描的圖片,不是可以複製的文字。這種你得先用 OCR 把圖片轉成文字,才有得切、才有得算向量。而 OCR 只要認錯字,後面就是切錯、算錯、撈錯,錯到底。所以如果你的來源有掃描檔,OCR 的準確度,就是你整個 RAG 品質的真正天花板 ——這一關沒顧好,後面再怎麼調都是白搭。

切塊的時候,還有一件順手但重要的事:記 metadata。每切出一段,就順便記下它來自哪份文件、哪一章、哪一頁。這樣最後生成答案時,才能標出處,讓使用者點回去看原文查證 ——這正是上一個主題講的「標出處」能成立的前提。而且這種東西現在不順手記,以後想補,就得把整個庫重切一遍,非常不划算。

這集帶走一句話:切塊跟選模型,是 build 階段做一次、卻決定整個 RAG 品質上限的兩件事。選模型,挑一顆懂你語言、能離線、而且夠用就好的;切塊,順著文件結構切、表格壓平成一問一答、段跟段留點重疊,還要順手記出處。最重要的:別一次就對整庫下手 ——先拿一小批真實文件切切看、問問看,確認撈得準了,再灌全庫。build 一次定生死,值得先驗證。