概念位置

Adaptive retrieval 位在 RAG 的控制流端。它跟 query rewriting 不同：rewriting 假設要 retrieve，只改查詢形狀；adaptive retrieval 先決定 retrieve 是否必要。

可觀察訊號與例子

「2+2 等於多少」不需要 retrieve；「公司退款政策第 4 條怎麼說」需要 retrieve。若使用者 query 一半是聊天、一半是 factual lookup，adaptive retrieval 可以明顯降低 retrieval cost。

設計責任

判斷器可以是規則、小模型、主模型 self-report 或 confidence signal。風險是模型過度自信而跳過檢索；高風險事實問答應偏向 retrieve 或提供 fallback。

概念位置

Context packing 位在 top-k retrieval 結果與 LLM prompt 之間。它跟 retrieval source 相鄰，因為來源 metadata 會影響引用；也跟 lost-in-the-middle 相鄰，因為 chunk 順序會影響模型注意力。

可觀察訊號與例子

常見 packing 決策包含 dedup 重複 chunk、把最相關內容放前後、按 document order 保留段落流、摘要或壓縮過長 chunks、在每段前加 source path 與 score。這些決策會改變答案品質、token cost 與可追溯性。

設計責任

設計 context packing 時要回答：哪些 chunk 真的要進 prompt、順序如何安排、是否保留來源、是否需要 summarization / compression。高追溯場景優先保留 source metadata；長 context 場景要避免把重要 chunk 放在中間；latency 敏感場景要限制 top-k 與 compression call。

概念位置

HyDE 三步：

 1User query
 2   ↓
 3[Step 1] LLM 生成 hypothetical document
 4         (可能 hallucinate、事實正確性不重要)
 5   ↓
 6[Step 2] Embed 假文件
 7   ↓
 8[Step 3] 用假文件 embedding 去 vector DB retrieve 真文件
 9   ↓
10真實 top-k chunks → 主 LLM 回答

為什麼比直接 embed query 好：假文件的 phrasing、長度、結構都更接近真文件的分佈、embedding 距離更可靠。重點是假文件當 embedding 的代理、不是當答案——hallucinate 出錯誤事實 OK、但語意 / 領域要落對。

設計責任

讀 RAG paper 或工具看到「HyDE」「hypothetical document」「query-side augmentation」就是這個機制。實作判讀：

1. 適用 phrasing 落差顯著的場景：問句 vs 陳述、口語 vs 正式、抽象 vs 技術詞彙。HyDE 原論文跨多領域都有提升、不限技術 / 學術。
2. 失效在假文件偏離主題：LLM hallucinate 到別領域、retrieve 拿到完全不相關的東西。緩解：生成多個假文件取平均 embedding、或用 query + 假文件兩個 embedding 合併 retrieve。
3. Cost：每 query 多一個 LLM call（生假文件）、latency 加 500ms-1s，屬於明顯的 retrieval cost。對 latency 敏感場景考慮 query rewriting 等較輕量的替代。
4. 跟 hybrid search 互補：HyDE 解語意 phrasing 落差、hybrid 解語意 / 字面互補、可以同時用。

完整 RAG 檢索增強技術 landscape 見 4.2 RAG 檢索增強。

概念位置

它是 RAG 與 agent loop 的交界：控制流比 vanilla RAG 複雜，但目標仍是補齊回答所需 context，而不是任意行動。

可觀察訊號與例子

多 hop 問題常需要 multi-step retrieval：先查 A 的屬性，再用該屬性查 B，最後比較。單次 retrieve 可能只抓到其中一邊，導致回答缺關鍵證據。

設計責任

Multi-step retrieval 只有在問題確實需要多 hop、latency budget 允許、且有停止條件時才划算。沒有 stop condition 時容易無限 retrieve；沒有資訊足夠性判斷時容易提高 retrieval cost 卻沒提升。

概念位置

Query decomposition 位在 RAG 的 query 端，跟 multi-step retrieval 相鄰但不相同。Decomposition 是先拆好 N 個子 query 平行 retrieve；multi-step retrieval 是 retrieve 後讀結果，再決定下一步要查什麼。

可觀察訊號與例子

「比較 A 與 B 在安全性和成本上的差異」可以拆成「A 的安全性」「B 的安全性」「A 的成本」「B 的成本」。每個子 query 都能獨立命中文件，最後再合成比較表。

設計責任

