LLMエージェント開発でハマらないための12の鉄則！信頼性を爆上げする方法とは？
引用元：https://news.ycombinator.com/item?id=43699271
この記事マジ最高じゃん。俺も数年やってて自分なりのテイク集[0]があったんだけど、そこまでファクターって呼べるかは微妙。一番デカいのは、一番下のプランニングループを自分で持つことかな。動的なプランニングもいいけど、OODAループ（観察、判断、決定、行動）を自分で持って、解決に近づいてるか（スコアリングとか）、あるいは脱出するか（最大ループ数とか）のヒューリスティクスを持つべき。
ワークフローエンジンも組み込むと良いかも。モデルにワークフローの仕様を作らせて、そのエンジンで実行させる（ワークフローステップがモデルを呼び出すこともあり）方が、モデル内で暗黙のワークフローを維持するより良い。[0]: https://mg.dev/lessons-learned-building-ai-agents/
このガイド、マジで良いね。特に「チャットインターフェースはクソ」って意見に激しく同意。AIベースのUIはまだまだこれからだね。
DSPY[0]みたいなライブラリは、factor-2[1]にどう組み込まれるのかな？読んでたらBAMLってのが出てきたけど＞（上の例はBAMLを使ってプロンプトを生成…“
個人的には、構造化されてないデータから構造化された情報を抽出するためにプロンプトを手書きするのがマジで難しい。DSPYは今のところ良い感じ。BAMLの生のプロンプトを使ったみたいだけど、DSPY[2]の生のプロンプトについてどう思う？[0] https://dspy.ai/[1] https://github.com/humanlayer/12-factor-agents/blob/main/con...[2] https://dspy.ai/tutorials/observability/#using-inspect_histo…
なるほどねー。この件に関してはBoundary (YC W23)の人たちに賛成かな。最先端のパフォーマンスが欲しいなら、箱を開けて中身をハックする必要があるよね。
この記事https://www.chrismdp.com/beyond-prompting/ には完全には同意しないけど、パンチカード→アセンブリ→C→高級言語の比較は参考になる。いつになったら適切な抽象化ができるんだろう？LangchainとかDSPYはまだAIの「C言語」じゃないと思う（そうなる可能性はあるけど！）。今はまだ「メタルに近い」ワークベンチで、トークンを調べたり、system/user/JSONみたいな特殊トークンを並べ替えたり、ライブラリのサポートを待たずに新しいモデルの癖に動的に対応できるようにするよ。
究極のパフォーマンスを引き出すためには、一段低い抽象化レベルに降りる必要があるのはいつものこと。（例えば、10年くらい前にC言語でゲーム＋エンジンを書いて、SIMDベクトルでレンダーループを最適化した。）
でも、ほとんどのユースケースではそこまでの制御は必要ないと思うし、ツールが改善されればプロンプトは使われなくなると思う。
LangchainとDSPYは自分にはまだ合わないなー。プロンプト＋評価っていう考え方自体を見直す必要があると思う。（実は今、そういうツールを作ってるんだ！）
新しいツール楽しみにしてる！
チェックしてみたいな。
swyxのポッドキャストでnotebookLMチームの人が言ってたことだけど＞AIで本当にすごい体験を作る唯一の方法は、モデルの能力のギリギリのところを見つけて、それを常に正しく行うことだ“
だから、すごく良いもの/他のものより良いものを作るためには、できる限りの最適化をすべて取り入れることが常に役立つ。
一番すごい体験の構成要素は、LLMを関与させるのに適切なポイント、コンポーネントのオーケストレーション、そしてユーザーエクスペリエンスだと思う。
ゲームでもそうだった。プレイしててマジックを感じたゲームは、最高のハンドロールエンジンを持ったゲームじゃなかった。
プロンプトを無視できるツールはまだないし、生のプロンプトに立ち戻る必要がある時もある。プロンプトの調整がシステムの1%だけで済む未来が楽しみ。
そうそう。問題は、ツールスタック/フレームワークに組み込まれてて、その1%のケースでカスタマイズできない場合だよね。多くのツールが「カスタマイズしたいことは何でもできる」ような適切な抽象化をしようとするけど、うまくいかない場合がある。
マジそれ。すべてのインタラクションをラップすることはできないし、すべきじゃない。新しいアプローチが必要だね。
フレームワークのパターンに関する昔のブログ記事が、キャリアを通じてずっと心に残ってるんだよね。LLMも同じで、“ライブラリ”として使うのがベストだと思う。記事に書いてある理由とか、今みたいな変化の激しい時期には特にそう。でも“フレームワーク”の方がセクシーだし売りやすいから、ロックインとか追加サービスにつながるけど、そっちが宣伝されちゃうんだよなー。
これマジで良い…
“パッケージ旅行はフレームワークみたいなもん。ホテルとか食事とか全部決まってて、それに合わせるしかない。自分で旅行を計画するのはライブラリを組み合わせるみたいで、フライトとか宿とか自分で手配するから大変だけど、完全にコントロールできるんだ。”
おれが一番好きなブログ記事/プレゼンはSandi Metzの「The Wrong Abstraction」だけど、これも良いね。小さい記事なのに、かなり良いこと言ってる。
間違った抽象化より、重複の方がマシってことだね。めんどくさがらずにswitch文を書けってこと。
＞switch
うっ、ちょっと神経に触ったかも。switch文って、チームA, B, CがチームDのリポジトリにswitch(calling_service)ブロックで特殊なコードを追加する入り口になりがち。このプレゼンの意図は、コンシューマーが自分のサービスでswitchを書けるように、もっと高いレベルでfactorすることだと思う。もしコンシューマーが似たようなロジックを書いてるなら、ライブラリとかサービスに落とし込むことを考える、みたいな。
でも、それ以外は同意。
なるほどね。switch文は“自分でやるべき基本的なプログラミングのプリミティブ”っていう広いカテゴリのことだね。確かに大きなswitch文はアンチパターンになりうる。インターフェースの方が明らかに適してる場合とか。
マジかよ、これ最高じゃん。リンク集に追加しよ。
キャリア開発の面でも、フレームワーク（またはもっとヤバいプラットフォーム）に頼るより、低レベルのLLMインターフェースを学ぶ方が絶対に良い。それを学べば、プラットフォームへの移行は簡単だけど、その逆は難しい。ジュニアデベロッパーは、履歴書にフレームワークがたくさん書いてある方が有利だと思いがちだけど、逆効果なこともある。
セキュリティとか、最初からベストプラクティスが組み込まれてるのは良いけどね。特にAIは、ベストプラクティスがまだ確立されてないから、今は低レベルで色々試すのが良いと思う。フレームワークはすぐ obsoleteになるかもしれないし。
ほんとそれ。正しいインターフェースを考えようとしてるけど、すぐに決めつけちゃうんだよね。
もし正しいインターフェースがあれば、ブラックボックスを作って、必要な人が変更できるように穴とかノブをつけるはず。
間違ったインターフェースだと、ノブは役に立たないから、ボックスを開けたり、変な角度で穴に手を入れたりして、誰も予想してなかったことをやる羽目になる。
いつか正しいインターフェースができると思うけど、今はボックスをスキップして、余計なサイクルを使った方がマシ。エンジニアならforループとかswitch文くらい書けるでしょ。プロンプトを外注して、コントロールフローを手放すな。
すごく参考になるwiki、ありがとうございます。ぜひ使わせてもらいます。実は、actor model、state machine、aspect oriented programmingに基づいて、独自の“AI Agents framework”[0]を作ったんです（昨日リリースしたばかりで、HNにはまだ投稿してません）。特に5と7が好きです。
5: Unify execution state and business state
8. Own your control flow
SecAIはまさにそうで、グラフのノードにLLMの呼び出しが埋め込まれてるんです。交渉、キャンセル、stateful relationで強化されてるから、より“有機的”です。devtools（dbg, repl, svg）も重要です。最初のtech demo[1]をリリースしました。Send/Stopボタンは“Factor 6. Launch/Pause/Resume with simple APIs”そのものです。ネットワークtransparentなので、スケールも可能です。
他のフレームワークが見落としがちなのは専用の devtools だよね。PydanticAI の Logfire はマジで使いやすかった！デバッグが他のフレームワークよりずっと楽だったんだよね。[0]も見てみて。 Logfire はトレースアプリで、Jaeger とか他の Otel UI と同じようなものだよ。今回は再実装 vs 統合については触れないけど、トレースはデバッグの一つの手段に過ぎないよね。am-dbg は実行ツリーじゃなくて、状態の合意のデバッグに焦点を当ててて、SaaS アカウントもいらないんだ。ワークフローには実行ツリーで十分だけど、bot/agent は単純なワークフローじゃないからね。 terminal UI と otel 連携が良いね！今はどんなタスクに使ってるの？ ありがとう！terminal UI は重要なデザインの選択だったんだ。速くて安くて、どこでも動くからね（wasm とか ssh 経由の web とか、タッチ操作の iPhone とか）。LLM レイヤーはまだ新しいけど、個人的には web scraping に使ってるよ。でも、基盤となるワークフローエンジンは成熟してて、いろんなところで使われてるんだ。sync エンジンとか、UI とか、daemon とか、ネットワークサービスとか。複雑さ、非決定性、リトライロジックに直面した時に輝くんだ。フローがめちゃくちゃになればなるほど、効果が大きいんだよね。LLM を使って、エージェントが DSL を使って動的に自分自身を作成するようなイメージかな。LLM の良いところは、リクエストの数じゃなくて、トークンで課金されるところだよね。細部まで個別に質問して、透明性の高い（そしてデバッグ可能な）推論でフローグラフを構築できるんだ。proactive なシナリオのための API スケッチもあるよ[0]。 これはすごいね！共有してくれて本当にありがとう！ もう一つ：大規模なコストを計画すること。 そうだよね！よく見るパターンは、「最初は遅くて高価だけど、開発工数が少ないものから始めて、スピード/品質/コストのボトルネックを徐々に改善していく」って感じかな。 一貫したナラティブがあれば、原則に従いやすくなると思うな。例えば、実世界のシステムで例を示せばいいんじゃないかな。 それは良いフィードバックだね！どんなユースケースが良いと思う？ぜひコミュニティと一緒に進化させていきたいな。 実世界の agent ワークフロー（あなたの production 経験からの toy を小さくしたもの）を選んで、これらの要素がどのようにプロジェクトに組み込まれるかを示すと良いかもね。12 個の要素のシンプルさに触発されて、これらの要素を取り入れた例をもっと学びたいな。 いくつかエージェントの実例がある https://github.com/got-agents/agents にリンクしてるよ ありがとう、見てみるね その分野は経験ないから、何も提案できないや これはすごい ーー 8割は苦労して学んだよ。残りの2割は読む価値ありそう！個人的には LangGraph + pydantic schemas がうまくいってる。他のみんなは何が便利だったか知りたいな。 ＞8割は苦労して学んだって言うのが面白いね。 マジで最高のタイミング！ LLMからの型付き出力はマジで革新的！ あんまりちゃんと読んでないけど、LLMはできるだけ使わず、可能な限り決定論的なコードを使いたいな。そっちの方が予測しやすいし、運用コストも低いし、誰も簡単に同じアプリを再現できないってことになるから。 buzz word なツールは使わず、自分でツールを作って LLM と連携させたい。そうじゃないなら、誰でも同じようなソリューションをすぐに作れちゃうと思う。コントロールが大事！ コントロールと決定論は大事だよね。一番の目標は「コントロールを手放しすぎないで」ってことをみんなに納得させることだけど、二番目の目標は「ここはコントロールを手放してもいい場所だよ」って示すこと。 よっしゃ！ HN のフロントページに載ってて超嬉しい。 例外処理について気になるなー。大規模なプロダクション環境でエージェントフレームワーク使ってる人いるのかな？いない気がするけど、誰か知ってたら教えてほしい。 自分もいくつか同じこと思ってたんだよね。こういうAIアプリもっと作りたいな。今はデータアナリストやってるんだけど、会社が技術志向じゃないから、そういうの作れるってあんまり評価されないんだよね。フルタイムでこういうのやりたいな。興味ある人いたら連絡して！(US/EU) オープンソースのいいところは、好きなことできるってことだよね。それに、同じような仕事してる人と知り合うには一番いい方法だと思う。 ほとんどのプロダクション環境に導入されてる“AI Agent”って、実はそんなにagenticじゃないんだよね。一番良いのは、LLMが要所要所に組み込まれた、ちゃんと設計されたソフトウェアなんだ。 みんなエージェントに夢中だけど、99回うまく行っても1回ミスするとアウトだよね。「なんでそんなバカな間違いしたんだ？」ってなる。理由はわからない。「じゃあ、ガードレールをもっとつけよう」ってなって、結局“ワークフロー”に戻るんだよね。 「最初のエージェントを品質管理する別エージェントを置いたらどう？」 ほんとそれ。 そうだね。 もともとは、人間の指示なしにディープラーニングだけでがんを発見するAIツールが、人間の指示ありのツールより優れてたのが始まりだったと思うんだ。LLMエージェントでも、もっと性能を上げれば同じことが起きるんじゃないかって期待されてた。でも、もう限界が見えてきたよね。OpenAIとかMetaの最新リリースも、サイズは大きいけどイマイチだし、重要なことに使えるレベルには程遠い。学習データも、もう新しいものはないんじゃないかな。 ＞“常識”は、人生経験がない機械には無理なのかも ほんと、うちのPMにもこれ言いたいんだよねー このコメント、スクショしてうちのPMに送ろっと。 あとさー、「エンジニア部門半分リストラしてLLMで置き換えようとするな」ってのも追加でお願いしたいわ。 ボーナスセクションにこれ追加するPRなら喜んで受け付けるよ いやいや、そんなことしたら君のリポジトリの価値が下がるでしょ。HNのくだらないおふざけで汚したくないし。 めっちゃ同意。エージェントとか構築フレームワークとか、ほとんど時間の無駄だと思うわ。 この人わかってるね！ 12factorとは関係ないけど、こういうエージェントとかソリューションって、LLM Opsはどうやってるんだろ？ 特定のツールやフレームワークに固執しないようにしてるんだ。大事なのは構成要素を自分でコントロールすること。そうすれば、最新のLLM OpsとかLLMの監視テクニックも使えるしね。 BAMLがここにあるの見るのめっちゃ嬉しい:) BAMLに関する素晴らしい仕事だね！エージェントの構成要素としてめっちゃ気に入ってるよ。 Herokuでの経験から、これらの12の原則がどのように生まれたのか、めっちゃ興味あるし知りたいな。 すごく良くて役に立つまとめだね！ありがとう！ 誰か同じようなものを画像生成エージェント向けに作ってくれたらマジで嬉しいんだけど。安定した画像/動画生成エージェントを作ろうとしてるんだけど、マジで不安定なんだよね。 お気に入りのオープンソースのエージェント用フレームワークって何？ Pydantic AIにめっちゃ感銘を受けたんだよね。だからAirflowでのLLMワークフロー専用のSDKを構築することになったんだ。 良いものはたくさん見てきたけど、どれも一長一短だよね。フレームワークに注目するよりも、何がそれらを構成しているのか、自分で構築した場合のトレードオフは何なのかを理解しようとしてる。 GoogleとOpenAIがほぼ同じ構文をエージェントSDKに採用しているのを見て、agnoを使い始めたんだ。今のところ良い感じだよ。 最近はAIエージェントとか色々あるけど、今でも毎日使ってる一番役立つAIエージェントは、地味な床掃除ロボットだわ。 自動化が家事をやってくれて、もっと執筆やアートに時間を使えるって言ってたのに。執筆は減ったし、洗濯は自分でやらなきゃいけない。 皮肉なことに、文章とかアートの多くはマジで自動化されちゃってるんだよね。 HNのコメントも文章じゃんね。笑 えー、そんなのAIいらなくね？あたしの洗濯ができるようになったらマジですごいと思うわ。 ＞reliable LLM applications 不安定な接続でデータをうまく転送できる？LLMはただの挙動がおかしいDBみたいなもんだって。適切な方法で固定して期待値を下げれば、”reliable LLM applications”はマジで可能だよ。でもregexpみたいなインテリジェンスで適当にやったら…。 ＞不安定な接続でデータをうまく転送できる？ たぶんね。笑 できるはず！私は信じる！もっとコメントを表示（1）
[0] https://ai.pydantic.dev/logfire/#pydantic-logfire
[0] https://github.com/pancsta/secai/blob/474433796c5ffbc7ec5744…
こういうのって、規模が大きくなると安くないんだよね。だから、何か決定論的なコンポーネントで処理できる場合は、まずそれを試してみて。ハルシネーションやレイテンシを節約できるだけでなく、収益にも大きな違いが生まれる可能性があるよ。
実は別タイトル候補は全角の”Agents the Hard Way”だったんだ（全角の”https://github.com/kelseyhightower/kubernetes-the-hard-way”的な意味で）。
視聴覚サンドボックス[1]のアイデアを練ってて(vvvv[2]みたいなやつ、もっとシンプルだけど)。LM(かローカルなニューラルネット)の”ノード”を挿入して、特定のタスクを与えて、出力はすごく制限されるって感じにしたい。
”質問 -> 回答: float”って例はすごく魅力的。質問は抽象的なものになるだろうけど。
[1]: https://kfs.mkj.lt/#audiovisllm
[2]: https://vvvv.org/もっとコメントを表示（2）
＞ほとんどの“AI Agents”は実際にはそれほどagenticではない。“AI ワークフロー”が9割で、“AI Agents”はおそらく1割くらい。
みんな目新しいものに飛びつきたいし、LLMベンダーはトークン消費量を増やしたいから、市場をそっちに誘導しようとするんだよ。
映画『マネー・ショート』のCDO二乗のシーンをもう一度見てみな。
＞「LLMが最初からちゃんと作れないなら、同じLLMにどうやって直させるんだ？」
っていつも思う。複数回繰り返せば性能が上がるのはわかるけど、保証はないよね。ツールによっては、90%とか99%の精度じゃ全然足りない場合もあるし。
＞“常識”は、人生経験がない機械には無理なのかも。
ブレイクスルーが起きるかもしれないけど、AI万能説に賭けるのは怖いな。
ダグ・レナートの常識知識ベースのアイデアって、そんなに悪くなかったのかもね。
テスト戦略とか、リグレッション起こさないようにするにはどうすれば？
「コンテキストは何か」だけじゃなくて、監視のことも12の要素に入れるのもありかもね。version 1.1で組み込むといいかも。
言ってることめっちゃ共感できる。LLMを関数として扱うってのが本当に大事。もっとコメントを表示（3）
[1] https://ai.pydantic.dev
[2] https://github.com/astronomer/airflow-ai-sdk
せっかく聞かれたからいくつか挙げると…
- ts: mastra、gensx、vercel ai、他にもたくさん！
- python: crew、langgraph、他にもたくさん！
それって矛盾したフレーズのリストに追加すべきじゃね？（jumbo shrimpとかみたいな）
LLMの出力を検証するのって、チェックサムとかCRCを計算するほど簡単じゃないよね。
