摘要： Exa 於 4 月 22 日推出 Highlights，讓 agent 只讀與查詢相關的段落；其自報評測宣稱 SimpleQA 上 500 字元摘錄可追平前 8,000 字元原文，token 少用 16 倍。這些數字未經第三方驗證，定價也未公開，採用前應用自己的查詢集測試。
只要讓 agent 跑過幾輪搜尋，這筆帳遲早浮上檯面：每輪搜尋都把一整頁原封不動灌進 context，真正的答案不過寥寥數句，剩下的盡是導覽列、頁尾和反覆出現的 boilerplate；輪次一旦疊加，token 開銷與 latency 便同步線性攀升。Exa 稱之為 context bloat，並主張這是 agentic search 眼下最該優先解決的難題——4 月 22 日推出的 Highlights 更新，思路就是把「讓 agent 讀整頁」改成「只讀與這次 query 相關的段落」。
先讀懂三組數字，再看結論
Exa 在文中列出三組關鍵數字。動手解讀之前，先確認它們的性質：這些清一色是 Exa 自己報出的評測成績，未經任何第三方檢驗，「部分 evals」從頭到尾沒點明是哪些 benchmark，只能當作廠商說法，不能視為可重製的結論。
| 宣稱 | 內容 |
|---|---|
| 準確度打平 | SimpleQA 上，500 字元的 Highlights 追得上頁面前 8000 字元的準確度 |
| token 用量 | 這組比較的 token 少用 16 倍；Exa 另聲稱部分 evals 以約 94% 更少 token 得到更高品質結果 |
| 預算放大 | 32k 字元的全文，仍敵不過 4k 字元的 Highlights |
三組之中最有分量的是 SimpleQA 那筆：區區 500 字元的摘錄便追平前 8000 字元原文的準確度，token 還少用 16 倍。「約 94%」屬於行銷摘要式的講法，找不到可供對照的基準細節；第三組（4k 勝 32k）則表示就算放寬預算，摘錄依舊佔上風。對 builder 而言，值得記住的是趨勢而非確切數字：壓縮比拉得再高，摘錄品質也沒有崩壞——這才是整篇公告想說的核心。
運作方式：逐請求現算、不吃快取、100 毫秒內完成
Highlights 是 Exa 自行打造的萃取方法（in-house method），用意是從網頁裡挑出與當次 query 最貼近的 excerpts。有三個設計決策值得留意。首先，它每個請求都重新執行、完全不做快取——同一頁面在不同 query 底下會萃出不相同的段落，Exa 寧取相關性而非重用。其次，單次執行不超過 100 毫秒，快到足以嵌進 agent loop 的每一步，等摘要不必以犧牲回應速度為代價。最後，Exa 表示這個模型是多輪研究磨合出來的，探索過各式架構與訓練配方才落定現行做法，並聲稱近來在技術文件（API references、SDK docs）與長文件（specs、research papers）上進展明顯。
差距拉得最開的正是長文件。在長頁面配小 context budget 的對比裡，500 字元這一點上 Highlights 拿 60%、對手方法只有 6%：面對滿紙 boilerplate 的長篇文件，對手幾乎鎖定不了正確段落，Highlights 卻能直接把答案段落推到最前面。多輪搜尋也因此受益最深——每一輪都在省，省下的量再乘上輪數，就是一個量級的落差。
公開 API 之外：也是 Exa 自家 agent 產品的檢索底層
對外的 Highlights API 並非全貌。Exa 自家的 agentic endpoints——/answer、Deep、Websets——底層同樣把 Highlights 當 retrieval substrate 用：這些產品的 agent loop 每迭代一次，讀進來的都是 highlights，而不是未經處理的頁面原文。Exa 更進一步聲稱，旗下 agentic 產品在 latency、cost、quality 三條軸上對競爭系統取得 Pareto dominant——這當然仍是自報宣稱，但邏輯站得住腳：檢索層先把 token 效率做起來，下游產品便自然同時繼承速度與成本兩項優勢，無須靠事後補做的壓縮。
採用前該盤點的取捨與限制
動手導入之前，有四件事得攤開來看。第一，全部數據出自 Exa 自報，沒有第三方背書，「部分 evals」也沒交代是哪些 eval，想套用結論，先用自己手上的查詢集驗一輪。第二，原文對 Highlights 的定價與計費隻字未提，成本模型得自己去弄清楚。第三，生態綁定：Highlights 隸屬 Exa API，走其他搜尋引擎或自建檢索的團隊得不到直接好處，出路只有兩條——換供應商，或自己訓一個類似模型。第四，摘錄必然會丟掉部分上下文，eval 上的 recall 不等於在你 domain 上的實際表現——被摘錄剔除的細節，agent 無從察覺它們缺席。
給 builder 的落地建議
三個馬上能用的判斷。第一，摘錄該被視為 agent 實際閱讀的介面，而非輸出前的妝點：檢索當下就只餵相關段落，比先收全文再過濾便宜整整一個量級，還能把 context window 留給真正的推理。第二，長文件工作負載優先接上——API references、SDK 文件、研究論文正是 60% 對 6% 這個差距現身的地方，也是 token 帳單最傷的位置。第三，人已經在 Exa 生態裡，Highlights 幾乎是零成本升級；人還在生態外，這篇公告起碼留下一個明確的訓練目標：檢索層該學會「為特定 query 抽特定段落」，而不是交回固定長度的頁首。