Query decomposition 適合子問題彼此獨立的複合問題。若後一個子 query 需要前一輪結果才能產生，改用 multi-step retrieval；若拆解後子 query 過多，要回到 retrieval cost 與 latency budget 評估。

概念位置

Query expansion 位在 RAG 的 query 端增強層。它會提高 retrieval cost，因為每個變體都要 retrieve；它也常跟 hybrid search 的 RRF 合併思路相鄰，用排名融合降低單一 query 變體失誤。

可觀察訊號與例子

使用者問「python deploy」時，系統可能擴成「Python application deployment」「Docker deploy Python service」「CI/CD for Python backend」。這能增加 coverage，但也可能把不同意圖混在一起。

設計責任

Query expansion 適合短 query、歧義 query、或同一問題有多種常見說法的場景。設計時要限制變體數量，保留 original query，並用 retrieval recall 驗證是否真的提高命中率；變體太發散時應改用澄清問題或 query rewriting。

概念位置

Query rewriting 位在 RAG pipeline 的 query 端，早於 embedding、hybrid search、reranker 與 context packing。它跟 HyDE 不同：rewriting 產生更好的查詢句，HyDE 產生假設文件再拿去 embed。

可觀察訊號與例子

使用者問「API 為什麼很慢」，rewriting 可能改成「API latency bottleneck, tail latency, database query optimization」。這能讓 retrieval 更容易命中正式文件中的用詞，但會增加 retrieval cost。

設計責任

改寫要保留原始意圖，避免把「診斷原因」改成「優化方案」這類偏移。實務上要保存 original query，retrieve 後再用原始 query 檢查結果是否對題。

概念位置

Query-document gap 位在 query 端與 embedding / search 端之間。它跟 hybrid search 的字面 vs 語意互補相關，也跟 query rewriting 與 HyDE 直接相鄰：前者改寫 query，後者生成假設文件來靠近 document 分佈。

可觀察訊號與例子

使用者問「API 為什麼很慢」，文件寫的是「tail latency、database query plan、connection pool saturation」。兩者意思相關，但 phrasing、抽象層級與術語不同，embedding 可能命中弱，BM25 可能完全漏掉。

設計責任

處理 query-document gap 時先判斷落差類型：同義詞、口語 vs 正式、問句 vs 陳述、跨語言、domain jargon 或識別碼。輕量修法是 query rewriting；形態落差明顯時可用 HyDE；精確 keyword 與語意都重要時用 hybrid search；仍然 top-k 不準時再加 reranker。

概念位置

Retrieval cost 橫跨 query 端、retrieval 端、context 組裝端與控制流端。它跟 TTFT 有關，但不只是一個延遲數字：query rewriting 多一次 LLM call，query expansion 多次 retrieve，reranker 多一段 cross-encoder 計算，retrieved chunks 進 prompt 會增加 token cost。

可觀察訊號與例子

常見訊號是「accuracy 有提升，但 p95 latency 變差」「每個 query 都 retrieve，聊天問題也燒 embedding / vector DB」「multi-step retrieval 連跑三輪，答案只比 single-step 好一點」。這時問題在於收益是否大於成本，而非技術能不能做。

設計責任

判斷 retrieval cost 要把 accuracy、latency、token budget、服務費用與維運複雜度一起看。低風險聊天可用 adaptive retrieval 降低不必要檢索；高價值問答可接受 reranker 或 multi-step retrieval 的額外成本；即時補完則通常偏向 single-step、cache 或較小 top-k。

概念位置

Retrieval recall 位在 retrieval component eval 層。它跟 reranker 相鄰，因為 reranker 常用來提升 top-k 的排序品質；也跟 query-document gap 相鄰，因為 gap 太大會讓 expected doc 不進 top-k。

可觀察訊號與例子

一組 eval query 事先標出 expected chunk。若 expected chunk 出現在 top-5，記為 hit@5；一百題中 82 題命中，hit_rate@5 是 82%。若 retrieval recall 高但答案錯，問題多半在 generation 或 context packing；若 retrieval recall 低，先修 chunking、embedding、hybrid search 或 query 端增強。

設計責任

設計 retrieval recall eval 時要保存 query、expected source、top-k 結果、score 與失敗分類。不要只看 end-to-end answer correctness；否則 retrieval miss 會被 LLM hallucination、judge 偏差或 prompt 問題掩蓋。

概念位置

