HN🔥 103
💬 54

【LLMコスト削減術】CLI出力からノイズを除去してトークン消費を91.8%削減するツール「lowfat」

zdkaster
1日前

ディスカッション (11件)

0
zdkasterOP🔥 103
1日前

Hacker Newsの皆さん、興味を持っていただけるか分かりませんが、CLIの冗長な出力をフィルタリングしてLLMのトークン消費を大幅に削減する自作ツール「lowfat」を紹介させてください。シングルバイナリで動作し、エージェントフックやシェルラッパーとして利用可能です。コマンドごとにフィルタをカスタマイズできるプラグインシステムも搭載しています。エージェントにとって、kubectl get -o yamlの全量や1万行ものダンプデータは意思決定に不要です。lowfatはそれらの間に入り込み、ノイズを取り除いて必要な情報だけを抽出します。2ヶ月間実際に運用した結果がこちらです。(以下、集計データ表)。私の環境での限定的な利用例ですが、業務でBedrockのトークン制限に引っかかることもなくなり、実用性は十分です。なぜ既存ツールを使わないのかという点ですが、コア機能を軽量に保ちつつプラグインで拡張可能にすること、社内ツールなど公開されていないCLIにも対応すること、テレメトリを一切含まないローカルファースト設計であること、そしてUNIXライクなパイプライン操作を重視したためです。フィルタの調整も可能で、エージェントに必要な情報を削りすぎないよう制御できます。GitHubはこちら(https://github.com/zdk/lowfat )。フィードバックや質問は大歓迎です!

1
devdoc83
1日前

エージェントが必要とする正確なスタックトレースを削ぎ落としてしまうリスクにはどう対処してる?そこがこのツールの難しいトレードオフに思えるんだよね。

2
alex7o
1日前

rtkみたいに既に高速でRust製である既存ツールとの詳しい比較がほしいかな。前のコメントでも指摘されてたけど、rtkの既知の問題として、LLMが必要(あるいは期待)している情報を削ってしまって、かえって手間が増えるケースがあるっていう話だし。

3
threecheese
1日前

ドキュメントにこれが「何」をするのかという例がなくて、「どう」動くかという説明しかないのが残念。しかもアプリの挙動じゃなくてコードベース上の話だけだし。

あると嬉しいのは:

  • フィルタリング対象のテキスト例と、なぜそれが重要なのか
  • 不要なコンテキストをどう削除するのかを示すランタイムのデータフロー図
4
fcanesin
1日前

巨大なCLI出力をそのままLLMに渡すのを拒否して、読み込む前に結果をフィルタリングするよう促す小さなツールを作ればいいんじゃないかな。そうすればLLM自身にフィルタリングを考えさせて書かせることになるし、そっちの方がうまくいきそう。

5
itsdesmond
1日前

こういうツールを表現する用語って決まってるの?LLMの挙動を特定の変換で制御する小規模なユーティリティを何て呼べばいいかな。会話の中では「CLI filter」で通じるけど、検索するとなるとキーワードが一般的すぎてあまりヒットしないんだよね。

6
jemmyw
1日前

rtxとかlean-ctxを試したけど、こういうツールって助けになるどころかエージェントを混乱させるだけな気がする。エージェントがツールを回避しようとして余計に呼び出し回数が増えてしまったら、トークンを節約した意味がなくなっちゃうし。

コスト節約については分からないけど、コンテキストサイズを小さく保ちたいなら、サブエージェントを使って高次の会話をクリーンに保つやり方の方がずっと良い結果が出てる。

7
wood_spirit
1日前

自分もLLMラッパーのハーネスを自作してて、同じようなこと+αの工夫をしてる。MCPはそんなに入れてないけど、search_mcpとload_mcpツール(あとsearch_skills)を入れてるから、LLMは必要な時に必要なものを、ベースとなるコンテキストを肥大化させずに見つけられる。LLMはこれらを使うのがすごく上手いよ。あと、思考プロセスを最終出力とは別にコンテキストに記録できるwaypointツールもある。会話に呼び出せるエキスパートを探すsearch_expert機能なんかも検討中。いろいろやってるんだ。

あとコツとしては、レスポンスを切り詰めた時に「全文は/tmp/whereever.txtにあるよ」と伝えておくと、LLMが自前でツールを使って読み込みに行ってくれるから、わざわざ大きなツール呼び出しをやり直さなくて済むよ。

8
cityofdelusion
1日前

面白いプロジェクトだけど、こういうのや例の「caveman mode」みたいな、扇情的に不正確なタイトルには警戒しちゃうな。トークンの91%を削減してるわけじゃなくて、あくまで特定のユーザーケースでのCLI生の出力トークンが91%減っただけ。こういう主張が不正確なままバズるのが嫌だから細かいことを言ってるんだ。

まともなベンチマークなら、同じプロンプトのサンプルを大量に用意して、ツールあり・なしで特定のハーネスに対して比較すべき。アムダールの法則を当てはめれば、タイトルが示唆するような全体で91%のトークン削減なんてありえないから。

非テック系の企業で働いてるんだけど、こういうのが中身を理解されないままバズり続けるのが本当に困る。エンジニアリングはどこへやら、貨物崇拝のような魔法の呪文ばかりが流行ってる。

9
rahulyc
約24時間前

いいアイデアだね。安価なローカルモデルに出力を投げて「重要」な部分だけ抽出させてからメインのモデルに渡すという手法はどうだろう?時間は余分にかかるけど、より大きなモデルでのトークン節約を考えれば価値はあるかも。

10
clutter55561
約21時間前

無駄な情報を削るツールは良さそうに思えるけど、LLMの推論に悪影響が出るんじゃないかと疑ってる。

LLMはインターネット上の典型的な「全部載せ」の出力で学習してるから、これまで見たこともないような少し加工されたレスポンスをいきなり渡されても戸惑うはず。

長期的には、これで本当にトークンを節約できるのかな?