Prompt Engineering & Prompt Optimization 之 Query Transformations

前言 / 為甚麼？

筆者前述寫了在構建 LLM 應用中不可或缺的 Guardrails 、RAG Evaluation 和 資料合成；(2025 年初) 看到不少文章開始梳理 RAG 的技術發展；於是也想更系統化地比較不同情境下該用哪些方法解決真實業務問題，因此整理這篇 Query 優化筆記

一方面當作練手，另一方面也讓日後設計 / 開發解決方案時，有一份可以回頭查的人肉 RAG XD

年紀大了還是要留點記錄好用來回溯…

本文架構

• 當 LLM 上下文大小接近無限大時、RAG 真的已死了嗎？
• Context window 越長 ≠ 效果越好
• 上下文越多，推論成本越高
• 檢索/優化查詢/記憶系統等技術的發展才是真正的未來趨勢
• RAG 技術回顧
• Query 優化的 7 種方法
• 評估方法：這次不只看 Prompt 好不好看，而是看它有沒有讓 RAG 變好
• 實驗設計與結果
• 結尾

當 LLM 上下文大小接近無限大時、RAG 真的已死了嗎？

誠如 RAG Paper 《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》作者群中畢業於 Stanford、曾任職 Facebook AI Research、HuggingFace、現任 Contextual.ai 的 CEO Douwe Kiela 在最近發表的 RAG is dead, long live RAG! 中提到 — —

Every few months, the AI world experiences a similar pattern. 
A new model drops with a larger context window, and social media 
lights up with declarations that “RAG is dead.”
But these pronouncements—whether for a context window breakthrough, 
a fine-tuning advancement, or the emergence of Model Context Protocol (MCP)
misunderstand RAG’s purpose and why it will always have a role in AI.

“每隔幾個月，AI 界就會經歷類似的循環。一款具有更大上下文窗口的新模型推出，
社群媒體便會熱烈討論 “RAG 已死”。但這些聲明 —— 無論是為了突破上下文窗口、
微調的進步，或是為了推出 Model Context Protocol（MCP）—— 
都誤解了 RAG 的本質以及它在 AI 中的角色。

" RAG 今天又死了一次"

在每次 LLM 有更長的 Context Window 或是 Memory Tool 出現時大部份不明所以的吃瓜群眾、或是利用著誇張標題吸人眼球博取流量的通俗媒體寫下一個 「RAG 已死、你需要的是 xxxx」的標題

大概是因為嗜血和 (企圖)顛覆常識的文字總是讓人無法度按捺（？）但 RAG 死不死總對不是媒體 / KOL / 賣課的人嘴秋出一兩篇文章就能幫它壽終正寢的

你說筆者為何胸有成竹？用大雄的話是這樣說的 — — 「你不懂胖虎！」

開玩笑完了，現在聽我娓娓道來。

Context window 越長 ≠ 效果越好

這時候或許有人會跳出來說「明明現在上下文窗口 Context Window 已經這麼長了、為甚麼我們還需要用 RAG 啊？」

Understanding the Impact of Increasing LLM Context Windows — Meibel

有這樣的想法是很直覺的；但我們要思考的是「到底現在過長的上下文會導致什麼樣的問題」

筆者這邊有兩個方向的引用：

第一，過長的上下文可能會對於模型生成的成效有影響

第二點，對於模型生成的成本也會有影響

長上下文未必能改善模型表現，反而可能導致注意力分散、訊息稀釋 (論文)

(去除極端值) 平均下降了 65 %、極端下降了 92%

模型本身對於資訊的處理能力仍有上限，過多的資訊可能降低準確率 (論文)

當使用完整文本時，所有模型的準確率都顯著下降

看到這裡讀者也可能會說「這些都是上一個世代的模型，可能在新一代模型會比較好？」

不能說你這樣的理解有問題，但最大的成本會是硬體—— 顯卡 (GPU)

上下文越多，推論成本越高

商用 LLM API（如 OpenAI、Anthropic）多以 Input / Output 加起來的總 token 數為單位計費，context 越長意味成本越高

另外你可能也會說，用本地的模型不就好了嗎？以 LLama-3.3–70B-Q8 為例，它的 context windows 上限是 128K：

• 在 1024 的 Input 時 vRAM 使用率是 73.96 GB
• 32k 的 Input 時 vRAM 使用率是 137.79GB
• 128k 的 Input 時 vRAM 使用率是 326.94 GB

足足上升了 4.x 倍的 vRAM 使用量

計算方式可以參考 APX VRAM calculator

若為了提升回答品質而一味擴增 context，不但效益不一定提升，還會導致開銷暴增，降低實務上應用可行性 — — 而且還會被成本中心的同仁打電話問候、當然你老闆也會在月會週會對你提出疑問

最要命的是當今天你有跑長上下文的需求的時候、所需要的顯卡也會指數級地開始往上。

以 70B 的模型而言，你可能只需要一張 96GB 的顯卡；但當你硬要把長上下文塞到模式裡面的時候，你需要的就會變成四張 96GB 的顯卡

