Tecnologia
Consultoria para colocar LLM em produção
A demonstração impressionou a diretoria. Meses depois a funcionalidade existe, mora numa tela ao lado do sistema e quase ninguém usa. Quando alguém pergunta se está boa, a resposta é a impressão de quem testou por último. Não houve métrica definida antes da subida, então não há com o que comparar. Quando a resposta vem errada, o usuário não tem para onde ir. E a conta do provedor cresce sem que ninguém consiga explicar por quê.
Como a gente encara.
A métrica vem antes do modelo. Definimos o que a funcionalidade precisa melhorar e como isso é medido hoje, porque depois de subir não existe mais linha de base. Só então vem o conjunto de casos com resposta esperada — a avaliação automática (evals) —, que roda a cada mudança de prompt ou de modelo. O custo é projetado por uso e por tamanho de contexto. E o desenho prevê o erro: caminho de escape e registro do que a pessoa fez depois.
Onde costuma quebrar
Os erros que aparecem sempre, e que ninguém conta na demonstração.
- 01
Métrica definida depois de subir. Sem o número de antes você fica só com a percepção de agora, e a decisão de continuar ou desligar vira disputa entre quem construiu e quem paga.
- 02
Nenhuma avaliação automática. Cada mudança de prompt é conferida à mão em alguns casos, e como a mesma pergunta costuma não devolver a mesma resposta, ninguém consegue distinguir melhora de sorte.
- 03
Custo tratado como imprevisível. Ele é projetável: preço por token de entrada e de saída, tamanho do contexto enviado e quantidade de chamadas que o seu fluxo faz por tarefa. O que falta é fazer a conta, não previsibilidade.
- 04
Ausência de caminho de escape. Quando o modelo erra, o usuário fica sem próximo passo: não dá para corrigir, não há para quem transferir, e a saída que sobra é abandonar a tela e fazer do jeito antigo.
- 05
Integração que para na tela. A funcionalidade vira uma caixa de conversa ao lado do sistema em vez de um passo dentro do fluxo onde o trabalho acontece. Quem usa precisa copiar a resposta para outro lugar, e é aí que o uso morre.
O que custa mais do que parece
- Avaliação é trabalho permanente, não etapa do projeto. Apontar para o apelido do modelo (alias) é aceitar que o provedor troque a versão por baixo. O comportamento se desloca sem que ninguém toque no código. Fixar a versão datada (pinned) segura isso até aquela versão ser aposentada, e aí migrar deixa de ser opcional. Sua base de conhecimento também muda por conta própria. Sem um conjunto de casos rodando sozinho, você descobre pela reclamação.
- O custo por chamada cresce com o contexto que você envia dentro da janela de contexto (context window). Cada instrução, exemplo e trecho recuperado acrescentado ao prompt entra em toda chamada seguinte, então o que era barato no piloto encarece sozinho conforme o prompt engorda e as conversas se alongam.
O que você recebe
- Métrica de sucesso definida antes da subida, com a medição atual registrada como linha de base.
- Conjunto de casos de avaliação com resposta esperada, executando a cada mudança de prompt ou de modelo.
- Projeção de custo por volume de uso e por tamanho de contexto, com alerta quando o consumo sai da faixa prevista.
- Caminho de escape desenhado: o que o usuário faz quando a resposta está errada e para onde a tarefa vai em seguida.
- Registro por interação ligando o que foi perguntado, o que foi respondido e o que a pessoa fez depois.
O que fazemos com LLM em produção
Open source ou enterprise, a frente é a mesma.
Implantar
Do zero, com a arquitetura decidida no diagnóstico e não pelo catálogo do fornecedor.
Migrar
De outra ferramenta, ou de uma versão antiga, com o que já roda continuando a rodar.
Desenvolver em cima
Aplicação, integração e automação construídas sobre LLM em produção, incluindo o que a ferramenta não faz sozinha.
Sustentar
Operação, custo sob controle e correção de rota depois que entra em produção.
Perguntas diretas.
- A minha empresa precisa mesmo de LLM para isso?
- Boa parte do que se pede a um modelo de linguagem é regra, consulta ou relatório disfarçado. Se a tarefa tem resposta certa e verificável, uma consulta ou uma regra escrita acerta sempre, custa quase nada por execução e não exige avaliação contínua. Modelo de linguagem paga quando a entrada é texto livre, o formato varia a cada caso, e um resultado quase certo revisado por uma pessoa já vale mais do que o trabalho manual inteiro. Fora disso, o que você adiciona é custo por chamada e uma incerteza que alguém vai administrar para sempre.
- Quanto custa manter uma funcionalidade dessas no ar?
- A fatura do provedor é a parte projetável, e essa conta cabe numa planilha antes da primeira linha de código. O que surpreende vem depois dela. O contexto que você envia dentro da janela de contexto (context window) engorda sozinho: mais instrução, mais exemplo, mais trecho recuperado, e cada acréscimo passa a ser cobrado em toda chamada seguinte, não uma vez só. Cache de prompt (prompt caching) alivia a parte repetida da entrada, e só funciona quando o começo do prompt é estável, o que obriga a organizar o prompt para isso. E a avaliação, a observabilidade e o ajuste depois de cada atualização do provedor são tempo de gente, que costuma custar mais do que a fatura.
- Como saber se o modelo está alucinando em produção?
- Resposta por resposta, não dá para ter certeza automática — se houvesse um detector confiável, ele já seria o modelo. O que dá é desenhar para que a invenção fique visível. Pedir citação da fonte e verificar se o trecho citado existe. Preferir saída que possa ser conferida contra o sistema de origem, em vez de texto solto. Amostrar interações e revisar com quem conhece o assunto. E capturar o sinal do usuário: correção, abandono e refação da pergunta dizem mais do que uma nota de satisfação. Sem nada disso, o que existe não é ausência de alucinação, é ausência de medida.
Antes de escolher a ferramenta
A ferramenta é consequência da arquitetura. Nunca a premissa.
Esta página existe porque alguém procura por esse nome. Mas a escolha certa sai do diagnóstico do seu cenário, não do catálogo de quem vende. Se a resposta for outra ferramenta, ou nenhuma, é isso que você vai ouvir.
Não está na lista? Não é impedimento, é conversa. O que decide não é o nome do produto, é o problema que ele precisa resolver.