Modelo de IA no produto: tarefa estreita, fonte visível e saída conferida

O suporte ligou um modelo de linguagem ao campo "Descreva seu problema" e, na primeira semana, ele respondeu a um cliente que o prazo de devolução era de 30 dias. A política da loja é de 7. Ninguém escreveu 30 em lugar nenhum; o modelo completou a frase mais provável. A resposta curta: um modelo de linguagem gera texto plausível, não consulta a verdade. Ele é útil quando a tarefa é estreita, quando a saída tem formato conferível por código e quando a pessoa vê de onde veio a informação. O que não passar na conferência vai para um humano.

O exemplo deste guia é o mesmo suporte da loja: classificar chamados em categorias e sugerir uma resposta baseada nos textos de política que a loja já tem, com cada etapa conferida antes de chegar ao cliente.

Por que o modelo inventa com confiança

Um modelo de linguagem foi treinado para prever a próxima palavra a partir de uma quantidade enorme de texto. Quando você pergunta o prazo de devolução, ele não abre a sua política: ele produz o que costuma vir depois de perguntas parecidas. Em muitas lojas, 30 dias é comum, então 30 sai com a mesma fluência que sairia a resposta certa. O tom seguro não é sinal de acerto.

Ele também não sabe o que aconteceu depois do treino, nem o que está no seu banco, a menos que você coloque essa informação no pedido. E a mesma pergunta pode receber respostas diferentes em chamadas diferentes. Se a resposta muda entre duas tentativas, aquele dado não está vindo de uma fonte, está sendo gerado.

Onde um modelo cabe e onde não cabe

Cabe bem em tarefas em que errar é barato e conferir é possível: resumir um texto que você já tem, classificar um pedido entre categorias que você definiu, extrair campos de um e-mail para um formulário que alguém revisa, sugerir um rascunho de resposta. Em todas elas, a fonte é um texto seu e a saída pode ser checada.

Não cabe decidir sozinho crédito, diagnóstico de saúde, prazo legal ou qualquer coisa que gere obrigação para a empresa. Nesses casos, o modelo pode no máximo preparar material para quem decide.

Como colocar o modelo no fluxo do suporte

1. Defina a tarefa em uma frase: "classificar o chamado numa das seis categorias e sugerir resposta usando só os trechos de política enviados".
2. Escolha os trechos da sua base que se aplicam (por busca ou pela categoria) e envie junto, cada um com um id.
3. Peça a saída num formato fixo, como JSON com campos conhecidos, e diga que ela deve citar o id do trecho usado.
4. Valide a saída por código: JSON válido, categoria dentro da lista, trechos citados existindo entre os enviados.
5. O que falhar na validação vai para a fila humana, sem resposta automática.
6. Mostre ao atendente a sugestão junto com o trecho citado, e registre a versão do prompt e o resultado.

A validação que separa sugestão de invenção

O código abaixo não depende de fornecedor. A função chamarModelo é a sua integração (uma API comercial ou um modelo aberto rodando na sua máquina, como os publicados no Hugging Face) e devolve o texto gerado. Todo o resto é JavaScript comum.

const CATEGORIAS = ['entrega', 'devolucao', 'pagamento', 'produto', 'conta', 'outro'];

function montarPedido(chamado, trechos) {
  const fontes = trechos.map(t => '[' + t.id + '] ' + t.texto).join('\n');
  return [
    'Classifique o chamado numa destas categorias: ' + CATEGORIAS.join(', ') + '.',
    'Sugira uma resposta usando somente os trechos abaixo.',
    'Se os trechos não respondem, use "fontes": [] e "resposta": "".',
    'Responda só com JSON: {"categoria": "...", "resposta": "...", "fontes": ["id"]}',
    '',
    'Trechos:',
    fontes,
    '',
    'Chamado:',
    chamado.texto
  ].join('\n');
}

