摘要： Exa 在 5 月 13 日公布對照實驗，兩個設定相同的 Qwen3-4B 搜尋 agent 只差搜尋後端：一方用 Exa，另一方透過 SERP 代理取得 Google 結果。廠商自述結果顯示 Exa 版在六個 benchmark 的 pass@1 全面領先，並以較少 tokens、搜尋次數與 turns 達到同等水準；實驗只測單一 4B 模型且未抓全文。
訓練搜尋 agent 時，大家的目光多半放在模型怎麼選、reward 怎麼設計、prompt 怎麼調整，搜尋 API 則被當成可以隨時換掉的零件。Exa 在 5 月 13 日公開的對照實驗把問題推回更上游：RL 過程中若換掉搜尋後端，agent 最終練出的能力是否跟著改變？結論是肯定的，而且這道鴻溝同時出現在準確率、訓練花費與推論花費上。話說在前頭：實驗是 Exa 自己做的，而 Exa 正是受測的兩個後端之一，文中所有數字皆屬廠商自述，引用時請帶著這層警覺。
實驗設計：兩個 agent 只差一個搜尋後端
實驗以 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、LoRA rank 32、context 上限 32k，跑 100 steps。兩邊 agent 的行動空間一模一樣，真正不同的只有一件事：搜尋這個動作由誰執行。
六個 benchmark 的成績：Exa 版全數領先
評測採 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）。在這兩座最難的山頭上，4B 加 RL 依舊翻不了盤。
算成本：tokens、search calls、turns 三本帳
跑到 step 100 時，SERP 這邊累積 1.89B total tokens，Exa 只要 1.58B，省下 20%。更該看的是等效點：Exa agent 只花 0.58B tokens（省 69%）就追平 SERP 版的最終水準，過程中 search calls 少 62%、turns 少 58%。換個說法，這不是「同一筆預算多換幾分」，而是訓練與推論兩端一起降價——搜尋更少次、trajectory 更短，到了推論端就直接變成更低的延遲與更小的帳單。有意思的是，RL 之後查詢次數不減反增（詳見下節），總 token 卻更省——多查幾次不是浪費，而是更聰明的問題拆解。
背後機制：reward 訊號更密、檢索更可靠
機制解釋靠兩組彼此呼應的證據。第一組談訊號密度：同一個 base policy 之下，Exa 搜尋結果命中正確答案的比率比 SERP 高出 10.7%（整體 36.1% 對 32.6%；首輪搜尋為 34.0% 對 30.5%）。放進 multi-turn RL 的脈絡，每次搜尋都更容易撞見答案，per-action 的 reward 就沒那麼稀疏，agent 也更容易歸納出「什麼樣的查詢能換來下一塊證據」，累積數十萬次 rollouts 後複利成 sample efficiency。同一個起點，兩邊餵給模型的證據濃度硬是不同。
第二組談穩定。整場訓練合計發出 476,474 次 search calls（Exa 224,462 次、SERP 252,012 次），SERP 有 6.74%（16,991 次）只回來不到 5 筆、0.19% 一筆都不剩；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），整條 rollout 只發一次 search call 的比例從 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 更短，等於直接兌換成延遲與成本；兩個後端分數打平時，先算成本帳再做決定。