Рабочий процесс разработчика приложений на основе генеративного ИИ

Для разработки надежного приложения генеративного ИИ требуется преднамеренное планирование, цикл быстрого развития, обратной связи и оценки, а также масштабируемая производственная инфраструктура. Этот рабочий процесс описывает рекомендуемую последовательность шагов, которые помогут вам выполнить первоначальное подтверждение концепции (POC) до развертывания в рабочей среде.

0. Предварительные требования

• Соберите требования для проверки соответствия ИИ поколения и определения ограничений.
• Проектирование архитектуры решения.

1. Сборка

• Подготовьте источники данных и создайте необходимые средства.
• Создание и проверка начального прототипа (POC).
• Развертывание в предварительной среде.

2. Оцените & Итерация

• Собирать отзывы пользователей и оценивать качество
• Исправление проблем с качеством путем уточнения логики агента и инструментария, базируясь на оценке.
• Использование информации эксперта в области для непрерывного улучшения качества агентской системы.

3. Производство

• Разверните приложение генеративного ИИ в рабочей среде.
• Отслеживайте производительность и качество.
• Поддерживать и улучшать на основе реального использования.

Этот рабочий процесс должен быть итеративным: после каждого цикла развертывания или оценки вернитесь к предыдущим шагам, чтобы уточнить конвейеры данных или обновить логику агента. Например, мониторинг производства может выявить новые требования, инициируя обновления дизайна агента и еще один этап оценки. Следуя этим инструкциям систематически и используя возможности отслеживания Databricks MLflow, Агентный Фреймворк и возможности оценки агентов, вы можете создавать высококачественные приложения генерации ИИ, которые надежно соответствуют потребностям пользователей, требованиям безопасности и соблюдения, и продолжают улучшаться со временем.

0. Необходимые условия

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

Сбор требований включает следующие действия.

• Проверьте, соответствует ли ИИ поколения вашему варианту использования.
• Определите взаимодействие с пользователем.
• Оцените источники данных.
• Задайте ограничения производительности.
• Учёт ограничений безопасности.

дизайн решения включает в себя следующее:

• Планирование конвейеров данных.
• Определите необходимые средства.
• Очертите общую системную архитектуру.

Заложив эту основу, вы задаете четкое направление для последующих этапов сборки, оценки, и производственного.

сбор требований

Определение четких и комплексных требований к варианту использования является важным первым шагом в разработке успешного приложения ИИ поколения. Эти требования служат следующим целям:

• Они помогают определить, подходит ли подход поколения ИИ для вашего варианта использования.
• Они направляют решения по проектированию, реализации и оценке решений.

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

Подходит ли вариант использования для ИИ поколения?

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

• создание контента: задача требует создания нового или творческого содержимого, которое невозможно достичь с помощью статических шаблонов или простой логики на основе правил.
• Динамическая обработка запросов: Запросы пользователей являются открытыми или сложными и требуют гибких ответов с учетом контекста.
• синтез информации: Сценарий использования получает пользу от интеграции и обобщения различных источников информации для получения согласованного результата.
• Агентных системах: Приложению требуется больше, чем просто создание текста в ответ на запрос. Возможно, потребуется способность:
  • планирование и принятие решений: формулирование многоступенчатой стратегии для достижения определенной цели.
  • Принятие мер: запуск внешних процессов или применение различных инструментов для выполнения задач (например, получение данных, вызовы API, выполнение SQL-запросов, выполнение кода).
  • Поддержание состояния: Отслеживание истории бесед или контекста задач в нескольких взаимодействиях для обеспечения непрерывности.
  • создание адаптивных выходных данных: создание ответов, которые развиваются на основе предыдущих действий, обновленных сведений или изменения условий.

И наоборот, подход к ИИ поколения может не быть идеальным в следующих ситуациях:

• Задача очень детерминирована и может быть эффективно решена с помощью предварительно определенных шаблонов или систем на основе правил.
• Весь набор необходимых сведений уже статический или вписывается в простую закрытую платформу.
• Требуются отклики с крайне низкой задержкой (миллисекунды), а накладные расходы на генеративную обработку не могут быть предусмотрены.
• Простые шаблонные ответы достаточно для предполагаемого варианта использования.

Важный

В разделах ниже используются метки P0, P1и метки P2 для указания относительного приоритета.

• 🟢 [P0] элементы являются критически важными или необходимыми. Они должны быть немедленно устранены.
• 🟡 [P1] элементы важны, но могут следовать после требований P0.
• ⚪ [P2] элементы являются задачами с более низким приоритетом или улучшениями, которые могут быть рассмотрены в зависимости от наличия времени и ресурсов.

Эти метки помогают командам быстро узнать, какие требования требуют немедленного внимания и которые могут быть отложены.

Взаимодействие с пользователем

Определите, как пользователи будут взаимодействовать с приложением генеративного ИИ и каких ответов следует ожидать.

• 🟢 [P0] Типичный запрос: Что будет выглядеть типичный запрос пользователя? Сбор примеров от заинтересованных лиц.
• 🟢 [P0] Ожидаемые ответы: Какой тип ответов должен создавать система (например, короткие ответы, объяснения длинной формы, творческие повествования)?
• 🟡 [P1] Модальность взаимодействия: Как пользователи взаимодействуют с приложением (например, интерфейс чата, панель поиска, голосовой помощник)?
• 🟡 [P1] Тон, стиль, структура: Какой тон, стиль и структура должны принимать создаваемые результаты (формальный, разговорный, технический, маркированный список или связная проза)?
• 🟡 [P1]обработка ошибок: Как приложение должно обрабатывать неоднозначные, неполные или внецелевые запросы? Следует ли предоставлять отзывы или запрашивать уточнение?
• ⚪ [P2] Требования к форматированию: Существуют ли конкретные рекомендации по форматированию или презентации для выходных данных (включая метаданные или дополнительные сведения)?

Данные

Определите природу, источник и качество данных, которые будут использоваться в приложении ИИ поколения.

• 🟢 [P0] Источники данных: Какие источники данных доступны?
  • Для каждого источника определите:
    • Структурированные или неструктурированные данные?
    • Что такое исходный формат (например, PDF, HTML, JSON, XML)?
    • Где находятся данные?
    • Сколько доступных данных?
    • Как получить доступ к данным?
