當程式碼代理收到使用者的 prompt 時，要提供正確答案，就必須先透過讀取檔案與搜尋相關資訊，來建立對程式碼庫的理解。

Cursor 的 Agent 使用的工具之一是語意搜尋。除了像 grep 這類提供正規表示式搜尋的工具外，它還能根據自然語言查詢（例如「我們在哪裡處理 authentication？」）擷取出相符的程式碼區段。

為了支援語意搜尋，我們訓練了自有的嵌入模型，並建立了用於快速檢索的索引處理管線。雖然你可以只依賴 grep 和類似的命令列工具來搜尋，但我們發現語意搜尋能顯著提升 Agent 的效能，特別是在大型程式碼庫上：

• 在回答問題時，平均達到高出 12.5% 的正確率（依模型不同介於 6.5%–23.5%）。

• 產生的程式碼變更更有可能在程式碼庫中被保留。

• 使用者為了得到正確解答所需的迭代次數更少。

• 在我們測試的所有模型上都能提升準確率，包括所有最先進的程式碼模型。

#離線評估

我們維護一個評估資料集 Cursor Context Bench，專門用於測試在已知正確答案的程式碼庫中擷取資訊的能力。這項評估會在 Cursor 中所有最常使用的模型上執行，包括我們自己的 Composer。

我們比較在兩組可用工具下的效能表現：一組包含語意搜尋，另一組則不包含。在每一種配置中，語意搜尋都能顯著提升結果品質。

#線上 A/B 測試

我們也希望了解這對最終使用者體驗的影響。我們設計了一個 A/B 測試，兩組都使用相同的模型，但其中一組的 Agent 能使用語意搜尋，而另一組則完全仰賴像 grep 這類傳統搜尋工具。我們觀察了兩個指標：

• 程式碼留存率（Code Retention）：由表現良好的 Agent 所撰寫的程式碼，更有可能留存在使用者的程式碼庫中。我們觀察到在支援語意搜尋時，Agent 程式碼留存率提升了 0.3%。在包含 1,000 個檔案以上的大型程式碼庫中，這個提升幅度來到 2.6%。

• 不滿意的使用者請求（Dissatisfied User Requests）：由表現良好的 Agent 所撰寫的程式碼，不需要後續追問或更正。我們觀察到在無法使用語意搜尋時，不滿意的後續使用者請求增加了 2.2%。

在這裡的效果幅度較小，因為 A/B 測試是針對所有發給 Agent 的查詢進行，而並非所有請求都需要進行搜尋。

#自訂檢索模型

支撐這些成果的其中一個關鍵元件是我們的自訂 embedding 模型。我們的方法是使用 Agent 工作階段作為訓練資料：當一個 Agent 在處理任務時，它會在找到正確程式碼之前進行多次搜尋並開啟多個檔案。透過分析這些操作軌跡，我們可以事後看出，在對話較早階段本該被檢索出來的內容是什麼。

我們將這些軌跡提供給 LLM，讓它在每個步驟中排序哪些內容會最有幫助。接著，我們訓練 embedding 模型，使其相似度分數與這些由 LLM 產生的排序對齊。這就形成一個回饋迴圈，讓模型能從 Agent 實際完成程式設計任務的方式中學習，而不是只依賴一般性的程式碼相似度。

#結論

語意搜尋目前是達成最佳效果所不可或缺的，特別是在大型程式碼庫中。

我們的代理大量使用 grep 搭配語意搜尋，而這兩者的結合能帶來最好的結果。隨著模型持續改進，我們也會不斷測試並評估配備給代理的所有工具。