【2026 最新】LASAGNA 教學：RAG 改寫加 Reranker 會更好嗎？四組對照看懂組合效應

你替文件問答加了查詢改寫，又加了 Reranker，原本答對的題目卻開始答錯。做 LASAGNA 教學 最值得學的，就是把這個疑問變成四組可以逐題核對的實驗：到底是哪個零件有幫助，接在一起又發生了什麼？

這篇寫給第一次替 RAG 做評估的讀者。你不必先懂統計，先把它想成試菜：醬料 A、醬料 B 各自好吃，混在一起未必更好。我們先用免生成模型 API 的小練習接通流程，再學會用自己的文件檢查組合；需要操作電腦終端機，程式與設定會逐段解釋。

以下依 2026 年 10 月 23 日查閱的官方文件與固定程式提交整理。本文提供來源查核過的操作設計，未執行完整模型檢索跑分；文中的算術示範也不是產品成績。

先說結論：組合效果，要用四格考卷驗收

交互作用＝兩個都開的改善－只開 A 的改善－只開 B 的改善。三個改善都以同一個「兩個都關」為起點。記住這句，你就不會再把兩篇論文的進步幅度直接相加。

• 先固定文件、題目、Embedding（把文字轉成數字向量的模型）及評分規則，再切換改寫與重排。
• 檢索找得好，和答案忠於證據，分開驗；等待時間與成本也各自記。
• 小型練習先看接線，正式選型再用代表性問題、干擾文件與獨立測試集。

一、LASAGNA 教學先懂三個零件：找書、換問法、排書單

RAG 是檢索增強生成：先替模型找資料，再讓它根據資料回答。若這一步還陌生，可先讀 BM25、Embedding 與 Hybrid Search 教學。這篇往前一步，問的是「加第二個零件時，第一個零件的幫助還在嗎？」

①「找書員」：Retriever 先決定誰能入圍

Retriever 是第一輪檢索。它從整個文件庫挑候選段落，好比先從圖書館搬出一疊可能相關的書。候選深度就是搬出幾本；之後只交幾段給回答模型，是另一個設定。兩者都要固定，否則你同時改了零件和工作量。

②「翻譯問題」：Query Rewrite 讓問法靠近文件用語

使用者問「多久內能退？」，文件寫「退貨申請期限」，改寫可以把口語對上正式詞。Rewrite-Retrieve-Read 原論文研究的就是查詢與所需知識之間的落差。改寫也可能漏掉「已拆封」之類關鍵限制，所以要保留原句及改寫文字，逐題核對意思。

③「決賽評審」：Reranker 把入圍者重新排序

Reranker（重排器）重新評估候選。Cross-Encoder 會把問題與段落一起讀入模型再評分；Sentence Transformers 的官方說明展示了先召回、再重排的分工。就這種兩階段流程而言，重排處理的是已入圍候選；要找回漏掉的證據，需先檢查第一輪檢索。

LASAGNA 則是試驗台：把零件放進可替換的管線，在其餘設定受控時觀察改動。它的價值在於留下設定、逐題分數及比較證據；可以和你原有的開發工具一起使用。完整知識庫還涉及資料清理、權限與更新，可搭配 企業 AI 知識庫架構理解。

二、為什麼不能把兩個進步數字相加？

2026 年 10 月 21 日提交的 《Retrieval Augmented Generation Compositionality》引入 LASAGNA。作者報告測試 450 種配置、八個基準，並檢查不同文件規模。他們觀察到零件收益未必相加、檢索與忠實度可能偏好不同配方，以及配方排名可能隨語料規模改變。

這些是作者在其測試設定下的研究觀察。論文對主要 profile 比較明列「一個建構的英文多領域測試床」等限制，不能直接當成繁中客服或法規文件的效果保證。本文借用的是檢驗組合的方法，不替某款 Reranker 預先判輸贏。

直覺上有兩種可能：改寫與重排都修好同一道題，改善就有重疊；改寫把不同證據帶進候選，重排也可能把那段證據擠掉。後者是否發生，要看實際候選與排序紀錄，不能只憑總分猜原因。

三、LASAGNA 教學第一步：固定版本，先跑 speed 接線

準備已安裝 Python 3.10–3.13 與 Git 的 macOS 或 Linux 練習環境；Windows 讀者可先依官方平台說明使用 WSL。以下以 Python 3.11 建虛擬環境，把這次套件與你其他專案隔開。依 官方安裝說明，套件名是 lasagna-rag。這裡固定到查核的提交，安裝包含評估用的 eval extra。

python3.11 -m venv .venv
source .venv/bin/activate
python -m pip install 'lasagna-rag[eval] @ git+https://github.com/dolev31/lasagna.git@3ed6686e4626b3fb78d42397bf35605677efbd39'
lasagna benchmark run smoke --profile speed

