Как поддерживать надежность в изначально стохастических системах
Делиться
Моя работа уже не совсем такая, как раньше. Работа инженера-программиста в сфере ИИ представляла собой гибрид разработки ПО, разработки ИИ, продуктовой интуиции и некоторой доли пользовательской эмпатии.
В свете всего происходящего мне захотелось сделать шаг назад и поразмыслить над общей картиной, а также над тем, какие навыки и ментальные модели необходимы инженерам, чтобы оставаться впереди. Недавнее прочтение книги O'Reilly «Инженерия искусственного интеллекта» подтолкнуло меня к тому, чтобы глубже разобраться в том, как следует рассматривать оценки — ключевой компонент любой системы искусственного интеллекта.
Было замечено одно: разработка искусственного интеллекта зачастую представляет собой скорее программное обеспечение, чем сам искусственный интеллект.
За пределами исследовательских лабораторий, таких как OpenAI или Anthropic, большинство из нас не обучает модели с нуля. Основная задача — решение бизнес-задач с помощью уже имеющихся инструментов: предоставление моделям достаточного контекста, использование API, построение конвейеров RAG, вызов инструментов — и всё это в дополнение к обычным задачам SWE, таким как развертывание, мониторинг и масштабирование.
Другими словами, разработка искусственного интеллекта не заменяет разработку программного обеспечения, а надстраивает над ней новый уровень сложности.
В этой статье я развиваю некоторые из этих тем. Если какая-то из них вам близка, буду рад узнать ваше мнение — пишите!
Три уровня стека приложений ИИ
Представьте себе приложение ИИ, которое состоит из трех слоев: 1) Разработка приложения 2) Разработка модели 3) Инфраструктура.
Большинство команд начинают с самого верха. Поскольку мощные модели уже доступны, часто имеет смысл сначала сосредоточиться на создании продукта, а затем уже приступать к разработке модели или инфраструктуры по мере необходимости.
Как говорит О'Рейли, «разработка ИИ — это просто разработка программного обеспечения с использованием моделей ИИ, добавленных в стек».
Почему оценки важны и почему они такие сложные
В разработке программного обеспечения одна из самых серьёзных проблем для быстро развивающихся команд — это регрессии . Вы выпускаете новую функцию и в процессе неосознанно ломаете что-то ещё. Спустя несколько недель в пыльном углу кодовой базы обнаруживается ошибка, и её отслеживание превращается в кошмар.
Наличие комплексного набора тестов помогает обнаружить такие регрессии.
Разработка ИИ сталкивается с аналогичной проблемой. Любое изменение — будь то оперативные корректировки, обновления конвейера RAG, тонкая настройка или контекстная инженерия — может повысить производительность в одной области, незаметно ухудшая другую.
Во многих отношениях оценки для ИИ — то же самое, что тесты для программного обеспечения: они выявляют регрессии на ранних стадиях и дают инженерам уверенность в том, что они могут действовать быстро, не ломая ничего.
Но оценивать ИИ непросто. Во-первых, чем интеллектуальнее становятся модели, тем сложнее становится оценивать. Легко определить, что аннотация к книге плоха, если она бессвязна, но гораздо сложнее, если аннотация действительно связная. Чтобы понять, действительно ли она отражает ключевые моменты, а не просто звучит бегло или фактически верно, вам, возможно, придётся прочитать книгу самостоятельно.
Во-вторых, задания часто не имеют однозначного ответа. Редко существует единственный «правильный» ответ, и невозможно составить полный список правильных результатов.
В-третьих, базовые модели рассматриваются как «чёрные ящики», где детали архитектуры модели, тренировочных данных и процесса обучения часто подвергаются тщательному анализу или даже публикуются. Эти данные многое говорят о сильных и слабых сторонах модели, и без них люди оценивают модели только на основе наблюдения за её результатами.
Как думать об оценках
Мне нравится группировать оценки по двум основным категориям: количественные и качественные.
Количественные оценки дают чёткие и однозначные ответы. Правильно ли решена математическая задача? Выполнился ли код без ошибок? Их часто можно протестировать автоматически, что делает их масштабируемыми.
Качественные оценки, с другой стороны, находятся в серой зоне. Они основаны на интерпретации и суждениях — например, на оценке эссе, оценке тональности чат-бота или решении, «звучит ли резюме правильно».
Большинство оценок представляют собой сочетание того и другого. Например, оценка созданного веб-сайта подразумевает не только проверку того, выполняет ли он свои функции (количественная: может ли пользователь зарегистрироваться, войти в систему и т. д.), но и оценку того, насколько интуитивно понятен пользовательский опыт (качественная).
Функциональная корректность
В основе количественных оценок лежит функциональная корректность : действительно ли выходные данные модели выполняют то, что должны выполнять?
Если вы поручите модели создать веб-сайт, главный вопрос заключается в том, соответствует ли сайт её требованиям. Может ли пользователь выполнять ключевые действия? Работает ли он надёжно? Это очень похоже на традиционное тестирование программного обеспечения, когда продукт проходит набор тестовых случаев для проверки поведения. Часто этот процесс можно автоматизировать.
Сходство с эталонными данными
Не все задачи дают такие чёткие и проверяемые результаты. Хороший пример — перевод: не существует единственно «правильного» перевода французского предложения на английский язык, но вы можете сравнить результаты с справочными данными .
Недостаток: это сильно зависит от наличия референтных наборов данных, создание которых требует больших затрат и времени. Данные, созданные человеком, считаются золотым стандартом, но всё чаще референтные данные используются другими системами искусственного интеллекта.
Существует несколько способов измерения сходства:
- Человеческое суждение
- Точное совпадение: проверяется, соответствует ли сгенерированный ответ одному из эталонных ответов в точности. Результат — булев тип.
- Лексическое сходство: измерение того, насколько похожими выглядят результаты (например, совпадения слов или фраз).
- Семантическое сходство: определение того, означают ли выходные данные одно и то же, даже если формулировки различаются. Обычно это включает преобразование данных в эмбеддинги (числовые векторы) и их сравнение. Эмбеддинги подходят не только для текста — такие платформы, как Pinterest, используют их для изображений, запросов и даже профилей пользователей.
Лексическое сходство проверяет только поверхностное сходство, тогда как семантическое сходство проникает глубже в смысл.
ИИ как судья
Некоторые задачи практически невозможно оценить однозначно, используя правила или справочные данные. Оценка тональности чат-бота, оценка связности резюме или критика убедительности рекламного текста — всё это попадает в эту категорию. Люди могут это сделать, но человеческие оценки не масштабируются.
Вот как структурировать этот процесс:
- Определите структурированные и измеримые критерии оценки. Чётко укажите, что для вас важно: ясность, полезность, фактическая точность, тон и т. д. Критерии могут использовать шкалу (от 1 до 5) или двоичные критерии (прошёл/не прошёл).
- Исходные входные данные, сгенерированный результат и любой сопутствующий контекст передаются ИИ-судье. Затем судья выставляет оценку, маркирует её или даже поясняет.
- Агрегируйте данные по нескольким результатам. Выполняя этот процесс на больших наборах данных, можно выявить закономерности — например, заметить, что полезность снизилась на 10% после обновления модели.
Благодаря возможности автоматизации этот процесс обеспечивает непрерывную оценку , заимствуя практику CI/CD в разработке программного обеспечения. Оценки можно проводить до и после изменений в конвейере (от оперативных корректировок до обновлений модели) или использовать для постоянного мониторинга для выявления отклонений и регрессий.
Конечно, ИИ-судьи не идеальны. Как нельзя полностью доверять мнению одного человека, так и не стоит полностью доверять мнению модели. Но при тщательном проектировании, использовании нескольких моделей-судей или их применении к множеству выходных данных они могут обеспечить масштабируемое приближение к человеческому суждению.
Разработка на основе оценки
О'Рейли рассказал о концепции разработки на основе оценки , вдохновленной разработкой на основе тестирования в программной инженерии, и я счел, что этим стоит поделиться.
Идея проста: определите свои оценки до того, как приступить к сборке.
В разработке искусственного интеллекта это означает решение вопроса о том, что такое «успех» и как он будет измеряться.
Влияние по-прежнему важнее, чем шумиха. Правильные оценки гарантируют, что приложения на базе ИИ будут демонстрировать свою ценность способами, актуальными для пользователей и бизнеса.
При определении оценок необходимо учитывать несколько ключевых моментов:
Знание предметной области
Публичные бенчмарки существуют во многих областях — отладка кода, юридические знания, использование инструментов, — но зачастую они носят общий характер. Самые содержательные оценки обычно получаются в результате встреч с заинтересованными сторонами, определения того, что действительно важно для бизнеса, а затем перевода этого в измеримые результаты.
Корректности недостаточно, если решение непрактично. Например, модель преобразования текста в SQL может генерировать корректный запрос, но если его выполнение занимает 10 минут или потребляет огромные ресурсы, он бесполезен при масштабировании. Время выполнения и использование памяти также являются важными метриками.
Возможность генерации
Для генеративных задач — будь то текст, изображение или аудио — оценки могут включать беглость, связность и метрики, специфичные для задачи, такие как релевантность.
Резюме может быть фактически точным, но упускать из виду самые важные моменты — это должно быть отражено в оценке. Всё чаще эти качества могут быть оценены другим ИИ.
Фактическая последовательность
Результаты необходимо сверять с источником достоверности. Это можно сделать двумя способами:
- Локальная согласованность
Это означает проверку выходных данных на соответствие предоставленному контексту. Это особенно полезно для специфических областей, которые уникальны и имеют ограниченный охват. Например, извлечённые данные должны соответствовать данным. - Глобальная согласованность
Это означает проверку результатов на основе открытых источников знаний, например, путем проверки фактов с помощью веб-поиска или маркетингового исследования и т. д. - Самопроверка
Это происходит, когда модель генерирует несколько выходных данных и измеряет, насколько эти ответы согласуются друг с другом.
Безопасность
Помимо обычного понятия безопасности, такого как запрет на ненормативную лексику и контент для взрослых, существует множество других определений безопасности. Например, чат-боты не должны раскрывать конфиденциальные данные клиентов и должны быть способны защищаться от атак с использованием метода «быстрого внедрения».
Подводить итоги
По мере развития возможностей ИИ надёжные оценки будут становиться всё важнее. Они — своего рода барьеры, позволяющие инженерам быстро двигаться вперёд, не жертвуя надёжностью.
Я видел, насколько сложной может быть проблема обеспечения надёжности и насколько дорогостоящими могут быть регрессии. Они вредят репутации компании, раздражают пользователей и создают неприятные условия для разработчиков, заставляя инженеров снова и снова бороться с одними и теми же ошибками.
По мере того, как границы между инженерными ролями размываются, особенно в небольших командах, мы сталкиваемся с фундаментальным изменением в нашем восприятии качества программного обеспечения. Необходимость поддержания и измерения надёжности теперь выходит за рамки систем, основанных на правилах, и распространяется на системы, которые по своей природе являются вероятностными и стохастическими.
Источник: towardsdatascience.com
