[Day 30] RAG 打造真正能上線的智慧助理

從 AI 能回答到系統真正能上線

30 天前，我們從一個很基本的問題開始：

如果要打造一套真正能使用的 AI 智慧助理，除了串接 LLM API，還需要完成哪些工作

一開始，我們認識了 RAG 的核心概念，從文件切分、Embedding、Vector Database，到檢索文件並交由 LLM 產生回答

但當系統逐漸具備基本功能後，我們也發現，能夠回答問題只是起點

一套真正要交付給使用者的智慧助理，還必須考慮：

• 找到的文件是否正確、相關
• 回答是否有依據，能否提供引用
• 當文件更新時，知識庫能否同步更新
• 當使用者增加時，系統是否還能維持合理的效能
• 當 LLM API 失敗時，系統如何處理
• 如何掌握 Token 使用量、API 成本與錯誤率
• 如何確保使用者只能存取有權限的文件
• 如何測試、部署、回復版本並持續改善

這些問題讓我們逐漸理解，AI 應用開發不只是模型整合，而是包含資料處理、軟體工程、系統架構、品質驗證與維運管理的完整流程

今天是這個系列的最後一天

我們不再單獨介紹某一項技術，而是將前 29 天建立的能力整合成一套 RAG 智慧助理是否已具備上線條件

這裡要特別注意，文件匯入與線上問答是兩條不同的流程

文件匯入負責建立及更新知識庫，而線上問答則負責檢索與生成

兩者應透過明確的資料版本、索引狀態與更新策略串接，避免文件已更新，但線上系統仍使用舊的索引

此外，快取必須考慮使用者權限與知識庫版本，不能因為某個使用者曾經查詢過，就將相同的答案無條件提供給其他使用者

第一道門檻：RAG 回答品質是否可靠

RAG 系統最核心的問題，不是能不能產生文字，而是能否根據正確的資料回答問題

因此，上線前至少要確認四件事

Retrieval：是否找到正確的文件

檢查：

• Chunking 是否保留必要的語意資訊
• Embedding 是否適合目前的語言與文件類型
• Vector Search 與 Keyword Search 是否互補
• Reranking 是否改善排序結果
• Top-K 是否能兼顧召回率與上下文品質
• Metadata Filter 是否正確處理文件權限

可使用 Recall@K、Precision@K 與 Context Relevance 等指標評估

Generation：回答是否有依據

檢查：

• 回答是否受到檢索上下文支持
• 是否正確回應使用者問題
• 是否在資料不足時適當表示無法回答
• 是否提供正確的文件引用
• 是否會將不同文件中的衝突資訊錯誤地合併

可使用 Faithfulness、Answer Relevance 與 Citation Accuracy 等指標

Evaluation：是否建立可重複的測試流程

至少要準備一份具代表性的 Evaluation Dataset，涵蓋：

• 一般事實查詢
• 關鍵字與語意改寫
• 需要多份文件才能回答的問題
• 文件資訊不足的問題
• 文件內容互相衝突的問題
• Prompt Injection 與越權存取測試

每次修改 Prompt、Embedding Model、Chunking 或 Retrieval 參數後，都應重新執行測試

Quality Gate：是否達到上線門檻

可以依照產品需求設定品質門檻

這些數字是示範值，不是適用所有產品的通用標準

正式門檻應根據測試結果、使用情境與錯誤風險制定

尤其是安全性與關鍵案例，不應只看平均分數。即使整體 Faithfulness 很高，只要仍有嚴重的越權資料洩漏，就不應視為已經具備上線條件

第二道門檻：系統效能與容量是否足夠

品質達標之後，還需要確認系統能否在預期流量下穩定運作

不要只測試單一使用者的請求是否正常

這只是測試階段的示意，實際併發量應依產品的預期流量與環境資源調整

測試時也應確認：

• RAG API 是否出現瓶頸
• Vector Database 是否能承受查詢量
• Redis 連線是否充足
• LLM API 是否受到 Rate Limit 限制
• 重試機制是否放大請求量
• 快取是否有效降低重複查詢成本

增加 API，不代表整條 RAG Pipeline 都會同步擴展

若真正的瓶頸在 LLM API 或 Vector Database，就必須針對瓶頸設計改善方案

第三道門檻：監控、告警與故障復原是否完整

Production 系統不能只依賴使用者回報問題

至少要具備以下能力

Observability

• 收集請求延遲、錯誤率與資源使用狀況
• 使用 Request ID 或 Trace ID 串接一次請求的紀錄
• 區分 Retrieval、Reranking 與 LLM Generation 的耗時
• 避免在日誌中不必要地記錄敏感資料

Alerting

• API Error Rate 超過門檻時通知
• P95 Latency 持續異常時通知
• LLM Timeout Rate 異常時通知
• Token 用量或成本接近預算時通知
• 安全事件或異常存取發生時通知

Recovery

• 明確定義故障處理流程
• 規劃 LLM API 暫時失效時的降級策略
• 設定合理的 Timeout、Retry 與 Backoff
• 確認部署版本可以回復
• 定期驗證備份與復原流程

例如，當 LLM API 暫時失效時，系統可以回傳清楚的暫時性錯誤訊息，而不是無限等待或產生看似可信、實際上沒有依據的答案

對可靠性要求較高的系統，也可以依需求設計替代模型或其他降級機制，但必須重新驗證其品質、成本與安全性

