「Amazon SageMaker ClarifyとMLOpsサービスを使用して、LLM評価をスケールで運用化する」

「Amazon SageMaker ClarifyとMLOpsサービスを駆使し、LLM評価を大規模に展開する方法」

過去数年間、大規模言語モデル（LLM）は、これまでにない高い能力でテキストを理解し、生成し、操作するための優れたツールとして注目を集めてきました。これらのモデルは、対話エージェントからコンテンツ生成、情報検索まで、様々な応用が可能であり、あらゆる産業を革新する可能性を秘めています。ただし、これらのモデルの潜在的な能力を引き出し、その責任ある効果的な利用を確保するためには、LLMの評価という重要なプロセスにかかっています。評価は、LLMや生成型AIサービスの出力の品質と責任を測るために使用されるタスクです。LLMの評価は、モデルの性能を理解するという欲求だけでなく、責任あるAIの実装や誤情報や偏ったコンテンツの提供のリスクを軽減し、有害で安全で悪意のある倫理に反するコンテンツの生成を最小限に抑える必要性からも動機付けられます。さらに、LLMの評価は、プロンプトデータの改ざんの文脈において、セキュリティリスクを軽減するのにも役立ちます。LLMをベースとしたアプリケーションでは、潜在的な侵害や不正なデータ操作に対する脆弱性を特定し、保護するためのセーフガードを実装することが重要です。

Amazon SageMaker Clarifyは、直感的な設定とワンクリックのアプローチで、LLMの評価に必要な必須ツールを提供し、上記の利点にアクセスすることができます。これらのツールを手に入れたら、次の課題は、LLMの評価を機械学習と運用（MLOps）ライフサイクルに統合して、プロセスの自動化とスケーラビリティを実現することです。この記事では、Amazon SageMaker Clarify LLM評価をAmazon SageMaker Pipelinesと統合して、スケーラブルなLLM評価を実現する方法を紹介します。また、このGitHubのリポジトリでは、Llama2-7b-f、Falcon-7b、およびファインチューニングされたLlama2-7bモデルなどの例を使用して、ユーザーがスケールでパラレルなマルチモデル評価を行うことができるコード例も提供しています。

LLM評価を行う必要があるのは誰ですか？

トレーニング、ファインチューニング、または単に事前にトレーニングされたLLMを使用する人は、正確に評価し、そのLLMによってパワーを供給されるアプリケーションの振る舞いを評価する必要があります。この基本原則に基づいて、LLM評価の能力が必要な生成型AIのユーザーは、以下の図に示すように3つのグループに分類することができます：モデルプロバイダー、ファインチューナー、および消費者。

ファウンデーションモデル（FM）プロバイダーは、汎用的なモデルをトレーニングします。これらのモデルは、特徴抽出やコンテンツ生成など、多くのダウンストリームタスクに使用できます。各トレーニングされたモデルは、その性能を評価するだけでなく、他の既存のモデルと比較するために、多くのタスクに対してベンチマークを行う必要があります。改善が必要な領域を特定し、その分野の進歩を追跡するためにもこれらのデータが必要です。また、モデルプロバイダーは、出発データセットの品質やモデルの正しい振る舞いを確保するために、任意のバイアスの存在をチェックする必要があります。評価データを収集することは、モデルプロバイダーにとって重要です。さらに、これらのデータとメトリクスは、今後の規制との適合も求められます。ISO 42001、バイデン政権のエグゼクティブオーダー、およびEUのAI法は、AIシステムが安全で安全かつ信頼性のあるものであることを保証するための標準、ツール、テストを開発しています。たとえば、EUのAI法では、どのデータセットがトレーニングに使用されているか、モデルを実行するために必要な計算能力はどれなのか、パブリック/業界標準のベンチマークに対するモデルの結果を報告し、内部および外部のテストの結果を共有することが求められます。
モデルファインチューナーは、特定のタスク（感情分類、要約、質問応答など）を解決するだけでなく、ドメイン固有のタスクに適用するための事前にトレーニングされたモデルも使用したいと考えています。彼らは、モデルプロバイダーによって生成された評価メトリクスが必要であり、正しい事前トレーニングモデルを選択するための出発点としてそれらを使用する必要があります。彼らは、タスク固有またはドメイン固有のデータセットで自分のファインチューニングモデルを評価する必要があります。頻繁に、一般に利用可能なデータセットは、特定のタスクに適したものであっても、彼らが求める特定のユースケースに必要なニュアンスを十分に捉えることができません。ファインチューニングは、完全なトレーニングよりも速く、安価であり、通常は多くの候補モデルが生成されるため、展開とテストのためにより迅速な操作的反復が必要です。これらのモデルの評価により、継続的なモデル改善、キャリブレーション、デバッグが可能となります。なお、ファインチューナーは、実世界のアプリケーションを開発する際には、自分自身のモデルの消費者になることもあります。
モデル消費者またはモデルデプロイヤーは、一般的な用途またはファインチューニングされたモデルを製品化し、監視することで、LLMの採用を通じてアプリケーションやサービスを向上させようとしています。彼らが最初に直面する課題は、選択したLLMが特定のニーズ、コスト、パフォーマンスの期待に合致していることを確認することです。モデルの出力の解釈と理解は、特にプライバシーやデータセキュリティが関わる場合には、常に懸念事項です（たとえば、規制された産業（金融セクターなど）におけるリスクとコンプライアンスの監査のため）。継続的なモデルの評価は、バイアスや有害なコンテンツの伝播を防ぐために重要です。堅牢なモニタリングと評価フレームワークを実装することにより、モデルの消費者はLLMの回帰を予防し、これらのモデルが長期にわたって効果的かつ信頼性のあるものであることを確保することが

