Agentes LLM y SOC: desarrolladores construyeron una base de datos de amenazas cibernéticas con RAG

Los desarrolladores compartieron en Habr cómo construyeron su propia base de datos de amenazas cibernéticas para agentes LLM y sistemas SOC: el servicio combina documentos PDF, registros de CVE y artículos de ciberseguridad en una base de datos y proporciona fragmentos relevantes a un agente de IA a través de una API HTTP.

Cómo se estructura la base de datos del pipeline

Inicialmente, la tarea se veía lineal y se ajustaba a una secuencia de pasos. Las fuentes — archivos PDF, descripciones de vulnerabilidades CVE y artículos de seguridad de la información — primero se cargan en el sistema, luego se extrae texto de ellos.

• Fuentes de datos — documentos PDF, registros de CVE y artículos de ciberseguridad
• El texto se divide en fragmentos (chunking) para indexación posterior
• Se construyen representaciones vectorizadas (embeddings) de fragmentos para búsqueda semántica
• La base de datos terminada devuelve resultados al agente LLM a través de una API HTTP
• Los autores ensamblaron un prototipo de trabajo rápidamente — el trabajo real comenzó después de su lanzamiento

Después de la extracción de texto, el sistema divide documentos en fragmentos, construye representaciones vectorizadas a partir de ellos y transforma todo en un índice de búsqueda del cual un agente LLM o analista SOC recibe contexto para una amenaza específica.

Por qué un prototipo es solo el comienzo

Según los autores, un prototipo de trabajo apareció rápidamente, y el trabajo real comenzó después. Esta es una situación típica para bases de conocimiento basadas en RAG (retrieval-augmented generation) en dominios especializados estrechos como ciberseguridad: ensamblar una cadena básica desde carga, extracción de texto, chunking, vectorización y búsqueda se puede hacer en poco tiempo, pero convertirla en una fuente en la que un agente LLM y un analista SOC realmente confían — es una tarea de una escala completamente diferente.

Una complejidad adicional en tal dominio es la heterogeneidad de formatos: los informes de amenazas PDF, los registros CVE estructurados y los artículos regulares de seguridad están estructurados de manera diferente y requieren enfoques diferentes para la extracción de texto y la fragmentación antes de que todo pueda llevarse a un índice de búsqueda unificado.

Por qué se necesita para agentes LLM y SOC

La idea es dar al agente LLM no conocimiento general del conjunto de datos de entrenamiento, sino fragmentos actuales y verificables de informes PDF, registros CVE y artículos de seguridad a través de una API HTTP. Para un analista SOC (Security Operations Center), esto significa que la respuesta del modelo a una amenaza específica se basa en una fuente real, no solo en lo que el modelo "recuerda" del preentrenamiento — un enfoque comúnmente llamado retrieval-augmented generation, o RAG.

Esta es la razón por la que los autores describen el camino no como un desarrollo único, sino como un proceso continuo: la base de datos de amenazas de ciberseguridad debe actualizarse continuamente con nuevas CVE y artículos, lo que significa que el pipeline de carga, chunking y búsqueda debe mantenerse y refinarse incluso después de que la primera versión comience a responder consultas.

El esquema de cinco pasos — carga, extracción de texto, chunking, construcción de vectores, búsqueda — es típico para sistemas RAG modernos y se ajusta a una lógica lineal comprensible que es fácil de describir en una pizarra. Esto es exactamente la versión simple del pipeline que los autores ensamblaron primero antes de pasar a la etapa de refinamiento más laboriosa.

Qué significa esto

El caso muestra un camino típico para construir sistemas RAG para dominios profesionales estrechos: un pipeline de trabajo para carga, chunking y búsqueda de vectores se puede ensamblar rápidamente, pero convertirlo en una herramienta en la que los agentes LLM y analistas SOC realmente confían — es una tarea que realmente comienza solo después del primer prototipo.