最後就會變成 NVIDIA 成為最後的贏家 (誤)

最後只有黃老闆獲得勝利 (Reference)

檢索/優化查詢/記憶系統等技術的發展才是真正的未來趨勢

• 優化的檢索策略（如：父子檢索、擴展檢索）讓 1M + context window 發揮更大效益
• RAG 的發展從來沒有停滯，而是持續演進，像是衍生出多階段檢索(Multi stage Retrieval )、多模態索引(Multimodal indexing)、GraphRAG、HM-RAG 等新技術
• Long context windows 讓檢索資訊涵蓋更廣的範圍，但「內容選擇」仍需靠檢索機制來把關，用來提升模型回覆的精準度和在成本-效能上抓個平衡

另外，在本文寫成的 2026 年 6 月的時候，有更多的壓縮方法的出現，讓長文本的成本稍微有變低（詳見：LLMingua-2, TurboQuant & ZipServ）

但不能說有了壓縮技術，長文本就是無限制的，因為還要回歸到成效問題，勢必要用其他方法來解決這件事——結論是 RAG 從來都沒有死、隨著不同技術的成熟，變得更接近 Infrastructure 或是 Common Technology 的定位

"不要相信非此即彼的錯誤觀念"

RAG 技術回顧

回顧一下 RAG 到底解決了甚麼問題？

• 無法存取私有（內部企業）資料：模型是基於公開資料訓練，但經常需要持續變化和擴展的專有資訊
• 過時的參數知識：即使頻繁更新模型，訓練截止日期與當前日期之間仍然存在差距
• 幻覺問題：模型常常會捏造聽起來合理但不正確的資訊。RAG 透過將回應建立在真實來源上並提供引用，讓用戶可以驗證資訊，來解決這些問題

甚麼情況下適用 RAG / 不要使用 RAG

Gen By GPT-Image 2

RAG 的種類

《Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks》

《Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks》 雖然是一篇 2024 年的論文，但它有非常良好的 insight 和 系統性地把不同的 RAG 技術進行歸納，所以以下用到的一些名詞或是概念都是以這篇論文引申或變化而來

Naïve RAG：基礎檢索增強生成

1. 處理文件：透過收集文件、將其轉換為文字格式並清除不相關的雜訊，為知識庫準備資料
2. 載入資料：建立並填充知識庫的內容
3. 檢索資料：建立一個工具，能根據使用者的查詢找出並回傳相關資料，通常是在向量資料庫中進行語意搜尋
4. 產生回答：利用檢索到的資料來強化使用者的提示詞，將其傳送給 LLM，並產生最終答案

Advanced RAG：檢索前後的進階優化

為甚麼這裡先談 Advanced RAG，而不是直接談 Modular RAG？我的理解是：Advanced RAG 比較像工程優化的基礎層，Modular RAG 則是把這些優化拆成可組合、可替換、可治理的模組

也因此本文先聚焦在檢索前後的進階優化，說清楚 Query Transformation 在工程上解決什麼問題，而不是展開 Modular RAG 的完整分類

而本系列會以 Advanced RAG 作為主要探討的議題，範圍如下：

前處理(Pre-Retrieval)

• Query 處理相關技術：透過重寫 (re-write)、擴充 (expand)、拆解 / 生成多重提問 (multi & child query)、假設性改寫 (HyDE)、後退一步思考 (Step-back) 來優化 Query 的品質；這也是本文要探討的重點
• 文本切分技術(Text splitting)

檢索階段(Retrieval)

• 檢索方法優化 (Retrieval Optimization)
• 檢索後處理 (Post-Retrieval Processing)

生成後（Post-Generation Rewriting）

• 答案重寫（Answer Rewriting）
• 風格重寫（Style Transfer）
• 事實校驗（Fact-Checking）

本文著重探討前處理(Pre-processing)中和 Query 優化 (Query Transformation)相關的內容

優化方法

接下來的優化說明，會以下面這個任務作為對象：

請撰寫一篇短文,探討人工智慧對社會和個人生活可能產生的影響和挑戰。
文章需涵蓋人工智慧的利弊、對就業市場的影響、隱私和安全議題、法律和倫理規範的必要性等層面,
並提出一些因應之道和建議。

查詢重寫（Query Rewrite）

優化使用者的原始查詢語句，使其更符合檢索系統的特性或補充完整的論述與背景讓模型生成更精準的內容

例如：將「我想找關於貓咪的照片」轉換為「feline photo image cat kitten」或「我想找一些高解析度的貓咪照片，包括不同品種、姿勢和背景的圖片，並希望這些照片能用於寵物相關的網站或個人收藏。」

system_prompt = (
"你是一個專業的查詢優化助手。請將以下原始查詢重寫得更詳細，" \
"回應必須使用正體中文，且僅輸出重寫後的查詢內容。"
)

