Live

Em produção desde jun. de 2026

Agente de IA para triagem de formulários de entrada

Agente de IA que lê formulários de entrada, gera um score e decide aprovação — com fallback humano quando o caso é ambíguo.

Período
jun. de 2026 em andamento
Papel
Solo
+1.500
forms/semana
15k+
casos de treino
0–1
score

#Contexto

O Brasil Capital Roleplay recebe um volume alto de formulários de entrada — jogadores que querem acesso ao servidor e precisam ser avaliados contra o que a comunidade preza. Feito à mão, isso significa uma equipe lendo texto livre, aplicando critério subjetivo e virando gargalo: o candidato espera, o avaliador cansa, e casos parecidos recebem decisões diferentes dependendo de quem leu.

O problema não era só velocidade. Era consistência: o mesmo formulário precisava ter a mesma resposta independentemente do horário ou de quem estava de plantão.

#O que o produto faz

  1. Lê o formulário enviado pelo candidato (texto livre, respostas abertas).
  2. Compara as respostas com o que a operação espera e considera aceitável.
  3. Gera um score de 0 a 1 representando a aptidão do candidato.
  4. Decide com base no score: aprova, reprova, ou encaminha para revisão humana quando fica na zona cinzenta.

#Arquitetura

Fluxo de triagem do formulárioO formulário entra por um webhook, passa pelo agente que consulta o LLM e as regras, gera um score, e é roteado para aprovação automática ou revisão humana.Formulário (entrada)Agente de triagemLLMRegras + históricoScore 0–1Auto-decisãoRevisão humana
Fluxo de triagem do formulário

#Decisões técnicas

Por que a IA não aprova sozinha todos os casos?

Porque o custo de um falso positivo é alto e assimétrico: aprovar quem não deveria entrar gera trabalho de moderação depois. O agente só decide sozinho nos extremos do score; a faixa ambígua cai para revisão humana. Sacrifiquei um pouco de automação total em troca de não terceirizar a responsabilidade da decisão de borda.

Por que um score contínuo de 0 a 1 em vez de um sim/não direto?

Um booleano esconde a incerteza. Com o score contínuo eu escolho onde colocar os cortes de aprovação e reprovação, e mexo neles conforme a operação fica mais ou menos rigorosa — sem retreinar nada. O custo é ter que definir e manter esses limiares.

Como garantir que a decisão siga o critério da operação, e não o 'bom senso' do modelo?

O agente foi calibrado com mais de 15 mil casos reais da própria operação, não com um prompt genérico. A régua é a da comunidade, não a do modelo. O trade-off é que a qualidade depende da curadoria desse histórico — lixo entra, lixo sai.

#O que deu errado

A primeira versão era rígida demais no corte: mandava muito caso para revisão humana, o que derrotava o propósito. O ajuste não foi mexer no modelo, e sim medir a distribuição real dos scores e recalibrar os limiares com base nela — a decisão certa quase sempre estava no dado, não no palpite.

#Resultado

  • Mais de 1.500 formulários triados por semana sem gargalo humano nos casos claros.
  • Decisão consistente: o mesmo formulário recebe a mesma resposta, independente do plantão.
  • Casos ambíguos preservados para o olhar humano, onde ele realmente agrega.

Stack

  • TypeScript
  • Node.js
  • LLM
  • PostgreSQL

Quer um resultado assim no seu produto?

Falar comigo