Forwarded from Dealer.AI
Защитники, продолжение...
4. LLM SFT/RL alignment. То, чем доблестно занимались Anthropic и прочие лидеры. Дотюн модели на "правильное" поведение или с sft или RLHF. Берём сеты с нужным поведением и тюним, главное не переборщить иначе модель станет сильно ограниченной. И помним, что в RLHF есть взлом награды, когда мы снова попадаем на OOV примеры.
+ Вдалбливаем тюном по LLM нужное поведения.
- Время на Sft, RL, трудоёмкость из-за сбора сетов, настройки и стабилизации обучения, ну и дорохо.
- OOV примеры и взлом награды в RL приводит к тому, что мы снова не можем покрыть 100% исходов атак или поломали награду и на выходе модель "скрыла" свое опасное поведение.
4. RAG. Собрать примеры хороших и плохих кейсов в формате: запрос, ответ, запрос-ответ, контекст-запрос-ответ. Поместить их в черно-белые списки и векторно к ним матчить все указанное выше в п.4. После матчинга досылать в LLM примеры плохого и хорошего поведения, как few-shot подсказки и тем самым регулировать её генерацию. Тип, вот тут был похожий запрос, он был плохой, вот такое поведение для него лежит в базе, следуй ему. Кстати, такие же механики юзают в RAG для кибербезы.
+ Работаем на уровне базы примеров.
+ Быстро на векторном поиске.
- Писать примеры в базу, анализировать логи, вычленяя оттуда примеры.
- Снова OOV, все не покроешь.
В заключении.
Видел я и QwenGuard, но и он не идеален и взламывается, тк это LLM и у неё есть глюки, и пробития, как ты её не элайнь (об этом я и писал выше) - это фундаментальная проблема на уровне парадигмы обучения. Поэтому большие Дяди из OpenAPI, Anthropic и пр., сначала элайнящее свои модели на тюне и RL, сдались и стали дополнительно обкладывать выход (генерация LM) и вход (фразы юзера) классификатор апи (мониторы и защитники) и в гибриде это работает надёжнее.
Вот и я советую ввиду того, что у каждого метода выше есть +/- блендить схемы защиты: списки+классификаторы+sft/rl. Да к сожалению, бленд дорого, тогда выбирайте свой лёгкий конструктор из того, что выше.
Пишите свои подходы к защите в комментариях ниже и конечно же Stay tuned 🦾
👇 👇 👇 👇 👇
4. LLM SFT/RL alignment. То, чем доблестно занимались Anthropic и прочие лидеры. Дотюн модели на "правильное" поведение или с sft или RLHF. Берём сеты с нужным поведением и тюним, главное не переборщить иначе модель станет сильно ограниченной. И помним, что в RLHF есть взлом награды, когда мы снова попадаем на OOV примеры.
+ Вдалбливаем тюном по LLM нужное поведения.
- Время на Sft, RL, трудоёмкость из-за сбора сетов, настройки и стабилизации обучения, ну и дорохо.
- OOV примеры и взлом награды в RL приводит к тому, что мы снова не можем покрыть 100% исходов атак или поломали награду и на выходе модель "скрыла" свое опасное поведение.
4. RAG. Собрать примеры хороших и плохих кейсов в формате: запрос, ответ, запрос-ответ, контекст-запрос-ответ. Поместить их в черно-белые списки и векторно к ним матчить все указанное выше в п.4. После матчинга досылать в LLM примеры плохого и хорошего поведения, как few-shot подсказки и тем самым регулировать её генерацию. Тип, вот тут был похожий запрос, он был плохой, вот такое поведение для него лежит в базе, следуй ему. Кстати, такие же механики юзают в RAG для кибербезы.
+ Работаем на уровне базы примеров.
+ Быстро на векторном поиске.
- Писать примеры в базу, анализировать логи, вычленяя оттуда примеры.
- Снова OOV, все не покроешь.
В заключении.
Видел я и QwenGuard, но и он не идеален и взламывается, тк это LLM и у неё есть глюки, и пробития, как ты её не элайнь (об этом я и писал выше) - это фундаментальная проблема на уровне парадигмы обучения. Поэтому большие Дяди из OpenAPI, Anthropic и пр., сначала элайнящее свои модели на тюне и RL, сдались и стали дополнительно обкладывать выход (генерация LM) и вход (фразы юзера) классификатор апи (мониторы и защитники) и в гибриде это работает надёжнее.
Вот и я советую ввиду того, что у каждого метода выше есть +/- блендить схемы защиты: списки+классификаторы+sft/rl. Да к сожалению, бленд дорого, тогда выбирайте свой лёгкий конструктор из того, что выше.
Пишите свои подходы к защите в комментариях ниже и конечно же Stay tuned 🦾
Please open Telegram to view this post
VIEW IN TELEGRAM
https://csrc.nist.gov/pubs/sp/800/57/pt1/r6/ipd
Опубликован проект новой редакции стандарта NIST по управлению ключами.
Основные правки это добавление разделов по квантовоустойчивым алгоритмам, в частности Ascon.
Опубликован проект новой редакции стандарта NIST по управлению ключами.
Основные правки это добавление разделов по квантовоустойчивым алгоритмам, в частности Ascon.
CSRC | NIST
NIST Special Publication (SP) 800-57 Rev. 6 (Draft), Recommendation for Key Management: Part 1 – General
This recommendation provides cryptographic key-management guidelines in three parts. Part 1 provides general guidelines and best practices for the management of cryptographic keying material, including definitions for the security services that may be provided…
Портал российского сообщества безопасной разработки
https://рбпо.рф
Планируется ряд разъяснительных публикаций направленных на повышение общей культуры безопасной разработки и рекомендаций по конкретным решениям.
https://рбпо.рф
Планируется ряд разъяснительных публикаций направленных на повышение общей культуры безопасной разработки и рекомендаций по конкретным решениям.
secure-software.ru
Унифицированная среда разработки безопасного отечественного ПО
В данном проекте реализуются подходы по применению ключевых практик разработки безопасного программного обеспечения и использованию инструментов исследования безопасности ПО.
ФСТЭК получилось за последние годы начать системные положительные изменения в процессах сертификации средств защиты информации: от формирования широкого сообщества до начала отзыва сертификатов на СЗИ в случае критичных уязвимостей.
Нельзя не отметить планируемые изменения в процессе сертификации ПО на 6 уровень доверия - планируется установить требование по предоставления доступа к исходному коду.
Нельзя не отметить планируемые изменения в процессе сертификации ПО на 6 уровень доверия - планируется установить требование по предоставления доступа к исходному коду.