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:
| Pergunta | Tipo | O que mede |
|---|---|---|
grounded | Sim ou não | A resposta se apoia nas fontes? |
data_leak | Sim ou não | A resposta expõe dados pessoais ou internos? |
policy | Escolha | compliant, promise, advice ou off_topic |
harmful | Sim ou não | Há conteúdo nocivo? |
E as políticas transformam as respostas em ação:
| Condição | Ação |
|---|---|
data_leak com 50% ou mais | block |
harmful com 50% ou mais | block |
grounded abaixo de 50% | fallback (por exemplo, responder com um texto seguro ou pedir mais contexto) |
policy diferente de compliant | escalate (revisão humana) |
| Nada disso | continue: 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 ] → clienteAs 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
| Momento | Pergunta | Ação típica |
|---|---|---|
| Antes do LLM | Para onde vai esta mensagem? Precisa de um LLM? | Rotear, responder direto ou chamar o modelo |
| Depois do LLM | Esta 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.