• 🟡 Обновления данных [P1]: Как часто обновляются данные? Какие механизмы используются для обработки обновлений?
• 🟡 [P1] Качество данных: известны ли проблемы с качеством или несоответствия?
  • Рассмотрите, требуется ли какой-либо мониторинг качества в источниках данных.

Попробуйте создать таблицу инвентаризации для консолидации этих сведений, например:

Источник данных	Источник	Тип файла	Размер	Частота обновления
Источник данных 1	Том каталога Unity	JSON	10 ГБ	Ежедневно
Источник данных 2	Общедоступный API	XML	NA (API)	Реальное время
Источник данных 3	SharePoint	PDF, .docx	500 МБ	Ежемесячный

Ограничения производительности

Сбор требований к производительности и ресурсам для приложения на основе генеративного ИИ.

задержки

• 🟢 [P0] Время до первого токена: Какова максимальная допустимая задержка перед доставкой первого токена выходных данных?
  • Примечание. Задержка обычно измеряется с помощью p50 (медиана) и p95 (95-й процентиль) для отслеживания средней и худшей производительности.
• 🟢 [P0] Время завершения: Что такое допустимое время отклика (время до завершения) для пользователей?
• 🟢 [P0] Задержка потоковой передачи: Если ответы передаются, допускается более высокая общая задержка?

масштабируемости

• 🟡 [P1]Одновременные запросы пользователей &: Сколько одновременных пользователей или запросов должно поддерживать систему?
  • Примечание. Масштабируемость часто измеряется с точки зрения QPS (запросов в секунду) или QPM (запросов в минуту).
• 🟡 [P1] Шаблоны использования: Каковы ожидаемые шаблоны трафика, пиковые нагрузки или пиковые пики использования?

ограничения затрат

• 🟢 [P0] Ограничения затрат на вывод: Каковы ограничения затрат или ограничения бюджета для вычислительных ресурсов вывода?

Оценка

Определите, как приложение ИИ поколения будет оцениваться и улучшаться с течением времени.

• 🟢 [P0] Бизнес-ключевые показатели эффективности: какая бизнес-цель или ключевые показатели эффективности должны влиять на приложение? Определите базовые значения и целевые объекты.
• 🟢 [P0] Отзывы заинтересованных лиц: кто будет предоставлять первоначальные и текущие отзывы о производительности и выходных данных приложений? Определите определенные группы пользователей или эксперты по домену.
• 🟢 [P0] Измерение качества: какие метрики (например, точность, релевантность, безопасность, оценки человека) будут использоваться для оценки качества созданных выходных данных?
  • Как эти метрики будут вычисляться во время разработки (например, для синтетических данных, вручную курируемых наборов данных)?
  • Как будет измеряться качество в рабочей среде (например, ведение журнала и анализ ответов на реальные запросы пользователей)?
  • Что такое общая терпимость к ошибке? (например, примите определенный процент незначительных фактических неточностей или требуют почти 100% правильность для критических вариантов использования.)
  • Цель состоит в том, чтобы построить набор оценки из фактических запросов пользователей, синтетических данных или сочетания обоих. Этот набор обеспечивает согласованный способ оценки производительности по мере развития системы.
• 🟡 циклы обратной связи [P1]: как собирать отзывы пользователей (например, палец вверх/вниз, формы опроса) и использовать их для итеративного улучшения?
  • Планирование частоты проверки и включения отзывов.

Безопасность

Определите все вопросы безопасности и конфиденциальности.

• 🟢 [P0] Конфиденциальность данных: существуют ли конфиденциальные или чувствительные элементы данных, требующие специальной обработки?
• 🟡 [P1] Элементы управления доступом: Необходимо ли реализовать элементы управления доступом, чтобы ограничить определенные данные или функциональные возможности?
• 🟡 [P1] Оценка угроз & устранения рисков: потребуется ли вашему приложению защита от распространенных угроз, связанных с генеративным ИИ, таких как инъекция команд или вредоносные данные от пользователей?

Развёртывание

Узнайте, как решение ИИ поколения будет интегрировано, развертывается, отслеживается и поддерживается.

• 🟡 : [P1] интеграция Как должно интегрироваться решение генеративного ИИ с существующими системами и рабочими процессами?
  • Определите точки интеграции (например, Slack, CRM, средства бизнес-аналитики) и необходимые соединители данных.
  • Определите, как запросы и ответы будут обрабатываться между генеративным ИИ приложением и зависимыми системами (например, REST API, веб-перехватчиками).
• 🟡 [P1] Развертывание: Каковы требования для развертывания, масштабирования и управления версиями приложения? В этой статье описывается, как комплексный жизненный цикл можно обрабатывать в Databricks с помощью MLflow, каталога Unity, Agent Framework, оценки агентаи обслуживания моделей.
• 🟡 [P1] Мониторинг в производственной среде & наблюдаемость: Как отслеживать приложение после внедрения в производственную среду?
  • Ведение журнала & трассировок: запись полных трассировок выполнения.
  • Метрики качества: непрерывно вычисляют ключевые метрики (такие как правильность, задержка, релевантность) в динамическом трафике.
  • Оповещения & панелях мониторинга. Настройка оповещений для критических проблем.
  • Петля обратной связи: включение отзывов пользователей в производство (положительные или отрицательные отзывы) для обнаружения проблем на ранних стадиях и проведения итеративных улучшений.

Пример

В качестве примера рассмотрим, как эти рекомендации и требования применяются к гипотетическому приложению RAG, используемому группой поддержки клиентов Databricks:

