Жизненный цикл разработки агента

В этом руководстве представлена отправная точка для понимания полного жизненного цикла создания приложения ИИ или агента ИИ. В этом руководстве "Агент ИИ" является обобщающим термином для систем, управляемых GenAI, включая простые вызовы LLM, функции ИИ и реализации на основе агента.

Обзор жизненного цикла разработки

  1. Общие сведения об использовании, области и метриках успешности
  2. Создание начального агента ИИ
  3. Итерация качества агента ИИ
  4. Согласование с заинтересованными сторонами перед производством
  5. Ввод в эксплуатацию и постоянный контроль качества

1. Общие сведения об использовании, области и метриках успешности

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

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

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

Этот фундамент позволяет вам:

  1. Определение источников данных и средств, необходимых агенту
  2. Написание начальных инструкций или запросов, которые отражают предполагаемое поведение
  3. Определение экспертов или тестировщиков домена, которые могут предоставлять примеры и ранние отзывы
  4. Создание автоматизированных судей, которые кодируют критерии оценки и ускоряют итерацию

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

2. Создание начального агента ИИ

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

2.1. Подготовка данных и средств

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

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

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

Создайте и управляйте новыми ресурсами по мере необходимости:

Все эти ресурсы данных и средства управляются и версионируются в Unity Catalog, что делает их обнаруживаемыми и повторно используемыми для агентов и приложений ИИ.

2.2. Создание начального агента

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

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

Если у вас уже есть код агента, можно перенести существующий код в Databricks и развернуть его как приложение Databricks.

По мере создания агента заранее спланируйте оценку и рабочую среду:

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

3. Повторите итерацию по качеству ИИ-агента

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

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

  1. Ранняя валидация разработчиков и заинтересованных сторон
  2. Более широкий обзор экспертов по домену
  3. Отзывы конечных пользователей

3.1. Проверка раннего поведения

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

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

После развертывания внутреннего прототипа Review App Chat UI предоставляет простой интерфейс для сбора отзывов. Поделитесь пользовательским интерфейсом чата для прототипа с небольшим набором разработчиков или экспертов домена, которые могут запрашивать как разумные, так и проблемные запросы.

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

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

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

3.2. Развертывание тестирования и обратной связи

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

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

3.3. Оценка качества и систематическая отладка

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

На практике вы, скорее всего, разделите данные на два типа наборов данных оценки:

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

Приведенные ниже средства помогают создавать и анализировать оба типа наборов данных оценки.

Выполнение тестов регрессии

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

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

Повышение точности автоматического обнаружения

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

Эффективно решайте проблемы с первопричиной

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

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

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

3.4. Устранение проблем и повторная проверка улучшений

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

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

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

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

4. Согласуйте с заинтересованными сторонами перед производством

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

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

5. Введение в эксплуатацию и постоянное следите за качеством

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

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

Дальнейшие действия

  • Last updated on