本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
著者: Max Fisher, Sr. Solutions Architect and Wesley Pasfield, Specialist Solutions Architect
イントロダクション
LLMを活用したエージェントをデプロイするチームにおいては、多くの場合において最大の課題は実際にエージェントを構築することではなく、エージェントをプロダクションに投入するのに必要な信頼を構築するということです。LLMを活用したエージェントを迅速にデプロイしている多くの組織では、厳密な評価の欠如が、予測不可能で高リスクのリリースにつながるを発見しています。開発のスピードと品質保証の間のオペレーション上のギャップは、開発ライフサイクルに直接組み込まれたスケーラブルで繰り返し可能な評価フレームワークを必要とします。
Databricks Agent Evaluationは、エージェントシステムの品質の評価、さまざまな評価データセットを作成し、さまざまな「ジャッジ」(人間、LLM、ルールベース)を定義するためのツールを提供する堅牢なフレームワークを提供します。
すると、重要な質問が生じます: このような評価プロセスを繰り返し可能に、既存のCI/CDパイプラインとシームレスに連携するにはどうすればいいのでしょうか？このインテグレーションは、信頼性を増加させながらエージェンティックシステムのプロダクションへのデプロイメントを加速させるには重要なものとなります。エージェントシステムの継続的な進化のため、繰り返し可能な評価は重要となり、組織は時間経過とともに品質を追跡し、退行を特定し、改善を検証し、A/Bテストを促進し、信頼を構築します。
このことを踏まえて、GitHub ActionsとDatabricks Agent Evaluationのパワフルなツールをどのように組み合わせられるのかを探索していきましょう。これによって、Agent Evaluationを我々のCI/CDに組み込み、GitHub内のプルリクエストレビュープロセスを用いて基盤的な評価を確立することができます。
サンプルシナリオの背景
この記事で説明されるデモシナリオは、こちらのリポジトリの添付ノートブックで詳細が説明されており、カスタマーサポートエージェントを構築する広告エージェンシーを取り上げています。このエージェントのタスクは、事務所のサービスや過去の発注に関する回答をクライアントが得る手助けをするものとなっています。
バイブチェックから堅牢な評価へ
この記事で説明するDatabricksにおけるエージェントの繰り返しの開発の支援と、GitHubでのCI/CDプロセスにおける評価プロセスのインテグレーションの助けにもなる繰り返し可能なプロセスを手に入れるようにするための、Agent Evaluationジョブをセットアップするには、3つの主要なステップが存在します。
評価データセットの作成
評価データセットの作成は時間を浪費するプロセスになる場合がありますが、品質評価の基礎となるので重要なものです。
以下を通じて評価データセットを入手することができます:
- ラベル付きの例
- 本番運用のトレース
- Databricksにおける合成データセット生成
ラベル付きの例や本番運用の例が利用できる場合は、それらは評価に必要な現実世界な使用量やパフォーマンスを明示的に表現するので常に優先度を高くしましょう。しかし、かず多くの実際の開発シナリオにおいては、これらのデータセットを利用することはできません。合成データを生成する能力によって、ソリューションが顧客に提供される前に、チームは効果的に評価プロセスをブートストラップし、品質のベースラインを確立することができます。
我々の例では、シンプルな評価データセットを使います:
eval_dataset = [
{
"inputs": {
"messages": [
{
"role": "system",
"content": system_prompt
},
{
"role": "user",
"content": "What should next steps be with user_10?"
}
]
},
"expected_response": None
}
]
評価ジャッジの確立
Databricksで確立できるジャッジには4つのタイプがあります:
- ビルトインのジャッジ: これらは、エージェント評価のためにDatabricksが提供するビルトインのジャッジであり、シンプルなimport文でロードされます。Safety、Relevance、RetrievalGroundedness、RetrievalRelevanceがあります。
- ガイドラインジャッジ: ジャッジにアウトプットをどのように評価させたいのかを自然言語で表現します。これは、明確で単純な、合格/不合格シナリオに適しています。
- プロンプトベースのジャッジ: ジャッジがどのようなものを期待するのか、評価をどのようにスコアリングすべきかをガイドするためにプロンプトを活用します。これは、あなたのスコアリング指標が定量的な分析における数値のスコアや、バージョン比較、カスタムのカテゴリーを必要とする複雑な評価指標を含む場合のあるシナリオに適しています。
- カスタムのスコアラー: ジャッジの評価プロセスやご自身のLLMジャッジモデルやカスタムライブラリを組み込むかどうかに対して完全なコントロールを持つジャッジを構築します。これによって、ジャッジがどのように動作すべきかに関して純粋なPythonで表現することで完全なコントロールを手に入れることができます。
Databricksにおいては、常に最もシンプルなソリューションからスタートし、必要な場合にのみ複雑性を増やすことをお勧めします。ビルトインのジャッジがコアユースケースを満足させるのであれば、これが理想的なスタート地点となります。しかし、エンタープライズのシナリオは多くの場合、プロプライエタリの専門性や特定のビジネスロジックを評価するカスタムジャッジの形態を必要とします。これらのケースにおいては、Guidelineジャッジからスタートし、あなたのスコアリング指標がより多くのコントロールや粒度を必要とするシチュエーションにおいては、プロンプトベースやカスタムスコアラーにスケールアップします。
こちらが、この取り組みのために確立したサンプルのジャッジとなります。ここでは二つのビルトインのジャッジ(RelevanceToQuery、Safety)と、エージェントがプロフェッショナルな方法で回答しているかどうかを判別するmy_guidelines変数で定義されたGuidelineジャッジを使用しています。
import mlflow
from mlflow.genai.scorers import RelevanceToQuery, Safety, Guidelines
# Define your custom guidelines
my_guidelines = Guidelines(
name="professional_conduct",
guidelines=[
"Responses should be professional relative to customer support standards",
]
)
# Define the list of scorers, including both built-in and custom ones
scorers = [
Safety(), # A built-in scorer for content safety
RelevanceToQuery(), # A built-in scorer for response relevance to the query
my_guidelines # Your custom guidelines scorer
]
評価ジョブのスケジュール
この例でセットアップした評価ジョブにおいては、Databricksワークフローのノートブックタスクとして設定を行いました。これは、上のeval_datasetと上で構築したジャッジのリストを引き渡すことで、評価を起動するために使うメインコードとなります。
eval_results = mlflow.genai.evaluate(
data=eval_dataset,
predict_fn=lambda messages: AGENT.predict({"messages": messages}),
scorers=[RelevanceToQuery(), Safety(), my_guidelines], # add more scorers here if they're applicable
)
これらの実行の後で結果は変数eval_resultsに格納され、そのオブジェクトから評価ジョブで実行されたジャッジに関連づけられた評価を取得するために、正確なトレースを取得するためのrun_idを取得することができます。
この評価データはJSONオブジェクトにパッケージングされ、文字列にシリアライズされます。
import json
traces_df = mlflow.search_traces(run_id=eval_results.run_id)
output_json = {"assessments": traces_df['assessments'][0]}
output_json_str = json.dumps(output_json)
最後に、解析され、GitHub ActionsパイプラインとGitHubのプルリクエストに適切に表示される評価ジョブが必要とするoutput_json_strにシリアライズされたトレースデータを引き渡せるようにdbutils.notebook.exit()を使います。
dbutils.notebook.exit(output_json_str)
ここから、Databricksワークフローにアクセスし、ジョブのタスクとしてこのノートブックを設定することができます。評価ジョブを起動する呼び出しで参照されるので、GitHub Actionsパイプラインのプロセスのセットアップで後で使用できるように、このジョブIDを保存しておきます。
Databricks Agent Evaluationと従来のCI/CDの統合
Agent EvaluationとGitHub Actionsのセットアップ
この例で構築したGitHub Actionsパイプラインをブレークダウンします:
始めに、パイプラインが参照するいくつかのシークレットの値を作成する必要があります。
Settings → Secrets and variables → Actions → New repository secretに移動します。
これらのシークレットを作成します:
- DATABRICKS_HOST: お使いのワークスペースのURL。
- DATABRICKS_TOKEN: APIアクセスのための生成したDatabricks PAT。
- DATABRICKS_EVAL_JOB_ID: 評価を実行するDatabricksジョブの数値ID。
実際の環境でセットアップする場合には、以下のステップを実行します:
- Settings → Environments → New environmentで設定することでGitHubの専任のレビュアー/承認者で保護された環境をセットアップします。
- すると、あなたのメインブランチへのマージに対する条件としてこのGitHub Actionsパイプラインを設定したいでしょうから、Settings → Branches → Branch protection rules → Add ruleであなたのメインブランチのブランチルールを設定します。
次に、GitHub Actionsパイプラインを構成するYAMLのコア部品です。
このセクションでは、Databricksで構成した評価ジョブを起動し、ジョブ実行の状態をポーリングし、ノートブックのアウトプットから結果を取得します。
- name: Trigger Databricks Evaluation Job
id: trigger-job
env:
DATABRICKS_HOST: ${{ secrets.DATABRICKS_HOST }}
DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_TOKEN }}
DATABRICKS_JOB_ID: ${{ secrets.DATABRICKS_EVAL_JOB_ID }}
GITHUB_PR_NUMBER: ${{ github.event.pull_request.number }}
GITHUB_HEAD_REF: ${{ github.head_ref }}
run: |
python .github/scripts/trigger_databricks_job.py
- name: Wait for Job Completion and Get Results
id: get-results
env:
DATABRICKS_HOST: ${{ secrets.DATABRICKS_HOST }}
DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_TOKEN }}
RUN_ID: ${{ steps.trigger-job.outputs.run_id }}
run: |
python .github/scripts/get_job_results.py
Databricks UIでは、このステップの成功はワークスペースのワークフローUIで以下のように見えます:
このセクションでは、結果を整形し、プルリクエストに適したマークダウンのコメントとして投稿します。
- name: Format Evaluation Results
id: format-results
run: |
python .github/scripts/format_results.py
- name: Summarize Results
if: always()
run: |
if [ -f formatted_results.md ]; then
cat formatted_results.md >> "$GITHUB_STEP_SUMMARY"
結果の解釈と整形の成功はプルリクエストのGitHub UIで以下のように見えるでしょう:
我々はワークフローを管理する条件ロジックの重要な部品に気づきます: 「マニュアルレビュー」ステップです。このステップは、すべての自動評価に通過したらスキップするように設計されているので、(人間の承認を求めるなど)従来の手続型のCI/CDゲートを通じてPRを続行することができます。しかし、評価にすべて通過しなかった場合、このワークフローは異なる結果を生成します。この失敗状態では、「manual-review」環境が起動され、専任のレビュアーの介入が行われるまではマージに対する強固なバリアーを構成します。
manual-review:
needs: run-databricks-evaluation
runs-on: self-hosted
if: ${{ needs.run-databricks-evaluation.outputs.all-passed != 'true' }}
environment: production-approval
steps:
- name: Request Manual Review
run: |
echo "⚠️ Evaluation did not pass all checks automatically."
echo "Manual review required. Please check the evaluation results in the PR comments."
こちらがチェックに失敗した際にどのように見えるかです。
GitHub Actionsパイプラインのログを最初に見ることになります:
そして、結果を確認するためにPRコメントにアクセスするとこちらを見ることになります:
このように、ここでは評価の一つが失敗した際には、チェックは通貨とは設定されず、人間のレビュアーはプルリクエストをマージせず、プロセスの継続を停止させます。
まとめ
このインテグレーションは、生成AIワークフローの本格運用に向けた重要な第一歩です。あなたのCI/CDプロセスによる直接のエージェントの品質と信頼度を支持する重要な評価結果をリンクすることで、これらの洗練されたシステムに対する安定し、監査可能なリリースサイクルを確立することができます。
この基盤をさらに拡張することができます: 新たに検証されたエージェントバージョンのデプロイメントを完全に自動化するためにMLflowやDatabricks APIとのWebHook連携やTerraformプロバイダーを活用したり、評価結果をSlackやTeamsに通知することができます。最終的には、このアプローチはエージェントの開発をアドホックな実験から厳密でスケーラブルなエンジニアリング原則に移行することになります。