user_prompt = (
"以下是原始查詢，請根據查詢意圖提供更完整、具體的改寫。"\
"\n\n原始查詢：" + query +
"\n\n輸出格式要求：\n- 不得包含任何說明、標題或多餘文字。\n- 需維持句子結構且語意通順。\n"
)
"""
### 優化結果
請撰寫一篇內容詳盡的短文，全面探討人工智慧在當代社會與個人生活中可能帶來的各種影響與挑戰。
文章內容應包括以下幾個層面：首先，分析人工智慧的主要優點，
例如提升效率、促進創新，以及改善生活品質；同時也要討論其潛在的缺點與風險，
例如可能導致失業、技術依賴或偏見問題。其次，深入探討人工智慧對就業市場的影響，
包括哪些行業可能受到正面或負面影響，並提出相關的因應策略，例如再教育與技能轉型。
再次，闡述人工智慧在個人隱私與資訊安全方面的挑戰，強調數據保護的重要性與可能的風險。
接著，討論法律與倫理規範的建立必要性，說明制定相關政策與標準的重要性，
以確保人工智慧的負責任使用。最後，提出一些具體的因應之道與建議，包括政府、
企業與個人應共同努力的措施，以促進人工智慧的健康發展，並最大化其社會與個人層面的正面效益，
同時有效降低潛在的負面影響。
"""

查詢擴充（Expand Query）

為原始查詢添加相關詞彙，包含同義詞、相關概念等，以提升檢索範圍。舉例來說，查詢「台北101」可能會擴充為「台北101 信義商圈 觀景台 景觀餐廳」；適合用在 RAG System 時快速找到除了與查詢相似度高以外有關聯性的資訊

system_prompt = (
"你是一個專業的查詢擴充助手，會為查詢提供同義詞、相關概念與上下位詞。"
)
user_prompt = (
"請針對以下查詢提供 5 個擴充詞彙。輸出格式必須為 JSON 陣列，元素類型需為字串，"
"且不可包含註解或其他文字。\n\n原始查詢：" + query
)

"""
### 優化結果
人工智慧的應用
社會變革
倫理與法律
就業轉型
隱私保護
"""

多重查詢（Multi Query）

將單一複雜查詢拆解成多個較簡單的子查詢，分別進行檢索後整合上下再輸入到 LLM 中進行生成。比方說「台灣的夜市文化與小吃特色」可以拆分為「台灣夜市分布」和「台灣特色小吃種類」；適合於 RAG 或 Deep Research 等情景中

system_prompt = (
    "你是一個查詢拆解助手，將複雜問題拆解為 2-5 個語意獨立的子查詢。"
)
user_prompt = (
    "請根據以下查詢，輸出 2 到 5 個子查詢，格式為 JSON 陣列 (Array of strings)。"\
    "每個子查詢需完整描述欲檢索的資訊要點，避免重複。\n\n原始查詢：" + query
)

"""
### 優化結果
探討人工智慧在社會和個人生活中的潛在影響，包括正面和負面效果。
分析人工智慧對就業市場的影響，包括可能的就業機會與失業風險。
討論人工智慧引發的隱私和安全議題，以及相關的挑戰與風險。
說明法律和倫理規範在人工智慧應用中的必要性，並提出相關的規範建議。
提出因應人工智慧帶來的挑戰的策略與建議，以促進其正面發展並降低負面影響。
"""

進階版：COT Driven Multi Query

核心的概念是透過推理模型先進行 reasoning 的過程，接著使用每一個 step 裡面分解成多個 query 來作為檢索的輸入，最後再聚合成資料給模型進行回覆生成

來自阿里巴巴淘實團隊的分享

子查詢（Child-Query）

根據主要查詢自動產生相關的延伸查詢，形成查詢樹狀結構。例如查詢「登山準備」會衍生出「登山裝備」、「登山安全須知」等子查詢：

system_prompt = (
"你是一個子查詢生成器，會根據主查詢建立層級化的子查詢樹。"
)
user_prompt = (
"請針對以下主查詢產生 3-6 個第一層子查詢，必要時再為每個子查詢提供 1-3 個次子查詢。"\
"輸出格式必須為 JSON 物件：{\"children\":[{\"query\":str,\"subqueries\":[str,...]}...]}."\
"所有字串需為正體中文。若沒有次子查詢，subqueries 請使用空陣列。"\
"\n\n主查詢：" + query
)

"""
### 優化結果
探討人工智慧的利弊
人工智慧的優點有哪些？
人工智慧的缺點和潛在風險是什麼？
分析人工智慧對就業市場的影響
人工智慧如何改變傳統就業結構？
哪些行業受到人工智慧的影響最大？
面對就業變動，應該採取哪些因應措施？
討論隱私和安全議題
人工智慧在資料收集與使用上的隱私問題是什麼？
如何保障個人資料安全？
探討法律和倫理規範的必要性
現行法律對人工智慧的規範有哪些不足？
建立人工智慧倫理準則的重要性？
提出因應之道和建議
政府、企業和個人應如何因應人工智慧的挑戰？
未來人工智慧發展的建議方向？
展望人工智慧對社會和個人生活的長遠影響
"""

