Операционализировать оценку LLM в масштабе с использованием сервисов Amazon SageMaker Clarify и MLOps.

Применение сервисов Amazon SageMaker Clarify и MLOps для оценки LLM в масштабе

За последние несколько лет большие языковые модели (LLM) стали выдающимися инструментами, способными понимать, генерировать и манипулировать текстом с беспрецедентной компетентностью. Их потенциальные применения охватывают разговорные агенты, создание контента и информационный поиск, обещая революцию во всех отраслях. Однако реализация этого потенциала при обеспечении ответственного и эффективного использования этих моделей зависит от критического процесса оценки LLM. Оценка – это задача, используемая для измерения качества и ответственности вывода LLM или генеративной службы искусственного интеллекта. Объяснение LLM Amazon SageMaker предоставляет пользователям большую часть вышеперечисленных преимуществ, предоставляя необходимые инструменты для оценки LLM с простой конфигурацией и одним щелчком мыши. Объединение оценки LLM с Amazon SageMaker Pipelines для обеспечения автоматизации и масштабируемости этого процесса является следующим вызовом. В этой статье мы покажем вам, как интегрировать оценку LLM Amazon SageMaker с Amazon SageMaker Pipelines, чтобы обеспечить оценку LLM в масштабе.

Следующее, что нам нужно сделать, это интегрировать оценку LLM Amazon SageMaker Clarify в жизненный цикл операций машинного обучения (MLOps) для достижения автоматизации и масштабируемости процесса. В этом посте мы покажем вам, как интегрировать оценку LLM Amazon SageMaker Clarify с Amazon SageMaker Pipelines, чтобы обеспечить оценку LLM в масштабе. Кроме того, в этом репозитории GitHub мы предоставляем пример кода, позволяющий пользователям проводить параллельную оценку множества моделей в масштабе, используя такие примеры, как модели Llama2-7b-f, Falcon-7b и Llama2-7b с настройкой.

Кто должен проводить оценку LLM?

Любой, кто тренирует, настраивает или просто использует предварительно обученную LLM, должен точно оценить ее для оценки поведения приложения, работающего с LLM. Относительно этого принципа, пользователей генеративного искусственного интеллекта, которым требуются возможности оценки LLM, можно классифицировать на 3 группы, как показано на следующей схеме: поставщики моделей, настройщики моделей и потребители.

  • Поставщики основных моделей (FM) тренируют модели, которые являются универсальными. Эти модели могут использоваться для многих последующих задач, таких как извлечение признаков или генерация контента. Каждая обученная модель должна быть оценена по многим задачам, не только чтобы оценить ее производительность, но и для сравнения с другими существующими моделями, чтобы выявить области, требующие улучшений, и, наконец, чтобы отслеживать прогресс в данной области. Поставщикам моделей также необходимо проверить наличие предвзятости, чтобы быть уверенными в качестве исходных наборов данных и правильной работы их моделей. Сбор оценочных данных жизненно важен для поставщиков моделей. Кроме того, эти данные и метрики должны быть собраны для соответствия предстоящим регулированиям. Стандарты, инструменты и тесты, разрабатываемые стандартом ISO 42001, указаниями по гражданским правам, Исполнительным поручением администрации Байдена и Европейским актом об искусственном интеллекте, помогают обеспечить безопасность, надежность и доверительность систем искусственного интеллекта. Например, задача Европейского акта об искусственном интеллекте заключается в предоставлении информации о том, какие наборы данных используются для обучения модели, какая вычислительная мощность требуется для работы модели, сообщать результаты модели по общедоступным или отраслевым стандартам и делиться результатами внутреннего и внешнего тестирования.
  • Настройщики моделей хотят решить конкретные задачи (например, классификацию настроения, суммирование, ответы на вопросы), а также использовать предварительно обученные модели для выпуска задач, специфичных для определенной области. Они нуждаются в оценочных метриках, сгенерированных поставщиками моделей, чтобы выбрать правильную предварительно обученную модель в качестве отправной точки. Они должны оценить свои настроенные модели по их желаемому использованию с помощью специфических для задачи или области наборов данных. Зачастую им приходится составлять и создавать свои собственные наборы данных, поскольку общедоступные наборы данных, даже те, которые разработаны для конкретной задачи, могут недостаточно точно учитывать необходимые характеристики для их конкретного случая использования. Настройка моделей более быстрая и дешевая по сравнению с полным обучением и требует более быстрой работы для развертывания и тестирования, так как обычно генерируется множество кандидатских моделей. Оценка этих моделей позволяет непрерывное улучшение, калибровку и отладку моделей. Обратите внимание, что настройщики моделей могут стать потребителями своих собственных моделей, когда они разрабатывают приложения для реального мира.
  • Потребители моделей – это лица или организации, которые обслуживают и контролируют общепринятые или настроенные модели в производстве с целью улучшения своих приложений или услуг с помощью LLM. Первой проблемой, которую они имеют, является обеспечение соответствия выбранной LLM их конкретным потребностям, затратам и ожиданиям производительности. Интерпретация и понимание результатов модели является постоянной проблемой, особенно когда речь идет о конфиденциальности и безопасности данных (например, для проверки рисков и соответствия в регулируемых отраслях, таких как финансовый сектор). Непрерывная оценка моделей критически важна для предотвращения распространения предубеждений или вредоносного контента. Реализация надежной системы мониторинга и оценки позволяет модельным потребителям проактивно выявлять и устранять регрессии в LLM, обеспечивая их эффективность и надежность в течение времени.

