Как Selectel автоматизировал разбор инцидентов с помощью RAG и локальной LLM
Команда информационной безопасности Selectel столкнулась с рутиной: аналитики тратили дни на проверку ложных срабатываний и заполнение документации. Для решения этой проблемы они отказались от сложного и долгого файнтюнинга, выбрав архитектуру RAG с локальной языковой моделью и валидатором. Это позволило сократить время разбора и снизить нагрузку на персонал, оставаясь в рамках строгих требований к безопасности данных.
# От рутины к интеллекту: автоматизация разбора инцидентов в SOC Selectel
В центрах мониторинга безопасности (SOC) часто возникает парадокс: значительная доля времени специалистов уходит на обработку однотипных инцидентов, которые в итоге оказываются ложными срабатываниями. Каждый сигнал требует проверки, обогатить контекстом и документирования. Такая нагрузка отнимает ресурс у аналитиков, увеличивает риск ошибок из-за усталости и мешает решению более сложных задач.
Команда информационной безопасности Selectel искала решение, которое позволит автоматизировать первичный анализ, не передавая данные во внешние сервисы и избегая многомесячных циклов дообучения моделей. Результатом эксперимента стала связка локальной LLM, технологии RAG и двухуровневой системы валидации.
Почему выбрана архитектура RAG вместо файнтюнинга
При выборе подхода к автоматизации перед командой стояли два сценария: дообучение (файнтюнинг) модели на исторических данных или использование готовой модели в связке с поиском знаний (RAG — Retrieval-Augmented Generation).
Файнтюнинг требовал бы создания массивного датасета с тысячами размеченных примеров «правильных» решений. Это означало бы не только огромные трудозатраты на разметку, но и постоянную необходимость перенастраивать модель при каждом обновлении внутренней документации или инфраструктуры. Такой подход был признан слишком медленным и дорогим.
Решение RAG позволило собирать актуальную информацию из внутренней документации Selectel по хостам, доменам и инфраструктуре. Вместо того чтобы заучивать всё подряд, модель получает только релевантные данные для конкретного запроса. Осознанным выбором стал полнотекстовый поиск, который, в отличие от векторного, эффективен для работы с небольшим спейсом данных, где точность совпадения текста критична.
*Как пишет Антон Дятлов, инженер по защите информации в Selectel: «Хотелось сделать быстро и эффективно. RAG позволяет собрать данные из внутренней документации, которая содержит информацию по хостам, доменам и инфраструктуре. Модель получает только нужную информацию и на ее основе принимает решение».*
Тонкая настройка модели и локализация
Ключевым условием для проекта стала политика безопасности Selectel: данные не могут покидать внутренний контур. Это сразу отсекло облачные модели вроде ChatGPT. Из оставшихся локальных вариантов в шорт-лист попали Qwen 3.6-27B и GLM-5.1/5.2.
Модель Qwen продемонстрировала нестабильность при работе с длинными контекстами и склонность к галлюцинациям. GLM-5.2, несмотря на высокую вычислительную стоимость, показала лучшую точность и надежность. Особенно важна была метрика *False Escalation* (ложная эскалация на уровень L2): именно по этому критерию GLM превзошла конкурента, минимизируя лишние задачи для старших аналитиков.
Для обогащения контекста система интегрируется с OSV API для получения актуальной информации об уязвимостях (CVE, критичность по CVSS) и использует Confluence для поиска технических деталей по инфраструктуре. Данные подтягиваются до вызова модели, что устраняет необходимость придумывать факты нейросети.
Процесс анализа: от сырого сигнала к решению
Автоматизированный процесс обработки инцидента построен на оркестраторе n8n и включает строго структурированный флоу:
1. Нормализация: Сырой JSON из SIEM часто содержит разнотипные данные и мусор. Скрипт превращает его в предсказуемый формат. 2. Обогащение: Система запрашивает данные об уязвимостях и ищет контекст в документации. 3. RAG и Промпт: Модель получает чистый набор фактов и жесткие инструкции (системный промпт), ограничивающие её роль до уровня L1-аналитика. 4. Анализ и Валидация: Это критический этап. Ответ первичной модели передается валидатору — второму проходу логики, который проверяет выводы на противоречия. * Если валидатор согласен (*agreement_score* >= 0.8), инцидент обрабатывается автоматически. * Если выявлены расхождения, решение корректируется. * При недостатке данных или сильном несогласии инцидент перенаправляется живому человеку.
Проблемы внедрения и результаты
Даже при тщательной проработке архитектуры реализация не обошлась без технических нюансов. Нейросети иногда оборачивают JSON-ответы в Markdown-блоки, что ломает парсинг скриптами — проблему решили регулярными выражениями. Также тяжелая модель GLM требовала задержек между запросами, чтобы избежать ошибок 502 сервера.
Несмотря на это, внедрение дало ощутимый эффект. Около 80% инцидентов, ранее требовавших ручного разбора, теперь закрываются системой практически без участия аналитика. Время на обработку сократилось, а сотрудники получили готовый аналитический отчет вместо сырых данных. В ближайших планах — переход на семантический поиск и тестирование независимых валидаторов.
Проект Selectel демонстрирует, что для автоматизации рутинных задач в ИБ не всегда нужны масштабные дообучения. Грамотная интеграция RAG и валидации с локальными моделями способна существенно повысить эффективность работы SOC, оставаясь при этом безопасной и контролируемой.