リポジトリ全体の把握 in ai coding agent
littlemexGraph
training fw
リポジトリに RAG して効率的な AI coding agent 化したい。
littlemex
chroma は vectorstore であり、faiss はライブラリ、ただ結果は似たようなもん。
スクリプトでファイル内の情報を一ファイルにまとめてドンして LLM にぶっこむ荒業を紹介してる。
あとは Dify で RAG せよ。って感じの内容。
うーん、、もうすこしうまくできんかなぁ。
littlemex
上と似てるけどもう少しリッチなつくり、rust なので早そう。
littlemex
**/*.py だけ抽出などできる
littlemexollama
コード整理の段階では ollama 使うとかやりたい
littlemex
この repomix mcp 有用
littlemex設計
思想
- 早いは正義、コードベースが大規模な場合でも早いことを重視
- 長期で考えると RAG が最適なのかは不明、1 shot か強化学習ベースがいいのかも
ソリューション
短期
- ローカルで爆速に動く、コードスコープを狭めて使う RAG ソリューション
- 1shot ぶっ込み
長期
- しっかりインフラを作り込んだコード全体に対しての RAG ソリューション
- 強化学習、Graph を作らせる学習など
情報整理
RAG
- 埋め込みベクトル
- ベクトルストア
- ファイルシステム（ローカル）
- OpenSearch
強化学習
- クラス・メソッド構造を抽出してグラフ DB にぶっ込むことに特化したモデル
littlemex学習
littlemex「リポジトリ内の各ファイルに対してqdrant-store-memoryというMCPツールを呼び出して、後で検索できるようにしてください」
littlemex最近、Windsurf のコンテキスト検索が他の製品よりも優れているという話が盛んに聞かれます。私が目にした反論の 1 つは、すべての製品が「コードベースをインデックス化する」というものです。
しかし、コードのインデックス化はコンテキスト検索ではありません。必要ではありますが、十分ではありません。
最良の結果を得るために私たちが裏で行っていることを少しお話ししたいと思います。
インデックス化と埋め込み検索は、RAG の基本的な手法です。ちなみに、この手法でも、これをより効果的にしたり、より効果的にしたりするアプローチがあります。私たちが行っていることの 1 つは、AST でコードを解析し、意味的に意味のある境界に沿ってチャンク化することです。ランダムなコード ブロックではありません。つまり、コード チャンクが取得されると、それは完全な関数またはクラスであり、連続したコードの任意のブロックではありません。
しかし、埋め込み検索は、コードベースのサイズが大きくなるにつれて、検索ヒューリスティックとして信頼できなくなります。代わりに、grep/ファイル検索、ナレッジ グラフ ベースの検索などの手法の組み合わせに頼る必要があります。これらのヒューリスティックすべてでは、取得されたコンテキストを関連性の順にランク付けする再ランク付け手順も必要になります。内部では LLM ベースの再ランク付けを使用しています。
「Varun、秘密のソースを漏らしてしまったの?」
いいえ。これはすべてわかっています。他の製品がこれを実行しない理由は単純です。レイテンシーです。この多次元検索には多くの計算が必要で、時間がかかります。Windsurf がこれを実行できるのは、最高の GPU インフラストラクチャの構築に何年も投資してきたからです。結局のところ、私たちは文字通り Exafunction という GPU ワークロード最適化会社としてスタートしたので、このことについては多少の知識があります 🙂
これで誤解が解消され、小規模なテスト コードベースで他の製品と並べてテストしているユーザーが同等の結果を得ている理由が説明できれば幸いです。より大きなリポジトリで試してみれば、違いが明らかになります。
littlemexbit.ly/smhp-slurm-workshop
bit.ly/smhp-eks-workshop
bit.ly/aws-do-hyperpod
bit.ly/do-eks
www.hpcworkshops.com
bit.ly/awsome-dt
bit.ly/awsome-inf
littlemexshort term/long term memory