第四道門檻：成本是否可控

AI 應用即使功能正常，也可能因為大量 Token、重複生成或不合理的重試而產生過高成本

上線前應先估算單次請求的成本，再評估預期流量下的整體支出

主要成本來源

• LLM Input Tokens
• LLM Output Tokens
• Embedding API 呼叫
• Vector Database 與儲存空間
• Application Compute
• Logging、Monitoring 與其他雲端服務

實際計價方式依供應商、模型與部署方式而異，因此應使用當下適用的價格與實際使用量進行估算

計算單次請求的估計成本

若模型依 Input Token 與 Output Token 分別計價

這個公式只涵蓋上述兩類 LLM Token 費用，不包含其他服務成本

快取與成本優化

可以透過以下方式降低重複支出：

• Embedding Cache
• Retrieval Cache
• LLM Response Cache
• 限制不必要的 Context 長度
• 控制 Top-K 與輸出 Token 上限
• 避免重複的 API 呼叫與無限制重試

不過，快取不能只追求高命中率

如果使用者權限、Prompt Version 或 Knowledge Base Version 發生變化，快取仍然必須確保不會回傳過期或越權的答案

第五道門檻：安全性是否落實

RAG 會接觸文件、使用者問題、模型上下文與可能的外部工具，因此必須從多個層面建立安全防護

特別需要強調的是：

RAG 的資料權限應該在檢索階段落實，而不是等模型產生回答後才檢查

一旦未授權的文件已經進入 LLM Context，就不能再單純依賴 Prompt 要求模型不要洩漏

同樣地，Agent 也不應直接執行模型提出的高風險操作。所有工具呼叫都必須經過應用程式的參數驗證與權限檢查

第六道門檻：部署、CI/CD 與版本管理

前面的功能即使都已完成，如果每次更新仍然需要人工手動操作，或沒有清楚的回復機制，仍然容易在正式環境發生問題

因此，Production RAG 應建立可重複的部署流程

實際優先級仍應根據影響範圍與風險評估決定

例如，若系統處理高度敏感的企業資料，權限驗證與資料保護應優先完成；若系統是面向大量使用者的公開服務，容量、濫用防護與成本控制也可能成為上線前的重要條件

上線不是把所有功能做完，而是確認已知風險在可接受的範圍內，並且具備持續監控與改善的能力

30 天之後：從完成專案走向持續改善

完成這個系列，不代表 RAG 系統的工程工作就此結束

真正進入 Production 後，系統仍然會遇到新的問題：

• 文件持續更新，知識庫如何保持一致
• 使用者的問題改變了，Evaluation Dataset 是否仍具代表性
• LLM 模型更新後，回答品質是否退步
• 流量成長後，現有架構是否還能承受
• 使用者回報的錯誤，如何轉化成新的測試案例
• 成本增加時，如何在效能、品質與支出之間取得平衡

這些問題需要透過持續改善的循環來處理

這個循環也是前面 30 天各項技術真正串接起來的地方

Evaluation 不只是測試分數，Observability 不只是儀表板，CI/CD 也不只是自動部署

它們共同構成一套可以持續發現問題、驗證改善效果，並降低版本更新風險的工程流程

今天學到什麼

回顧這 30 天，我們從 RAG 基礎一路走到 Production Readiness，逐步建立了以下能力：

1. 建立 RAG Pipeline： 從 Chunking、Embedding、Vector Search 到 LLM Generation 與文件引用
2. 改善回答品質： 透過 Hybrid Search、Reranking、Evaluation Dataset 與 Error Analysis，持續改善檢索與生成結果
3. 建立工程驗證流程： 透過 Experiment Tracking、Regression Test 與 Quality Gate，讓每次調整都有依據
4. 掌握 Production 狀態： 透過 Observability、Tracing、Alerting 與 Cost Tracking，追蹤效能、錯誤與支出
5. 建立可擴展架構： 透過 Load Testing、Caching、Scaling、Docker 與 Kubernetes，處理部署與容量問題
6. 確保系統可靠與安全： 透過 SLI、SLO、Error Budget、Authentication、Authorization 與 Prompt Injection 防護，降低實際使用風險

最後，我認為這個系列最重要的收穫，不是記住了多少工具或框架，而是建立一個完整的工程思維

系列總結：AI 不只會回答

30 天前，我們從 RAG 的基本概念開始，逐步探索如何將 LLM 與企業知識整合，讓 AI 能夠根據文件提供更有依據的回答

這一路上，我們不只討論模型與檢索，也深入到資料工程、軟體測試、系統監控、效能優化、部署自動化、可靠性與安全性

因為真正的 AI 應用，不會只存在於 Notebook 或 Demo 裡

它必須面對真實使用者、真實資料、真實流量與真實的失敗情境

模型可以持續進步，框架也會不斷更新，但能夠定義問題、設計驗證方法、建立安全邊界，以及持續改善系統的工程能力，才是讓 AI 從展示走向實際應用的關鍵

AI 不只會回答，更要能在真實場域中持續提供有依據、可衡量、可維運且值得信賴的服務

這就是這 30 天想完成的目標，也是打造真正能上線的智慧助理的起點

感謝一路閱讀與交流的每一位讀者

系列告一段落，但實作與改善不會停止

我們下個專案再見