ジュリア・ヴィージンガー、パトリック・マーロー、ウラジミール・ヴスコヴィッチ著
オリジナル:https://www.kaggle.com/whitepaper-agents
ディレクトリ
簡単
知的身体とは何か?
モデリング
アーティファクト
オーケストレーション層
インテリジェンシアとモデリング
認知アーキテクチャ:知性の仕組み
道具:外の世界への鍵
エクステンション
サンプル・エクステンション
関数
ユースケース
関数サンプルコード
データストレージ
実現と応用
ツールレビュー
的を絞った学習でモデルのパフォーマンスを向上
LangChainでIntelligentsiaをクイックスタート
バーテックスAIインテリジェンスを使用した生産アプリケーション
概要
このような推論、論理、外部情報へのアクセスの組み合わせは、生成的なAIモデルと結びつき、インテリジェンスという概念につながる。
簡単
人間は面倒なパターン認識作業をこなすのが得意だ。しかし、結論に達するまでには、本やグーグル検索、電卓などのツールに頼り、予備知識を補うことが多い。
人間と同じように、生成AIモデルはツールを使ってリアルタイムの情報にアクセスしたり、現実世界の行動を提案したりするように訓練することができる。例えば、モデルはデータベース検索ツールを使って、顧客の購入履歴などの特定の情報にアクセスし、オーダーメイドのショッピング推奨情報を生成することができる。
あるいは、ユーザーからの問い合わせに基づいて、モデルは様々なAPIコールを行ったり、同僚に電子メールの返信を送ったり、あなたに代わって金融取引を完了したりすることができます。これを行うためには、モデルは一連の外部ツールにアクセスするだけでなく、自己主導的にあらゆるタスクを計画し実行する能力を持たなければなりません。
このような推論、論理、外部情報へのアクセスの組み合わせはすべて生成AIモデルにつながり、生成AIモデルの独立した能力を拡張する知的身体またはプログラムという概念につながる。このホワイトペーパーでは、これらすべてと関連する側面をより詳細に探求する。
知的身体とは何か?
最も基本的な形として、生成的AIインテリジェンスは、世界を観察し、利用可能なツールを使って行動することで目標を達成しようとするアプリケーションと定義することができる。インテリジェンスは自律的であり、特に果たすべき適切な目標や意図が与えられている場合には、人間の介入とは無関係に行動することができる。また、インテリジェン ティアは目標達成に向けて積極的に行動することもできる。人間からの明示的な指示がなくても、知的生命体は最終的な目標を達成するために次に何をすべきかを推論することができる。AIにおける知能の概念は非常に一般的で強力なものであるが、このホワイトペーパーでは、出版時点で生成AIモデルが構築できる特定のタイプの知能に焦点を当てている。
知能の内部構造を理解するために、まず、知能の行動、行動、意思決定を促す基本的な構成要素について説明しよう。これらの構成要素の組み合わせは認知アーキテクチャーと呼ぶことができ、これらの構成要素を組み合わせたり組み合わせたりすることで実現できる、このようなアーキテクチャーは数多く存在する。コア機能に焦点を当てると、図1に示すように、知的体の認知アーキテクチャには3つの基本コンポーネントがある。
モデリング
インテリジェンティアの文脈では、モデルとは言語モデル(LM)のことであり、インテリジェンティアのプロセスにおいて中央集権的な意思決定者として使用される。インテリゲンチアで使用されるモデルは、ReAct、Chain of Thought、Thinking Tree などの命令ベースの推論や論理的フレームワークに従うことができる、1つまたは複数のLMである。モデルは一般的なもの、マルチモーダルなもの、あるいは特定のスマートボディアーキテクチャのニーズに合わせて微調整されたものなどがある。最良の結果を得るには、意図するエンド・アプリケーションに最適で、コグニティブ・アーキ テクチャで使用する予定のツールに関連するデータ・シグネチャでトレーニングされたモデルを使用す るのが理想的です。通常、モデルはインテリジェンスの特定の構成設定(ツールの選択、オーケストレーショ ン/推論設定など)を使用してトレーニングされないことに注意することが重要です。ただし、インテリジェントボディがさまざまなコンテキストで特定のツールまたは推論ステッ プを使用するインスタンスなど、インテリジェントボディの機能を示す例を提供することで、インテリジェン トボディのタスクを実行するようにモデルをさらに最適化することができる。
アーティファクト
基礎となるモデルは、その優れたテキストや画像生成能力にもかかわらず、外部世界と相互作用することができないため、依然として制限されている。ツールはこのギャップを埋めるものであり、インテリジェンスが外部のデータやサービスと対話することを可能にすると同時に、基礎となるモデルそのものを超えた幅広い操作範囲を解き放ちます。ツールにはさまざまな形態があり、複雑さの深さもさまざまですが、一般的にはGET、POST、PATCH、DELETEなどの一般的なWeb APIメソッドと連携しています。例えば、ツールはデータベースの顧客情報を更新したり、天候データをフェッチしてインテリジェンスがユーザーに提供する旅行の推奨に影響を与えることができる。ツールにより、インテリジェンスは実世界の情報にアクセスして処理することができる。これにより、検索機能付きジェネレーション(ラグ)を使用することで、基礎となるモデルが単独で達成できる範囲を超えて、知能の能力を大幅に拡張することができます。ツールについては後ほど詳しく説明しますが、ツールは知能の内部機能と外部世界とのギャップを埋め、より幅広い可能性を引き出すものであることを理解することが最も重要です。
オーケストレーション層
オーケストレーションレイヤーは、インテリジェントボディがどのように情報を取得し、内部で推論を行い、その推論を次の行動や意思決定に役立てるかを制御する、周期的なプロセスを記述する。通常、このループは知的体がゴールまたは停止点に達するまで続く。オーケストレーションレイヤーの複雑さは、インテリジェント体とそれらが実行するタスクによって大きく異なる。ループの中には、決定ルールを持つ単純な計算もあれば、連鎖論理を含むもの、機械学習アルゴリズムを追加するもの、その他の確率的推論技術を実装するものもある。インテリジェント・オーケストレーション・レイヤーの実装については、コグニティブ・アーキテクチャのセクションで詳しく説明する。
インテリジェンシアとモデリング
インテリジェンスとモデルの違いをより明確に理解するために、次の図を考えてみよう:
モデリング | インテリジェントボディ |
---|---|
知識はトレーニングデータから得られるものに限られる。 | 知識は、ツールを介して外部システムと接続することで拡張される。 |
ユーザークエリに基づくシングルセッション推論/予測。モデルのために明示的に実装されない限り、セッション履歴や継続的なコンテキストの管理はありません。(例:チャット履歴) | セッション履歴(つまりチャットログ)を管理することで、オーケストレーションレイヤーで行われたユーザーからの問い合わせと決定に基づいて、推論/予測の複数のラウンドを可能にする。この場合、"ラウンド "とは、相互作用するシステムと知的身体との間の相互作用として定義される。(つまり、1つの受信イベント/クエリと1つのインテリジェントボディ応答)。 |
ネイティブツールの実装はない。 | ツールはネイティブのスマート・ボディ・アーキテクチャで実装されている。 |
ネイティブのロジックレイヤーは実装されていない。ユーザーは単純な質問としてプロンプトを作成したり、推論フレームワーク(CoT、ReActなど)を使用して複雑なプロンプトを作成し、モデルを予測に導くことができる。 | ネイティブのコグニティブ・アーキテクチャは、CoT、ReActなどの推論フレームワークや、LangChainなどの事前に構築されたインテリジェンス・フレームワークを使用する。 |
認知アーキテクチャ:知性の仕組み
忙しい厨房にいるシェフを想像してみてほしい。彼らの目標はレストランの客においしい料理を提供することであり、そのためには計画、実行、調整のサイクルが必要である。
- 顧客の注文やパントリーや冷蔵庫の食材などの情報を収集する。
- 彼らは、今集めた情報をもとに、どのような料理が作れるか、どのような味付けができるかを推論する。
- 野菜を切り、スパイスを混ぜ、肉を炒める。
各段階において、シェフは必要に応じて調整を行い、食材がなくなったり、顧客からフィードバックを受けたりすると、計画を練り直し、前回の結果をもとに次の行動計画を決定する。この情報摂取、計画、実行、調整というサイクルは、シェフが目標を達成するために採用する独自の認知アーキテクチャを表している。
シェフのように、インテリジェントな身体は、認知アーキテクチャを使用して、情報を繰り返し処理し、情報に基づいた決定を下し、以前の出力に基づいてその後の行動を洗練させることで、最終的な目標を達成することができる。知的体の認知アーキテクチャの中心には、記憶、状態、推論、計画の維持を担うオーケストレーション層がある。この層は、急速に発展しているキューエンジニアリングの分野と関連するフレームワークを利用して推論と計画を導き、知的体が環境と相互作用し、タスクをより効果的に完了できるようにする。言語モデルのためのキューエンジニアリングフレームワークとタスクプランニングの分野の研究は急速に発展しており、様々な有望なアプローチが生み出されている。網羅的なリストではありませんが、このホワイトペーパーの出版時点で最も人気のあるフレームワークと推論技術を以下に示します:
- ReActは、キューエンジニアリングフレームワークであり、言語モデルがユーザのクエリを推論し、行動するための思考プロセス戦略を提供する。
- CoTには、自己言及的、能動的キューイング、マルチモーダルCoTなど、さまざまなサブテクニックがあり、それぞれ特定の用途に応じて長所と短所がある。
- 手がかり工学のフレームワークである思考ツリー(ToT)は、探索的または戦略的な予見タスクに理想的に適している。思考連鎖プロンプトを一般化し、言語モデルを用いて一般的な問題解決への中間段階として機能する様々な思考連鎖を探索することを可能にする。
知的ボディは、上記の推論技術の1つ、または他の多くの技術を使用して、与えられたユーザー要求に対して次に最適なアクションを選択することができます。例えば、以下のようにプログラムされたものを考えてみよう。 リ・アクト フレームワークは、ユーザークエリのインテリジェンスに対して適切なアクションとツールを選択する。一連の流れは次のようになる:
- ユーザーはスマートボディにクエリーを送信する。
- インテリジェンスがリ・アクト・シークエンスを開始
- インテリジェントなボディは、モデルに対して次のリアクトを生成するよう求めるプロンプトを提供する。
ステップのひとつと、それに対応する出力:
a. 質問:プロンプトとともに提供される、ユーザーのクエリーからの質問の入力
b. 振り返り:次に何をすべきかをモデリングする。
c. オペレーション:次にどのようなアクションを取るかについてのモデルの決定
i. ここでツールを選択することができる
最初の3つはモデルが選択できる既知のツールを表し、最後の3つは「ツール選択なし」を表す。
d. 操作入力:ツールがある場合、どのような入力をツールに提供するかについてのモデルの決定。
e. 観察:操作の結果/入力シーケンスの操作
i. この思考/操作/インプット/観察は、必要なだけ何度でも繰り返すことができる。
f. 最終的な答え: モデルによって提供される、元のユーザークエリに対する最終的な答え。
4.ReActループが終了し、最終的な回答PSがユーザーに提供される:ReAct実装ロジック・ハンズオン
図2に示すように、モデル、ツール、およびインテリジェンスは、ユーザーの元のクエリに基づいて、情報に基づいた簡潔な応答をユーザーに提供するために協調して動作するように構成されています。モデルが先験的な知識に基づいて答えを推測する(錯覚を起こす)一方で、ツール(フライト)を使ってリアルタイムの外部情報を検索する。この追加情報はモデルに提供され、実際の事実データに基づいてより多くの情報に基づいた意思決定を可能にし、集約されてユーザーにフィードバックされる。
まとめると、インテリジェント・ボディの反応の質は、適切な道具を選択する能力や、その道具がどれだけ適切に定義されているかを含め、モデルがこれらの様々なタスクを推論し、操作する能力に直接関係することができる。シェフが新鮮な食材を使って料理を作り、顧客からのフィードバックに注意を払うように、知的身体は健全な推論と信頼できる情報に頼って最適な結果を出す。次のセクションでは、インテリジェンスが新鮮なデータに接続する様々な方法について掘り下げていく。
道具:外の世界への鍵
言語モデルは情報を処理することには長けているが、現実世界を直接認識し、影響を与える能力に欠けている。このため、外部のシステムやデータと相互作用する必要がある状況では、その有用性が制限される。つまり、ある意味、言語モデルは学習データから学習したものだけが優れているということだ。しかし、どんなに多くのデータをモデルに与えても、モデルには外界と相互作用する基本的な能力が欠けています。では、どうすればモデルに、リアルタイムでコンテキストを意識した方法で外部システムと対話する能力を与えることができるのだろうか?関数、拡張機能、データストア、プラグインはすべて、この重要な機能をモデルに提供する方法です。
ツールにはさまざまな呼び名があるが、私たちの基礎となるモデルと外界との接点を作るものである。この外部システムやデータとの接続により、我々の知性体はより正確で信頼性の高い様々なタスクを実行できるようになる。例えば、ツールは、知的体がスマートホームの設定を調整したり、カレンダーを更新したり、データベースからユーザー情報を取得したり、特定の指示セットに基づいて電子メールを送信したりすることを可能にする。
このホワイトペーパーの日付の時点で、Googleモデルが相互作用できるツールには、エクステンション、ファンクション、データストアの3つの主要なタイプがあります。インテリジェンスにツールを装備することで、世界を理解するだけでなく、それに基づいて行動するための巨大な可能性を解き放ち、数え切れないほどの新しいアプリケーションと可能性への扉を開くことができる。
エクステンション
エクステンションを理解する最も簡単な方法は、標準化された方法でAPIとインテリジェンスの間のギャップを埋め、インテリジェンスが基本的な実装に関係なくAPIをシームレスに実行できるようにすることだと考えることです。例えば、ユーザーがフライトを予約できるようにすることを目的としたインテリジェンスを構築したとしよう。フライト情報を取得するためにGoogle Flights APIを使用したいことはわかっているが、スマート本体にこのAPIエンドポイントを呼び出させる方法がわからない。
1つのアプローチは、入力されたユーザークエリを受け取り、関連情報を解析し、APIコールを行うカスタムコードを実装することかもしれない。例えば、フライト予約のユースケースでは、ユーザーは "オースティンからチューリッヒへのフライトを予約したい "と言うかもしれない。この場合、我々のカスタムコードソリューションは、APIコールを試みる前に、ユーザークエリから関連するエンティティとして "Austin "と "Zurich "を抽出する必要がある。しかし、ユーザーが出発都市を指定せずに「チューリッヒ行きのフライトを予約したい」と言ったらどうなるだろうか?必要なデータがなければ、APIコールは失敗し、そのようなエッジで極端なケースを捕捉するために、より多くのコードを実装する必要がある。このアプローチはスケーラブルではなく、実装されたカスタムコードの範囲を超えるような状況では簡単に失敗してしまう。
より確実なアプローチは、エクステンションを使うことだ。エクステンションは、以下のような方法でインテリジェンスとAPIのギャップを埋める:
- API エンドポイントの使い方をインテリジェンスに教えるために、例を使用する。
- APIエンドポイントを正常に呼び出すために必要なパラメータをインテリジェンスに教える。
拡張機能はインテリジェンスから独立して構築することもできますが、インテリジェンス の構成の一部として提供する必要があります。インテリジェントボディは、実行時にモデルと例を使用して、ユーザーのクエリを解 決するのに適切な拡張機能を決定します。このことは、インテリジェントボディがタスクに最も適したエクステンションを動的に選択できるようにする、エクステンションの主な利点である組み込みの例タイプを強調します。
ソフトウェア開発者は、ユーザーの問題を解決するときにどのAPIエンドポイントを使うかを決める。同じように、Intelligentsia/Model Stack は既知の拡張機能のセットを使って、ユーザーのクエリに最適なものを決定します。エクステンションの動作を見たい場合は ジェミニ 設定]>[拡張機能]を選択し、テストしたい拡張機能を有効にして、アプリ上で試してみてください。例えば、Google Flightsエクステンションを有効にして、Geminiに「来週の金曜日にオースティンからチューリッヒへのフライトを表示する」ように頼むことができる。
サンプル・エクステンション
エクステンションの使用を簡単にするために、Google はすぐにプロジェクトにインポートでき、最小限の設定で使用できる、すぐに使えるエクステンションを多数提供しています。例えば、Code Snippet 1のcode interpreterエクステンションでは、自然言語の記述からPythonコードを生成して実行することができます。
パイソン
インポートvertexai
インポート pprint
project_id = "あなたのプロジェクトID"
REGION = "us-central1"
vertexai.init(project=PROJECT_ID, location=REGION)
from vertexai.preview.extensions import Extension
extension_code_interpreter = Extension.from_hub("code_interpreter")
CODE_QUERY = """バイナリツリーをO(n)時間で反転させるpythonメソッドを書いてください。"""
response = extension_code_interpreter.execute()
operation_id = "generate_and_execute"、
operation_params = {"query": CODE_QUERY}.
)
print("生成されたコード:")
pprint.pprint({response['generated_code']})
# 上記のスニペットは以下のコードを生成します。
#生成コード。
# class TreeNode.
# def __init__(self, val=0, left=None, right=None):
# self.val = val
# self.left = left
# self.right = right
パイソン
def invert_binary_tree(root).
"""
バイナリツリーを反転します。
引数
root: バイナリ木のルート。
Args: root: バイナリ木のルート。
反転されたバイナリ木のルート。
"""
if not root: return None
None を返す。
# 左と右の子を再帰的に入れ替える。
root.left, root.right = \
invert_binary_tree(root.right), invert_binary_tree(root.left)
invert_binary_tree(root.left)
# 使用例
# サンプル・バイナリツリーを構築する
# 4
# / \
# 2 7
# 2 7
# 1 3 6 9
root = TreeNode(4)
root.left = TreeNode(2)
root.right = TreeNode(7)
root.left.left = TreeNode(1)
root.left.right = TreeNode(3)
root.right.left = TreeNode(6)
root.right.right = TreeNode(9)
# バイナリツリーを反転する
inverted_root = invert_binary_tree(root)
コード・スニペット 1. コード・インタープリター・エクステンションは、Pythonコードを生成して実行する。
要約すると、エクステンションはインテリジェンスに、外界を知覚し、外界と相互作用し、外界に影響を与えるためのさまざまな方法を提供する。これらのエクステンションの選択と呼び出しは、エクステンション設定の一部として定義されている例の使用によって導かれる。
関数
ソフトウェア工学の分野では、関数は特定のタスクを達成するために使用され、必要に応じて再利用できる自己完結型のコードモジュールとして定義されている。ソフトウェア開発者がプログラムを書くとき、通常、様々なタスクを実行するために多くの関数を作成します。また、function_aやfunction_bを呼び出すロジックや、期待される入出力も定義します。
関数は知能の領域でもよく似た働きをするが、ソフトウェア開発者の代わりにモデルを使うことができる。モデルは、既知の関数のセットを受け取り、その仕様に基づいて、それぞれの関数をいつ使うか、その関数がどのような引数を取るかを決定することができる。関数は拡張機能とはいくつかの点で異なります:
- モデル出力関数とそのパラメータはあるが、リアルタイムのAPIコールはない。
- ファンクションはクライアント側で実行され、エクステンションはスマートボディ側で実行される。
グーグル・フライトの例で説明すると、図7のようになる。
ここでの主な違いは、ファンクションもインテリジェンスもGoogle Flights APIと直接やりとりしないということである。では、実際にAPIコールはどのように行われるのだろうか?
関数を使用する場合、以下の図8と図9に示すように、実際のAPIエンドポイントへの呼び出しのロジックと実行は、インテリジェンスからクライアント・アプリケーションに転送される。これにより、開発者はアプリケーション内のデータの流れをより細かく制御できるようになります。開発者が拡張機能よりも関数の使用を選択する理由はたくさんありますが、一般的な使用例をいくつか挙げます:
- APIは、エージェントアーキテクチャのプロセスで直接呼び出すのではなく、アプリケーションスタックの別のレベルで呼び出す必要があります(例えば、ミドルウェアシステムやフロントエンドフレームワークなどを使用)。
- エージェントがAPIを直接呼び出すことを妨げるセキュリティまたは認証の制限(例えば、APIがインターネットに公開されていない、またはエージェントインフラがAPIにアクセスできない)。
- エージェントがリアルタイムでAPIを呼び出すことを妨げる、時間または一連の操作の制限(バッチ操作、手動レビュープロセスなど)。
- エージェントが実行できない API レスポンスには、追加のデータ変換ロジックが必要です。例えば、いくつかのAPIエンドポイントは、返される結果の数を制限するためのフィルタリングメカニズムを提供していません。クライアント側で関数を使用することで、開発者はこれらの変換を実行する機会を増やすことができます。
- 開発者は、APIエンドポイントのための追加インフラをデプロイすることなく、プロキシ開発を反復したい(例えば、関数コールはAPIのための「ステーキングシミュレーション」として機能することができる)。
図8に示すように、2つのアプローチの違いは、内部アーキテクチャの観点からはより微妙なものであるが、関数コールは、追加の制御を提供し、外部インフラへの依存を低減するため、開発者にとって魅力的な選択肢となる。
ユースケース
モデルは、エンドユーザーの複雑なクライアント側の実行プロセスを処理するために関数を呼び出すために使用することができます。インテリジェント開発者は、言語モデルにAPIの実行を管理させたくない場合があります(拡張機能の場合と同様)。次の例を考えてみよう。インテリジェントボディが、旅行コンシェルジュとして訓練され、休暇旅行の予約を希望するユーザーと対話する。目標は、インテリジェントボディがミドルウェアアプリケーションで使用できる都市のリストを生成し、ユーザーが旅行を計画するための画像やデータなどをダウンロードすることです。ユーザーはこう言うかもしれない:
家族でスキー旅行に行きたいのですが、どこに行こうか迷っています。
このモデルの典型的なプロンプトでは、出力は次のようになる:
もちろん、家族でのスキー旅行で検討すべき都市のリストはここにある:
- アメリカ合衆国コロラド州クレステッドビュート
- カナダ、ブリティッシュ・コロンビア州ウィスラー
- スイス、ツェルマット
上記の出力には必要なデータ(都市名)が含まれているが、そのフォーマットは解析には適していない。関数を呼び出すことで、この出力を構造化されたスタイル(例えばJSON)でフォーマットするようにモデルに教えることができます。ユーザーから同じ入力プロンプトが与えられた場合、関数からのサンプルJSON出力はコードスニペット5のようになります。
滑脱
関数_call {
name: "display_cities"
args: {
"cities": ["Crested Butte", "Whistler", "Zermatt"], "preferences": "skiing" (スキー)
「プリファレンス": "スキー"
}
}
コードスニペット5. 都市のリストとユーザープリファレンスを表示するためのサンプル関数コールロード このJSONロードはモデルによって生成され、クライアントサーバに送信されます。この特定のケースでは、モデルによって提供された都市を取得し、画像を検索するためにGoogle Places APIを呼び出し、フォーマットされたリッチコンテンツとしてユーザーに提供します。図9のシーケンス図を参照してください。
図9の例の結果は、クライアントUIがGoogle Places APIをコールするために必要なパラメータを「空白を埋める」ためにモデルが使用されるということです。クライアントUIは、実際のAPIコールを管理するために、返された関数の中でモデルによって提供されたパラメータを使用します。これは関数呼び出しの1つのユースケースに過ぎませんが、他にも考慮すべきシナリオはたくさんあります:
- 言語モデルにコードで使用できる関数を提案してもらいたいが、コードにクレデンシャルを含めたくない。関数呼び出しは関数を実行しないので、関数に関する情報を持つクレデンシャルをコードに含める必要はありません。
- 完了までに数秒以上かかる可能性のある非同期処理を実行している。これらのシナリオは、非同期操作であるため、関数呼び出しに適用されます。
- 関数呼び出しとその引数を生成したシステムとは別のデバイスで関数を実行したい。
関数について覚えておくべき重要なことの1つは、APIコールの実行とアプリケーション内のデータの全体的な流れを開発者がよりコントロールできるようにするためのものだということです。図9の例では、開発者はAPI情報をインテリジェンスに返さないことを選択した。しかし、アプリケーションのアーキテクチャによっては、外部のAPI呼び出しデータをインテリジェンス本体に返し、将来の推論、ロジック、アクションの選択に影響を与えることが理にかなっている場合がある。最終的に、特定のアプリケーションに何が適切かを選択するのは、アプリケーション開発者次第である。
関数サンプルコード
スキー休暇のシーンから上記の出力を得るために、gemini-1.5-flash-001モデルで動作するように各コンポーネントを構築してみましょう。まず、display_cities関数を単純なPythonメソッドとして定義します。
パイソン
def display_cities(cities: list[str], preferences: Optional[str] = None).
"""ユーザの検索クエリと環境設定に基づいて都市のリストを提供します。
引数
preferences (str): ユーザーの検索条件、
ビーチ、レストラン、バーベキューなど。
cities (list[str]): ユーザにお勧めする都市のリスト。
戻り値: リスト[str]:ユーザーに推奨される都市のリスト。
list[str]:ユーザーにお勧めする都市のリスト。
"""
都市を返す
コード・スニペット 6. 都市のリストを表示する関数のサンプル Python メソッド。
次に、モデルをインスタンス化し、ツールを構築し、ユーザーのクエリとツールをモデルに渡します。以下のコードを実行すると、コードスニペットの下部に示された出力が生成されます。
パイソン
from vertexai.generative_models import GenerativeModel, Tool, FunctionDeclaration
model = GenerativeModel("gemini-1.5-flash-001")
display_cities_function = FunctionDeclaration.from_func(display_cities)
tool = Tool(function_declarations=[display_cities_function])
message = "家族でスキー旅行に行きたいのですが、どこに行けばいいかわかりません。"
res = model.generate_content(message, tools=[tool])
print(f "関数名: {res.candidates[0].content.parts[0].function_call.name}")
print(f "関数引数:{res.candidates[0].content.parts[0].function_call.args}")
> 関数名:display_cities
関数名: display_cities > 関数引数: {'preferences': 'skiing', 'cities': ['Aspen', 'Vail'.
パークシティ']}。
コードスニペット7. ツールを構築し、ユーザークエリとともにモデルに送信し、関数呼び出しができるようにする。
要約すると、関数は、アプリケーション開発者がデータフローとシステム実行をきめ細かく制御することを可能にするシンプルなフレームワークを提供します。開発者は、特定のアプリケーションアーキテクチャの要件に応じて、外部データを返すことでインテリジェンスを「ループ内」に保持するか、省略するかを任意に選択できます。
データストレージ
言語モデルを、学習データを含む膨大なライブラリーと想像してほしい。しかし、常に新しい本を入手する図書館とは異なり、この図書館は静的なままであり、最初のトレーニングで得た知識しか保持していない。実世界の知識は常に変化しているため、これは難題である。
開発データストレージは、よりダイナミックで最新の情報へのアクセスを提供し、モデルの応答が常に事実と関連性に基づいていることを保証することによって、この制限に対処する。
よくあるシナリオを考えてみましょう。開発者は、おそらくスプレッドシートやPDFの形で、モデルに少量の追加データを提供する必要があるかもしれません。
データストアにより、開発者はインテリジェンスに追加データを元の形式で提供できるため、時間のかかるデータ変換やモデルの再トレーニング、微調整が不要になります。データストアは、入力されたドキュメントを、インテリジェンスが次のアクションやユーザーへの応答を補完するために必要な情報を抽出するために使用できるベクトルデータベース埋め込みセットに変換します。
実現と応用
生成AIインテリジェンスの文脈では、データストレージは多くの場合ベクトルデータベースとして実装され、開発者はインテリジェンスが実行時にアクセスできることを期待している。ここではベクトル・データベースについて深くは触れないが、理解すべき重要な点は、ベクトル・データベースはデータを高次元ベクトルまたは提供されたデータの数学的表現であるベクトル埋め込みという形で保存するということである。近年、言語モデルによるデータストアの最も典型的な使用例のひとつは、RAG(Retrieval Augmented Generation)アプリケーションである。これらのアプリケーションは、例えば様々な形式のデータへのアクセスをモデルに提供することで、モデル知識の幅と深さを拡張しようとするものである:
- ウェブサイトの内容
- PDF、Word文書、CSV、スプレッドシート、その他の形式で構造化されたデータ。
- HTML、PDF、TXT、その他の形式の非構造化データ。
各ユーザーリクエストとインテリジェントボディのレスポンスサイクルの基本的な プロセスは、通常、図13に示すようにモデル化される。
-
- ユーザーのクエリは、クエリの埋め込みを生成するために埋め込みモデルに送られる。
- 次に、マッチングアルゴリズム(ScaNNなど)を使って、クエリー埋め込みをベクトルデータベースの内容とマッチングさせる。
- ベクターデータベースからテキスト形式でマッチを取得し、スマートボディに送り返す。
- インテリゲンチアは、ユーザーからの問い合わせと検索されたコンテンツを受信し、応答やアクションを作成します。
5.最終応答をユーザーに送る
最終的な結果は、インテリジェンスがユーザーのクエリと既知のデータストアをベクトル検索で照合し、生のコンテンツを取得し、さらなる処理のためにオーケストレーションレイヤーとモデルに提供するアプリケーションである。次のステップは、最終的な答えをユーザーに提供すること、または結果をさらに最適化するために追加のベクトル検索を実行することである。ReAct推論/プランニングを備えたRAGを実装する知的ボディとの対話の例を図14に示す。
ツールレビュー
要約すると、拡張機能、関数、およびデータストアは、インテリジェンスが実行時に使用できるいくつかの異なるタイプのツールを構成しています。各ツールにはそれぞれ目的があり、インテリジェンス開発者の判断で一緒に使用することも、別々に使用することもできます。
エクステンション | 関数呼び出し | データストレージ | |
---|---|---|---|
はこびだす | インテリジェントなボディサイドの実装 | クライアント側の実行 | インテリジェントなボディサイドの実装 |
ユースケース |
|
|
開発者は、以下のデータ型のいずれかを使用してRAG(Retrieval Augmented Generation)を実装したいと考えている:
|
モデル・パフォーマンスの向上と的を絞った学習
モデルを効果的に使用するための重要な側面は、アウトプットを生成する際に適切なツールを選択する能力である。一般的なトレーニングは、モデルがこのスキルを身につけるのに役立つ。しかし、現実のシナリオでは通常、それ以上のことが要求される。トレーニングデータの知識。基本的な料理の腕前と、特定の料理を極めることの違いを考えてみよう。どちらも基本的な料理の知識が必要だが、後者はよりニュアンスのある結果を得るために的を絞った学習が必要だ。
モデルがこの種の特定の知識を習得するのを助けるために、いくつかのアプローチが存在する:
- 文脈学習:このアプローチは、推論時にヒントやツール、小さなサンプルサンプルを一般的なモデルに提供し、特定のタスクにこれらのツールをいつどのように使うかを「その場で」学習できるようにするもので、ReActフレームワークは自然言語におけるこのアプローチの一例である。
- 検索ベースのコンテキスト学習:この手法は、最も関連性の高い情報、ツール、関連する例を外部ストレージから検索することで、モデルのヒントを動的に入力する。この例として、Vertex AIエクステンションの「example store」や、前述のデータストアRAGアーキテクチャが挙げられる。
- ファインチューニングに基づく学習:この方法では、推論を行う前に、より大きな例固有のデータセットでモデルをトレーニングする。これは、ユーザーからの問い合わせを受ける前に、モデルが特定のツールをいつ、どのように適用するかを理解するのに役立つ。
それぞれの学習方法の目標をさらに説明するために、料理の例えに戻って探ってみよう。
- あるシェフが、特定のレシピ(ヒント)、いくつかの重要な食材(関連ツール)、そして顧客からいくつかのサンプル料理(サンプルレス)を受け取ったとする。この限られた情報とシェフの一般的な料理知識に基づいて、シェフはレシピと顧客の好みに最も合う料理を「その場で」調理する方法を考え出す必要がある。これが文脈学習である。
- ここで、食材とレシピ(例とツール)が満載のパントリー(外部データストレージ)を備えた、品揃え豊富なキッチンにいるシェフを想像してみよう。シェフはパントリーから食材やレシピを動的に選択し、顧客のレシピや好みに合わせることができる。これにより、シェフは既存の知識と新しい知識を活用して、よりスマートで洗練された料理を作ることができる。これが検索ベースの文脈学習である。
- 最後に、シェフを学校に送り、新しい料理や料理(より大きな例固有のデータセットで事前に訓練されたもの)を学ばせることを想像してみよう。これにより、シェフはより深い理解をもって将来の未知の顧客のレシピに取り組むことができる。シェフに次のことをさせたい場合
このアプローチは、特定の料理(知識分野)を得意とする場合に最適である。これは微調整に基づいた学習です。
各アプローチには、スピード、コスト、レイテンシーの面で、それぞれ独自の長所と短所がある。しかし、インテリジェントなボディフレームワークにこれらの技術を組み合わせることで、利点を活用し、欠点を最小限に抑えることができる。
LangChainでIntelligentsiaをクイックスタート
実行可能なインテリジェンスの動作例を提供するために、LangChainとLangGraphライブラリを使って簡単なプロトタイプを作ります。これらの人気のあるオープンソースライブラリは、論理と推論のシーケンスを "リンク "させることでクライアントインテリジェンスを構築することを可能にします。コードスニペット8に示すように、gemini-1.5-flash-001モデルといくつかの簡単なツールを使って、ユーザーからの多段階クエリに回答します。
使用するツールは、SerpAPI(Google検索用)とGoogle Places APIです。コードスニペット8で説明したプロシージャを実行すると、コードスニペット9にサンプル出力が表示されます。
パイソン
from langgraph.prebuilt import create_react_agent
from langchain_core.tools import tool
from langchain_community.utilities import SerpAPIWrapper
from langchain_community.tools import GooglePlacesTool
os.environ["SERPAPI_API_KEY"] = "XXXXX"
os.environ["GPLACES_API_KEY"] = "XXXXX"
ツール
def search(query: str):
"""SerpAPIを使用してGoogle検索を実行します。""""
search = SerpAPIWrapper()
return search.run(クエリ)
ツール
def places(query: str): """Google Placesを使用します(query: str):""
"""Googleプレイスクエリを実行するためにGoogle Places APIを使用します。""""
places = GooglePlacesTool()
return places.run(クエリ)
model = ChatVertexAI(model="gemini-1.5-flash-001")
tools = [検索, 場所]
query = "先週のフットボールでテキサス・ロングホーンズはどこと対戦しましたか? 相手チームのスタジアムの住所はどこですか?"
agent = create_react_agent(model, tools)
input = {"messages": [("human", query)]}.
for s in agent.stream(input, stream_mode="values"):
message = s["messages"][-1].
if isinstance(message, tuple).
print(message)
else: message.pretty_print(message, tuple): print(message)
message.pretty_print()
コード・スニペット8.ツールLangChainとLangGraph Intelligentsiaの使用例
滑脱
=============================== ユーザー・ニュース 先週のテキサスロングホーンズのフットボール対戦相手は?相手チームのスタジアムの住所は? ツール呼び出し:検索 パラメータ 検索:テキサスロングホーンズフットボールスケジュール ツールメッセージ========================================================================================================ツール 名前:検索 {...結果: "NCAAディビジョンIフットボール、ジョージア州、日付..."}。 AIニュース =========================================================================== テキサス・ロングホーンズは先週、ジョージア・ブルドッグスと対戦しました。 ツール呼び出し:場所 パラメータ クエリ:ジョージア・ブルドッグ・スタジアム ================================ ツール・メッセージ =============================================================== 名前:場所 {...サンフォードスタジアムの住所:100サンフォードロード...}。 AIメッセージ================================================================================================================================================ Georgia Bulldogs Stadiumの住所は100 Sanford Road, Athens, Georgia 30602です。
コードスニペット9 コードスニペット8のプログラムの出力。
これはインテリジェントな体のかなり単純な例だが、モデル、オーケストレーション、ツールの基本的なコンポーネントがすべて特定の目標を達成するために連携していることを示している。最後のセクションでは、Vertex AIインテリジェンスやGenerative PlaybooksのようなGoogleスケールのホスティング製品において、これらのコンポーネントがどのように組み合わされているかを探る。
バーテックスAIインテリジェンスを使用した生産アプリケーション
GoogleのVertex AIプラットフォームは、先に説明したすべての重要な要素を含む完全にホストされた環境を提供することで、このプロセスを簡素化します。開発者は、自然言語インタフェースを使用して、インテリジェンスの主要要素(目標、タスク記述、ツール、タスク委譲のためのサブインテリジェンス、例)を素早く定義し、望ましいシステム動作を簡単に構築することができます。さらに、このプラットフォームは、インテリジェンスのテスト、評価、パフォーマンス測定、デバッグ、および開発されたインテリジェンスの全体的な品質向上に使用できる一連の開発ツールを提供します。これにより、開発者はインテリジェンスの構築と最適化に集中でき、複雑なインフラストラクチャ、デプロイメント、メンテナンスはプラットフォーム自身が管理します。
図 15 では、Vertex Agent Builder、Vertex Extensions、Vertex Function Calls、Vertex Example Storage などのさまざまな機能を使用する Vertex AI プラットフォーム上に構築されたインテリジェンスのアーキテクチャ例を示します。このアーキテクチャには、量産可能なアプリケーションに必要なさまざまなコンポーネントの多くが含まれています。
私たちの公式ドキュメントにある、構築済みのスマートボディ・アーキテクチャの例を試すことができる。
概要
このホワイトペーパーでは、生成的AI知能の基本的な構成要素、その構成、および認知アーキテクチャの形でそれらを実装する効果的な方法について説明する。このホワイトペーパーの主なポイントは以下の通りです:
- インテリゲンチアは、ツールを使用して言語モデルの機能を拡張し、リアルタイムの情報にアクセスしたり、実用的なアクションを提案したり、複雑なタスクを自律的に計画して実行したりします。インテリゲンチャは、1つまたは複数の言語モデルを使用して、いつ、どのように状態を遷移させるかを決定し、外部ツールを使用して、モデルが単独で実行することが困難または不可能な複雑なタスクを実行することができます。
- インテリジェンスの動作の中心には、推論、計画、意思決定を構築し、その行動を導く認知アーキテクチャーであるオーケストレーション層がある。様々な推論技術(ReAct、思考連鎖、思考ツリーなど)は、オーケストレーション層が情報を受け取り、内部推論を実行し、情報に基づいた意思決定や応答を生成するためのフレームワークを提供する。
- ツール(エクステンション、ファンクション、データストアなど)は、インテリジェンスにとって外部への鍵の役割を果たし、外部システムとのやり取りや、トレーニングデータ以外の知識へのアクセスを可能にする。エクステンションは、インテリジェンスと外部APIの橋渡しをする。これにより、APIコールの実行とリアルタイム情報の取得が可能になる。ファンクションは、責任の分担によって開発者によりきめ細かい制御を提供し、インテリジェンスがクライアント上で実行可能なファンクションパラメータを生成できるようにする。データストアは、構造化データまたは非構造化データへのアクセスをインテリジェンスに提供し、データ駆動型アプリケーションをサポートします。
知的体の未来にはエキサイティングな進歩が待っている。ツールがより洗練され、推論能力が強化されれば、インテリジェンスはますます複雑な問題を解決できるようになるだろう。さらに、「インテリジェンスの連鎖」という戦略的アプローチも勢いを増していくだろう。それぞれが特定の領域やタスクに秀でた、専門化されたインテリジェンスを組み合わせることで、業界や問題領域を超えて優れた結果を出すことができる。
複雑なインテリジェンス・アーキテクチャを構築するには、反復的なアプローチが必要であることを忘れてはならない。実験と改良は、特定のビジネスケースや組織のニーズに対する解決策を見つけるための鍵です。インテリジェンスは、そのアーキテクチャを支える基本モデルの生成的な性質により、2つとして同じものはありません。しかし、基盤となる各コンポーネントの強みを活用することで、言語モデルの機能を拡張し、真の価値をもたらすインパクトのあるアプリケーションを作成することができます。
注
- Shafran, I., Cao, Y. et al., 2022, 'ReAct: Synergising Reasoning and Acting in Language Models'. にて入手可能。
https://arxiv.org/abs/2210.03629 - Wei, J., Wang, X. et al., 2023, 'Chain-of-Thought Prompting Elicits Reasoning in Large Language Models'.
https://arxiv.org/pdf/2201.11903.pdf。 - Wang, X. et al., 2022, 'Self-Consistency Improves Chain of Thought Reasoning in Language Models'.
https://arxiv.org/abs/2203.11171。 - Diao, S. et al., 2023, 'Active Prompting with Chain-of-Thought for Large Language Models'. にて入手可能。
https://arxiv.org/pdf/2302.12246.pdf. - Zhang, H. et al., 2023, 'Multimodal Chain-of-Thought Reasoning in Language Models'. にて入手可能。
https://arxiv.org/abs/2302.00923. - Yao, S. et al., 2023, 'Tree of Thoughts: Deliberate Problem Solving with Large Language Models'. にて入手可能。
https://arxiv.org/abs/2305.10601. - Long, X., 2023, 'Large Language Model Guided Tree-of-Thought'. にて入手可能。
https://arxiv.org/abs/2305.08291. - **Google Gemini Application」。 http://gemini.google.com。
- **Swagger.'OpenAPI仕様'. 入手先: **https://swagger.io/specification/.
- Xie, M., 2022, 'How does in-context learning work? との違いを理解するためのフレームワーク'.
伝統的な教師あり学習」。 https://ai.stanford.edu/blog/understanding-incontext/。 - Google Research「ScaNN (Scalable Nearest Neighbors)」。 で入手可能。
https://github.com/google-research/google-research/tree/master/scann. - **LangChain'。 入手先:**https://python.langchain.com/v0.2/docs/introduction/。