Build vs Buy: por que só um LLM erra nos customer insights

‍

Toda liderança já ouviu esse discurso: exporte os seus tickets, calls, reviews e surveys, ou conecte o seu LLM ou AI harness favorito (Claude, ChatGPT, Gemini) ao MCP deles. Depois, pergunte qualquer coisa. Entregue "customer intelligence" num fim de semana, pule o fornecedor, guarde o orçamento.

É a ideia mais tentadora em CX no momento. Ao longo dos onze posts da nossa série Build vs Buy, desmontamos essa ideia uma capacidade de cada vez. Este fechamento reúne o argumento inteiro num só lugar, com as provas.

Aqui vai a versão curta: customer insights precisos não vêm do modelo, vêm do customer context por trás dele. Quando testamos um LLM puro contra uma classificação estruturada em 136.864 reviews reais de clientes, a abordagem pura produziu um problema principal diferente a cada execução, marcou 30 pontos a menos em precisão e queimou a maior parte da sua computação refazendo o mesmo trabalho. Quando uma decisão real depende desse resultado, o que costuma acontecer, isso não é um erro de arredondamento. No nosso estudo, a diferença entre duas leituras plausíveis dos mesmos dados foi a diferença entre corrigir um problema real e financiar uma correção cara para um sintoma.

É isso que está em jogo. Agora, vamos às evidências.

O teste: 136.864 reviews, três abordagens, três execuções cada

Queríamos saber o que realmente acontece quando você aponta um LLM para customer signals brutos em escala de produção. Por isso, construímos o experimento que a maioria dos debates de build vs buy pula.

Reunimos 136.864 reviews reais de seis grandes marketplaces e fizemos as perguntas que toda liderança de CX e de produto faz: quais são os principais problemas, qual o tamanho de cada um e onde agir primeiro. Rodamos três setups lado a lado:

1. Uma customer context layer estruturada. Os signals são classificados antes, contra uma taxonomia governada, e o LLM raciocina em cima dessa estrutura. É assim que a Birdie funciona.
2. Um LLM com a mesma taxonomia na mão. Sem estrutura, mas com toda vantagem que um time interno esperto poderia dar a ele, incluindo as nossas próprias definições de categoria.
3. Um LLM puro em cima de dado bruto. O projeto de fim de semana. Conecte o dado, escreva um bom prompt, pergunte.

Cada setup respondeu a cada pergunta três vezes. Medimos a precisão contra rótulos de ground truth validados por especialistas humanos, mantidos fora do treino. Mesmo dado, mesmas perguntas, mesma família de modelo. A única variável foi a estrutura.

Cinco jeitos pelos quais o caminho do LLM puro erra nos customer insights

1. Pergunte a mesma coisa duas vezes e receba duas respostas diferentes

Reprodutibilidade é a primeira coisa que morre. Nas três execuções, a abordagem estruturada devolveu a mesma lista dos 10 principais problemas todas as vezes: 100% de sobreposição. O LLM com a taxonomia chegou a 67%. O LLM puro chegou a 0%. Não é "um pouco instável". É sobreposição zero. Um problema número um diferente em cada execução, mesmo brincando com temperatura do modelo, seeds e por aí vai.

2. Cobertura não é precisão

LLMs fazem amostragem porque precisam. Os seus signals podem não caber numa context window, então o modelo lê uma fatia e conta uma história confiante sobre o todo. Dá para contornar o limite com chunking e pipelines bem construídos, e times fazem isso. Mas aí aparece um problema mais sutil: os próprios rótulos erram com mais frequência.

‍

Medida contra o ground truth rotulado por especialistas, a camada estruturada tirou um F-score de 95. O LLM trabalhando com a mesma taxonomia tirou 65. O F-score importa porque equilibra precisão (quantas respostas estavam realmente certas) e recall (quantas ele deixou passar). Um único número pode parecer bom escondendo as duas falhas, e é exatamente por isso que avaliações "LLM-as-judge" que não reportam nenhum dos dois não deveriam tranquilizar ninguém.

Esse é o paradoxo da cobertura: rotular mais volume com um classificador mais fraco não te dá mais verdade. Te dá mais volume rotulado errado, entregue mais rápido.

3. Mesmo com a sua taxonomia na mão, as contagens não se sustentam

O resultado mais surpreendente não foi o LLM puro falhando. Foi o LLM bem equipado falhando. Demos a ele a taxonomia exata da Birdie, as mesmas definições de categoria que o nosso pipeline estruturado usa, e pedimos para ele dimensionar os problemas.

O mesmo problema, "atraso na entrega", foi contado 1.385 vezes num setup e 7.481 vezes no outro. Isso é uma diferença de 5,4x no tamanho do mesmo problema, a partir do mesmo dado, usando as mesmas definições. Priorize por uma contagem e atraso na entrega é uma reclamação de nicho. Priorize pela outra e é a casa pegando fogo.

Uma taxonomia não é um documento que você anexa a um prompt. É uma disciplina que você aplica de forma idêntica a cada signal, todos os dias, e governa à medida que as categorias evoluem, para que este trimestre continue comparável ao trimestre passado. Essa governança é a parte que você não resolve escrevendo um prompt melhor.

4. Perguntas que cruzam fontes multiplicam o erro

Decisão real raramente mora dentro de um único dataset. As perguntas que movem orçamento cruzam sistemas: os clientes que reclamam de onboarding também aparecem no churn? O problema que dispara nos reviews bate com o que os agentes ouvem nas calls? Cada cruzamento entre uma fonte não estruturada e outro sistema perde precisão, e as perdas se multiplicam. No nosso estudo, a precisão entre fontes cruzadas ficou perto de dois terços de ponta a ponta. O elo mais fraco é sempre a etapa não estruturada, e nenhuma engenharia de prompt resolve isso, porque o problema não é o raciocínio. É o chão em que o raciocínio pisa.