speed 使用 all-MiniLM-L6-v2 做向量檢索；官方把該模型下載量描述為約 92 MB。smoke 內含 24 份文件與 12 道題，這條檢索命令不呼叫生成模型。套件依賴仍包含 Torch 等程式，整體安裝遠大於那個模型檔，請先留足空間與下載時間。

先讀終端機的成功、失敗與輸出路徑；有失敗就先處理，不把少跑的題目當作零分後混入平均。smoke 通過代表接線跑通。官方刻意把它設得容易，適合練習資料流，不適合選出正式上線的贏家。首次下載、模型載入與暖機後查詢的時間，也分開保留。

四、建立改寫 × 重排的四組條件

先把 A 定義成「啟用一份固定的查詢改寫」，B 定義成「啟用 Cross-Encoder 重排」。這裡採人工同義詞規則，避免為了學實驗設計先接付費 API；它不是論文的 LLM 改寫器，也不代表 LLM 改寫能達到同樣效果。

在目前資料夾建立 terms.py，貼上以下函數。@lasagna.query_enhancer 把它包成管線可呼叫的改寫元件；回傳值是一份查詢清單。這兩條英文字詞規則只拿來讓 smoke 練習看得出改動，換成自己的測試題時，應在開發集決定規則，保留未拿來調整的測試集。

import lasagna

@lasagna.query_enhancer
def fixed_rewrite(query):
    rewritten = query.replace("drying out", "desiccation")
    rewritten = rewritten.replace(
        "thermal shock", "sudden temperature change"
    )
    return [rewritten]

重要的是實際語意：這版多查詢路徑會保留原問題，原句與改寫各走一次檢索，再融合結果。11 格會在各查詢分支重排後，以加權 RRF（依名次合併清單）產生最終排序，並非融合後才做一次重排。因此 A 測的是「原句＋固定改寫的搜尋流程」，包含融合造成的影響，不是只替換一句話的純效果。若要研究完全替換原句，需另接對應 Retriever，並重新定義實驗。官方查詢流程程式碼可核對這個邊界。

接著在同一資料夾建立 compose.yaml。config_overrides 為每組命名；speed 是共同起點，enable_reranking: false 明確表示關閉重排。只在需要的格子指定元件，不用 null 猜「關閉」的含義。

name: fixed rewrite and reranking
benchmarks: [{name: smoke}]
tracks: [retrieval]
pipeline:
  base_profile: speed
  config_overrides:
    - name: neither
      enable_reranking: false
    - name: rewrite
      query_enhancer: terms:fixed_rewrite
      enable_reranking: false
    - name: rerank
      reranker: cross_encoder
    - name: both
      query_enhancer: terms:fixed_rewrite
      reranker: cross_encoder
n_runs: 1

這個 cross_encoder 在 speed 比較使用 MiniLM 重排模型，首次使用另需下載。固定函數與本機重排的這份配方不需要生成模型 API；若日後換成官方 rewrite LLM 元件，就要另外設定已授權的模型入口、重跑次數及費用預算，不能沿用「免 API」的描述。

lasagna component validate terms:fixed_rewrite
lasagna benchmark experiment compose.yaml --dry-run --no-probe
lasagna benchmark experiment compose.yaml

第一行驗元件介面；第二行列出計畫且不做探測執行；第三行才真的跑四組。確認輸出只有預期的四個名稱，再查看失敗項目、實際設定及 stage isolation（階段隔離）訊息。若兩組候選或排名完全相同，先確認改寫有被呼叫、詞語有命中，以及重排後名單是否真的移動；相同結果可能是這題沒有受影響，也可能是元件未生效。

正式換自己的文件時，依 官方自有資料格式準備 BEIR 資料夾：corpus.jsonl 存文件、queries.jsonl 存題目、qrels/test.tsv 存哪題對應哪些相關文件。將 YAML 的 benchmark 換成 benchmarks: [{path: data/my_beir}]，相對路徑以 YAML 所在資料夾為準。先用 lasagna benchmark validate-data data/my_beir 檢查。這樣才能把真正無關但很像的文件放進考場。

五、算交互作用：少於相加，不等於組合比原版差

每題都保留同一個 ID，對齊四格分數。令 S00 是都關，S10 只開改寫，S01 只開重排，S11 都開；交互作用對比就是 S11 − S10 − S01 ＋ S00。正值表示超過這個指標上的相加預期，負值表示低於相加預期；它本身不會告訴你是哪段程式造成的。

