當程式代理收到提示時，若要給出正確答案，必須透過讀取檔案並搜尋相關資訊，來建立對程式碼庫的理解。

Cursor 的 Agent 使用的工具之一是語意搜尋。除了像 grep 這類工具提供的正則表達式搜尋外，它還能依照自然語言查詢擷取相符的程式碼片段，例如「我們在哪裡處理身分驗證？」。

為了支援語義搜尋，我們訓練了自家的嵌入模型，並打造了索引處理管線以加速擷取。雖然你可以只依賴 grep 等命令列工具來搜尋，但我們發現語義搜尋能大幅提升 Agent 效能，尤其是在大型程式碼庫中：

• 在問答準確率方面平均提升 12.5%（依模型不同提升介於 6.5% 至 23.5%）。
• 產出更可能在程式碼庫中被保留的程式碼變更。
• 讓使用者以更少的反覆嘗試即可達成正確解決方案。
• 提升我們測試過的所有模型（包括所有最先進的程式碼模型）的準確性。

離線評估

我們維護一個名為 Cursor Context Bench 的評估資料集，專注於在具有已知正確答案的程式碼庫中擷取資訊。此評估涵蓋 Cursor 中最常用的各款模型，包括我們自家的Composer。

此比較評估在兩組可用工具下的效能：一組包含語意搜尋，另一組不包含。在每種設定中，語意搜尋都能大幅改善結果。

線上 A/B 測試

我們也希望了解對最終使用者體驗的影響。我們進行了一次 A/B 測試：兩組都使用相同的模型，但其中一組的代理可使用語義搜尋，另一組則僅依賴像 grep 這樣的傳統搜尋工具。我們觀察了兩項指標：

• 程式碼留存：由高效 Agent 撰寫的程式碼更有機會留存在使用者的程式碼庫中。我們觀察到，當可使用語意搜尋時，Agent 產生的程式碼留存率提高 0.3%。在包含 1,000 個以上檔案的大型程式碼庫中，此效果提升至 2.6%。
• 不滿意的使用者請求：由高效代理撰寫的程式碼無需後續追問或更正。我們觀察到在無法使用語意搜尋時，不滿意的後續使用者請求增加了 2.2%。

這裡的效果量較低，因為這次 A/B 測試涵蓋所有 Agent 查詢，而並非所有請求都需要搜尋。

自訂檢索模型

促成這些成果的關鍵之一是我們的自訂嵌入模型。我們的方法以 Agent 工作階段作為訓練資料：當 Agent 處理任務時，通常會在找到正確的程式碼之前進行多次搜尋並開啟多個檔案。透過分析這些追蹤紀錄，我們可以回過頭來看出在對話較早階段本應該被擷取的內容。

我們將這些追蹤資料提供給 LLM，讓它在每個步驟評定並排序最有幫助的內容。接著，我們訓練嵌入式模型，使其相似度分數與這些由 LLM 產生的排序對齊。如此形成一個回饋迴圈，模型能從代理實際完成程式設計任務的方式中學習，而非依賴通用的程式碼相似度。

結語

若要達到最佳效果，目前必須使用語意搜尋，尤其是在大型程式碼庫中。

我們的 Agent 大量使用 grep 與語意搜尋，兩者結合能帶來最佳效果。隨著模型不斷改進，我們會持續測試並評估提供給 Agent 執行框架的所有工具。