Blog

Antes e depois do LLM: o Dcision como guardrail da resposta de um agente

3 min de leitura

O jeito mais comum de usar o Dcision é antes do LLM: uma decisão tipada classifica a mensagem, escolhe a rota e só chama um modelo gerador quando ele é mesmo necessário. Essa decisão custa uma fração de uma chamada de LLM e devolve uma probabilidade junto com a resposta.

Existe um segundo lugar em que a mesma ideia vale: depois do LLM. Um agente acabou de escrever uma resposta. Antes de ela chegar ao cliente, alguém precisa perguntar: isso pode ser enviado?

O problema da resposta gerada

Um LLM escreve bem, mas nem sempre escreve certo. Os riscos mais comuns numa resposta de atendimento ou de um agente são:

  • Falta de fundamentação: a resposta afirma algo que não está nas fontes que o agente recebeu.
  • Vazamento de dados: aparece um e-mail, um documento ou um dado interno que não deveria sair.
  • Promessa indevida: um desconto, um prazo ou um reembolso que ninguém aprovou.
  • Conteúdo nocivo ou fora do tema.

Pedir para outro LLM "revisar" a resposta gera mais texto, e o texto ainda precisa ser interpretado pelo seu código. O que você quer é uma resposta tipada, com probabilidade, e uma ação.

O template "Guardrail de saída de LLM"

O novo template recebe três campos: a mensagem do usuário, a resposta gerada e as fontes que o agente usou. Ele faz quatro perguntas:

PerguntaTipoO que mede
groundedSim ou nãoA resposta se apoia nas fontes?
data_leakSim ou nãoA resposta expõe dados pessoais ou internos?
policyEscolhacompliant, promise, advice ou off_topic
harmfulSim ou nãoHá conteúdo nocivo?

E as políticas transformam as respostas em ação:

CondiçãoAção
data_leak com 50% ou maisblock
harmful com 50% ou maisblock
grounded abaixo de 50%fallback (por exemplo, responder com um texto seguro ou pedir mais contexto)
policy diferente de compliantescalate (revisão humana)
Nada dissocontinue: a resposta pode ser enviada

O exemplo do template mostra o caso clássico: o agente promete "20% de desconto pelo atraso", mas as fontes dizem que descontos precisam da aprovação de um gerente. O guardrail aponta a promessa e a decisão escala para uma pessoa em vez de deixar a mensagem sair.

Onde ele entra no fluxo

mensagem → [ Dcision: rota ] → LLM ou agente → [ Dcision: guardrail ] → cliente

As duas decisões são chamadas comuns da API. A do guardrail recebe a resposta gerada como estado e devolve action. O seu código só precisa olhar esse campo: continue envia, block descarta, escalate abre revisão e fallback usa a resposta segura.

Como qualquer decisão do Dcision, o guardrail tem versões, Playground, registro de cada execução e a aba Visão geral. Dá para ver quantas respostas foram barradas, por qual regra, e calibrar os limites com dados. Com os destinos, a ação pode virar um webhook para a fila de revisão ou uma função no seu SDK, sem código de cola.

Qual motor usar

O guardrail roda em qualquer um dos três motores: Jev, Laya ou OpenAI Decisions. Use Comparar motores no Playground para ver como cada um avalia as suas respostas de exemplo. Depois, ligue o modo sombra para medir a concordância no tráfego real antes de escolher.

Resumo

MomentoPerguntaAção típica
Antes do LLMPara onde vai esta mensagem? Precisa de um LLM?Rotear, responder direto ou chamar o modelo
Depois do LLMEsta resposta pode ser enviada?Enviar, bloquear, escalar ou usar a resposta segura

O LLM gera. O Dcision decide o que fazer com o que foi gerado. Crie a decisão em Templates → Guardrail de saída de LLM.