JetBrainsが語る、セマンティックコード検索のRAGパイプライン構築記
Building a RAG Pipeline for Semantic Code Search
JetBrainsが、LLMエージェントに正確で引用可能なコードの根拠を提供するRAGパイプライン「Air Context」の構築記を公開した。キーワード検索やgrepでは意味に基づく検索ができないため、コードをAST解析して構造を保ちながらチャンク化し、ベクトル化する。固定長分割では無関係なコードが混ざるため、言語ごとの構文を理解したスマートなチャンク化が重要だと説く。さらに、数百万チャンクのベクトルを扱うための次元数と精度のトレードオフにも踏み込む。
エージェントがセッショントークンの更新箇所を探すとき、コードに都合よく「refresh」という単語が含まれていることは期待できない。
- keeda
こういうのはコーディングエージェントの品質を上げる鍵になると思う。多くの人が観察している非常に一般的な問題（おそらく最大の問題）は、エージェントが大量の重複した冗長なコードを生成しがちだということだ。同じ目的の些細なバリエーションに対応するために、複数の抽象化、メソッド、クラス、データ構造などを作ってしまう…時には同じファイル内でさえ！
私の理論では、これはこれらのモデルが与えられたタスクを実行する際に持つ一種の「トンネル視野」によるものだ。なぜなら、会社に新しく入ったエンジニアも、その土地勘を学び、似たような問題が他所で解決済みだと気づくまでは同じことをするからだ。
以前の仕事で、私のチームは社内のマルチリポジトリコード検索ツールを担当していた。それは群を抜いて最も人気のある社内ツールで、後に別のチームが同様のセマンティック検索機能を追加した。とてもワクワクしたが、実際にどう機能するかを見る前に私は退職してしまった。
つまり、キーワード検索をして、かなりの作業を要する主要な機能が必要かどうかを探ったり、自分のリポジトリにコードが存在しない抽象化に遭遇してそれについてもっと知りたいときに調べたりするだろう。しかし、フロー状態で小さな抽象化、たとえばクラスやユーティリティメソッドを発明しているときは、必ずしもそれを検索しようとは思わない。さらに悪いことに、たとえ検索しようとしても、効果的に検索できない。なぜなら、似たようなものが微妙に異なる命名や用語、あるいはキーワード検索では見逃すタイポで存在しているかもしれないからだ。予想通り、sc […]
- duhhhhh1212
https://www.pangram.com/history/c901e80e-9cb7-46e4-bf10-7348...
最初の半分は人間が書いたのだから、時間を無駄にするなとは言いたくない。著者たちへの質問：あなたたちはただ書くのに飽きて「もういいや、残りはLLMに仕上げさせよう」と言ったのか？それとも、一人がLLMを使って後半を書き、もう一人が自分の言葉で書いたのか？
- simianwords
またかよ、業界はほぼRAGを見限った。実際、grepがRAGと同じくらいうまく機能しないケースはほとんど見たことがない。