LLM評価の実施方法

効果的なモデル評価には、以下の3つの基本要素が必要です。評価対象のデータセット（プロンプト、会話、または通常の入力）と評価ロジックを評価するための1つ以上のFMまたはファインチューニングされたモデルです。

評価対象のモデルを選択するためには、データの特性、問題の複雑さ、利用可能な計算リソース、および望ましい結果など、さまざまな要素を考慮する必要があります。入力データストアは、選択したモデルのトレーニング、ファインチューニング、およびテストに必要なデータを提供します。モデルのパフォーマンスは、学習するデータの質に大きく依存するため、このデータストアは構造化され、代表的で高品質であることが重要です。最後に、評価ロジックはモデルのパフォーマンスを評価するために使用する基準やメトリクスを定義します。

これらの3つの要素は、機械学習モデルの厳密かつ体系的な評価を保証する統一的なフレームワークを形成します。このフレームワークにより、明確な意思決定とモデルの効果の改善が実現されます。

モデル評価技術は、現在も研究の活発な領域です。過去数年間において、コミュニティの研究者によってさまざまなタスクやシナリオをカバーするために、多くの公開ベンチマークおよびフレームワークが作成されました。これらのベンチマークには、GLUE、SuperGLUE、HELM、MMLU、およびBIG-benchなどが含まれます。これらのベンチマークには、評価されたモデルを比較するために使用できるリーダーボードがあります。HELMなどのベンチマークでは、精度以外の指標（適合率やF1スコアなど）に関する評価も行われます。HELMベンチマークでは、公平性、バイアス、有害性などのメトリクスも評価されます。これらのメトリクスも総合的なモデル評価スコアにおいて同じく重要な役割を果たします。

これらのベンチマークには、特定のタスクにおけるモデルのパフォーマンスを測定する一連のメトリクスが含まれています。最も有名で一般的なメトリクスには、ROUGE（Gisting Evaluationのためのリコール指向アンダースタディ）、BLEU（バイリンガル評価アンダースタディ）、およびMETEOR（明示的な順序付けを伴う翻訳の評価メトリクス）があります。これらのメトリクスは自動評価の有用なツールとなり、生成されたテキストと参照テキストの間の語彙的類似性の定量的な尺度を提供します。ただし、これらのメトリクスには、意味理解や文脈、スタイルのニュアンスなど、人間のような言語生成の全体的な幅を捉えることはできません。例えば、HELMでは特定のユースケースに関連する評価の詳細や、カスタムプロンプトのテストのためのソリューション、および非専門家によって容易に解釈できる結果は提供されません。これはプロセスが費用対効果が低い、スケーラビリティが低く、特定のタスクにのみ適用可能であるためです。

