На пути к обоснованию безопасности обучения передового ИИ
Мы считаем, что вступаем в новую эпоху, в которой для продолжения любого цикла обучения передового ИИ с подкреплением должна требоваться структурированная документация по безопасности. В идеале такая документация должна соответствовать уровню «обоснований безопасности» — всесторонней, структурированной и подкрепленной доказательствами аргументации о рисках, используемой в других отраслях, где безопасность критически важна. Мы рассматриваем обоснования безопасности как ориентир, к которому стремимся. При этом мы признаем, что для моделей ИИ трудно обеспечить такую же строгость обоснований, как в авиации или атомной энергетике: с каждым новым уровнем возможностей ИИ возникает новая сложность. Мы разрабатываем систему, которая позволит закрепить эти практики.
Ниже приведены первые рекомендации, которые, на наш взгляд, следует включить в такие обоснования безопасности обучения передового ИИ. Эти практики отражают накопленный нами опыт. Мы ожидаем, что они будут меняться по мере дальнейшего совершенствования внутренних процессов осмотрительной разработки. Мы делимся ими сейчас, чтобы открыто изложить наш текущий подход и получить обратную связь от сообщества. Обратите внимание: этот документ посвящен обучению передовых моделей с подкреплением. Внутреннее и внешнее развертывание требуют учета гораздо более широкого набора характеристик согласованности.
Обоснования безопасности должны охватывать три аспекта технического стека: обучение согласованности, изоляцию и мониторинг. Эти меры помогают обеспечить, чтобы модель не пыталась действовать вразрез с заданными целями, а если бы и попыталась, ей было бы трудно выйти за пределы изолированной среды и мониторинг выявил бы это до причинения вреда.
Согласованность модели: первой линией защиты должно быть обучение моделей согласованности, то есть надежному поведению в соответствии с нашими намерениями. Сюда могут входить:
Среды обучения и оценивание: снижайте риск формирования рассогласованного поведения, не допуская положительного подкрепления манипуляций с вознаграждением в ходе обучения. Для этого можно использовать:
Автоматизированные проверки наборов данных: используйте агентов для поиска и исправления дефектных сред обучения с подкреплением, в которых рассогласованные траектории действий могут получать высокое вознаграждение за использование уязвимостей, а не за нужное поведение. Это сократит возможности для закрепления рассогласованного поведения при обучении.
Ручные проверки наборов данных: дополняйте автоматизированный red teaming ручным анализом и проверками качества наборов данных, чтобы выявлять некорректные задания, которые могут непреднамеренно закреплять рассогласованное поведение.
Настройка оценщиков: настраивайте оценщики так, чтобы они штрафовали модель за попытки использовать уязвимости или взламывать среды обучения с подкреплением в ходе обучения.
Анализ предыдущих циклов обучения: применяйте классификаторы к трассировкам предыдущих экспериментов, чтобы убедиться, что оценщики работают как задумано.
Измерение согласованности: проводите оценки, отслеживающие склонность модели к рассогласованию, чтобы измерять эффективность обучения согласованности. Для этого можно использовать:
Офлайн-оценки согласованности: проводите оценки согласованности в ходе циклов обучения передовых моделей, чтобы проверять, идет ли обучение как задумано, и расследуйте любые существенные ухудшения.
Ретроспективная проверка: проверяйте методы оценки согласованности на прошлых инцидентах, чтобы убедиться, что они выявляют ранее рассогласованные модели и не подогнаны под конкретные инциденты.
Отслеживание манипуляций с оценками: отслеживайте осведомленность об оценке и метаигру — распознавание моделью того, что ее тестируют, — которые могут вызвать изменение поведения. Например, включайте соответствующий мониторинг при оценке согласованности и задавайте конкретные пороги блокировки.
Стресс-тесты наихудших сценариев: провоцируйте наихудшие варианты нежелательного поведения и проверяйте, что хотя бы один метод оценки способен их выявить.
Запрет на обучение по цепочке рассуждений (CoT): не предоставляйте автоматическим оценщикам доступ к цепочке рассуждений (CoT) при обучении с подкреплением, чтобы модели в ходе обучения не вырабатывали способы обхода мониторинга цепочки рассуждений (CoT).
Изоляция: обеспечьте достаточно надежную изоляцию в песочнице и защиту, чтобы предотвратить вредоносные действия, если модель станет рассогласованной. Для этого можно использовать:
Многоуровневая защита инфраструктуры: вкладывайте значительные ресурсы в усиление защиты как песочницы, в которой работает модель, так и исследовательской инфраструктуры, на которой размещена песочница. Это обеспечит дополнительный уровень защиты на случай выхода из песочницы.
Red teaming изоляции: укрепляйте защиту песочницы, исследовательской инфраструктуры и периметра, итеративно проводя red teaming этих систем с использованием контрольных точек циклов обучения передовых моделей и с учетом анализа безопасности, чтобы находить и устранять пробелы. Также проводите red teaming всех сервисов, с которыми модель может взаимодействовать во время обучения (например, интернет-кэша).
Обмен данными между выборками: разрешайте высокоскоростной обмен данными между выборками только по одобренным каналам, например через инструменты для взаимодействия нескольких агентов, и закрывайте побочные каналы инфраструктуры с высокой пропускной способностью, которые агенты могут легко обнаружить.
Неизменяемые записи взаимодействий: сохраняйте записи взаимодействий агентов в неизменяемом виде на достаточный срок (например, в учетных записях хранилища с однократной записью) для всех процессов обучения с подкреплением, оценки и внутреннего развертывания. Это обеспечит надежное расследование инцидентов и предотвратит случайные изменения записей.
Мониторинг: на случай, если модели начнут действовать вразрез с заданными целями, предусмотрите мониторинг в реальном времени, который выявит возможное рассогласование и позволит быстро устранить приоритетные проблемы до возникновения серьезного инцидента. Для этого можно использовать:
Обеспечение возможности мониторинга: следите за тем, чтобы модели оставались доступными для мониторинга. Проверяйте это с помощью оценок наблюдаемости и обхода мониторинга с четкими пороговыми значениями, чтобы выявлять вызывающее опасения поведение на ранней стадии.
Высокая полнота выявления известных проблем: обеспечьте высокую полноту выявления прошлых инцидентов системой мониторинга на отложенной тестовой выборке.
Актуальность оценок мониторинга: создавайте тестовые примеры, отражающие принципиально новые риски в новых циклах обучения, чтобы показатели полноты и точности мониторинга не устаревали.
Быстрое реагирование: внедрите приоритетные оповещения, по которым в установленный SLA срок принимаются меры: либо вызывается дежурный специалист, либо автоматически приостанавливается затронутый цикл обучения, прежде чем модель причинит вред. Например, днем при инцидентах оповещайте дежурного специалиста по безопасности и ответственного за цикл обучения, а ночью автоматически приостанавливайте циклы, если оповещения остаются без подтверждения.
Наряду с рекомендациями по техническим мерам защиты мы разрабатываем организационные практики подготовки и применения обоснований безопасности для циклов обучения передового ИИ. Они могут включать:
Возражения (предварительный анализ возможных сбоев): после подготовки обоснования безопасности сотрудник другой команды должен составить возражения, выявив возможные пробелы и представив взвешенную оценку риска. Затем команда обучения должна проработать эти возражения, чтобы укрепить обоснование безопасности.
Согласование: обоснование безопасности должны рассмотреть представители высшего руководства, каждый из которых вправе наложить вето на цикл обучения. Это обеспечит несколько уровней внутренней проверки (например, со стороны руководителя исследовательского подразделения или вице-президента по исследованиям, руководителя по безопасности и главного научного сотрудника).
Ответственность: старший руководитель, отвечающий за цикл обучения (например, руководитель исследовательского подразделения или вице-президент по исследованиям), должен нести ответственность за обоснование безопасности и реагирование на любые инциденты, в том числе при оценке результатов его работы. Это создаст и для команд обучения стимул добиваться безопасности и согласованности моделей с заданными целями.
Приостановка: на случай выявления проблем, делающих обоснование безопасности недействительным (например, новой уязвимости), необходимо предусмотреть инструкции, технические механизмы и соглашения об уровне обслуживания (SLA) для приостановки всех охватываемых им циклов обучения.
Внутренняя прозрачность: обоснования безопасности должны быть доступны внутренним надзорным органам (например, Комитету по безопасности и защите).
Аудиты: аудиторам следует предоставить достаточный доступ, чтобы они могли проверить достоверность и обоснованность утверждений в обосновании безопасности и сообщить о выявленных пробелах.
Эскалация: необходим четкий порядок эскалации проблем рассогласования, таблица установленных уровней их серьезности и дежурный специалист по рассогласованию, который сможет экстренно оповестить руководство (например, генерального директора), когда ситуация в ходе обучения достигнет определенного уровня серьезности.
Технические механизмы контроля: людям и агентам должно быть сложно запускать циклы обучения, не соответствующие требованиям. При сбое защитных функций, таких как мониторинг и автоматическая приостановка, работа должна блокироваться. Например, должно быть невозможно начать цикл обучения без включенного надлежащего мониторинга или отключить мониторинг из среды обучения с подкреплением, оценки либо внутреннего развертывания.
Возможность отката: должно быть легко выявить все последующие применения рассогласованной модели в процессе обучения (например, для генерации данных или оценивания), чтобы при необходимости устранить влияние ее рассогласованных результатов.
Полнота учета остаточных рисков: обоснования безопасности должны содержать как можно более полный перечень остаточных рисков, не охваченных действующими мерами защиты, чтобы решения о принятии рисков были обоснованными.
Это наши текущие рекомендации, которые сейчас внедряются в OpenAI. Мы ожидаем, что в ближайшие недели наши практики продолжат развиваться.
Мы также разрабатываем практики расследования серьезных инцидентов рассогласования ИИ. Лаборатории должны стремиться извлечь как можно больше уроков из каждого инцидента, чтобы предотвращать подобные случаи в будущем, — по аналогии с практиками расследования(открывается в новом окне) в других отраслях с высокой ценой ошибки. Вот несколько примеров возможных действий:
Внутренняя прозрачность: поскольку расследование может занять много времени, внутри организации следует регулярно сообщать о его ходе (например, ежедневно для текущих расследований). Для сотрудников должны быть предусмотрены четкие процедуры получения расширенного доступа, в том числе к исходным записям взаимодействий и генерации ответов рассогласованными моделями, если это безопасно и необходимо для их работы.
Первопричины рассогласования: исследователи должны изучать динамику обучения и выявлять первопричины рассогласования (например, с помощью целевых абляционных экспериментов или экспериментов с повторной генерацией выборок). Это поможет понять, как возникло рассогласованное поведение, углубить научное понимание этого явления и эффективнее предотвращать его в будущем.
Разбор инцидента: следует проанализировать организационные процессы и корпоративную культуру, чтобы выявить все причины, способствовавшие инциденту, в том числе понять, почему проблемы возникли и до инцидента оставались незамеченными или не были переданы на более высокий уровень.
Выявление: необходимо разрабатывать методы проверки согласованности, способные выявить склонность к поведению, вызвавшему инцидент, не подгоняя их напрямую под сведения об этом инциденте (например, записи взаимодействий или краткие описания). На основе инцидентов следует создавать «регрессионные тесты», чтобы убедиться, что будущие модели не проявляют склонности к рассогласованию в очень похожих ситуациях.
Публичное раскрытие информации: после завершения расследования его результаты, итоги разбора и изменения в рабочих процессах следует публиковать. Затронутые третьи стороны следует уведомлять как можно скорее.