假設性示範查詢（HyDE Query）

讓模型生成可能的相關文本範例，再用這些範例進行檢索，特別適合處理抽象或概念性的查詢需求

system_prompt = (
"""角色設定：你是「HyDE 假設性內容生成器」。你的任務是根據使用者查詢，產生 3–5 段可供檢索的「假設性但合理」內容片段，用於向量檢索與語義搜尋。要求：
- 以中立、百科式語氣撰寫，避免不可驗證的精確數字或來源斷言。
- 每段 80–160 字為原則，聚焦關鍵實體、專有名詞、同義詞/縮寫/別名。
- 片段之間需語義去重，涵蓋不同面向（定義/機制/優缺點/案例/比較/時間線/常見誤區等）。
- 優先保留查詢中的關鍵實體與限制條件（時間、地點、產業、框架、法規等）。
- 僅產生可檢索內容，不輸出最終答案或觀點結論。
- 所有輸出須使用正體中文。
    """
)

user_prompt = (
"""
請依下列規則回覆：
1. 只輸出 JSON 陣列，每個元素為一段字串，不得包含註解或多餘文字。
2. 每段 80–160 字；避免流水帳，聚焦可檢索的關鍵訊息與專有名詞。
3. 涵蓋多元面向，並加入合理的同義詞、縮寫、別名（例：GDPR/一般資料保護規則）。
4. 若原查詢過於抽象，請先假設合理情境後再生成片段，但避免杜撰來源或精確數字。
5. 片段內容彼此去重（不同角度/場景/任務/技術/法規/案例）。
6. 另外輸出一個鍵 "optimized_query"（字串），摘要查詢核心與限制條件；
其餘仍是 passages 陣列。
原始查詢："""
) + query


"""
### 優化結果
探討人工智慧對社會與個人生活的影響與挑戰，涵蓋利弊、就業、隱私、安全、法律與倫理規範，
並提出因應策略，限制在2023年前後的技術與法規背景。
"""

後退一步思考（Step-back Prompting）

SBP 是來自 2023 年 Google DeepMind 的論文，其方法是希望使用 LLM 先針對原始查詢生成一個更高層次 (更抽象而不是具體)的問題後利於模型進行推理(Reasoning)；而用於 Prompt Engineering 中更傾向用於生成更泛化、通用的查詢來進行檢索，避免因為問題問得太具體、但檢索對象裡並不存在與問題有高度相似性的資料塊 (data chunk)，導致後續檢索成效不佳造成「GIGO」的情況；

實驗結果顯示，Step-Back Prompting 能夠在 MMLU 、TimeQA、多跳推理等任務上，對 PaLM-2L 都帶來 7%～27% 不等的性能提升

其原理是：

論文原理圖

這一次，筆者透過參考論文原理概念，把相對應的 Step 1 和 Step 2 的方式變成 Prompt 來進行實驗，Prompt 如下

system_prompt = "你是一個專精於 Step-Back Prompting 的查詢優化助手。
你的任務不是回答原始問題，而是幫助重寫問題，讓後續模型更容易基於高層概念回答它。
\n\n流程分兩步：\n\n### 
Step 1: Abstraction（抽象化）

\n- 生成一個更高層的 Step-Back Question，以概括原問題的核心概念或原理。
\n- 根據該問題，提供一段 Step-Back Answer（高層背景或理論）。\n\n### 
Step 2: Rewrite（基於抽象的重寫）

\n- 根據 Step-Back Answer，將原始問題改寫成一個更具語義結構、範圍明確、
且能引導模型聚焦核心議題的新查詢（Optimized Query）。
\n\n最終輸出格式：\n```\n### Step 1: Abstraction\nStepback Question: ...\n
Stepback Answer: ...\n\n### 
Step 2: Rewrite\nOptimized Query: ...（這是新的查詢，不是答案）\n```"

user_prompt = f"請使用 Step-Back Prompting 方法來重寫以下問題，讓它更具抽象性、
結構清晰、並聚焦於關鍵議題。注意要保持和原問題的同樣動機和意圖。\n\n原問題：{query}"

"""
### Step 1: Abstraction
Stepback Question: 如何全面分析一項具有廣泛社會影響的技術創新，並提出應對策略？
Stepback Answer: 在討論一項新興技術的影響時，應該考慮其對社會結構、個人生活、經濟、
法律和倫理層面的潛在影響，並提出相應的政策或措施來管理其風險與促進其正面效益。

### Step 2: Rewrite
Optimized Query: 請撰寫一篇短文，從社會、經濟、法律和倫理角度，
全面分析一項具有廣泛影響的技術創新（如人工智慧）可能帶來的挑戰與機遇，
並提出相應的因應策略與建議。
"""

提示壓縮 (Prompt Compress)

