4.1 生成器（LLM）在 RAG 中的作用

檢索器負責把資料找出來，生成器（generator） 負責把答案寫出來。生成器就是 LLM，但它在 RAG 裡的工作，和平常直接問 ChatGPT 之類的聊天不太一樣。

角色的轉變

	一般的 LLM 問答	RAG 裡的 LLM
依據	訓練時學到的記憶	提示詞裡提供的參考資料
主要工作	回想、推論、創作	閱讀理解、整理、改寫
資料不夠時	常常自己補上去，也就是幻覺	應該說「資料中沒有提到」

換句話說，RAG 裡的模型比較像一個很會讀資料、很會寫摘要的助理，而不是一個憑記憶回答的專家。

生成器要做的事

1. 理解問題

看懂使用者真正想問什麼，包括口語、省略、指代不明的問法。

2. 閱讀參考資料

從檢索到的幾段內容裡，找出和問題有關的部分。檢索回來的資料不一定都有用，其中可能混著不太相關的段落。

3. 整合並回答

把可能分散在好幾段的資訊，整合成一個通順、直接回應問題的答案，而不是把原文照抄一遍。

4. 守住界線

這是最重要的一點：只根據資料回答。資料裡沒有的，要誠實說不知道，而不是用自己的記憶補上去。這個行為不是自動會有的，要靠提示詞來要求（4.2）。

5. 標出處

說明每個重點是根據哪一段資料，方便使用者查證（4.6）。

為什麼模型還是會出錯

就算資料給對了，生成階段仍然可能出問題：

• 忽略資料：模型太相信自己的記憶，沒照著資料回答。
• 誤讀資料：把「不得」讀成「得」，或搞混不同條件。
• 混合記憶和資料：資料裡只有一半的答案，模型偷偷用記憶補另一半，使用者看不出哪些是資料、哪些是模型加的。
• 被雜訊干擾：塞進了不相關的段落，模型跟著離題。
• 資料互相矛盾：兩份文件寫得不一樣（例如新舊版本），模型不知道要信哪個。

這些都是第 6 章評估「生成品質」時要檢查的項目。

選擇生成模型要考慮什麼

• 遵循指示的能力：能不能乖乖照著「只根據資料回答」「標出處」這類規則做。
• 上下文視窗的長度：決定一次能放多少資料（4.4）。
• 對語言的掌握：處理中文資料，要確認模型的中文品質。
• 成本與速度：RAG 的提示詞比一般問答長很多，每次都要付這些輸入的費用。
• 資料保密：敏感資料送到外部的 API，還是用自己架設的模型。

在 RAG 裡，模型不一定要最強、最貴。因為知識來自資料，不是模型的記憶，所以閱讀理解和遵循指示夠好的模型，通常就能勝任。

生成端要處理的事

接下來會依序講：

1. 提示詞怎麼設計（4.2）
2. 資料怎麼放進提示詞（4.3）
3. 放不下怎麼辦（4.4）
4. 模型怎麼產出答案（4.5）
5. 怎麼標出處（4.6）