さらに、人間のような言語生成を実現するためには、人間をループに組み込んで定性的な評価と人間の判断を取り入れる必要があります。人間による評価はLLMの出力を評価するための貴重な方法ですが、異なる人間の評価者はテキストの品質に対して異なる意見や解釈を持つ可能性があるため、主観的でバイアスの影響を受けることもあります。さらに、人間による評価はリソースを消費するため、費用がかかり、時間と労力がかかることがあります。

Amazon SageMaker Clarifyがどのようにつながりをスムーズにして顧客が徹底的なモデル評価と選択を行うのか、詳細に探っていきましょう。

Amazon SageMaker ClarifyによるLLM評価

Amazon SageMaker Clarifyは、正確性、頑健性、有害性、ステレオタイプ化や事実知識などのメトリクスの自動化、およびスタイル、一貫性、関連性などの人間ベースの評価のための評価手法を自動化することで、顧客がLLMやAmazon BedrockなどのLLMベースのサービスを評価するのを支援します。完全に管理型のサービスであるSageMaker Clarifyは、Amazon SageMaker内でオープンソースの評価フレームワークの使用を簡素化します。顧客は、シナリオに応じた評価データセットとメトリクスを選択し、独自のプロンプトデータセットと評価アルゴリズムで拡張することができます。SageMaker Clarifyは、LLMワークフロー内のさまざまな役割をサポートするために、複数の形式で評価結果を提供します。データサイエンティストは、SageMaker Clarifyの可視化機能を使用して詳細な結果を分析できます。また、SageMaker Model CardsやPDFレポートも利用できます。一方、運用チームは、SageMaker Clarifyが特定のリスクを特定するために使用するAmazon SageMaker GroundTruthを使用して、リスクの高いアイテムを確認および注釈付けすることができます。たとえば、ステレオタイプ化、有害性、エスケープしたPII、または低い精度などです。

注釈と強化学習は、潜在的なリスクを軽減するために後続に使用されます。特定されたリスクのユーザーフレンドリーな説明により、手動レビュープロセスが迅速化され、コストが削減されます。概要レポートでは、異なるモデルやバージョン間の比較的なベンチマークが提供され、明確な意思決定が容易になります。

次の図は、LLMおよびLLMベースのサービスを評価するフレームワークを示しています：

Amazon SageMaker Clarify LLM評価は、顧客が簡単にLLMを評価できるようにするためにAWSが開発したオープンソースのFoundation Model Evaluation（FMEval）ライブラリです。すべての機能はまた、Amazon SageMaker Studioに組み込まれており、MLOpsの原則を使用してLLM評価を可能にするためにSageMakerパイプラインとの統合が紹介されます。以下のセクションでは、Amazon SageMaker Clarify LLM評価機能をSageMakerパイプラインと統合し、MLOpsの原則を使用してLLM評価をスケールアップする方法について紹介します。

Amazon SageMaker MLOpsライフサイクル

「Amazon SageMakerを使用した企業向けMLOps基盤ロードマップ」という記事では、MLOpsはプロセス、人々、技術の組み合わせであり、効率的にMLを実践化するためのものです。

次の図は、エンドツーエンドのMLOpsライフサイクルを示しています：

一般的なプロセスは、データサイエンティストがビジネスの問題を解決するためにMLが使用できることを証明するために概念実証（PoC）ノートブックを作成するところから始まります。 PoCの開発中、データサイエンティストはビジネスの主要パフォーマンス指標（KPI）を精度や偽陽性率などの機械学習モデルのメトリックに変換し、これらのメトリックを評価するための限られたテストデータセットを利用します。データサイエンティストはMLエンジニアと共同作業し、ノートブックからリポジトリにコードを移行し、Amazon SageMakerパイプラインを使用してMLパイプラインを作成します。これには前処理、トレーニング、評価、ポストプロセッシングなどのさまざまな処理ステップとタスクが含まれます。また、常に新しい製品データを組み込みながら、リポジトリの相互作用とCI/CDパイプラインのアクティベーションを行います。 Amazon SageMakerパイプラインの展開は、モデルの利害関係者がパフォーマンスを評価し、パフォーマンスの結果とベンチマークに基づいてプロダクションへの進行を決定するためにモデルレジストリで行われます。その後、ステージングと本番展開のための別のCI/CDパイプラインがアクティベートされます。本番環境にある場合、MLの利用者はモデルをアプリケーショントリガーによって推論し、直接の呼び出しやAPI呼び出しを通じてモデルを利用し、継続的なパフォーマンス評価のためにモデルの所有者にフィードバックループを提供します。

