Decisões — quando usar um termo ou outro

A.Prompt (contexto no prompt)

Use o prompt quando o conhecimento é pequeno (cabe em algumas páginas), estável e igual para todos os usuários: regras de tom, formato de resposta, políticas curtas, exemplos de como responder. É a opção mais barata, mais rápida de mudar e que não exige nenhuma infraestrutura. Se uma regra muda, basta editar o texto e rodar o eval. O limite aparece quando o conteúdo cresce: cada chamada carrega tudo, o custo sobe e a qualidade cai em contextos longos.

B.RAG

Use RAG quando o conhecimento é grande, muda com frequência, varia por usuário ou cliente, ou precisa ser citado: contratos, manuais, base de tickets, políticas extensas. O RAG traz para o modelo só o trecho relevante a cada pergunta, respeita permissões de acesso e permite atualizar a base sem retreinar nada. Também permite mostrar a fonte ao usuário. É a abordagem certa para a maioria dos assistentes sobre conhecimento da empresa.

C.Fine-tuning

Use fine-tuning quando o que precisa mudar é o comportamento, o estilo ou o formato, e o prompt não consegue induzir isso de forma consistente; quando há jargão muito específico que o modelo não domina; ou quando o volume é alto e vale incorporar instruções ao modelo para encurtar o prompt. Fine-tuning não serve para “ensinar fatos”: fatos mudam, e o modelo esquece ou confunde. É a opção mais cara, mais lenta e mais difícil de reverter.

A.Copiloto

Use copiloto quando a pessoa executa e decide, e a IA sugere, resume ou rascunha. É a escolha certa quando o erro é caro, quando o contexto tácito da pessoa importa e quando o usuário quer manter o controle. O ganho é de velocidade individual: cada pessoa faz mais em menos tempo. Mas a vazão do processo continua limitada pela capacidade humana.

B.Agente

Use agente quando a IA decide o caminho (quais ferramentas usar, em que ordem) e executa, com uma pessoa supervisionando por exceção. É a escolha certa quando a tarefa é variável demais para um fluxo fixo e o erro é recuperável. O ganho é de vazão: o processo deixa de depender de uma pessoa em cada etapa. O custo é imprevisibilidade, mais consumo de tokens e necessidade de limites e monitoramento.

C.Automação (workflow)

Use automação (workflow) quando o fluxo é fixo, definido por pessoas, e o modelo entra em etapas específicas: classificar, extrair, redigir. É a escolha certa quando o processo é conhecido e repetitivo. É mais barato, previsível e testável do que um agente. A maioria dos casos de uso em produto cabe aqui.

A.Human-in-the-loop (HITL)

Use Human-in-the-loop quando a pessoa aprova antes de a ação valer: cada saída passa por revisão. É a escolha certa para ações irreversíveis, de alto valor, reguladas, ou enquanto a confiabilidade do sistema ainda não foi provada. Custa capacidade humana e limita a vazão. Se o volume cresce e a equipe não acompanha, a revisão vira carimbo.

B.Human-on-the-loop (HOTL)

Use Human-on-the-loop quando o sistema age e a pessoa monitora amostras, alertas e exceções, com poder de intervir. É a escolha certa para volume alto, erro recuperável e evals maduros. Exige observabilidade real, alertas bem calibrados e um kill switch acessível. A pessoa não aprova cada caso, mas precisa conseguir parar tudo em minutos.

C.Human-out-of-the-loop

Use Human-out-of-the-loop apenas quando não há ninguém no fluxo, só auditoria periódica. É aceitável para tarefas de baixo risco, alta confiabilidade comprovada e erro barato: classificação interna, sugestão não vinculante, organização de dados. Para tudo que afeta pessoas ou dinheiro, é a exceção, não a regra.

A.Busca vetorial (semântica)

Use busca vetorial quando as perguntas vêm em linguagem natural, com sinônimos, paráfrases e intenção: “posso devolver em outra cidade?” precisa encontrar “devolução em local diferente do de retirada”. Ela entende o sentido, não as palavras. Falha com códigos, siglas, nomes próprios e números exatos, que tendem a se confundir com outros parecidos.

B.Busca lexical (BM25)