Retrieval source 位在 ingestion、index 與 runtime retrieval 的交界。它跟 chunking 不同：chunking 決定來源如何切片，retrieval source 決定來源本身是否可信、是否新鮮、是否有權限被查、是否能被引用。

可觀察訊號與例子

看到「從 codebase retrieve」「從歷史客服案例庫取相似案例」「從 vector DB 查 policy」「把 filesystem search 結果塞進 prompt」就是 retrieval source 問題。不同 source 的責任不同：官方 policy 文件可引用，使用者上傳文件要標記租戶與權限，網頁內容要防 prompt injection，過期 index 要能重建。

設計責任

設計 retrieval source 時要同時回答四件事：資料來源是否可信、資料是否新鮮、查詢者是否有權限、LLM 回答是否能追溯。高風險來源要保留 source metadata、ingestion timestamp、tenant boundary 與引用標籤；否則 retrieval 命中正確內容，也可能把不該看的資料送進 prompt。

概念位置

兩條 retrieval 路線的盲點：

主流合併方法：

Reciprocal Rank Fusion（RRF）

最常用、簡單：

 1對每個 doc：
 2  score = sum_over_retrievers(1 / (k + rank_i))
 3
 4k 是常數（典型 60）、rank 是該 retriever 給 doc 的排名
 5
 6example：
 7  doc X 在 BM25 排名 3、在 embedding 排名 1
 8  RRF score = 1/(60+3) + 1/(60+1) = 0.0159 + 0.0164 = 0.0323
 9
10按 RRF score 排序、取 top-K

優點：不需要 normalize 不同 retriever 的分數、簡單可靠 缺點：不能 fine-tune 兩條路線的權重

Weighted score fusion

對每條路線的 score 加權平均：

1score = α × BM25_score_normalized + (1-α) × embedding_score_normalized

優點：可以調 α 偏 BM25 或 embedding 缺點：要 normalize 兩個 score scale、調 α 是 hyper-parameter

設計責任

讀 RAG production / retrieval framework 看到「hybrid search」「BM25 + dense」「RRF」就是這 framing。寫 code 場景的判讀：

1. 何時值得加 hybrid：embedding-only retrieval 漏精確 keyword / 識別碼、BM25-only 漏語意相似、混合補完
2. 何時不需要：純語意任務（embedding 已準）、純 keyword 任務（BM25 已準）、極小語料
3. 跟 reranker 的組合：hybrid retrieve top-50（BM25 top-25 + embedding top-25、RRF 合併）→ reranker rerank → LLM top-5
4. 主流實作：Elasticsearch / OpenSearch 內建、Weaviate / Qdrant / Pinecone 都支援、Postgres 用 pg_search + pgvector
5. 跟 4.1 RAG 章節 的關係：本卡是定義、章節是 retrieval pipeline 設計含 hybrid 段

概念位置

Bi-encoder vs cross-encoder 的差別：

1Bi-encoder（embedding model、retrieval 第一階段）：
2  query → embedding A
3  document → embedding B（pre-compute、存 vector DB）
4  score = cosine(A, B)
5  → 快、可 pre-compute、適合海量 retrieval
6
7Cross-encoder（reranker、retrieval 第二階段）：
8  (query, document) 一起進模型 → 直接輸出 relevance score
9  → 慢（每對都要 forward pass）、不可 pre-compute、適合 top-K rerank

主流 reranker：

設計責任

讀 RAG / production retrieval docs 看到「reranker」「cross-encoder」「rerank stage」就是這 framing。寫 code 場景的判讀：

1. 何時值得加 reranker：retrieval 結果有「相關但不精確」問題、top-K hit rate 高但 top-5 hit rate 低、有 latency / cost budget
2. 何時不需要：小語料（< 1000 docs、retrieval 已準）、明確 keyword 任務（BM25 已準）、latency 敏感（< 100ms TTFT）
3. Pipeline 設計：bi-encoder retrieve top-50 → reranker rerank → 給 LLM top-5；50/5 是常見起點、看實測調
4. 跟 hybrid search 結合：BM25 + embedding hybrid retrieve top-50 → reranker rerank → LLM、是 production RAG 標配
5. 跟 4.1 RAG 章節 的關係：本卡是定義、章節是 retrieval pipeline 設計（含 reranker / hybrid 段）

實務上 vanilla RAG 不夠用的場景比想像多：query-document gap 大、單次 retrieve 拿到的片段不足以回答完整問題、retrieve 結果太多塞爆 context、不該 retrieve 的問題被強制 retrieve。每個場景對應不同的增強技術。本章把這些技術寫成可挑選的工具箱、不是「全部都套」的最佳實踐。

