Спрашивали – отвечаем ✍️ Откуда пошло цветовое деление у команд ИБ? Истоки концепции – в военных учениях (wargame). Во время Холодной войны, когда армии и аналитические организации моделировали военные конфликты, "красная" сторона (Red) часто символизировала противника (например, СССР), а "синяя" (Blue) – своих или союзников 💪 Например, RAND Corporation во времена Холодной войны проводила такие симуляции, где Red представляла противника, а Blue – США. Со временем этот подход перешел из военного сценарного моделирования в кибербезопасность: "Red Team vs Blue Team" стали использовать для имитации атак и защиты в ИТ-системах ⚔️

Двух цветов со временем стало недостаточно, потому что безопасность – не просто атака vs защита ✏️ С ростом сложности ИТ-инфраструктур понадобились новые роли: разработчики, операторы, люди, внедряющие безопасность на разных этапах. И в 2017 году на конференции Black Hat USA эксперт Эприл Райт (April C. Wright) представила доклад "Orange Is the New Purple", в котором расширила модель, например, добавила "жёлтый" цвет (для разработчиков), фиолетовый (Purple) для описания совместной деятельности Red и Blue для улучшения защиты, и предложила идею, что можно "смешивать" цвета 🎨, получая новые роли. После этого понятием "цветовое колесо" (color wheel) стали называть расширенную систему распределения ролей.

Сегодня деление на цвета выглядит следующим образом: 🎨
🎨 Red Team (красные) – "атакующие" – "белые" хакеры, пентестеры. Они пытаются взломать систему, найти уязвимости, показать, как злоумышленник мог бы проникнуть и нанести вред организации.
🎨 Blue Team (синие) – защитники – отвечают за мониторинг, обнаружение, реагирование на инциденты, защиту систем в режиме реального времени, укрепление безопасности, предотвращение атак.
🎨 Purple Team (фиолетовые) – гибрид / посредник: сочетает подходы Red + Blue. Цель – не просто атака или защита, а совместная работа над усилением безопасности: моментальный разбор обнаруженных уязвимостей, совместная настройка обороны, обмен знаниями.
🎨 Yellow Team (желтые) – разработчики / архитекторы / инженеры: те, кто строят, пишут код, проектируют системы – с учетом безопасности "изнутри". То есть DevSecOps / Secure-by-Design.
🎨 Green Team (зеленые) – инженеры по автоматизации / DevOps-специалисты, кто обеспечивает, чтобы процессы безопасности (патчи, обновления, CI/CD, конфигурации) были автоматизированы, надежны и масштабируемы.
🎨 Orange Team (оранжевые) – команда обучения и трансляции знаний: они "переносят" уроки, которые дает Red Team, внутрь организации, в процессы разработки, операционной безопасности – повышают осведомленность, обучают, помогают закрепить улучшения.
🎨 White Team (белые) – "арбитры" / координаторы: устанавливают правила, рамки, область контроля, наблюдают за процессом, управляют учениями и тестами; гарантируют, что тесты безопасны, организованы, а выводы – адекватно оформлены и переданы командам.

Purple, Green, Orange и другие часто не формальные "отдельные команды", а роли или подходы – особенно в организациях, где нет строго структурированного разделения.

#стратегия

🚀 DroPE: как расширить контекст LLM, просто “выкинув” позиционные эмбеддинги (механизм, который говорит трансформеру в каком порядке идут токены.)

Sakana AI выпустили DroPE - метод, который позволяет увеличить контекст у уже предобученных LLM без привычных адских затрат на long-context fine-tuning.

Идея звучит как ересь, но результаты говорят об обратном .

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

То есть:
- для обучения - нужны
- для генерализации на очень длинные последовательности - мешают

📌 Решение DroPE
Авторы предлагают относиться к позиционным эмбеддингам как к временным “строительным лесам”:
- в pretraining они дают стабильность
- после обучения их можно сбросить (drop)
- и получить zero-shot length extrapolation (модель начинает заметно лучше работать на длинах, которых не видела)

Большие контексты нужны пользователям :
- огромные code diff и монорепы
- юридические контракты на сотни страниц
- аналитика логов и документов без разбиения на чанки

Именно тут многие стандартные модели начинают “ломаться” просто потому что контекст слишком длинный.

Результаты:

DroPE проверили на разных open-source моделях:
- калибровка занимает <1% бюджета от исходного pretraining
- а качество на long-context задачах заметно лучше популярных подходов
- сильные результаты на LongBench и RULER

Позиционка нужна, чтобы обучить модель, но может быть лишней, чтобы мыслить длинно

Возможно RoPE - не “обязательная часть архитектуры”, а просто инструмент для стабильного обучения.

📄 Paper: arxiv.org/abs/2512.12167
🔧 Code: github.com/SakanaAI/DroPE

@ai_machinelearning_big_data

#sakana #ai #ml #opensource