幻覺（hallucination）是 LLM 生成了聽起來合理、但實際不正確或無依據的內容。它不是 bug，是語言模型的基本特性：模型的訓練目標是生成高概率的下一個 token，而不是「說真話」。在 Agentic SaaS 裡，幻覺的影響從令人尷尬（錯誤的建議）到造成業務損失（觸發了基於錯誤判斷的自動化操作）不等。
幻覺的主要成因
訓練資料截止與知識缺口：模型只知道訓練截止日前的事，之後發生的事它只能推測或瞎猜。知識截止在 Agentic SaaS 裡是常見問題，特別是需要即時資訊（股價、法規最新版、產品更新）的場景。
高置信度輸出低概率事實：模型對「聽起來對」的答案（高頻、符合語言模式）會有更高輸出概率，即使那個答案在事實上是錯的。名稱、數字、日期、引用來源是幻覺的高發區域。
Long-tail knowledge 的稀疏性：訓練資料中罕見的特定知識（小眾法律條文、特定版本的 API、小公司的產品規格）在訓練資料中出現稀少，模型在這些域的可靠性顯著低於高頻知識。
In-context 矛盾：當 prompt 裡不同段落提供矛盾的資訊，模型可能任意選擇一方，或者「融合」出一個兩者都沒說的答案。
降低幻覺的工程手段
RAG Grounding 多項 2025 年研究彙整顯示，適當實作的 RAG 可以把幻覺率降低最多 71%。機制：提供模型可以引用的具體文件，引導它根據這些文件回答，而不是從訓練記憶推理。
重要限制：「71%」是多個 benchmark 的彙整，各 benchmark 任務類型差異極大。在「有明確文件可查的事實性問題」上降低幻覺效果佳；在「需要綜合推理、文件裡找不到直接答案」的問題上，RAG 效果有限，模型仍然可能幻覺出推論過程。
Citation Enforcement（引用強制）
要求模型在每個主張後附上來源引用（[出處：文件名，第X段]）。Stanford 醫療 RAG 研究顯示，Citation-enforced prompting 的 StrictCitations 策略能達到最高的來源忠實度。
工程實作：在 system prompt 裡明確要求「每個事實主張必須附上你的依據來自哪個文件的哪個段落，如果你找不到依據請明說不知道」。同時在評估時驗證：citation 指向的段落是否真的支持該主張（這一步需要 LLM-as-judge 或人工抽查）。
Constrained Generation（約束生成） 對於輸出範疇有限的任務（分類、從有限選項中選一個、結構化資料抽取），用 Structured Outputs 限制模型只能從指定選項裡選，而不是自由生成。這把幻覺問題從「模型可以說任何事」縮小到「模型只能說這些選項裡的一個」。代價是降低了泛化能力。
Retrieval Verification 在把 retrieved chunks 傳給 LLM 之前，先用嵌入相似度或另一個 LLM 驗證這些 chunks 確實和問題相關。防止「檢索到了不相關的文件，LLM 強行用它回答」的情況。
Evals 框架
Evals（評估）是系統性量測 LLM 輸出品質的機制。在 Agentic SaaS 裡，evals 是上線前和持續監控的必備工具，而不是可選項——沒有 evals，你不知道模型更新或 prompt 修改有沒有讓系統變壞。
PromptFoo（官網） CI-native 設計：用 YAML 定義 test cases 和 assertions，整合 GitHub Actions 讓每次 PR 自動跑 evals。最適合「需要在 CI 裡把關 prompt 改動」的場景，不需要帳號，本地就能跑。
Braintrust（官網） 更全面的 pipeline：evals → production monitoring → human review → release control 整合在一個工作流裡。Braintrust 的幻覺偵測分析（2026）把它定位為「連接 evaluation 和 production monitoring 的最強整合平台」。適合需要持續追蹤 production 品質、有人工審核流程的團隊。
LLM-as-Judge 用另一個 LLM 評分目標 LLM 的輸出。常見格式：給評分 LLM 看問題、目標輸出、評分 rubric，讓它輸出 0-1 分和理由。Braintrust 和 PromptFoo 都支援這個模式。優點是可以評估主觀性強的輸出（回應語氣、答案完整性）；缺點是評分 LLM 本身也可能有偏見，評分結果需要人工校準。
Guardrails
Guardrails 是在 LLM 輸入輸出兩端設的防護層：
輸入端：
- 長度限制（防止 prompt injection 或超長輸入耗盡 context）
- 敏感資訊偵測（PII 遮蔽，防止敏感資料進入 LLM 的 log）
- 主題過濾（對於有特定用途的系統，過濾離題請求）
輸出端：
- Schema 驗證（已在結構化輸出與可靠性討論）
- 有害內容偵測（利用 Anthropic 或 OpenAI 的 moderation API，或開源的 Llama Guard）
- 事實 grounding 驗證（檢查回應是否能在 retrieved context 中找到依據）
何時不應該用 LLM
這是個常被跳過但很重要的問題。以下情境下強行用 LLM 通常弊大於利：
精確計算：LLM 的數學能力在大多數商業任務上已夠用，但在高精度財務計算、科學計算上不可靠。用 LLM 生成計算邏輯（程式碼），讓程式碼執行計算，比讓 LLM 直接算更可靠。
需要完全確定性的業務規則：合規判斷、醫療診斷、金融風控這類「必須正確且可解釋」的決策，LLM 的非確定性和幻覺風險不可接受。LLM 可以輔助（提供分析摘要），但最終決策邏輯應該在可審計的確定性系統裡。
有現成且可靠的確定性解法：如果一個任務可以用規則引擎、正則表達式、SQL 查詢精確完成，不需要 LLM 的泛化能力，加入 LLM 只增加成本、延遲和不確定性。
資料量極大的批次操作：LLM 的 token 費用和延遲讓它不適合做「掃描整個資料庫找某個模式」這類任務；應該用傳統 indexing 和搜索，LLM 只用在需要語意理解的局部操作上。
延伸
- RAG 架構的詳細設計 → RAG、記憶與知識庫
- Prompt injection 作為資安問題 → 限制、取捨與 Demo 不等於 Production
- 全景與閱讀路徑 → AI Agentic SaaS 專欄首頁