Do Prompt ao Produto: Transformando LLMs em Aplicações Reais

Um prompt que funciona em um playground é uma demo, não um produto. A distância entre os dois é onde a maioria dos projetos de IA morre em silêncio. Construir aplicações com LLMs que sobrevivem a usuários reais tem menos a ver com prompting engenhoso do que as demos sugerem, e muito mais a ver com a disciplina comum de engenharia de software. Já lançamos o suficiente desses — Youp, MadaiOps e agora Linea — para ter opiniões sobre o que de fato fecha essa distância. Nada disso é glamouroso.

A armadilha é que a primeira versão parece pronta. Você cola um prompt esperto, o modelo devolve algo impressionante, e é tentador embrulhar isso em uma interface e chamar de lançamento. Então usuários reais chegam com entradas que você nunca imaginou, o modelo faz algo confiantemente errado, e você descobre que não tem como saber se a sua correção melhorou ou piorou as coisas. Este texto é sobre o andaime que transforma aquela demo impressionante em algo que você consegue rodar em produção e dormir tranquilo à noite.

Comece pelos evals, não pelos prompts

A coisa de maior alavancagem que você pode construir cedo é um conjunto de avaliação. Não um benchmark, não um ranking — uma pasta de entradas reais pareadas com como se parece uma boa saída. Vinte exemplos batem zero, e cinquenta exemplos selecionados batem mil raspados da internet.

A razão é simples. Assim que você tem evals, a engenharia de prompt deixa de ser intuição pura. Você muda uma linha, roda o conjunto, observa o número se mover. Sem eles, cada ajuste é uma superstição. Já vimos times gastarem uma semana melhorando um prompt só para regredir em casos que haviam resolvido meses antes, porque nada media os casos para os quais eles não estavam olhando.

Algumas opiniões que sustentamos com firmeza:

• Avalie por resultados, não por redação. Para qualquer coisa estruturada — extração, classificação, roteamento — verifique o resultado interpretado, não a similaridade de strings. Para texto aberto, um LLM-como-juiz com uma rubrica bem definida serve, mas valide o juiz contra um punhado de rótulos humanos primeiro, ou você estará apenas medindo o gosto de um modelo.
• Mantenha um arquivo de regressões. Toda falha em produção vira um caso de teste permanente. É assim que o seu conjunto de evals se mantém honesto — ele cresce exatamente nas direções em que a realidade empurra.
• Versione seus evals junto com seus prompts. Um prompt sem o seu conjunto de evals é uma alteração de código não testada.

Se você construir uma única coisa a partir deste artigo, construa isto. Tudo o que vem depois depende de conseguir responder: isso melhorou?

Guardrails saem mais baratos que pedidos de desculpa

Modelos falham de formas que o software comum não falha. Eles vão inventar uma API que não existe, concordar com uma premissa falsa do usuário ou emitir um JSON de aparência válida com um campo alucinado. Guardrails são a camada que captura isso antes de chegar a um usuário ou, pior, a uma etapa de execução.

Pense em três posições.

• Guardrails de entrada rejeitam ou higienizam antes de o modelo rodar: triagem de injeção de prompt, ocultação de dados pessoais, filtragem de temas fora de contexto.
• Guardrails de saída validam o que volta: validação de esquema, checagem de ancoragem em citações, filtros de política.
• Guardrails de ação ficam entre o modelo e qualquer coisa com efeitos colaterais.

Esse terceiro é onde mora o risco de verdade. No Linea, nossos agentes de automação de fluxos de trabalho, o modelo pode propor ações — chamar uma API, mover um registro, enviar uma mensagem. A proposta e a execução são etapas deliberadamente separadas. Toda ação relevante passa por um contrato tipado e uma checagem de política antes de qualquer coisa rodar, e ações destrutivas ou irreversíveis exigem um portão de confirmação explícito. Um agente sugerindo a coisa errada é um problema de experiência sobre o qual você consegue iterar. Um agente fazendo a coisa errada é um incidente. Mantenha esses dois modos de falha em lados opostos de uma fronteira rígida.

A versão opinativa: valide a saída estruturada contra um esquema e faça nova tentativa em caso de falha, em vez de confiar que o modelo será consistente. E nunca deixe que a saída bruta de um modelo seja o que dispara uma ação irreversível. Coloque uma checagem determinística no meio, sempre.

Orce latência e custo como se fossem funcionalidades

