ИИ SOC на двух ядрах CPU: как модель в 9 млрд параметров достигла точности 96%

Александр Кельчин, технический директор и директор по информационной безопасности Medici Lab, в часовом интервью разобрал архитектуру самописной системы мониторинга угроз, которую его команда строила с нуля и довела до промышленных показателей на минимальном железе.

ИИ SOC (Security Operations Center, центр мониторинга и реагирования на киберугрозы, где часть работы аналитика берёт на себя языковая модель) обычно требует мощных серверов и дорогих подписок. Кельчин пошёл другим путём: перенёс первичную обработку на сами рабочие станции, а модели дал только короткий, уже очищенный контекст. Результат команда измерила на внутренних тестах; методику пока не публиковали, но публичный ориентир от Microsoft подтверждает порядок стартовых цифр.

Что показали замеры и почему 60% хуже, чем кажется?

• Базовая точность языковой модели на задачах второй линии SOC составила около 60%. Вторая линия SOC означает, что аналитик не просто смотрит на оповещение, а расследует: собирает контекст, связывает события, решает, реальный ли это инцидент, и реагирует. Из каждых ста событий модель ошибалась в сорока, что делает полностью автоматическое реагирование невозможным.

• Публичный бенчмарк Microsoft подтверждает тот же порядок. В тесте ExCyTIn-Bench, где ИИ-агенты расследуют угрозы по 57 таблицам логов Microsoft Sentinel (7 542 вопроса), лучшая модель на момент публикации набрала 0,606. Метрики и задачи другие, но вывод один: целиком вторую линию модель пока не закрывает.

• После перестройки архитектуры и дообучения (обучения модели на конкретных примерах под узкую задачу) точность выросла до 96-97%. Ключевой инженерный ход: задачу уменьшили до размера, на котором маленькая модель надёжна. Модель проверяет не весь инцидент, а одно конкретное сработавшее правило с контекстом около 200 токенов (токен, минимальная единица текста для модели, примерно 3-4 символа русского текста).

• Вся система держала 150 хостов на двух ядрах CPU. Агент на каждой рабочей станции весит 60 килобайт, написан на C и C++, применяет правила локально и отправляет в центр только очищенные события.

• Сравнивать 60% и 96-97% напрямую нельзя. В первом случае модель делала работу второй линии целиком, во втором проверяет одно сработавшее правило с крошечным контекстом.

Как устроена обработка событий?

Классический SIEM (система сбора и анализа событий безопасности) собирает всё на центральный сервер: там данные нормализуются, обогащаются и коррелируются. Масштабируется это увеличением числа серверов, а требования к памяти и дискам растут вместе с потоком. Для ИИ SOC такая схема создаёт дополнительную проблему: если отправить весь нормализованный поток в языковую модель, вы упираетесь в контекстное окно (объём текста, который модель может обработать за один раз). Расширение окна стоит кратно дороже, а качество ответа на длинном контексте падает.

Команда Кельчина перенесла обработку на конечные хосты. Агент на каждой машине применяет правила локально и отправляет на коллектор только очищенные события. Ориентиром Кельчин назвал концепцию Microsoft Sentinel, где SIEM наполовину становится EDR (системой обнаружения и реагирования на конечных устройствах).

Формат событий задаёт собственный движок правил, поэтому модели на коллекторе не нужна нормализация. Она всегда видит короткий и предсказуемый вход. Перед моделью стоит диспетчер: он определяет, какое правило сработало, и направляет событие в соответствующую дообученную модель. Аналитик на выходе получает разобранные и проверенные карточки вместо сырого потока.

Кельчин уточнил, что на их сервере модель успевала разбирать примерно три события в секунду, причём события к этому моменту уже прошли фильтрацию на хостах.

Выбор модели: снизу вверх или сверху вниз?

Команда начала с Qwen на 9 миллиардов параметров (открытая модель, opеnsорс) без дообучения и замерила базовую линию. Кельчин также пробовал фронтирные модели (самые мощные закрытые модели ведущих разработчиков) по подписке на тестовом стенде. Метрики качества росли, но скорость падала, а на длинном контексте выигрыш размывался.

Настоящий скачок дало именно дообучение модели 9B под конкретные группы правил, а не увеличение размера. Кельчин ответил, что размер модели для этого менять не пришлось.

Два подхода к выбору размера: начинать с маленькой модели и наращивать, пока задача не решится, или сразу проверить идею на фронтирной и потом спускаться. Второй путь экономит месяцы, если удаётся угадать нужный размер. В случае Medici Lab сработал первый.

Доступен ли такой подход в России?

Решение Medici Lab внутреннее, публичного продукта на момент интервью команда не предлагала. Но сам подход воспроизводим: Qwen 9B доступна для скачивания, агент написан на C/C++, архитектура описана в интервью.

Из коммерческих ИИ SOC на российском рынке работают решения от Positive Technologies (MaxPatrol SIEM с элементами автоматизации) и Kaspersky (KUMA). Оба используют собственные правила корреляции. Насколько они применяют языковые модели для автоматической проверки сработавших правил, компании публично не раскрывают. Прямого аналога схемы «агент 60 КБ плюс дообученная модель на коллекторе» среди публичных продуктов нет.

Для тех, кто работает с YandexGPT или GigaChat: сама идея «не давать модели весь контекст, а только короткое описание одного сработавшего правила» применима к любой языковой модели. Разница в том, что Кельчин дообучал модель локально, а облачные российские модели дообучения пока не предлагают в таком формате.

Что делать с этим прямо сейчас, по ролям?

Автору Дзена, который пишет про технологии или безопасность. Архитектура Кельчина даёт конкретный кейс для контента: как маленькая модель побеждает большую, когда ей правильно нарезают задачу. Это работает как иллюстрация для любой темы про ИИ-автоматизацию.

Маркетологу и предпринимателю. Принцип «уменьши задачу до размера, на котором дешёвая модель надёжна» переносится на любую автоматизацию. Если вы пробовали отдать ИИ-агенту сложный процесс и получили 60% качества, попробуйте разбить процесс на узкие шаги и дообучить модель на каждом.

Специалисту по безопасности. Посмотрите полное интервью на YouTube. Кельчин разбирает три типичных возражения к схеме и объясняет, где архитектура ломается. Методику замеров команда не публиковала, поэтому цифры 96-97% стоит воспринимать как ориентир, а не как воспроизводимый бенчмарк.

Частые вопросы

Можно ли повторить эту систему без знания C и C++?

Саму архитектуру агента на 60 килобайт без программирования на C/C++ повторить нельзя. Но принцип «фильтруй данные до модели, а не после» работает с любым стеком. Если вы используете облачную модель, просто отправляйте ей не весь лог, а короткое описание конкретного события с контекстом в 200-300 токенов.

Почему команда выбрала Qwen 9B, а не более крупную модель?

По словам Кельчина, модели на 27 миллиардов параметров и фронтирные модели по подписке давали лучшее качество на базовых тестах, но скорость падала, а на длинном контексте выигрыш размывался. После дообучения модели 9B качество выросло до 96-97% без увеличения размера. Для задачи, где нужно обрабатывать три события в секунду на скромном сервере, скорость оказалась важнее параметров.

Подходит ли эта схема для малого бизнеса без отдела безопасности?

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