Как провести оценку LLM

Эффективная модель оценки включает в себя три основных компонента: одну или несколько ФМ или точно настроенных моделей для оценки входных наборов данных (подсказок, разговоров или обычных входных данных) и логику оценки.

Для выбора моделей для оценки необходимо учитывать различные факторы, включая характеристики данных, сложность проблемы, доступные вычислительные ресурсы и желаемый результат. Входное хранилище предоставляет необходимые данные для обучения, настройки и тестирования выбранной модели. Крайне важно, чтобы это хранилище данных было хорошо структурировано, представительно и имело высокое качество, так как производительность модели в значительной степени зависит от данных, из которых она учится. Наконец, оценочные логики определяют критерии и метрики, используемые для оценки производительности модели.

Вместе эти три компонента формируют целостную рамку, которая гарантирует строгую и систематическую оценку моделей машинного обучения, в конечном итоге приводящую к информированным решениям и улучшению эффективности модели.

Техники оценки моделей все еще являются активной областью исследований. За последние несколько лет сообществом исследователей были созданы множество общедоступных бенчмарков и фреймворков для охвата широкого спектра задач и сценариев, таких как GLUE, SuperGLUE, HELM, MMLU и BIG-bench. Эти бенчмарки имеют таблицы лидеров, которые можно использовать для сравнения и контраста оцененных моделей. Бенчмарки, такие как HELM, также стремятся оценивать метрики, выходящие за рамки мер точности, такие как точность или F1-оценка. В бенчмарке HELM приведены метрики для справедливости, предубежденности и токсичности, которые имеют одинаковое важное значение в общем балле оценки модели.

Все эти бенчмарки включают набор метрик, которые измеряют, как модель справляется с определенной задачей. Самые известные и наиболее распространенные метрики – ROUGE (Recall-Oriented Understudy for Gisting Evaluation), BLEU (BiLingual Evaluation Understudy) или METEOR (Metric for Evaluation of Translation with Explicit ORdering). Эти метрики служат полезным инструментом для автоматической оценки, предоставляя количественные меры лексической схожести между созданным и ссылочным текстом. Однако они не охватывают всю широту языковой генерации, близкой к человеческому, которая включает семантическое понимание, контекст или стилистические нюансы. Например, HELM не предоставляет подробностей оценки, относящихся к конкретным случаям использования, решения для тестирования настраиваемых подсказок и легко интерпретируемые результаты, используемые неспециалистами, поскольку этот процесс может быть затратным, сложным в масштабировании и применяется только для определенных задач.

Кроме того, достижение языковой генерации, близкой к человеческой, часто требует учета человеческого фактора для качественной оценки и принятия суждений, дополняющих автоматические метрики точности. Оценка человеком является ценным методом для оценки LLM, но она также может быть субъективной и подвержена предубеждению, поскольку разные человеческие оценщики могут иметь разные мнения и толкования качества текста. Кроме того, оценка человеком может потребовать больших ресурсов и быть дорогостоящей, а также требовать значительного времени и усилий.

Давайте поглубже разберемся, как Amazon SageMaker Clarify на практике связывает все эти моменты, помогая клиентам проводить тщательную оценку и выбор моделей.