function validar(saidaTexto, trechos) {
  let saida;
  try {
    saida = JSON.parse(saidaTexto);
  } catch {
    return { ok: false, motivo: 'json_invalido' };
  }
  if (!CATEGORIAS.includes(saida.categoria)) {
    return { ok: false, motivo: 'categoria_fora_da_lista' };
  }
  const idsEnviados = new Set(trechos.map(t => t.id));
  const fontes = Array.isArray(saida.fontes) ? saida.fontes : [];
  if (saida.resposta && fontes.length === 0) {
    return { ok: false, motivo: 'resposta_sem_fonte' };
  }
  if (fontes.some(id => !idsEnviados.has(id))) {
    return { ok: false, motivo: 'fonte_inexistente' };
  }
  return { ok: true, saida };
}

async function sugerir(chamado, trechos, chamarModelo) {
  const texto = await chamarModelo(montarPedido(chamado, trechos));
  const resultado = validar(texto, trechos);
  if (!resultado.ok) {
    return { destino: 'fila_humana', motivo: resultado.motivo };
  }
  return { destino: 'atendente_revisa', ...resultado.saida };
}

No caso dos 30 dias: com o trecho "[pol-07] Devoluções são aceitas em até 7 dias corridos após o recebimento" enviado, a sugestão correta cita pol-07. Se o modelo responder 30 dias citando pol-07, a validação passa, mas o atendente vê o trecho ao lado e percebe a contradição. Se responder sem citar nada, cai em resposta_sem_fonte e vai para a fila. A validação não garante que a resposta está certa; ela garante que toda resposta aponta para um texto que alguém pode conferir.

Uma conferência extra barata para campos numéricos: extraia os números da resposta e veja se cada um aparece nos trechos citados. "30" não aparece em pol-07, e isso basta para mandar à fila.

Dados do cliente, tempo de resposta e transparência

Antes de mandar o texto do chamado para um serviço externo, saiba o que o serviço guarda, por quanto tempo e se usa para treino. Chamado de suporte costuma ter nome, endereço, CPF e número de pedido. Remova o que a tarefa não precisa e registre essa decisão; o guia de adequação à LGPD em sistema pequeno ajuda a organizar isso. Nos seus próprios logs, guarde a versão do prompt, a categoria e o motivo da recusa, não o texto pessoal inteiro, como explica o post sobre log sem dado sensível.

Chamada a modelo pode demorar ou travar. Coloque um prazo e, se estourar, o chamado segue para a fila humana normalmente; o post sobre timeout antes do infinito mostra como escolher esse prazo. E se algum texto gerado chegar ao cliente, diga que ele foi gerado e revisado. Esconder isso transforma um erro do modelo num erro de confiança da empresa.

Erros comuns

• Deixar o modelo responder sem fonte. Ele preenche a lacuna com o que é comum em outros lugares, e a política da sua loja vira a de outra.
• Aceitar texto livre onde o sistema espera um valor. Uma categoria escrita de um jeito novo quebra o relatório ou cai no lugar errado em silêncio.
• Mandar dado pessoal sem saber o que o serviço guarda. O chamado do cliente passa a morar num lugar que você não controla.
• Não registrar a versão do prompt. Quando a qualidade cai, você não sabe se mudou o modelo, o prompt ou os trechos.
• Usar o modelo para decidir o que gera obrigação. Prazo, reembolso e crédito decididos por texto gerado viram promessa da empresa.
• Não ter caminho humano quando o modelo falha ou demora. O chamado fica parado esperando uma resposta que não vem.

Checklist

• A tarefa cabe numa frase e tem saída conferível por código.
• A saída tem formato fixo e é validada antes de ser usada.
• Toda resposta cita um trecho que foi realmente enviado.
• O que falha na validação vai para uma pessoa, não para o cliente.
• Há prazo máximo para a chamada ao modelo e um caminho quando ele estoura.
• Você sabe o que o serviço guarda dos dados enviados.
• Logs registram versão do prompt e motivo da recusa, sem dado pessoal desnecessário.

Faça agora o teste mais simples que existe: pegue um chamado real (anonimizado) e mande a mesma pergunta factual ao seu modelo três vezes. Se o número ou o prazo mudar entre as respostas, o modelo não é a fonte daquele dado. Na sua integração de hoje, quem confere a saída antes de ela chegar ao cliente?