O gasto que mata features de IA vem depois do deploy

Shipping de IA é glamour. Sustentação é boleto. A maioria dos produtos que colocam um assistente “inteligente” no ar descobre, em poucas semanas, que o custo decisivo não está no modelo escolhido, e sim no ecossistema de manutenção que mantém tudo minimamente confiável. Não é romântico, mas é aí que as margens evaporam — e onde os poucos que dominam a rotina ganham.

Exemplo rápido: você lança um bot de suporte baseado em RAG para reduzir contatos humanos. Funciona no demo. No mês seguinte, o time jurídico altera duas políticas, o time de produto renomeia campos num schema interno, a equipe de dados faz um ajuste no pipeline de PDFs e a provedora do embedding troca discretamente o comportamento do endpoint. O recall despenca, o alucinômetro dispara e a diretoria quer saber por que os custos subiram “mesmo com a automação”. Bem-vindo à economia invisível da IA: reindexar, reavaliar, reconectar, repetir.

RAG não é plug-in, é uma operação

Três pontos técnicos que separam vitrines de sistemas produtivos:

1) Indexação e drift de embeddings. Mudar de um modelo de embedding 768-d para 1536-d (ou trocar text-embedding-3-small por text-embedding-3-large, ou migrar para bge/multilingual) quase sempre exige reindexação completa. Em bases com Milhões de chunks, isso é tempo de máquina, I/O e janelas de degradação. Em HNSW, a troca de espaço vetorial e parâmetros (M, efConstruction) impacta a topologia do grafo; em IVF-Flat/IVF-PQ, quantizadores precisam ser reajustados. Não é só custo computacional: qualquer retreinamento altera a distribuição de similaridade e muda, silenciosamente, o seu ponto de corte de relevância.

2) Estratégia de chunking. Recursive chunking com sobreposição (sliding windows) melhora a cobertura semântica, mas multiplica o tamanho do índice e o tempo de reindex. Chunking por estrutura (headers, seções) mantém contexto mas sofre quando os documentos chegam mal formatados (olá, PDFs). Em sistemas reais, o time convive com heurísticas mistas: limitar tokens por chunk (ex.: 300–800), manter overlaps de 10–20%, deduplicar via simhash e normalizar artefatos (listas, tabelas) antes de mandar para o pgvector, Milvus ou Weaviate. “Depois a gente refina” vira dívida operacional eterna.

3) Latência vs. recall no vetor. HNSW brilha em baixa latência com alto recall… até o grafo crescer demais e a memória estourar. IVF ganha em controle de latência via número de listas (nlist) e probes (nprobe), mas cobra no recall. Pinecone e serviços gerenciados escondem parte da aflição, porém a conta chega no tail latency e no overprovisioning. E quando você acrescenta reranking com modelos cross-encoder (ex.: e5-reranker ou Cohere re-rank), o p95 da requisição dobra. O usuário não perdoa o spinner.

Evals não salvam ninguém sozinhos

Empresas que operam IA que realmente funciona montaram fábricas de avaliação. Offline, rodam suites de golden sets e contraexemplos gerados via data augmentation. Online, fazem canary e shadow traffic medindo: taxa de confiança x acerto factual, taxa de “I don’t know”, sensibilidade a injeção de prompt, e custo por resolução. LLM-as-judge ajuda, mas drift no “juiz” também é real: troque o modelo avaliador e sua métrica balança. Sem um dataset fixo, versionado e com casos de borda etiquetados por humanos, o time passa a semana perseguindo fantasmas.

Ferramentas? LangSmith, Arize Phoenix e Weights & Biases ajudam, OpenTelemetry no request end-to-end dá visibilidade de onde o tempo e o dinheiro somem. O detalhe sujo: sampling mal configurado vira cegueira intermitente. E sem correlação entre versão de prompt, versão de embedding e versão do índice, qualquer rollback é chute.

Contratos de ferramentas: JSON é lei (e às vezes trai)

Agentes dependem de chamadas de função com contratos estáveis. Quando a ferramenta de “criar_pedido” muda um campo de string para enum, metade das execuções começa a falhar de forma silenciosa. A defesa é previsível, porém rara: JSON Schema versionado, validação antes de chamar a tool, Pydantic para decodificar e normalizar, timeouts agressivos, retries com jitter e idempotency keys. Streaming parcial ajuda a UX, mas complica a atomicidade da cadeia de ferramentas. E se o provedor do LLM altera levemente o comportamento do function calling, seu decoder vira arqueólogo.

Empresas grandes já tratam tools como APIs públicas internas. Testes de contrato rodam junto com as CI/CD pipelines, com fixtures que simulam erros banais (campos nulos, enums desconhecidos, tempo de resposta aleatório). É chato de manter? Sim. Mais chato é um agente comprando cinco cadeiras de escritório porque interpretou “quantidade: 5” no campo errado.

Observabilidade de verdade, não só contagem de tokens