原理是使用 SLM 來完成對於內文多餘的 Token 進行處理，常用的模型為微軟開源的 LMLingua-2，也整合到主流的 RAG Framework 裡；原理透過一個 fine tuning 的 SLM (LMLungua) 進行資料蒸餾 — — 讀者有看過 DeepSeek R1 的論文想切對於這個概念不陌生，DeepSeek 是利用「教師模型-蒸餾知識-學生模型-學習」方式來增加模型對於知識的學習

而在這裡資料蒸餾概念也類似、透過壓縮無關的內容，在保留忠實性 (faithfulness) 的前題下縮短 Prompt 的長度，進而減少 Token Cost 和進入 LLM 時所佔 K-V Cache 的成本；成果同時有在 ACL 2024 中發表 <Paper>

簡單來說，就是蒸餾一個專門用於 Prompt Compressor 的模型

from llmlingua import PromptCompressor

llm_lingua = PromptCompressor(
    model_name="microsoft/llmlingua-2-xlm-roberta-large-meetingbank",
    use_llmlingua2=True, # Whether to use llmlingua-2
)
compressed_prompt = llm_lingua.compress_prompt(prompt, rate=0.33, force_tokens = ['\n', '?'])
## Or use LLMLingua-2-small model
llm_lingua = PromptCompressor(
    model_name="microsoft/llmlingua-2-bert-base-multilingual-cased-meetingbank",
    use_llmlingua2=True, # Whether to use llmlingua-2
)
"""
{'compressed_prompt': '撰文人工智慧利弊就業市場響隱私安全法律倫理規範因應建議', 
'compressed_prompt_list': ['撰 文 人 工 智 慧 利 弊 就 業 市 場 響 隱 私 
安 全 法 律 倫 理 規 範 因 應 建 議'], 

'origin_tokens': 130, 'compressed_tokens': 66, 'ratio': '2.0x', 
'rate': '50.8%', 'saving': ', Saving $0.0 in GPT-4.'}
"""

{
 'compressed_prompt': '', // 壓縮後的 Prompt
 'origin_tokens': , // 原來 Prompt 的 Token 數目
 'compressed_tokens': 211, // 壓縮的 Token 數目
 'ratio': '11.2x', // 壓縮比例
 'saving': ''Saving $0.1 in GPT-4.' // 以 GPT-4 而言省了多少錢
}

現在可能大家都使用通用的模型來進行壓縮；像是在 OpenAI 的 Codex Compaction 中，就是利用非常複雜的原理，讓對話接近 Context Window 的極限的時候，就會把整個對話的內容變成下一輪的上下文

網路上有人把這功能進行了逆向工程，實在是太強了…

評估方法：這次不只看 Prompt 好不好看，而是看它有沒有讓 RAG 變好

Prompt Optimization 最容易掉進一個陷阱：我們看著改寫後的 Query，覺得它變完整、變漂亮、變像一個「專業問題」，於是就直覺認為它比較好

但 RAG 系統不是在考作文、Query Transformation 真正要回答的是幾個更實務的問題：

• 改寫後的 Query 有沒有保留原始問題的意圖？
• 它有沒有讓檢索系統更容易找到正確文件？
• 生成答案時，它有沒有提高答案被 retrieved contexts 支撐的程度？
• 這個改善值不值得多出來的 latency、token cost 和工程複雜度？

所以這次筆者沒有只停在方法介紹，而是把前面提到的 query rewrite、expand、multi query、child query、HyDE、step-back 都接進同一個 E2E pipeline 裡跑一次

這不算大型 benchmark，比較像一個可重現的小型實驗：用 20 筆問答 case 放在 100 筆無所關的文件中，觀察不同 query transformation 在相同資料與評估標準下的取捨

本次實驗實際使用的 Prompt

下面是這次實驗實際放進 pipeline 的 prompt：

Query Rewrite

system_prompt = (
    "你是一個專業的查詢優化助手。請將以下原始查詢重寫得更詳細，"
    "回應必須使用正體中文，且僅輸出重寫後的查詢內容。"
)

user_prompt = (
    "TRANSFORM_METHOD: rewrite\n"
    "以下是原始查詢，請根據查詢意圖提供更完整、具體的改寫。\n\n"
    f"原始查詢：{query}\n\n"
    "輸出格式要求：\n"
    "- 不得包含任何說明、標題或多餘文字。\n"
    "- 需維持句子結構且語意通順。\n"
    "- 需保留原始查詢中的時間、地點、人物、組織、事件與限制條件。"
)

Expand Query

system_prompt = "你是一個專業的查詢擴充助手，會為查詢提供同義詞、相關概念與上下位詞。"

user_prompt = (
    "TRANSFORM_METHOD: expand\n"
    "請針對以下查詢提供 5 個擴充詞彙或短語。"
    "輸出格式必須為 JSON 陣列，元素類型需為字串，且不可包含註解或其他文字。\n\n"
    f"原始查詢：{query}"
)

Multi Query

system_prompt = "你是一個查詢拆解助手，將複雜問題拆解為 2-5 個語意獨立的子查詢。"

