«Мониторинг и наблюдаемость LLM – сводка техник и подходов к ответственному искусственному интеллекту»

Monitoring and observability of LLM - summary of techniques and approaches to responsible artificial intelligence

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

Кажется, что сегодняшним утром в каждом списке дел генерального директора, объявлении о вакансии и резюме есть генеративное искусственное интеллекта (genAI). И это совершенно справедливо. Приложения, основанные на базовых моделях, уже изменили способ работы, обучения, написания, проектирования, кодирования, путешествий и покупок миллионов людей. Большинство, включая меня, считают, что это только вершина айсберга.

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

Исследованное программное обеспечение*: Aporia, Arize, Arthur, Censius, Databricks/MLFlow, Datadog, DeepChecks, Evidently, Fiddler, Galileo, Giskard, Honeycomb, Hugging Face, LangSmith, New Relic, OpenAI, Parea, Trubrics, Truera, Weights & Biases, Why Labs

• Snowflake против Data Bricks соревнование за лучшую облачную платформу для данных
• Пройдите обучение на магистерской программе по науке о данных с третьей лучшей онлайн-программой
• Как следует относиться к предвзятой клинической информации в медицинском машинном обучении? Призыв к археологической перспективе

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

Структура статьи

• Оценка LLM — Как оцениваются LLM и готовы ли они к производству?
• Отслеживание LLM — Что означает отслеживание LLM и какие компоненты должны быть включены?
• Мониторинг LLM — Как мониторятся LLM, когда они находятся в производстве?

Жизненный цикл LLM

Ведется борьба за внедрение LLM в рабочие процессы, но техническое сообщество пытается разработать bewt практики, чтобы эти мощные модели вели себя ожидаемым образом в течение времени.

Оценка LLM

Оценка традиционной модели машинного обучения (ML) включает проверку точности ее вывода или предсказаний. Это обычно измеряется известными метриками, такими как Accuracy, RMSE, AUC, Precision, Recall и так далее. Оценка LLM гораздо сложнее. Сегодня данные ученые используют несколько методов.

(1) Метрики классификации и регрессии

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

(2) Метрики текста

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

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

Более сложный подход заключается в извлечении вложений из вывода модели и анализе этих вложений на наличие необычных паттернов. Это можно сделать вручную, исследуя график вложений в трехмерном пространстве. Раскраска или сравнение по ключевым полям, таким как пол, предсказанный класс или оценка перплексии, может выявить скрытые проблемы с вашим приложением LLM и предоставить меру смещения и объяснимости. Существует несколько программных инструментов, которые позволяют визуализировать вложения таким образом. Они кластеризуют вложения и отображают их в трех измерениях. Обычно это делается с помощью HDBSCAN и UMAP, но некоторые используют основанный на K-средних подход.

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

(3) Наборы данных для оценки

Набор данных с размеченными данными позволяет сравнивать текстовый вывод с базовыми одобренными ответами.

Хорошо известным примером является метрика ROUGE. В случае задачи перевода текста, ROUGE опирается на набор эталонных данных, ответы которых сравниваются с оцениваемой моделью LLM. Значимость, точность и множество других метрик могут быть рассчитаны по отношению к эталонным данным. Встраивания играют ключевую роль. Стандартные метрики расстояния, такие как J-S Distance, Hellinger Distance, KS Distance и PSI, сравнивают встраивания выходных данных вашей модели LLM с эталонными встраиваниями.

Наконец, существует ряд широко принятых тестовых испытаний для LLM. Страница HELM от Stanford – отличное место, чтобы узнать о них.

(4) Оценочные LLM

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

Один широко принятый пример – метрика Toxicity. Она опирается на Оценочный LLM (Hugging Face рекомендует roberta-hate-speech-dynabench-r4) для определения, являются ли выходные данные вашей модели токсичными. Все вышеупомянутые метрики из раздела Наборы данных для оценки применимы здесь, поскольку мы рассматриваем выходные данные Оценочного LLM как эталонные.

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

(5) Отзывы пользователей

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

Отслеживание LLM

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

Глубокие идеи получаются при фиксации входных запросов и выходных ответов для будущего анализа. Это кажется простым на поверхности, но на самом деле нет. Сложность возникает из того, что я до сих пор упускал из виду (и большинство ученых-данных делают то же самое, когда говорят или пишут о LLM). Мы не оцениваем, отслеживаем и мониторим LLM. Мы имеем дело с приложением; совокупностью одной или нескольких LLM, предварительно заданными инструкционными запросами и агентами, которые взаимодействуют друг с другом для создания вывода. Некоторые приложения LLM не такие сложные, но многие из них являются таковыми, и тенденция идет к большей сложности. Даже в немного сложных приложениях LLM может быть сложно определить окончательный вызов запроса. Если мы находимся в режиме отладки, нам потребуется знать состояние вызова на каждом шаге и последовательность этих шагов. Практикам захочется использовать программное обеспечение, которое поможет разобраться в этих сложностях.

Мониторинг LLM

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

(1) Функциональный мониторинг

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

(2) Мониторинг запросов

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

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

(3) Мониторинг ответов

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

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

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

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

(4) Оповещение и пороги

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

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

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

(5) Интерфейс мониторинга

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

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

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

Заключительные мысли для практиков и руководителей

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

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

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

Об авторе:

Джош Подуска – ведущий специалист по искусственному интеллекту, стратег и консультант с более чем 20-летним опытом работы. Он является бывшим главным научным сотрудником по обработке полевых данных в Domino Data Lab и управлял командами и стратегией науки о данных в нескольких компаниях. Джош создавал и реализовывал решения науки о данных в различных областях. Он имеет степень бакалавра по математике от UC Irvine и степень магистра по прикладной статистике от Корнелльского университета.