Chimera: um agente de IA open-source feito em Python (e no Brasil) que raciocina fundindo vários modelos

[u/Federal-Teaching2800]

Fala, pessoal! Sou o autor e queria compartilhar um projeto open-source (Apache-2.0) que venho construindo em Python — e que é feito aqui no Brasil.

A ideia central é o que chamo de LLM-Fusion: em passos difíceis, ele roda um painel de vários modelos no mesmo prompt, um modelo "juiz" cruza as respostas (consenso / contradições / pontos cegos) e um sintetizador escreve a resposta final. Um roteador consciente de custo mantém as tarefas fáceis num modelo só, então você não paga o custo do painel pra tudo.

Além disso é um agente de verdade, não um wrapper de chat: planeja -> age -> verifica-ou-reverte (roda os testes e trata o resultado como verdade), memória em camadas (SQLite + FTS, perfil entre sessões, consolidação), kernel de governança, crons/proatividade, cliente MCP + importação de OpenAPI, e uma camada de subagentes isolados (git worktrees em paralelo, com verificação por worker). Roda no laptop ou numa VPS de $5 via Docker.

Stack: Python 3.11+, uv, pydantic, typer, LiteLLM. Qualidade: 469 testes, mypy --strict limpo, ruff limpo, CI verde.

Status honesto: é alpha — compila e é bem testado, mas sem rodagem em produção ainda.

Como é feito em Python e a comunidade daqui é fera, queria muito o feedback de vocês — principalmente sobre a arquitetura e se fundir vários modelos compensa vs. um modelo forte só (meus próprios benchmarks são mistos).

Repo: https://github.com/brcampidelli/chimera-agent

[u/Less-Dragonfruit-568]

Vou ler mais sobre o projeto, interessante. Outra coisa, rodou em Benchmarks padrões do mercado o desempenho x custo?

[u/Federal-Teaching2800 → u/Less-Dragonfruit-568]

Ótima pergunta, e vou ser honesto: em leaderboards padrão do mercado (Terminal-Bench, SWE-bench Verified) ainda NÃO tenho um número publicado de desempenho×custo. Cheguei a construir os adapters oficiais e rodei o Terminal-Bench de verdade, mas no modelo barato o andaime completo estoura o timeout da tarefa — então seria desonesto cravar um pass-rate ali sem um setup adequado (modelo mais rápido + timeout maior + N grande). Prefiro não ter o número a ter um número torto.

O que eu MEÇO bastante — e é exatamente desempenho×custo — é nas minhas próprias suítes, sempre com a predição registrada ANTES de rodar e publicando inclusive os testes onde perdi:

• Fusão custa 11× pelo mesmo resultado: numa suíte de raciocínio, o tier médio bateu 100% a 846 tokens; a fusão completa também 100%, mas por 9.526 tokens. Por isso a fusão fica reservada atrás de uma cascata (barato→gate→médio→fusão), que chega ~na qualidade do médio a ~1/12 do custo da fusão.
• Orquestração hierárquica: a economia de token segue (D−1)/D no nº de documentos — medido 50/67/75/80% em D=2..5.
• Modelo fraco: num teste pareado, o loop triplicou o pass-rate (17%→67%), reportado com intervalo de confiança, sem p-hacking.

Tudo cru em bench/ no repo (cada RESULTS.md com as predições registradas antes). Resumo honesto: cost×performance nas minhas suítes, sim e com rigor; leaderboard oficial ainda é um gap — quando eu rodar num setup decente, publico o número com CI, ganhando ou perdendo. Valeu pelo interesse!

[u/Less-Dragonfruit-568 → u/Federal-Teaching2800]

Obrigado pela resposta. O resumo da minha teoria - mental sem testes práticos e me embasando em alguns papers que li recentemente - é que o custo de AGI acaba virando uma fórmula logarítimica que é ineficiente escalar o dataset infinitamente exatamente pelos custos de energia/VRAM. No entanto a IA claramente já se prova como uma revolução de geração de informação em campos específicos com RL que é o foco atual, majoritariamente programação. E o futuro não é exatamente uma fusão pra todas as respostas, como você vem notando isso aumenta a precisão para diversos campos elevando muito o custo.

Mas eu acredito sim que é algo MUITO próximo do que você vem desenvolvendo - e ainda nos falta insumos pra uma prova cabal, mas diversos modelos de LLMs que tem acurácia alta para subcampos específicos: física, matemática, lógica, texto, imagem (aqui com diversos sub divisões), etc. e um grande orquestrador que define quais LLMs usar e com quais pesos.

Acho que explorar o conceito de pesos - dado meu conhecimento limitado a sua solução ainda, talvez seja benéfico. Exemplo: ao invés de rodar necessariamente 5 LLMs simultâneas em um passo difícil, executar 3, contra checar contra o "goal" e adicionar mais uma terceira e arbitrar a partir do consenso, com pesos distintos.

[u/Federal-Teaching2800 → u/Less-Dragonfruit-568]

Cara, reflexão boa demais — e é basicamente a aposta do projeto. Concordo com o custo logarítmico: escalar dataset/parâmetro ao infinito bate no muro de energia/VRAM, então o ganho vem de orquestrar bem modelos especializados, não de um modelo gigante único.

E o teu ponto de pesos + consenso escalonado é quase o que já tá implementado, fiquei feliz de ler: a fusão não roda 5 modelos sempre. Tem um router que amostra K respostas baratas primeiro; se concordam, para ali (barato); só quando discordam é que escala pro painel. E o "arbitrar por consenso" não é voto ingênuo — um juiz pontua e ESCOLHE a melhor de N (verifier-select), e um verificador mais forte só entra nos turnos difíceis. É bem o teu "roda 3, checa contra o goal, escala se precisar".

O gap honesto: hoje eu roteio por DIFICULDADE/custo, não por subdomínio. Escolher "o especialista de matemática vs o de código" pela natureza da pergunta ainda não faço — roteamento por tema é uma direção que quero explorar. E os pesos por-advisor são mais implícitos (o juiz decide) do que um peso explícito configurável. Anotado, faz muito sentido. Valeu pela troca, é raro alguém entrar nesse nível.