user_prompt = (
    "TRANSFORM_METHOD: multi_query\n"
    "請根據以下查詢，輸出 2 到 5 個子查詢，格式為 JSON 陣列 (Array of strings)。"
    "每個子查詢需完整描述欲檢索的資訊要點，避免重複。\n\n"
    f"原始查詢：{query}"
)

Child Query

system_prompt = "你是一個子查詢生成器，會根據主查詢建立層級化的子查詢樹。"

user_prompt = (
    "TRANSFORM_METHOD: child_query\n"
    "請針對以下主查詢產生 3-6 個第一層子查詢，必要時再為每個子查詢提供 1-3 個次子查詢。"
    "輸出格式必須為 JSON 物件："
    "{\"children\":[{\"query\":str,\"subqueries\":[str,...]}]}。"
    "所有字串需為正體中文。若沒有次子查詢，subqueries 請使用空陣列。\n\n"
    f"主查詢：{query}"
)

HyDE

system_prompt = (
    "角色設定：你是「HyDE 假設性內容生成器」。你的任務是根據使用者查詢，"
    "產生 3-5 段可供檢索的「假設性但合理」內容片段，用於向量檢索與語義搜尋。\n"
    "要求：\n"
    "- 以中立、百科式語氣撰寫，避免不可驗證的精確數字或來源斷言。\n"
    "- 每段 80-160 字為原則，聚焦關鍵實體、專有名詞、同義詞、縮寫與別名。\n"
    "- 片段之間需語義去重，涵蓋不同面向。\n"
    "- 優先保留查詢中的關鍵實體與限制條件。\n"
    "- 僅產生可檢索內容，不輸出最終答案或觀點結論。\n"
    "- 所有輸出須使用正體中文。"
)

user_prompt = (
    "TRANSFORM_METHOD: hyde\n"
    "請依下列規則回覆：\n"
    "1. 只輸出 JSON 物件，不得包含註解或多餘文字。\n"
    "2. JSON 格式必須為 {\"optimized_query\": str, \"passages\": [str, ...]}。\n"
    "3. passages 請提供 3-5 段，每段 80-160 字；避免流水帳，聚焦可檢索的關鍵訊息與專有名詞。\n"
    "4. 涵蓋多元面向，並加入合理的同義詞、縮寫、別名。\n"
    "5. 若原查詢過於抽象，請先假設合理情境後再生成片段，但避免杜撰來源或精確數字。\n"
    "6. 片段內容彼此去重。\n\n"
    f"原始查詢：{query}"
)

Step-Back Prompting

system_prompt = (
    "你是一個專精於 Step-Back Prompting 的查詢優化助手。你的任務不是回答原始問題，"
    "而是幫助重寫問題，讓後續模型更容易基於高層概念回答它。\n\n"
    "流程分兩步：\n\n"
    "### Step 1: Abstraction（抽象化）\n"
    "- 生成一個更高層的 Step-Back Question，以概括原問題的核心概念或原理。\n"
    "- 根據該問題，提供一段 Step-Back Answer（高層背景或理論）。\n\n"
    "### Step 2: Rewrite（基於抽象的重寫）\n"
    "- 根據 Step-Back Answer，將原始問題改寫成一個更具語義結構、範圍明確、"
    "且能引導模型聚焦核心議題的新查詢（Optimized Query）。"
)

user_prompt = (
    "TRANSFORM_METHOD: step_back\n"
    "請使用 Step-Back Prompting 方法來重寫以下問題，讓它更具抽象性、結構清晰、"
    "並聚焦於關鍵議題。注意要保持和原問題的同樣動機和意圖。\n\n"
    f"原問題：{query}"
)

實驗背景：模型、資料集與環境

這次實驗的目的並不是要證明某一個 provider 一定比較好，而是想回答一個更工程化的問題：在同一批資料、同一組 query transformation 方法，以及同一個 retrieval pipeline 之下，不同模型與方法在品質、成本與 latency 之間，會形成什麼樣的交互關係

換句話說，我關心的不是單點模型排名，而是當 query optimization 被放進真實 RAG pipeline 之後，它對整體系統造成的影響。尤其在企業場景中，模型品質固然重要，但 latency、成本、可維運性與 pipeline 複雜度，往往同樣會影響一個方法是否真的能被採用

本次實驗使用的是 CRUD-RAG compact dataset，包含 20 筆中文問答 cases，另外加入 100 筆 distractors 作為文件；Retrieval 的部分使用 FAISS (Facebook AI Similarity Search) 作為 Vector Search Library，Embedding Model 則使用本地 OMLX OpenAI-compatible endpoint，模型為 Qwen3-Embedding-0.6B-4bit-DWQ

這次比較的 transform / generate 模型，原則上盡量選用 lightweight LLM。原因很直接：query optimization 位在使用者輸入後的第一個步驟，它會直接影響後續的整體 latency

如果 query 被改寫得更長，模型推論時間通常也會增加；如果某個方法會把單一 query 展開成多個 query，則不只會拉高檢索次數，也會增加 RRF merge 成本與整體 pipeline 複雜度。因此，在這類任務中，模型是否「適用」有時比模型是否「最強」更重要