Оценка LLM с помощью Amazon SageMaker Clarify

Amazon SageMaker Clarify помогает клиентам автоматизировать оценку метрик, включая, но не ограничиваясь, точностью, надежностью, токсичностью, стереотипами и фактическими знаниями для автоматической оценки, а также стилем, связностью, актуальностью для оценки на основе человека, и методами оценки, предоставляя фреймворк для оценки LLM и сервисов, основанных на LLM, таких как Amazon Bedrock. В качестве полностью управляемого сервиса SageMaker Clarify упрощает использование оценочных фреймворков с открытым исходным кодом в Amazon SageMaker. Клиенты могут выбирать соответствующие наборы данных и метрики оценки для своих сценариев и расширять их собственными наборами данных и алгоритмами оценки подсказок. SageMaker Clarify предоставляет результаты оценки в нескольких форматах для поддержки различных ролей в рабочей среде LLM. Специалисты по данным могут анализировать подробные результаты с помощью визуализаций SageMaker Clarify в Notebooks, Сard-моделей SageMaker и отчетов в формате PDF. В то же время команды операций могут использовать Amazon SageMaker GroundTruth для обзора и аннотирования высокорисковых элементов, которые идентифицирует SageMaker Clarify. Например, по стереотипам, токсичности, утечке личной информации или низкой точности.

Аннотации и обучение с подкреплением впоследствии используются для устранения потенциальных рисков. Понятные объяснения выявленных рисков ускоряют процесс ручного обзора и снижают издержки. Сводные отчеты предлагают бизнес-заказчикам сравнительные показатели между различными моделями и версиями, что способствует принятию обоснованных решений.

Следующая рисунок показывает структуру для оценки LLM и LLM-базованных сервисов:

Amazon SageMaker Clarify LLM evaluation – это открытая библиотека модели оценки Foundation Model Evaluation (FMEval), разработанная AWS, чтобы помочь клиентам легко оценивать LLM. Все функциональные возможности также были включены в Amazon SageMaker Studio для возможности оценки LLM пользователями. В следующих разделах мы представим интеграцию возможностей оценки Amazon SageMaker Clarify LLM с SageMaker Pipelines для оценки LLM в масштабе с использованием принципов MLOps.

Жизненный цикл Amazon SageMaker MLOps

Как описывается в посте «MLOps фундаментальный план для предприятий с использованием Amazon SageMaker», MLOps – это комбинация процессов, людей и технологии для эффективного интегрирования использования ML в производство.

Следующая рисунок показывает полный цикл жизни MLOps:

Типичное путешествие начинается с создания научным сотрудником блокнота для доказательства того, что ML может решить бизнес-проблему. Во время разработки доказательства концепта (PoC) научным сотрудникам приходится преобразовывать ключевые показатели эффективности бизнеса (KPI) в метрики модели машинного обучения, такие как точность или ложноположительная оценка, и использовать ограниченный тестовый набор данных для оценки этих метрик. Научные сотрудники сотрудничают с инженерами по машинному обучению для переноса кода из блокнотов в репозитории, создания ML-пайплайнов с использованием Amazon SageMaker Pipelines, которые связывают различные этапы обработки и задачи, включая предварительную обработку, обучение, оценку и постобработку, всегда внедряя новые производственные данные. Развертывание Amazon SageMaker Pipelines зависит от взаимодействия с репозиториями и активации конвейера CI/CD. ML-пайплайн хранит модели с лучшей производительностью, изображения контейнеров, результаты оценки и информацию о состоянии в реестре моделей, где ответственные за модель оценивают производительность и принимают решение о переходе к производству на основе результатов и бенчмарков, после чего активируется другой конвейер CI/CD для тестирования и развертывания в производство. После ввода в эксплуатацию потребители ML используют модель с помощью вызова оценки приложения через прямое обращение или вызовы API, с обратной связью с владельцами моделей для непрерывной оценки производительности.

Интеграция Amazon SageMaker Clarify и MLOps

Следуя жизненному циклу MLOps, настройщики или пользователи моделей с открытым исходным кодом вводят в эксплуатацию настроенные модели или модели Fine-tuned models или FM с использованием служб Amazon SageMaker Jumpstart и MLOps, как описано в статье Внедрение практик MLOps с использованием предварительно обученных моделей Amazon SageMaker JumpStart. Это приводит к новой области операций с домашними моделями (FMOps) и LLM-операций (LLMOps) FMOps/LLMOps: Создание операционных возможностей генеративного ИИ и различий с MLOps.

