著者 | ラウナック・ジェイン 編纂者：岳陽 オープンソース ツールを使用して、構成可能なフローと複数の異なるモジュールで構成される複合 AI システムを構築する方法。 01 複合AIシステムとは何ですか？最近、バークレー大学の研究者たちは「モデルから複合AIシステムへの移行」と題した論文を発表しました。この論文では、LLMアプリの開発過程を辿り、複雑なパイプラインの継続的な進化という性質を強調しています。これらのパイプラインは、単一のクローズドソースモデルに依存するのではなく、複数のコンポーネントが連携してインテリジェントシステムを構築することで構築されます。最終的な複合AIシステムは、同じ基盤モデル（GPT4など）を使用する場合もありますが、システム内の様々なコンポーネントは、具体的なプロンプトやコンテキストに応じて異なるコンポーネントとして扱われる場合があります。 以下は、複合 AI システムの一般的な実際の展開モデルです。
02 複雑系における構成要素間の相互作用メカニズムとその構築法複合AIシステムは通常、これらの「モジュール」を相互に接続し、連携させます。これらのモジュールは特定のタスクを実行でき、相互に依存しており、要件に応じて動的に組み合わせ・調整され、事前に定義された設計パターンを実行します。 ここで「モジュール」とは、システム内の個々のコンポーネントを指します。これらのモジュールは明確に定義された機能またはタスクを持ち、独立して、または必要に応じて検索エンジンやLLMなどの基盤システムのサポートを受けてこれらのタスクを実行できます。一般的な「モジュール」には、データジェネレーター、データリトリーバー、データランキングマシン、データ分類器などがあります。NLP分野では、これらは通常、総称してタスクと呼ばれます。これらはドメイン固有の概念的抽象化です（例えば、NLPの抽象モジュールは、コンピュータービジョンやレコメンデーションシステムの抽象モジュールとは異なる場合がありますが、基盤となるモデルサービスや検索エンジンはすべて同じです）。 図1：「モジュール」の主要コンポーネント 図2: その他の一般的なモジュール 人工知能の主流文化では、「ツール[5]」、「エージェント[6]」、「コンポーネント[7]」などの用語が使われていますが、これらはすべて「モジュール」と見なすことができます。 03 LLMベースの自律エージェント - 複合AIシステムの主要モジュール「モジュール」のもう一つの形態は、自律エージェント[8]（訳者注：このタイプのエージェントは、人間の継続的な介入なしに、自律的に環境を認識、分析、反応することができます。）であり、LLMの助けを借りて自律的に推論と計画を行うことができます。自律エージェントは、環境と相互作用する際に、一連のサブモジュールに依存して、どのように推論し、行動を計画するかを決定します。 出典: https://arxiv.org/pdf/2401.03428.pdf 3.1 自律エージェントサブモジュールの主要スキル:エージェントは推論能力を使用して問題について考え、分析し、一連の関連する思考ステップを形成し、最終的に問題を解決したり目標タスクを達成したりするための行動計画を策定することができます。
3.2 この技術は単に「Stochastic Parrots」ですか?
3.3 これらの「オウム」は、タスク解決のプロセスを具体的にどのように計画するのでしょうか?この調査[9]によると、LLMは次のような方法で自律エージェントを効果的に強化できるようです。
「LLMエージェントの計画を理解する：調査」[9] 上で述べた様々な能力、特にRAGモデルをどのように訓練すればよいのでしょうか？詳細については、「エンタープライズRAGのためのLLMの微調整 - 設計的観点」[14]を参照してください。 モジュール抽象化を使用することで、会話型 AI、RAG (検索拡張) システム、CoPilot システムが複雑な問題を処理する際に直面する課題に対処するためのさまざまな設計パターンを開発できます。 複合AIシステムの4つの設計パターン4.1 このセクションを読む際に習得すべき関連概念または用語現在の人工知能分野は「ポップカルチャー」（訳注：よりポピュラーで商業化され、娯楽性が高く、広く大衆に受け入れられ、求められ、一般人のライフスタイルや美的嗜好に近い文化形態）に似た雰囲気を呈しているため、一部の用語は誤解され、誤解されています。そのため、議論を進める前に、いくつかの概念を明確にし、説明する必要があります。 1）「エージェント」モードとは何ですか？ 自律エージェントの真の利点は、タスクを完了するためにどのプロセスを使用するかを自律的に決定する能力にあります。手動でフローを定義したり、意思決定を行ったりする必要がある場合、それは単にインテリジェントワークフローです（訳注：従来のワークフローと比較して、インテリジェントワークフローは入力データと条件に基づいて自動的に意思決定を行い、フィードバックと学習に基づいて実行プロセスを継続的に最適化・改善できます）。しかし、システムの処理フローが事前定義されておらず、前述の機能（タスク解決ステップの分解、複数の代替ソリューションの生成など）を活用し、さまざまなツールやアクションを統合することで自律的な意思決定を実現する場合、それは「エージェント」モデルに該当します。例えば、エージェントRAGでは、モジュールは検索ツールにアクセスし、事前定義された処理ステップなしで複雑な検索フローを自動的に生成できます。 2）「ワークフロー」とは何ですか？ 簡単に言うと、ワークフローとは、すべての手順、決定、アクションが事前に記述され、実行前に手動で指定され、予測可能かつ繰り返し可能な方法で問題を解決するプロセスを指します。 3) 「マルチエージェント」とは何ですか? AIシステムでは、異なるモジュールが異なる役割と責任を担い、互いに影響を及ぼし合い、互いの出力に基づいて問題を解決するために連携して動作します[15]。 4.2 適切なデザインパターンを選択する前に考慮すべき要素RAG、会話型 AI、コパイロット、複雑な問題解決者の開発に使用できるシステムを抽象化して定義するには、次の質問をする必要があります。 1) モジュール間のワークフローは明確に定義されていますか、それともシステムによって自律的に決定されていますか？これは、エンジニアリングフロー（過去の経験に基づいて設計および最適化されたもの）とエージェントシステム（目標達成や問題解決のために相互作用、連携、または競合する複数のエージェントで構成されるシステム）のどちらに相当しますか？ 2) ワークフローは方向性を持つのか、それとも「メッセージパッシングメカニズム」を通じて通信・連携するのか？システム内のモジュールは協力的か、それとも競合的か？Agent Modulo[10]を参照 3) ワークフローは自己学習可能か？自己反省・修正機能は重要か？
4) システムの各コンポーネントまたはモジュールによって生成された結果は、実際の環境で検証および評価できますか? 5) ワークフローの実行中に情報やコンテキストは保存されますか? また、ユーザー入力はワークフローの実行パスや結果に影響しますか? 05 展開モード 1 — RAG / 会話型 RAG下の図は、RAGシステム／会話型RAGシステムにおける各モジュールの主な機能的役割を示しています。RAG／会話型RAGは以前は情報検索（IR）に分類され、ニューラルサーチとナレッジグラフによって当初は改良されました。その後、生成ループ法（LLMを使用）によってさらに改良されました。会話型IR[16]は、情報検索（IR）と対話システムを統合したシステムに対する別の視点です。この視点では、クエリは対話中に変化する文脈オブジェクトとみなされます。 RAGシステムを成功させる鍵は、ユーザーのクエリを理解し、それを基礎知識（構造化または非構造化）にマッピングし、適切な指示とともにジェネレータ/ダイアログマネージャにフィードバックすることです。これは、明確に定義されたワークフローを使用するか、実行するステップを動的に決定するエージェントモジュールを使用することで実現できます（次のセクションで詳しく説明します）。 RAG のワークフローには、ダイアログ マネージャーへの引き継ぎが含まれます。ダイアログ マネージャーがエージェントである場合、RAG はツールと見なすことができます。 エージェントがこの複雑な RAG の世界をうまくナビゲートできるようにする中間モジュール/ツールをいくつか見てみましょう。 5.1 クエリの理解とリファクタリングクエリ拡張 / マルチクエリテクノロジー 従来の転置インデックスやクエリ文書マッチングリトリーバー、スパースリトリーバーや統計リトリーバーを使用する場合、LLMを使用してクエリを拡張すると[17]、検索結果が向上する可能性があります。 クエリ書き換え / セルフクエリ技術 自己クエリ型リトリーバーは、その名の通り、自身にクエリを実行できる（つまり、外部データソースや他のシステムに依存せずに、自然言語を用いてクエリを構築・使用する）リトリーバーです。具体的には、自然言語クエリに対して、リトリーバーは言語モデルを用いてクエリを理解し、構造化クエリに変換します。この構造化クエリは、基盤となるVectorStore（これらのベクトル表現を格納するためのデータ構造）に適用されます。このように、リトリーバーは、ユーザーが入力したクエリと格納されているドキュメントの内容との間の意味的な類似性を比較するだけでなく、ユーザーのクエリからフィルターを抽出して格納されているドキュメントのメタデータを定義し、これらのフィルターを用いて格納されているドキュメントをフィルタリングすることもできます。 エンティティ認識技術 （訳者注：人名、地名、組織名などの自然言語テキストからエンティティを識別および分類する機能を指します。これは、ユーザーの意図を理解するのに役立ち、情報抽出や関係抽出などの後続のタスクを支援します。） 5.2 クエリエンリッチメント(翻訳者注: 外部の知識ソース (ナレッジ ベースやコーパスなど) を利用して元のクエリを補足および拡張すると、より豊富で意味的に意味のあるクエリが生成され、ドキュメント ライブラリ内のコンテンツとの一致が向上し、検索結果の関連性と精度が向上します。) 5.3 知識または意図の検索複数文書検索技術 （翻訳者注：この機能により、複数のコーパスにまたがる同時複合検索が可能になり、より包括的な情報を取得し、複雑なクエリを処理できるようになります。） 対話管理技術 （翻訳者注：対話管理モジュールは、対話の状態とコンテキストを追跡し、対話が可能な限り自然で一貫性のあるものになるように、対話の次のステップを決定する必要があります。） レスポンス生成技術 （翻訳者注：ユーザーのクエリに応答するために、高品質で一貫性のある自然言語応答を生成すること。これには、事前定義されたテンプレートから適切な応答を選択する、自然言語生成モデルを使用してテキストを生成する、ルールやパターンマッチングに基づいてモデル応答を生成するなどの方法が含まれます。） 5.4 エージェントRAGエージェント型RAGは、LLM（限定言語管理システム）によって駆動されるモジュールを特徴とする設計パターンです。LLMは、利用可能なツールセットに基づいて推論を行い、質問への回答方法を計画することができます。より困難で複雑なシナリオでは、複数のエージェントを接続することで、RAGの問題を創造的に解決することができます。これらのエージェントは、コンテンツを取得するだけでなく、検証や要約などの機能も実行できます。このトピックの詳細については、「マルチエージェント」セクションを参照してください。 詳細に説明する必要がある主な手順とコンポーネントは次のとおりです。
これらの操作は通常、以下に説明するパターンを使用して実行されます。 5.5 Agentic RAGに基づく推論: Agentic RAGに基づく推論手法関連論文: https://arxiv.org/pdf/2210.03629.pdf システムは利用可能な検索ツールを推論して分析し、推論結果に基づいて対応するアクションを実行して問題を解決したりタスクを完了したりします。 5.6 計画ベースのAgentic RAG: Agentic RAGに基づくソリューション計画方法関連ドキュメント: https://blog.langchain.dev/planning-agents/ 関連論文: https://arxiv.org/abs/2305.18323 ReAct メソッドと比較して、ReWoo RAG メソッドは出力を生成する際により簡潔で効率的なトークン シーケンスを生成できるため、計算効率が効果的に向上し、冗長性が回避されますが、情報量が減少する可能性があります。
関連論文: https://openreview.net/forum?id=4sajV6NEnWE これは 2 つの部分で構成されます。最初に、タスク全体を小さなサブタスクに分割するソリューションが開発され、次に、計画されたソリューションに従ってサブタスクが実行されます。 関連論文: https://arxiv.org/abs/2305.04091 06 導入モード2 — 会話型AI従来、会話の流れは高度にスクリプト化されていました。「ロボットが話す」→「人間が話す」→「ロボットが話す」…といった具合です。様々な仮想的な現実世界のシナリオを想定したこの形式は、Rasa開発者が「ストーリー」と呼んでいるものです。ユーザーの状態やインタラクションに応じて、各ユーザーの意図は数百もの「ストーリー」（事前定義された会話シナリオまたはインタラクションパターン）として表現されます。ロボットは対応するアクションを実行し、定義されたストーリーを実行し、事前定義された応答で応答します。例えば、ユーザーがニュースレターを購読したい場合、次の2つのシナリオが考えられます。
出典: https://rasa.com/blog/designing-rasa-training-stories/ ユーザーが「ニュースレターを購読するにはどうすればよいですか？」と入力し、ボットがこれを認識し、事前定義されたユーザーインテントをトリガーした場合、ボットはユーザーが既に購読しているかどうかを確認し、適切な次のステップを実行する必要があります。この「次に何をするか」の決定は、事前設定されたパスです（翻訳者注：システムがさまざまなユーザーインテントやリクエストを処理し、それに対応するモデルレスポンスを生成する方法をガイドするために使用されます）。ボットがこのパスから逸脱した場合、「申し訳ありませんが、まだ学習中です。xyzについてお手伝いできます…」と返答する必要があります。 ロボットの開発と維持にかかる真のコストは、これらの「ストーリー」（事前定義された対話シナリオまたはインタラクションパターン）から生じます。この面倒で複雑なパターンを使用する理由は、ロボットが様々な現実世界のシナリオに対応し、新しいパスを体系的かつ体系的に追加できるようにするためです（パスは、システムがユーザーの様々な意図や要求をどのように処理し、それに応じたモデル応答をどのように生成するかを導きます）。しかし、パスの作成者は、対話開始時に「確認すべき条件」、「実行すべき操作」、「望ましい最終状態または結果」を常に念頭に置いてスクリプトを実行し、目的を明確にします。 LLMを使用すると、推論機能と計画機能を使用してスクリプトの作成や行動パスの計画を自動化したり（[19]詳細はこちら）、ループシステムに強力な人工知能を追加したりすることができます。 あなたがカスタマーサービス担当者で、ユーザーが「サービスに登録するにはどうすればよいですか？」という同じリクエストをしたとします。次にどのようなアクションを取るべきか、どのように判断しますか？ 明示的に定義された制約なしに処理を進めることは可能でしょうか？ おそらく不可能でしょうが、コストを抑えるために、上記のようなスクリプトを大量に記述することはできません。もし私があなたに次のようなスクリプトを提示したとしたら…
解決策を考え出し、それを実行する能力と自信があれば、次のようなストーリーを頭の中で紡ぐことができるはずです。
LLMに期待されるのはまさにこれです。つまり、「計画」を生成し、それを青写真として用い、システムの実行中に実行するのです。計画と推論に関する詳細については、こちらをクリックしてください[18]。 このモジュラー システムの青写真を振り返って、プランナーがどのようになっているかを見てみましょう。 上記のプランナーは、ツールと条件を用いて、設計時または実行時にプランやストーリーを構築できます。研究から得られた実例を見てみましょう。 関連論文: https://arxiv.org/abs/2403.03101 KnowAgent: LLM ベースエージェントのための知識拡張プランニング、https://arxiv.org/pdf/2403.03101.pdf 次のようなツールは、プランナーが信頼できる推論を使用してパスを決定するのに役立ちます。
07 デプロイメントモード3 - マルチ - エージェントマルチエージェントの構成と最適化の目標は、大規模な言語モデルによって駆動されるジェネレーター モジュールの役割と責任を明確に定義し、さまざまなエージェント モジュールにカスタマイズされた機能サポートを提供して、それらが連携して最終的にインテリジェントな回答/ソリューションを提供できるようにすることです。 役割と基盤となるモデルが明確に定義されているため、各エージェントはサブゴールまたは「行動計画」の一部を「エキスパート」（特定のドメインまたはタスクに関する専門知識または特化を持つシステム内のモジュール、アルゴリズム、または機能）に委任し、その出力を使用して次に何をすべきかを決定することができます。詳細については、記事末尾のGPTPilotの例を参照してください。 関連論文: https://arxiv.org/abs/2401.03428 上記のパターンは、以下の通信パターンを用いて実行されます。これらの通信パターンは、実行チェーンにおける次のアクションステップを定義する権限を制御します。詳細については、「Orchestration Agentic Systems」[20]を参照してください。 現実世界のアプリケーション向けに CoPilots システムを構築する場合、さまざまなエージェント/モジュールはどのように通信し、連携するのでしょうか? (https://arxiv.org/pdf/2402.01680v1.pdf) マルチエージェント設計パターン[21]の利点は次のとおりです。
各エージェントモジュールは、それぞれ専用の命令と少数のサンプルデータセットを持ち、独立して微調整された言語モデルによって駆動され、様々なツールによってサポートされます。各エージェントモジュールには明確な分担が与えられており、多数の補助リソースやツールから選択して割り当てる必要がなく、特定のタスクのみに集中できます。
マルチエージェント設計パターンは、複雑な問題を管理しやすい作業単位に分割し、専門のエージェントと言語モデルで処理することを可能にします。このパターンにより、アプリケーション全体を混乱させることなく、各エージェントを個別に評価・改善することが可能になります。ツールと責任をグループ化することで、より良い結果が得られます。エージェントは特定のタスクに集中することで、成功する可能性が高まります。
エージェントチームを構築する際には、各チーム内に十分な多様性を確保することが不可欠です。これには、異なるモデル、知識源、タスクの視点などが含まれます。多様性は、チームが問題をさまざまな角度から検討し、相互検証して結果を洗練させ、システムが錯覚やバイアスを生み出すリスクを軽減するのに役立ちます。これは、人間のチームは多様な背景と視点を持つべきであるという考えと一致しており、この設計パターンの人間的な側面を反映しています。
エージェントが構築されると、さまざまなユースケースで再利用したり、適切なオーケストレーション/調整フレームワーク (AutoGen、Crew.ai など) を通じて共同で問題を解決するためのエージェント エコシステムの構築を試みたりする機会があります。 08 展開モード4 — CoPilot私の見解では、CoPilot が他の AI システムと比較した最大の違いと利点は、外部世界 (ユーザー、テスト ツールなど) とのやり取りを通じて新しい知識を獲得する能力にあります。 8.1 CoPilotフレームワークとCoPilotの実装方法の紹介在构建这些协同智能助手（CoPilot）时，最重要的是要区分构建CoPilot 的框架和协同智能助手的实现方法（如GPTPilot和Aider）。在大多数情况下，没有任何开源的协同智能助手是基于这些框架开发的，都是从零开始开发的。 回顾一下当下流行的CoPilot 实现方法：OpenDevin（ https://github.com/OpenDevin/OpenDevin） 、 GPT Pilot（ https://github.com/Pythagora-io/gpt-pilot/tree/main） 回顾一下当下流行的相关研究论文：AutoDev（ https://arxiv.org/pdf/2403.08299.pdf） 、AgentCoder（ https://arxiv.org/pdf/2312.13010.pdf） 当下流行的CoPilot 构建框架：Fabric（ https://github.com/danielmiessler/fabric） 、LangGraph（ https://python.langchain.com/docs/langgraph）、 DSPy（ https://github.com/stanfordnlp/dspy） 、CrewAI（ https://github.com/joaomdmoura/crewAI） 、AutoGen（ https://microsoft.github.io/autogen/docs/Getting-Started/） 、MetaGPT、SuperAGI等 09 Deep Dive — apps9.1 GPT PilotGPT Pilot 项目是一个表现出色的经典案例，它以 “layered” flow （译者注：将任务分解为较小的子任务，并在不同的层次或级别中处理这些子任务，逐步实现任务。）的方式执行看似复杂的任务，使用具有创造性的提示词来引导语言模型生成特定类型的模型输出，并将多个模型的响应拼接在一起，执行目标任务或生成复杂的内容输出。 系统中的不同配置文件（profiles）或角色以分层通信的方式工作，请浏览下面的绿色矩形框： https://www.reddit.com/r/MachineLearning/comments/165gqam/p_i_created_gpt_pilot_a_research_project_for_a/ 系统中各个独立的Agent 以一种分层的方式相互交互，各agent按顺序相继被触发，在整个系统中不存在中心决策的agent。 产品在部署时采用了一些很好的设计原则，这些设计原则使得该产品在实际运行时表现出色：
尽管本文介绍的提示词工程和工作流设计都很复杂，但对每个Agent 进行微调，对于降低使用成本和提高AI 系统准确性的好处是不言而喻的。 読んでくれてありがとう！ Raunak Jain Seeking patterns and building abstractions 終わり 参考文献[1] https://docs.deepwisdom.ai/main/en/guide/use_cases/agent/researcher.html [2] https://www.youtube.com/watch?v=m8VSYcLqaLQ [3] https://www.youtube.com/watch?v=8R7QOJgGyIQ [4] https://www.youtube.com/watch?v=Cl19yWHhc2g [5] https://python.langchain.com/docs/modules/tools/ [6] https://microsoft.github.io/autogen/docs/Use-Cases/agent_chat [7] https://docs.haystack.deepset.ai/docs/components [8] https://www.sciencedirect.com/science/article/abs/pii/B0080430767005349 [9] https://arxiv.org/pdf/2402.02716.pdf [10] https://arxiv.org/abs/2402.01817 [11] https://aiguide.substack.com/p/can-large-language-models-reason [12] https://www.ece.uw.edu/wp-content/uploads/2024/01/lecun-20240124-uw-lyttle.pdf [13] https://arxiv.org/abs/2402.10178 [14] https://medium.com/@raunak-jain/fine-tuning-llms-for-enterprise-rag-8c1eb3ac6b32 [15] https://arxiv.org/abs/1612.01294 [16] https://arxiv.org/abs/2201.05176 [17] https://arxiv.org/pdf/2305.03653.pdf [18] https://medium.com/@raunakjain_25605/path-to-production-for-llm-agents-f0a9cafd2398 [19] https://medium.com/@raunak-jain/llm-driven-planning-and-reasoning-for-enterprise-ai-09bf6b5e1965 [20] https://medium.com/@raunak-jain/orchestrating-agentic-systems-eb945d305083 [21] https://abvijaykumar.medium.com/multi-agent-architectures-e09c53c7fe0d この記事は、原著者の許可を得てBaihai IDPによって翻訳されました。翻訳の転載をご希望の場合は、お問い合わせください。 オリジナルリンク: https://medium.com/@raunak-jain/design-patterns-for-compound-ai-systems-copilot-rag-fa911c7a62e0 |