本次實驗比較的模型與 provider 如下：

• OpenAI： gpt-4.1-nano-2025-04-14
• Gemini：gemini-3.1-flash-lite
• OpenRouter： qwen/qwen-2.5-7b-instruct
• NVIDIA NIM：meta/llama-4-maverick-17b-128e-instruct

Judge 模型使用：OpenAI 的 gpt-5-mini-2025-08-07

指標設計

LLM As A Judge 會分為兩種：一種是針對 Query Judge，針對輸入的文字經過了 Query Transformation 之後的評估；另外一種是針對 Query Transformation 之後，用於 Retrieval 以及 Answering 的結果進行 Judge：

Query Judge：

你是一個嚴格、穩定的 RAG Query Transformation 評估員。 
你的工作是比較原始查詢與優化後查詢，判斷 query transformation 是否保留原始意圖，
並是否讓查詢更清晰、更適合檢索。

評分規則：
- 所有分數只能是 1, 2, 3, 4, 5 的整數。
- intent_preservation_score 評估是否保留原始查詢的核心任務、實體、條件、時間、地點與限制。
- clarity_enhancement_score 評估優化後查詢是否更明確、無歧義、具體，且更適合檢索系統找到相關文件。
- 不要因為查詢變長就自動給高分；如果新增資訊改變原意，intent 必須降分。
- 回覆必須是單一 JSON object，不得輸出 Markdown、註解或其他文字。

Retrieval / Answer Support Judge：

你是一個嚴格、穩定的 RAG Retrieval / Answer Support 評估員。
你會看到原始問題、參考答案、baseline 檢索結果，以及 candidate 方法的檢索結果。
你的工作不是判斷文字是否好看，而是判斷 candidate 檢索結果是否比 baseline 
更可能支持正確回答。

評分規則：
- answer_preference_score 評估 candidate retrieved contexts 相對 
baseline 是否更能回答原始問題。
- faithfulness_score 評估 candidate retrieved contexts 是否足以支持 
reference_answer；若 contexts 缺少答案依據，必須低分。
- 如果 candidate 和 baseline 幾乎等價，winner 使用 "tie"。
- 只根據提供的 contexts 評估，不使用外部知識。
- 回覆必須是單一 JSON object，不得輸出 Markdown、註解或其他文字。

這裡有一個小坑。第一版只在 prompt 裡要求模型輸出 JSON，結果全量跑下來只有 108 / 560 筆 Judge 成功；後來改用 OpenAI structured output JSON schema、加上 checkpoint 與 --retry-failed 後，成功率才提高到 554 / 560。這件事對筆者來說比模型分數本身更有提醒：如果你的 evaluation pipeline 依賴 LLM-as-a-Judge，就不能只相信 prompt 約束，必須讓輸出格式在 API 層被約束。

(現在 OpenAI 和 Gemini 都有 structured output；vLLM 也支援 choice、regex、json、grammar、structural_tag 等輸出規範)

Reddit 上看到別人發的 Meme XDDD

實驗流程

實驗結果

Query Transformation 方法層比較

這個結果有點反直覺，但也很符合工程現場常見的情況：複雜方法不是一定比較好

rewrite 的 answer preference 只比 baseline 高 0.005，但它保留了很高的 intent / clarity，而且 query count 沒增加；而child_query 的 answer preference 最高，但平均 query count 來到 10.84，latency 也高。

以這次資料來看，如果要選一個先上線測試的 query transformation，筆者會先選 rewrite，不是因為它分數最高，而是它風險和成本最低。

相對 baseline 的差異

如果只看 answer preference，前幾名看起來都有進步。但把 latency 和 query count 放回來，故事就變得比較誠實：這次 dataset 上的 improvement 很薄，複雜方法的成本增加反而比較明顯。

模型層比較

這裡不適合過度解讀成「哪個模型一定最好」；四個 provider 的 answer preference 平均差距其實很小，從 0.594 到 0.613。比較有參考價值的是：gemini 在這次實驗的品質、latency、parse_ok 之間比較平衡；nvidia 的 faithfulness 高，但 latency 也高 (但免錢就不要那麼多要求了…)

Takeaways

這次實驗最值得帶走的不是「某個 query transformation 方法屌打其他方法」，而是幾個比較務實的觀察：

第一、當 baseline retrieval 已經很強時，query transformation 的收益會被壓縮

這次 recall@5 幾乎都接近 1.0，代表 retrieval 已經很容易命中 gold docs；在這種情況下，multi-query、HyDE、step-back 不一定能創造更多價值，反而會增加 query count、latency 和 parse 風險

第二、rewrite 是最值得先試的低風險方法

它不需要增加 retrieval query 數量，也不會像 step-back 那樣把問題抽象化到偏離原意；如果要在 production RAG 裡先加一個 query optimization layer，筆者會從 rewrite 開始，而不是直接上 multi-query 或 HyDE

第三，LLM-as-a-Judge 可以省下不少人工標註與評分成本