Следующая рисунок показывает полный цикл жизни LLMOps:

В LLMOps основные отличия по сравнению с MLOps заключаются в выборе модели и оценке модели, привлекающей различные процессы и метрики. Находясь в начальной фазе экспериментирования, научные сотрудники (или настройщики) выбирают FM, которая будет использоваться для конкретного случая использования Генеративного ИИ. Это часто приводит к тестированию и настройке нескольких FM, некоторые из которых могут давать сравнимые результаты. После выбора модели(ей), инженеры ответственны за подготовку необходимых входных данных и ожидаемого результата для оценки (например, входные запросы, включающие входные данные и запросы) и определения метрик, таких как сходство и токсичность. Помимо этих метрик, научные сотрудники или настройщики должны проверить результаты и выбрать соответствующую FM не только на основе метрик точности, но и на основе других возможностей, таких как задержка и стоимость. Затем они могут развернуть модель на конечную точку SageMaker и протестировать ее производительность в небольшом масштабе. В то время как фаза экспериментирования может включать простой процесс, переход в производство требует от клиентов автоматизировать процесс и улучшать устойчивость решения. Поэтому нам нужно глубже изучить, как автоматизировать оценку, обеспечивая возможность эффективной оценки на большом масштабе и внедряя мониторинг входных и выходных данных модели в реальном времени.

Автоматизация оценки FM

Amazon SageMaker Pipelines автоматизирует все фазы предобработки, настройки FM (по желанию) и оценки в масштабе. При задании выбранных моделей во время экспериментирования, инженерам необходимо охватить более широкий набор сценариев, подготовив множество подсказок и сохранив их в назначенном хранилище под названием каталог подсказок. Дополнительную информацию можно найти по ссылке FMOps/LLMOps: Операционализация генеративного искусственного интеллекта и отличия от MLOps. Затем Amazon SageMaker Pipelines могут быть структурированы следующим образом:

Сценарий 1 – Оценить несколько FM: В этом сценарии FM могут охватывать бизнес-кейс без настройки. Amazon SageMaker Pipeline состоит из следующих шагов: предобработка данных, параллельная оценка нескольких FM, сравнение моделей и выбор на основе точности и других свойств, таких как стоимость или задержка, регистрация выбранных артефактов модели и метаданных.

Ниже приведена диаграмма этой архитектуры.

Сценарий 2 – Настроить и оценить несколько FM: В этом сценарии Amazon SageMaker Pipeline структурирован так же, как в сценарии 1, но выполняет параллельно как настройку, так и оценку для каждого FM. Лучшая настроенная модель будет зарегистрирована в Реестре моделей.

Ниже приведена диаграмма этой архитектуры.

Сценарий 3 – Оценить несколько FM и настроенных FM: В этом сценарии сочетаются оценка общего назначения FM и настроенных FM. В этом случае клиенты хотят проверить, может ли настроенная модель работать лучше, чем общепринятая FM.

На следующем рисунке показаны результаты шагов SageMaker Pipeline.

Обратите внимание, что регистрация моделей осуществляется двумя способами: (a) хранение модели с открытым исходным кодом и артефактов или (b) хранение ссылки на собственный FM. Дополнительную информацию можно найти по ссылке FMOps/LLMOps: Операционализация генеративного искусственного интеллекта и отличия от MLOps.

Обзор решения

Чтобы ускорить ваш путь в оценке LLM в масштабе, мы создали решение, которое реализует сценарии с использованием как Amazon SageMaker Clarify, так и нового Amazon SageMaker Pipelines SDK. Пример кода, включая наборы данных, исходные блокноты и SageMaker Pipelines (шаги и ML-пайплайн), доступен на GitHub. При разработке данного решения мы использовали два FM: Llama2 и Falcon-7B. В этом посте основное внимание уделяется ключевым элементам решения SageMaker Pipeline, относящимся к процессу оценки.

Конфигурация оценки: В целях стандартизации процедуры оценки мы создали файл конфигурации YAML (evaluation_config.yaml), который содержит необходимую информацию для процесса оценки, включая набор данных, модель(и) и алгоритмы для выполнения на шаге оценки SageMaker Pipeline. Ниже приведен пример конфигурационного файла:

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 предоставляет пользователям гибкость определения пользовательских шагов в рабочем процессе машинного обучения с использованием декоратора Python ‘@step’. Поэтому пользователям необходимо создать базовый скрипт на 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 автоматически генерирует рабочий процесс, интерпретируя зависимости между различными шагами при вызове API создания SageMaker Pipeline, как показано в следующем примере:

