前言

昨天談了 Prompt 設計的原則，但即使規則寫得再完整，實際運行時仍然會遇到一些典型問題。今天整理生成階段最常見的三種狀況，以及對應的緩解方式。

問題一：即使有參考資料，模型仍然產生幻覺

這是最讓人困擾的狀況——明明 Prompt 已經要求「只根據參考資料回答」，模型卻還是加油添醋，補充了參考資料中沒有的細節。

常見原因：

• 檢索到的內容跟問題只是部分相關，模型為了「回答得完整」，用自己的知識補上缺的部分
• Prompt 中的限制規則不夠明確或不夠強硬

緩解方式：

規則加強版：
「如果參考資料只能回答問題的一部分，請只回答資料中有明確依據的部分，
並明確指出哪些部分缺乏資料佐證，不要用你自己的知識補充。」

也可以加入更嚴格的檢查機制：生成完答案後，再用一個獨立的 LLM 呼叫，檢查答案中的每個陳述是否真的能在參考資料中找到依據（這個技巧會在 Day 23-24 評估階段更深入討論）。

問題二：答非所問

模型的回答看起來很完整、很有條理，但沒有真正回答使用者的問題。

常見原因：

• 檢索到的內容本身就沒有真正回答到問題（檢索階段的問題，不是生成階段的問題）
• 問題包含多個子問題，模型只回答了其中一部分
• Prompt 中沒有要求模型「先確認自己是否回答了問題」

緩解方式：

• 先確認是不是檢索階段的問題（可以先人工檢查檢索結果是否真的相關）
• 在 Prompt 中要求模型檢查是否完整回答了問題的所有子問題：

「如果問題包含多個子問題，請確保每個子問題都有被回答到，
並在回答最後列出「本次回答涵蓋的子問題」與「未能回答的子問題」（如有）。」

問題三：引用來源錯誤或標註不一致

要求模型標註引用來源（如 [來源1]）雖然能提升可追溯性，但模型有時會標錯來源、或漏標。

常見原因：

• 模型在生成長答案時，容易搞混多筆參考資料的對應關係
• 參考資料本身如果內容重疊度高，模型難以精確區分該引用哪一筆

緩解方式：

• 給每筆參考資料一個清楚、不容易混淆的編號與清楚的分隔符號
• 生成完後，用程式邏輯做一次基本驗證：檢查回答中提到的來源編號是否確實存在於本次的檢索結果中

import re

def validate_citations(answer, num_sources):
    cited = set(int(n) for n in re.findall(r"\[來源(\d+)\]", answer))
    invalid = [c for c in cited if c < 1 or c > num_sources]
    return invalid  # 若有無效引用，代表生成內容可能有問題，應標記或重新生成

一個實用的除錯習慣：建立錯誤案例集

建議在開發過程中，把每次發現的「回答有問題」的案例都記錄下來，包含：

• 使用者問題
• 檢索到的內容
• 模型的錯誤回答
• 問題屬於檢索階段還是生成階段

這份案例集會在 Day 26（錯誤案例分析與迭代優化）發揮很大的作用——優化 RAG 系統很少是「一次到位」，而是透過不斷檢視真實錯誤案例，逐步找出根因並修正。

小結

生成階段的問題，很多時候根源其實在檢索階段（垃圾進、垃圾出），但也有一部分是 Prompt 設計與模型本身的限制造成的。透過加強規則、要求自我檢查、程式化驗證引用正確性，可以降低這些問題發生的機率。明天我們要開始討論如何用量化的方式評估整個 RAG 系統的表現。