Площадь	Соображения	Требования
Взаимодействие с пользователем	Модальность взаимодействия. Типичные примеры запросов пользователей. Ожидаемый формат отклика и стиль. Обработка неоднозначных или неуместных запросов.	Интерфейс чата, интегрированный с Slack. Примеры запросов: "Как уменьшить время запуска кластера?" "Какой план поддержки у меня есть?" Четкие технические ответы с фрагментами кода и ссылками на соответствующую документацию, где это уместно. При необходимости предоставьте контекстные предложения и передайте их инженерной поддержке.
Логика агента	Понимание запросов и классификация. Многоэтапное планирование и принятие решений. Автономный выбор и выполнение операций с инструментами. Управление состоянием и контекстом в рамках взаимодействий. Механизмы обработки ошибок и резервных механизмов.	Планирование на основе LLM с детерминированными резервными механизмами. Интегрируйте с набором заранее определенных инструментов (например, инструментами для извлечения документов или инструментом Salesforce). Поддержание состояния беседы для последовательного многоэтапного взаимодействия и надежного восстановления ошибок.
Данные	Число и тип источников данных. Формат данных и расположение. Размер и частота обновления данных. Качество и согласованность данных.	Четыре источника данных. Документация компании (HTML, PDF). Разрешенные запросы в службу поддержки (JSON). Публикации форума сообщества (таблица Delta). Коннектор Salesforce. Данные, хранящиеся в каталоге Unity и обновляемые еженедельно. Общий размер данных: 5 ГБ. Согласованная структура данных и качество, поддерживаемые специально выделенными командами и группами поддержки.
Производительность	Максимальная допустимая задержка. Ограничения затрат. Ожидаемое использование и конкурентность.	Требование максимальной задержки. Ограничения затрат. Ожидаемая пиковая нагрузка.
Оценка	Доступность набора данных оценки. Метрики качества. Сбор отзывов пользователей.	Эксперты в предметной области из каждой категории продукта помогают просматривать результаты и корректировать неправильные ответы для создания оценочного набора данных. Ключевые показатели эффективности бизнеса. Увеличение частоты разрешения запросов в службу поддержки. Уменьшение времени пользователя, затраченного на запрос в службу поддержки. Метрики качества. Оценка правильности и релевантности ответа, проведенная LLM. LLM оценивает точность извлечения. Голос за или против пользователя. Коллекция отзывов. Slack будет оснащен возможностью предоставления лайков/дизлайков.
Безопасность	Обработка конфиденциальных данных. Требования к управлению доступом.	Конфиденциальные данные клиента не должны находиться в источнике извлечения. Проверка подлинности пользователей с помощью единого входа в Databricks Community.
Развёртывание	Интеграция с существующими системами. Развертывание и управление версиями.	Интеграция с системой запросов в службу поддержки. Агент, развернутый как конечная точка обслуживания модели Databricks.

Проектирование решения

Инструменты источников данных &

При разработке приложения ИИ поколения важно определить и сопоставить различные источники данных и средства, необходимые для решения. Они могут включать структурированные наборы данных, неструктурированные конвейеры обработки данных или запросы внешних API. Ниже приведены рекомендации по включению различных источников данных или инструментов в приложение генеративного ИИ.

Структурированные данные

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

Неструктурированные данные

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

Действия внешних API &

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

• Управление учетными данными API с помощью подключения Каталога Unity: Используйте подключение Каталога Unity для безопасного управления учетными данными API. Этот метод гарантирует, что токены и секреты централизованно управляются и контролируются доступом.
• Вызов с помощью SDK Databricks:
  Отправка HTTP-запросов во внешние службы с помощью функции http_request из библиотеки databricks-sdk. Эта функция использует подключение каталога Unity для проверки подлинности и поддерживает стандартные методы HTTP.
• использовать функции каталога Unity:
  Оберните внешние подключения в функции каталога Unity для добавления пользовательской логики предварительной или последующей обработки.
• средства исполнителя Python:
  Для динамического выполнения кода для преобразования данных или взаимодействия API с помощью функций Python используйте встроенное средство исполнителя Python.

Пример:

Приложение внутренней аналитики извлекает динамические данные рынка из внешнего финансового API. Приложение использует:

• Внешнее подключение каталога Unity для безопасного хранения учетных данных API.
• настраиваемая функция каталога Unity упаковывает вызов API для добавления предварительной обработки (например, нормализации данных) и последующей обработки (например, обработки ошибок).
• Кроме того, приложение может напрямую вызвать API с помощью пакета SDK Databricks.

Подход к реализации

При разработке приложения ИИ поколения у вас есть два основных варианта реализации логики агента: использование платформы с открытым исходным кодом или создание пользовательского решения с помощью кода Python. Ниже приведена разбивка плюсов и минусов для каждого подхода.

Использование платформы (например, LangChain, LlamaIndex, CrewAI или AutoGen)

Плюсы:

• Готовые компоненты: Фреймворки поставляются с инструментами для управления подсказками, связывания вызовов и интеграции с различными источниками данных, что может ускорить разработку.
• Сообщество и документация: Воспользуйтесь поддержкой сообщества, учебными материалами и регулярными обновлениями.
• распространенные шаблоны проектирования: платформы обычно предоставляют четкую модульную структуру для оркестрации общих задач, что может упростить общую структуру агента.

Недостатки:

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

Использование чистого Python

Преимущества:

• Гибкость: Разработка в чистом Python позволяет адаптировать реализацию точно в соответствии с вашими потребностями, не ограничиваясь решениями по проектированию фреймворка.
• быстрая адаптация: вы можете быстро настроить код и включить изменения по мере необходимости, не ожидая обновлений из внешней платформы.
• Простота: Избегайте ненужных слоев абстракции, что может привести к более простому, более производительному решению.

Недостатки:

• Увеличение усилий по разработке: сборка с нуля может потребовать больше времени и опыта для реализации функций, которые может предоставить выделенная платформа.
• Изобретать велосипед заново: вам может потребоваться разработать общие функции (например, цепочку инструментов или управление запросами) самостоятельно.
• ответственность за обслуживание: все обновления и исправления ошибок становятся вашей ответственностью, что может быть сложной задачей для сложных систем.

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

1. Строить

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

Процесс сборки выполняет следующие ключевые действия.

