Pipeline Builder の LLM を使用ノード

Pipeline Builder の LLM を使用ノードは、データに対して大規模言語モデル（LLM）を大規模に実行するための便利な方法を提供します。このノードは Pipeline Builder に統合されているため、さまざまなデータ加工の間に LLM の処理ロジックをシームレスに組み込むことができ、コードを記述せずに LLM をパイプラインに簡単に統合できます。

LLM を使用ノードには、事前に設計されたプロンプトテンプレートが含まれています。これらのテンプレートは、経験豊富なプロンプトエンジニアの専門知識を活用して、初心者でも簡単に LLM を使い始められるようにします。また、入力データセットの数行に対して試行を実行し、データセット全体でモデルを実行する前にプロンプトを繰り返し改善することもできます。このプレビュー機能は数秒で計算を完了するため、フィードバックループが短縮され、開発プロセス全体が改善されます。

利用するには、ユーザーはプラットフォーム管理者からカスタムワークフロー用の AIP 機能の利用権限を付与されている必要があります。

データセットを選択する

データセットに LLM を適用するには、ワークスペース内のデータセットノードを選択し、LLM を使用を選択します。

モデルを選択する

LLM を使用ノードは、Palantir が提供するモデルと登録済みモデルの両方に対応しています。Palantir が提供するモデルはデフォルトで利用可能で、GPT-4o やその他の対応する LLM などを選択できます。

Palantir が提供するモデルに加えて、LLM を使用ノードは、Data Connection の REST API ソースまたは Compute Moduleを元にする登録済みモデルにも対応しています。登録済みモデルを選ぶには、モデルセレクターで登録済みタブを選択します。

プロンプトを選択する

以下に、利用可能なテンプレートプロンプトのさまざまな例を示します。独自のプロンプトを作成するには、空のプロンプトを選択します。

分類

データをさまざまなカテゴリーに分類する場合は、分類プロンプトを使用します。

以下の例では、レストランのレビューをサービス、料理、雰囲気の3つのカテゴリーに分類するという仮の目的に合わせて、プロンプトにどのように入力するかを示します。

カテゴリー数項目では、出力列に含めるカテゴリーを1つ、複数、または指定した数にするかを選択できます。この例では、レビューが該当する可能性のあるすべてのカテゴリーを含めたいので、1つまたは複数のカテゴリーを選択します。

コンテキスト項目には、データの説明を入力します。この例では、Restaurant Review と入力します。

カテゴリー項目には、データを割り当てたいカテゴリーをそれぞれ入力します。この例では、レストランのレビューを3つのカテゴリーのいずれかに分類したいので、Food、Service、Atmosphere の3つのカテゴリーを指定します。

分類する列項目では、分類したいデータを含む列を選択します。この例では、レストランのレビューを含む列である review 列を選択します。

要約

要約テンプレートを使用して、データを指定した長さに要約できます。

このテンプレートでは、要約の長さを指定できます。単語数、文数、段落数のいずれかを選択し、要約後の長さ項目にその数を指定できます。

この例では、レストランのレビューを1文に要約したいので、要約後の長さに 1 を指定し、ドロップダウンから文を選択します。

翻訳

データを別の言語に翻訳するには、翻訳プロンプトを使用します。言語項目に、データの翻訳先の言語を指定します。以下の例では、レストランのレビューをスペイン語に翻訳したいので、言語項目に Spanish を指定します。

感情分析

データの肯定的または否定的な感情に基づいて数値スコアを割り当てたい場合は、感情分析プロンプトを使用します。

このテンプレートでは、出力スコアの尺度を設定できます。以下の例では、0から5までの数値を使い、5が最も肯定的なレビュー、0が最も否定的なレビューを表すようにします。

エンティティ抽出

データから抽出したい特定の要素がある場合は、エンティティ抽出プロンプトを使用します。この例では、レストランのレビューに含まれる food、service、times visited のすべての要素を抽出します。

具体的には、料理に関するすべての要素を String 配列として、サービスの質を String として、また、その人がレストランを訪れた回数を示す値を Integer として抽出します。

これらの結果を得るには、抽出するエンティティ項目を更新します。エンティティ名に food、service、number visited と入力し、次のプロパティを設定します。

• food には、データ型として Array を指定し、その配列のデータ型として String を選択します。
• service には、データ型として String を選択します。
• number visited には、Integer を選択します。

これで、この例で指定したデータ型に従うように LLM の出力が設定されました。

プロンプトページの出力タイプにある構造体内で、抽出するエンティティのデータ型を調整することもできます。

空のプロンプト

どのプロンプトテンプレートもユースケースに合わない場合は、空のプロンプトを選択して独自のプロンプトを作成できます。

ビジョン

Pipeline Builder はビジョン機能にも対応しており、ビジョンに対応するモデルで画像を分析し、視覚的な入力に基づいて質問に回答できます。モデルにビジョン機能があるかを確認するには、モデルセレクターで、そのモデルの機能の下にビジョンラベルがあるかを確認します。

