單純的 Retrieve → Read (Naive RAG) 架構在初期導入時，確實能快速看到成效，從使用者提問、系統檢索文件、到透過大型語言模型生成答案。整個流程直觀且容易上線。然而，隨著應用深入，很快就會發現失敗案例大多源於一個根本問題，就是使用者說的話太模糊、指令不清楚

例如，當使用者輸入幫我分析 AI 晶片最新發展時，模型可能只會給出教科書式的基礎知識，或是隨機拼貼幾個不完全相關的段落。這並非檢索器或 LLM 不夠強大，而是因為輸入的自然語言本質上不適合直接用於機器檢索

人類與機器的溝通方式

人類比較習慣用自然語言表達模糊、概括性的需求，但檢索器需要的是結構化、明確且可執行的查詢指令。為了解決這個問題，我們可以將流程向前延伸一步，加入了 Rewrite 環節 (原本只有 Retrieve → Read)

我們可以將 Rewrite 想成是 API Gateway 的請求預處理器，將使用者輸入的高自由度的人話，轉成後端檢索器、重排器和閱讀器都能夠穩定處理的標準化 payload

Naive RAG 的五個典型陷阱

如果你曾導入過 RAG 系統，以下這些問題想必不陌生。這些問題都共同指向一件事：查詢本身需要被精心設計。而 R3 框架正是將查詢設計這件事系統化。

1. 詞彙鴻溝：使用者說新能源車，但知識庫裡的文件可能使用的是 NEV、EV、BEV 或 PHEV ... 等專業術語。語意未能對應，導致檢索失敗
2. 模糊與歧義：使用者只輸入共同基金，系統無法判斷他到底想了解的是定義、費用、績效比較還是相關新聞
3. 過度具體：查詢中包含了日期、訂單 ID、特定版本號等細節。反而可能干擾嵌入模型的語意理解，使其忽略了核心概念
4. 多跳推理：一個簡單的提問背後，可能隱含了三到四個需要依次解答的子問題，使用單次檢索很難捕捉到完整的資訊鏈。
5. 遺失對話上下文：在多輪對話中，如果沒有將先前的對話內容有效整合進當前查詢，後續的問題就會變成一個個獨立的、缺乏上下文的無效句子