a. Подготовьте данные & с помощью инструментов: Убедитесь, что необходимые данные доступны, обработаны и готовы к извлечению. Реализуйте или регистрируйте функции и подключения каталога Unity (например, API-интерфейсы извлечения или внешние вызовы API), которые понадобятся вашему агенту. b. агент сборки: оркеструйте основную логику, начиная с простого подхода POC. с. проверка качества: проверить основные функциональные возможности перед тем, как предоставить приложение большему числу пользователей. d. развертывание предварительного агента: сделать POC доступным для тестирования пользователей и экспертов по темам для первоначальной обратной связи. e. Сбор отзывов пользователей: использовать реальные примеры использования для выявления областей улучшения, дополнительных данных или инструментов, необходимых для этого, и потенциальные уточнения для следующей итерации.

a. Подготовка инструментов данных &

На этапе разработки решения вы получите начальную идею источников данных и инструментов, необходимых для приложения. На этом этапе держите его минимальным: сосредоточьтесь на достаточном объеме данных для проверки POC. Это обеспечивает быструю итерацию без больших предварительных инвестиций в сложные конвейеры.

Данные

1. Определение репрезентативного подмножества данных
   • Для структурированных данныхвыберите ключевые таблицы или столбцы, наиболее соответствующие исходному сценарию.
   • Для неструктурированных данныхприоритизируйте индексирование только подмножества репрезентативных документов. Используйте базовый конвейер фрагментирования и внедрения с поиск вектора мозаики ИИ, чтобы при необходимости агент смог получить соответствующие фрагменты текста.
2. Настройка доступа к данным
   • Если приложению требуется выполнять вызовы внешних API, сохраните учетные данные безопасно с помощью подключения каталога Unity.
3. Проверка базового покрытия
   • Убедитесь, что выбранные подмножества данных должным образом рассматривают запросы пользователя, которые планируется протестировать.
   • Сохраните дополнительные источники данных или сложные преобразования для будущих итераций. Ваша текущая цель должна заключаться в доказательстве базовой осуществимости и сборе отзывов.

Инструменты

При настройке источников данных следующим шагом будет реализовать и зарегистрировать инструменты, которые будут вызываться агентом во время выполнения, в каталоге Unity. Инструмент — это функция единого взаимодействия, например SQL-запрос или вызов внешнего API, которую агент может вызвать для извлечения, преобразования или выполнения действий.

средства извлечения данных

• ограниченные структурированные запросы данных: Если запросы исправлены, обтекайте их в функцию SQL каталога Unity или UDF Python. Это обеспечивает централизованную и обнаруживаемую логику.
• открытые структурированные запросы данных: Если запросы более открыты, рассмотрите возможность настройки пространства Genie для обработки запросов текста в SQL.
• вспомогательные функции неструктурированных данных: Для неструктурированных данных, хранящихся в Mosaic AI Vector Search, создать инструмент извлечения неструктурированных данных, которое агент может вызвать для получения соответствующих фрагментов текста.

средства вызова API

• вызовы внешнего API: вызовы APIможно напрямую вызывать с помощью метода http_request пакета SDK Databricks.
• необязательные оболочки: Если необходимо реализовать логику предварительной или последующей обработки (например, нормализацию данных или обработку ошибок), заключите вызов API в функции каталога Unity.

держите минимализм

• Начать только с основных инструментов: Сосредоточиться на одном пути извлечения или ограниченном наборе вызовов API. Вы можете добавить дополнительные сведения по мере итерации.
• интерактивно проверять: тестировать каждое средство независимо (например, в записной книжке), прежде чем включить его в систему агента.

После готовности средств прототипа перейдите к созданию агента. Агент управляет этими средствами для ответа на запросы, получение данных и выполнение действий по мере необходимости.

b. Агент сборки

После размещения данных и средств можно создать агент, который отвечает на входящие запросы, такие как запросы пользователей. Чтобы создать первоначальный агент прототипа, используйте Python или площадки ИИ. Выполните следующие действия.

1. Начните с простого
   • Выбрать базовый шаблон проектирования: для POC, начните с базовой цепочки (например, фиксированной последовательности шагов) или одного агента вызова инструментов (где LLM может динамически вызывать один или два основных инструмента).
     • Если сценарий соответствует одному из примеров записных книжек, предоставленных в документации Databricks, адаптируйте этот код в качестве скелета.
   • Минимальный запрос: сопротивляться призыву перепроектировать запросы на этот момент. Держите инструкции краткими и непосредственно относящимися к вашим основным задачам.
2. Включить средства
   • интеграция инструментов: Если используется шаблон проектирования цепочки, шаги, вызывающие каждое средство, будут жёстко прописаны. В агенте вызова инструментов вы предоставляете схему, чтобы LLM знал, как вызвать функцию.
     • Убедитесь, что инструменты в изоляции функционируют как ожидается, прежде чем включать их в систему агента и выполнять полное тестирование.
   • Ограничители: Если ваш агент может изменять внешние системы или выполнять код, убедитесь, что у вас есть базовые меры безопасности и ограничители (например, ограничение количества вызовов или запрет определенных действий). Реализуйте эти функции в функции каталога Unity .
3. Отслеживание и журналирование агента с помощью MLflow
   • Проследите каждый шаг: Используйте трассировку с помощью MLflow для фиксирования входных данных, выходных данных и времени выполнения, чтобы отладить проблемы и измерить производительность.
   • Зафиксируйте агента: используйте отслеживание с помощью MLflow для логирования кода и конфигурации агента.

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

c. Проверка качества

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

1. Тестируйте интерактивно в ноутбуке
   • Ручное тестирование: вручную вызовите вашего агента с репрезентативными запросами. Обратите внимание, извлекает ли он правильные данные, вызывает средства правильно и соответствует требуемому формату.
   • Проверьте трейсы MLflow: Если вы включили трассировку MLflow, просмотрите пошаговую телеметрию. Убедитесь, что агент выбирает соответствующие средства, обрабатывает ошибки корректно и не создает непредвиденные промежуточные запросы или результаты.
   • проверьте задержку: Обратите внимание, сколько времени занимает выполнение каждого запроса. Если время отклика или использование токенов слишком высоки, возможно, потребуется сократить шаги или упростить логику перед тем как двигаться дальше.
