Semble: AIエージェント向けコード検索の最適化（トークン削減率98%）

For developers building AI coding agents, the "grep-and-read" cycle is a notorious bottleneck. When an agent needs to understand a codebase, it typically greps for a keyword, identifies a file, and then reads the entire file into its context window. This process is not only slow but incredibly wasteful, often consuming thousands of tokens on irrelevant code just to find a single function definition.

Semble はこのサイクルを打破するために設計されたコード検索ライブラリです。エージェントに自然言語およびセマンティッククエリを実行させ、最も関連性の高いコードチャンクだけを返すことで、従来のgrepベースの探索に比べてトークン使用量を最大98%削減できると主張しています。

Sembleのアーキテクチャ

Unlike heavyweight transformer-based search engines, Semble is designed for speed and local execution. It runs entirely on the CPU with no requirement for GPUs, API keys, or external services.

仕組み

Sembleはハイブリッドリトリーバル戦略を採用し、精度と再現率の両方を確保します：

  1. Code-Aware Chunking: Chonkie ライブラリを使用し、Sembleはコードの論理構造を尊重したチャンクにファイルを分割します。
  2. Hybrid Retrieval: 2つの補完的な手法を組み合わせます：
    • Semantic Search: 静的な Model2Vec 埋め込み（potion-code-16M モデル経由）を利用し、概念的な類似性を測ります。
    • Lexical Search: 識別子やAPI名の完全一致検索に BM25 を使用します。
  3. Reciprocal Rank Fusion (RRF): 両リトリーバーからの結果を融合し、統一されたランキングを作成します。
  4. Code-Aware Reranking: 最終結果は以下のような複数のシグナルを用いて再ランク付けされます：
    • Adaptive Weighting: シンボル的なクエリ（例: getUserById）はレキシカルマッチを優先し、自然言語クエリはバランスを保ちます。
    • Definition Boosts: クラスや関数を定義するチャンクは、単に参照するだけのチャンクよりも高くランク付けされます。
    • Identifier Stemming: クエリトークンはステミングされ、parseConfig や ConfigParser のようなバリエーションにマッチします。
    • Noise Penalties: テストファイル、レガシーシム、宣言スタブは下位にランク付けされ、正規の実装が優先的に表示されます。

パフォーマンスとベンチマーク

Sembleの主な価値提案は、速度と精度の両立です。プロジェクトのベンチマークによると、NDCG@10 が 0.854 を達成しており、これははるかに大規模なトランスフォーマーモデル（例: CodeRankEmbed Hybrid）とほぼ同等ですが、レイテンシは劇的に低くなっています。

  • Indexing Speed: 平均的なリポジトリは約250msでインデックス化できます。
  • Query Latency: クエリは通常約1.5msで解決します。
  • Token Efficiency: プロジェクトは、Sembleがわずか2kトークンで94%のリコールを達成できると報告しています。一方、grep+readアプローチでは85%のリコールを得るために100kのコンテキストウィンドウが必要です。

統合とワークフロー

Sembleは最新のエージェントハーネス向けに「ドロップイン」ツールとして設計されています。主に2つの方法で統合できます：

1. Model Context Protocol (MCP) サーバー

MCP（Claude Code、Cursor、Codex など）をサポートするエージェント向けに、Sembleはサーバーとして実行できます。これによりエージェントは search と find_related ツールを直接呼び出せます。リポジトリはオンデマンドでクローンされインデックス化され、ローカルパスは自動再インデックスのために監視されます。

2. Bash 統合

サブエージェントや CLI ベースのハーネス向けには、Semble を AGENTS.md または CLAUDE.md に追加できます。これによりエージェントは grep に依存せず、semble search "query" ./path を使用するよう指示されます。

コミュニティの視点と批判的分析

ベンチマークは印象的ですが、Hacker News コミュニティはエージェントワークフローにおけるセマンティック検索の実用化に関していくつかの重要な指摘を行っています。

「信頼」問題

大きな懸念は、LLM がセマンティック検索ツールの結果を実際に信頼できるかどうかです。あるユーザー（@jerezzprime）の指摘によれば、多くのモデルは grep 用に強く RL 調整されています。モデルがセマンティック結果を信頼しない場合、依然として grep を実行したりファイルを再読したりし、トークン削減効果が無効になる可能性があります。

確率的検索 vs. 決定的検索

grep が決定的であるのに対し、Semble は確率的です。小規模な埋め込みモデルが、文字列検索で即座に見つかるような重要で曖昧な識別子を見逃す可能性があると懸念するユーザーもいます。

「認知的欠損」仮説

より哲学的な批判として、"ショートカット" ツールを提供することでエージェントの認知能力が低下する可能性が指摘されています。tree と grep を用いてコードベースを探索する能力はエージェントの推論プロセスの核心であり、これをブラックボックスの検索ツールに置き換えると、長期的なタスクにおける「展開可能なインテリジェンス」が全体としてマイナスになると主張する声もあります。

実世界でのテスト

これらの批判にもかかわらず、ユーザーの中には肯定的な結果を報告する者もいます。あるユーザー（@aadishv）は並行テストを実施し、非 Semble バージョンは時に詳細だったものの、Semble バージョンは特定のトレースタスクにおいて一貫してコンテキスト効率が高く、コスト効果も優れていることが分かりました。

結論

Semble は「エージェントネイティブ」なコード検索への転換を示しています。ファイル全体を読むという高コストで不正確なプロセスから脱却することで、エージェントははるかに小さなコンテキストフットプリントで動作できます。確率的検索が grep の決定的性質を完全に置き換えられるかどうかの議論は続いていますが、トークンオーバーヘッドの大幅な削減は、AI 主導の開発をスケールさせるすべての人にとって Semble を魅力的なツールにしています。

Sources