Amazon SageMaker ClarifyとMLOpsの統合

MLOpsライフサイクルに従って、ファインチューナーやオープンソースモデルのユーザーは、Amazon SageMaker JumpstartとMLOpsサービスを使用してファインチューニングされたモデルやFMをプロダクション化します。これは、Amazon SageMaker JumpStartの事前学習モデルを使用したMLOpsプラクティスの実装で説明されています。これにより、Foundation Model Operations（FMOps）およびLLM Operations（LLMOps）という新しいドメインが生まれました。FMOps/LLMOps：Generative AIの実行とMLOpsとの違いをオペレーショナライズする.

次の図は、エンドツーエンドのLLMOpsライフサイクルを示しています：

LLMOpsでは、MLOpsと比較してモデルの選択とモデルの評価に関する異なるプロセスとメトリックがあります。初期の実験フェーズでは、データサイエンティスト（またはファインチューナー）が特定のGenerative AIのユースケースに使用するFMを選択します。これにより、複数のFMsのテストとファインチューニングが行われる場合がありますが、そのうちいくつかは比較可能な結果を生み出すことがあります。モデルが選択された後、プロンプトエンジニアは評価のための必要な入力データと期待される出力（例：入力データとクエリーからなる入力プロンプト）を準備し、類似性や有害性などのメトリックを定義します。これらのメトリックに加えて、データサイエンティストやファインチューナーは結果を検証し、精度のメトリックだけでなく、レイテンシやコストなどの他の機能に基づいて適切なFMを選択する必要があります。その後、モデルをSageMakerエンドポイントにデプロイし、そのパフォーマンスを小規模でテストします。実験フェーズは比較的簡単なプロセスを含む場合がありますが、本番環境への移行にはプロセスの自動化とソリューションの堅牢性を向上させる必要があります。そのため、評価の自動化方法、スケールでの効率的な評価を実行できるようにする方法、およびモデルの入力と出力のリアルタイムモニタリングの詳細について説明する必要があります。

FM評価を自動化する

Amazon SageMaker Pipelinesは、前処理、FMの微調整（オプション）、およびスケールでの評価のすべてのフェーズを自動化します。実験中に選択されたモデルに基づいて、プロンプトのエンジニアは多くのプロンプトを準備し、それらをプロンプトカタログと呼ばれる指定されたストレージリポジトリに保存する必要があります。詳細については、FMOps/LLMOps: Generative AIのプロフェッショナルとMLOpsの違いを実装するを参照してください。それから、Amazon SageMaker Pipelinesは次のように構成されることができます：

シナリオ1 – 複数のFMを評価する： このシナリオでは、FMは微調整せずにビジネスユースケースをカバーできます。 Amazon SageMakerパイプラインは、データの前処理、複数のFMの並列評価、モデルの比較、および精度やコスト、遅延などの他の特性に基づいて選択したモデルアーティファクトとメタデータの登録などの手順で構成されます。

次の図は、このアーキテクチャを示しています。

シナリオ2 – FMを微調整して評価する： このシナリオでは、Amazon SageMakerパイプラインはシナリオ1とほぼ同様に構成されますが、各FMの微調整と評価手順を並行して実行します。最良の微調整モデルはモデルレジストリに登録されます。

次の図は、このアーキテクチャを示しています。

シナリオ3 – 複数のFMと微調整されたFMを評価する： このシナリオは、汎用FMの評価と微調整されたFMの評価を組み合わせたものです。この場合、顧客は微調整モデルが汎用FMよりも優れたパフォーマンスを発揮できるかどうかを確認したいと考えています。

次の図は、SageMakerパイプラインの手順を示しています。

モデルの登録は2つのパターンに従います：（a）オープンソースモデルとアーティファクトの保存、または（b）プロプライエタリFMへの参照の保存です。詳細については、FMOps/LLMOps: Generative AIのプロフェッショナルとMLOpsの違いを実装するを参照してください。