2. Проверка настроения
   • Это можно сделать либо в записной книжке, либо в ИИ Песочнице.
   • Согласованность и правильность &: Имеет ли смысл вывод агента для тестированных запросов? Есть ли вопиющие неточности или отсутствующие подробности?
   • Краевые случаи: Если вы пробовали несколько нетипичных запросов, агент ответил логически или, по крайней мере, завершилось корректно (например, вежливо отказываясь отвечать, а не производя бессмыслицу)?
   • Соблюдение запроса: Если вы предоставили общие инструкции, такие как нужный тон или форматирование, следуют ли им агент?
3. оценка соответствия качества "достаточно хорошему"
   • Если вы ограничены в тестовых запросах в данный момент, рассмотрите возможность создания искусственных данных. См. раздел Создание ознакомительного набора.
   • Устранение основных проблем: Если вы обнаруживаете серьезные недостатки (например, агент неоднократно вызывает недопустимые инструменты или выводит нездоровую информацию), исправьте эти проблемы, прежде чем предоставлять их более широкой аудитории. См. распространенные проблемы с качеством и способы их устранения.
   • Решите о целесообразности: Можно продолжить, если агент соответствует базовому уровню пользовательской удобности и правильности для небольшого набора запросов. Если нет, доработайте запросы, исправьте проблемы с данными или инструментом и повторите тест.
4. Спланировать дальнейшие шаги
   • Отслеживание улучшений: Документируйте любые недостатки, которые вы решили отложить. После сбора реальных отзывов на этапе предварительного производства вы можете вернуться к этим аспектам.

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

д. Развертывание агента для предпродакшн-среды

После того как агент соответствует базовому порогу качества, следующим шагом будет разместить его в предварительной рабочей среде, чтобы понять, как пользователи взаимодействуют с приложением, и собрать их отзывы для направления разработки. Эта среда может быть вашей средой разработки на этапе POC. Основное требование заключается в том, что среда доступна для выбора внутренних тестировщиков или экспертов домена.

1. Разверните агента
   • Внести в журнал и зарегистрировать агента: сначала зарегистрируйте агента как модель MLflow и внесите его в каталог Unity.
   • развернуть с помощью Agent Framework: использовать agent Framework для принятия зарегистрированного агента и развернуть его в качестве конечной точки службы моделей.
2. таблицы умозаключений
   • Agent Framework автоматически сохраняет запросы, ответы и трассировки вместе с метаданными в таблице интерпретации в каталоге Unity для каждой точки обслуживания.
3. Защита и настройка
   • управление доступом:ограничить доступ к конечной точке для вашей тестовой группы (малые и средние предприятия, продвинутые пользователи). Это гарантирует управляемое использование и позволяет избежать неожиданного воздействия данных.
   • проверки подлинности: убедитесь, что все необходимые секреты, токены API или подключения к базам данных настроены правильно.

Теперь у вас есть контролируемая среда для сбора отзывов о реальных запросах. Одним из способов быстрого взаимодействия с агентом является ИИ Playground, где можно выбрать только что созданную конечную точку для работы с моделью и сделать запрос к агенту.

e. Сбор отзывов пользователей

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

1. Используйте приложение проверки

   • При развертывании агента с помощью Agent Framework создается простое чат-стиль приложение для обзора. Он предоставляет удобный для пользователя интерфейс, где тестировщики могут задавать вопросы и немедленно оценивать ответы агента.
   • Все запросы, ответы и отзывы пользователей (палец вверх/вниз, письменные комментарии) автоматически регистрируются в таблицу вывода данных , что облегчает дальнейший анализ.

2. Использование пользовательского интерфейса мониторинга для проверки журналов

   • Отслеживайте голосование 'за'/'против' или текстовые отзывы в интерфейсе мониторинга , чтобы увидеть, какие ответы тестировщики считают особенно полезными (или неполезными).

3. Привлечь экспертов по предметной области

   • Призывайте МСП выполнять типичные и необычные сценарии. Знания о домене помогают выявить тонкие ошибки, такие как неправильное понимание политики или отсутствие данных.
   • Ведите список задач, от небольших изменений в подсказках до более крупных рефакторингов конвейера обработки данных. Определите, какие исправления следует приоритизировать перед переходом.

4. Курировать новые наборы данных для оценки

   • Преобразуйте заметные или проблемные взаимодействия в тестовые случаи. С течением времени они образуют основу более надежного набора данных оценки.
   • По возможности добавьте правильные или ожидаемые ответы на эти случаи. Это помогает оценить качество в последующих циклах оценки.

5. Произведите итерацию на основе отзывов

   • Примените быстрые исправления, такие как небольшие изменения запроса или новые защитные меры, чтобы устранить немедленные проблемные аспекты.
   • Для более сложных проблем, таких как требование расширенной многофакторной логики или новых источников данных, соберите достаточно доказательств, прежде чем инвестировать в крупные архитектурные изменения.

Используя обратную связь из приложения проверки, журналов таблиц вывода и аналитики SME, этот этап предварительной работы помогает устранить пробелы ключей и уточнить итеративное определение агента. Реальные взаимодействия, собранные на этом шаге, создают основу для создания структурированного набора оценки, что позволяет переходить от нерегламентированных улучшений к более систематическому подходу к измерению качества. После устранения повторяющихся проблем и стабилизации производительности вы будете хорошо подготовлены к развертыванию в рабочей среде с проведением надежной оценки.

2. Оценка & итерации

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

На этом этапе приведены следующие действия.

• Сбор реальных запросов из журналов: Преобразовать высокоценные или проблемные взаимодействия из таблиц вывода в тестовые случаи.
• Добавить метки экспертов:, где это возможно, прикрепляйте к этим случаям фактические данные, стиль и политические рекомендации, чтобы можно было более объективно оценивать правильность, обоснованность и другие измерения качества.
• Использование оценки агента: используйте встроенные оценки LLM или настраиваемые проверки для количественной оценки качества приложений.
• Повторите: Улучшите качество, уточнив логику агента, конвейеры данных или запросы. Повторно запустите оценку, чтобы убедиться, устранены ли ключевые проблемы.

Обратите внимание, что эти возможности работают даже если приложение генеративного ИИ запускается за пределамиDatabricks. Инструментируя код с помощью трассировки MLflow, вы можете записывать трассировки из любой среды и объединять их в платформу аналитики данных Databricks для согласованной оценки и мониторинга. По мере того как вы продолжаете внедрять новые запросы, отзывы и аналитические сведения SME, ваш набор данных оценки становится живым ресурсом, который лежит в основе непрерывного цикла улучшения, гарантируя, что ваше приложение ИИ поколения остается надежным, надежным и согласовано с бизнес-целями.