做一次純算術演練：假設某題四格依序是 0.40、0.50、0.55、0.58，相加預期是 0.65，對比為 −0.07。組合的 0.58 仍高於單用任一零件，也高於原版；所以負交互作用與「加上去反而更差」是兩個判斷。要回答值不值得在改寫後加重排，直接比較 S11 − S10，再一起看等待與成本。以上數字是自訂教學例子。

把終端機印出的 results.json 真實路徑放進變數，不要照抄尖括號占位字。以下名稱與剛才的四組一致；ndcg@10 是重視相關文件是否排在前面的指標。

RESULTS="填入本次實際輸出的 results.json 路徑"
lasagna results interaction "$RESULTS" --metric ndcg@10 --neither neither --only-a rewrite --only-b rerank --both both
lasagna results significance "$RESULTS" -m ndcg@10 --all
lasagna results per-query "$RESULTS" --sort-by ndcg@10

依 官方統計方法，交互作用檢驗以每題四格的配對對比做 sign-flip 測試，並報告平均差的 t 信賴區間；全配對顯著性比較另外使用 Holm 校正。入門先讀差距方向、區間與失敗題，不把「未顯著」寫成兩套完全一樣。這個小 smoke 的任務是演練流程，正式結論要另備足夠而有代表性的題目。

六、四張成績單：檢索、忠實度、等待與成本分開記

第一張，證據找對沒有？看 nDCG、Recall 以及逐題候選。Recall 是已標註相關證據中找回多少；nDCG 還考慮順序。正確段落原本在候選內、重排後卻掉出交給回答模型的範圍，才有證據追查重排那一段。

第二張，回答是否忠於資料？Ragas 的 Faithfulness 定義檢查答案中的主張能否由取回內容支持。它與回答是否完整、資料本身是否正確是不同問題。這份 retrieval-only YAML 沒有生成答案，所以也沒有替你量忠實度；完成檢索比較後，再固定生成模型、提示詞、可用上下文長度與評分模型，開另一輪生成評估。

第三張，使用者等多久？從問題進入到結果可用量端到端時間；保留改寫、檢索、重排與生成的分段耗時。第一次模型載入另列，不把暖機後的中位數當所有請求都會達到的時間。有模型呼叫的配置交錯執行並重複，避免把某一時段的服務壅塞誤判為零件效果。

第四張，付出多少資源？本機模型沒有逐次生成 API 帳單，仍占 CPU／GPU、記憶體與運行時間。若接外部改寫、回答及評分 API，三筆用量分開算，再記重試與失敗；送往哪個服務的問題和段落也一起盤點。先用可公開或自製資料，不把客戶內容直接放進新的評分入口。

最後，把相同問題放回不同語料規模重考。擴大時保持既有相關文件及題目，新增文件後也檢查有沒有多出可接受正解；只增加文件卻不補標註，會把找對的新證據誤算成錯。英文 speed 練習完成後，繁中正式資料需另選合適模型並重跑四格，不能把語言與 Embedding 一起換掉後，仍將差距歸因於 Reranker。

常見問題：八個直接答案

1. LASAGNA 是另一個聊天 App 嗎？

不是這篇要操作的用途。這裡使用它的檢索與評估管線，目標是知道改了哪個零件、哪些題目跟著改變。

2. 加 Reranker 一定會變差嗎？

不一定。先看相同候選與題目的前後排序，本文沒有給任何模型通用的勝負結論。

3. speed 跑完就有答案忠實度嗎？

沒有這份設定下的忠實度分數。本文只要求 retrieval 軌；要量答案，必須另外實際生成並評分。

4. 三格能算出第四格嗎？

不能直接從已測三格推定真實第四格。相加只是待驗假設，四格實際跑完才能檢查偏離。

5. 負交互作用就應該刪掉一個零件嗎？

先比較你的下一個決策。組合可能仍比單項好；若多花的時間只換很小改善，再按預先設定的品質與等待門檻取捨。

6. smoke 很高分，可以上線嗎？

先換正式考卷。它的文件少、題目容易，適合抓接線錯誤；用真實問法、干擾文件及保留測試集再驗。

7. JSONL 只有標準答案段落，夠嗎？

能練流程，但考場偏容易。LASAGNA 會把各列 contexts 聚成 pooled_gold；正式庫裡常見的相似錯誤段落，也應納入有標註的語料。

8. 改成 LLM 重寫後，還用同一輪結果嗎？

重新跑。固定函數變成模型呼叫，查詢內容、變異、延遲、費用都變了；先保存提示詞與模型設定，再重複四組。

給新手的三個重點

• 先問新增零件改善哪個失敗，再用四格檢查它與既有零件是否互相影響。
• 把相加預期、實際組合增益與每題差異分開，避免一個總分遮掉退步。
• 先跑通小練習，再用自己的語言、文件規模與服務限制決定配方。