ビジョン機能を使用するには、空のプロンプトテンプレートの入力データを指定してくださいセクションに Media Reference 列を指定し、目的のビジョンモデルを選択します。

任意の設定

出力タイプ

プロンプトページで、LLM の出力が従う出力タイプを指定できます。画面の下部にある出力タイプオプションを選択し、ドロップダウンメニューから希望するデータ型を選択します。

構造体出力のパース動作

Use LLM ノードが構造体型を出力するように設定すると、ノードは厳格なパースによって LLM のレスポンスを指定されたスキーマに変換します。LLM の出力が期待される構造体スキーマに従っていない場合、ノードの処理は失敗し、Cannot coerce to provided output type. などのエラーが発生します。

この厳格な動作は、非対話型のパイプラインフロー向けに意図されたものであり、誤ったデータが気付かないうちに生成されるのではなく、スキーマの不一致が明確に示されるようにします。

型変換エラーが発生した場合、実用的な回避策として、Use LLM ノードが構造体ではなく JSON 文字列を出力するように設定し、後続のデータ加工でその文字列を目的の構造体型にパースする方法があります。この方法では、パイプライン内でのパースエラーの処理をより細かく制御できます。

エラーを含む

プロンプトページでは、出力値とともに LLM のエラーを表示するように出力を設定することもできます。この設定により、出力タイプは元の出力タイプとエラー文字列で構成される構造体に変わります。LLM のエラーを含めるには、エラーを含むの横にあるチェックボックスをオンにします。

エラーを含まない元の出力に戻すには、エラーを含むチェックボックスをオフにします。

すでに処理済みの行の計算をスキップする

計算コストと時間を節約するため、行の再計算をスキップを切り替えることで、すでに処理済みの行の計算をスキップできます。

行の再計算をスキップが有効な場合、入力プロンプトに渡される列とパラメーターに基づいて、行が以前に処理された行と比較されます。列とパラメーターの値が同じで、一致する行には、今後のデプロイで再処理せずにキャッシュされた出力値が使用されます。キャッシュキーは、プロンプトで実際に使用される列の値だけから生成されます。入力プロンプトに含まれない列の値が異なる行でも、キャッシュに一致し、以前に計算された出力が再利用されます。前回のデプロイで出力値がエラーまたは null だった行にはキャッシュが適用されず、次回の実行時に再計算されます。

Use LLM ノードのキャッシュは、実用上の行数制限が事実上ない Foundry データセットに保存されます。入力が決定論的で、ビルド間で同じ行が現れる限り、数千万行規模の大規模なユースケースに対応できます。

すべての行を再計算する必要がある変更をプロンプトに加えた場合、キャッシュをクリアできます。LLM の表示の上部に警告バナーが表示されます。

キャッシュをクリアするには、赤いごみ箱アイコンを選択します。キャッシュがクリアされると、SNAPSHOT がトリガーされ、次回のデプロイですべての行が再処理されます。

出力タイプを変更すると、キャッシュは自動的にクリアされます。このとき、警告バナーが表示されます。誤って変更した場合は、バナー内の変更を元に戻すを選択できます。

キャッシュの状態に対する変更は、ブランチをマージするときに変更ページに表示されます。

下流に複数の出力を持つ Use LLM ノードで行の再計算をスキップが有効になっている場合、これらの出力を同じジョブグループに配置する必要があります。そうしないと、デプロイを試みたときに次のエラーが発生します。

このエラーを解消するには、デフォルトのジョブグループとは別に新しいジョブグループを作成します。

[詳細] モデルの設定を表示する

プロンプトごとに、その Use LLM ノードで使用するモデルを設定できます。

• モデルタイプ：3.5 や 4 など、GPT インスタンスのモデルタイプです。Use LLM ノードは、Mistral AI の Mixtral 8x7b などのオープンソースモデルにも対応しています。
• 温度： 温度の値が高いほど出力のランダム性が高まり、低いほど出力がより焦点を絞った決定論的なものになります。
• 最大トークン： 出力内のトークン数を制限します。トークンは、言語モデルが書き言葉を理解して処理するための構成要素として使用する、小さなテキストの断片と考えることができます。
• 停止シーケンス： 停止シーケンスのいずれかの値に達すると、LLM の生成を停止します。停止シーケンスは最大4個設定できます。

試行

各 Use LLM ボードの下部には、例を使って使用する LLM をテストするオプションがあります。試行の実行タブを選択し、左側にテストする値を入力します。次に、実行を選択します。

さらに例をテストするには、試行を追加を選択します。

入力データから直接例を追加するには、入力テーブルタブに移動し、試行に使用する行を選択します。試行用に行を使用を選択すると、自動的に試行の実行タブに戻り、選択した行が試行として入力されます。