a. Оценка агента

После запуска агента в предпроизводственной среде следующим шагом является систематическое измерение производительности за пределами интуитивных проверок. оценка агента ИИ Мозаики позволяет создавать наборы оценки, выполнять проверки качества с помощью встроенных или пользовательских судей LLM и быстро выполнять итерацию по проблемам.

Автономные и онлайн оценки

При оценке приложений ИИ поколения существует два основных подхода: автономная оценка и онлайн-оценка. На этом этапе цикла разработки основное внимание уделяется автономной оценке, которая относится к систематической оценке за пределами интерактивного взаимодействия с пользователем. Онлайн-оценка будет рассмотрена позже, в разделе о мониторинге агентов в производственной среде.

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

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

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

Вложение времени в оффлайн-оценку приносит значительные дивиденды в долгосрочной перспективе, помогая вам получать consistently высококачественные ответы.

Создайте оценочный набор

Оценочный набор служит основой для измерения производительности приложения на базе генеративного ИИ. Аналогично набору тестов в традиционной разработке программного обеспечения, эта коллекция репрезентативных запросов и ожидаемых ответов становится вашим набором данных тестирования качества и регрессии тестирования.

Вы можете создать набор оценки с помощью нескольких дополнительных подходов:

1. преобразовать журналы таблиц вывода в примеры оценки

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

   Преобразование этих журналов в оценочный набор даёт несколько преимуществ.

   • покрытие в реальном мире: сюда включены непредсказуемые поведения пользователей, которые вы, возможно, не предвидели.
   • Ориентированный на проблемы: можно фильтровать специально по отрицательным отзывам или медленным ответам.
   • Репрезентативное распределение: фиксируется фактическая частота различных типов запросов.

2. Создание искусственных данных оценки

   Если у вас нет курированного набора запросов пользователей, можно автоматически создать синтетический оценочный набор данных. Этот начальный набор запросов помогает быстро оценить, является ли агент:

   • Возвращает последовательные, точные ответы.
   • Отвечает в правильном формате.
   • Учитывает структуру, тональность и руководящие принципы политики.
   • Правильно извлекает контекст (для RAG).

   Искусственные данные обычно не совершенны. Подумайте об этом как временный шаговый камень. Вы также захотите:

   • Попросите специалистов по предметной области или экспертов проверить и удалить любые неуместные или повторяющиеся запросы.
   • Замените его либо дополните позже логами использования в реальном мире.

3. вручную обрабатывать запросы

   Если вы предпочитаете не полагаться на искусственные данные или еще не имеет журналов вывода, определите 10–15 реальных или репрезентативных запросов и создайте из них набор оценки. Репрезентативные запросы могут поступать из интервью с пользователями или из обсуждений на мозговых штурмах разработчиков. Даже короткий, курированный список может разоблачить яркие недостатки в ответах вашего агента.

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

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

Рекомендации по оценке запросов

При создании набора оценки намеренно включают различные типы запросов, например следующие:

• Как ожидаемые, так и непредвиденные шаблоны использования (например, очень длинные или короткие запросы).
• Потенциальные попытки неправильного использования или атаки инъекции запросов (например, попытки обнаружить системный запрос).
• Сложные запросы, требующие выполнения нескольких действий или вызовов инструментов.
• Особые случаи с минимальной или неоднозначной информацией (например, с ошибками в написании или расплывчатыми запросами).
• Примеры, представляющие различные уровни навыков и опыт пользователей.
• Запросы, которые проверяют потенциальные смещения в ответах (например, "compare Company A vs Company B").

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

Добавление критериев оценки

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

Базовые факты или справочные ответы

При оценке фактической точности существует два основных подхода: ожидаемые факты или справочные ответы. Каждая из них служит другой целью в стратегии оценки.

Использовать ожидаемые факты (рекомендуемые)

Подход expected_facts включает перечисление ключевых фактов, которые должны отображаться в правильном ответе. Пример см. в разделе Пример оценочного набора с request, response, guidelinesи expected_facts.

Этот подход обеспечивает значительные преимущества:

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

Встроенный оценщик правильности проверяет, содержит ли ответ агента эти важные факты, независимо от формулировки, порядка или дополнительного материала.

Использовать ожидаемый ответ (альтернативный)

Кроме того, можно предоставить полный справочный ответ. Этот подход лучше всего подходит в следующих ситуациях:

• У вас есть золотые стандартные ответы, созданные экспертами.
• Точная формулировка и структура ответа имеют значение.
• Вы оцениваете ответы в строго регулируемых контекстах.

Databricks обычно рекомендует использовать expected_facts вместо expected_response, так как это обеспечивает большую гибкость, в то же время обеспечивая точность.

Рекомендации по стилю, тону или соответствию политике

Помимо фактической точности, может потребоваться оценить, соответствуют ли ответы определенному стилю, тону или требованиям политики.

Рекомендации только

Если основной проблемой является применение стиля или требований политики, а не фактическая точность, вы можете предоставить рекомендации без ожидаемых фактов:

# Per-query guidelines
eval_row = {
    "request": "How do I delete my account?",
    "guidelines": {
        "tone": ["The response must be supportive and non-judgmental"],
        "structure": ["Present steps chronologically", "Use numbered lists"]
    }
}

# Global guidelines (applied to all examples)
evaluator_config = {
    "databricks-agent": {
        "global_guidelines": {
            "rudeness": ["The response must not be rude."],
            "no_pii": ["The response must not include any PII information (personally identifiable information)."]
        }
    }
}

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

Объединение фактических данных и руководящих принципов

Для комплексной оценки можно объединить проверки фактической точности с рекомендациями по стилю. См. образец оценочного набора с request, response, guidelinesи expected_facts. Этот подход гарантирует, что ответы являются фактически точными и соответствуют стандартам коммуникации вашей организации.

Использование предварительно захваченных ответов

