BM25でCodexの候補探索を最適化し、約29.2%（約30%）のトークン消費削減を実験で示す技術記事。
”その中でも、特に多くのトークンを消費しているのが、「ファイルの検索」です。 ”
音ゲーを使用してトークン消費を削減!?、と思ったらそれはBM98だった。
後で試す
とりあえずMCPサーバにしてみたけど、本当に効くかはしらん＼(^o^)／https://github.com/toaruR/mcp-server-bm25-code-search
cocoindex-codeと比べてどうなんだろう。
この手のやつ、本当に効果があるなら、あるいは弊害が少ないなら、本家がとっくの昔に採用してるんだよね。Serena..
BMI25の脂質を燃やしてCodexトークン消費を30%抑えるのか、肉体労働かな？と思った自分が通りますよ
ついでに https://github.com/rtk-ai/rtk と組み合わせたらもっと減るんじゃないか？
コメントはともかくソースコードのついてはBM25合ってないから品質下がりそう。それで30%しか変わらないなら使わないな。
情報検索に使われるBM25が生まれたのは1990年代だけど，あまりにも安くて強いので費用対効果が合わず今も現役で使われ続けているが，その強さが今も…
トークン減らすものはツール色々あるけど、成果物の品質や精度がどうなのか検証してるのはあんまりないな。ただ減ればいいだけではないんだよな。結果的に重要な部分が削られたり手戻りあると意味がない。
基本的にそこ研究しても、彼らのビジネスモデルを崩すだけだから誰も得しないよ。一番簡単なのは古いモデルを使う事。でも使い物に何ないでしょ？
ファイル検索が弱くそれにトークンが使われているので検索を効率化したという話
ボクの毛玉より賢い仕組みにゃ！トークン節約して、その分撫でてほしいにゃ。
BMI25はちょっと痩せたほうがいいのでは？って素で思ってしまったので疲れてる
コード検索にBM25を使用するならコードをElasticsearchに入れといても同じことできるよね。何ならベクトル検索も併用できるよね／スネークケースとキャメルケースの分割はどうやったんだろ。検索処理周りが気になる。
“トークン消費の多い「ファイルの検索」、単純なキーワード検索なので検索効率が悪い。BM25インデックスを27秒で構築することで関連度の高いコード断片からCodexへ返す仕組みにすると3割削減”
検索に使うインデックス回り、あらかじめ軽量安価なLLMで上手く処理をしておくと、いい感じにできる気がする。Graphの実装例は知ってるけど、もうちょいインテリジェントに行ける気がする。誰かやってみて欲しい
よくわかんないけど、自前で作るよりも、gitやらgithub自体が提供したら良いと思うよ
先祖返り感がある
リポジトリのコードとドキュメント(設計書)の整理しておけば、一般的なアプリだったらBM25を使って検索するより確実に情報を辿れると思うけど、複雑なプロジェクトだったら有効なのかな
7,536ファイルのコードベースでCodexの探索を比較。BM25探索は全12問正解を維持し、総トークンを29.2%削減。動作時間中央値も50.8秒→30.0秒。
BM25を使用してCodexのトークンの消費を30%抑える
BM25でCodexの候補探索を最適化し、約29.2%（約30%）のトークン消費削減を実験で示す技術記事。
”その中でも、特に多くのトークンを消費しているのが、「ファイルの検索」です。 ”
音ゲーを使用してトークン消費を削減!?、と思ったらそれはBM98だった。
後で試す
とりあえずMCPサーバにしてみたけど、本当に効くかはしらん＼(^o^)／https://github.com/toaruR/mcp-server-bm25-code-search
cocoindex-codeと比べてどうなんだろう。
この手のやつ、本当に効果があるなら、あるいは弊害が少ないなら、本家がとっくの昔に採用してるんだよね。Serena..
BMI25の脂質を燃やしてCodexトークン消費を30%抑えるのか、肉体労働かな？と思った自分が通りますよ
ついでに https://github.com/rtk-ai/rtk と組み合わせたらもっと減るんじゃないか？
コメントはともかくソースコードのついてはBM25合ってないから品質下がりそう。それで30%しか変わらないなら使わないな。
情報検索に使われるBM25が生まれたのは1990年代だけど，あまりにも安くて強いので費用対効果が合わず今も現役で使われ続けているが，その強さが今も…
トークン減らすものはツール色々あるけど、成果物の品質や精度がどうなのか検証してるのはあんまりないな。ただ減ればいいだけではないんだよな。結果的に重要な部分が削られたり手戻りあると意味がない。
基本的にそこ研究しても、彼らのビジネスモデルを崩すだけだから誰も得しないよ。一番簡単なのは古いモデルを使う事。でも使い物に何ないでしょ？
ファイル検索が弱くそれにトークンが使われているので検索を効率化したという話
ボクの毛玉より賢い仕組みにゃ！トークン節約して、その分撫でてほしいにゃ。
BMI25はちょっと痩せたほうがいいのでは？って素で思ってしまったので疲れてる
コード検索にBM25を使用するならコードをElasticsearchに入れといても同じことできるよね。何ならベクトル検索も併用できるよね／スネークケースとキャメルケースの分割はどうやったんだろ。検索処理周りが気になる。
“トークン消費の多い「ファイルの検索」、単純なキーワード検索なので検索効率が悪い。BM25インデックスを27秒で構築することで関連度の高いコード断片からCodexへ返す仕組みにすると3割削減”
検索に使うインデックス回り、あらかじめ軽量安価なLLMで上手く処理をしておくと、いい感じにできる気がする。Graphの実装例は知ってるけど、もうちょいインテリジェントに行ける気がする。誰かやってみて欲しい
よくわかんないけど、自前で作るよりも、gitやらgithub自体が提供したら良いと思うよ
先祖返り感がある
リポジトリのコードとドキュメント(設計書)の整理しておけば、一般的なアプリだったらBM25を使って検索するより確実に情報を辿れると思うけど、複雑なプロジェクトだったら有効なのかな
7,536ファイルのコードベースでCodexの探索を比較。BM25探索は全12問正解を維持し、総トークンを29.2%削減。動作時間中央値も50.8秒→30.0秒。