AIエージェントシステム：信頼性の高い企業向けAIを実現するモジュール型エンジニアリング

モノリシックからモジュラーへ

新技術の概念実証（POC）は、多くの場合、特性を明確にするのが難しい大規模でモノリシックな単位から始まります。POCはその性質上、拡張性、保守性、品質といった課題を考慮せずに「技術が動作する」ことを示すために設計されます。しかし、技術が成熟し広く展開されると、これらの課題に対応するために、製品開発はより小さく管理しやすい単位に分解されていきます。これがシステム思考の基本的な概念であり、AIの導入が単一のモデルからAIエージェントシステムへと進化している理由なのです。

モジュール設計の概念が適用されてきた分野: modular design

• 自動車: 座席、タイヤ、ライト、エンジンなどを異なるベンダーから調達可能
• コンピュータチップ: メモリ、I/Oインターフェイス、FLASHメモリなどの事前構築されたモジュールを統合
• 建築物: 窓、ドア、床、家電など
• ソフトウェア: オブジェクト指向プログラミングやAPIにより、小規模で管理可能なコンポーネントに分割

ほぼすべてのエンジニアリングシステムは、最終的に独立検証可能で接続可能なモジュール単位へと成熟します。50年前、ソフトウェアは1本の指令の流れとして実装されていましたが、現在の開発環境ではほぼ考えられません。
ソフトウェア工学は、複雑性を管理するための手法を進化させ、移植性、拡張性、保守性の高いコードを実現しました。現在では、開発者は問題を管理可能なサブユニットに分割し、それらの間に明確なインターフェイスを設けています。機能は分離可能であり、コンポーネントの修正がシステム全体の変更を必要としません。インターフェイスが正しく機能すれば、統合システムは想定通りに動作します。この構成可能性により、モジュールを新しい方法で組み合わせたり、新しいコンポーネントと統合して異なるシステムを構築することが可能になります。

大規模言語モデル（LLM）は、近年までモノリシックな形態で運用されており、新しい学習データを取り込むたびにモデル全体の再学習が必要で、カスタマイズの影響も評価することが困難でした。初期のLLMは信頼性が低く、不透明なユニットとして扱われ、出力が提供された検証済みデータに基づいているのか、既存のトレーニングデータに基づいているのかを判別することができませんでした。このような「ブラックボックス」出力は、制御性、信頼性、予測可能性を重視する企業向けアプリケーション、特に顧客に直接対応する用途には不向きでした。

さらに、規制産業では、顧客とのやり取りが法的・コンプライアンスの枠組みに適合する必要があります。たとえば、医療システムは患者に医療データを提供することが求められますが、そのデータの解釈には制限が課されています。データの取得とその解釈を分離することで、医療システムはデータの正確性と解釈の正確性を独立して検証できるようになります。

エージェントAIシステムは、これらの機能を分割し、それぞれを独立して制御する能力を企業に提供します。たとえば、これらのシステムに決定論的なデータアクセス（関数の呼び出しやデータベースの統合）を可能にする機能を持たせることができます。これにより、すべての応答の基盤として機能する「真実の基盤」となるデータセットを提供することができます。こうしたアプローチにより、特定のデータがすべての応答の根拠として機能することが保証されます。

インテリジェンスアプリケーションの新たな開発パラダイム

これらの要件により、エンドツーエンドのインテリジェンスアプリケーションを構築する新しい方法が求められています。今年初め、バークレーAI研究所が発表したブログ記事で、Compound AI Systems（CAIS）という概念を紹介しました。AIエージェントシステムは、CAISとモジュール設計理論を実世界のAIシステム開発に適用したものです。

AIエージェントシステムは、モデル、リトリーバー、ベクターデータベースなどの複数のコンポーネントに加え、評価、モニタリング、セキュリティ、ガバナンスのためのツールを使用します。これらの複数の相互作用するコンポーネントにより、単一モードのファウンデーションモデルよりもはるかに高品質な出力を実現し、AI開発者が独立して検証可能なコンポーネントを展開できるようになります。これにより、保守や更新が容易になります。

現在、大規模なAI研究機関もこの方向に進んでいます。たとえば、OpenAIのChatGPTはツールインターフェースを介してインターネットにアクセス可能であり、最新の推論モデル「O1」は、推論チェーン内で複数の相互作用するコンポーネントを備えています。

従来のアプリケーションソフトウェアとは対照的に、インテリジェンスアプリケーションは確率的コンポーネントと決定論的コンポーネントを持ち、それらが予測可能な方法で相互作用する必要があります。人間の入力は本質的に曖昧ですが、大規模言語モデル（LLM）は、文脈を利用してリクエストの意図を解釈し、それをより決定論的なものに変換する能力を提供してくれます。

リクエストに応えるためには、特定の事実を検索したり、コードを実行したり、過去に学習した変換に基づいて推論フレームワークを適用する必要があるかもしれません。これらのすべての情報を再構築し、一貫性のある出力として正しい形式で提供する必要があります。このようなモジュール化により、完全に決定論的な部分（データベース参照や計算機など）、部分的に曖昧な部分（プロンプトの文脈的な処理）、完全に創造的な部分（新しいデザインや独創的な文章の生成）をアプリケーション内で分離することが可能になります。

