Трансформеры с бесконечным контекстом. Часть 1. Смысл слов, контекст
Обзор статьи Leave No Context Behind: Efficient Infinite Context Transformers with Infini-attention
#ai #ml_в_иб #иб_в_ml
Часть 2
Часть 3
Давненько я обещал написать разбор статьи про бесконечное контекстное окно LLM от Google, да все никак руки не доходили.
Но вот мы здесь, и сейчас немного углубимся в то, как все устроено у трансформеров под капотом, что предлагают нового авторы, а еще - на какие задачи применительно к ИБ повлияет данное новшество и, потенциально, какие у него будут уязвимости с точки зрения атак на модели.
Внимание и контекст
Как работает с точки зрения математики способность LLM'ок (на основе трансформеров) смотреть в завтрашний день в контекст и использовать информацию из него?
1. Сначала про то, как языковые модели смотрят на текст. Вспомним, что первым делом текста превращаются моделями в токены. Это условные числа, которые по определенному словарю сопоставляются словам или частям слов. Например, есть алгоритм WordPiece. Его особенность в том, что если в какой-то момент токенизатор встретил в тексте новое слово (пусть будет playing), он, прежде чем добавлять его в словарь как новое, разделит его на части и проверит их наличие - play и ##ing, и далее соотнесет слову в тексте токены этих двух частей. Есть еще также Byte-Pair Encoding на основе популярных пар слов, TikToken и прочие. В итоге вместо входного текста имеем набор чисел - [200, 15, 3845, 99, ...]. Отличный ликбез по ним есть в nlp-course на hf.
2. Далее из токенов получаются эмбеддинги. Как - тема отдельного поста, вот например объяснение их сути. Нам сейчас важно знать, что они являются векторами в каком-то многомерном пространстве, расположенные так, что близкие по смыслу токены (читай - слова) близки и как вектора, и наоборот. В чем их проблема? Не учитывается то, в каком контексте они применяются, а ведь это сильно влияет на смысл слов (читай - токены).
3. И здесь появляется внимание - механизм преобразования эмбеддингов слов под влиянием оных от соседних слов. Что значит соседних? Для каждого слова в поданном тексте вычисляется, насколько оно близко и важно каждому, это называется self-attention. А просто attention - это когда вычисляется важность слов на входе для слов из генерируемого ответа.
4. Размер контекстного окна обусловлен размерностью определенной матрицы в слое внимания. Какой, обсудим ниже. Чем оно больше, тем больше нужно вычислений проводить при каждом входном запросе. А когда история сообщений уже очень длинная, или документ длинный - трансформер будет помнить только что-то из конца.
Математика внимания в следующем посте)
Обзор статьи Leave No Context Behind: Efficient Infinite Context Transformers with Infini-attention
#ai #ml_в_иб #иб_в_ml
Часть 2
Часть 3
Давненько я обещал написать разбор статьи про бесконечное контекстное окно LLM от Google, да все никак руки не доходили.
Но вот мы здесь, и сейчас немного углубимся в то, как все устроено у трансформеров под капотом, что предлагают нового авторы, а еще - на какие задачи применительно к ИБ повлияет данное новшество и, потенциально, какие у него будут уязвимости с точки зрения атак на модели.
Внимание и контекст
Как работает с точки зрения математики способность LLM'ок (на основе трансформеров) смотреть в завтрашний день в контекст и использовать информацию из него?
1. Сначала про то, как языковые модели смотрят на текст. Вспомним, что первым делом текста превращаются моделями в токены. Это условные числа, которые по определенному словарю сопоставляются словам или частям слов. Например, есть алгоритм WordPiece. Его особенность в том, что если в какой-то момент токенизатор встретил в тексте новое слово (пусть будет playing), он, прежде чем добавлять его в словарь как новое, разделит его на части и проверит их наличие - play и ##ing, и далее соотнесет слову в тексте токены этих двух частей. Есть еще также Byte-Pair Encoding на основе популярных пар слов, TikToken и прочие. В итоге вместо входного текста имеем набор чисел - [200, 15, 3845, 99, ...]. Отличный ликбез по ним есть в nlp-course на hf.
2. Далее из токенов получаются эмбеддинги. Как - тема отдельного поста, вот например объяснение их сути. Нам сейчас важно знать, что они являются векторами в каком-то многомерном пространстве, расположенные так, что близкие по смыслу токены (читай - слова) близки и как вектора, и наоборот. В чем их проблема? Не учитывается то, в каком контексте они применяются, а ведь это сильно влияет на смысл слов (читай - токены).
3. И здесь появляется внимание - механизм преобразования эмбеддингов слов под влиянием оных от соседних слов. Что значит соседних? Для каждого слова в поданном тексте вычисляется, насколько оно близко и важно каждому, это называется self-attention. А просто attention - это когда вычисляется важность слов на входе для слов из генерируемого ответа.
4. Размер контекстного окна обусловлен размерностью определенной матрицы в слое внимания. Какой, обсудим ниже. Чем оно больше, тем больше нужно вычислений проводить при каждом входном запросе. А когда история сообщений уже очень длинная, или документ длинный - трансформер будет помнить только что-то из конца.
Математика внимания в следующем посте)
🔥4👍1
Трансформеры с бесконечным контекстом. Часть 2. Математика внимания
Обзор статьи Leave No Context Behind: Efficient Infinite Context Transformers with Infini-attention
#ai #ml_в_иб #иб_в_ml
Часть 1
Часть 3
Тут будет введение в то, на чем основана одна из самых важных частей современных LLM - механизм внимания (в его базовой форме). Если все известно уже и так, или не очень интересно погружаться в математику - идем в часть 3).
5. Итак, математика внимания (а именно - QKV-внимания). Рассмотрим вектор(деление на корень из длины контекста и потом softmax в случае с scaled-dot attention, например) , которая в итоге делает все веса вектора
6. Важно понимать, что все операции на самом деле вычисляются в матричной форме и параллельно. Вот есть набор входных эмбеддингов токенов (векторизованная история всей беседы). Это
7. Кстати, если быть точным, то итоговая размерность
Очень рекомендую лекции Татьяны Гайнцевой (Лекция про энкодер-декодер (лекция про энкодер-декодер, лекция про внимание, лекция 1 про трансформеры, лекция 2 про трансформеры и qkv attention), отлично объяснение математики выше с историей и картинками.
Обзор статьи Leave No Context Behind: Efficient Infinite Context Transformers with Infini-attention
#ai #ml_в_иб #иб_в_ml
Часть 1
Часть 3
Тут будет введение в то, на чем основана одна из самых важных частей современных LLM - механизм внимания (в его базовой форме). Если все известно уже и так, или не очень интересно погружаться в математику - идем в часть 3).
5. Итак, математика внимания (а именно - QKV-внимания). Рассмотрим вектор
Y - эмбеддинг какого-то токена из текста. Нам надо посчитать важность остальных токенов для него, и делается это для каждого из них (X_i) отдельно. Введем матрицы WQ, WK и WV. Это по сути обычные веса в нейросети, только вместо одного числа - весового коэффициента, целая "весовая" матрица. В процессе обучения эти матрицы, как и любые другие веса, обучаются и меняются. WQ - это query, матрица запроса, которая как бы фильтрует из исходного токена только то, что пригодится для формирования веса токена X_i для Y. Y*WQ и получается вектор Q. Его транспонируют, и умножают на вектор K=X_i*WK (K - key), чтобы получить скалярное число - вес i-го токена w_i. Перемножение с WK по факту означает "вот я, вектор X_i, и у меня есть столько-то хорошей инфы". Вот мы теперь имеем для каждого токена X_i число веса w_i, но оно может быть любым вещественным числом, что затрудняет задачу. Надо, чтобы оно сравнимо с другими. И чтобы нормализовать вектор весов, применяют некую функцию нормализации w для Y распределенными от 0 до 1 и в сумме дающими 1. А что же матрица V? Мы умножаем для каждого токена i-го его изначальный эмбеддинг на матрицу V, и получаем вектор w_v со смыслом "вот я, вектор X_i, и вот моя инфа, которую я отдам для обновления Y" , а потом весь вектор на число его веса w_i. Итого, у нас есть вектор внимания (или, как его называют еще вектор контекста) a=w*X*WV=w*V для токена Y, и они объединяются, а именно - например поэлементно суммируются. А потом еще раз нормализуются. последние два действия, кстати, суть слоя Add&Norm из классической архитектуры трансформера. 6. Важно понимать, что все операции на самом деле вычисляются в матричной форме и параллельно. Вот есть набор входных эмбеддингов токенов (векторизованная история всей беседы). Это
X. И на самом деле Q=X*WQ, K=X*WK и V=X*WV. Вот эти три матрицы Q, K, V, уникальные для каждой новой итерации беседы, и характеризуют ее в каждый новый момент времени. А точнее, нам важны именно K и V, в которых записано, к какой информации контекста надо обращаться и непосредственна эта информация. Q не берется, так как ситуативен и просто описывает запрос пользователя. Произведение K^T (транспонированное) и V по сути и есть состояние беседы, запись в кэше. В стандартном механизме внимания они каждый раз отбрасываются и пересчитываются. Но в компрессионных... Об этом я расскажу ниже, в третьем посте.7. Кстати, если быть точным, то итоговая размерность
X складывается из размера эмбеддингов, длины контекста, количества голов внимания, и размера батча. И расчеты там все же чуууточку сложнее... Но это уже техника, для сути дела сейчас не важно.Очень рекомендую лекции Татьяны Гайнцевой (Лекция про энкодер-декодер (лекция про энкодер-декодер, лекция про внимание, лекция 1 про трансформеры, лекция 2 про трансформеры и qkv attention), отлично объяснение математики выше с историей и картинками.
❤2👍2
Трансформеры с бесконечным контекстом. Часть 3. Секрет бесконечности и безопасность.
Обзор статьи Leave No Context Behind: Efficient Infinite Context Transformers with Infini-attention
#ai #ml_в_иб #иб_в_ml
Часть 1
Часть 2
Наконец-то мы можем перейти непосредственно к идее статьи.
8. Теория такая - вектор внимания
9. На бенчмарках по языковому моделированию с длинным контекстом (PG-19, arXiv-math) авторы берут трансформер с 12 слоями и hidden_dim =1024, и по перплексии метод заметно опережает конкурентные подходы (Transformer-XL, Memorizing Transformers), при этом используя для памяти модели в 114 раз меньшее количество параметров.
10. Далее был бенчмарк по извлечению единичных фактов из текста (passkey retrieval). Они взяли некую LLM с контекстным окном 5к (то есть размером входного слоя), заменили в ней стандартное внимание на Infini-attention, и прогнали на текстах вплоть до 1M токенов. И она с какой-то ненулевой точностью справилась, при чем результаты перестали сильно отличаться после длины текста в 256к токенов.
11. На следующем бенчмарке по пересказу книг BookSum Infini-transformer тоже неплох - бьет модели BART и Primera, и обе с опцией Unlimiformer, достигая SOTA-уровня по данной задаче.
‼️ И самое интересное. Я нашел неофициальные реализации этого алгоритма: раз и два, и три. И есть модель, основанная на данном методе и доступная для скачивания. Это Gemma 2B с итоговым окном контекста в 10M токенов!
Безопасность
1. Как это можно использовать в безопасности? Для RAG-систем, конечно же, на которых сейчас создаются SOC-ассистенты по threat intelligence и реагированию (как этот). Отчеты большие, и даже в контекстное окно в 32к не влезает больше одного-двух. Технологии, как эта, точно нужны для будущих систем подобного класса. Еще одна жадная до контекста ИБ задача - анализ логов событий с помощью LLM. Да-да, и такое есть (полезный гит на эту тему) (а вот аналогичный проект, но с кодом).
2. Безопасно ли такое использовать? Определенно можно сказать, что увеличение контекстного окна выгодно атакам промпт-инъекций, так как обнаружить и забороть атаки по типу распределенных инструкций будет намного сложнее. Они будут давать эффект, что показывает ненулевое качество теста passkey retrieval - только вместо безобидных "иголок в стоге сена" злоумышленики будут вкладывать в модель инструкции рекомендовать вредоносные ссылки, или не отвечать ни на какие промпты, и так далее.
3. Поживем - увидим, конечно. В оригинальной статье, напомню, я описывал, как на основе некоторых других своих разработок исследователи из Google задумали создать систему глобального распределенного обучения моделей, что даст просто ей просто гигантские количественные показатели. А вкупе с таким компрессионным вниманием ее возможности и представить сложно. Я не сомневаюсь, что подобная история кардинально изменит ИБ, как с точки зрения инструментов его обеспечения, так и с точки зрения целей и объектов защиты
Спасибо, что остались до конца этого длиннотекста. Вы бы знали, сколько я его готовил, завершал и переписывал заново... Но все-таки закончил)
Обзор статьи Leave No Context Behind: Efficient Infinite Context Transformers with Infini-attention
#ai #ml_в_иб #иб_в_ml
Часть 1
Часть 2
Наконец-то мы можем перейти непосредственно к идее статьи.
8. Теория такая - вектор внимания
A рассчитывается теперь так: A=k*A_mem+(1-k)*A_dot, где A_dot - это стандартный вектор внимания по контексту модели (тот что выше объяснен), а A_mem - вектор внимания по всей истории (все это для i-го эмбеддинга). Вся соль в A_mem - он получается в результате накопления так называемых состояний памяти - матриц, получаемых в результате K^T*V (почему именно такие матрицы - см. часть 2) и всяких там нормализаций. Накопление производится хитрым суммированием, и называется Linear+Delta rule. Вдобавок, из-за постоянной нормализации состояние памяти меняется плавно. 9. На бенчмарках по языковому моделированию с длинным контекстом (PG-19, arXiv-math) авторы берут трансформер с 12 слоями и hidden_dim =1024, и по перплексии метод заметно опережает конкурентные подходы (Transformer-XL, Memorizing Transformers), при этом используя для памяти модели в 114 раз меньшее количество параметров.
10. Далее был бенчмарк по извлечению единичных фактов из текста (passkey retrieval). Они взяли некую LLM с контекстным окном 5к (то есть размером входного слоя), заменили в ней стандартное внимание на Infini-attention, и прогнали на текстах вплоть до 1M токенов. И она с какой-то ненулевой точностью справилась, при чем результаты перестали сильно отличаться после длины текста в 256к токенов.
11. На следующем бенчмарке по пересказу книг BookSum Infini-transformer тоже неплох - бьет модели BART и Primera, и обе с опцией Unlimiformer, достигая SOTA-уровня по данной задаче.
Безопасность
1. Как это можно использовать в безопасности? Для RAG-систем, конечно же, на которых сейчас создаются SOC-ассистенты по threat intelligence и реагированию (как этот). Отчеты большие, и даже в контекстное окно в 32к не влезает больше одного-двух. Технологии, как эта, точно нужны для будущих систем подобного класса. Еще одна жадная до контекста ИБ задача - анализ логов событий с помощью LLM. Да-да, и такое есть (полезный гит на эту тему) (а вот аналогичный проект, но с кодом).
2. Безопасно ли такое использовать? Определенно можно сказать, что увеличение контекстного окна выгодно атакам промпт-инъекций, так как обнаружить и забороть атаки по типу распределенных инструкций будет намного сложнее. Они будут давать эффект, что показывает ненулевое качество теста passkey retrieval - только вместо безобидных "иголок в стоге сена" злоумышленики будут вкладывать в модель инструкции рекомендовать вредоносные ссылки, или не отвечать ни на какие промпты, и так далее.
3. Поживем - увидим, конечно. В оригинальной статье, напомню, я описывал, как на основе некоторых других своих разработок исследователи из Google задумали создать систему глобального распределенного обучения моделей, что даст просто ей просто гигантские количественные показатели. А вкупе с таким компрессионным вниманием ее возможности и представить сложно. Я не сомневаюсь, что подобная история кардинально изменит ИБ, как с точки зрения инструментов его обеспечения, так и с точки зрения целей и объектов защиты
Спасибо, что остались до конца этого длиннотекста. Вы бы знали, сколько я его готовил, завершал и переписывал заново... Но все-таки закончил)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🔥4
Статья от Anthropic про защиту LLM от джейлбрейков
#иб_для_ml
Исследователи из MATS, Anthropic и NYU 12 ноября представили всесторонний обзор техник защиты LLM от инъекций.
На канале "llm security и каланы" есть интересный подробный разбор статьи, приходите смотреть (ниже будут ссылки).
Я же при прочтении статьи отметил ее пользу с точки зрения практики. С моей точки зрения, она отражается в четырех положениях:
1. Есть польза для automated llm red teaming. Авторы описывают метод генерации дополнительных текстов промпт-атак jailbreak proliferation (с помощью которого дообучались методы защиты). Попробовали модели Llama 3.1. 8B, Gemma 2 9B, Gemma 2 27B, Llama 3.1. 70B, Llama 3.1. 405B. Между 70B и 405B по графику почти не заметно разницы, и лучшей была признана 70B-версия. Однако и 8B модель неплохо справилась, поэтому в практических целях, я думаю, можно использовать и ее.
Целевыми моделями в исследовании были GPT-4o, и маленькие Llama-3-8B и Mistral-7B.
2. Описывается метод защиты LLM, признанный самым эффективным - на основе специальной языковой модели, оценивающей вход (guard fine-tune). В результате эта техника смогла снизить ASR испытанных атак на 0.4% для стратегий, которые были в дообучении модели-защитник, и до 6.4% для атак по тактикам, которых защитник никогда не видел. Авторы отмечают, что guard fine-tune - единственная техника, которая увеличивает свое качество по мере увеличения объема обучающей выборки input guard с proliferated джейлбрейками.
3. Методологическая польза. Авторы используют и поясняют ключевые определения понятий. Например, сильнейшая защита определяется как та, чья эффективность увеличивается больше всего по мере расширения выборки вредоносных промптов, на которой защита основана.
4. Авторы также упоминают, что используют мониторинг промптов, но, к сожалению, не раскрывают детали его реализации. Насколько понятно из статьи, выделенные с помощью мониторинга новые атаки предлагается размножать с помощью Llama 70B, и подавать в новый fine-tune input guard модели (и в этом и выведенный в заголовок метод Rapid Response). Но, к сожалению, не уточняется архитектура этой модели, только фраза "LM-based input classifier".
➡️ Ссылка на статью
➡️ Ссылка на репозиторий
Обзор "llm security и каланы":
1. Введение и проблематика
2. Виды проведенных атак и испытанных способов детекциии
3. Использованные модели, результаты и выводы
#иб_для_ml
Исследователи из MATS, Anthropic и NYU 12 ноября представили всесторонний обзор техник защиты LLM от инъекций.
На канале "llm security и каланы" есть интересный подробный разбор статьи, приходите смотреть (ниже будут ссылки).
Я же при прочтении статьи отметил ее пользу с точки зрения практики. С моей точки зрения, она отражается в четырех положениях:
1. Есть польза для automated llm red teaming. Авторы описывают метод генерации дополнительных текстов промпт-атак jailbreak proliferation (с помощью которого дообучались методы защиты). Попробовали модели Llama 3.1. 8B, Gemma 2 9B, Gemma 2 27B, Llama 3.1. 70B, Llama 3.1. 405B. Между 70B и 405B по графику почти не заметно разницы, и лучшей была признана 70B-версия. Однако и 8B модель неплохо справилась, поэтому в практических целях, я думаю, можно использовать и ее.
Целевыми моделями в исследовании были GPT-4o, и маленькие Llama-3-8B и Mistral-7B.
2. Описывается метод защиты LLM, признанный самым эффективным - на основе специальной языковой модели, оценивающей вход (guard fine-tune). В результате эта техника смогла снизить ASR испытанных атак на 0.4% для стратегий, которые были в дообучении модели-защитник, и до 6.4% для атак по тактикам, которых защитник никогда не видел. Авторы отмечают, что guard fine-tune - единственная техника, которая увеличивает свое качество по мере увеличения объема обучающей выборки input guard с proliferated джейлбрейками.
3. Методологическая польза. Авторы используют и поясняют ключевые определения понятий. Например, сильнейшая защита определяется как та, чья эффективность увеличивается больше всего по мере расширения выборки вредоносных промптов, на которой защита основана.
4. Авторы также упоминают, что используют мониторинг промптов, но, к сожалению, не раскрывают детали его реализации. Насколько понятно из статьи, выделенные с помощью мониторинга новые атаки предлагается размножать с помощью Llama 70B, и подавать в новый fine-tune input guard модели (и в этом и выведенный в заголовок метод Rapid Response). Но, к сожалению, не уточняется архитектура этой модели, только фраза "LM-based input classifier".
Обзор "llm security и каланы":
1. Введение и проблематика
2. Виды проведенных атак и испытанных способов детекциии
3. Использованные модели, результаты и выводы
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4🔥1
Forwarded from Слономойка Вестник
Добрый день, друзья!
Кто такие специалисты MLSec?
Профессия - специалист по безопасности машинного обучения. Это активно развивающееся направление появилось на стыке информационной безопасности и ML как ответ на возросшее количество угроз, связанных с применением интеллектуальных систем - использующих нейронные сетей и другие модели машинного обучения.
Безопасность машинного обучения, как и ИБ, оперирует понятием доверия. Но традиционные методы оценки доверенности зачастую малоэффективны по отношению к интеллектуальным системам, поскольку в них первое место по значимости занимают уже данные, а не код. Вот тут на сцену и выходит MLSec - чтобы предоставить новые подходы, применимые к современным интеллектуальным системам.
Илья Запорожец является тем самым специалистом MLSec.
Познакомиться и пообщаться можно будет 24 ноября в музее криптографии
Мероприятие бесплатно 😉
Кто такие специалисты MLSec?
Профессия - специалист по безопасности машинного обучения. Это активно развивающееся направление появилось на стыке информационной безопасности и ML как ответ на возросшее количество угроз, связанных с применением интеллектуальных систем - использующих нейронные сетей и другие модели машинного обучения.
Безопасность машинного обучения, как и ИБ, оперирует понятием доверия. Но традиционные методы оценки доверенности зачастую малоэффективны по отношению к интеллектуальным системам, поскольку в них первое место по значимости занимают уже данные, а не код. Вот тут на сцену и выходит MLSec - чтобы предоставить новые подходы, применимые к современным интеллектуальным системам.
Илья Запорожец является тем самым специалистом MLSec.
Познакомиться и пообщаться можно будет 24 ноября в музее криптографии
Мероприятие бесплатно 😉
🔥5👍1
Руководство по AI Red Teaming
Вчера от Артема вышла публикация о появлении системы оценки уязвимостей ИИ - AIVSS. Заинтересовавшись автором, я узнал, что его зовут Ken Huang, и он является CEO некого стартапа DistributedApps.ai, а также VP of Research в Cloud Security Alliance Great China Region (CSA GCR), органе, судя по всему, занимающимся защитой ИИ на гос. уровне в Китае.
И помимо многих книг, выпущенных этим исследователем, за его авторством значится и любопытный документ "RFI for NIST AI Executive: ref Order-88 FR 88368" - комментарии к информационному письму NIST по безопасности ИИ. Документ обширный (24 страницы), и имеет следующее оглавление:
1: Introduction
2: Recommendation for AI Roles and Responsibilities
3: Evaluating RAG Based LLM Applications
4: Comments on Red-Teaming
5: Comments on Reducing the Risk of Synthetic Content
6: Comments on Advance Responsible Global Technical Standards for AI Development
7: Contracting to the DistributedApps.ai and HORUSTeam
Особенно интересен раздел 4, про red teaming (RT), конечно. Описываются сценарии применения RT, ограничения этой деятельности, лучшие практики, распределение по ЖЦ моделей, краткое руководство к проведению RT, рекомендации по ведению информационной политики, экономическое обоснование для разных типов организаций и целеполагание RT в зависимости от типа организации и мл-моделей у нее. Останавливаться на всем не буду, затрону только один пункт, но к прочтению рекомендую. Правда, там иногда встречаются отсылки на повестку типа расового разнообразия в коллективе, но без этого у западных коллег, видимо, никуда.
Распределение деятельности Red Team по этапам жизненного цикла моделей
1. Стадия проектирования
Теоретическая оценка уязвимостей архитектур различных мл-моделей, подбираемых под решение прикладной задачи. Исследование датасетов, собираемых для обучения моделей, на соответствие требованиям безопасности.
2. Стадия разработки
По мере создания основных компонентов AI-системы, в изолированных средах можно проводить более тщательное тестирование, делать whitebox-атаки. Цель состоит в том, чтобы обнаружить недостатки моделей и данных на ранней стадии, являющиеся, обычно, самыми критичными.
3. Стадия тестирования (pre-deployment)
Здесь RT нужно проводить уже blackbox-исследования, приближенные к реальным условиям. Рекомендуется использовать расцензуренные LLM-оценщики оценки небезопасных генераций целевой модели.
4. Стадия эксплуатации (post-deployment)
Красной команде на данном этапе следует продолжить периодическое тестирование моделей в проде на новые появляющиеся атаки в blackbox-режиме, но при этом уделять время и мониторингу реального трафика, для поиска злонамеренного использования модели и реагирования на подобный инциденты.
Примечание
В самом исполнительном распоряжении, к которому Ken Huang и Mehdi Bousaidi дают комментарии, есть в числе прочего и определение AI Red Team. Вот перевод с небольшими купюрами (убрал воду):
Вчера от Артема вышла публикация о появлении системы оценки уязвимостей ИИ - AIVSS. Заинтересовавшись автором, я узнал, что его зовут Ken Huang, и он является CEO некого стартапа DistributedApps.ai, а также VP of Research в Cloud Security Alliance Great China Region (CSA GCR), органе, судя по всему, занимающимся защитой ИИ на гос. уровне в Китае.
И помимо многих книг, выпущенных этим исследователем, за его авторством значится и любопытный документ "RFI for NIST AI Executive: ref Order-88 FR 88368" - комментарии к информационному письму NIST по безопасности ИИ. Документ обширный (24 страницы), и имеет следующее оглавление:
1: Introduction
2: Recommendation for AI Roles and Responsibilities
3: Evaluating RAG Based LLM Applications
4: Comments on Red-Teaming
5: Comments on Reducing the Risk of Synthetic Content
6: Comments on Advance Responsible Global Technical Standards for AI Development
7: Contracting to the DistributedApps.ai and HORUSTeam
Особенно интересен раздел 4, про red teaming (RT), конечно. Описываются сценарии применения RT, ограничения этой деятельности, лучшие практики, распределение по ЖЦ моделей, краткое руководство к проведению RT, рекомендации по ведению информационной политики, экономическое обоснование для разных типов организаций и целеполагание RT в зависимости от типа организации и мл-моделей у нее. Останавливаться на всем не буду, затрону только один пункт, но к прочтению рекомендую. Правда, там иногда встречаются отсылки на повестку типа расового разнообразия в коллективе, но без этого у западных коллег, видимо, никуда.
Распределение деятельности Red Team по этапам жизненного цикла моделей
1. Стадия проектирования
Теоретическая оценка уязвимостей архитектур различных мл-моделей, подбираемых под решение прикладной задачи. Исследование датасетов, собираемых для обучения моделей, на соответствие требованиям безопасности.
2. Стадия разработки
По мере создания основных компонентов AI-системы, в изолированных средах можно проводить более тщательное тестирование, делать whitebox-атаки. Цель состоит в том, чтобы обнаружить недостатки моделей и данных на ранней стадии, являющиеся, обычно, самыми критичными.
3. Стадия тестирования (pre-deployment)
Здесь RT нужно проводить уже blackbox-исследования, приближенные к реальным условиям. Рекомендуется использовать расцензуренные LLM-оценщики оценки небезопасных генераций целевой модели.
4. Стадия эксплуатации (post-deployment)
Красной команде на данном этапе следует продолжить периодическое тестирование моделей в проде на новые появляющиеся атаки в blackbox-режиме, но при этом уделять время и мониторингу реального трафика, для поиска злонамеренного использования модели и реагирования на подобный инциденты.
Примечание
В самом исполнительном распоряжении, к которому Ken Huang и Mehdi Bousaidi дают комментарии, есть в числе прочего и определение AI Red Team. Вот перевод с небольшими купюрами (убрал воду):
Термин «AI Red Teaming» описывает процесс структурированного тестирования, который направлен на выявление недостатков и уязвимостей в системе искусственного интеллекта. Это тестирование часто проводится в контролируемой среде и в тесном сотрудничестве с разработчиками ИИ.
Обычно ... [красные] команды ищут такие недостатки, как:
* Вредные или дискриминационные результаты работы системы ИИ;
* Непредсказуемое или нежелательное поведение системы;
* Ограничения и потенциальные риски, связанные с неправильным использованием системы.
❤13👍1🔥1
Всем привет! В воскресенье (8 декабря) в Музее Криптографии пройдет второй из трех подкастов по ML Security, на тему "Безопасность LLM: prompt-атаки и защита от них".
⏳ Время - 12:00-14:00
✉️ Обсудим, что же такое промпт-атаки и джейлбрейки. Почему LLM так уязвимы к вредоносным запросам, как они могут привести к утечкам данных или нежелательному поведению моделей. Узнаем, как защитить системы с помощью дообучения, мониторинга и красных команд, и какие методы помогают предотвратить компрометацию LLM и агентов на его основе.
🎤 Подкаст проведёт Дарья Курнаева, технический писатель, аналитик и исследователь философии науки и техники. Обожает задавать вопросы разработчикам, мыслителям и самой себе. Она ведёт блог с размышлениями об IT и цифровизации.
Спикеры секретные. Но, как всегда, очень интересные)
🔗 Регистрация тут, и без нее нельзя)
Спикеры секретные. Но, как всегда, очень интересные)
🔗 Регистрация тут, и без нее нельзя)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍2🔥1🦄1
В это воскресенье прошла встреча в Музее Криптографии, посвященная безопасности LLM
#иб_для_ml
Спикерами были два Артема: Юрьев, и Семенов aka PWNAI. А ведущая - прекрасная Даша Курнаева тоже со своим каналом. В процессе диалога друг с другом и с аудиторией эксперты затронули разные темы, от актуальности темы до возможных профессий в этой области. Ниже перечислю ключевые тезисы со встречи, которые могут представлять для нас интерес, а также свои мысли, которые у меня появились от услышанного. Перечень отдельных заметок по итогу дискуссии:
— Для уменьшения склонности с галлюцинациям есть два пути - добавлять RAG с точными знаниями, или, как ни странно, больше обучать и дообучать модели.
— Защита (как бы) на основе RAG. Можно использовать косинусный поиск по векторной БД с промпт-атаками в целях мониторинга атак, а потом спрашивать LLM-защитник (является ли этот промпт атакой данного типа [подставляем пример из векторной БД])
— Из аудитории озвучили название интересного решения - ProtectAI (можно найти на гитхабе). У них есть модели и алгоритмы, которые оценивают опасность промпт-запроса, смотрят, есть ли в промптах опасные урлы. Таким образом, в этой задаче релевантны не только сложные трансформеры, но и вопросы эвристики мониторят как инпут, так и аутпут.
— Также из аудитории: сегодня LLM интегрируются во многих критических процессы, и простой такой системы вследствие промпт-атаки может стоить многих сотен миллионов.
— Про специалистов мнения разделились. Эксперт из аудитории подсветил, что нужно строится от фундаментальных проблем алгоритмов и данных, поэтому в ML Security нужны математики и дата саентисты. Артем Юрьев занял позицию, что надо идти от application security. Есть специфика конкретного стэка, но принципиальные подходы схожи. Неизвестный эксперт из зала предложил компромиссный подход. Он отметил, что классификацией и проверкой данных на легитимность будет заниматься 1 человек, безопасностью процесса разработки – 2, проверять код моделей на безопасность будут кто-то 3 (условно аппсек), параллельно инфраструктурные безопасники делают свою работу по железу и ПО – 4, редтим-специалисты проводят мероприятия на эксплуатации – 5. И млсекопс-эксперт вырабатывает весь процесс и всех объединяет. При изложении этот человек сослался на Databricks. Помимо этого, была отмечена важная роль мер поддержки осведомленности сотрудников для информационной безопасности.
— Пример актуальности атак через отравление внешних ссылок (которые могут браузить ии-агенты). Японские сайты начали добавлять на сайты фразу «4 июня Тяньаньмэнь», что привело к блокировке их на территории Китая, так как их файерволл не пропускает сайты с такой тематикой. Что привело к недоступности определенных знаний для китайских потребителей (студентов, в частности)
— Задача обнаружения unbounded consumption лежит шире, чем только в области DevOps. Сложности начинаются, когда необходимо отличить возросший трафик при условном скачке популярности сервиса от реальной DDoS атаки. Если перепутать (false positive), и отключить новые легитимные диалоги, то можно потерять много денег. Решение – кросс-пользовательский анализ всей совокупности запросов и выявление кластеров с высокой степенью схожести между собой и схожести с джейлбрейками.
— На агентов может быть свой аналог DDoS-атаки. Можно заставить агента делать какие-то действия очень много раз, что может иметь самые разные последствия (А. Семенов)
И, конечно, приходите на заключительную в этом году встречу в грядущее воскресенье 15 декабря в том же месте в то же время! Организатор так же Слономойка. Тема - "Препарирование ИИ: как интерпретировать модели и зачем это для безопасности". Регистрируйтесь обязательно)
#иб_для_ml
Спикерами были два Артема: Юрьев, и Семенов aka PWNAI. А ведущая - прекрасная Даша Курнаева тоже со своим каналом. В процессе диалога друг с другом и с аудиторией эксперты затронули разные темы, от актуальности темы до возможных профессий в этой области. Ниже перечислю ключевые тезисы со встречи, которые могут представлять для нас интерес, а также свои мысли, которые у меня появились от услышанного. Перечень отдельных заметок по итогу дискуссии:
— Для уменьшения склонности с галлюцинациям есть два пути - добавлять RAG с точными знаниями, или, как ни странно, больше обучать и дообучать модели.
— Защита (как бы) на основе RAG. Можно использовать косинусный поиск по векторной БД с промпт-атаками в целях мониторинга атак, а потом спрашивать LLM-защитник (является ли этот промпт атакой данного типа [подставляем пример из векторной БД])
— Из аудитории озвучили название интересного решения - ProtectAI (можно найти на гитхабе). У них есть модели и алгоритмы, которые оценивают опасность промпт-запроса, смотрят, есть ли в промптах опасные урлы. Таким образом, в этой задаче релевантны не только сложные трансформеры, но и вопросы эвристики мониторят как инпут, так и аутпут.
— Также из аудитории: сегодня LLM интегрируются во многих критических процессы, и простой такой системы вследствие промпт-атаки может стоить многих сотен миллионов.
— Про специалистов мнения разделились. Эксперт из аудитории подсветил, что нужно строится от фундаментальных проблем алгоритмов и данных, поэтому в ML Security нужны математики и дата саентисты. Артем Юрьев занял позицию, что надо идти от application security. Есть специфика конкретного стэка, но принципиальные подходы схожи. Неизвестный эксперт из зала предложил компромиссный подход. Он отметил, что классификацией и проверкой данных на легитимность будет заниматься 1 человек, безопасностью процесса разработки – 2, проверять код моделей на безопасность будут кто-то 3 (условно аппсек), параллельно инфраструктурные безопасники делают свою работу по железу и ПО – 4, редтим-специалисты проводят мероприятия на эксплуатации – 5. И млсекопс-эксперт вырабатывает весь процесс и всех объединяет. При изложении этот человек сослался на Databricks. Помимо этого, была отмечена важная роль мер поддержки осведомленности сотрудников для информационной безопасности.
— Пример актуальности атак через отравление внешних ссылок (которые могут браузить ии-агенты). Японские сайты начали добавлять на сайты фразу «4 июня Тяньаньмэнь», что привело к блокировке их на территории Китая, так как их файерволл не пропускает сайты с такой тематикой. Что привело к недоступности определенных знаний для китайских потребителей (студентов, в частности)
— Задача обнаружения unbounded consumption лежит шире, чем только в области DevOps. Сложности начинаются, когда необходимо отличить возросший трафик при условном скачке популярности сервиса от реальной DDoS атаки. Если перепутать (false positive), и отключить новые легитимные диалоги, то можно потерять много денег. Решение – кросс-пользовательский анализ всей совокупности запросов и выявление кластеров с высокой степенью схожести между собой и схожести с джейлбрейками.
— На агентов может быть свой аналог DDoS-атаки. Можно заставить агента делать какие-то действия очень много раз, что может иметь самые разные последствия (А. Семенов)
И, конечно, приходите на заключительную в этом году встречу в грядущее воскресенье 15 декабря в том же месте в то же время! Организатор так же Слономойка. Тема - "Препарирование ИИ: как интерпретировать модели и зачем это для безопасности". Регистрируйтесь обязательно)
❤5👍4🔥2
В прошлое воскресенье случилась заключительная встреча в 2024 нашего дискуссионного клуба "Секреты Стаи Слонов" в Музее Криптографии
Тема дискуссии - Препарирование ИИ: как интерпретировать модели и зачем это для безопасности
Спикерский состав в этот раз был большой
🔘 Илья Запорожец, эксперт по интерпретируемости ML
🔘 Тимур Низамов, спецалист по редтимингу LLM, представитель команды Llamator.
🔘 Григорий Маршалко, эксперт по безопасности данных и ML
А ведущая - уже известная вам Дарья Курнаева.
Обсудили множество интересных вещей. Я для себя сделал главный вывод - локальную (post hoc) интерпретацию можно использовать применительно к джейлбрейкам GenAI. Интерпретация будет позволять точечно обнаруживать причины некорректной генерации модели и либо их вычищать прям из весов, либо из обучающей выборки.
А еще меня очень порадовала живая вовлеченность аудитории. Слушатели очень часто становились сами практически спикерами, активно участвуя в развитии мысли обсуждения. Спасибо всем, кто пришел!)
Содержание дискуссии в тезисах:
🔘 Интерпретируемость - это и про сверточные сети, и про языковые модели, и про классические модели, на подобие случайного леса, который итерпретировать достаточно легко.
🔘 Белый ящик (вайтбокс), с точки зрения безопасности - когда все известно про атакуемую систему, наиболее комфортная для нарушителя позиция. Серый ящик - когда мы частично знаем атакуемую систему. Черный ящик (блэкбокс) - когда нарушитель ничего не знает про систему (Г. Маршалко).
🔘 Бывает как вайтбокс интерпретация, так и блэкбокс. Обычно говорят, конечно про первую, особенно когда надо проанализировать знания модели целиком (т. н. глобальная интерпретация). Блэкбокс интерпретация - по факту инструмент кражи модели (И. Запорожец)
🔘 Из аудитории подметили - белый ящик при достижении больших размеров - все равно что черный, с точки зрения доступа к знаниям модели (а не с точки зрения ИБ). Прямо как когда в большой корпорации становится слишком много документации.
🔘 Мнения разделились на тему природы ИИ. Часть аудитории спикеров утверждали, что ИИ - не просто большая база данных, а проводит процесс создания абстракции из получаемой информации. Кто-то - что это просто вероятностный аппарат предсказания следующего слова (токена). Примечание: ситуация прямо как с корпускулярно-волновым дуализмом...
🔘 Был интересный рассказ от Ильи про исследование Apple о супервесах модели. Далее цитата.
Илья даже показывал распечатанные графики)
🔘 Тоже от Ильи о том, что такое полисемантичность
🔘 Злоумышленник может применить методы интерпретации, чтобы понять, как обойти этичное выравнивание модели и ее системный промпт.
Продолжение в комментариях)
Тема дискуссии - Препарирование ИИ: как интерпретировать модели и зачем это для безопасности
Спикерский состав в этот раз был большой
А ведущая - уже известная вам Дарья Курнаева.
Обсудили множество интересных вещей. Я для себя сделал главный вывод - локальную (post hoc) интерпретацию можно использовать применительно к джейлбрейкам GenAI. Интерпретация будет позволять точечно обнаруживать причины некорректной генерации модели и либо их вычищать прям из весов, либо из обучающей выборки.
А еще меня очень порадовала живая вовлеченность аудитории. Слушатели очень часто становились сами практически спикерами, активно участвуя в развитии мысли обсуждения. Спасибо всем, кто пришел!)
Содержание дискуссии в тезисах:
Эппл заострили свое внимание на mlp-слоях и смотрели, насколько отдельные веса или активации сильно влияют при их исключении на качество ответа модели. Другое исследование - майкрософт провели исследование, можно ли улучшить качество модели, при этом ее не дообучая. Они заменяли одни весовые матрицы другими, поменьше, специально аппроксимированными. И внезапно обнаружили, что качество при этом увеличивается. По сути произошло затирание мусорной информации из весов.
Также интересно наблюдать в области концептуальной интерпретируемости. LLM - существо многомерное, и в ней находятся вектора-концепты, проходящие по всем ее слоям. И эти вектора содержат конкретную информацию. И это направление называется representation_engineering. В нем анализируются активации. И в результате мы видим, как в результате цепочка активаций она принимает как раз так вид дерева, просто строящегося динамически под каждый ответ модели.
Илья даже показывал распечатанные графики)
Это большой камень, на который нашла коса интерпретации ЛЛМ. Это когда один и тот же нейрон активируется на запросы совершенно разных тем. Потому что обучающие данные невозможно закодировать в непересекающихся векторах, потому что размер модели относительно размера обучающей выборки все таки многократно меньший.
Продолжение в комментариях)
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍1
Математическое моделирование рисков
#иб
Под конец года наконец-то вышла наша с Максимом Анненковым статья про технический подход к управлению рисками в организации.
В статье Максим писал о прикладных аспектах расчета рисков, о расчете возврата инвестиций, а я - математический блок. В нем я рассказываю про расчет потенциальных убытков компании на основе сугубо статистики событий информационной безопасности.
Идея - использовать байесовскую сеть и метод Монте-Карло. Но о паре вещей в тексте я не упоминаю.
В чем суть?и что я не сказал в статье
Первое - предлагаемый метод оценки позволит посчитать потенциальный ущерб в следующем временном периоде на основе анализа прошедшего. Стоит только уточнить, что такая оценка справедлива в рамках задаваемого доверительного интервала, например 2 или 3 σ.
Второе - стоит упомянуть, что сведения по потенциальному ущербу необходимо либо вводить руками, оценивая риски экспертно, либо на основе атрибуции рисков и активов (или бизнес-процессов). В результате атрибуция дает различные виды стоимости активов - простоя, восстановления, замещения и т.д. Можно считать стоимость риска через штрафы регуляторов, а можно и любым другим уникальным для каждого конкретного случая образом.
➡️ Если заинтересовало, предлагаю погрузиться в материал детальнее)
#иб
Под конец года наконец-то вышла наша с Максимом Анненковым статья про технический подход к управлению рисками в организации.
В статье Максим писал о прикладных аспектах расчета рисков, о расчете возврата инвестиций, а я - математический блок. В нем я рассказываю про расчет потенциальных убытков компании на основе сугубо статистики событий информационной безопасности.
Идея - использовать байесовскую сеть и метод Монте-Карло. Но о паре вещей в тексте я не упоминаю.
В чем суть?
Первое - предлагаемый метод оценки позволит посчитать потенциальный ущерб в следующем временном периоде на основе анализа прошедшего. Стоит только уточнить, что такая оценка справедлива в рамках задаваемого доверительного интервала, например 2 или 3 σ.
Второе - стоит упомянуть, что сведения по потенциальному ущербу необходимо либо вводить руками, оценивая риски экспертно, либо на основе атрибуции рисков и активов (или бизнес-процессов). В результате атрибуция дает различные виды стоимости активов - простоя, восстановления, замещения и т.д. Можно считать стоимость риска через штрафы регуляторов, а можно и любым другим уникальным для каждого конкретного случая образом.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10
#праздное #ml_для_иб #иб_для_ml
Подходит к завершению 2024 год, а на носу - год 2025, открывающий новую четверть 21 века.
Я уверен, профиль профессии и вообще жизни каждого из нас изменится неузнаваемо в ближайшие годы.
Поэтому я всем желаю в водовороте новых идей, событий, знакомств и задач не терять из виду свои интересы и ценности.
Это, наверное, одно из главных соображений, которое я извлек за этот год.
В 2024 году этот канал появился в публичном пространстве, и я благодарен каждому из вас, что проявили свой интерес к теме машинного обучения и информационной безопасности, присоединившись к каналу «Борис_ь с ml»!)
Постараюсь вас и впредь радовать интересной и снабжать полезной информацией!
А сейчас предлагаю вашему вниманию самые интересные сообщения в моем канале за этот год.
Дайджест 2024
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13🎄6🔥3
2025 год для канала начался очень даже хорошо - он преодолел отметку 500 читателей! Спасибо вам, друзья!
Я невероятно рад, что мой интерес и взгляд на будущее информационных технологий разделяют еще столько людей. Для меня это теперь ответственно - рассказывать вам о том, что происходит в мире информационной безопасности и искусственного интеллекта. Поэтому наполнение канала постараюсь держать как минимум на заданной планке и впредь
И не откладывая в долгий ящик, я представляю вам, читатели, первую публикацию в этом году - хабр-статья про интерпретацию ИИ.
Тема меня очень заинтересовала давно, и сначала вылилась в подкаст в Музее Криптографии. Но я понял, что сам еще многое не рассказал вам и не показал, так что сел за статью. В ней я разбираюсь, чем отличается интерпретируемость и объяснимость, и, как всегда, привожу море ссылок. Приятного чтения)
#иб_для_ml
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Что такое интерпретируемость машинного обучения?
Насколько интерпретируемость важна для машинного обучения? Зачем она вообще нужна? Для чего она в информационной безопасности? Меня эти вопросы начали интересуют уже около полугода, и в фоновом режиме...
👍11🔥4❤2
Безопасность ИИ-агентов
#иб_для_ml #мысли
Примечание: в последнее время я понял, что застопорился на очень больших информационных материалах, из-за чего контент подолгу зависает. Чтобы увеличить динамику постов, попробуем новый формат - просто мои мысли по разным темам, без ссылок-источников.
Очень популярное сегодня направление работ - системы, производящие взаимодействие с внешней средой согласно заложенной в них цели. Реализуются, понятное дело, на GenAI-моделях. Избегаю термина LLM, так как модели как с мультимодальным входом, так и выходом, уже достаточно распространены.
Какие у них могут быть проблемы безопасности? Начать надо, как это принято в ИБ, с объектов защиты. Я выделяю следующие:
1. Безопасность ИИ-агента и его внутренних механизмов
2. Безопасность среды исполнения действий агента.
Каждый из них ветвится далее, но это уже частности, которые еще точно будут уточняться. Атака на агент может привести к его дисфункции, или утечке данных из его памяти. Это может быть целью атаки, но скорее всего конечной целью нарушителя должна быть среда исполнения агента. Например, украсть содержимое файла etc/passwd в среде исполнения функций агента, или переменные среды. Или, если агент может загружать картинки из интернета и открывать их пользователю, он может открыть и зараженный файл, который послужит полноценным событием initial access на устройство/в сеть.
Есть и еще один объект защиты, с которым я пока не до конца определился:
3. Безопасность взаимодействия ИИ-агентов.
Не определился о его самоботнытности: он отдельный, или включен в пункт 2 (приглашую здесь к дискуссии в комментариях). Здесь больше всего интересных кейсов. В результате взаимодействия со внешней средой один агент может подвергнут успешному джейлбрейку, и начать распространять вредоносную инструкцию дальше при общении с другими агентами. Эта логика будет переходить и модифицировать поведение агентов, пока не достигнет нужного агента, обладающего правами, например, работать с БД. Он прочитает нужную информацию, и по цепочке вернет это агенту, общающемуся с интернетом.
Про то, какие я вижу меры защиты для ИИ-агентов и мультиагентных систем, я напишу в другом посте.
Друзья, дайте пожалуйста знать, если вам по душе такой формат)
#иб_для_ml #мысли
Очень популярное сегодня направление работ - системы, производящие взаимодействие с внешней средой согласно заложенной в них цели. Реализуются, понятное дело, на GenAI-моделях. Избегаю термина LLM, так как модели как с мультимодальным входом, так и выходом, уже достаточно распространены.
Какие у них могут быть проблемы безопасности? Начать надо, как это принято в ИБ, с объектов защиты. Я выделяю следующие:
1. Безопасность ИИ-агента и его внутренних механизмов
2. Безопасность среды исполнения действий агента.
Каждый из них ветвится далее, но это уже частности, которые еще точно будут уточняться. Атака на агент может привести к его дисфункции, или утечке данных из его памяти. Это может быть целью атаки, но скорее всего конечной целью нарушителя должна быть среда исполнения агента. Например, украсть содержимое файла etc/passwd в среде исполнения функций агента, или переменные среды. Или, если агент может загружать картинки из интернета и открывать их пользователю, он может открыть и зараженный файл, который послужит полноценным событием initial access на устройство/в сеть.
Есть и еще один объект защиты, с которым я пока не до конца определился:
3. Безопасность взаимодействия ИИ-агентов.
Не определился о его самоботнытности: он отдельный, или включен в пункт 2 (приглашую здесь к дискуссии в комментариях). Здесь больше всего интересных кейсов. В результате взаимодействия со внешней средой один агент может подвергнут успешному джейлбрейку, и начать распространять вредоносную инструкцию дальше при общении с другими агентами. Эта логика будет переходить и модифицировать поведение агентов, пока не достигнет нужного агента, обладающего правами, например, работать с БД. Он прочитает нужную информацию, и по цепочке вернет это агенту, общающемуся с интернетом.
Про то, какие я вижу меры защиты для ИИ-агентов и мультиагентных систем, я напишу в другом посте.
👍17❤🔥4👏3
Как оценивать джейлбрейки LLM
#ml_для_иб
В рамках безопасности языковых моделей с ростом зрелости процессов в какой-то момент встает вопрос об их автоматизации. А что есть автоматизация этого процесса? Генерация определенного набора атакующих промптов не вручную, но при помощи программы. И проверка ответов LLM, являющейся целью тестирования, тоже программой. И практически единственный способ реализации такой схемы - LLM как атакующий и LLM как оценщик. Многие blackbox-атаки сегодня используют такую компоновку.
Почему я об этом вспомнил?
Потому что мне попалась на глаза интересная статья про метрики оценки качества LLM (https://habr.com/ru/companies/yandex/articles/861084/).
Прочитав ее, на ум мне сразу же пришла аналогия с задачей оценки опасности ответа LLM (считай - качества джейлбрейка). Вот какие выводы я извлек из этой статьи:
1. Необходим бенчмарк не только для целевой модели на безопасность ее ответов, но и бенчмарк для оценщика ответов. И чтобы иметь надежную модель-оценщик, необходимо иметь собранный человеческими экспертами контрольный датасет оценок промптов на опасность/безопасность.
2. При использовании бенчмарка на результатах очередного тестирования нужно подмешивать в эти данные и контрольную выборку, чтобы контролировать качество оценщика, если вы не контролируете его состояние (по факту - используете предоставляемую по API модель).
3. Необходимо периодическое обновление контрольного датасета оценщика, так как атаки будут представлять давать модели все новые опасные инструкции, и необходимо быть уверенными, что наш инструмент "понимает", что они действительно опасные.
4. Когда модель-оценщик и целевая модель - это одна и та же модель, в Side-By-Side сравнении с "непредвзятой моделью" у нее появляется "нарциссизм", то есть оценщик предпочитает "свои" ответы ответам других моделей. В случае оценки безопасности ответов это может вылиться в то, что оценщик того же рода, что и целевая модель, будет завышать безопасность ответов оцениваемой модели.
В заключение скажу, что есть и специально дообученные под оценку модели. Среди них Llama Guard 3, Google ShieldGemma, IBM Granite Guardian, Protectai Prompt Guard, TrustSafeAI Attention Tracker.
Тем, кто занимается автоматизацией LLM Red Teaming, надеюсь, будет полезно.
#ml_для_иб
В рамках безопасности языковых моделей с ростом зрелости процессов в какой-то момент встает вопрос об их автоматизации. А что есть автоматизация этого процесса? Генерация определенного набора атакующих промптов не вручную, но при помощи программы. И проверка ответов LLM, являющейся целью тестирования, тоже программой. И практически единственный способ реализации такой схемы - LLM как атакующий и LLM как оценщик. Многие blackbox-атаки сегодня используют такую компоновку.
Почему я об этом вспомнил?
Потому что мне попалась на глаза интересная статья про метрики оценки качества LLM (https://habr.com/ru/companies/yandex/articles/861084/).
Прочитав ее, на ум мне сразу же пришла аналогия с задачей оценки опасности ответа LLM (считай - качества джейлбрейка). Вот какие выводы я извлек из этой статьи:
1. Необходим бенчмарк не только для целевой модели на безопасность ее ответов, но и бенчмарк для оценщика ответов. И чтобы иметь надежную модель-оценщик, необходимо иметь собранный человеческими экспертами контрольный датасет оценок промптов на опасность/безопасность.
2. При использовании бенчмарка на результатах очередного тестирования нужно подмешивать в эти данные и контрольную выборку, чтобы контролировать качество оценщика, если вы не контролируете его состояние (по факту - используете предоставляемую по API модель).
3. Необходимо периодическое обновление контрольного датасета оценщика, так как атаки будут представлять давать модели все новые опасные инструкции, и необходимо быть уверенными, что наш инструмент "понимает", что они действительно опасные.
4. Когда модель-оценщик и целевая модель - это одна и та же модель, в Side-By-Side сравнении с "непредвзятой моделью" у нее появляется "нарциссизм", то есть оценщик предпочитает "свои" ответы ответам других моделей. В случае оценки безопасности ответов это может вылиться в то, что оценщик того же рода, что и целевая модель, будет завышать безопасность ответов оцениваемой модели.
В заключение скажу, что есть и специально дообученные под оценку модели. Среди них Llama Guard 3, Google ShieldGemma, IBM Granite Guardian, Protectai Prompt Guard, TrustSafeAI Attention Tracker.
Тем, кто занимается автоматизацией LLM Red Teaming, надеюсь, будет полезно.
👍9❤1🔥1
Тренд безопасности AI-агентов
#иб_для_ml
Что есть сейчас, и к чему идет этот тренд? Развивается, но почему?
Захотелось рассказать, что думаю на этот счет, и услышать ваше мнение. Так что ниже будет опрос)
Что такое AI-агенты?
Про AI-агентов говорят очень много, но давайте взглянем в суть вещей. Что это? Есть широчайшие расхождения в данных понятиях, и пространные определения, но сойдемся на главном.
Первое: AI-агент - не GenAI-модель, это код (в обычном его понимании, да), который использует GenAI-модель.
Второе: у AI-агента может и не быть механизмов памяти, планирования, рефлексии и даже в целом какой-то целеустановки (читай, роли).
Третье: что у агента точно должно быть, так это возможность вызвать какие-то функции на основании сгенерированного GenAI-моделью ответа. При чем эти действия не должны в 100% случаев валидироваться людьми, иначе это уже не агент.
В чем риск AI-агентов?
Именно благодаря действиям к двум существующим эфемерным рискам добавится третий, уже далеко не эфемерный.
Первые два - это репутационный ущерб организации, если сервис с LLM торчит наружу, и нарушение бизнес-процессов при нарушении ожидаемой от ответов GenAI-модели логики. И то, и другое, может произойти как вследствие недостаточной AI Safety (модель сама выдала случайно некорректный ответ), так и в следствие недостаточной AI Security (нарушитель вызвал генерацию некорректного ответа).
А вот третий риск, специфичный для AI-агентов - это его возможность совершать действия, которые могут повлечь негативные последствия. И веер угроз тут огромен - от выгрузки за пределы контура конфиденциальной информации до загрузки зараженного файла внутрь этого контура, от случайного удаления файлов до перевода средств не на тот счет и не в том размере.
В заключение
Известно, что GenAI-модели как продукт - убыточная история, история без KPI. Затраты на разработку, дообучение (не говоря уж про претрейн) очень тяжело покрыть с доходов при интеграции модели в какие-то сервисы. Но, с точки зрения имиджа и в надежде на развитие прикладного использования, вложения продолжаются. С появлением же у GenAI-моделей способности влиять на мир вокруг, все изменится. Сначала (в 2025 году) появятся игрушечные агенты, которые будильник по расписанию ставят и товары по ТЗ в браузере находят. А спустя еще год, максимум два - они смогут и покупать найденные товары (и продавать ваши будильники, хехе...), иными словами - смогут манипулировать ограниченными ресурсами. И весь арсенал промпт-атак на GenAI обретет смысл, киллчейн достроится до конца. Тогда и начнется раздолье.
А про то, какие будут промпт-атаки, и почему произойдут первые инциденты в области AI Security, я расскажу в следующем посте)
P. S. Не удержался я все-таки, приведу одно хорошее исчерпывающее определение агента, чтобы было.
При чем интересно - одна половина определения (про автономность и достижение поставленных целей) - это определение просто агента из мат. моделирования 1970х годов. А другая половина (про планирование, реагирование и взаимодействие) - это уже интеллектуальный агент, концепция которых была развита М. Вулдриджем в 1990х годах.
#иб_для_ml
Что есть сейчас, и к чему идет этот тренд? Развивается, но почему?
Захотелось рассказать, что думаю на этот счет, и услышать ваше мнение. Так что ниже будет опрос)
Что такое AI-агенты?
Про AI-агентов говорят очень много, но давайте взглянем в суть вещей. Что это? Есть широчайшие расхождения в данных понятиях, и пространные определения, но сойдемся на главном.
Первое: AI-агент - не GenAI-модель, это код (в обычном его понимании, да), который использует GenAI-модель.
Второе: у AI-агента может и не быть механизмов памяти, планирования, рефлексии и даже в целом какой-то целеустановки (читай, роли).
Третье: что у агента точно должно быть, так это возможность вызвать какие-то функции на основании сгенерированного GenAI-моделью ответа. При чем эти действия не должны в 100% случаев валидироваться людьми, иначе это уже не агент.
В чем риск AI-агентов?
Именно благодаря действиям к двум существующим эфемерным рискам добавится третий, уже далеко не эфемерный.
Первые два - это репутационный ущерб организации, если сервис с LLM торчит наружу, и нарушение бизнес-процессов при нарушении ожидаемой от ответов GenAI-модели логики. И то, и другое, может произойти как вследствие недостаточной AI Safety (модель сама выдала случайно некорректный ответ), так и в следствие недостаточной AI Security (нарушитель вызвал генерацию некорректного ответа).
А вот третий риск, специфичный для AI-агентов - это его возможность совершать действия, которые могут повлечь негативные последствия. И веер угроз тут огромен - от выгрузки за пределы контура конфиденциальной информации до загрузки зараженного файла внутрь этого контура, от случайного удаления файлов до перевода средств не на тот счет и не в том размере.
В заключение
Известно, что GenAI-модели как продукт - убыточная история, история без KPI. Затраты на разработку, дообучение (не говоря уж про претрейн) очень тяжело покрыть с доходов при интеграции модели в какие-то сервисы. Но, с точки зрения имиджа и в надежде на развитие прикладного использования, вложения продолжаются. С появлением же у GenAI-моделей способности влиять на мир вокруг, все изменится. Сначала (в 2025 году) появятся игрушечные агенты, которые будильник по расписанию ставят и товары по ТЗ в браузере находят. А спустя еще год, максимум два - они смогут и покупать найденные товары (и продавать ваши будильники, хехе...), иными словами - смогут манипулировать ограниченными ресурсами. И весь арсенал промпт-атак на GenAI обретет смысл, киллчейн достроится до конца. Тогда и начнется раздолье.
А про то, какие будут промпт-атаки, и почему произойдут первые инциденты в области AI Security, я расскажу в следующем посте)
P. S. Не удержался я все-таки, приведу одно хорошее исчерпывающее определение агента, чтобы было.
ИИ-агент - система на базе GenAI, способная планировать и совершать автономные действия во внешней среде, реагировать на изменения и взаимодействовать с человеком или другими агентами для достижения поставленных целей.
При чем интересно - одна половина определения (про автономность и достижение поставленных целей) - это определение просто агента из мат. моделирования 1970х годов. А другая половина (про планирование, реагирование и взаимодействие) - это уже интеллектуальный агент, концепция которых была развита М. Вулдриджем в 1990х годах.
👍10
Forwarded from PWN AI (Artyom Semenov)
Дамы и господа, ни к чему не обязывающий опрос. Хочется узнать у вас работаете ли вы там, где необходимо совмещать ИБ и ИИ. (нужно выбрать несколько вариантов)
Anonymous Poll
14%
Да, занимаюсь больше машинным обучением для безопасности
18%
Да, стараюсь сделать машинное обучение безопасным
6%
Да, пишу научные публикации по теме безопасности машинного обучения
19%
Мне просто это интересно и в дальнейшем планирую работать в сфере защиты искусственного интеллекта.
43%
Хочу для себя понять как можно применить ИИ в ИБ
23%
Мне интересна безопасность LLM и всё что с этим связано, и планирую связать с этим свой путь.
18%
Пока не вижу перспектив в защите ИИ, однако эта тема меня также интересует.