AIエージェントシステム: 高信頼のエンタープライズAIアプリケーションのためのモジュラーエンジニアリング

[AI Agent Systems: Modular Engineering for Reliable Enterprise AI Applications \| Databricks Blog: AI Agent Systems](https://www.databricks.com/blog/ai-agent-systems)の翻訳です。

:::note warn
本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
:::

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

いかなる新規技術のPOCは多くの場合、特徴づけることが困難な大規模でモノリシックなユニットからスタートします。定義によれば、POCは拡張可能性やメンテナンス、品質のことを考慮することなしに、ある技術が動作することを説明することを目的としています。しかし、技術が成熟して広くデプロイされると、これらの要件によって製品開発は小規模でより管理可能なユニットに分割されるようになります。これは、システムシンキングの背後にある基本的なコンセプトであり、我々がAIの実装がモデルからAIエージェントシステムに移行していることを目撃している理由なのです。

[モジュラーデザイン](https://en.wikipedia.org/wiki/Modular_design)のコンセプトは以下の領域で適用されています:

- 自動車: シート、タイヤ、ライト、エンジンのすべてが異なるベンダーから提供可能です。
- コンピューターチップ: 現在ではチップの設計は、メモリーインタフェース、IOインタフェース、FLASHメモリーのように特殊な回路のための構築済みのモジュールとインテグレーションされます。
- 建築: 窓、ドア、床、電気機器。
- ソフトウェア: オブジェクト指向プログラミングとAPIは、ソフトウェアを小規模で管理可能なコンポーネントに分割します。

実際のところ、エンジニアリングされる全てのシステムは、独立して検証、接続可能なモジュール化された、利用可能なユニットへと成熟します。50年前、ソフトウェアはコマンドの単一のストリームによって実装されていましたが、現在の開発環境ではほとんど考えられないことです。ソフトウェアエンジニアリングは、ポータブルで拡張可能、メンテナンス可能なコードになるように、複雑性に対応できるようにプラクティスを進化させました。現在では、開発者はコード間で適切に定義されたインタフェースを持つ、管理可能なサブユニットに問題を分割しています。機能は区分ごとに分割可能です。コンポーネントの変更には、システム全体の変更を必要としません。コンポーネントが適切にインタフェースをほかのモジュールに提供している限り、統合されたシステムは意図した通りに稼働し続けます。この構成可能性によって、拡張可能性を実現します。新たな方法でコンポーネントを構成したり、異なるシステムを構築するために新たなコンポーネントを使用することができます。

大規模言語モデル(LLM)は、最近まではモノリシックな形態を撮っていました。新規トレーニングデータの入力では、多くの場合モデルの完全な再トレーニングを必要とし、カスタマイズのインパクトを特徴づける事が困難でした。初期段階では、LLMは信頼性がなく、精査できないユニットとなっていました。それらのアウトプットが検証されたデータに立脚しているのか、すでにトレーニングデータに含まれているのかが不明確でした。この「ブラックボックス」のアウトプットは、エンドユーザー向けアプリケーションで高いレベルでのコントロール、信頼性、予測可能性を必要とする企業アプリケーションに適さないものとなりました。さらに、規制のある業界では、顧客とのインタラクションで準拠すべき法的、コンプライアンスのフレームワークが存在します。例えば、ヘルスケアシステムでは患者に[ヘルスケアデータを提供](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html#:~:text=With%20limited%20exceptions%2C%20the%20HIPAA,the%20patient%2C%20etc.)する事が求められますが、患者のヘルスケアデータの解釈に対する制限が存在しています。解釈とデータ収集を分離することで、ヘルスケアシステムは解釈の適切性とは個別に、データの適切性を適格なものにする事ができます。エージェントAIシステムは、企業が異なる機能を管理し、それぞれの機能を個別にコントロールできる能力を提供します。そのような機能は、これらのシステムに全てのレスポンスの基礎を形成するデータへの*決定論的な*アクセス(関数呼び出しやデータベースの組み込み)をもたらします。上述のシナリオでは、システムからのすべてのレスポンスにおける真実のソースとしてデータセットを提供する事が望まれます。

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

これらの要件は、エンドツーエンドのインテリジェンスアプリケーションを構築するための新たな方法を必要とします。今年初頭に、我々はBerkeley AI Research departmentで公開された[ブログ記事](https://qiita.com/taka_yayoi/items/287ad22441d6abc7e07e)の複合AIシステム(CAIS)のコンセプトを紹介しました。AIエージェントシステムは、現実世界のAIシステム開発にCAISのコンセプトとモジュラーデザインを適用します。AIエージェントシステムでは、(モデル、レトリーバー、ベクトルデータベースを含む)複数のコンポーネントと評価、モニタリング、セキュリティ、ガバナンスのためのツールを活用します。これらの連携する複数のコンポーネントは、単一モードの基盤モデルよりもはるかに高い品質のアウトプットを提供し、AI開発者はメンテナンスと更新がより容易になる独立して検証可能なコンポーネントをデプロイできるようになります。我々は、OpenAIのような大規模なAIラボがこの方向に向かっているのを目撃しています: ChatGPTはツールインタフェースからインターネットにアクセスでき、彼らの最新の理由付けモデルであるO1は、自身の理由づけのチェーンで複数のコンポーネントとやりとりをしています。

標準的なアプリケーションソフトウェアとは対照的に、インテリジェンスアプリケーションには予測可能な方法でインタラクションする確率論的なコンポーネントと決定論的なコンポーネントが存在します。本質的に人間の入力は曖昧なものです。今では、LLMはリクエストの意図を解釈するために文脈を用いて、入力をより決定論的なものに変換する能力を提供しています。リクエストに対するサービスを提供するには、以前学んだ変換処理に基づいて、特定の事実を収集し、コードを実行し、理由づけのフレームワークを適用する必要があるかもしれません。この情報の全ては利用する人(あるいは物)に対して適切にフォーマットされた一貫性のあるアウトプットとして構成されなくてはなりません。モジュール化によって、開発者はアプリケーションのパーツを、(データベースの検索や計算のように)完全に決定論的なもの、(プロンプトの文脈処理のように)部分的に曖昧なもの、(新たなデザインのレンダリングや革新的な散文のように)完全にクリエーティブであるものに分割する事ができます。

多くのインテリジェンスアプリケーションには、これらの論理的なコンポーネントが含まれることになります:

![](https://www.databricks.com/sites/default/files/inline-images/AgentSystems_Diagram1.png?v=1731472783)

- *入出力のフォーマッティング:* アプリケーションに固有のフォーマットあるいは言語。例えば、税コードは非常に特殊な人間の言語であり、解釈や生成には特殊なLLMが必要になる事があります。フォーマットには、(コードの実行のように)ほかの種類の処理に必要となるJSONやドメイン固有の言語のように高度に構造化された方法で提供されることもあります。
- *データの基盤:* アプリケーションをサポートするために必要な一連の事実。現在では、これは通常ユーザーのクエリーに対して文脈や事実を提供できるデータベースの形態として提供されます。一般的なアプローチは、それぞれのクエリーに対して[Mosaic AI Vector Search](https://docs.databricks.com/ja/generative-ai/vector-search.html)を使うか、シンプルにシステムに対するプロンプトとして、クエリーに対して必要とされるすべての事実を追加します。
- *決定論的処理:* 適切で高品質なレスポンスを生成するのに必要な一連の関数とツールです。LLMは決定論的処理を行うために、クエリーからフィールドを抽出し、それらを標準的な関数呼び出しに渡す事ができます。Databricksプラットフォームでは、[Mosaic AI Tools and Functions](https://community.databricks.com/t5/technical-blog/unity-catalog-functions-tools-for-users-and-agents/ba-p/98221)の機能がこの挙動を実現します。ユーザー定義関数は、Databricks内のほとんどのアクションを実行する事ができ、それらは自然言語で呼び出されて、決定論的な能力と確率論的な能力を組み合わせる事ができます。
- *汎用的な理由づけ:* 現在、ほとんどのLLMが行っている事です。これらのLLMは、通常の言語の用法、慣用句、一般的な知識の文脈づけを行うために、インターネットから得られる汎用的な情報でトレーニングされています。これらのLLMは通常、様々なドメインにおける基本的な専門用語のいくつかを理解しますが、ドメイン情報を解析するためにトレーニングされていないので、信頼できない結果を提供する場合があります。
- *ドメインの理由づけ:* ドメイン固有の言語を解析、生成する方法と特定のドメインで適切に質問に回答する方法を理解します。データの基盤が効果的にレスポンスの根拠となるように、データ基盤のドメインにシステムのドメイン理由づけがマッチしている事が重要です。このようなドメインの特殊性を達成するために、これらのLLMはファインチューニングされたり、徹底的なプロンプトエンジニアリングが行われます。ここでは、モデルの能力を修正するために関数呼び出しが用いられることもあります。
- *汎用的、ドメインの評価:* ここでは、我々のアプリケーションの成功を定義します。評価とは、我々のタスクにおいて適切な挙動として定義する一連の質問とレスポンスです。開発プロセスの初期でタスクに対する評価セットを構築しておく事が重要です。これによって、我々のアプリケーションに求められる品質や、さまざまな干渉がスコアにどのような影響を及ぼすのかを理解する事ができます。[Mosaic AI Agent Evaluation Framework](https://www.databricks.com/jp/blog/announcing-mosaic-ai-agent-framework-and-agent-evaluation)は、これらの評価を構造的に定義する方法と、インテリジェンスアプリケーションに評価を実行する手段を提供します。この能力は急速に改善されておりますので、この領域を注視していてください。

# 実践する

Databricksでは、これらのエンドツーエンドシステムを容易に構築できるようにするために、[Mosaic AIエージェントフレームワーク](https://www.databricks.com/jp/product/machine-learning/retrieval-augmented-generation)を開発しました。このフレームワークは、システムの評価指標を定義し、特定のアプリケーションにおける品質のスコアリングを行うために活用する事ができます。[Mosaic AI Gateway](https://docs.databricks.com/ja/ai-gateway/index.html)は、アクセス制御、レート制限、ペイロードの記録、ガードレール(システム入出力のフィルタリング)を提供します。ゲートウェイはユーザーに、安全性、バイアス、品質を監視するために稼働中のシステムに対する定常的なモニタリングを提供します。

現在のAIエージェントシステムの典型的なコンポーネントは:

- エンべディングモデルとベクトルデータベース([Mosaic AI Vector Search](https://docs.databricks.com/ja/generative-ai/vector-search.html))
- 関数呼び出しとツール使用のインタフェース([Mosaic AI Function Calling](https://docs.databricks.com/ja/machine-learning/model-serving/function-calling.html))
- プロンプトやファインチューニングによるLLMのカスタマイズ([MLFlow LLMOps](https://www.databricks.com/jp/blog/mlflow-2-7-llmops-prompt-eng-ai-gateway-updates)、[DSPy on Databricks](https://docs.databricks.com/ja/generative-ai/dspy/index.html)、[Mosaic AI Fine-tuning](https://docs.databricks.com/ja/large-language-models/foundation-model-training/index.html))
- モニタリングとガードレール([Mosaic AI Gateway](https://docs.databricks.com/ja/ai-gateway/index.html))

すでに我々は、インテリジェンスアプリケーションの優れたエンドツーエンドの品質とメンテナンス可能性をドライブするためにお客様がこのモジュール性を活用しているのを目撃しています。例として、Factsetでは投資や企業の専門家に財務データ、分析、ソフトウェアソリューションを提供しています。彼らは自身のデータに構造化クエリーを行うために、*FQL*と呼ばれる彼ら自身のクエリー言語を開発しました。彼らは自分たちのプラットフォームに[英語のインタフェースを追加](https://www.databricks.com/blog/factset-genai)したいと考え、高品質な情報のアウトプットを維持したいと考えていました。ファインチューニング、Vector Search、プロンプトを組み合わせることで、自分たちのAIエージェントシステムをプロダクションにデプロイする事が可能になりました。

![](https://www.databricks.com/sites/default/files/inline-images/AgentSystems_Diagram2.png?v=1731472783)

我々は、AIエージェントシステムをインテリジェンスアプリケーションにおける新たなアプリケーション開発のパラダイムの先駆けと見ています。モノリシックでメンテナンスできないLLMから、モジュール化され、カスタマイズ可能なアプローチへの移行は、多くのメリットを提供する自然な前進と言えます: より高い信頼性、メンテナンスの容易化、優れた拡張可能性などです。Databricksでは、企業の要件に応える必要なモニタリングやガバナンス構造とともに、統合されたプラットフォームでこれらのアプリケーションを繋ぎ合わせる繊維を提供します。自分たちの組織のためにこれらのツールを活用する方法を学ぶ開発者は、クイックかつ高品質なアプリケーションの開発で、明確なメリットを享受することになるでしょう。

### はじめてのDatabricks

[はじめてのDatabricks](https://qiita.com/taka_yayoi/items/8dc72d083edb879a5e5d)

### Databricks無料トライアル

[Databricks無料トライアル](https://databricks.com/jp/try-databricks)