替 Claude Code 加語意搜尋的實測

概要

• Claude Code 預設靠 grepKuba 提到 Boris 說過，早期版本用過本地向量資料庫做語意搜尋，後來發現 agentic search（用 grep 翻檔案系統）效果更好也更簡單。Cursor 則仍把程式碼索引進 Turbopuffer。
• embedding 是快取下來的運算grep 式搜尋每個 session、每個 agent 都得重做一次，Kuba 舉的例子是 6,000 個 token；語意搜尋是先花一次切塊、embed、建索引的成本，之後查詢就能直接拿到需要的程式碼片段。
• TurboGrep 是 Turbopuffer 做的 CLI用一個解析程式碼的函式庫走過程式庫、切塊，以 Voyage 的 code 模型 embed 後上傳到 Turbopuffer，讓 Claude Code 透過 tpuf search 工具來查。
• 精準率從 65% 升到 87%測試用 ContextBench，baseline 的 Claude Code 精準率是 65%，換算下來每三次讀檔就有一次白讀；加上視窗化讀取與語意搜尋後，是每八次一次。
• 召回率沒有跟著變好預設的 Claude Code 檔案召回率反而最高，另外兩種條件差不多，部分任務甚至下降。拆開看，語意搜尋適合找行為相近但關鍵字不同的檔案，grep 則適合追 import、關鍵字一兩次就命中的任務。
• Kuba 的結論Claude Code 是為 grep 打造的，語意搜尋對它只是外加工具，不像 Cursor 的 Composer 模型把它當內建工具；長期贏家會是提供輕量工具、把龐大 context 縮成對的那一小塊的人。

原話

• “this is also due to the fact that Cloud Code by default is really exploratory. It loves to read as much as it can and tries to read everything”

  這也是因為 Claude Code 預設非常愛探索，能讀多少就讀多少

  ▶ 06:50

• “Cloud Code, one in every three file reads, is actually just a completely wasted file.”

  Claude Code 每三次讀檔，就有一次是完全白讀的檔案

  ▶ 07:07

• “And this kind of proves certain tasks require different types of tools.”

  這也印證了不同的任務需要不同類型的工具

  ▶ 08:44

• “we kind of like add as an extra tool and it's like hey like here's this cool tool you probably should use it sometimes”

  我們只是把它當成額外的工具丟進去，跟它說這個工具不錯，你有時候應該用

  ▶ 10:06

• “the people that provide these, like, easy tools to shrink down these billion context windows into the right million will win in the long term.”

  提供簡單工具，把十億等級的 context 縮到對的百萬等級的人，長期會贏

  ▶ 10:42

延伸

• Cursor 的 A/B 測試數字（2.6%、2.2%）看起來小，Kuba 說是因為不是每個查詢都用得到語意搜尋，Cursor 的部落格也這樣說明。
• 限制每次只讀 50 行，是因為整份讀上千行的檔案時雜訊太大，三種條件比不出差異。
• Kuba 說自己一次同時跑三個 agent，grep 式搜尋每個 agent 都得重來一次，事先索引的成本長期下來就划算。