hugoprd/security-llm-agent

Security LLM Agent

Esse repositório serve como submódulo do repositório risk-security-platform.

Tudo relacionado ao agente LLM e à RAG dele será configurado e executado neste e a partir deste repositório.

Para garantir a reprodutibilidade e evitar conflitos de dependências, este projeto utiliza Conda para gerenciar seu ambiente virtual.

A proposta desse projeto - e especificamente deste agente LLM - é utilizar apenas ferramentas Open Source.

1. Pré-requisitos

• —Conda: Necessário ter uma distribuição do Conda instalada (seja Anaconda ou Miniconda, que é mais leve e recomendado). Entre na preparação do ambiente do projeto, na "seção 1", para instalar e preparar o ambiente Conda, assim, possuindo acesso a todas as bibliotecas necessárias.

• —Pytest: Para conseguir rodar os testes dos métodos/funções corretamente, entre na preparação do ambiente do projeto, na "seção 2.", para configurar corretamente a biblioteca no VSCode.

2. Recursos utilizados

A ideia por trás do agente LLM é utilizar a ferramenta Ollama com o modelo de LLM do Deepseek e, para o programa ter um funcionamento perene/contínuo, será utilizada a plataforma Hugging Face Spaces para possuir um container Docker para o projeto.

2.1. Explicação da escolha da plataforma em nuvem

As duas principais plataformas em nuvem pesquisadas e focadas foram o Hugging Face Spaces e o Oracle Cloud (Always Free Tier). Ambas escolhas eram excelentes para o intuito do projeto, porém, mesmo a Oracle oferecendo um plano totalmente gratuito para a criação de uma Virtual Machine (VM), ainda houve obstáculos.

2.1.1. Oracle Cloud

A Oracle Cloud possibilita que os usuários criem máquinas virtuais em nuvem. O planejamento seria, através desta máquina virtual, criar um container Docker para servir como ambiente em nuvem do Ollama. Porém, ao tentar criar o container, fui travado pelo domínio da Oracle estar sobrecarregado. Seria possível tentar, através dos dias, criar a máquina virtual, todavia, devido ao tempo e necessidade de progredir no projeto, foi decidido prosseguir com o Hugging Face Spaces.

2.1.2. Hugging Face Spaces

O Hugging Face Spaces é uma - traduzindo literalmente - plataforma como serviço (PaaS) que servirá como o ambiente em nuvem que já possui todos os recursos, sem ser necessário se preocupar com a criação de um container Docker, por exemplo.

2.1.3. Conclusão

Neste projeto, tentei focar ao máximo explorar ferramentas e recursos que não conhecia/nunca tinha trabalhado antes com, ou seja, utilizar o serviço do Oracle Cloud era visto como mais interessante, pela necessidade de desenvolver e trabalhar mais em cima dessa plataforma em nuvem e dos containers Dockers. Porém, pelo prazo do trabalho, foi necessário deixar de lado essa tentativa, por enquanto, para a conclusão dele.

2.2. Ollama

Ollama é uma ferramenta Open Source que executa LLMs diretamente em uma máquina. Essa característica torna-o uma escolha agradável em relação à privacidade e controle de dados. A escolha de utilizar o Ollama em vez de outra API de LLM (como diretamente com a API do Gemini, por exemplo) se deve ao fato do usuário possuir mais controle dos dados transmitidos e evita possíveis riscos de segurança.

Para conseguir testar o Ollama em sua máquina local, para este projeto, siga as instruções.

2.2.1. Ollama: DeepSeek 1.5:b

A versão do DeepSeek "deepseek-r1:1.5b" é devido ao fato de ser uma versão mais leve, que consiga funcionar com o intuito do projeto da melhor forma possível. Utilizando a versão padrão (4 GB, com 7.5 bilhões de parâmetros), o Hugging Face Space não suportava, pelo menos a versão gratuita.

Tentei utilizá-la com o Hugging Face Space e funcionava, porém não 100% das vezes, com várias vezes tendo um tempo de resposta muito longo ou dando freeze no Hugging Face Space.

Então, optei por usar outro modelo.

2.2.2. Ollama: Gemma 2:b

A versão Gemma 2:b, da Google, é - igual ao 1.5:b do DeepSeek - uma versão mais leve, possuindo 2 bilhões de parâmetros no modelo.

Da mesma forma, tentei utilizá-lo com o Hugging Face Space e a situação ficou similar ao modelo do DeepSeek mais leve: algumas vezes funcionava, porém a maioria ou demorava muito ou congelava o espaço do Hugging Face.

2.2.3. Ollama: Qwen 2.5 1.5:b

O modelo Qwen foi a escolha ideal para o projeto, com as limitações compreendidas. Mesmo possuindo a mesma quantidade de parâmetros que o do DeepSeek mais leve (1,5 bilhões) ele ainda sim era mais leve, porém, ao mesmo tempo, menos potente. Logo, foi necessário fazer um prompt mais específico para que ele respondesse adequadamente, junto com a RAG dele.

2.3. Neon

Neon é um DBaaS (DataBase as a Service) que fornece um banco de dados Postgres completo e gerenciado, permitindo a concentração de uma aplicação sem uma preocupação com a infraestrutura. Sendo projetado para resolver problemas em nuvem, por ser serveless, foi a escolha ideal para este projeto.

Estarei utilizando o Neon como o banco de dados RAG do agente LLM.

2.4. Base RAG

O conteúdo do banco de dados RAG do agente é mais especificado no aqui.

3. Testes

Os testes feitos para este repositório envolvem apenas testes de códigos feitos para a criação do agente LLM.

3.1. Testes do Google Colab

Os primeiros testes foram feitos através do Google Colab, para ser possível - principalmente - visualizar o agente LLM e montar o código sem ser necessário instalar na máquina local bibliotecas que talvez não fossem ser utilizadas no futuro.

Os testes se encontram na pasta de testes do Colab e todos os códigos dentro dela não foram testados na versão final do repositório, servindo, assim, apenas para documentação dos testes feitos no Colab.

Será possível ver pelos, por exemplo, códigos dos testes do Colab que há outras bibliotecas sendo utilizadas para a ambientação em nuvem, como o Ngrok, que não foram utilizadas na versão final do código

3.2. Testes de métodos/funções

Os arquivos contidos na pasta de testes, fora da pasta de testes do Colab, são testes relacionados à criação de métodos/funções para o código.

Utilizei do princípio Test-Driven Development (TDD) para o desenvolvimento deste repositório, consistindo onde os testes são escritos antes dos métodos/funções e que funciona em um ciclo curto e repetitivo, conhecido como Red-Green-Refactor.

3.2.1. Pytest

Para botar em prática o TDD, utilizei a biblioteca Pytest para a criação dos testes. Todos os testes tem o objetivo de testar lógicas dos métodos para que garanta, se houver retorno, o retorno dos valores corretos por aquele método.