AIP Analyst のコンピュート使用量

AIP Analyst はエージェント型のアプリケーションです。1つの質問から、モデルの呼び出しや Foundry に対するクエリが何度も実行されることがあります。その使用量がどこで発生するかを理解すると、コストを予測し、モデルを選択し、効率的な分析を設計できます。

AIP Analyst の使用量は、次の2つのカテゴリーに分かれます。

• LLM トークン： モデルを呼び出すたびに入力トークンと出力トークンが消費され、モデルに応じたレートでコンピュート秒に換算されます。LLM トークン使用量を参照してください。
• フェデレーションされた Foundry コンピュート： 各ツール呼び出しは、オントロジー、データセット、関数などの基盤となる Foundry システムに対して実行されます。結果を要求して読み取るために使われるトークンに加え、そのシステムのコンピュートも消費します。フェデレーションされた Foundry コンピュートを参照してください。

Palantir とエンタープライズ契約を結んでいる場合は、コンピュート使用量の計算を進める前に、Palantir の担当者にお問い合わせください。

LLM トークン使用量

AIP Analyst は、会話をモデルに繰り返し送信し、レスポンスに基づいて処理を行います。各リクエストには、システム指示、ユーザーのメッセージ、有効なツールの定義、およびコンテキストに残っている以前のツール呼び出しの結果が含まれます。モデルの返答は、拡張思考を含めて出力トークンとして計上されます。

この設計には、次の3つの特徴があります。

• 会話が続くにつれて、トークン使用量が増加します。 新しいターンごとに、それまでのメッセージとツールの結果が再送信されるためです。長い分析では、終盤の質問の方が序盤の質問よりも、1つの質問あたりのコストが高くなります。
• サイズの大きいツールの結果が、使用量を左右する主な要因です。 数千個のオブジェクトを読み込んだり、列数の多い SQL 結果セットを返したり、長い PDF を読み取ったりすると、大量のテキストがコンテキストに追加されます。このテキストは、削除されるまで、それ以降のすべてのターンで再送信されます。
• 有効なツール自体にもコストがかかります。 ツールの定義が各リクエストに含まれるためです。ツールメニューで不要なカテゴリーを無効にすると、分析内のすべてのリクエストのサイズが小さくなります。

トークンからコンピュート秒への換算レートは、モデルによって大きく異なります。現在のレートについては、AIP の従量課金におけるコンピュート換算を参照してください。トークンの計数方法に関する一般的な情報については、AIP のトークンを参照してください。

保存済みの分析には、選択したモデルカテゴリーまたは特定のモデルが保持されます。カテゴリーで使用されるモデルは時間とともに変わることがあり、それに伴ってトークンからコンピュート秒への換算レートも変わる場合があります。分析ごとの設定を参照してください。

フェデレーションされた Foundry コンピュート

AIP Analyst のほとんどのツールは、それ自体では計算を行いません。代わりに、ユーザーに代わって既存の Foundry システムを呼び出し、そのシステムの通常のコンピュートモデルが適用されます。次のテーブルは、各ツールカテゴリーと処理を実行するシステムの対応を示しています。

可視化を作成やコンテキストのクリーンアップなど、可視化および計画カテゴリーのツールは、別のバックエンドにクエリを実行しません。コストは、結果の生成と読み取りに使われるトークンです。Workshop の参照ツールと Machinery の参照ツールも同様に動作します。どちらもクエリを実行するのではなく、リソースの設定を読み取るため、コストは返された定義を読み取るために使われるトークンです。これらのツールが提示するオブジェクトタイプ、関数、アクションタイプに対して後続の処理を行う場合は、対応するカテゴリーに課金されます。

AIP Analyst のオントロジーツールは、Object Explorer、Workshop、およびオントロジー SDK（OSDK）と同じオントロジーレイヤーにクエリを実行し、同じモデルで計測されます。AIP Analyst が実行するオントロジー集計は、オントロジー SDK アプリケーションからの同等のリクエストと同じように、集計クエリとして課金されます。異なるのはクエリの数です。未知のオントロジーを探索するエージェントは、既知の固定されたクエリに基づいて構築されたアプリケーションよりも、検索や、最終的に使われない中間クエリを多く実行します。

AIP Analyst が作成したリソースは、分析が終了した後もコンピュートを消費し続けます。公開済みの Quiver ダッシュボードや保存済みの Contour 分析は、誰かが開くたびにコンピュートを使用します。この使用量は、AIP Analyst ではなく、そのリソースに帰属します。

コストの帰属

Foundry のコンピュート秒は、通常、ユーザーではなくリソースに帰属します。AIP Analyst のトークン使用量は、次のように帰属します。

• 保存済みの分析： 使用量は分析リソースに帰属します。
• 埋め込み分析： 使用量は、AIP Analyst ウィジェットを含む Workshop モジュールなど、分析を所有するリソースに帰属します。
• 未保存の分析： デフォルトでは、使用量は分析を実行したユーザーに帰属します。未保存の分析のコスト帰属先設定が構成されている場合、使用量は代わりに、その設定で選択されたプロジェクトに帰属します。一般設定を参照してください。

