同じ苦労をしないでほしい！生成AI活用システムの開発体験談

私が初めてマルチエージェントシステムをプロトタイプしたときにハマってしまった落とし穴や教訓についてお話した際の資料です。

Transcript

1. 町田　凌 同じ苦労をしないでほしい！ 生成AI活用システムの 開発体験談 2024年7月31日　関西生成AI祭り　LT
2. 初めてのパブリックな場でのLTです 🎉 生成AIについて色々お話聞けると嬉しいです 👂✨ 初めてのプロトタイプ開発の中で僕がハマってしまった落とし穴の話や、やってよかったことを お話します 町田　凌 フルスタックエンジニア ~2023年 2023年~ 大阪出身。大学院までずっと関西。特にAIとは深く関わらず過ごす BIPROGY（旧: 日本ユニシス）入社、現在新卒2年目。 自社サービスのアジャイル開発の後、 現在は、設計書をインプットとするソースコード生成システムの開発を担当
3. LLMが複雑な目的に取り組むための システム構成
4. Prompt Chain 段々複雑になるLLMを使ったシステム 目的達成の難しさに応じて、システムの構成が複雑になる マルチ エージェント プロンプト 複雑度 低 複雑度 高 構成の複雑さについて考えるため、ここでは 以下のようにシステムを分類してみる エージェント
5. プロンプトによる単純な生成 考慮すべき：利用モデル、プロンプトエンジニアリング 翻訳文 翻訳の指示 原文
6. Prompt Chain [1] あるプロンプトの出力結果を他のプロンプトの入力とし、 生成を繰り返すこと 考慮すべき：下流のプロンプトに役立つ情報を上流から　 提供できるか より原文を理解し 文化的に伝わりやすい 翻訳文 原文の入力 原文の理解 文化的な違いの考慮 翻訳 [1]: The Prompt Report: A Systematic Survey of Prompting Techniques, https://doi.org/10.48550/arXiv.2406.06608
7. エージェント[1] 目的の達成のため、LLMの外部のシステムとの連携を行う システムのこと 考慮すべき：外部システムから得た情報が役立つか 専門知識を 踏まえた翻訳文 原文の入力 翻訳の参考になる情報の 検索ワードを生成 翻訳 専門知識DB [1]: The Prompt Report: A Systematic Survey of Prompting Techniques, https://doi.org/10.48550/arXiv.2406.06608 専門性のある翻訳エージェント
8. マルチエージェント 目的達成のために複数のエージェントが協調するシステム 考慮すべき：下流のエージェントに役立つ情報を上流から 提供できるか 各分野での 専門的な外部情報を 踏まえた上での 翻訳文 原文の入力 原文理解 エージェント 文化的背景 エージェント 翻訳 エージェント 校正 エージェント
9. 考慮すべきことが増えていく だからこそ、構成要素となるプロンプト/エージェントを　 しっかり設計・実験し、それらを組み合わせた上位レイヤ に進まないと大変 Prompt Chain マルチ エージェント プロンプト 複雑度 低 複雑度 高 エージェント
10. ここでいう設計とは プロンプト/エージェントが目指す出力は何？ プロンプト/エージェントへ渡す変数はどんな情報？ プロンプト/エージェントのどんなテクニックを使う？ これらを意識しながら、プロンプト/エージェントの改善を 繰り返す
11. 失敗体験談
12. いざ初めてのプロトタイプ！ コード生成の既存ツールから、ふるまいや実装を勉強 GitHub Copilot / Cursor Devin / OpenDevin (OSS) / Devika (OSS) ⇒大抵エージェント要素があるので、マルチエージェント で作ろう！
13. 生まれたプロトタイプ Devikaを拡張し、エージェントを数種類実装 Planner君 タスクを読み解いて 皆に仕事を与えます < DependencyFetcher君 依存関係 教えるよ < SimilarityFetcher君 似た実装 探してくるよ < WebResearcher君 Web検索 するよ < Coder君 コード 書くよ < Patcher君 テスト実行して コード修正するよ < 基本的に左から右へ仕事が受け渡される
14. いざ実行して挙動を監視すると コード生成の結果は大したことはなかったが、 それ以上に重大なミスがあった Patcher君 うーん、コード生成難しいw <
15. 良い影響を与えていないエージェント 参考になる既存実装をCoderに渡して、コーディングの　 参考にさせたかったが、出力にその影響はなかった SimilarityFetcher君 僕は自分の仕事を きっちりこなしたけどな < Coder君 君の情報あんまり 役に立ってないよ > 僕 ・・・ <
16. 実験の不足が原因 Coderエージェントの生成物を良くするには何が必要か Coderエージェント単体で十分に実験してから、 　　　　　　 追加のエージェントを実装すべきだった 下流エージェントに役立つ情報が何か実験すること を怠ったまま、上流エージェントを追加していた
17. 更に原因を深掘りすると思い込みがあった LLMの原理は理解しつつも、ついつい　　　　　　　 「人間がコーディングするなら」ベースで　　　　　 エージェントを加えていた 巷にあふれる、人になぞらえたマルチエージェント　　 システムの情報から「人間と同じように組織すれば　 上手くいきそう」と上っ面だけで思い込んでしまった
18. 目的達成のために絶対に必要なエージェントから　　 小さく作る 新たにエージェントを作る前に、既存のエージェント 単体で何があれば出力が改善されるか実験する 無駄なものを作り出さない教訓 僕 SimilarityFetcher君 コーディング規約を守らせるには 他の方法の方が良かったから 既存コードの情報いらないよ じゃあ休んどくね < > Coder君
19. コードを整え、実験しやすい環境を作った Jinja2というテンプレートエンジンを活用し、コードか ら「プロンプトの記述」という責務を分離 Tests as Documentation（テストがユニットテストと IO仕様のドキュメントの両方の役割を果たす） プロンプト/エージェント単体でマニュアル実行できる ようなテスト関数を追加 エージェントを改善しやすくするために
20. 今日の話題のまとめ マルチエージェントを採用してシステムの複雑度が増しても、 　　 プロンプト/エージェント単位での設計・実験が大事
21. ご清聴ありがとうございました！
22. エージェント開発の小さな工夫 （時間の都合で発表できず）
23. テンプレートエンジン（Jinja2）が便利 MVCフレームワークのViewでよくある 動的な文字列コンテンツを作るためのテンプレートエンジン forやifのような簡単な処理をテンプレートに書ける
24. コードとプロンプトの責務を分離できる プロンプトの整形をJinja2に任せてしまって、コードは LLMに渡すデータの収集に専念する コード上にプロンプトの 内容を見せない
25. Jinja2は著名なOSSでも使える
26. エージェントのためのテストコード 以下の2つを用意できると、安心して開発を続けられる LLM部分をモック化したテストコード プロンプト/エージェント単体での　　　　　　　　　　 マニュアル実行のためのテストコード もし可能なら用意したい プロンプト/エージェントの評価のためのテストコード
27. ① LLM部分をモック化したテストコード 不確実性のあるLLM部分以外をテストすることで、 　　　　 確実性のある他の処理がエージェントの挙動に悪い影響を　 与えていないことを担保できる これがないと問題が起こった際に生成結果が悪いのか、 　　 その他の部分が悪いのか切り分けが面倒
28. Tests as Documentation LLM以外の部分がどういう想定だったか読み取れるようにな るため、開発者がエージェント内部を理解しやすくなる
29. Planner君内部での とあるプロンプト による生成結果 コード生成は以下のステップで行います Step 1: ネット検索 ... Step N: コード書き込み 次にテストは以下のステップで行います Step 1: テストケース作成 ... Step N: テスト実行 僕 あれ？ステップが二種類生成してる 実装者はこういう場合を想定してたんだろうか？ プロンプトを修正すべきか？整形処理を拡張すべきか？ エージェントの動きに悩まされたとき...
30. テストデータ ステップが数件の場合 期待値 Step 1: Web検索 ... Step M: コード生成 Step M+1: テストコード生成 ... Step N: テスト実行 僕 テストデータではステップのセットは1つだな！ プロンプトは過去から変更がないので、モデルの違いが原因か 実例に即したテストデータは理解を助ける
31. 著名ライブラリはLLMを抽象化でき便利 抽象クラスが提供されていたり テストダブルが提供されていたりと、至れり尽くせり
32. ② 単体マニュアル実行用のテストコード プロンプト/エージェント単体で実験するため、 　　　　　　 気軽に実行できる仕組みを作っておく （pytestのm flagで、手動実行しやすくしておくと良い） Tests as Documentationをやれてれば、データをそのまま 手動の実験に使えるのでGood
33. ③ エージェント評価のためのテストコード G-EvalのようなLLMで結果を評価する仕組みが便利 confident-ai/deepeval の ような自動テストで使える 便利な評価ツールが 登場している
34. LLMに頼らないテスト基準も有用 一方、確実性が求められるタスクなら、LLMという不確実な ものに頼らないテスト基準を作りたい コード生成なら コンパイルできる 事前定義した単体テストを通過する など
35. テストの仕組みにコストをかけすぎない 社内システムのように、利用者の良識が期待できるもの なら、エージェントの入出力のモニタリングに留め、 　　　 自動テストの準備・運用にかかるコストをかけないのも　　 一つの手 Planner君 テストは悩ましいな <