Если вы уже захватили пары запрос-ответ из разработки или тестирования, их можно оценить напрямую без повторного вызова вашего агента. Это полезно для:

• Анализ существующих шаблонов в поведении агента.
• Тестирование производительности по сравнению с предыдущими версиями.
• Экономия времени и средств за счёт отказа от повторной генерации ответов.
• Оценка агента, обслуживаемого за пределами Databricks.

Дополнительные сведения о предоставлении этих соответствующих столбцов в вашем кадре данных оценки см. в Примере : как передать ранее созданные выходные данные для оценки агента. Оценка агента Mosaic AI использует эти заранее сохраненные значения вместо повторного вызова агента, при этом применяются те же проверки качества и метрики.

Рекомендации по критериям оценки

При определении критериев оценки:

1. Будьте конкретными и объективными: определите чёткие, измеримые критерии, которые различные оценщики будут интерпретировать аналогичным образом.
   • Попробуйте добавить пользовательские метрики, чтобы оценить критерии качества, о которым вы заботитесь.
2. Сосредоточьтесь на ценности для пользователей: Определите приоритеты критериям, которые соответствуют тому, что наиболее важно для ваших пользователей.
3. начать просто: Начать с основного набора критериев и расширить по мере роста понимания потребностей качества.
4. Баланс охвата: включить критерии, которые охватывают различные аспекты качества (например, фактическую точность, стиль и безопасность).
5. Повторяйте в соответствии с отзывами: Уточняйте критерии на основе отзывов пользователей и постоянно изменяющихся требований.

Для получения дополнительных сведений о разработке наборов данных оценки высокого качества см. раздел "Рекомендации по разработке" и раздел.

Проведение оценок

Теперь, когда вы подготовили набор оценки с запросами и критериями, можно выполнить оценку с помощью mlflow.evaluate(). Эта функция обрабатывает весь процесс оценки, от вызова агента до анализа результатов.

Базовый рабочий процесс оценки

Для выполнения базовой оценки требуется всего несколько строк кода. Дополнительные сведения см. в Проведение оценки.

При активации оценки:

1. Для каждой строки в наборе данных для оценки mlflow.evaluate() выполняет следующие действия:
   • Вызывает вашего агента с запросом (если вы еще не дали ответ).
   • Применяет встроенные модели LLM для оценки аспектов качества.
   • Вычисляет операционные показатели, такие как использование токенов и задержка.
   • Записывает подробные обоснования для каждой оценки.
2. Результаты автоматически регистрируются в MLflow, создавая:
   • Оценка качества по каждой строке.
   • Агрегированные метрики во всех примерах.
   • Подробные журналы для отладки и анализа.

Настройка оценки

Вы можете настроить оценку в соответствии с конкретными потребностями с помощью дополнительных параметров. Параметр evaluator_config позволяет выполнять следующие действия:

• Выберите встроенные судьи, которые нужно запустить.
• Задайте глобальные рекомендации, применимые ко всем примерам.
• Настройте пороговые значения для судей.
• Предоставьте несколько примеров с небольшим количеством вариантов для руководства оценкой судьи.

Для получения дополнительной информации и примеров см. Примеры.

Оценка агентов за пределами Databricks

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

Какие судьи задействованы

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

Анализ результатов оценки

После выполнения оценки пользовательский интерфейс MLflow предоставляет визуализации и аналитические сведения для понимания производительности приложения. Этот анализ помогает выявлять шаблоны, диагностировать проблемы и определять приоритеты улучшений.

Навигация по результатам оценки

При открытии пользовательского интерфейса MLflow после выполнения mlflow.evaluate(), вы найдете несколько взаимосвязанных представлений. Сведения о том, как перемещать эти результаты в пользовательском интерфейсе MLflow, см. в разделе Просмотр выходных данных с помощью пользовательского интерфейса MLflow.

Для получения руководства по интерпретации шаблонов сбоев см. b. Улучшите агента и средства.

Пользовательские модели ИИ для оценки метрик &

Хотя встроенные инструменты охватывают множество распространенных проверок (таких как правильность, стиль, политика и безопасность), возможно, потребуется оценить аспекты производительности, специфичные для вашего домена. Пользовательские судьи и метрики позволяют расширить возможности оценки для решения уникальных требований к качеству.

судьи для Custom LLM

Дополнительные сведения о создании пользовательского судьи LLM на основе запроса см. в разделе "Создание ИИ-судей на основе запроса".

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

• Соответствие конкретным доменам (юридическое, медицинское, финансовое).
• Стиль фирменной символики и коммуникации.
• Культурная чувствительность и уместность.
• Качество сложных рассуждений.
• Специализированные правила письменности.

Результаты судьи отображаются в пользовательском интерфейсе MLflow вместе с предустановленными судьями, с теми же подробными объяснениями оценок.

пользовательские метрики

Для получения дополнительных программных детерминированных оценок можно создавать пользовательские метрики с помощью декоратора @metric. См. @metric декоратор.

Пользовательские метрики идеально подходят для:

• Проверка технических требований, таких как проверка формата и соответствие схем.
• Проверка наличия или отсутствия определенного содержимого.
• Выполнение количественных измерений, таких как длина отклика или оценки сложности.
• Реализация правил проверки для конкретного бизнеса.
• Интеграция с внешними системами проверки.

b. Улучшение агента и инструментов

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

Распространенные проблемы с качеством и способы их устранения

Оценки судей LLM по результатам вашей оценки указывают на определенные типы сбоев в вашей агентной системе. В этом разделе рассматриваются распространенные шаблоны сбоев и их решения. Информацию о том, как интерпретировать результаты работы судей LLM, см. в результатах работы ИИ-судей.

Рекомендации по итерации улучшения качества

Когда вы выполняете итерацию по усовершенствованиям, соблюдайте строгую документацию. Например:

1. Версионируйте ваши изменения
   • Регистрируют каждую значимую итерацию с помощью отслеживания MLflow.
   • Сохраните запросы, конфигурации и ключевые параметры в центральном файле конфигурации. Убедитесь, что это зарегистрировано с агентом.
   • Для каждого нового развернутого агента сохраните журнал изменений в репозитории, где подробно описаны изменения и почему.
