先分類錯誤，不要先選技術
當 AI 把產品代號、部門縮寫或內部流程名稱解釋錯誤，團隊常直覺認為模型「不懂公司」，因此考慮微調。但企業術語問題通常包含不同根因：系統可能沒有取得正確文件、檢索找到了相似卻不適用的段落、文件本身互相矛盾，或模型雖然讀到資料，仍沒有依照指定格式與規則回答。這些問題需要不同處理方式。
第一步應建立可重現的錯誤集。每筆至少保留使用者問題、預期答案、有效來源、實際檢索結果與模型回答，再把錯誤分為「沒有找到」、「找到錯誤內容」、「找到但理解錯誤」、「內容正確但表達不合規」。如果沒有這層分類，微調可能只是把檢索缺陷藏起來，而調整向量資料庫也可能無法修正模型的輸出行為。
還要分清楚術語是知識還是行為。某料號代表哪個產品、某縮寫目前指哪個部門，屬於可變動的知識；看到某種工單時要套用哪套判斷流程、答案必須依照固定欄位輸出，則較接近穩定行為。前者通常優先強化檢索，後者才可能適合微調。
術語會更新、答案要有來源時，先強化檢索
若術語來自產品目錄、ERP 欄位、SOP、合約版本或部門維護的詞彙表，檢索增強生成通常是較安全的起點。資料可在來源更新後重新索引，不必重新訓練模型；回答也能附上文件名稱、版本與段落，方便使用者驗證。對需要權限隔離的企業系統，檢索層還能在送入模型前依使用者身分過濾內容。
不過，將文件切片後放進向量資料庫並不等於完成 RAG。企業代碼通常很短，語意向量未必能穩定處理精確字串；同一縮寫也可能在採購、財務與維運部門代表不同意思。實作時通常要把關鍵字搜尋、向量搜尋、metadata 過濾與重新排序組合起來，並保留文件的上下文結構。
- 建立術語實體：為正式名稱、別名、舊稱、產品代碼與所屬部門建立明確欄位，不要只把它們埋在長篇文件中。
- 採用混合搜尋：精確代碼優先走關鍵字或欄位比對，自然語言問題再使用向量召回，最後以重新排序模型挑選內容。
- 加入版本與權限：以生效日期、文件狀態、組織與存取角色過濾，避免模型引用過期或無權查看的定義。
- 允許拒答：找不到足夠證據或來源互相衝突時，系統應指出缺口，而不是依語言流暢度猜測。
需要穩定行為，而非記住最新名詞時，才考慮微調
微調較適合教模型遵循反覆出現且相對穩定的模式，例如把客服敘述分類到企業既有的問題類別、依固定欄位產生維修摘要、套用內部語氣，或在多個可能流程中選擇正確的處理方式。它能降低長提示詞的負擔，並使格式與決策模式更一致，但不適合作為經常變動的企業百科全書。
若把產品名稱、價格、組織架構或最新 SOP 直接訓練進模型，日後更新會變得困難。模型也無法可靠指出某個答案究竟來自哪一版資料，刪除或修正單一知識更不容易。微調資料還必須經過去識別化、權限審查與品質清理；如果範例本身互相矛盾，模型只會更穩定地重現矛盾。
- 適合微調：穩定分類標籤、固定輸出結構、專業寫作習慣、可由大量一致範例示範的判斷模式。
- 不適合只靠微調：經常更新的名詞定義、即時庫存、客戶專屬資料、需要逐句引用來源的答案。
- 先檢查基準：若改善提示詞、提供少量範例或增加結構化輸出即可達標，通常沒有必要立即承擔微調的資料與維運成本。
多數企業系統需要的是分工，而不是二選一
實務上，較穩健的架構常讓檢索負責「現在有哪些有效事實」，讓模型或微調版本負責「如何解讀與呈現這些事實」。例如，檢索層先取得特定設備代碼的現行定義、維修規範與適用廠區；模型再依企業指定格式整理風險、步驟與待確認事項。如此一來，知識更新不需要重新訓練，行為一致性也能獨立優化。
選擇時可依四個條件判斷：知識更新頻率、是否需要引用來源、答案是否受使用者權限影響，以及問題主要是內容正確性還是輸出行為。只要前三項任一項重要，通常都應保留檢索或即時系統查詢；只有當來源已正確送入、模型仍持續無法遵循穩定規則時，微調的價值才會明顯。
- 檢索優先：資料常更新、必須可追溯、不同角色看到不同內容。
- 微調優先：知識已提供，但分類、格式或決策習慣長期不穩定。
- 混合方案：術語本身會變動，同時又需要高度一致的分析流程與回答格式。
用可診斷的評測決定下一步
上線前的評測不應只有「答案看起來對不對」。測試集要涵蓋正式名稱、別名、錯字、跨部門同名詞、過期版本、無權限內容、找不到答案與來源衝突。指標也要拆開觀察：正確文件是否被召回、重新排序是否選對段落、最終答案是否忠於來源、引用是否有效，以及格式與拒答行為是否符合規則。
建議先建立不含微調的基準版本，依序改善資料治理、查詢改寫、混合搜尋、metadata 過濾與提示詞。若檢索證據已穩定正確，但輸出仍在相同類型的行為上反覆失敗，再以經審核的範例進行小範圍微調，並與原始基準做回歸測試。這樣能知道改善究竟來自哪一層，也能避免模型更新後破壞原本正常的能力。
真正可維運的企業 AI，不是把所有知識塞進模型，而是讓資料來源、權限、檢索、模型行為與評測各自可替換、可追蹤。若內部系統分散在 LINE、ERP、CRM 與雲端平台，整合團隊的價值也在於把這些責任邊界設計清楚，而不只是更換模型。