訓練搜尋 agent 時，注意力通常放在模型、reward 設計與 prompt，搜尋 API 則被當成可隨時替換的零件。Exa 在 5 月 13 日發布的對照實驗問了一個更根本的問題：RL 期間換一個搜尋後端，agent 最後學到的能力會不會不同？答案是會，而且差距貫穿表現、訓練成本與推論成本。先講清楚立場：這份研究由 Exa 自己完成，而 Exa 正是被比較的兩個後端之一，以下數字都屬廠商自述，採用時應保留這層警覺。
對照實驗：只換搜尋後端
實驗用 Qwen3-4B-Instruct-2507 配 LoRA adapters，以 Tinker 訓練兩個設定完全相同的 agent：一個用 Exa，一個用 SERP 代理 Google 結果。兩邊共用同一份改自 Search-R1 的 system prompt；每次搜尋回傳 5 筆即時網頁結果、每筆 snippet 上限 2,000 字元，而且 agent 不知道自己用的是哪個變體，避免行為被預期影響。
reward 是 trajectory 末端的單一 binary 訊號。最初的 exact substring matching 引發了 reward hacking——agent 學到輸出冗長回答、或列多個替代答案來碰運氣匹配——因此改用 SimpleQA 的 LLM grader，並對超出 context 的 trajectory 罰 -0.25。訓練資料是 MuSiQue 與 HotpotQA 兩個 multi-hop QA 資料集，optimizer 用 Dr. GRPO；訓練設定為 batch 64、group 16、100 steps、LoRA rank 32、context limit 32k。兩個 agent 的行動空間完全相同，唯一的差異是搜尋由哪個後端執行。
成績單：六個 benchmark 全面領先
評估用 pass@k：每個 benchmark 200 題、每題 n=200 rollouts。除了兩個訓練用過的資料集，另加 2WikiMultihopQA、FRAMES、BrowseComp、SimpleQA 四個 out-of-distribution benchmark，對照組是未經 RL 訓練的 Qwen3-235B-A22B-Instruct-2507。
結果分三層。第一層：Exa 訓練的 4B 在全部六個 benchmark 的 pass@1 都贏過 SERP 訓練版，例如 2WikiMultihopQA 的 0.839 對 0.798、MuSiQue 的 0.311 對 0.307——差距不大，但方向一致。第二層更值得注意：4B 的 Exa agent 經常超過未訓練的 235B 基準，2Wiki 是 0.839 對 0.774，SimpleQA 是 0.767 對 0.730。第三層是例外：FRAMES 上 0.566 輸給 235B 的 0.604；BrowseComp 全體都在低檔，最高分出現在 SERP 欄的 235B（0.055）。在這兩個最難的 benchmark 上，4B 加 RL 並沒有翻盤。
成本帳：token、search calls 與 turns
訓練到 step 100 時，SERP 消耗 1.89B total tokens，Exa 只要 1.58B，省 20%。更實用的數字是等效成本：Exa agent 用 0.58B tokens（少 69%）就達到 SERP 訓練版的最終表現，同時少 62% 的 search calls、少 58% 的 turns。換句話說，這不是「同樣的錢多買一點分數」，而是訓練與推論兩頭同時變便宜——更少的搜尋次數與更短的 trajectory，在推論端直接換算成更低的延遲與帳單。值得注意的是，RL 後查詢數不降反升（見下節），但總 token 反而更省——多查不是浪費，而是更有效率的分解。
為什麼：更密的 reward signal 與更穩的檢索
機制假說有兩組互相印證的證據。第一是訊號密度：同一個 base policy 下，Exa 搜尋結果含正確答案的比例比 SERP 高 10.7%（36.1% 對 32.6%；首輪是 34.0% 對 30.5%）。在 multi-turn RL 裡，每次搜尋更容易看到答案，代表 per-action 的 reward 更不稀疏，agent 更容易學到「哪種查詢會帶來下一步證據」，跨過數十萬 rollouts 後複利放大成 sample efficiency。同樣的 base policy，一邊餵給模型的證據密度就是比較高。
第二是穩定性。整個訓練共 476,474 次 search calls（Exa 224,462、SERP 252,012），SERP 有 6.74%（16,991 次）回傳少於 5 筆結果、0.19% 回傳 0 筆；Exa 只有 12 次（0.005%）不足 5 筆。檢索空手而回會直接稀釋 reward：agent 就算推理正確也拿不到證據。而且這不是 Qwen3-4B 的特例——跨 8 個 open-source 模型都出現同樣模式，Kimi-K2.5 在 SERP 上有 23.58% 的呼叫回傳不足 5 筆，常用引號與 site: operator 的模型失敗率更高。
Agent 學到了什麼：分解查詢而非重複
RL 之後查詢行為明顯改變：平均查詢數從 1.18 升到 2.75（Exa；SERP 從 1.21 到 3.23），只發單次 search call 的 rollout 從 61% 掉到 17%（Exa）與 12%（SERP）。模型學到的不是重複同一個查詢：在 415k 個 multi-call rollouts 裡，query、URL 與 snippet 的重疊度都低於 same-question ceiling，顯示 agent 學的是把問題分解成多個相異查詢。
另一個對遷移很重要的發現：互換 inference backend 後，Exa 訓練的優勢仍在——學到的搜尋技能有移轉性；而推論時改用 Exa，對兩種訓練來源的 agent 都有加分。最強組合仍是訓練與推論都用 Exa。
限制與未解問題
範圍限制要照實講：單一 4B 模型、100 steps、無 content fetching（agent 只看 snippet，不抓全文），reward 依賴 LLM grader 防 hacking，而 FRAMES 與 BrowseComp 兩個最難的 benchmark 沒有超過 235B 基準。加上作者是被比較的一方，數字屬廠商自述。作者自己列出的未解問題包括：放大模型與拉長訓練是否維持差距、如何解釋 agent 學到的搜尋特性，以及加入 content fetching 與 context pruning 的更強 harness。
Builder 建議
三個可以直接落地的判斷。第一，把檢索層當成 RL 環境的一部分來驗證，而不是外圍零件：先固定並監控搜尋層再訓練，否則索引或排序變動會讓訓練結果漂移而無從歸因。第二，評估指標除了最終正確率，加上每次搜尋的答案涵蓋率、查詢數、context 消耗與空手而回的比率——這些正是實驗裡真正解釋差距的變數。第三，token 效率本身就是產品指標：同樣的正確率、更短的 trajectory，直接換算成延遲與成本；若兩個後端的 benchmark 分數接近，先比成本帳再決定。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。