Use busca lexical quando a pergunta contém termos exatos: código de peça, número de contrato, sigla, nome de produto, código de erro. É rápida, barata e explicável: dá para saber por que um resultado apareceu. Falha com sinônimos e com perguntas vagas, porque procura exatamente o que foi escrito.

C.Busca híbrida

Use busca híbrida como padrão em RAG corporativo: executa as duas buscas e funde os resultados. Resolve tanto a pergunta com identificador quanto a pergunta vaga no mesmo sistema. Custa duas buscas em vez de uma, mas a latência adicional costuma ser pequena e o ganho de qualidade, grande. Combinada com reranking, é a configuração mais robusta.

A.Otimizar precisão

Use precisão como prioridade quando agir errado custa: bloquear um cliente legítimo, marcar um e-mail importante como spam, mostrar um item irrelevante, disparar um alerta que ninguém precisava ver. Aceita-se perder alguns casos positivos para não incomodar quem não deveria ser incomodado. O limiar sobe: o modelo só aponta quando tem confiança.

B.Otimizar recall

Use recall como prioridade quando deixar passar custa: fraude, falha de segurança, doença, cláusula de risco em um contrato, defeito em um produto. Aceitam-se mais falsos alarmes, desde que exista capacidade humana para revisá-los. O limiar desce: o modelo aponta na dúvida.

A.Data drift

Suspeite de data drift quando a distribuição das entradas mudou: novo perfil de cliente, novo canal, mudança sazonal, campo preenchido de outra forma. O modelo vê coisas que não viu no treino. Detecta-se comparando as distribuições das variáveis em produção com as do treino (por exemplo, com o PSI). Resolve-se com dados novos e retreinamento.

B.Concept drift

Suspeite de concept drift quando a relação entre entrada e saída mudou: o que era fraude deixou de ser, uma política nova mudou o que é elegível. As entradas parecem iguais, mas significam outra coisa. Detecta-se pela queda de desempenho com rótulos recentes, o que exige juntar previsão e resultado real. Resolve-se retreinando com a nova relação.

C.Provider / prompt drift

Suspeite de provider ou prompt drift quando nada mudou nos seus dados: o fornecedor atualizou o modelo, ou alguém alterou o prompt sem registro. O comportamento muda sem causa aparente. Detecta-se rodando o eval fixo com a versão fixada. Resolve-se fixando a versão do modelo e versionando prompts.

A.SLM (modelo pequeno)

Use um modelo pequeno para tarefas estreitas e bem definidas: classificar, extrair campos, rotear, moderar, formatar. Latência baixa, custo por chamada 10 a 50 vezes menor, possibilidade de rodar em infraestrutura própria. Exige eval para provar que basta. Muitas vezes, basta, especialmente depois de um fine-tuning leve.

B.LLM de fronteira

Use um modelo de fronteira para raciocínio longo, tarefas abertas, agentes com muitas ferramentas, casos raros e ambíguos. Mais caro e mais lento, mas resolve o que o pequeno não resolve. É a escolha para o que exige julgamento, síntese complexa e adaptação a situações novas.

A.Open-weight (pesos abertos)

Use modelo de pesos abertos quando os dados não podem sair da empresa (regulação, sigilo), quando é preciso fine-tuning profundo, quando o volume justifica infraestrutura própria ou quando a independência de fornecedor é estratégica. Exige time de MLOps, GPUs e operação contínua. O custo é previsível, mas existe mesmo sem uso.

B.Proprietário via API

Use modelo proprietário via API quando o time é enxuto, quando a melhor qualidade disponível importa, quando o volume é variável ou quando a velocidade de lançamento é prioridade. Custo por uso, sem infraestrutura para operar. Em troca, dependência do fornecedor, custo variável e risco de mudanças no modelo (provider drift).

A.LLM-as-a-judge

Use LLM como juiz para escala: milhares de respostas por hora avaliadas com uma rubrica. Funciona bem para fidelidade à fonte, relevância, tom e aderência a formato. Precisa ser calibrado contra avaliação humana (concordância de pelo menos 80%) e revisado periodicamente. Tem vieses conhecidos: prefere respostas longas e do mesmo modelo.

B.Avaliação humana

