Arquitetura para Avaliação de LLMs: Desafios, Dados e Decisões

O objetivo deste artigo é descrever os principais aprendizados do projeto de benchmarking de modelos de Large Language Models (LLMs). Também abordaremos detalhes sobre as decisões de arquitetura e desafios metodológicos. Previamente temos uma constatação importante: avaliar modelos de LLMs é hoje um problema tão complexo quanto utilizá-los em produção.

Nos últimos anos, a explosão de Large Language Models (LLMs) inundou o mercado com opções. Hoje temos modelos proprietários, como os oferecidos por OpenAI e Gemini, além de uma crescente comunidade de modelos open-source executados localmente com ferramentas como Ollama. No ambiente de um laboratório de inovação, a pergunta não é ‘se’ usamos IA, mas ‘como’ validamos rapidamente o que realmente funciona para o cidadão.

Qual modelo é o melhor para o meu caso de uso?

Para isso, desenvolvemos um pipeline automatizado de benchmarking de LLMs. A plataforma submete múltiplos modelos, de GPT-4 a Llama local, a um mesmo conjunto de testes paralelos. O sistema coleta métricas como tokens, latência e taxa de alucinação e avalia respostas com critérios pré-definidos, consolidando os resultados em dashboards analíticos que geram evidências técnicas sobre assertividade, custo e segurança. A solução foi construída utilizando:

• • Nuxt 3 + Vue 3

• • Node.js com runtime Nitro

• • TypeScript

• • PostgreSQL

• • Prisma ORM

• • LangChain

O objetivo foi avaliar diferentes dimensões do comportamento dos modelos, incluindo algumas métricas como; compreensão textual, raciocínio lógico, conhecimento jurídico, comportamento em cenários de RAG, geração de código e outras.

Arquitetura da Plataforma de Benchmarking

A aplicação foi construída como uma arquitetura full-stack tipada, onde frontend e backend compartilham o mesmo repositório e a mesma base de tipos em TypeScript. Essa abordagem reduz inconsistências entre camadas e acelera o desenvolvimento.

Frontend (Nuxt 3 + Vue 3 + EChar): O frontend foi desenvolvido com Nuxt 3 e Vue 3, focado na visualização analítica dos resultados dos benchmarks. A biblioteca ECharts permite criar gráficos interativos capazes de cruzar variáveis como taxa de acerto, custo de tokens e incidência de alucinação. A Composition API do Vue 3 facilita a organização de componentes e a reutilização de lógica, bom para iterar rapidamente na interface de análise.

Backend (Nitro Runtime): O backend foi implementado utilizando Nitro, o runtime server do Nuxt. Essa camada funciona como orquestrador dos experimentos, responsável por executar prompts nos modelos, coletar respostas, acionar os avaliadores e persistir resultados. O Nitro traz vantagens como serverless-ready, cold start rápido e rotas backend simples, permitindo que a aplicação funcione como um backend leve para orquestrar execuções de benchmark.

Integração com LLMs (LangChain): Para integrar diferentes provedores de modelos de linguagem, foi utilizado o LangChain, que funciona como uma camada de abstração e orquestração para interação com LLMs. A biblioteca oferece interfaces padronizadas para chamadas de modelos, permitindo trabalhar com provedores distintos, sem alterar significativamente a lógica da aplicação.

Persistência (PostgreSQL + Prisma ORM): Os resultados são armazenados em PostgreSQL, com Prisma ORM gerenciando a camada de persistência. O PostgreSQL foi escolhido pela sua robustez, excelente suporte a consultas analíticas e campos JSON, úteis para armazenar respostas estruturadas de LLMs. O Prisma oferece tipagem automática para queries, migrações simplificadas e integração nativa com TypeScript.

TypeScript em vez de Python: Pode parecer contra intuitivo usar TypeScript em um projeto de IA, onde Python é o padrão. No entanto, o foco deste projeto não foi treinar modelos, mas sim orquestrar, avaliar e visualizar o uso deles. A escolha por TypeScript foi por três motivos principais. Primeiro, a unificação full-stack permite que frontend e backend compartilhem os mesmos tipos, eliminando inconsistências de dados entre a interface e a API. Segundo, a segurança de tipos é crítica para benchmarking, onde a estrutura de prompts e métricas deve ser rigorosamente validada. Terceiro, o ecossistema JavaScript lida nativamente com operações assíncronas e streaming de respostas, essenciais para uma experiência de usuário fluida. O LangChain em JavaScript ofereceu a abstração necessária para integração dos modelos.