本章目標

讀完本章後你能：

1. 區分 retrieval pipeline 的四個增強層（query 端 / retrieval 端 / context 組裝端 / 控制流端）。
2. 對 query-document gap 選對工具（query rewriting / expansion / HyDE）。
3. 判斷任務需要 multi-step retrieval 還是 single-step 夠用。
4. 設計 retrieve 後的 context packing（dedup、ordering、summarization）。
5. 設計 adaptive retrieval：什麼時候該 retrieve、什麼時候直接答。

Retrieval Pipeline 的四個增強層

Vanilla RAG 是「query → retrieve → prompt」三步。增強分四層、每層解不同問題：

 1┌─────────────────────────────────────────────────┐
 2│ User query                                      │
 3└─────────┬───────────────────────────────────────┘
 4          ↓
 5   [1. Query 端增強]
 6   query rewriting / expansion / HyDE / query decomposition
 7          ↓
 8   [2. Retrieval 端增強]
 9   hybrid search + reranker（見 4.1）
10   multi-step / iterative retrieval
11          ↓
12   [3. Context 組裝端]
13   dedup / ordering / summarization / compression
14          ↓
15   [4. 控制流端]
16   adaptive retrieval（要不要 retrieve）/ self-RAG
17          ↓
18   LLM final answer

判讀 vanilla 不夠時、先定位失敗在哪一層、再選對應工具。盲目把四層全套上、retrieval cost 跟 latency 翻倍、accuracy 不一定有對應收益。

Query 端增強

Vanilla RAG 直接用 user query 做 embedding、但 user query 往往不是「最適合 retrieve 的形狀」。Query 端增強就是在 retrieve 前重塑 query。

Query rewriting

用 LLM 把 user query 改寫成「更接近 document phrasing」的形式。

• 適用：query 口語、document 正式（如 user：「怎麼讓 API 跑快」、document：「latency optimization techniques」）。
• 實作：LLM call、prompt 是「把以下 query 改寫成適合 search 的查詢句、保留語意、改用技術詞彙」。
• 失效：rewriting 把意圖改偏（user 問「為什麼慢」、改成「optimization」、答非所問）。緩解：rewriting 提示要求 preserve intent、retrieve 結果回來後讓 LLM 對照原 query 判斷。
• Cost：每 query 多一個 LLM call、latency 加 200–500ms，屬於 retrieval cost。

Query expansion

不改 query、而是生成多個 query 變體、一起 retrieve、合併結果。

• 適用：query 短、有多種可能解讀（「python」可指語言 / shell / 套件）、單一 query 漏 coverage。
• 實作：LLM 生成 3–5 個變體（同義改寫、不同角度、不同抽象層級）、每個變體獨立 retrieve、結果用 Reciprocal Rank Fusion 合併（RRF 是 RAG 文獻常見的多 retrieval source 合併演算法、不在本指南範圍展開）。
• 失效：變體太發散、混入無關 doc、稀釋了 top-k 的精確度。緩解：限制變體數量（3–5）、合併時對重複出現的 doc 加權。
• Cost：N 倍 retrieval cost、但每次 retrieve 是平行、latency 不是 N 倍。

HyDE（Hypothetical Document Embeddings）

HyDE（4.1 RAG 原理 提過、這裡展開）。核心觀察：query 跟 document 在 embedding 空間的距離、往往比 document 跟 document 之間更遠——這是 query-document gap 的典型表現。

機制：

1. 用 LLM 對 user query 生成「一份假設的答案文件」（hallucinated document）。
2. 對這份假文件做 embedding、不是對原 query。
3. 用假文件 embedding 去 retrieve 真實 document。

為什麼比直接 embed query 好：假文件的 phrasing、長度、結構都更接近 document 分佈、embedding 距離更可靠。重點是 retrieval、不是回答——假文件的事實正確性不重要（hallucinate 出錯誤細節 OK）、但語意 / 領域要落在對的範圍、才能拉回對的 document。

• 適用：query-document gap 顯著的場景（問句 vs 陳述、口語 vs 正式、抽象 vs 技術詞彙）。HyDE 原論文跨多個領域 benchmark 都有提升、不限技術 / 學術。
• 失效：假文件偏離主題（LLM hallucinate 到別的領域）、retrieve 拿到完全不相關的東西。緩解：生成多個假文件取平均 embedding、或用 query + 假文件兩個 embedding 合併 retrieve。
• Cost：每 query 多一個 LLM call（生假文件）、latency 加 500ms–1s。

