Pipeline Builder の LLM を使用ノード

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

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

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

データセットを選択する

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

モデルを選択する

LLM を使用ノードは、Palantir が提供するモデルと登録済みモデルの両方に対応しています。Palantir が提供するモデルはデフォルトで利用可能で、対応する LLM に記載されている選択肢が含まれます。

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

プロンプトを選択する

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

分類

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

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

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

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

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

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

要約

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

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

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

翻訳

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

感情分析

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

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

エンティティ抽出

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

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

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

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

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

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

空のプロンプト

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

ビジョン

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

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

任意の設定

出力タイプ

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

構造体出力のパース動作

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

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

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

エラーを含める

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

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

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

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

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

LLM を使用ノードのキャッシュは Foundry データセットに保存され、行数に実用上の制限はほぼありません。入力が決定論的で、ビルド間で同じ行が検出される限り、数千万行規模の大規模なユースケースにも対応します。

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

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

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

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

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

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

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

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

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

試行

各 LLM を使用ボードの下部では、例を使って特定の LLM をテストできます。試行の実行タブを選択し、左側にテストする値を入力します。次に、実行を選択します。

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

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

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

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

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

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

評価スイート

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

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

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

プレビューして作成する

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

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

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

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

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

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

上記の理由から、LLM を使用ノードはコアごとに複数のスレッドを使用して、多数のリクエストを同時に送信します。単一のコアを使用するデフォルトの Extra Small コンピューティングプロファイルでも、非常に高い同時実行数を実現できます。

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

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

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

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

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