ディスカッション (24件)
ベンチマーク(TerminalBench)のランキング上位を目指して、自律的に最適化を行うエージェントパイプラインを実験していました。10タスクのサブセットで試したところ、パフォーマンスが約30%から約90%まで向上したのです。この仕組みがうまく機能したので、「ベンチマークだけでなく、普段のチャットでもこの『振り返りと書き換え』のプロセスを継続的に回せないか?」と考えました。
仕組み
- ローカルLLMとのやり取りはすべて小さなプロキシを経由してログに記録されます。
autoswarm reflectコマンドを実行すると、モデル自身がそのログをレビューし、具体的な教訓を抽出してskills.yamlに書き込みます。- 抽出された教訓は、次回のチャットからシステムプロンプトへ自動的に注入されます。
実行方法(LM Studioの場合)
- LM Studioのローカルサーバーを起動し、モデルをロードします。
- 以下のコマンドを実行してください。
pip install -e .
autoswarm doctor # LM Studioに接続できるか確認
autoswarm start # 上流モデルを自動検出し、8080ポートで待機
自己最適化エージェントという考え方には非常に可能性を感じており、もっと大きな発見があるはずだと確信しています。まだ趣味レベルの実験的なプロジェクトですが、ぜひ皆さんのフィードバックをいただけると嬉しいです!
リンク: https://github.com/arteemg/autoswarm
現在も開発を続けていますので、興味を持っていただけたらぜひリポジトリのスターをお願いします!
このアイデアとUI、かなりいいね!後で見てみる。ちなみにリポジトリの改善には、監視なしでこのスキル を使うのがかなり役立つよ。開発中の注意書きはあるけど、とりあえずスターを付けてチェックさせてもらうね!
面白いアイデアだね!この文脈でもう少し改良できそうな点があるかも。すべてのスキルがグローバルに適切とは限らないよね。リフレクションの結果をグローバルスキルにするか、プロジェクト単位のスコープにするか、あるいはagents.mdの変更、ツール、MCPサーバーなどに応用できるようにすれば、汎用性が高まってより良い結果が得られるんじゃないかな。個人的な意見だけど、既存のセッションを振り返って長期的なメリットを抽出するような「スキルそれ自体」としてうまく機能するのかも気になる。自分のpi agent環境でも何か試してみるよ。ありがとう!
それだとプロンプトがかなり肥大化しない?自己修正のアクションを保存するWiki形式のメモリシステムみたいな他の選択肢もあるよね。LLMがWikiから関連するケースを検索してその知識を使うみたいな。自分はRAG構成でやり取りから学習する似たシステムを使ってる。RAGのDBをそのままメモリの保存場所にして、サクッと取り出せるようにしてるんだ(RAG本来の使い方だしね!)。メモリはシンプルなテキストファイルとしてフォルダに同期させてるから、不要になったものを簡単にチェックして削除できるよ。
Qwen 35bや27bみたいなモデルを複数インスタンス動かすには、どんなハードウェアを使ってるの?あと、単一エージェントに必要な最小限のコンテキストサイズはどれくらい?
質問ありがとう!今のところAutoSwarmは複数のモデルコピーを読み込む仕組みにはなってないんだ。単一の上流LLMを呼び出す形。オンラインプロキシが、過去のチャットから学習した「スキルブック」を注入するだけ。「スワーム(群れ)」が登場するのはベンチマークモードの時だけで、そこではメタエージェントがエージェントの役割(プランナー、エグゼキューターなど)のパイプラインを構築して、同じエンドポイントを共有しながらベンチマークスコアを競うんだ。ハードウェアとしては、27B/32BのQ4(約20GB)を単一の24GB GPUや32GB以上のMacで動かせれば十分だよ。コンテキストの最低制限もないし、4k以上あれば何でも動くよ。
クールなアイデアだけど、「学んだ教訓を将来のチャットのシステムプロンプトに自動注入する」っていう仕組みは、今後のコンテキストを圧迫しそうな気がする。
このアイデアの実装は何度か見たことあるけど、どれも最終的にはコンテキストウィンドウを使いすぎてしまうっていう同じ問題に悩まされることになるんだよね。
AutoSwarmにはそれ用のガードレールが2つあるんだ。スキルブックの上限を30エントリに固定していることと、判断プロセスで冗長なスキルを積極的に削除するリフレクションパスがあること。だから、どれだけ動かし続けても注入されるブロックはだいたい1~2kトークンで一定に保たれるよ。
u/Rude_Substance_8904 同感だけど、コンテキスト以外にもキャッシュヒット率を考慮する必要があるよ。その場しのぎの調整をすると、基本的にプリフィルキャッシュが無効化されちゃうからね。10万トークン以上まで積み上がった長いセッションやマルチターンのセッションを想像してみて。システムが再処理を走らせることになるし、言い換えれば、10万トークン分(+最新メッセージの新しいトークン分)のプロンプトを即座に処理するか、入力を再処理するのに長い時間を費やす羽目になるよ。
いい仕事だね、クールなアイデアだと思う。
ありがとう!
ログからスキルを抽出するのは面白いけど、教訓が永続化される前にレビューや有効期限の設定がほしいかな。自己改善って、下手すると悪い習慣をすぐに定着させちゃうから。
確かに。モデルが小さくて(賢くなくて)あればあるほど重要だね。
いい指摘だね。手動レビューを導入するのもありかも。ユーザーが手動でリフレクションをトリガーする現行バージョンならうまく機能しそう。ただ、ロードマップとしてはループを完全に自律化させようとしてたから、手動レビューだと時間がかかってユーザーの摩擦になるかもしれないね……。
llama.cppサーバーはデフォルトで8080ポートを使うけど、他にも同じポートを使うソフトは山ほどあるよ。別のデフォルトポートを選んで、8080でモデルが提供されていないか確認するようにしたほうがいいかも。
いいアドバイスをありがとう!
いつか突き止めてやる。なぜ流行りのアプリはどれもポートに8080や8000を使うのか。Claudeのお気に入り?ヒトラー関連の88?さあな。
80がデフォルトのhttpポートで、そこから8080(Apache Tomcatとか)や8000(Djangoとか)に派生したんだよ。AIが登場するよりずっと前の話。
あれは真面目な推測というより皮肉だよ。LLMの学習データがそうさせるんだろうね。
スコアリングの部分をどう実装してるか分からないけど、ローカルの小規模なLLMは位置的なバイアスが強い(最初の方の回答を高く評価しがちなど)ことが多いんだよね。なので、順序をランダム化したり、最低でも4つの選択肢を与えたり、複数回実行したりして「真の」スコアリングを得るようにする必要があるよ。
ついでに、みんなが普段どうやってローカルLLMを動かしてるかも知りたい!使ってるツール(Ollama、LM Studioとか)や、どんなモードで使ってるか(LM StudioならGUIのままか、サーバーを立てるかとか)気になってる。次に何をサポートすべきか優先順位を決めるためにユースケースを集めてるんだ。よろしく!🙌
Hermes agentで動くかな?オーバーヘッドはどれくらい?
このUI最高じゃん(笑)