2. Задокументируйте как то, что работало, так и то, что не работало
   • Документируйте успешные и неудачные подходы.
   • Обратите внимание на конкретное влияние каждого изменения на метрики. Вернитесь к ссылке на запуск MLflow для оценки агента.
3. согласование с заинтересованными сторонами
   • Используйте приложение проверки для проверки улучшений с помощью SMEs.
     • Сообщите рецензентам об изменениях, используя инструкции для рецензентов .
   • Для параллельного сравнения разных версий агента рассмотрите возможность создания нескольких точек доступа агента и использования модели в ИИ Playground. Это позволяет пользователям отправлять один и тот же запрос на отдельные конечные точки и проверять ответ и трассировки параллельно.

3. Производство

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

Этап производства включает следующее:

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

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

a. Развертывание агента в рабочей среде

После завершения тщательной оценки и итеративного улучшения вы можете ввести агента в эксплуатацию в рабочей среде. [Платформа агента ИИ Мозаики](/generative-ai/agent-framework/build-gen AI-apps.md#agent-framework) упрощает этот процесс, обрабатывая многие проблемы развертывания автоматически.

Процесс развертывания

Развертывание агента в продакшен включает следующие шаги.

1. Зарегистрируйте и ведите журнал вашего агента в качестве модели MLflow в Unity Catalog.
2. Развернуть агент с помощью Agent Framework.
3. Настройте аутентификацию для любых зависимых ресурсов, к которым вашему агенту нужно получить доступ.
4. Проверьте развертывание, чтобы проверить функциональные возможности в рабочей среде.
   • После готовности конечной точки обслуживания модели вы можете взаимодействовать с агентом на игровой площадке ИИ, где можно протестировать и проверить функциональные возможности.

Подробные инструкции по реализации см. в статье Развертывание агента для создания приложений ИИ.

Рекомендации по развертыванию в рабочей среде

При переходе к промышленной эксплуатации учитывайте следующие ключевые аспекты:

производительность и масштабирование

• Балансируйте затраты и производительность на основе ожидаемых шаблонов использования.
• Рассмотрите возможность включения масштабирования до нуля для периодически используемых агентов для снижения затрат.
• Изучите требования к задержке в зависимости от потребностей пользователей приложения.

системы безопасности и управления

• Убедитесь, что управление доступом на уровне Unity Catalog настроено правильно для всех компонентов агента.
• Используйте встроенное прозрачное средство проверки подлинности для ресурсов Databricks, где это возможно.
• Настройте соответствующее управление учетными данными для внешних API или источников данных.

Подход к интеграции

• Определите, как приложение будет взаимодействовать с агентом (например, с помощью API или внедренного интерфейса).
• Рассмотрим, как обрабатывать и отображать ответы агента в приложении.
  • Если клиентскому приложению требуется дополнительный контекст (например, ссылки на исходные документы или оценки достоверности), разработайте вашего агента таким образом, чтобы он включал эти метаданные в свои ответы (например, с помощью пользовательских выходных данных).
• Планирование обработки ошибок и резервных механизмов для случаев, когда агент недоступен.

сбор отзывов

• Используйте приложение проверки для отзывов заинтересованных лиц во время первоначального развертывания.
• Механизмы разработки для сбора отзывов пользователей непосредственно в интерфейсе приложения.
  • Конечная точка обратной связи, созданная для сбора отзывов из приложения проверки, также может использоваться внешними приложениями для предоставления отзывов об агенте. См. , чтобы оставить отзыв о развернутом агенте.
• Убедитесь, что данные обратной связи передаются в процесс оценки и улучшения.

b. Мониторинг агента в рабочей среде

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

Настройка мониторинга агента

Мозаичный ИИ предоставляет встроенные возможности мониторинга , которые позволяют отслеживать производительность агента без создания пользовательской инфраструктуры мониторинга:

1. Создайте монитор для развернутого агента.
2. Настройте скорость семплирования и частоту в зависимости от объема трафика и требований к мониторингу.
3. Выбрать метрики качества для автоматической оценки выборочных запросов.

Основные измерения мониторинга

Как правило, эффективный мониторинг должен охватывать три критически важных измерения:

1. операционные метрики

   • Запрос объема и шаблонов.
   • Задержка ответа.
   • Коэффициенты ошибок и типы.
   • Использование токенов и расходы.

2. показатели качества

   • Релевантность запросов пользователей.
   • Обоснованность в найденном контексте.
   • Безопасность и соблюдение руководящих принципов.
   • Общая скорость передачи качества.

3. отзывы пользователей

   • Явная обратная связь (палец вверх/вниз).
   • Неявные сигналы (последующие вопросы, заброшенные беседы).
   • Проблемы, сообщаемые в каналы поддержки.

Использование пользовательского интерфейса мониторинга

Пользовательский интерфейс мониторинга предоставляет визуализированные аналитические сведения в этих измерениях с помощью двух вкладок.

• вкладка диаграммы: просмотр тенденций в объёме запросов, метрик качества, задержки и ошибок со временем.
• вкладка "Журналы": изучайте отдельные запросы и ответы, включая результаты их оценки.

Возможности фильтрации позволяют пользователям искать определенные запросы или фильтровать по результатам оценки. Дополнительные сведения см. в разделе Использование пользовательского интерфейса мониторинга.

Создание панелей мониторинга и оповещений

Для комплексного мониторинга:

• Создавайте настраиваемые панели с помощью данных мониторинга, хранящихся в оцененной таблице трассировок.
• Настройте оповещения для критических пороговых значений качества или операционных порогов.
• Запланируйте регулярные проверки качества с ключевыми заинтересованными лицами.

Цикл непрерывного улучшения

Мониторинг наиболее ценен, когда он интегрируется в процесс улучшения.

1. Определить проблемы посредством мониторинга метрик и отзывов пользователей.
2. Экспорт проблемных примеров в набор оценок.
3. Диагностируйте первопричины с помощью анализа трассировки MLflow и оценки результатов LLM (как описано в распространенных проблемах качества и способах их устранения).
4. Разработайте и протестируйте улучшения на расширенном наборе оценки.
5. развертывать обновления и отслеживать влияние.

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