但在法遵、醫療、反洗錢、製程等高度依賴領域知識的場景，仍然需要兩層校準：

1. 讓 SME / 專家參與評分規則設計，避免 judge prompt 只學到表面語氣，卻沒有對齊領域判斷標準
2. 保留 Human-as-a-Judge 抽樣校準。在完成第一版 LLM-as-a-Judge 後，挑出一批樣本讓 SME / 專家共同評分，再比較人類評分與模型評分的差異，回頭修正 judge prompt、criteria 與評分流程

像在淘寶團隊在 RAG Feedback 上的標註也會分成很多不同的維度，方便然後在優化的時候可以更具體、更細緻

第四、這次結果提醒我們：Query Transformation 不是越複雜越好

真正要問的是：

1. 你的資料集是否真的需要更複雜的查詢策略？
2. 你的 retrieval 是否還有改善空間？
3. 多出來的 latency 和 token cost 是否能換到足夠的答案品質？

如果這三個問題答不出來，複雜方法很可能只是把 pipeline 做得更花哨、但對於實際業務情景沒甚麼幫助～

主管問我為甚麼 RAG 成效還是沒調好…窩不知道…

小結

Query Transformation 不是越複雜越好。當 baseline retrieval 已經很強時，簡單 rewrite 往往比 multi-query、HyDE、step-back 更划算；真正重要的是把 evaluation pipeline 做穩，尤其是 LLM-as-a-Judge 必須使用 structured output

這也是筆者現在對 RAG 優化比較保守的看法：不要急著堆技術名詞，先把問題拆清楚，再用 evaluation 去證明每一層優化真的值得存在。

若 baseline retrieval 已經足夠強，第一步通常不是加上更複雜的 transformation，而是先驗證一個低成本 rewrite 是否真的帶來可觀改善

實驗的結果跟方法，我都把它上傳到 GitHub 上面了，所以大家可以自由取用來復現～

[embed]GitHub - NeroHin/rag-practise: A practical guide to Retrieval-Augmented Generation (RAG), featuring… A practical guide to Retrieval-Augmented Generation (RAG), featuring query expansion and rewrite techniques…github.com

結尾 MurMur 與總結

本文從 2 月一路拖到現在才完成（謎之語：這段落是 6 月下旬看表演時敲下的，然後 9 月的我又來簽到，來到 10 月又補了一輪；完稿時間在 2026 年中…只能說拖延不太好啊哈哈哈哈…）

2025 年被不少人預告是 Agentic AI 元年，但走到現在，我仍覺得 Agentic AI 多數時候還停留在能 coding、能當 researcher 的階段；距離真正取代具備領域業務判斷的員工，還有很長一段路

哪怕現在已經迭代到 Agentic RAG…但資料和 Domian 還是 RAG 的最大敵人

但也是因為有了這些沉澱以及靜待新技術的過程，才會讓人意識到什麼是真正迫切的問題，可能不是 LLM 在 benchmark 上又多跑出幾分畢竟在真實工作裡，你我每天遇到的任務很少只是單一輸入、單一輸出；難點通常卡在各行各業的基礎設施（資料源、存取權限、知識庫）、接口（MCP、A2A、RESTful API），以及模型在反覆 reasoning-planning-action-review 的流程裡，是否仍能對齊一開始的任務目標——上述都是困難到不行的問題 QAQ

這也是筆者寫下本篇文章的動機之一：模型能力和 prompt 調整都有邊界。GIGO 的問題不會因為 context window 變大或 query transformation 變多就自動消失；比較可靠的做法，仍然是根據業務性質，一步一步優化開發者能掌握的環節，並用 evaluation 證明每一層優化值得存在。

這也許是在不追捧喧嘩報導與實驗性論文時，仍然可以安心研究和落地的方向！

• 謝謝您看到這裡，如果文章對您有幫助可以幫我拍個手！
• 也歡迎找我交流你的心得和想法～
• LinkedIn: https://www.linkedin.com/in/nerouch/
• GitHub: https://github.com/NeroHin

Reference

1. Three Paradigms of Retrieval-Augmented Generation (RAG) for LLMs
2. 最全梳理：一文搞懂 RAG 技術的 5 種範式！
3. 從 30%到 90%準確率: 企業級 RAG 落地實踐
4. LlamaIndex介紹
5. Ilya Rice: How I Won the Enterprise RAG Challenge
6. Contextual Compression: LangChain | LlamaIndex
7. RAG 技巧与底层代码剖析
8. https://github.com/FareedKhan-dev/all-rag-techniques
9. https://github.com/NirDiamant/RAG_Techniques
10. 【LLM 论文】Step-Back Prompting：先解决更高层次的问题来提高 LLM 推理能力
11. 5 Chunking Techniques for Retrieval-Augmented Generation (RAG)
12. 情境工程（Context Engineering）解析：打造實用 AI Agent 的關鍵技巧，與提示工程（Prompt Engineering）有什麼不同？
13. Generative AI Design Patterns: Lessons from the Enterprise
14. 深度理解：提示词工程