O que aprendemos operando.

Por que a maioria dos projetos de IA trava na integração

Em quase todo projeto de IA que entra na fase de produção, o modelo deixa de ser o problema por volta da terceira semana. A pergunta muda de “qual modelo usar?” para “por que o dado do cliente está em quatro lugares diferentes e nenhum deles concorda?”.

O modelo é a parte fácil

Hoje qualquer time consegue chamar uma API e ter uma resposta plausível em uma tarde. O custo real está em entregar essa resposta com o contexto certo, no tempo certo e com rastreabilidade — para o atendente, o analista ou o sistema que vai agir em cima dela.

Contexto disperso é o gargalo

Um agente de triagem precisa saber quem é o cliente, qual o contrato, qual o SLA e o que já foi respondido antes. Isso normalmente mora em um ERP, um CRM, uma pasta de PDFs e a memória de duas pessoas. Sem um contrato de dados que una essas fontes, o agente improvisa — e improvisar, em produção, se chama erro.

• Sem identidade unificada, o agente trata o mesmo cliente como três pessoas.
• Sem permissão herdada, ele mostra dado que o usuário não deveria ver.
• Sem versão do contexto, dois usuários recebem respostas diferentes para a mesma pergunta.

A pergunta certa não é “o modelo responde bem?”. É “o que exatamente ele recebe, de quem e com qual garantia?”.

Sem avaliação, não existe melhoria

Times que não montam um conjunto de avaliação com casos reais acabam ajustando prompt por impressão. O resultado é um ciclo de mudanças que parece produtivo e não move nenhum número. Antes de aumentar o contexto, medimos: acerto por tipo de pergunta, taxa de citação correta, custo por atendimento e tempo até a primeira resposta útil.

O que funciona na prática

• Comece pelo fluxo que já tem dono e métrica — não pelo caso mais criativo.
• Trate a integração como produto: contrato, versão, retry e monitoramento.
• Coloque o humano no circuito até a taxa de acerto justificar o contrário.
• Meça custo por resposta desde o primeiro dia; ele cresce mais rápido que a receita.

IA em operação é, antes de tudo, engenharia de dados e de sistemas. Quem entende isso chega mais longe com modelos menores — e com muito menos sustos.

RAG em produção: custo, contexto e a disciplina que ninguém mostra

RAG (retrieval-augmented generation) virou sinônimo de “colocar um PDF no chat”. Em produção, é um pipeline com ingestão, indexação, recuperação, reranking, geração e avaliação — e cada etapa tem um custo que aparece na fatura e na paciência do usuário.

Chunking não é detalhe

O pedaço de documento que você recupera define a qualidade da resposta mais do que o modelo. Contratos, por exemplo, perdem o sentido quando cortados no meio de uma cláusula. Preferimos chunking por estrutura (título, seção, cláusula) com sobreposição curta e metadados de origem — e testamos a recuperação separadamente da geração.

Recuperação boa é mensurável

Antes de olhar a resposta final, medimos recall@k: o trecho que responde à pergunta está entre os recuperados? Se não estiver, nenhum prompt salva. Só depois entram reranking, filtros por permissão e compressão de contexto.

Um agente que cita a fonte errada é pior que um agente que diz “não encontrei”. O segundo custa uma consulta; o primeiro custa a confiança.

O custo mora no contexto

Colar dez documentos em cada chamada é a forma mais rápida de transformar um projeto viável em um projeto caro. As decisões que mais economizam, na nossa experiência:

• Recuperar menos e melhor: 4 trechos precisos superam 20 trechos vagos.
• Cachear respostas para perguntas repetidas — suporte tem muita repetição.
• Usar modelo menor para classificação e roteamento; reservar o maior para o raciocínio.
• Orçar por atendimento resolvido, não por token — é a métrica que o cliente entende.

Disciplina de avaliação

Mantemos um conjunto de 150 a 300 perguntas reais com resposta esperada e fonte. Toda mudança de chunking, modelo ou prompt passa por ele. Sem isso, a qualidade oscila sem ninguém perceber — e o primeiro a notar é o cliente, no pior momento possível.

RAG é menos sobre “usar IA” e mais sobre organizar conhecimento. A parte de IA é a menor fração do trabalho.

Observabilidade não é dashboard: é tempo de resposta

Dashboard é onde a informação aparece. Observabilidade é a capacidade de responder “o que está acontecendo e por quê?” em minutos, com o time que está de plantão às três da manhã. São coisas diferentes, e confundir as duas custa caro.

Telemetria sem contexto não ajuda

Um pico de latência não diz nada sozinho. O que resolve é saber qual rota, qual cliente, qual versão e qual dependência estavam envolvidos. Por isso todo evento carrega identificadores de correlação — pedido, tenant, deploy, região — desde a primeira linha.

Alerta bom é alerta acionável

• Alerta que não tem ação clara deve ser removido, não silenciado.
• Alerta por sintoma do usuário (erro, lentidão, fila) vem antes de alerta por CPU.
• Um incidente, uma página. Rajadas de alertas treinam o time a ignorar o canal.

Se ninguém sabe o que fazer quando o alerta toca, o problema não é o alerta — é o runbook que não existe.

Runbook é documentação viva

Cada serviço crítico tem um runbook curto: sintomas, hipóteses prováveis, comandos de diagnóstico, caminho de escalonamento e critério de rollback. Ele é revisado depois de cada incidente, porque incidente é a única fonte de documentação que nunca mente.

Meça o que importa

Tempo até detectar, tempo até diagnosticar, tempo até mitigar. Uptime é consequência disso — e não o contrário. Times que otimizam só o número do mês aprendem, no primeiro incidente longo, que disponibilidade se constrói no processo.