Shopping cart

Subtotal $0.00

View cartCheckout

Building better devs

TnewsTnews
Artigos

A parte que ninguém mostra nas demos de IA

Email : 2

A parte que ninguém mostra nas demos de IA

Demonstração é teatro. Produto é logística. O salto entre um chatbot brilhando no palco e um copiloto que presta serviço todo dia passa por coisas pouco instagramáveis: CDC em cima de tabelas confusas, cache semântico que falha na quarta-feira, ACLs herdadas do SharePoint 2013 e um orçamento de tokens que evapora mais rápido que a paciência do time jurídico.

Nos últimos meses, quase todo SaaS enfiou um “AI assistant” no canto da tela. Quem manteve o recurso depois do hype fez uma coisa que não aparece em keynote: chão de fábrica. O segredo não é um prompt genial — é o encanamento. E é aí que a competição real está acontecendo.

Começa no básico: grounding. Sem ancorar respostas em dados internos, o assistente vira bancada de ficção. A arquitetura clássica — RAG — parece simples no diagrama, mas ganha rugas na vida real. Hybrid search (BM25 + embeddings) supera o purismo vetorial quando o acervo é bagunçado, e chunking decente não é cortar parágrafos no meio; envolve janelas deslizantes, metadados e deduplicação agressiva. A Notion, por exemplo, teve de priorizar permission-aware indexing para seu Q&A: recuperar o pedaço certo do workspace sem vazar um doc de RH. Parece detalhe. Até o dia em que um estagiário pergunta “qual é o budget do time X” e recebe a planilha certa… que ele não devia ver.

No mundo enterprise, “freshness” ganha SLO. Um copiloto que cita política desatualizada mata confiança. Isso empurra times a construírem pipelines de atualização do índice com Change Data Capture: Debezium/Kafka para eventos de alteração, workers que geram embeddings incrementais, e reindexação por prioridade (novidade > popularidade > antiguidade). Sem isso, o banco vetorial vira um cemitério de PDFs antigos. A Microsoft vende o grounding no Graph como trunfo do Copilot — tecnicamente, é sobre mapear objetos de produtividade (emails, docs, reuniões) a um grafo navegável, aplicar filtros de permissão e reduzir latência ao mínimo tolerável para conversa. Glamour? Não. Efetivo? Bastante.

Unidade econômica é a segunda gravidade. Preço por 1k tokens parece barato até seu assistente resolver explicar políticas com prosa de advogado. Empresas que fizeram a lição trataram a conversa como produto com custos variáveis: budget por sessão, degraus de modelo (classificador pequeno para roteamento, LLM grande só quando necessário), compressão de contexto com re-resumo, e cache semântico para perguntas repetidas. Semantic cache não é salvar string; é indexar pares (consulta, resposta) com embedding e LSH, versionar por tenant e invalidar por trilha de dados alterados. Quando o cache acerta, custo cai e P95 respira. Quando erra, você entrega resposta estagnada com autoridade robótica — e o usuário não perdoa.

Terceiro ponto: avaliação. Offline, muita gente corre para RAGAS, G-Eval e similares. São úteis como triagem, mas o que realmente importa é correlação com métricas de produto: resolução de tickets sem agente humano, tempo até ação útil no CRM, queda de back-and-forth em e-mails. Times mais maduros rodam A/B com políticas rígidas: mesmo corpus, variação de prompt, degradação controlada de contexto, e logging com OpenTelemetry para traçar cada hop (retriever → re-ranker → LLM → ferramentas). Não é pedantismo: quando o P95 sobe de 2,1s para 4,7s, a adoção cai de forma não linear. O GitHub percebeu cedo: latência é funcionalidade quando você escreve código; interrupção mata flow.

Ferramentas e function calling são o quarto fosso. Esquema drift em JSON é inevitável; evoluir Pydantic sem quebrar chamadas agente→ferramenta exige versionamento explícito e contratos testáveis. O padrão saudável: registrar ferramentas via catálogo (nome, schema, sinais de confiabilidade), simular ambiente hostil com inputs ruins e injetar sabotagens controladas (campos extras, formatos borderline). E logar não só o “tool_name” mas a árvore de decisão do orquestrador (LangGraph, Guidance, DSPy; escolha seu veneno). Agentes que “alucinam” ferramentas raramente são místicos — são mal treinados sobre affordances e timeouts.

Segurança e governança não são pós-crédito. Redação de PII com Presidio ou equivalente precisa vir antes do embedding; do contrário você grava RG no vetor e torce para ninguém fazer um nearest neighbor entusiasmado. Guardrails baseados em LLM (como classificadores de saída) quebram quando o atacante está no documento, não no prompt — injeção por conteúdo é hoje o vetor mais ignorado. Policy engines do tipo OPA ajudam a centralizar o que o assistente pode ou não fazer (compartilhar links, enviar e-mails, criar ordens de compra), e trilha de conformidade deveria anexar a cadeia de contexto que levou a cada ação. Parece burocracia até o auditor pedir “mostre como essa resposta foi gerada”.

Há também o atrito cultural. O Slack AI precisa parecer Slack — conciso, com aquele tom meio seco. O mesmo vale para bots que vivem dentro de CRMs, ERPs, IDEs. O melhor prompt do mundo não sobrevive a um tom desalinhado com o produto. Times que acertam criam guias de voz para a IA tão específicos quanto os do design system: persona, taboo words, nível de hedging, exemplos de boas e más respostas. E, crucialmente, deixam o bot dizer “não sei” com dignidade.

Exemplos do mercado contam histórias úteis. A Salesforce empurrou o Einstein com Data Cloud no papel de fonte de verdade: não é sobre “um modelo melhor”, é sobre controle de dado, lineage e políticas por objeto — um desenho que vende para compliance. A Atlassian, ao levar IA para Jira/Confluence, teve de encarar permissionamento detalhado e contexto por issue/space: recuperação é trivial até colidir com security boundaries. A GitHub, no Copilot Chat, explora code search proprietário para sugerir pontos de extensão do repositório: RAG, sim, mas com re-ranking treinado em sinal de desenvolvedores reais. Em todos os casos, a mágica é menos “sintaxe” e mais “semântica com pedigree”.

Trade-offs? Muitos. Um re-ranker pesado melhora precisão, mas encarece e adiciona 200–400ms por chamada. Janelas de contexto maiores reduzem esforço de prompt, mas desorganizam atenção do modelo e elevam a conta. Fine-tuning dá tom consistente, porém congela viés: você compra menos variância ao preço de mais manutenção. E tem o velho risco jurídico: modelos que explicam políticas internas às vezes inventam onde a política é ambígua — o que força o time a consertar a política, não o bot. Inconveniente, porém útil.

No fim, a métrica brutal para decidir se seu copiloto vive ou morre é chata: redução de custo operacional sem destruir NPS. Ticket deflection com qualidade, reuniões mais curtas, playbooks acionáveis, código gerado que compila e passa review. O resto é conversão de slide.

O detalhe que manda em tudo

Copilotos que funcionam tratam “dados, política e latência” como a tríade sagrada. O modelo é importante, claro, mas vira commodity rápido. O mofo aparece em outro lugar: pipelines que não atualizam, evals que não medem nada útil e decisões de roteamento que ignoram o contexto do negócio. Quem domina o backlog — não o benchmark — controla o produto. E, honestamente, a parte menos glamourosa é a que mais fideliza: quando o bot sabe quando calar a boca, devolve a fonte certa e responde antes do usuário se arrepender de ter clicado no ícone.

Related Tags:

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts