2

Eu tenho a seguinte visão de agentes de IA: São a interface probabilística de interação com a camada determinística. Em outras palavras: é o novo "teclado", ou novo "navegador", ou novo "touchscreen". É só uma interface. Poderosa, mas só interface.

Se delegarmos regras de negócio para a interface decidir, o resultado pode ser caótico.

Agora, o ponto que vc abordou, da amarração das regras de forma rígida, é onde o desenvolvedor (no sentido mais amplo da palavra, quem está concebendo) deverá ajustar a régua. Não é um determinístico VS probabilístico. É pra qual lado a balança pesa mais (falei igual IA agora kkkkk)

Vou dar um exemplo concreto para não ficar abstrato:

Ao desenvolver um agente de agendamentos o mesmo alucinava com a agenda correta (qual id?), com o horário correto (qual horário?), com o profissional correto (qual profissional?).

Minha solução: amarrei no backend, com base em interações do usuário, um novo ID que representava diversos outros IDs por baixo dos panos.

Ex.: ID "s_124" representava {agenda: 'ac5697eb-d692-4835-8dac-c84d14105b7b', horario: '2026-07-21T14:00:00.000Z', profissional: 'c152bbd4-f1d8-481e-8ca4-08c4b1c2b661', servicos:['c2fba37e-42ba-4931-b4f5-fdc1ed301b1c']}

Agora imagina uma lista de 40 slots de horário por dia, na janela de 1 semana para o usuário escolher! Alucinação garantida, pelo excesso de dados.

E de quebra economizei muito token.

Aqui a decisão probabilística foi resumida a um único id, que deterministicamente foi mapeado para diversas decisões internas.

Parabéns pelo artigo!

Carregando publicação patrocinada...
1

Que comentário bom — você pegou o mesmo princípio e me deu um enquadramento melhor que o meu. "Interface probabilística pra camada determinística" é uma forma mais limpa de dizer a mesma coisa: o LLM é a ponte, não o cofre. (falei igual IA também KKKK cada vez mais difícil separar)

E o "pra qual lado a balança pesa" é o pulo do gato. Não é dogma determinístico vs probabilístico — é calibrar a régua por caso. Concordo 100%.

O teu exemplo do s_124 é a melhor parte, e acho algo a mais que o meu artigo: eu tirei a execução das mãos do LLM; você tirou também a complexidade da escolha. Em vez de deixar o modelo garimpar entre 4 IDs × 40 slots × 7 dias (mar de tokens = alucinação garantida), você colapsou tudo num único ID opaco que o backend remapeia deterministicamente.

Isso reduz o que a literatura chama de action space do agente — quanto menor o leque de decisão que você entrega ao LLM, menos ele tem onde errar. E o bônus de token é consequência direta: menos opções no contexto, menos custo.

Resumindo os dois padrões que saíram daqui:

  • Propõe/dispõe → o LLM não executa a ação.
  • Teu s_124 → o LLM nem enxerga a complexidade da escolha; decide sobre um símbolo, não sobre os dados crus.

Vou guardar esse exemplo (anonimizado, se você deixar) — é didático demais pra não virar referência. Valeu pela contribuição de verdade. 👏