試行を実行した後、モデルに送信された生のプロンプトと生の出力を確認できます。選択した試行の右側にある </> アイコンを選択します。

これにより、次の詳細を含むダイアログが開きます。

• 初期プロンプト：バックエンドが行う変更や追加を含め、モデルに送信された正確なプロンプトです。
• LLM の中間出力：失敗した出力を含む、LLM からのすべての出力です。
• 修正：失敗に対して行われた修正の詳細です。
• 最終出力：LLM が生成した最終的な結果です。

左側で該当するタイトルを選択すると、パネルの右側に生のテキストが表示されます。

評価スイート

LLM を使用ノードをより包括的にテストするには、LLM 評価スイートを使用します。試行実行では個別の例でプロンプトをすばやくテストできますが、評価スイートでは次のことができます。

• スイート内に複数の評価を設定する
• 分離されたテスト環境で評価を実行する
• 文字列の完全一致などの評価ツールを使用して、モデルの出力を期待される結果と比較する
• 評価結果を出力データセットに保存する
• ビルドの進行状況を追跡し、詳細な結果を確認する

デプロイ前に評価スイートを使用して LLM ロジックを検証します。

プレビューして作成する

5つのテンプレートのいずれかを使用する場合は、プレビュータブを選択すると、プロンプトを作成する前に LLM プロンプトの指示をプレビューできます。プレビュータブでは、指示の表示のみが可能で、編集はできません。テンプレートを編集する場合は、設定タブに戻ります。

新しい出力列の名前を編集し、出力列で結果をプレビューするには、プロンプトを作成を選択します。

出力列の名前を変更するには、出力列セクションを編集します。変更を出力テーブルのプレビューに反映して表示するには、適用済を選択します。出力テーブルをプレビューするには、出力テーブルタブを選択します。このプレビューには先頭の50行のみが表示されます。

最後に、LLM を使用ノードの設定が完了したら、右上の適用を選択します。これにより、LLM ボードの出力にデータ加工のロジックを追加できるようになります。また、Pipeline Builder のメインワークスペースで LLM ボードを選択すると、先頭の50行のプレビューを表示できます。

Spark バッチパイプラインでのコンピュート使用量

Spark は通常、ほぼ CPU コア単位で並列処理を実行します。理解しやすい考え方としては（多少単純化していますが）、各コアが一度にデータの1行を処理すると捉えられます。算術演算など、ほとんどの処理では、すべての計算がローカルで行われるため、このアーキテクチャは効率的です。ただし、プロセスが外部の LLM とやり取りする場合、計算の大部分は外部で行われ、プロセスはほとんどの時間をレスポンスの待機に費やします。このような場合は、コアごとに複数のスレッドを使用して同時実行する方がはるかに効率的で、待機時間を有効に活用して新しいリクエストを送信できます。

上記の理由から、LLM を使用ノードはコアごとに複数のスレッドを使用し、多数のリクエストを同時に送信します。1コアを使用するデフォルトの極小コンピュートプロファイルでも、同時実行数は非常に多くなります。

より多くのコアを提供するコンピュートプロファイル（エグゼキューター数を増やすか、エグゼキューターあたりのコア数を増やすもの）を使用すると、同時実行数をさらに増やせます。ただし、コア数が増えるにつれて、LLM プロバイダーまたは AIP によるレート制限にジョブが抵触するリスクがあります。LLM を使用ノードの実装には再試行ロジックがあるため、これらのレート制限に抵触してもジョブは成功できますが、失敗したリクエストの再試行に多くの時間を費やすコアを複数プロビジョニングすることは、非効率または無駄になる可能性があります。

同時実行数を調整する際は、デフォルトの極小コンピュートプロファイルを基準として使用することを推奨します。同時実行数をさらに増やす場合は、ごく少しずつスケールアップし（一度に追加するコアは2個以下）、ジョブの Spark 詳細ページで「すべてのタスクの合計実行時間」と「ジョブの所要時間」の相関の傾向を監視します。理想的には、コアを追加するにつれてジョブの所要時間が短くなり、すべてのタスクの合計実行時間は変わらないか、わずかに増える程度にとどまります。すべてのタスクの合計実行時間が大幅に増え始めた場合、特にジョブの所要時間がそれに見合って短くならない場合は、コア数が多すぎるため、スケールダウンする必要があります。

関数エグゼキューターのルーティング

LLM を使用ノード経由の LLM 呼び出しは、Language Model Service (LMS) に直接送信されるのではなく、関数エグゼキューターを経由してルーティングされます。関数エグゼキューターは、パイプライン内の LLM 処理ロジックのオーケストレーションを担います。このアーキテクチャにより、LLM モデルを使用する大規模なビルドでは、LLM のコンピュートコストに加えて、関数エグゼキューターの使用量が発生します。

LLM 処理を多用するパイプラインの容量を計画し、リソース消費を把握する際には、この動作を考慮することが重要です。