Agentes LLM e SOC: desenvolvedores construíram um banco de dados de ameaças cibernéticas usando RAG

Os desenvolvedores compartilharam no Habr como construíram seu próprio banco de dados de ameaças cibernéticas para agentes LLM e sistemas SOC: o serviço combina documentos PDF, registros CVE e artigos de segurança cibernética em um banco de dados e fornece fragmentos relevantes a um agente de IA através de uma API HTTP.

Como o banco de dados do pipeline é estruturado

Inicialmente, a tarefa parecia linear e se encaixava em uma sequência de etapas. Fontes — arquivos PDF, descrições de vulnerabilidades CVE e artigos de segurança da informação — primeiro são carregados no sistema, depois o texto é extraído deles.

• Fontes de dados — documentos PDF, registros CVE e artigos de segurança cibernética
• O texto é dividido em fragmentos (chunking) para indexação subsequente
• Representações vetorizadas (embeddings) são construídas a partir de fragmentos para busca semântica
• O banco de dados concluído retorna resultados ao agente LLM através de uma API HTTP
• Os autores montaram um protótipo de trabalho rapidamente — o trabalho real começou após seu lançamento

Após a extração de texto, o sistema divide documentos em fragmentos, constrói representações vetorizadas a partir deles e transforma tudo em um índice de busca do qual um agente LLM ou analista SOC recebe contexto para uma ameaça específica.

Por que um protótipo é apenas o começo

Segundo os autores, um protótipo de trabalho apareceu rapidamente e o trabalho real começou depois. Esta é uma situação típica para bases de conhecimento baseadas em RAG (retrieval-augmented generation) em domínios especializados estreitos como segurança cibernética: montar uma cadeia básica de upload, extração de texto, chunking, vetorização e busca pode ser feito em pouco tempo, mas transformá-la em uma fonte que um agente LLM e analista SOC realmente confiam — é uma tarefa de uma escala completamente diferente.

Uma complexidade adicional em tal domínio é a heterogeneidade de formatos: relatórios de ameaças PDF, registros CVE estruturados e artigos regulares de segurança são estruturados de forma diferente e requerem abordagens diferentes para extração de texto e fragmentação antes que tudo possa ser trazido para um índice de busca unificado.

Por que isso é necessário para agentes LLM e SOC

A ideia é dar ao agente LLM não conhecimento geral do conjunto de dados de treinamento, mas fragmentos atuais e verificáveis de relatórios PDF, registros CVE e artigos de segurança através de uma API HTTP. Para um analista SOC (Security Operations Center), isso significa que a resposta do modelo para uma ameaça específica é baseada em uma fonte real, não apenas no que o modelo "lembra" do pré-treinamento — uma abordagem comumente chamada retrieval-augmented generation, ou RAG.

Esta é a razão pela qual os autores descrevem o caminho não como um desenvolvimento único, mas como um processo contínuo: o banco de dados de ameaças de segurança cibernética deve ser continuamente atualizado com novos CVEs e artigos, o que significa que o pipeline de carregamento, chunking e busca precisa ser mantido e refinado mesmo depois que a primeira versão começa a responder consultas.

O esquema de cinco etapas — upload, extração de texto, chunking, construção de vetores, busca — é típico para sistemas RAG modernos e se encaixa em uma lógica linear compreensível que é fácil de descrever em um quadro branco. Este é exatamente a versão simples do pipeline que os autores montaram primeiro antes de passar para a etapa de refinamento mais trabalhosa.

O que isso significa

O caso mostra um caminho típico para construir sistemas RAG para domínios profissionais estreitos: um pipeline de trabalho para upload, chunking e busca de vetores pode ser montado rapidamente, mas transformá-lo em uma ferramenta que agentes LLM e analistas SOC realmente confiam — é uma tarefa que realmente começa apenas após o primeiro protótipo.