import os
import argparse
from datetime import datetime
import sagemaker
from sagemaker.workflow.pipeline import Pipeline
from sagemaker.workflow.function_step import step
from sagemaker.workflow.step_outputs import get_step
# Импорт необходимых шагов
from steps.preprocess import preprocess
from steps.evaluation import evaluation
from steps.cleanup import cleanup
from steps.deploy import deploy
from lib.utils import ConfigParser
from lib.utils import find_model_by_name
if __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) показан на следующей картинке.

Последуя аналогичному подходу и, используя и настраивая пример из Fine-tune LLaMA 2 models on SageMaker JumpStart, мы создали конвейер для оценки уточненной модели, как показано на следующей картинке.

Используя предыдущие шаги конвейера SageMaker в качестве “конструкторских” блоков, мы разработали решение для Сценария 1 и Сценария 3, как показано на следующих рисунках. Конкретно, репозиторий GitHub позволяет пользователю оценивать несколько моделей FM параллельно или выполнять более сложную оценку, комбинируя оценку как фундаментальных, так и уточненных моделей.

Дополнительные функции, доступные в репозитории, включают:

  • Генерация шагов динамической оценки: Наше решение динамически генерирует все необходимые шаги оценки на основе файла конфигурации, чтобы пользователи могли оценить любое количество моделей. Мы расширили решение для поддержки простой интеграции новых типов моделей, таких как Hugging Face или Amazon Bedrock.
  • Предотвращение повторного развертывания точки доступа: Если точка доступа уже находится на месте, мы пропускаем процесс развертывания. Это позволяет пользователю повторно использовать точки доступа с FM для оценки, что приводит к экономии затрат и сокращению времени развертывания.
  • Удаление точки доступа: После завершения оценки конвейер SageMaker деактивирует развернутые точки доступа. Эта функциональность может быть расширена для сохранения точки доступа лучшей модели.
  • Шаг выбора модели: Мы добавили заполнитель для шага выбора модели, требующий определения логики бизнеса для выбора конечной модели, включая критерии, такие как стоимость или задержка.
  • Шаг регистрации модели: Лучшая модель может быть зарегистрирована в Amazon SageMaker Model Registry в качестве новой версии определенной группы моделей.
  • Теплое пул: Управляемые SageMaker тепловые пулы позволяют сохранять и повторно использовать предоставленную инфраструктуру после завершения задания для снижения задержки при повторяющихся рабочих нагрузках

На следующей картинке показаны эти возможности и пример многомодельной оценки, которую пользователи могут легко и динамически создавать с помощью нашего решения в репозитории GitHub.

Мы специально оставили подготовку данных за рамками этого обзора, так как она будет подробно описана в другой публикации, включая создание каталога требований, шаблонов запросов и оптимизацию запросов. Дополнительную информацию и связанные компоненты можно найти в статье FMOps/LLMOps: Операционализация генеративного искусственного интеллекта и различия с MLOps.

Заключение

В этой статье мы сосредоточились на том, как автоматизировать и операционализировать оценку LLM в масштабе с использованием возможностей оценки модели Amazon SageMaker Clarify LLM и Amazon SageMaker Pipelines. В дополнение к теоретическим архитектурным решениям, у нас есть примеры кода в этом репозитории GitHub (сделанные на основе моделей Llama2 и Falcon-7B), чтобы позволить клиентам разрабатывать собственные масштабируемые механизмы оценки.

На следующей иллюстрации показана архитектура оценки модели.

В этой статье мы сосредоточились на операционализации оценки LLM в масштабе, как показано на левой стороне иллюстрации. В будущем мы сосредоточимся на разработке примеров, которые покроют всю жизненный цикл моделей, от FMs до продуктивного использования, следуя руководству, описанному в статье FMOps/LLMOps: Операционализация генеративного искусственного интеллекта и отличия от MLOps. Это включает обслуживание LLM, мониторинг, хранение выходных рейтингов, которые в конечном итоге приведут к автоматической повторной оценке и настройке, а также взаимодействие с людьми для работы с размеченными данными или каталогами запросов.