RAG CLI 的設計哲學：先把檢索、打包、驗證拆開，再讓模型上場

每次在終端機（terminal）串接 RAG 服務，最頭痛的不是模型寫不出通順的句子，而是回答裡那些真假難辨的幻覺（hallucination）。如果使用者來抱怨回答有錯，你卻不知道是哪一條資料檢索歪了、還是模型自己腦補，那就是資料管線的邊界沒切清楚。這也是為什麼，一個真正能上戰場的 RAG CLI，第一步往往是先把檢索、打包與驗證的邊界拆乾淨。

如果一開始就把檢索、生成、驗證混在同一個 API 打，後面維護一定會踩坑。反過來說，如果命令列工具（CLI）能把這三件事拆開，它通常就比較像一個真正可靠的系統，而不是一次性的 demo。

為什麼先做 CLI？

RAG 如果只包在一個 Web 聊天框介面裡，常常會遇到幾個黑盒問題：不知道資料是從哪個 endpoint 撈出來的、模型到底吃了哪些 context、引用有沒有對上，也不知道今天的結果下次能不能重現。

CLI 的好處是把這些步驟都變成具體的命令與輸出。你可以很直接地用腳本（script）去跑檢索，看撈出來的 raw data 長怎樣、打包出的 bundle 格式對不對、驗證有沒有通過。這種方式雖然沒有華麗的 UI，但對需要處理資料精準度、引用來源的工具來說，反而最穩健。

核心不是回答，而是證據

一個成熟的 RAG CLI，設計中心不該是「回答」，而是「證據」。它的首要任務不是生成漂亮段落，而是先確認相關資料有沒有被撈到、找到的資料是不是可引用、哪些內容可以打包進 context 給模型。

如果這個順序顛倒，模型就很容易開始「補洞」。補到最後，表面上像答案，實際上跟來源脫節。

我會把它拆成三層

1. 檢索層（Retrieval）

只做一件事：去資料庫或搜尋引擎撈資料。關鍵字搜尋、向量搜尋（vector search）、hybrid search 或 rerank 都行，但重點是把「可能有用的材料」撈出來。這層還要處理一個很現實的問題：資料有沒有過期？RAG 很常不是模型不行，而是索引沒更新、來源早就變了。

2. 打包層（Bundle）

這是很多人會忽略、但其實最重要的一步。Bundle 不是單純把結果列出來，而是把檢索到的材料整理成一份可以交給下游模型的 evidence package：query、citation id、source url、excerpt、allowed citations、schema version、timestamp 都要寫進去。這樣模型拿到的不是一個鬆散的搜尋結果清單，而是一個有邊界、可追溯的資料包（bundle）。

這裡我會特別強調 schema version。Bundle 一旦開始被別的服務接，就不能一直靠「人看得懂」維持，必須要能版本化、能回放、能比對。

3. 驗證層（Verify）

負責確認引用有沒有對上：citation 是否在 bundle 裡、有沒有引用 bundle 外的資料、來源 ID 有沒有錯、bundle 與答案是不是同一版資料。這層最好是用寫程式的方式（deterministic）去做規則檢查，不要再丟給另一個 LLM 去做。驗證一旦又丟回模型，整個系統就失去基準了。

這套哲學的幾個關鍵詞

• Retrieval-only：核心先不要做答案生成。只要先把檢索撈資料做好，就已經比很多直接聊天式工具穩。
• Bundle as contract：Bundle 不只是輸出格式，而是跟下游模型之間的合約。合約裡要寫清楚可以引用什麼、不能引用什麼、證據不足時要怎麼標示。
• Verify before generate：不是先生成再想辦法補證據，而是先把證據準備好，再讓模型根據證據寫答案。LLM 是工具的消費者，不是資料管線的中心；它負責整理與表達，不負責決定資料邊界。

可觀測性（observability）也要先規劃好。如果這東西要真的用在工作流裡，至少要能看到搜尋查了哪些來源、哪些命中被選進 bundle、驗證哪裡失敗。沒有這些，系統很快就會變成黑盒子。

要長期用，我會補這幾件事

Help 指令和範例一定要寫，讓人知道怎麼起手。Base URL、模型來源、索引版本、輸出格式最好都能設定。Health 檢查至少能確認服務活著沒、資料版本對不對，offline tests 則用固定樣本把檢索與驗證先測穩。

Error mode 要明確區分「沒結果」、「資料缺欄位」、「驗證失敗」、「服務掛了」這幾種情況，logs 至少要能回頭查一次完整流程，高風險領域則一定要保留人工確認的關卡。這些看起來很工程，但其實是 RAG CLI 能不能從 demo 變成工具的分水嶺。

適合哪些場景？

只要資料多、來源雜、需要引用、不能亂講、需要追溯重跑，這套設計都有價值。除了法律合規，財經研究的財報與法說會分析、客服知識庫的 FAQ 與工單、工程資安的 runbook 與 postmortem，甚至是公部門的開放資料，都非常適合套用。

我會直接把流程固定成九步：ingest 抓資料、normalize 統一格式與 metadata、chunk 切成可檢索單位、embed 建索引、retrieve 撈資料、pack bundle 輸出證據包、generate 讓模型只根據 bundle 寫答案、verify 做 citation 檢查，最後在需要合規的領域保留人工 review。

這樣拆完之後，整個系統就會像是可信賴的工具鏈，而不是一個把功能塞在一起的黑盒 AI 應用。我們只要守住這條邊界——資料邊界清楚、引用邊界清楚、檢索與生成分開、驗證可重複、失敗模式可辨識，系統就會非常耐用。