ИИ собираются научить духовно-нравственным ценностям

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

Как ранее сообщал «Ъ», представители силовых структур настаивают на полностью закрытом формате, чтобы исключить оптимизацию моделей под известные экзаменационные вопросы. Участники рынка говорят о рисках замедления технологического прогресса из-за непрозрачности правил. В качестве компромисса обсуждается комбинированная модель — открытый бенчмарк для предварительной самодиагностики разработчиками и закрытый пул заданий с вариативными формулировками для финальной аттестации.

Впрочем, сама идея измерения духовно-нравственных ценностей применительно к ИИ-модели также, по мнению ряда ИТ-спецов, выглядит спорной. «Большие языковые модели генерируют ответы на основе закономерностей, сформированных в обучающих данных и последующей настройке. Скорее мы можем оценивать, как она отвечает на определённый набор этических вопросов и насколько её ответы соответствуют заданным критериям», — говорит младший инженер технологий машинного обучения R-Vision Данила Бояров. Гораздо практичнее проверять, например, насколько модель может быть использована для проведения кибератак, создания оружия или запрещённых веществ. Подобные оценки уже применяются при тестировании передовых моделей в США, в том числе у OpenAI и Anthropic, считает эксперт. При этом пользователям, по мнению эксперта, в первую очередь нужно понимать, как хорошо модель решает конкретные задачи, насколько точно отвечает, умеет ли работать с определёнными типами данных и безопасно ли её использовать.

Векторы атак и скрытые угрозы

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

«Если бенчмарк используется для обязательной оценки, разработчик получает прямой стимул узнать вопросы и оптимизировать модель под них, — поясняет проджект-менеджер ГК Softline (MD Audit) Кирилл Лёвкин. — Полностью открытый набор действительно можно постепенно натренировать. Причём необязательно специально переобучать всю модель: достаточно настроить системные инструкции, дополнительный слой фильтрации или post-processing так, чтобы на известных тестах она демонстрировала нужное поведение. В результате бенчмарк будет измерять способность модели проходить именно этот тест, а не её поведение в реальной эксплуатации».

Однако подгонка под тест грозит не только формализмом. Как отмечает главный специалист группы по анализу защищённости мобильных и веб-приложений компании «Бастион» Алексей Трофимов, утечка тестового набора позволяет недобросовестной лаборатории обучить модель маскировать реальные алгоритмы работы.

«В теории это позволит создать шпиона, который при попадании в инфраструктуру сразу или спустя некоторое время начнёт вредительскую активность. Даже если инструменты, которые модель может использовать, ограничены, последствия могут быть негативными», — предупреждает эксперт.

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

Причина такой уязвимости кроется в самом формате современных бенчмарков, которые обычно проверяют алгоритмы в режиме «вопрос — ответ». Однако изолированный диалог не позволяет предсказать, как поведёт себя сложный автономный агент при наличии системных полномочий.

Дополнительный вектор угрозы возникает при попытке автоматизировать проверку с помощью моделей-арбитров. «Если ответы проверяет другая языковая модель, тестируемая система потенциально может встроить в свой ответ инструкции для модели-арбитра, то есть использовать prompt injection непосредственно внутри самой процедуры оценки. Это ставит под вопрос независимость автоматической проверки», — отмечает Данила Бояров.

Уязвимости могут также возникать и в самой процедуре испытаний за счёт подмены параметров запуска или прямого вмешательства в тестовую среду. «В число критических рисков входят изменение версии модели, параметров запуска, тестового окружения или самих результатов. Отдельный класс — это prompt injection, особенно если тестовая система использует автоматизированные агенты, внешние источники данных или сложные сценарии взаимодействия с моделью», — говорит Кирилл Лёвкин. Поэтому защищать нужно не только датасет. Необходима цепочка доверия от идентификации версии модели и её конфигурации до фиксации входных запросов, ответов и итогового результата, отмечает он.

Как выстроить цепочку доверия

Чтобы закрытый бенчмарк не превратился в скомпрометированную формальность, контур тестирования требует классических мер защиты чувствительной информации.

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

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

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

Другой рубеж защиты связан с отказом от статичных списков вопросов. Любая неизменная база заданий рано или поздно становится известна участникам рынка. «Главный принцип в том, чтобы не давать модели возможность заранее «выучить экзамен»», — считает Кирилл Лёвкин. Поэтому вместо одного постоянного набора нужен пул заданий, из которого формируются разные тестовые сессии. Полезно менять формулировки, контекст и порядок вопросов, сохраняя проверяемую компетенцию. Для закрытой части можно использовать задания, которые никогда не публикуются, и регулярно обновлять их, говорит он.

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

Что должно быть открытым

Процедура тестирования моделей не должна превращаться в «чёрный ящик», считают ИТ-эксперты. «Закрытый финальный набор допустим как защита от подгонки ответов под известные задания. Полная непрозрачность при этом лишает разработчика возможности понять причину провала», — считает управляющий партнёр компании «Зинин, Штурбин и партнёры» Тим Зинин.

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

Дополнительно нужен открытый диагностический набор, близкий по структуре к контрольному, но без совпадающих заданий. «После теста разработчику полезен отчёт по категориям: где система нарушила критерий, к какому типу относится ошибка и какая версия конфигурации участвовала в ответе. Содержимое закрытых заданий можно сохранить в тайне. Такой подход защищает набор от подгонки и оставляет возможность исправить модель, фильтр, системную инструкцию или источник контекста», — считает Тим Зинин.

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

Процесс тестирования должен быть не только прозрачным, но и доступным. Сложная и дорогостоящая процедура сертификации может стать непреодолимым барьером для небольших ИТ-команд, говорит Тим Зинин. Смягчить этот риск можно бесплатным эталонным стендом, единым форматом протокола для повторных проверок и пропорциональными требованиями. «Объём проверки стоит связывать с областью применения и последствиями ошибки: справочный инструмент и система, влияющая на значимое решение, требуют разной глубины контроля. Тогда бенчмарк остаётся инструментом качества, а расходы сохраняют связь с реальным риском продукта», — считает Тим Зинин.

Баланс между безопасностью и развитием

«Важно не создать ситуацию, когда один тест определяет пригодность модели вообще. Корректнее говорить о профиле соответствия: безопасность, надёжность, устойчивость к манипуляциям, корректность работы с чувствительными темами и отдельно — ценностные критерии, — говорит Кирилл Лёвкин. — Стандартизированный набор тестов становится частью обычного жизненного цикла ИИ-разработки. Но не надо превращать такой тест в механический экзамен на правильность. Для задач с однозначным ответом можно использовать чёткие эталоны, а при оценке соответствия духовно-нравственным ценностям неизбежна экспертная интерпретация».

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