ソリューションの概要

大規模なLLM評価への旅を加速するために、Amazon SageMaker Clarifyと新しいAmazon SageMaker Pipelines SDKの両方を使用したシナリオを実装するソリューションを作成しました。コードの例、データセット、ソースノートブック、およびSageMakerパイプライン（手順とMLパイプライン）は、GitHubで入手できます。この例のソリューションの開発には、Llama2とFalcon-7Bの2つのFMを使用しました。この記事では、評価プロセスに関連するSageMakerパイプラインソリューションの主要な要素に重点を置いています。

評価構成： 評価手順を標準化するために、評価データセット、モデル（s）、およびSageMakerパイプラインの評価ステップ中に実行するアルゴリズムなど、評価プロセスに必要な詳細を含むYAML構成ファイル（evaluation_config.yaml）を作成しました。次の例は、構成ファイルを示しています：
```
pipeline:    name: "llm-evaluation-multi-models-hybrid"dataset:    dataset_name: "trivia_qa_sampled"    input_data_location: "evaluation_dataset_trivia.jsonl"    dataset_mime_type: "jsonlines"    model_input_key: "question"    target_output_key: "answer"models:  - name: "llama2-7b-f"    model_id: "meta-textgeneration-llama-2-7b-f"    model_version: "*"    endpoint_name: "llm-eval-meta-textgeneration-llama-2-7b-f"    deployment_config:      instance_type: "ml.g5.2xlarge"      num_instances: 1    evaluation_config:      output: '[0].generation.content'      content_template: [[{"role":"user", "content": "PROMPT_PLACEHOLDER"}]]      inference_parameters:         max_new_tokens: 100        top_p: 0.9        temperature: 0.6      custom_attributes:        accept_eula: True      prompt_template: "$feature"    cleanup_endpoint: True  - name: "falcon-7b"    ...  - name: "llama2-7b-finetuned"    ...    finetuning:      train_data_path: "train_dataset"      validation_data_path: "val_dataset"      parameters:        instance_type: "ml.g5.12xlarge"        num_instances: 1        epoch: 1        max_input_length: 100        instruction_tuned: True        chat_dataset: False    ...algorithms:  - algorithm: "FactualKnowledge"     module: "fmeval.eval_algorithms.factual_knowledge"    config: "FactualKnowledgeConfig"    target_output_delimiter: "<OR>"
```
評価ステップ：新しいSageMaker Pipeline SDKでは、ユーザーはMLワークフローでカスタムステップを定義するために「@step」Pythonデコレータを使用する柔軟性を提供しています。したがって、ユーザーは評価を実施する基本的なPythonスクリプトを作成する必要があります。具体的には以下のようになります：
```
def evaluation(data_s3_path, endpoint_name, data_config, model_config, algorithm_config, output_data_path,):    from fmeval.data_loaders.data_config import DataConfig    from fmeval.model_runners.sm_jumpstart_model_runner import JumpStartModelRunner    from fmeval.reporting.eval_output_cells import EvalOutputCell    from fmeval.constants import MIME_TYPE_JSONLINES    s3 = boto3.client("s3")    bucket, object_key = parse_s3_url(data_s3_path)    s3.download_file(bucket, object_key, "dataset.jsonl")    config = DataConfig(        dataset_name=data_config["dataset_name"],        dataset_uri="dataset.jsonl",        dataset_mime_type=MIME_TYPE_JSONLINES,        model_input_location=data_config["model_input_key"],        target_output_location=data_config["target_output_key"],    )    evaluation_config = model_config["evaluation_config"]    content_dict = {        "inputs": evaluation_config["content_template"],        "parameters": evaluation_config["inference_parameters"],    }    serializer = JSONSerializer()    serialized_data = serializer.serialize(content_dict)    content_template = serialized_data.replace('"PROMPT_PLACEHOLDER"', "$prompt")    print(content_template)    js_model_runner = JumpStartModelRunner(        endpoint_name=endpoint_name,        model_id=model_config["model_id"],        model_version=model_config["model_version"],        output=evaluation_config["output"],        content_template=content_template,        custom_attributes="accept_eula=true",    )    eval_output_all = []    s3 = boto3.resource("s3")    output_bucket, output_index = parse_s3_url(output_data_path)    for algorithm in algorithm_config:        algorithm_name = algorithm["algorithm"]        module = importlib.import_module(algorithm["module"])        algorithm_class = getattr(module, algorithm_name)        algorithm_config_class = getattr(module, algorithm["config"])        eval_algo = algorithm_class(algorithm_config_class(target_output_delimiter=algorithm["target_output_delimiter"]))        eval_output = eval_algo.evaluate(model=js_model_runner, dataset_config=config, prompt_template=evaluation_config["prompt_template"], save=True,)                print(f"eval_output: {eval_output}")        eval_output_all.append(eval_output)        html = markdown.markdown(str(EvalOutputCell(eval_output[0])))        file_index = (output_index + "/" + model_config["name"] + "_" + eval_algo.eval_name + ".html")        s3_object = s3.Object(bucket_name=output_bucket, key=file_index)        s3_object.put(Body=html)    eval_result = {"model_config": model_config, "eval_output": eval_output_all}    print(f"eval_result: {eval_result}")    return eval_result
```
SageMaker Pipeline：必要なステップ（データ前処理、モデルデプロイメント、モデル評価など）を作成した後、ユーザーはSageMaker Pipeline SDKを使用してこれらのステップをリンクする必要があります。新しいSDKは、SageMaker Pipeline作成APIが呼び出されたときに異なるステップ間の依存関係を解釈してワークフローを自動的に生成します。以下の例を参考にしてください：
```
import osimport argparsefrom datetime import datetimeimport sagemakerfrom sagemaker.workflow.pipeline import Pipelinefrom sagemaker.workflow.function_step import stepfrom sagemaker.workflow.step_outputs import get_step# 必要なステップをインポートfrom steps.preprocess import preprocessfrom steps.evaluation import evaluationfrom steps.cleanup import cleanupfrom steps.deploy import deployfrom lib.utils import ConfigParserfrom lib.utils import find_model_by_nameif __name__ == "__main__":    os.environ["SAGEMAKER_USER_CONFIG_OVERRIDE"] = os.getcwd()    sagemaker_session = sagemaker.session.Session()    # データの場所を定義する - 引数で指定するか、デフォルトのバケットを使用する    default_bucket = sagemaker.Session().default_bucket()    parser = argparse.ArgumentParser()    parser.add_argument("-input-data-path", "--input-data-path", dest="input_data_path", default=f"s3://{default_bucket}/llm-evaluation-at-scale-example", help="The S3 path of the input data",)    parser.add_argument("-config", "--config", dest="config", default="", help="The path to .yaml config file",)    args = parser.parse_args()    # データ、モデル、アルゴリズムの設定を初期化    if args.config:        config = ConfigParser(args.config).get_config()    else:        config = ConfigParser("pipeline_config.yaml").get_config()    evalaution_exec_id = datetime.now().strftime("%Y_%m_%d_%H_%M_%S")    pipeline_name = config["pipeline"]["name"]    dataset_config = config["dataset"]  # データセットの設定を取得    input_data_path = args.input_data_path + "/" + dataset_config["input_data_location"]    output_data_path = (args.input_data_path + "/output_" + pipeline_name + "_" + evalaution_exec_id)    print("Data input location:", input_data_path)    print("Data output location:", output_data_path)    algorithms_config = config["algorithms"]  # アルゴリズムの設定を取得    model_config = find_model_by_name(config["models"], "llama2-7b")    model_id = model_config["model_id"]    model_version = model_config["model_version"]    evaluation_config = model_config["evaluation_config"]    endpoint_name = model_config["endpoint_name"]    model_deploy_config = model_config["deployment_config"]    deploy_instance_type = model_deploy_config["instance_type"]    deploy_num_instances = model_deploy_config["num_instances"]    # ステップを構築    processed_data_path = step(preprocess, name="preprocess")(input_data_path, output_data_path)    endpoint_name = step(deploy, name=f"deploy_{model_id}")(model_id, model_version, endpoint_name, deploy_instance_type, deploy_num_instances,)    evaluation_results = step(evaluation, name=f"evaluation_{model_id}", keep_alive_period_in_seconds=1200)(processed_data_path, endpoint_name, dataset_config, model_config, algorithms_config, output_data_path,)    last_pipeline_step = evaluation_results    if model_config["cleanup_endpoint"]:        cleanup = step(cleanup, name=f"cleanup_{model_id}")(model_id, endpoint_name)        get_step(cleanup).add_depends_on([evaluation_results])        last_pipeline_step = cleanup    # SageMaker Pipelineを定義    pipeline = Pipeline(        name=pipeline_name,        steps=[last_pipeline_step],    )    # SageMaker Pipelineをビルドして実行    pipeline.upsert(role_arn=sagemaker.get_execution_role())    # pipeline.upsert(role_arn="arn:aws:iam::<...>:role/service-role/AmazonSageMaker-ExecutionRole-<...>")    pipeline.start()
```
この例では、初期データセットの前処理、モデルの展開、評価の実行による単一FMの評価を実装しています。生成されたパイプラインの有向非循環グラフ（DAG）は、以下の図に示されています。