Log de prompt e resposta é o básico. O que evita incidentes é traço distribuído com contexto: trace do request desde a UI até a query ANN, passando por cache semântico, reranking, tool calls, e auditoria de PII. OpenTelemetry com atributos customizados (prompt_hash, prompt_version, embedding_model_version, index_sha) transforma caça a bugs em engenharia, não em esoterismo. Caching também evolui: além de Redis por chave exata, times usam caches vetoriais de baixo custo ou Bloom/SimHash para hits aproximados. Aumento de acerto em perguntas repetitivas derruba custo de inferência tanto quanto um modelo mais barato — e sem trocar de provedor.

Ah, e versionamento de prompt é civilização. Nada de “final_v2_final_agora_valendo”. Use controles de rollout, A/B e feature flags, exatamente como frontend faz há anos. A diferença é que um prompt mal desenhado às vezes funciona… até encontrar uma exceção que transforma reembolso em pedido novo.

Segurança e governança: o copo com furinhos

RAG não é firewall. Sem controles de acesso na camada de recuperação (row-level security, ABAC), seu assistente “interno” pode vazar estratégia comercial por acidente. Sanitização de conteúdo antes de indexar, criptografia em repouso, chaves rotacionadas e auditoria legível por humanos não são luxo. Também não terceirize integralmente a detecção de PII para o modelo; regex e heurísticas continuam úteis. E sim, prompt injection continua um esporte sangrento: filtros de saída, whitelists de ferramentas e política de “nunca executar sem dupla confirmação” para ações destrutivas ainda são a linha de defesa mais realista.

Casos de mercado, com os pés no chão

– Empresas que construíram search interno robusto (Atlassian, Notion, Salesforce) usam pipelines de indexação com orquestração explícita de reprocessamento e verificações de integridade. O produto parece “simples”, mas por trás tem agendamento de reindex por fonte, testes de consistência entre embeddings antigos e novos e dashboards que mostram a saúde do índice por coleção.

– Quem aposta em copilots de código aprendeu a duras penas que o ganho vem de uma malha de telemetria e feedback de desenvolvedor. GitHub Copilot, JetBrains AI e afins coletam sinais finos (aceitação, edição pós-sugestão, tempo até o erro) para calibrar prompts e políticas. A magia aparece na IDE; o trabalho pesado acontece em background com pipelines de avaliação contínua.

– No suporte, empresas que divulgam bots “resolvendo X% dos casos” investem pesado em fallback controlado, escalonamento com contexto preservado e workflows de revisão humana. A economia real não vem do modelo em si, mas da orquestração: quando entregar “não sei”, quando pedir mais dados, quando desistir antes de gerar custo adicional e frustração.

Unit economics menos fotogênica

Coloque números honestos no quadro: custo de inferência é uma linha. As outras: reindex periódico (cadência mensal? por evento?), armazenamento expandindo com overlaps, rerankers, cobrança do serviço vetorial, logs e traces, execuções de evals, horas de analistas rotulando casos de borda, on-call para incidentes, retrabalho pós-mudança de API, auditorias de segurança. Some 10–30% de buffer para drift e sazonalidade. Quase sempre, a curva de manutenção vira o determinante da margem, não o preço do token.

Trocas de fornecedor — modelo, embeddings, vetor — exigem ensaios controlados com shadow traffic e planos de rollback. Sem isso, migrar “porque ficou mais barato” destrói KPIs discretamente. E lock-in não é só técnico: seu conjunto de goldens, seus filtros e suas heurísticas viram patrimônio. Migrar dói por causa deles.

Trade-offs que doem agora, aliviam depois

– Mais recall hoje com index maior vs. custo de reindex amanhã. O meio-termo são índices por coleção com SLAs distintos e políticas de frescor por fonte (ex.: contratos reindex sob demanda, wikis por delta diário).

– Ferramentas “inteligentes” de alto poder vs. políticas conservadoras. Se a ação é destrutiva, dois cliques e confirmação frustram um pouco a UX, mas evitam manchetes constrangedoras.

– Modelos grandes e criativos vs. modelos menores com caching agressivo e prompts mais explícitos. Consistência vence criatividade na maior parte dos fluxos transacionais.

– Observabilidade completa vs. privacidade. Truncar e mascarar é obrigatório; sem contexto, troubleshooting vira adivinhação. Investir em redatores automáticos de logs “seguros” é mais barato do que advogados depois.

Conclusão

O diferencial competitivo não está em “qual LLM” você escolheu, e sim em quão competente é sua rotina de pós-deploy. As empresas que vão sobreviver à ressaca da hype tratarão IA como search e pagamentos: contratos estáveis, telemetria obsessiva, testes que quebram cedo e rollback sem drama. O resto é perfumaria cara.

Se quiser uma métrica útil para a próxima reunião com o CFO, leve três: tempo de reindex completo, cobertura e saúde do conjunto de evals, e custo por resolução bem-sucedida com variância semanal. Se nenhuma delas existe, a sua feature de IA já está cara — só não apareceu no relatório ainda. E quando aparecer, não vai ser um spike. Vai ser um vazamento crônico, do tipo que começa com um campo renomeado e termina com um plantão às 3h tentando descobrir por que “telefone” virou enum.