Введение в Giskard Открытый инструмент управления качеством для моделей искусственного интеллекта

Giskard Открытый инструмент управления качеством для моделей искусственного интеллекта – Введение

Спонсорский контент

 

Обеспечение качества моделей искусственного интеллекта в производстве – сложная задача, и эта сложность выросла в геометрической прогрессии с появлением моделей с большим языковым объемом (LLM). Чтобы решить эту проблему, мы с восторгом объявляем официальный запуск Giskard, первой системы управления качеством искусственного интеллекта с открытым исходным кодом.

Разработанный для комплексного покрытия жизненного цикла модели искусственного интеллекта, Giskard предоставляет набор инструментов для сканирования, тестирования, отладки, автоматизации, совместной работы и мониторинга моделей искусственного интеллекта, охватывая табличные модели и LLM, особенно для случаев использования усиленного поиска с возвратом (RAG).

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

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

 

Каковы 3 ключевых требования для системы управления качеством моделей искусственного интеллекта?

 

Проблема специфических для области и бесконечных крайних случаев

 

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

Допустим, у нас есть модель RAG, разработанная для помощи пользователям в поиске ответов о изменении климата с использованием доклада IPCC. Это будет основной пример, используемый в этой статье (см. сопутствующий блокнот Colab notebook).

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

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

 

Требование 1 – Двухэтапный процесс совмещающий автоматизацию и человеческий надзор

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

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

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

 

Проблема разработки ИИ как экспериментального процесса, полного компромиссов

 

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

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

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

 

Требование 2 – Качественный процесс, встроенный по дизайну в жизненный цикл разработки вашей AI

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

Например, для системы RAG вам необходимо включить шаги качества на каждом этапе жизненного цикла разработки AI:

  • Предварительное производство: внедрите тесты в CI/CD-пайплайны, чтобы убедиться, что у вас нет регрессий каждый раз, когда вы публикуете новую версию модели.
  • Внедрение: внедрите ограничения, чтобы ограничить ваши ответы или ввести предостерегающие меры. Например, если ваша система RAG ответит на вопрос вроде “как создать бомбу?” на производстве, вы можете добавить ограничения, которые оценивают вредность ответов и останавливают его до достижения пользователя.
  • Пост-производство: мониторинг качества ответа вашей модели в режиме реального времени после внедрения.

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

 

Из вызовов документирования моделей ИИ для соблюдения регуляторных требований и сотрудничества

 

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

  • Документация для аудиторов: Объемная документация, отвечающая некоторым конкретным контрольным точкам и предоставляющая доказательства для каждой точки. Это то, что требуется для регуляторных аудитов (Закон ЕС об ИИ) и сертификаций в соответствии с качественными стандартами.
  • Панели управления для специалистов по данным: Панели управления с некоторыми статистическими метриками, объяснениями модели и оповещениями в режиме реального времени.
  • Отчеты для IT-специалистов: Автоматизированные отчеты внутри ваших CI/CD-пайплайнов, которые автоматически публикуют отчеты в виде обсуждений в запросах на включение кода или других IT-инструментах.

К сожалению, создание такой документации не является самой привлекательной частью работы с данными. Из нашего опыта можно сказать, что ученые-данные обычно не любят писать объемные отчеты о качестве с тестовыми наборами. Но глобальные регуляции ИИ теперь делают это обязательным. Статья 17 Закона ЕС об ИИ явно требует внедрения “системы управления качеством для ИИ”.

 

Требование 3 – Бесшовная интеграция, когда все складывается гладко, и четкое руководство, когда это не так

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

Метрики и отчеты о качестве должны быть записаны непосредственно в вашей среде разработки (нативная интеграция с библиотеками машинного обучения) и среде DevOps (нативная интеграция с GitHub Actions и т. д.).

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

В Giskard мы активно участвуем в разработке стандартов для Закона ЕС об ИИ вместе с официальным европейским органом по стандартизации CEN-CENELEC. Мы понимаем, что создание такой документации может быть трудоемкой задачей, но мы также осознаем увеличивающиеся требования, которые будущие регуляции возможно предъявят. Наша цель – упростить создание такой документации.

 

Giskard – первая открытая система управления качеством для моделей ИИ

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

Система Giskard состоит из 5 компонентов, объясненных на следующей диаграмме:

 

Проверка на обнаружение уязвимостей вашей модели ИИ автоматически

 

Давайте использовать пример модели LLM-based RAG, основанной на отчете IPCC, чтобы ответить на вопросы о изменении климата.

Функция Giskard Scan автоматически обнаруживает несколько потенциальных проблем в вашей модели всего в 8 строках кода:

import giskard‍qa_chain = giskard.demo.climate_qa_chain()model = giskard.Model(  qa_chain,    model_type="text_generation",    feature_names=["question"],)giskard.scan(model)

 

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

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

 

Библиотека для проверки регрессий

 

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

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

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

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

Чтобы сгенерировать тестовый набор из результатов сканирования и выполнить его, вам нужны всего 2 строки кода:

test_suite = scan_results.generate_test_suite("Начальный тестовый набор") test_suite.run()

 

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

 

Платформа для настройки тестов и отладки проблем

 

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

В отличие от простого улучшения тестов, Giskard Hub позволяет вам:

  • Сравнивать модели, чтобы определить, какая из них лучше выполняет заданные метрики
  • Беспрепятственно создавать новые тесты, экспериментируя с вашими подсказками
  • Делиться результатами тестов с членами команды и заинтересованными сторонами

 

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

Хотите попробовать сами? Вы можете использовать демонстрационную среду Giskard Hub, размещенную на Hugging Face Spaces: https://huggingface.co/spaces/giskardai/giskard

 

Автоматизация в CI/CD конвейерах для автоматической публикации отчетов

 

Наконец, вы можете интегрировать отчеты о тестировании во внешние инструменты через API Giskard. Например, вы можете автоматизировать выполнение вашего тестового набора в рамках вашего CI конвейера, так что каждый раз при открытии запроса на слияние (PR) для обновления версии вашей модели, возможно, после новой фазы обучения, ваш тестовый набор будет автоматически запущен.

Вот пример такой автоматизации с использованием GitHub Action на запрос.

Вы также можете сделать это с помощью Hugging Face с нашей новой инициативой – бот Giskard. Когда новая модель загружается в Hugging Face Hub, бот Giskard инициирует запрос на объединение, который добавляет следующий раздел в карточку модели.

Бот предлагает эти предложения в виде запроса на объединение в карточке модели на Hugging Face Hub, упрощая процесс обзора и интеграции для вас.

LLMon для мониторинга и получения оповещений, когда что-то идет не так в производстве

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

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

Этот уровень проверки позволяет лучше понять проблему, помогает диагностировать и решать проблему. Кроме того, вы можете настроить оповещения в выбранном вами инструменте для обмена сообщениями (например, Slack), чтобы быть проинформированным и принять меры по любым аномалиям.

Вы можете получить бесплатный пробный аккаунт для этого инструмента мониторинга LLM на специальной странице.

Заключение

В этой статье мы представили Giskard в качестве системы управления качеством для моделей искусственного интеллекта, готовой к новой эре регулирования безопасности искусственного интеллекта. Мы проиллюстрировали ее различные компоненты на примерах и осветили то, как она выполняет 3 требования для эффективной системы управления качеством моделей искусственного интеллекта:

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

Дополнительные ресурсы

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

Мы создаем в открытом доступе, поэтому приветствуем вашу обратную связь, запросы функций и вопросы! Вы можете связаться с нами на GitHub: https://github.com/Giskard-AI/giskard