ARI — Um Sistema Universal de Automação de Pesquisa que Funciona de Laptop a Supercomputador

Introdução

A ideia de automatizar a pesquisa não é nova. Desde o AI Scientist v2 da Sakana AI, houve muitas tentativas de entregar todo o processo de pesquisa a agentes LLM. Mas, na prática, esses sistemas exigem um orçamento de nuvem, uma equipe de engenharia interna ou ferramentas específicas de domínio — tornando-os ferramentas para poucos que já possuem recursos.

ARI (Inteligência Artificial de Pesquisa) é um sistema de automação de pesquisa de código aberto projetado para derrubar essa barreira. Ele funciona de forma idêntica em uma instância local do Ollama em seu laptop e em um cluster de supercomputador SLURM com APIs comerciais — usando um único arquivo Markdown. O núcleo não contém nenhum conhecimento de domínio codificado; cada decisão é tomada pelo LLM em tempo de execução. Esse design significa que o mesmo pipeline pode lidar com benchmarks de desempenho HPC, ajuste de hiperparâmetros de ML e — em princípio — otimização química.

Neste artigo, vou apresentar o design do sistema e percorrer um verdadeiro artigo de análise de desempenho SpMM de 11 páginas que o ARI produziu com zero intervenção humana.

• Página inicial do projeto: https://kotama7.github.io/ARI/
• GitHub: https://github.com/kotama7/ARI

Resumo em 3 Linhas

• Entrada: Um arquivo Markdown descrevendo seu objetivo de pesquisa (mínimo 3 linhas)
• Saída: Código de experimento, dados medidos, figuras, artigo em LaTeX, revisão por pares e relatório de verificação de reprodutibilidade
• Ambiente: Alterna sem problemas entre laptop (Ollama local) e cluster HPC (SLURM + API comercial) com o mesmo arquivo de experimento

Versão atual: v0.4.1 (lançada em 2026-04-08). Inclui um painel web de 9 páginas em React/TypeScript, 14 habilidades MCP e documentação em 3 idiomas.

Por que ARI — Democratizando a Automação de Pesquisa

A automação de pesquisa historicamente exigiu:

• Orçamentos de nuvem caros
• Equipes de engenharia internas
• Ferramentas específicas de domínio que não se generalizam

ARI é construído em uma única afirmação: a distância entre "Eu tenho uma ideia" e "Eu tenho resultados" deve ser medida em horas, não meses — independentemente dos seus recursos.

O sistema escala ao longo de 5 eixos com uma única base de código unificada:

O arquivo de experimento mínimo é realmente apenas isso:

# Otimização de Multiplicação de Matrizes
## Objetivo da Pesquisa
Maximizar GFLOPS de DGEMM nesta máquina.
<!-- metric_keyword: GFLOPS -->

A partir deste objetivo de 3 linhas, o ARI executa pesquisa → geração de hipótese → implementação → execução → geração de figuras → redação de artigo → verificação de reprodutibilidade de ponta a ponta.

Arquitetura — "experiment.md → artigo + relatório de verificação"

experiment.md ──► ARI Core ──► resultados + artigo + relatório de reprodutibilidade
                      │
          ┌───────────┼──────────────────────┐
          │           │                      │
     BFTS Engine   ReAct Loop         Post-BFTS Pipeline
  (Busca de Árvore   (agente por nó)   (driven por workflow.yaml)
   de Melhor Primeiro)        │
                  MCP Skill Servers
                  (sistema de plugins)

O núcleo do ARI possui três camadas:

• Motor BFTS (Busca de Árvore de Melhor Primeiro) — explora o espaço da hipótese de forma orientada por evidências, não exaustivamente
• Ciclo ReAct — agente LLM executando por nó: raciocínio → chamada de ferramenta → observação
• Servidores de habilidades MCP — ferramentas puramente funcionais implementadas via Protocolo de Contexto de Modelo (submissão de trabalho HPC, geração de artigo, geração de figuras, etc.)

Após a conclusão do BFTS, o Pipeline Pós-BFTS definido em workflow.yaml executa extração de dados → geração de figuras → redação de artigo → revisão por pares → verificação de reprodutibilidade automaticamente.

Fluxo de Dados de Ponta a Ponta (10 Passos)

1. Pesquisa — buscar trabalhos relacionados no arXiv / Semantic Scholar
2. Geração de hipótese — deliberação multi-agente estilo VirSci determina hipóteses, métricas-chave e critérios de avaliação
3. Busca em árvore — BFTS expande nós candidatos em ordem de prioridade
4. Execução do experimento — agente ReAct gera, compila e executa código por nó (polling automático até que o trabalho SLURM seja concluído)
5. Avaliação de revisão por pares — LLMEvaluator atribui scientific_score (0.0–1.0)
6. Análise em toda a árvore — Transform skill BFS atravessa a árvore para extrair insights de hardware/método/ablação
7. Geração de figuras — O skill de plotagem do LLM escreve código matplotlib e gera figuras em PDF
8. Redação de artigo em LaTeX — O skill de artigo gera um artigo completo com citações BibTeX
9. Revisão por pares do artigo — O LLM atua como árbitro e pontua o artigo
10. Verificação de reprodutibilidade — Um agente ReAct separado lê apenas o texto do artigo, re-executa o experimento e verifica os valores reivindicados em relação às medições reais

O passo 10 merece destaque: o agente de reprodutibilidade lê apenas o artigo — sem acesso à configuração original do experimento. Isso verifica se os métodos descritos no artigo são realmente suficientes para reproduzir os resultados. Esta é uma verificação que a revisão por pares humana não pode realizar realisticamente.

O Design Central — Princípio de Zero Conhecimento de Domínio

Ao ler o código-fonte do ARI, você notará algo: ari-core não contém palavras-chave específicas de domínio para HPC, ML, química ou qualquer outra coisa. Isso não é acidental — é um invariante de design imposto na revisão de código.

O núcleo especifica apenas três coisas:

• Formato: chamadas de ferramenta em JSON, descrições de experimento em Markdown
• Protocolo: comunicação de habilidades via MCP
• Sinal: classificação BFTS via scientific_score atribuído pelo LLM (0.0–1.0)

Tudo o mais — o que medir, o que comparar, quais informações de hardware importam, quais figuras desenhar, quais citações incluir — é determinado autonomamente pelo LLM em tempo de execução.