LLM-агенты и SOC: разработчики построили базу данных о киберугрозах на RAG

Разработчики рассказали на Habr, как построили собственную базу данных о киберугрозах для LLM-агентов и SOC-систем: сервис объединяет PDF-документы, записи CVE и статьи по кибербезопасности в одной базе и отдаёт релевантные фрагменты ИИ-агенту через HTTP API.

Как устроен пайплайн базы

Изначально задача выглядела линейной и укладывалась в одну цепочку шагов. Источники — PDF-файлы, описания уязвимостей CVE и статьи по информационной безопасности — сначала загружаются в систему, затем из них извлекается текст.

• Источники данных — PDF-документы, записи CVE и статьи по кибербезопасности
• Текст разбивается на фрагменты (chunking) для последующей индексации
• Из фрагментов строятся векторные представления (embeddings) для семантического поиска
• Готовая база отдаёт результат LLM-агенту через HTTP API
• Рабочий прототип авторы собрали быстро — основная работа началась уже после его запуска

После извлечения текста система разбивает документы на части, строит по ним векторные представления и превращает всё это в поисковый индекс, из которого LLM-агент или аналитик SOC получает контекст по конкретной угрозе.

Почему прототип — это только начало

По словам авторов, рабочий прототип появился быстро, а настоящая работа началась уже потом. Это типичная ситуация для баз знаний на основе RAG (retrieval-augmented generation) в узкоспециализированных доменах вроде кибербезопасности: собрать базовую цепочку из загрузки, извлечения текста, чанкинга, векторизации и поиска можно за короткое время, но превратить её в источник, которому реально доверяют LLM-агент и аналитик SOC, — задача совсем другого масштаба.

Отдельная сложность такого домена — разнородность форматов: PDF-отчёты об угрозах, структурированные записи CVE и обычные статьи по-разному устроены и требуют разного подхода к извлечению текста и разбиению на фрагменты, прежде чем всё это можно свести к единому поисковому индексу.

Зачем это нужно LLM-агенту и SOC

Идея — дать LLM-агенту не общие знания из обучающей выборки, а актуальные, проверяемые фрагменты из PDF-отчётов, записей CVE и статей по безопасности через HTTP API. Для аналитика SOC (Security Operations Center) это означает, что ответ модели по конкретной угрозе опирается на реальный источник, а не только на то, что модель «помнит» из предобучения — подход, который в индустрии принято называть retrieval-augmented generation, или RAG.

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

Схема из пяти шагов — загрузка, извлечение текста, чанкинг, построение векторов, поиск — типична для современных RAG-систем и укладывается в понятную линейную логику, которую легко описать на доске. Именно такую простую версию пайплайна авторы и собрали в первую очередь, прежде чем перейти к более трудоёмкому этапу доработки.

Что это значит

Кейс показывает типичный путь построения RAG-систем для узких профессиональных доменов: рабочий пайплайн загрузки, чанкинга и векторного поиска можно собрать быстро, но превратить его в инструмент, которому доверяют LLM-агенты и аналитики SOC, — задача, которая по-настоящему начинается только после первого прототипа.