ディスカッション (11件)
AIエージェントが自力でコードを書き、スキルとして蓄積していく「自己生成スキル」。一見すると画期的な進化に思えますが、最新の研究によると「実はほとんど役に立っていない」という衝撃の事実が明らかになりました。自律型AI開発の常識を覆すかもしれない、非常に興味深い調査結果です。
一般的なルールとして、LLMで自動化するレイヤーを増やせば増やすほど、後のレイヤーほどひどくなるみたいだね。LLMの出力を別のLLMへの入力としてパイプしてると、すぐボロが出て収集がつかなくなるのがわかる。アイデアと、だいたいの実装プランがあれば、コーディングをLLMにやらせて保守しやすい良いものを作ることはできる。基本は自分次第だ。そこから1つレイヤーを剥いで、アイデアはあるけど実装プランからLLMに考えさせて、実装もやらせる。そうすると理想とは程遠いものになる。さらにレイヤーを減らして、全部LLMに任せると、もうめちゃくちゃだよ。
「自己生成スキル:スキルは提供されないが、タスクを解く前に関連する手続き的知識を生成するようにエージェントにプロンプトを出す。これでLLMの潜在的なドメイン知識の影響を切り分ける」... これは有用な結果だけど、みんなが「LLMがスキルを生成する」って時に考えてるのと必ずしも一致しないのは注意が必要だね。苦労して何かをやり遂げた教訓をLLMにスキルとして書き出させる方が一般的だし(そう願いたい)、この論文が言ってることとは全然違う。ニュースとかSNSの有名アカウントは、この辺を慎重に報じてくれるだろうから、誰も勘違いしないだろうね(皮肉)。
システム内の情報を拡張せずに出力を入力に回してるだけなら、エージェントに知識の裏付けなしでスキルを作らせる意味はほぼないよ。ネットでしっかりリサーチさせて、モデルが間違えがちな情報や学習データより新しい情報、あるいはデフォルトの生成結果よりも自分のワークフローに合うように情報を削ぎ落とせば、もっと便利なスキルができるはず。自分は、このアプローチをガイドするためにスキル作成時に起動するスキルを使ってるよ:https://github.com/sammcj/agentic-coding/blob/main/Skills/sk...
自己生成のドキュメントでも同じようなことを見てきたよ。LLMでコードを調べて「ベストプラクティス」やドキュメントを定義させて、とんでもないガイダンスを出す開発者がいるんだ。独自のバイアスが入っちゃうからね。開発者が怠慢すぎて、「良し」とされる箇条書きすら自分で打とうとしない。例えば、C#/.NETで、アプリケーションコードには入れるべきじゃなくて、ASP.NETでも普通不要な ConfigureAwait(false) が散りばめられたスニペットがあった。コーディングエージェントが「ライブラリ」っぽいコードを見て適用しちゃったんだ。で、誰かがそれに対してLLMを走らせて「ベストプラクティス」としてリポジトリに入れて、コンテキスト全体を汚染し始めた。PRでそのコードを見つけて、ソースを特定して削除したよ。あと、Task.Run のひどい使い方も整理しなきゃならなかった(これもC#のベストプラクティスじゃないし、挙動を理解して使うべきもの)。結局、一貫性と品質を上げるために、厳選されたベストプラクティスをコーディングエージェントに提供する新しいシステムを構築してる。自己生成のスキルや知識を使うのは、画像を入力して何も変えずにそのまま出力させる実験みたいなもんだ。n回繰り返すと、間違いなく元のものから激しく変質する。エージェントによるコーディングは未来だけど、みんなまだ適応できてない。パンチカードからアセンブリ、FORTRAN、C、JSへと進んで、そのたびに抽象化が進んできた。次の抽象化はMarkdownだ。Markdownを書いて磨き上げることに時間を投資するチームが、品質やセキュリティ、パフォーマンス、保守性を損なわずにエージェントを動かせる、より良いガードレールを作れると思う。
別に驚きもないし、的外れだね。特定のモデル向けにスキルを作る時、普通はモデル自身の潜在知識だけで作らせたりしない。そうじゃないと「行動する前に計画を立てて、ミスをしないように」って言ってるのと同じような結果になる。でも論文の著者がやったのはまさにそれ!「自己生成」と言うなら、ウェブ検索すら含めたツールへのアクセスを一切許可してないんだ。もし以下の方法で作成されたスキルをテストしてたら、もっと面白かっただろうに。A) 人間にインタビューしてスキルを作成する。B) 情報を集めるために1つ以上のディープリサーチタスクを実行する。C) それらの組み合わせ。
自分が使ってるカスタムのスキル作成スキルには、こんな内容が入ってる。「よくある落とし穴は、Claudeがタスク完了のための生成情報を詰め込んでスキルを作ってしまうこと。問題は、その生成された内容がすでにClaudeの確率空間にあるってことだ。Claudeは結局、すでに知ってることを自分に言い聞かせてるだけなんだ!代わりに、ClaudeはSKILL.mdに以下の情報だけを記録するように努めるべき:1. Claudeの学習データにないもの(リサーチ、実験、経験を通じて学んだこと)、2. 特定のコンテキストに依存するもの(今知っているが、コンテキストウィンドウがクリアされたら忘れてしまうこと)、3. 未来のClaudeと現在のClaudeを同期させるもの(未来のClaudeに望ましい動作をさせるためのガイド)。また、派生データは記録すべきじゃない。馬を水辺に連れて行くべきで、水の飲み方を教えるべきじゃない。必要なことが全てわかるソースが簡単に手に入るなら、そのソースを指し示す。すでに知っている情報や提供済みの情報から簡単に導き出せるなら、その派生データは提供しないこと」 興味がある人向けにフルバージョンはここ:https://github.com/j-r-beckett/SpeedReader/blob/main/.claude...
自己生成のスキルがマイナスの効果(-1.3pp)で、厳選されたスキルが+16.2ppっていう発見が一番面白いね。大きな差だけど、納得だ。LLMは手続き的知識を「生み出す」より「消費する」方が得意だって考えと一致する。ソフトウェアエンジニアリング(SWE)で+4.5ppっていうのは、ヘルスケアの+51.9ppに比べると怪しいくらい低い。たぶん最先端のモデルは学習データからすでに強いSWEの事前知識を持ってるから、スキルの追加価値が少ないってことだと思う。もしそうなら、スキルが最も価値を発揮するのは、まさにモデルが最も弱いドメインってことになる。それこそプロダクション環境でエージェントを投入したい場所だし、心強いね。
Claude用に持ってるスキルは全部個人の好みだし、自分のセットアップを反映させてる。自分にとって本当にうまくいく特定のセットに確率空間を狭めるための手段なんだ。
一般的に、LLMは推論を使って新しい情報を「生み出す」ことはできない、ってことを示すような結果がよく出てる。LLMが生成したスキルは役に立たないし、LLMが生成したコンテンツで学習させるとモデルが崩壊するとか。それは直感的に受け入れられてるみたいだけど、自分にはかなり驚きなんだ。学習コーパスには「膨大な」情報が含まれていて、モデルは「頭の良い初心者」レベルで動いてる。コーパスの各側面をもっと深く掘り下げれば、引き出せる洞察がもっとあるはずじゃないか。なんでこれが驚異的なことだと思われてないんだろう?
記事はいいし、フレームワークがあるのは嬉しいけど、これらが良いSWEスキルだとは思えないな。もっと、実際の技術書に基づいたこういう感じのを想像してた。https://github.com/ryanthedev/code-foundations