Banco de dados

A avaliação de modelos de LLMs gera uma quantidade grande de dados, tais como: prompts enviados, respostas geradas, contagem de tokens, métricas derivadas e embeddings vetoriais. Para lidar com esse volume, utilizamos o PostgreSQL como motor analítico central. Já o Prisma ORM, foi responsável por acelerar o desenvolvimento, gerando automaticamente tipos TypeScript a partir do schema do banco. Isso eliminou grande parte do trabalho manual de validação de estruturas de dados. Além do mais, os cálculos analíticos mais complexos, utilizamos o SQL nativo do PostgreSQL. 

Vetores e Testes de RAG

Para avaliar modelos em cenários de Retrieval-Augmented Generation (RAG) foi utilizada a extensão pgvector do PostgreSQL. Isso permitiu armazenar embeddings diretamente no banco e realizar buscas semânticas utilizando consultas de similaridade vetorial. O benchmark então executa um fluxo simples:

1. Recupera documentos relevantes por similaridade vetorial
2. Envia esses documentos como contexto ao modelo
3. Avalia se a resposta realmente utilizou esse contexto

Caso o modelo invente informações que não estavam presentes nos documentos recuperados, o sistema registra esse comportamento como alucinação factual.

O desafio: avaliar as respostas dos modelos

Imagine um benchmark com 500 perguntas, que devem ser respondidas por 10 modelos de LLMs. Isso gera 5.000 respostas em texto livre. Cada resposta precisa ser classificada como:

• correta
• parcialmente correta
• incorreta
• alucinação

Fazer isso manualmente com poucos recursos e prazos é inviável. Para resolver esse problema foi adotada uma abordagem cada vez mais comum em pipelines de IA.

LLM-as-a-Judge

O padrão LLM-as-a-Judge consiste em utilizar um segundo modelo para avaliar as respostas geradas pelo modelo testado. O avaliador recebe três elementos:

• a pergunta original
• o gabarito correto
• a resposta produzida pelo modelo testado

Com base nesses três elementos, ele gera uma classificação estruturada indicando se a resposta está correta, incorreta ou constitui uma alucinação. Para garantir consistência, o sistema exige que o avaliador retorne a resposta em JSON estruturado, validado automaticamente no backend. Essa abordagem permite transformar um processo manual extremamente custoso em um pipeline automatizado capaz de avaliar milhares de respostas em minutos.

Avaliação de Código Gerado por IA

Um dos testes mais interessantes do benchmark avalia a capacidade dos modelos de gerar código executável. Nesse cenário, o modelo recebe um problema computacional e precisa produzir um script capaz de resolvê-lo. O pipeline funciona em duas etapas. Primeiro o código gerado é executado em um ambiente isolado. Caso o script falhe, a resposta recebe nota zero. Quando o código executa corretamente, um segundo processo analisa se a lógica implementada realmente resolve o problema. Executar código gerado por IA é um risco de segurança significativo. Para mitigar esse problema foi criado um sandbox utilizando Bun, onde o código roda em um processo isolado com acesso restrito ao ambiente do servidor.

Stack Moderna

Uma das percepções mais interessantes desse projeto foi a velocidade com que o sistema evoluiu. Isso aconteceu motivado pela tipagem end-to-end com TypeScript e Prisma, convenções e automações do Nuxt e abstração de provedores via LangChain. Essa combinação permitiu que os esforços de desenvolvimento fossem direcionados para contrução das métricas, datasets e avaliação de modelos.

Conclusão

Grande parte dos esforços no projeto foram concentrados na curadoria de datasets, segurança de execução e na análise do comportamento não determinístico das IAs. Avaliar modelos de forma sistemática e orientada a dados será um dos pilares da engenharia de IA nos próximos anos. Plataformas de benchmarking como essa ajudam a transformar experimentação em decisão técnica baseada em evidência, algo essencial para qualquer organização que queira utilizar IA de forma responsável e eficiente.