Aqui está um cenário que ocorre constantemente nas equipes de software program empresarial. Um gerente de produto pergunta ao assistente de IA da empresa: “Quem são nossos principais clientes neste trimestre?” O sistema retorna uma lista limpa e classificada. Parece certo. Todo mundo segue em frente.
Exceto que o grupo de produtos outline “prime” por engajamento. As finanças o definem pela receita líquida. As vendas definem isso pelo tamanho do negócio. A IA escolheu uma interpretação, apresentou-a com whole confiança e ninguém percebeu até que uma decisão estratégica foi tomada com base em números que significavam algo diferente para cada pessoa na sala.
Isto não é alucinação na forma como as pessoas costumam falar sobre isso. O sistema não inventou nada. Apenas fez uma escolha sobre o significado que nunca foi sua escolha.
O verdadeiro problema não é o modelo
Há uma suposição generalizada na adoção de IA empresarial de que se você escolher o modelo certo, ajustá-lo cuidadosamente e alimentá-lo com bons dados, você obterá resultados confiáveis. Essa suposição ignora o modo de falha actual.
LLMs são extraordinariamente bons em idiomas. Eles não são bons em significado organizacional. Pergunte à sua IA qual é a sua taxa de rotatividade e observe o que acontece. O modelo não sabe se você mede a rotatividade no nível da assinatura ou no nível do cliente. Ele não sabe se você conta os downgrades ou os ignora. Ele não sabe se contas corporativas com múltiplas licenças são tratadas de maneira diferente. Estas não são respostas enterradas em algum documento em algum lugar. São decisões organizacionais que residem no conhecimento tribal, nos acordos de equipe e nos comentários do modelo de dados escritos há dois anos por alguém que já deixou a empresa.
O modelo irá inferir. E a inferência, apresentada com confiança, é uma desvantagem.
Incorporações não resolvem isso
A resposta padrão para esse problema é uma melhor recuperação. Incorpore sua documentação, extraia os pedaços mais relevantes, dê mais contexto ao modelo. É uma intuição razoável e uma melhoria parcial. Mas isso não resolve o problema subjacente.
Os embeddings medem a proximidade de dois trechos de texto no espaço vetorial; eles não dizem nada sobre se uma determinada interpretação é realmente correta para a sua organização. “Receita” e “lucro” são vizinhos no espaço de incorporação porque aparecem juntos constantemente na redação financeira. No seu sistema de relatórios financeiros, combiná-los é um erro grave. Nenhuma recuperação resolve isso porque a resposta correta não está em nenhum documento. Está em uma decisão que sua equipe financeira tomou sobre como definir as coisas, provavelmente anos atrás, provavelmente nunca escrita em um formato que uma máquina possa usar.
O mesmo problema estrutural aparece em todos os lugares. “Usuário ativo” significa algo diferente para sua equipe de engenharia (uma chamada de API) e para sua equipe de produto (uma transação concluída). “Conversão” significa uma solicitação HTTP bem-sucedida para uma equipe e uma progressão de inscrição para pagamento para outra. “Engajamento” é a frequência do evento em um painel e a profundidade da sessão em outro. A recuperação não resolve a ambiguidade de definição. Ele apenas recupera mais texto que contém a ambigüidade.
Figura 1: Sem uma camada semântica, os resultados do LLM são plausíveis, mas inconsistentes. Com um, eles estão fundamentados e corretos.
O que realmente precisa acontecer
A resposta é uma camada semântica, uma representação estruturada e legível por máquina do que os termos da sua organização realmente significam. Não é um glossário. Não é melhor documentação. Uma codificação formal de entidades, relacionamentos, métricas e regras de desambiguação que fica entre seus dados e seu sistema de IA, para que quando alguém perguntar sobre rotatividade, contas ativas ou clientes principais, o sistema não esteja adivinhando.
Esta não é uma ideia nova no mundo dos dados. Ferramentas como dbt e Looker o aplicam à inteligência de negócios há anos. A novidade é a pressão para estendê-lo aos pipelines de IA, e as ferramentas estão se atualizando: a camada semântica dbt agora oferece suporte à integração direta de pipelines de IA, e plataformas como Dice estão construindo conexões LLM nativas exatamente para esse propósito.
O ponto de partida prático para a maioria das equipes é uma abordagem baseada em esquema: Arquivos de configuração YAML ou JSONcontrolado por versão no git, injetado no momento da inferência. Menos rigorosas que as ontologias formais, mas dramaticamente mais sustentáveis e geralmente suficientes. Se você já possui uma camada semântica de BI, seu trabalho de definição está praticamente concluído. O desafio é torná-lo consultável quando a IA precisar.
O problema mais difícil é organizacional
Aqui está o que a maioria dos posts sobre arquitetura deixa de fora: a implementação técnica é a parte fácil. Conseguir que três departamentos concordem sobre o que significa “ativo” não é. Construir e manter uma camada semântica força conversas que as organizações evitam rotineiramente e traz à tona divergências que produzem silenciosamente resultados inconsistentes há anos. Isso é desconfortável. Esse também é o ponto.
Há um teste simples que utilizo: se um novo contratado precisar ler documentação interna para entender o que significa um termo comercial importante, esse termo pertence a uma camada semântica, não a um immediate.
A próxima fase da IA empresarial não é sobre qual modelo você usa. Trata-se de quão bem sua organização sistematizou seu próprio conhecimento para consumo de máquinas. Da engenharia imediata à engenharia de contexto. De pipelines de dados a pipelines de significado. As equipes que acertarem isso produzirão resultados de IA que não são apenas fluentes; eles estarão corretos. Em sistemas empresariais, ser fluente não é suficiente. Se a sua IA não estiver definidamente correta, ela não será operacionalmente confiável.
Em vez de perguntar: “Quem são nossos principais clientes?”– Defina:
TopCustomer = Revenue_last_90_days > US$ 50 mil E active_subscription = true