Query decomposition

把複雜 query 拆成幾個子 query、各自 retrieve、再合併。

• 適用：複合問題（「比較 A 跟 B 在 X 跟 Y 的差異」）、單次 retrieve 拿到的 chunk 不完整。
• 跟 multi-step retrieval 的差異：decomposition 是「一次拆成 N 個 query 平行 retrieve」、multi-step 是「retrieve → 看結果 → decide 下一個 query」。前者快、後者貼近資料。
• 失效：子 query 之間有依賴（後面的 query 要看前面的結果）、平行做不出來、要走 multi-step。

何時用哪個

實務上 query rewriting 跟 HyDE 是首選——cost 低、改 prompt 即可、收益穩。Expansion 跟 decomposition 在特定 query 形態才有顯著收益、預設不開。

Multi-step / Iterative Retrieval

Single-step retrieve 假設「一次 retrieve 拿到所有需要的 chunk」、但多 hop 問題（要從 doc A 找到 entity X、再從 doc B 找 X 的屬性）這個假設不成立。Multi-step retrieval 是 retrieve → LLM 判斷夠不夠 → 不夠就再 retrieve、靠 LLM 的判斷決定 retrieve 路徑。

機制：

 1Initial query
 2   ↓
 3Retrieve round 1 → top-k chunks
 4   ↓
 5LLM：「這些 chunks 夠回答嗎？若不夠、下一個該 retrieve 什麼？」
 6   ↓ (不夠)
 7Generate sub-query 2
 8   ↓
 9Retrieve round 2 → top-k chunks
10   ↓
11LLM 判斷
12   ↓ (夠)
13Final answer

跟 vanilla single-step 的差異：

• 靈活：retrieve 路徑是 query-dependent、不是固定。
• 昂貴：每 round 加一個 LLM call + retrieve、latency 跟 cost 線性疊加。
• 失敗模式：LLM 判斷「不夠」的能力差、無限 retrieve；或判斷「夠了」太樂觀、缺資訊還是答。

對應 4.4 agent 架構 的失敗模式分類：multi-step retrieval 是 agent loop 的特例、context drift / goal drift 一樣會發生。

Multi-hop 推理的核心模式

Multi-hop 問題的典型 pattern：「A 跟 B 有什麼共同點」、需要先 retrieve A 的屬性、再 retrieve B 的屬性、再 compare。Single-step retrieve 不會自動把這兩組 chunk 都抓回來。

Multi-step retrieval 在這類問題上的 accuracy 提升明顯、但 trade-off 是 latency 翻倍以上、cost 翻倍以上。

Multi-step 划算的三條件

三條件全滿足才走 multi-step、任一不滿足就停在 single-step：

• 問題確實 multi-hop：需要 retrieve A → 推 X → retrieve B 的形態。Single-hop 問題硬套 multi-step 純增加 cost。
• Latency budget 允許：每 round 加 1-2 秒、即時 chatbot 場景通常不容許、batch 場景才行。
• 有客觀停止訊號：可用 deterministic check 判斷「夠了」、不是純靠 LLM 自評。沒有停止訊號容易無限 loop。

Context packing：retrieve 拿到後怎麼塞進 prompt

Retrieve 拿到 top-k chunks 後、怎麼塞進 prompt 不是「直接 concat」這麼簡單。Context 組裝端的決策影響最終 accuracy 跟 cost。

Dedup

不同 chunk 可能涵蓋同樣內容（同段文字被多個版本切到、或不同 doc 引用同一個事實）。直接 concat 浪費 context budget。

• 實作：semantic dedup（embedding 距離小於 threshold 視為重複）、或字面 dedup（hash 比對）。
• 失敗：dedup 太激進、誤殺有用 chunk；dedup 不夠、context 塞重複內容。

Ordering

塞進 prompt 的 chunk 順序影響 LLM 注意力。LLM 對 context 開頭跟結尾的注意力比中間強（lost-in-the-middle 現象、深度討論見 4.11 long context engineering）。

• 策略一：relevance ordering：最相關的 chunk 放最前 / 最後、不重要的放中間。Trade-off：依賴 retrieval 的 ranking 準。
• 策略二：document order：按原文順序排（同一 doc 的 chunk 連起來）。Trade-off：保留邏輯流、但相關性散落。
• 策略三：mixed：top-3 放最前、top-4 到 top-K 按 document order 放後面。