Amazon SageMaker JumpStartでLLaMA 2モデルを微調整するの例を参考にし、同様のアプローチを取り、微調整されたモデルを評価するためのパイプラインを以下の図に示しました。

前述のSageMakerパイプラインのステップを「レゴ」ブロックとして使用し、シナリオ1とシナリオ3のソリューションを開発しました。具体的には、GitHubリポジトリでは、複数のFMを並列で評価するか、ファウンデーションモデルと微調整モデルの両方の評価を組み合わせたより複雑な評価を実行できるようにしています。

リポジトリで利用可能な追加機能は次のとおりです:
- 動的な評価ステップの生成: 当社のソリューションは、設定ファイルに基づいて必要な評価ステップを動的に生成し、ユーザーが任意の数のモデルを評価できるようにしています。Hugging FaceやAmazon Bedrockなどの新しいモデルの簡単な統合をサポートするために、ソリューションを拡張しました。
- エンドポイントの再展開を防止: エンドポイントが既に存在する場合、展開プロセスをスキップします。これにより、ユーザーは評価のためにFMsを使用したエンドポイントを再利用できるため、コスト削減と展開時間の短縮が実現できます。
- エンドポイントのクリーンアップ: 評価が完了すると、SageMakerパイプラインは展開されたエンドポイントを廃止します。この機能は、最良のモデルエンドポイントを維持するために拡張することもできます。
- モデル選択ステップ: 最終的なモデル選択のビジネスロジック（コストやレイテンシなどの基準を含む）を要求するモデル選択ステップのプレースホルダーを追加しました。
- モデル登録ステップ: 最良のモデルは、特定のモデルグループの新しいバージョンとしてAmazon SageMaker Model Registryに登録できます。
- ウォームプール: SageMakerの管理下のウォームプールは、ジョブの完了後にプロビジョニングされたインフラストラクチャを保持して再利用することで、繰り返しワークロードのレイテンシを低減します
以下の図は、これらの機能と、ユーザーが簡単かつ動的に作成できるマルチモデル評価の例を示しています。詳細なデータの準備については、別の記事で詳しく説明します。詳細については、FMOps/LLMOps：生成型AIのオペレーショナライズとMLOpsとの違いを参照してください。

結論

この投稿では、Amazon SageMaker Clarify LLM評価の自動化と運用化に焦点を当て、Amazon SageMaker Pipelinesを使用して大規模な評価を行う方法について説明しました。理論的なアーキテクチャ設計に加えて、このGitHubのリポジトリ（Llama2とFalcon-7B FMsを特集しています）には、お客様が独自のスケーラブルな評価メカニズムを開発できるサンプルコードもあります。

以下の図は、モデル評価のアーキテクチャを示しています。

この投稿では、図の左側に示されているように、大規模なLLM評価の運用化に焦点を当てました。将来的には、FMOps/LLMOps: 操作可能な生成AIとMLOpsとの違いについて説明されたガイドラインに従い、FMsの全体ライフサイクルを実現する例の開発に焦点を当てる予定です。これには、LLMの提供、モニタリング、出力評価の保存、自動再評価と微調整のトリガー、最後に、ラベル付きデータやプロンプトカタログでの人間を介した作業などが含まれます。