Use avaliação humana como padrão-ouro: casos ambíguos, calibração do juiz automático, temas sensíveis, decisões de lançamento. É cara e lenta, então deve ser usada por amostragem estratificada, com rubrica clara e concordância entre avaliadores medida.

C.Métrica automática (código)

Use métrica automática por código sempre que a saída é verificável objetivamente: formato JSON válido, valor extraído bate com o esperado, teste passa, número dentro da faixa. É determinística, barata e sem viés de juiz. Deve ser a primeira opção quando aplicável.

A.Deploy canário

Use deploy canário para expor a nova versão a uma fração pequena do tráfego real (1% a 5%), monitorar erro, latência e qualidade, e expandir ou reverter. Serve para detectar problemas operacionais com risco limitado. Exige feature flag para desligar rápido e métricas de qualidade na fatia canário.

B.Shadow deployment

Use shadow deployment para rodar a nova versão em paralelo sobre o tráfego real, sem entregar suas respostas, só comparando. Risco zero ao usuário; ideal para modelo novo ou fornecedor novo antes do canário. Diz, com dados, se a mudança melhora alguma decisão e em quantos casos.

C.Teste A/B

Use teste A/B para dividir usuários entre duas versões e comparar métricas de negócio com significância estatística. Serve para decidir qual versão é melhor para o usuário, não só se funciona. Exige amostra calculada antes, métrica definida e disciplina para não parar cedo.

A.Síncrono

Use execução síncrona para interação conversacional, busca e sugestão em tempo real: o usuário está esperando e a resposta cabe em segundos. Exige orçamento de latência definido e, em chats, streaming para melhorar a percepção de velocidade.

B.Assíncrono

Use execução assíncrona para tarefas longas: análise de lote, agente com muitos passos, processamento de documentos, fluxos com aprovação. O sistema aceita o pedido, processa e notifica. Permite retry, fila, paralelismo e revisão humana sem travar o usuário. A experiência muda de “esperar” para “acompanhar”.

A.MCP

Use MCP quando várias aplicações de IA (assistentes, agentes, IDEs) precisam das mesmas ferramentas e fontes, com descoberta dinâmica e padrão aberto. Um servidor atende muitos clientes. Exige tratar cada servidor como fronteira de segurança, especialmente os de terceiros.

B.API/REST direta

Use API REST direta para integração ponto a ponto entre o seu backend e um sistema, sem modelo no meio. Previsível, controlada, sem camada extra. O modelo não “vê” a API; o código do produto chama e devolve o resultado.

C.Function calling nativo

Use function calling nativo para ferramentas específicas de uma aplicação, definidas no código dela, sem necessidade de compartilhar com outras. Mais simples do que MCP; a ferramenta vive dentro do produto. É a escolha para um assistente único com poucas ferramentas próprias.

A.Paridade demográfica

Use paridade demográfica quando o que deve ser igual é o resultado: mesma proporção de aprovados ou expostos por grupo. Adequada quando o resultado é uma oportunidade a ser distribuída ou quando o rótulo histórico é suspeito de viés. Inadequada quando há diferença real e legítima na taxa base entre grupos.

B.Equalized odds / equal opportunity

Use equalized odds ou equal opportunity quando o que deve ser igual é o erro: mesma taxa de acerto (e, no equalized odds, de falso alarme) por grupo. Adequada quando existe verdade de referência confiável e o dano é errar mais para um grupo. Equal opportunity é a mais usada em produto: os merecedores têm a mesma chance, em qualquer grupo.

C.Calibração por grupo

Use calibração por grupo quando o que deve ser igual é o significado da pontuação: “80% de risco” quer dizer o mesmo em qualquer grupo. Adequada quando humanos leem a pontuação e decidem a partir dela. Sem calibração por grupo, a mesma nota leva a decisões diferentes dependendo de quem é avaliado.

A.Janela de contexto

Use apenas a janela de contexto quando basta o que cabe na conversa atual. Simples, sem estado, sem risco de privacidade acumulada. É suficiente para a maioria das interações únicas: uma pergunta, uma resposta, fim.

B.Memória de curto prazo (sessão)