AIP Analyst がほかのアプリケーションに委譲するコンピュートには、それぞれのアプリケーションの帰属ルールが適用されます。特にオントロジークエリでは、クエリの実行元となるリソースが存在する場合はそのリソースに、存在しない場合はクエリ対象のオブジェクトタイプにコンピュートが帰属します。オントロジークエリによる Foundry コンピュート使用量を調査するを参照してください。

使用量を監視する

使用量は、いくつかの粒度で確認できます。

• 分析中： セッション内のトークン推定ツールには、現在のコンテキストのサイズが表示されます。概要には、個々のツール呼び出しのトークン使用量が報告されるため、過剰なデータを読み込んだステップを容易に特定できます。
• エンロールメント全体： Control Panel から AIP トークン使用量データセットをエクスポートすると、モデル別およびリソース別に分類された日次のトークン消費量を確認できます。AIP トークン使用量データをエクスポートするを参照してください。
• ほかの使用量と併せて： Resource Management でプロジェクト別およびリソース別のコンピュート秒を確認し、AIP 使用量メトリクスでモデルへのリクエストを時系列で追跡します。

使用量を管理する

以下の方法では、質問できる内容を変えずに使用量を削減できます。

コンテキストを小さく保つ

• 不要になったデータを外します。 コンテキストのクリーンアップツールを使用するか、概要から個別のツール結果を非表示にして、大きな結果が毎ターン再送信されないようにします。
• 会話を続けるのではなく分岐します。 関連のない質問に移るときは、長い会話を続けるのではなく、新規タブを作成します。タブと分岐を参照してください。
• 読み込むのではなく集計します。 大きなオブジェクトセットを読み込んでモデルに要約を求めるよりも、オントロジー集計またはオントロジー SQL を優先します。集計された出力の1行にかかるコストは、その元となるオブジェクトのコストのごく一部です。

検索対象を絞る

• 検索範囲を制限します。 オントロジー、オブジェクトタイプグループ、プロジェクト、ステータス、重要性を制限すると、エージェントが発行する検索クエリの数と、その結果のサイズの両方が減ります。検索範囲を制限するを参照してください。
• 適切なコンテキストを事前に読み込みます。 関連するオブジェクトタイプやデータセットを最初に追加すると、探索のための検索がまったく不要になります。Workshop ウィジェットでは、コンテキストを事前に読み込み、有効にするツールを固定することで、ガイド付きワークフローの使用量をはるかに予測しやすくなります。
• 使用しないツールカテゴリーを無効にします。 有効なツールが少ないほどリクエストが小さくなり、エージェントが成果につながらない経路を探索する機会も減ります。

適切なモデルを選択する

最大のモデルと最小のモデルでは、料金が10倍以上異なります。最も高性能なモデルは本当に難しい推論にのみ使用し、日常的な参照や要約には小規模なモデルを優先します。質問が事前にわかっている埋め込みワークフローでは、モデルを明示的に設定してモデルセレクターを非表示にし、使用量を予測しやすくします。表示オプションとチャットコントロールを参照してください。

統合ツールと関数およびエージェントの比較

ワークフローを十分に理解できている場合は、エージェントのツールループから処理を切り出し、AIP Analyst が呼び出すリソースや、完全に単独で実行されるリソースに移すことができます。これにより、コストの特性と結果の信頼性の両方が変わります。

選択する際は、以下の指針を参考にしてください。

• 質問の内容がまだ固まっていない間は、統合ツールを優先します。 事前のモデリングが不要で、グラフ表示により各ステップを検証できる点が利点です。一方で、中間データがモデルのコンテキストを通過するため、コストがかかります。
• ロジックが安定したら、関数に移します。 関数を使用すると、本来なら多数のツール呼び出しが必要な処理を1回の呼び出しにまとめられます。中間データが分析のコンテキストに入ることはなく、結果は推論によるものではなく決定論的であり、コンピュート使用量は関数に帰属します。繰り返し実行することが想定される計算では、通常これが適切な選択です。また、エージェントに毎回ロジックを導き出させるよりも、一般にコストが低く、信頼性も高くなります。
• 計算ではなくアプローチを記録するには、スキルを使用します。 スキルは、ある種類の質問にどのように取り組むかを記録します。エージェントはその実行に引き続き統合ツールを使用するため、スキルは一貫性を向上させますが、それ自体でフェデレーションされたコンピュート使用量を削減するものではありません。
• 対話型セッションをブロックすべきでない処理には、Pro-code エージェントを使用します。 Pro-code エージェントは非同期で実行され、同期の関数実行の制限を受けないため、長時間実行されるタスクに適しています。

実用的なパターンは、これらのアプローチを組み合わせることです。分析を理解できるまで統合ツールで探索し、その後、安定したコストの高い部分を関数に移して、その結果の解釈と提示には引き続き AIP Analyst を使用します。

関連リソース

• AIP のコンピュート使用量
• オントロジークエリのコンピュート使用量
• 使用量の種類
• サポートされている LLM