最近我把一個公司官網（118 頁、中英日三語）做成了一個 AI 客服小助手：使用者問產品問題，系統從官網內容找出答案、用 AI 生成一段有根據、可標來源的回覆。
技術上這叫 RAG（檢索增強生成）。原理很像「開書考試」：AI 本身不用背公司資料，而是先翻到相關那幾頁（檢索），再照著回答（生成）。這也是它不亂編、能附出處的關鍵。
聽起來很順，但真正上線、用真實問題去問之後，我才學到最重要的一課：
做 AI 產品，最難的往往不是 AI，而是「資料的形狀」。
以下是我踩到的 5 個坑，每個都很有代表性。
初版很自然地只抽取網頁的文字，<img> 圖片整個被丟掉。對 AI 的知識庫來說，那些產品圖根本不存在。
解法：把圖片連同說明文字存進索引，回答時一起帶出縮圖。
初版把「檢索到的每一頁的圖」全倒出來，結果混入隔壁產品、甚至虛擬主機 logo。
解法：只顯示用型號或產品名稱確定對得上那一頁的圖；跨頁重複出現的圖判定為裝飾自動過濾。
檢索明明把正確內容排第一，AI 卻回「查無」，還簡繁夾雜。原因不是檢索、也不是提示詞，而是我用的小型模型能力不足。
解法：因為系統一開始就設計成「模型可在後台切換」，換上更強的模型後，品質立刻穩定。
官網明明有「AAP 4 Chip」這個產品，AI 卻查不到。原因很微妙：型號全是英文字母 → 被判成「英文問題」 → 系統只搜英文頁 → 但這型號只出現在中文頁 → 被自己的「同語言過濾」規則擋掉了。
解法：把過濾從「硬性排除」改成「軟性優先」——同語言優先，但跨語言若明顯更相關就採用。
電話、地址都查得到，唯獨 Email 沒有。因為初版為了乾淨，把每頁頁尾整段移除——而信箱剛好只放在頁尾和 mailto: 連結裡。
解法：在移除頁尾之前先把信箱撈出來。
很多人以為做 AI 就是「把資料丟給模型」。其實一套 RAG 系統有兩個完全不同的階段，搞清楚這兩段，就懂了整件事：
① 建立知識庫（離線做一次）：把公司所有資料整理成 AI 查得到的形狀，事先存好。
② 回答問題（每次提問即時）：使用者一問，先去知識庫翻出相關內容，再交給模型寫成答案。
圖裡藏著一個常被忽略的重點：整套系統其實用到「兩顆模型」。一顆在建立知識庫時把資料變成向量（Embedding 模型），一顆在回答時把找到的內容寫成人話（LLM 模型）。前面五個坑裡，坑 1、2、5 出在左邊（資料怎麼進去），坑 3、4 出在右邊（檢索與模型怎麼運作）。
「開書考試」這個比喻很好，但它容易讓人以為：反正答案都在書上，模型隨便一顆就行。這是我踩坑後最想更正的誤解——開書考試，你還是得看得懂書、會抓重點、會用人話把答案寫清楚，而這幾件事，全是 LLM 在做。
所以我後來把 RAG 的品質拆成一條很好記的式子：
是相乘，不是相加——任何一項太弱，結果就崩：
檢索對了、模型太弱 → 明明資料就排第一，AI 卻回「查無」、還簡繁夾雜（這正是坑 3）。
模型很強、檢索錯了 → 它會一本正經地、講得頭頭是道地……胡說。
認清這點之後，我做了一個現在看來最值得的架構決定：把模型做成「可插拔」的零件。我用一層模型代理（LiteLLM）把系統和「當下用哪顆模型」隔開，於是——
坑 3 當初就是靠這個設計救回來的：不是重寫程式、也不是狂調提示詞，只是把後台那顆小模型換成更強的一顆，答案品質立刻穩定。
結論：在 RAG 裡，檢索負責「找對資料」，模型負責「讀懂並好好回答」——它不是配角，是和檢索並列的另一半。而讓模型可以隨時被換掉，是我最推薦的一筆架構投資。
這些都不是隨機 bug，而是同一個道理：
AI 系統的行為，取決於資料的形狀。
初版為了處理「常見情況」做了合理的簡化（只抽文字、同語言過濾、砍頁尾），但真實資料的邊緣情況——藏在圖片、頁尾、mailto、單一語言頁裡的資訊——只有在真實使用中才會浮現。
所以我更相信：AI 產品要先上線、用真實問題快速迭代，而不是一開始就想把所有情況設計到完美。你的使用者，會用你想不到的方式問問題，而那正是最好的規格書。