5. Você paga o modelo para refazer o mesmo trabalho, para sempre

Em cima de dado bruto, um LLM gasta de 68 a 75% da sua computação reestruturando os mesmos signals a cada execução, antes mesmo de começar a responder a sua pergunta. Estruture uma vez, e toda pergunta depois disso sai barata. Nas nossas medições, a abordagem estruturada saiu até 5,3x mais barata por análise.

Ou seja, o caminho de construir por conta própria não custa só um time de engenharia para montar e cuidar de pipelines. Ele também aluga o mesmo entendimento repetidamente, a preço de inferência.

LLM puro vs. customer context layer, lado a lado

Não é um problema de modelo. É um problema de contexto.

Nada disso é argumento de que LLMs são ruins. Os modelos são notáveis, e só tendem a melhorar. É um argumento sobre o chão em que eles pisam.

Um LLM respondendo perguntas sobre os seus clientes está fazendo dois trabalhos ao mesmo tempo: entender o que cada signal significa, e raciocinar sobre o padrão. Quando você alimenta ele com exportações brutas, está pedindo para refazer o primeiro trabalho do zero a cada pergunta, de forma invisível, sem ground truth, sem garantia de consistência e sem memória de como fez da última vez. Tudo que vem depois herda essa instabilidade.

Uma customer context layer faz o primeiro trabalho uma vez, direito. Ela reúne cada signal que os seus clientes mandam, entre tickets, calls, reviews, surveys, notas de CRM e product analytics, num lugar só. Classifica 100% deles, não uma amostra, contra uma taxonomia governada que significa a mesma coisa para todo time e continua comparável conforme evolui. Ela conecta esses signals uns aos outros e aos números que a liderança usa para agir, como o ARR em risco por trás de um problema. E mantém uma nota auditável: F-scores medidos contra rótulos de especialistas, não um modelo corrigindo a própria prova.

É sobre essa base estruturada que o nosso produto de customer intelligence constrói, e é por isso que as respostas continuam as mesmas entre segunda e quinta-feira. O loop ao qual voltamos ao longo da série roda em cima disso: Signal, Diagnose, Act, Prove, Learn. Os signals entram de cada fonte do seu stack, são estruturados e quantificados, disparam uma ação, e o impacto dessa ação é medido contra as mesmas categorias estáveis que a revelaram. Essa última etapa, provar que uma correção funcionou, só é possível quando as categorias deste trimestre significam a mesma coisa que significavam no trimestre passado.

E num mundo de IA isso importa mais, não menos. Todo mundo consegue construir rápido agora. Muito poucos times constroem sobre fundações coerentes. Contexto estruturado está virando o ativo escasso, porque é a única coisa que o modelo não consegue gerar sozinho.

A resposta não é build ou buy. É build em cima de buy.

É aqui que a série chega, e não é em "nunca construa".

Os times que tiram mais proveito de IA fazem as duas coisas. Eles compram a camada difícil e especializada: ingestão em escala, classificação de cobertura total, governança de taxonomia, medição de precisão, a conexão entre signals e receita. Depois constroem livremente em cima disso, porque agora os LLMs, agentes e ferramentas internas deles têm chão firme embaixo.

É exatamente para isso que serve a camada MCP. Qualquer pessoa do seu time pode fazer uma pergunta em linguagem natural e receber uma resposta fundamentada em 100% dos seus signals estruturados, não uma amostra de texto bruto. Os seus analistas, os seus agentes e, sim, os seus LLMs, todos consultam o mesmo contexto governado. O projeto de fim de semana vira viável, porque a parte que o tornava perigoso é resolvida por baixo.

Faça-você-mesmo os workflows. Não faça-você-mesmo o contexto.

"Não dá para resolver isso com prompt melhor, RAG ou fine-tuning?"

Essa é a objeção que mais ouvimos, e ela merece uma resposta de verdade.

Prompt, retrieval e fine-tuning melhoram o trabalho de raciocínio. Nenhum deles cria ground truth. RAG recupera pedaços do mesmo texto não estruturado e herda a mesma ambiguidade. Fine-tuning ensina ao modelo o seu tom e o seu domínio, não uma contagem consistente e governada do que aconteceu no mês passado. Prompts melhores reduzem a variância, mas não eliminam ela, e você não vai saber quando isso morde, porque não existe uma nota auditada te avisando.

A segunda objeção é mais discreta: "o nosso time de dados também consegue construir essa camada estruturada". Consegue, e em alguns casos deveria. Mas seja realista sobre o tamanho da tarefa. Não é um pipeline, é um produto: qualidade de classificação medida continuamente contra rótulos humanos, uma taxonomia governada através de cada reorganização e lançamento de produto, cruzamentos mantidos entre cada fonte conforme os formatos mudam, em milhões de signals por mês. Montar isso leva um fim de semana. Fazer isso devolver a mesma resposta duas vezes, com 95 de precisão, por anos, é trabalho do tamanho de uma empresa. Sabemos porque essa é a empresa que construímos.

Pare de apostar a estratégia numa moeda ao ar

Onze posts, uma conclusão. Qualquer LLM produz customer insights. Só o contexto estruturado torna eles precisos, reprodutíveis e dignos de virar ação.

Se o seu problema número um não sobrevive a uma segunda execução, ainda não é um insight. Veja como os seus signals se comportam numa fundação de verdade: agende uma demo.

‍