Дезинформация (Misinformation)

Описание

Дезинформация (Misinformation), генерируемая LLM, представляет собой ключевую уязвимость для приложений, которые на эти модели полагаются. Дезинформация возникает, когда LLM выдают ложную или вводящую в заблуждение информацию, которая выглядит достоверной. Эта уязвимость может привести к нарушениям безопасности, репутационному ущербу и юридической ответственности.

Одна из главных причин дезинформации — галлюцинации (hallucination), когда LLM генерирует контент, который кажется точным, но является вымышленным. Галлюцинации возникают, когда LLM заполняют пробелы в обучающих данных на основе статистических закономерностей, не понимая содержания по-настоящему. В результате модель может выдавать ответы, которые звучат правильно, но совершенно ничем не обоснованы. Хотя галлюцинации — основной источник дезинформации, это не единственная причина: свой вклад могут вносить также смещения (biases), привнесённые обучающими данными, и неполнота информации.

Связанная проблема — чрезмерное доверие (overreliance). Оно возникает, когда пользователи излишне доверяют контенту, сгенерированному LLM, и не проверяют его точность. Чрезмерное доверие усиливает последствия дезинформации, поскольку пользователи могут без должной проверки использовать неверные данные в критически важных решениях или процессах.

Типовые примеры уязвимости

1. Фактические неточности. Модель выдаёт неверные утверждения, из-за чего пользователи принимают решения на основе ложной информации. Например, чат-бот Air Canada предоставил пассажирам недостоверную информацию, что привело к операционным сбоям и юридическим осложнениям. В результате иск против авиакомпании был удовлетворён (ссылка: BBC, https://www.bbc.com/travel/article/20240222-air-canada-chatbot-misinformation-what-travellers-should-know).
2. Необоснованные утверждения. Модель генерирует беспочвенные утверждения, что особенно опасно в чувствительных контекстах, таких как здравоохранение или судебные разбирательства. Например, ChatGPT выдумал несуществующие судебные дела, что повлекло серьёзные проблемы в суде (ссылка: LegalDive, https://www.legaldive.com/news/chatgpt-fake-legal-cases-generative-ai-hallucinations/651557/).
3. Искажение уровня компетентности. Модель создаёт иллюзию понимания сложных тем, вводя пользователей в заблуждение относительно уровня своей экспертизы. Например, было установлено, что чат-боты искажают сложность вопросов, связанных со здоровьем, указывая на неопределённость там, где её нет, из-за чего пользователи ошибочно полагали, что необоснованные методы лечения всё ещё являются предметом обсуждения (ссылка: KFF, https://www.kff.org/health-misinformation-monitor/volume-05/).
4. Генерация небезопасного кода. Модель предлагает небезопасные или несуществующие библиотеки кода, которые при интеграции в программные системы могут привносить уязвимости. Например, LLM предлагают использовать небезопасные сторонние библиотеки, и если доверять этому без проверки, возникают риски безопасности (ссылка: Lasso, https://www.lasso.security/blog/ai-package-hallucinations).

Меры предотвращения и смягчения

1. Генерация с дополненной выборкой (RAG). Используйте RAG, чтобы повысить надёжность вывода модели за счёт извлечения релевантной и проверенной информации из доверенных внешних баз данных при генерации ответа. Это помогает снизить риск галлюцинаций и дезинформации.
2. Дообучение модели (fine-tuning). Улучшайте модель с помощью дообучения или эмбеддингов, чтобы повысить качество вывода. Снизить частоту дезинформации помогают такие методы, как параметрически эффективное дообучение (parameter-efficient tuning, PET) и промптинг с цепочкой рассуждений (chain-of-thought).
3. Перекрёстная проверка и контроль со стороны человека. Побуждайте пользователей сверять вывод LLM с доверенными внешними источниками для подтверждения точности информации. Внедрите контроль со стороны человека и процессы проверки фактов, особенно для критически важной или чувствительной информации. Убедитесь, что проверяющие должным образом обучены и не проявляют чрезмерного доверия к контенту, созданному ИИ.
4. Механизмы автоматической проверки. Внедрите инструменты и процессы для автоматической проверки ключевых результатов, особенно в средах с высокой ценой ошибки.
5. Информирование о рисках. Определите риски и возможный вред, связанные с контентом, созданным LLM, и чётко доводите эти риски и ограничения до пользователей, включая возможность дезинформации.
6. Практики безопасной разработки. Установите практики безопасной разработки, чтобы предотвратить появление уязвимостей из-за некорректных предложений кода.
7. Проектирование пользовательского интерфейса. Проектируйте API и пользовательские интерфейсы, поощряющие ответственное использование LLM: встраивайте фильтры контента, чётко маркируйте контент, созданный ИИ, и информируйте пользователей об ограничениях надёжности и точности. Конкретно указывайте ограничения предполагаемой области применения.
8. Обучение и повышение осведомлённости. Проводите для пользователей всестороннее обучение по ограничениям LLM, важности независимой проверки сгенерированного контента и необходимости критического мышления. В отдельных контекстах проводите отраслевое обучение, чтобы пользователи могли эффективно оценивать вывод LLM в своей профессиональной области.

Примеры сценариев атак

1. Сценарий №1. Злоумышленники экспериментируют с популярными ассистентами для программирования, чтобы найти часто галлюцинируемые названия пакетов. Определив такие часто предлагаемые, но несуществующие библиотеки, они публикуют в широко используемых репозиториях вредоносные пакеты с этими названиями. Разработчики, полагаясь на подсказки ассистента, неосознанно интегрируют эти отравленные пакеты в своё ПО. В результате злоумышленники получают несанкционированный доступ, внедряют вредоносный код или создают бэкдоры, что приводит к серьёзным нарушениям безопасности и компрометации пользовательских данных.
2. Сценарий №2. Компания предоставляет чат-бот для медицинской диагностики, не обеспечив достаточной точности. Чат-бот выдаёт некачественную информацию, что приводит к вредным последствиям для пациентов. В результате иск к компании о возмещении ущерба удовлетворяется. В этом случае сбой безопасности не потребовал участия злоумышленника, а возник из-за недостаточного контроля и низкой надёжности системы LLM. В этом сценарии для возникновения у компании риска репутационного и финансового ущерба активный атакующий не нужен.

Связанные фреймворки и таксономии

• AML.T0048.002 - Societal Harm — MITRE ATLAS (https://atlas.mitre.org/techniques/AML.T0048)