Latência e custo não são coisas que você mede no final. São restrições contra as quais você projeta desde o começo, porque elas mudam a arquitetura, não apenas a conta.

Defina orçamentos explícitos por ação voltada ao usuário: uma meta de latência de p95 e um teto de custo por chamada. Uma vez que isso está escrito, as decisões de projeto ficam mais fáceis. Alguns padrões aos quais recorremos repetidamente:

• Dimensione o modelo certo para cada etapa. A maioria dos pipelines tem uma ou duas etapas que genuinamente precisam do modelo de fronteira e várias que um modelo menor e mais rápido resolve bem. Rotear uma classificação simples para um modelo barato e reservar o caro para a etapa de raciocínio difícil é a otimização de maior retorno disponível, e normalmente também melhora a latência.
• Faça streaming do primeiro token. Para qualquer coisa conversacional, a latência percebida é dominada pelo tempo até o primeiro token. Uma resposta em streaming que leva quatro segundos parece melhor do que uma bloqueante que leva dois.
• Use cache de forma agressiva. Cache de prompt no contexto de sistema estável, cache comum de resultados em entradas repetidas. Uma fração relevante do tráfego de produção é quase duplicada.

O trade-off a manter em mente: modelos maiores reduzem o seu esforço de engenharia mas elevam o seu custo marginal e a latência para sempre. Modelos mais baratos empurram trabalho para você — mais cuidado com prompts, mais guardrails, mais evals — mas esse trabalho é um custo único contra uma economia permanente. Para qualquer coisa com volume, invista na engenharia.

Mantenha humanos no circuito, de propósito

"Humano no circuito" é dito com tanta frequência que parou de significar qualquer coisa. Feito bem, não é um plano B para quando a IA falha — é uma divisão de trabalho projetada. A pergunta não é se incluir um humano, mas onde o julgamento do humano vale mais do que a latência que ele adiciona.

O padrão que melhor nos serviu é o escalonamento condicionado por confiança. O sistema trata a maioria confiante automaticamente e roteia a minoria incerta para uma pessoa, com o raciocínio do modelo anexado, para que o humano decida em segundos, não em minutos. No MadaiOps, operações de ordem dentro de parâmetros normais fluem direto; qualquer coisa anômala aparece para um operador com contexto, em vez de executar em silêncio. O revisor não está cuidando da máquina. Ele está gastando sua atenção apenas onde ela é escassa e valiosa.

Mais uma regra: instrumente as correções do humano e realimente-as no seu conjunto de evals e nos seus prompts. Um sistema com humano no circuito que não aprende com seus humanos está apenas pagando duas vezes pelo mesmo trabalho.

Saiba o que não automatizar

O julgamento mais difícil nesta disciplina é a contenção. Nem toda tarefa deveria ser entregue a um modelo, e maturidade é saber quais deixar em paz.

Nosso teste aproximado: automatize onde o custo de um erro é baixo, ou o erro é fácil de detectar e reverter. Redigir, resumir, extrair, classificar, rotear — bons candidatos. Um rascunho errado é editado; um resumo errado é pego na leitura. Seja muito mais cauteloso onde os erros são caros, difíceis de detectar ou irreversíveis: qualquer coisa que movimenta dinheiro, envia uma comunicação irrevogável ou toma uma decisão jurídica ou médica. Ali, o modelo pertence a um papel assistivo — trazendo opções à tona, redigindo para revisão — não ao volante.

A linha que sustentamos: se você não consegue descrever como pegaria o modelo errando, você não está pronto para automatizar aquela etapa. A capacidade de detectar falha é o verdadeiro pré-requisito, mais do que a precisão. Uma etapa 95% precisa que você consegue verificar por completo é mais segura de lançar do que uma 99% precisa que você não consegue.

O formato do trabalho

Transformar um prompt em produto é, na maior parte, a parte sem glamour: evals para poder medir, guardrails para que as falhas fiquem contidas, orçamentos para que continue rápido e acessível, humanos posicionados onde o julgamento importa, e a disciplina de deixar algumas coisas não automatizadas. O modelo é talvez vinte por cento do sistema. Os outros oitenta por cento são a engenharia que torna seguro depender do seu brilhantismo ocasional.

A boa notícia é que este é um trabalho familiar. Ele recompensa os mesmos instintos que fazem bom software de qualquer tipo: meça antes de mudar, contenha o raio de impacto, respeite o tempo dos seus usuários. O modelo é novo. O ofício não é.