Почему модель — это наименьшая часть развертывания ИИ в государственном секторе и на чем нужно сосредоточиться на самом деле.
Большинство государственных инициатив в сфере ИИ начинаются с одного и того же вопроса: какую модель нам использовать? Это неверная отправная точка. Модели меняются каждые несколько месяцев, поэтому этот выбор легко пересмотреть. Решение, которое определяет курс ведомства на годы вперед — это то, какую часть системы следует создать, купить или скомбинировать.
В нашем новом документе «Анатомия развертывания ИИ: от данных до внедрения» (The Anatomy of an AI Deployment: From Data to Delivery) излагается методология, которую Scale использует совместно с государственными партнерами. Он основан на десятках практических внедрений в различных секторах и странах. Вот идеи, которые имеют наибольшее значение.
Модель — это не продукт
Попросите передовую модель классифицировать заявку на получение разрешения в соответствии с национальным законодательством или составить проект брифинга для кабинета министров в формате министерства. Она ответит бегло, но у вас не будет оснований доверять результату.
Устранение разрыва между правдоподобным ответом и пригодным к использованию — это то, для чего существует развертывание. Практически вся инженерная работа заключается в этом разрыве, и ничто из этого не отображается при сравнении моделей. Таким образом, два вопроса предшествуют вопросу о модели: оправдывает ли этот рабочий процесс создание индивидуальной системы в принципе, и если да, то что именно строится вокруг модели?
Создавать, покупать или комбинировать
Это продолжает тему там, где останавливается концепция суверенного ИИ от Scale: как только сценарий использования преодолевает вопрос национального уровня о том, требуется ли ему суверенный контроль, какую часть системы ведомство должно создать, купить или скомбинировать? Дилемма «создавать или покупать» — это ложный выбор. Практически все, что государственные структуры используют на практике, представляет собой комбинацию. Настоящий вопрос заключается в том, какой объем системы ведомство должно контролировать.
Готовые решения побеждают в общих задачах и при работе с неконфиденциальными данными, причем побеждают быстро. Перевод, внутреннее составление документов и ответы на вопросы по общедоступным документам подходят идеально. Кастомизация оправдывает свои затраты, когда сценарий использования переходит порог, который покупной продукт преодолеть не может: суверенные данные, специализированный рабочий процесс, решения, подлежащие аудиту, или высокая цена ошибки. Большинство государственных рабочих процессов пересекают хотя бы один такой порог.
Пять вопросов позволяют классифицировать практически любой сценарий использования, обычно в рамках одного семинара:
- Являются ли данные конфиденциальными или суверенными?
- Является ли рабочий процесс общим или специализированным?
- Должны ли принимаемые решения подлежать аудиту?
- Какова цена ошибки?
- Будет ли сценарий использования актуален через 18 месяцев? Если да, то владение окупается. Если нет — берите в аренду.
Плата за лицензию редко является самой крупной статьей в счете
Большинство решений о закупках оказываются ошибочными из-за сравнения только видимых затрат. На протяжении жизненного цикла индивидуальной системы лицензионные сборы или плата за API обычно являются наименьшей статьей расходов. Интеграция с системами идентификации, унаследованными базами данных и сетевыми правилами, как правило, оказывается самой крупной и наиболее недооцениваемой. Управление изменениями, инференс в больших масштабах, постоянные обновления моделей и стоимость последующего перехода — все это суммируется.
Адаптация заслуживает особого внимания. Неиспользуемая система обходится в 100% затрат и не приносит никакой отдачи. Ей необходима отдельная строка бюджета, ответственное лицо и метрика реального использования, а не выданных лицензий.
Ценность должна измеряться на четырех уровнях: сначала адаптация, затем влияние по сравнению с базовым показателем до развертывания, затем результаты для граждан и, наконец, окупаемость за весь жизненный цикл системы.
Восемь компонентов, один из которых лицензирован
Каждое индивидуальное развертывание строится на основе восьми компонентов. Только один из них, веса модели, лицензируется лабораторией базовых моделей. Остальные семь разрабатываются специально для данного сценария использования и при соблюдении определенных условий принадлежат ведомству или контролируются им:
- Модель данных: собственные структурированные знания ведомства в своей предметной области. Самый долговечный компонент; он переживает любые модели.
- Промпты: инструкции и контекст, отправляемые при каждом вызове. Структурированная итерация обычно позволяет поднять качество первоначального промпта примерно с 70% на оценочном наборе до высоких 80-х или низких 90-х процентов при использовании той же модели.
- Инженерия контекста: извлечение данных и память, которые определяют, что видит модель, благодаря чему ответы формируются на основе актуального, авторитетного текста и могут содержать ссылки на источники.
- Каркас агентов (скэффолдинг): планирование, маршрутизация, повторные попытки и валидация. Без этого модель может отвечать, но не действовать.
- Инструменты: функции, вызываемые моделью для работы в реальных системах.
- Параметры инференса: настройки, балансирующие стоимость, скорость и стабильность.
- Оценочный комплекс (харнесс): тестовый набор и критерии оценки для каждого изменения.
Пользовательский каркас — это стандартный выбор по умолчанию
Существует три способа заставить модель работать. Готовое решение «из коробки» не требует разработки ни одного из восьми компонентов и подходит для универсальных чат-ботов. Тонкая настройка (файн-тюнинг) задействует все восемь компонентов, включая веса, при максимальных затратах. Пользовательский каркас настраивает семь из восьми компонентов вокруг мощной модели без повторного обучения, и это оптимальный выбор по умолчанию для большинства специализированных рабочих процессов.
Тонкая настройка оправдана в двух случаях: когда самые конфиденциальные рабочие нагрузки должны выполняться локально (on-premise) на более мелких моделях, или когда ни одна передовая модель не может справиться с задачей только за счет инженерных методов. Два ведомства могут обращаться к одной и той же передовой модели и получать совершенно разные результаты. Причина редко кроется в самой модели.
Оценка — это якорь
Процесс внедрения состоит из шести фаз: определение сценария использования, создание оценочного набора, определение базовых показателей и итерации, точка принятия решения, укрепление и развертывание, а затем поддержка. Пропуск этапа создания оценочного набора является наиболее частой причиной неудачного развертывания.
Полезный оценочный комплекс обладает тремя свойствами:
- Покрытие: типичные, сложные и нестандартные случаи, а не только простые.
- Критерии (рубрики): четкие критерии, такие как точность, формат, полнота и тон, согласованные с ведомством до начала настройки.
- Скорость: полный прогон менее чем за десять минут, чтобы его можно было запускать при каждом изменении.
Оценочный комплекс также является артефактом управления. Каждое изменение оценивается по одному и тому же набору, и регулятор может запустить его повторно независимо. Общедоступные бенчмарки помогают сформировать короткий список моделей; только оценочный комплекс показывает, справляется ли система с задачей.
Ответственный ИИ закладывается изначально, а не добавляется потом
Средства контроля встроены в восемь компонентов. Окончательное решение по разрешениям, одобрениям и льготам принимают люди. Оценочные наборы охватывают все рабочие языки, и система, демонстрирующая худшие результаты на каком-то одном языке, считается не прошедшей проверку, какими бы ни были ее средние показатели. Успешные атаки методом «красной команды» (red-team) становятся постоянными тестовыми примерами.
Данные остаются под контролем ведомства. Справочные и операционные данные никогда не попадают в модель. Данные для обучения необходимы только для тонкой настройки, и когда оценочный комплекс достигает целевого показателя, данные для обучения вообще не используются.
Проектируйте с расчетом на изменения
Технологические возможности быстро распространяются вниз по ценовой шкале. Задача, для которой в этом году требуется самая дорогая модель, в следующем году будет выполняться на более дешевой. Поскольку модель данных, оценочный комплекс и конвейеры извлечения данных остаются неизменными, замена модели занимает считанные дни, а не требует перестройки с нуля.
Принцип: привязывайтесь к сценариям использования, а не к поставщикам. Каждый компонент должен быть переносимым между моделями и пригодным для использования без команды, которая его создала, включая партнера по внедрению. Пересматривайте модель, хостинг и стоимость раз в год в соответствии с текущими предложениями рынка.
Шесть рекомендаций
Модель — это наименьшая часть работы. Решение о том, создавать, покупать или комбинировать — самое масштабное.
Для принятия решения до написания какого-либо кода:
- Начинайте с результата, а не с технологии. Сначала определите проблему, пользователей и измеримый успех.
- Ожидайте гибридного подхода. Готовые решения для типовых задач и неконфиденциальных данных; адаптированные — для специализированных рабочих процессов и суверенных данных.
- Создавайте то, что необходимо контролировать; покупайте остальное. Контроль может обеспечиваться как контрактом, так и собственной разработкой.
Что касается метода, то после принятия решения:
- Определяйте успех как измеримый балл на согласованном оценочном наборе, а не как список функций.
- Сделайте оценочный набор первым результатом работы, а не последним.
- Отдавайте предпочтение кастомной обвязке. Прибегайте к дообучению только тогда, когда этого требуют результаты оценки.
Границы возможностей будут постоянно сдвигаться. Созданное таким образом решение выигрывает от каждой новой модели, а не устаревает из-за нее.
Читайте полную версию доклада: «Анатомия развертывания ИИ: от данных до поставки» подробно описывает всю структуру, категории затрат, жизненный цикл поставки и средства контроля ответственного ИИ.
