Архитектурная уязвимость – как создаются и как «думают» нейросети?

Картина мира у нейросетей проявляется в весах и параметрах. Вес – это число с плавающей запятой, которое показывает силу связей в графе, а параметр – это одна ячейка памяти с числом.

Если модель имеет 70 млрд параметров, где каждый параметр занимает 2 байта памяти, соответственно, вес модели – около 140 гигабайт.

Картина мира - это совокупность весов (состояние модели), а архитектура - это алгоритм, который позволяет входным данным взаимодействовать с этими весами для получения результата.

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

Модель заранее выучила, что вектор «смартфон» должен быть математически близок к вектору «телефон» и далек от вектора «банан».

Теперь вектор слова «смартфон» начинает путешествие через слои нейросети (через 32 или 96 слоев). На каждом слое происходит два главных процесса, где перемножаются веса. Вектор «смартфон» взаимодействует с вектором «наилучшие характеристики», поглощая в себя информацию с вектором, имеющим наибольшую вероятность.

Теперь этот обогащенный вектор идет в блок «памяти». Здесь происходит умножение матрицы на вектор. Каждая колонка матрицы – это детектор какого-то признака.

При умножении на веса активизируются те нейроны, которые связаны с флагманскими моделями в соответствии с запросами.

Теперь «обогащенный» вектор передает в последнюю матрицу (Unembedding Matrix), где в соответствии с конфигурацией «обогащенного» вектора выстраивается иерархия приоритетов для генерации токенов выходного ответа.

В чем уязвимость?

🔘Веса статичны и никогда не меняются до момента нового цикла предварительного обучения.

🔘Любая попытка дообучения ломает всю архитектуру модели – система в принципе не обучаемая на уровне архитектуры. Вместо накопления знаний, как у биологических организмов, происходит интерференция и замещение.

🔘В нейросети знания хранятся в распределенном виде. Факт «Париж — столица Франции» не записан в одном конкретном нейроне. Он «размазан» тонким слоем по миллионам параметров. В модель нельзя ни добавить, ни изъять точечные знания в отличия от обычной СУБД на SQL.

🔘Чудовищная неэффективность. На вопрос «2*2=?», чтобы сгенерировать всего один токен, вычислительное ядро должно активизировать все параметры в системе, включая квантовую физику, теорию струн и историю Древнего Рима и так каждый раз, создавая несоизмеримую нагрузку все на все вычислительные блоки. Сейчас решается через MoE (смесь экспертов).

🔘Отсутствие долгосрочной памяти и накопления опыта. Биологический мозг обладает синаптической пластичностью: связи меняются прямо в момент мыслительного процесса, у LLM долговременная память отсутствует и никакого накопления опыта не может быть на уровне архитектуры. Каждый раз с чистого листа.

🔘Проклятие размерности. Когда модель интерполирует (строит векторный путь) от понятия А к понятию Б, этот путь может случайно пролечь через эту «пустоту», где нет обучающих примеров в пространстве 4096 измерений. В этой пустоте поведение модели математически не определено, создавая неизбежные галлюцинации.

🔘Ошибки обучения – программирование связей между десятками миллиардов параметров практически всегда приводят к ошибкам интерпретации.

🔘Накопление ошибки точности. Сигнал проходит через десятки и сотни слоев. На каждом слое происходит умножение матриц. Микроскопическая ошибка округления (шум) на 1-м слое, умноженная на веса, может усилиться к 50-му слою и полностью исказить смысл вектора к конечному слою.

🔘Несовершенство алгоритмом компрессии информации. Десятки и сотни триллионов токенов сжимаются в десятки миллиардов параметров с компрессией 1:1000 и более. Уникальные факты, случайные числа, конкретные даты, цитаты, адреса. Это шум с точки зрения статистики, что приводит к несовершенству интерпретации.

Текущая архитектура LLM крайне уязвима, ресурснозатратна и неэффективна.

IBM ARES: Открытый фреймворк для Red Teaming AI-систем
#IBM #red_team #pentest

TLDR: IBM выпустила ARES (AI Robustness Evaluation System) — открытый фреймворк для автоматизированного тестирования на проникновение AI-систем. Он позволяет систематически проверять модели на уязвимости к jailbreaking, извлечению данных и генерации вредоносного контента, предоставляя разработчикам инструмент для выявления и устранения проблем до их эксплуатации.

➡️Цель фреймворка
Основная цель ARES — демократизировать и стандартизировать процесс Red Teaming для AI-систем. В условиях, когда регуляторы (Белый дом, EU AI Act, NIST) требуют обязательного тестирования на проникновение для AI, ARES предоставляет практический инструментарий для выполнения этих требований. Фреймворк позволяет перейти от ручного, интуитивного поиска уязвимостей к систематическому, автоматизированному и воспроизводимому процессу.

➡️Преимущества
Систематический подход: ARES структурирует Red Teaming вокруг трех ключевых компонентов: целей (что вы пытаетесь заставить AI сделать?), стратегий (как вы создаете атаки?) и оценки (удалась ли атака?).
Интеграция с OWASP Top 10 для LLM: Фреймворк позволяет тестировать системы на соответствие известным шаблонам уязвимостей, а не изобретать атаки с нуля.
Тестирование всей инфраструктуры: ARES предназначен не только для тестирования «голых» моделей, но и для оценки всей системы в комплексе: локальных развертываний с защитными механизмами (guardrails), облачных моделей (например, через WatsonX.ai) и развернутых агентов (через AgentLab). Это критически важно, поскольку уязвимости часто возникают на стыке компонентов, а не в самой модели.
Открытость и расширяемость: Будучи open-source проектом, ARES позволяет сообществу вносить свой вклад, добавлять новые типы атак, метрики оценки и интеграции.

➡️Архитектура
ARES построен на модульной архитектуре, которая обеспечивает гибкость и расширяемость. Ключевые компоненты:

Plugin Catalog: Ядро фреймворка, которое позволяет подключать различные модули:
Target Connectors: для взаимодействия с различными AI-моделями и системами.
Custom Attack Goals: для определения специфических целей атак (например, извлечение PII).
Attack Strategies: для реализации различных техник атак (GCG, PyRIT, Garak и др.).
Robustness Evaluations: для оценки успешности атак.
Orchestrator: Центральный компонент, который управляет процессом тестирования: загружает конфигурацию, выбирает цель, устанавливает цели, запускает стратегии атак, оценивает результаты и генерирует отчет.
Evaluator: Модуль оценки, который использует как автоматизированные методы (например, сопоставление по ключевым словам), так и LLM-as-a-judge для определения, была ли атака успешной.

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

🔗Источник

🌚 @poxek_ai