← Все статьи
Заметки о технологиях

Риски нейросетей: как замечать ошибки до того, как они станут проблемой

Практический обзор достоверности, конфиденциальности и безопасности.

5–7 минут чтения · Источники приведены в конце

Убедительный ответ может быть неверным

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

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

Конфиденциальность начинается до отправки

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

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

Инструкции, спрятанные в чужих данных

Представьте помощника, который читает страницу и готовит по ней краткое содержание. На странице может оказаться текст, который пытается выдать себя за системную инструкцию и заставить помощника изменить поведение. Это пример внедрения инструкций через недоверенное содержимое. OWASP рассматривает подобные атаки как отдельный класс риска для приложений с языковыми моделями [2].

Не стоит полагаться только на просьбу «игнорировать вредные инструкции». Ограничивайте права инструментов, разделяйте данные и инструкции, проверяйте назначения ссылок и требуйте подтверждения значимых действий. Например, помощник может предложить письмо или команду, но доступ к отправке сообщения либо изменению базы должен контролироваться отдельно. Защитные меры нужно проверять на реалистичных сценариях.

Справедливость и человеческое достоинство

Система может воспроизводить и усиливать перекосы, присутствующие в исходных данных или постановке задачи. Например, автоматическая оценка кандидатов может отразить прежние несправедливые предпочтения вместо реальных требований должности. Также ответ способен неверно описать человека или приписать ему слова, которых он не произносил.

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

Управление рисками на практике

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

Периодически пересматривайте меры: функции инструментов меняются, как и условия их использования. NIST предлагает рассматривать управление рисками на всём жизненном цикле системы [1]. Самая полезная привычка — задавать вопрос не только «умеет ли инструмент это сделать», но и «как мы узнаем, что он сделал это правильно».

Что делать при обнаружении ошибки

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

Источники

  1. NIST, профиль управления рисками генеративного ИИ (2024)
  2. OWASP, риски приложений с языковыми моделями