Summarization / compression

Retrieve 拿到的 chunk 太多、塞不進 context。兩條路：

• Summarization：用 LLM 把 chunks 摘要成更短的版本、再餵主 LLM。
• Compression：用較小模型抽出 chunks 中跟 query 相關的句子、丟掉無關部分。

Trade-off：

Source attribution

Retrieve 拿到的 chunk 進 prompt 時、要不要標來源，是 retrieval source 的追溯責任問題。

• 標：LLM 可以引用、提升可信度、user 可以 verify。Cost：每 chunk 加幾十 token。
• 不標：context 短、但 LLM 沒法引用、user 沒法追溯。

實務多半標、特別是法律 / 醫療 / 學術場景。

控制流端：要不要 retrieve

Vanilla RAG 對每個 query 都 retrieve、不問該不該。實務上有些 query 不需要外部資料（「現在幾點」「2+2 等於多少」「翻譯這段文字」）、強制 retrieve 反而塞無關 chunk 干擾，也會浪費 retrieval cost。

Adaptive retrieval

讓 LLM 自己決定 retrieve 與否。

• 路線一：predict-then-retrieve：先用小模型 / 規則判斷 query 類型（factual / reasoning / chitchat）、factual 才 retrieve。
• 路線二：self-RAG：LLM 在生成過程中、輸出特殊 token 「我需要 retrieve」、觸發 retrieve、整合結果繼續生成。需要訓練過或 prompt engineered 的模型支援。

判讀 adaptive retrieval 是否有用：

• Query 分佈：若 80% query 都需要 retrieve、adaptive 收益小、固定 retrieve 就好。
• Query 分佈：若 query 一半 chitchat 一半 factual、adaptive 減半 retrieval cost、收益大。

Confidence-based retrieval

LLM 先嘗試直接答、若 confidence 低（self-report 或 logits 機率）、再 retrieve。

• 適用：模型對部分 query 有把握、部分沒、想省 retrieval cost。
• 失敗：模型過度自信、low-confidence 訊號不準、該 retrieve 沒 retrieve。

失敗模式：增強堆疊出反效果

不同層的增強可以堆、但堆過頭會反效果：

• Query rewriting + HyDE + expansion 全開：query 端 noise 過多、retrieve 結果稀釋、accuracy 反降。
• Multi-step + reranker + summarization 全開：每 round latency 累積到使用者不能忍受。
• Adaptive + multi-step 混亂：adaptive 說「不 retrieve」、但 multi-step 又觸發 retrieve、控制流互打。

設計反射動作：先確認 vanilla RAG（hybrid + reranker）的失敗在哪一層、針對性加一個增強、看是否有收益、有再加下一個。不要四層全套。

跟相鄰章節的邊界

• vs 4.1 RAG 原理：4.1 寫 vanilla 骨架跟 production 兩段式（hybrid + reranker），這章寫進一步增強。
• vs 4.11 long context engineering：long context 是「context 大到能塞」、RAG 是「context 不夠要 retrieve」、兩者是不同 regime 的策略。本章 context packing 段的 lost-in-the-middle 是兩個 regime 的共通議題。
• vs 4.7 workflow patterns：multi-step retrieval 是 workflow pattern 在 RAG 場景的特例。

何時過時 / 何時不過時

不會過時的部分：

• 四層增強分類（query / retrieval / context 組裝 / 控制流）的座標。
• 各 query 端技術解的核心問題（用詞落差 / 歧義 / 形態落差 / 複合問題）。
• Multi-step retrieval 跟 single-step 的 trade-off 結構。
• Context 組裝的三個議題（dedup / ordering / compression）。
• 「先 vanilla、再針對失敗加增強」的設計反射。

會變的部分：

• HyDE 等特定方法的最佳實作（隨 embedding 模型演化、效果會變）。
• Self-RAG 等需要訓練的方法（隨 base model alignment 訓練成熟、可能變預設能力）。
• 各家 reranker 跟 embedding 模型的選型（半年一個世代）。

下一章

下一章：4.3 Tool use 原理、從「LLM 讀外部資料」延伸到「LLM 對外部世界做事」。Vanilla RAG 的骨架見 4.1、long context 跟 RAG 的取捨見 4.11、multi-step 跟 reflection 的失敗模式比對見 4.7。