Imagina você rodar modelos locais com a mesma qualidade dos grandes modelos de API? essa e a ideia que estou construindo!

Minha tese é simples: especialistas sob demanda vencem generalistas inchados. Em vez de carregar um Frankenstein de 70B parâmetros para “fazer tudo”, eu mantenho um modelo base compacto residente em VRAM e plugo experts leves (LoRA/DoRA/IA³) só quando a tarefa pede. Isso roda em GPU de consumo (8–16 GB), carrega adapters em milissegundos e mantém contexto longo sem custo absurdo. Não é MoE; é composição dinâmica em runtime, com um roteador heurístico que aciona 1–10 experts por consulta.

O porquê

Modelos gigantes custam caro, são lentos e erram com confiança. Especialistas, por outro lado, assumem responsabilidade limitada, com saídas auditáveis e comportamento previsível. A proposta do Expert System nasceu para isso: inference especializada em hardware comum, sem fundir nada no base — cada expert é um pacote pequeno, versionado e distribuível.

O que muda na prática

  • Velocidade e foco. Carrego só o que preciso, só no momento em que preciso. Sem inchá-lo de pesos desnecessários.

  • Evolução contínua. Posso adicionar experts novos sem re-treinar o mundo. Treinou, versionou, publicou, pronto.

  • Roteamento transparente. Regras claras (palavras-chave, embedding, escolha do usuário) decidem quais experts entram; nada de gating opaco típico de MoE.

  • Mercado de experts. Pacotes de 5–80 MB, plug-and-play, pensados para compartilhar e descobrir especialidades.

O que defendo

Chega de cassino de tokens. Quero controle, determinismo na saída e accountability por tarefa. Composição por consulta dá isso: cada expert entra com propósito, cada saída passa por validação, e eu sei por que aquilo foi gerado — e posso repetir amanhã.

Para quem isso serve

  • Times que precisam de qualidade estável (dados, busca, grafos, BI).

  • Produtos que exigem explicabilidade e auditoria.

  • Devs que querem performar em GPU doméstica sem sacrificar precisão.

Expert JSON
Não é sobre “inventar” estruturas; é sobre consertar e padronizar. Repara vírgulas, chaves, tipos óbvios e entrega JSON válido. Falha quando a transformação é profunda (mapear texto → schema → dados remodelados). Caminho: mais pares reais de transformação e validação rígida de saída.

Expert Neo4j
A regra é simples: schema primeiro. Com labels/propriedades no prompt, o Cypher vem redondo; sem mapa, vira palpite. Institucionalizei o “schema obrigatório” para grafos.

Expert Elastic
Estou afiando agora. Foco em Query DSL, mappings e KQL/EQL. Zero “prompt mágico”: quero instruções limpas, reprodutíveis e auditáveis. Elastic é precisão, não adivinhação.

Expert SQL
Dialetos contam (Postgres, MySQL, SQLite). O especialista prioriza SELECT seguro (modo read-only), sabe JOIN e GROUP BY sem gambiarras, respeita chaves/índices quando informados e evita DDL destrutivo. Próximo passo: variações por dialeto e checagens automáticas (lint + explain opcional) para queries mais longas.

O que aprendi
Composição por consulta funciona melhor que um generalista ansioso por agradar. Eu escolho o especialista, defino contexto, valido a saída. Sem messianismo de IA. Sem cassino de tokens. Só trabalho direito.

Repos (críticas e PRs bem-vindos)

Eu não busco “criatividade de IA”. Eu busco confiabilidade. E isso nasce de especialistas que fazem o necessário, no momento certo.