Use memória de curto prazo (sessão) para o estado de uma tarefa em andamento: passos executados, resultados intermediários, checkpoints. Necessária para agentes; vive enquanto a sessão vive. Exige definir quando o estado é apagado e cuidado com dados pessoais nele.

C.Memória de longo prazo (persistente)

Use memória de longo prazo para preferências e fatos sobre o usuário entre sessões. Melhora a personalização, mas exige consentimento, controle do usuário sobre o que é lembrado, prazo de retenção e mecanismo de correção. Memória errada é pior do que nenhuma: um fato desatualizado lembrado com confiança gera erro persistente.

A.Eval offline

Use eval offline antes de lançar e a cada mudança: conjunto fixo de casos, resultados reprodutíveis, comparação entre versões. Barato de repetir; cego para o que o conjunto não cobre. Responde “a mudança é segura?”.

B.Eval online (produção)

Use eval online em produção: amostragem contínua de respostas reais julgadas por rubrica, feedback do usuário, métricas de negócio. Vê o mundo real; mais lento e mais caro por caso. Responde “o produto continua bom?”.

A.Instrução no prompt

Use instrução no prompt para comportamento desejado que tolera exceção: tom, formato, prioridades, estilo de recusa. O modelo geralmente obedece; às vezes, não. É a ferramenta certa para moldar como o sistema se comporta na maior parte do tempo.

B.Guardrail em código

Use guardrail em código para regras que não podem falhar de jeito nenhum: nunca revelar dados pessoais, nunca executar ação sem aprovação, nunca sair do escopo. Funciona fora do modelo; uma injeção de prompt não o desliga. É a ferramenta certa para o que precisa ser garantido, e não apenas desejado.

A.Taxa de contenção

Use taxa de contenção para medir quantos casos não chegaram a um humano. Fácil de medir, mas pode subir com respostas ruins que o cliente aceitou ou desistiu de contestar. Sempre acompanhe junto com a taxa de reabertura.

B.Taxa de sucesso da tarefa

Use taxa de sucesso da tarefa para medir quantos casos foram de fato resolvidos por critério verificável: sem reabertura, ação concluída, dado correto. É a métrica de valor real. Exige definir “sucesso” para cada tipo de tarefa, o que dá trabalho e vale a pena.

C.CSAT

Use CSAT para medir como o cliente se sentiu. Captura o que as outras não veem (tom, esforço, clareza), mas tem viés de resposta e não mede resolução. Compare o CSAT do assistente com o do atendimento humano e olhe especialmente as conversas escaladas.

A.Texto livre

Use texto livre quando uma pessoa vai ler: conversa, resumo, explicação. Flexível e natural; difícil de validar automaticamente. É a forma certa de comunicar com humanos.

B.Saída estruturada (JSON/schema)

Use saída estruturada quando um sistema vai consumir: extração de campos, classificação, chamada de ferramenta, integração. Validável por esquema, testável por código, sem ambiguidade. É a forma certa de comunicar com máquinas.

A.Retreino programado

Use retreino programado (semanal, mensal, trimestral) independentemente de sinal. Simples e previsível; pode retreinar sem necessidade ou tarde demais. É o ponto de partida quando ainda não há monitoramento de drift maduro.

B.Retreino por gatilho

Use retreino por gatilho quando o monitoramento detecta drift ou queda de métrica além do limiar. Mais eficiente; exige monitoramento confiável e pipeline de retreino automatizado. É a evolução natural quando a observabilidade está madura.

C.Descontinuação

Use descontinuação quando o modelo não entrega mais valor que o custo de operá-lo, quando o problema mudou ou quando a adoção caiu. Modelos também morrem; ter critério de saída evita modelos zumbis. Toda capacidade deveria nascer com critério de desligamento.

A.Vibe coding / protótipo em ferramenta no-code

Use vibe coding ou ferramentas no-code para aprender rápido: testar uma hipótese com usuários, demonstrar um conceito, explorar viabilidade. Dias, não semanas; código descartável. O objetivo é o aprendizado, não o artefato.

B.Engenharia de produto

Use engenharia de produto para operar: testes, segurança, observabilidade, evals, conformidade com LGPD, escala. O protótipo vira especificação; o código é reescrito com engenharia. O objetivo é confiabilidade sustentada.