多くのインテリジェンスアプリケーションは、一般的に次のような論理コンポーネントで構成されます。

• 入力と出力のフォーマット: アプリケーション固有のフォーマットや言語のこと。例えば、税法は非常に特化した人間の言語であり、それを解釈・生成するためには専門のLLMが必要になる場合があります。フォーマットは、JSONやドメイン固有言語のように高度に構造化された形式で提供されることもあり、別の処理（例：コードの実行）が求められることがあります。
• データ基盤: アプリケーションをサポートするために必要な事実のセット。現在では、これは通常データベースの形式で提供され、ユーザーのクエリに文脈や事実を提供します。一般的なアプローチとして、各クエリに対してDatabricksベクター検索を使用するか、必要な事実をすべてクエリに追加してプロンプトとしてシステムに渡す方法があります。
• 決定論的処理: 正確で高品質な応答を生成するために必要な関数やツールのセット。LLMはクエリからフィールドを抽出し、それを標準的な関数呼び出しに渡して決定論的処理を行うことができます。Databricksプラットフォーム内では、Databricksツールと関数の機能によりこの動作が可能です。ユーザー定義関数はDatabricks内でほとんどの処理を実行でき、これらは自然言語を使用して呼び出すことができ、決定論的および確率的な機能を組み合わせることができます。
• 一般的な推論: 現在のLLMが主に行う処理。これらのLLMは、インターネット上の一般的な情報をもとにトレーニングされており、通常の言語使用、慣用句、一般知識を文脈化します。これらのLLMは、さまざまな分野の基本的な専門用語をある程度理解していますが、ドメイン情報を解析するようにはトレーニングされておらず、不正確な結果を出すことがあります。
• ドメイン推論: 特定のドメインに特化した言語を解析・表現し、そのドメイン内で正確に質問に答える方法を理解すること。ドメイン推論をデータ基盤のドメインと一致させることが重要であり、それによりデータ基盤が応答を効果的に支えることができます。このようなLLMはファインチューニングや詳細なプロンプト設計によってドメイン特化を実現することがあります。また、関数呼び出しを使用してモデルの能力を補完することもできます。
• 一般およびドメイン評価: アプリケーションの成功を定義する方法。評価は、タスクにおける正しい動作として定義される質問と応答のセットです。評価は開発プロセスの初期段階で構築することが重要であり、それによりアプリケーションに求められる品質や、さまざまな介入がスコアにどのような影響を与えるかを理解できます。Databricksエージェント評価フレームワークは、これらの評価を構造化して定義する方法と、インテリジェンスアプリケーションに対して評価を実行する方法を提供します。この機能は急速に進化しているため、注目が必要です。

実践に移す

Databricksでは、これらのエンドツーエンドシステムを簡単に構築できるようにAgent Bricks Custom Agentsを作成しました。このフレームワークは、システムの評価基準を定義し、そのアプリケーションに対する品質をスコアリングするために使用できます。Agent Bricks AI Gatewayは、アクセス制御、レート制限、ペイロードログ、ガードレール（システムの入力と出力のフィルタリング）を提供します。ゲートウェイは、ユーザーに安全性、バイアス、品質を監視するための常時監視を提供します。

今日、AIエージェントシステムの典型的なコンポーネントは：

• 埋め込みモデルとベクトルデータベース (Databricks AI Search)
• 関数呼び出しとツール使用インターフェース（Databricks関数呼び出し)
• LLMsのカスタマイズは、プロンプトまたは微調整によって行われます（MLFlow LLMOps, DSPy on Databricks, Databricks Fine-tuning)
• モニタリングとガードレール（Agent Bricks AI Gateway）

すでに、このモジュラリティを活用してインテリジェンスアプリケーションのエンドツーエンドの品質と保守性を向上させる顧客がいることを見てきました。例えば、Factsetは投資家や企業専門家向けの金融データ、分析、ソフトウェアソリューションを提供しています。彼らは自分たちのデータに対するクエリを構造化するための独自のクエリ言語、FQLを作成しました。 彼らは、情報出力の高品質を維持しながら、プラットフォームに英語のインターフェースを追加したいと考えていました。
ファインチューニング、ベクトル検索、プロンプトの組み合わせを使用することで、彼らはAIエージェントシステムを本番環境にデプロイすることができました。

私たちは、AIエージェントシステムを、インテリジェンスアプリケーションの新しいアプリケーション開発パラダイムの先駆けと見ています。モノリシックで保守性のないLLMsからモジュラーでカスタマイズ可能なアプローチへの移行は、高い信頼性、容易な保守性、そして大きな拡張性という多くの利点を伴う自然な進行です。Databricksは、これらのアプリケーションを統一されたプラットフォームで縫い合わせ、エンタープライズのニーズに対応するための必要な監視とガバナンス構造を提供します。これらのツールを自分の組織のために使いこなすことを学ぶ開発者は、高品質なアプリケーションを迅速に構築するための明確な利点を持つでしょう。