Matias Schimuneck Principal Engineer, Strattum Uma mesma empresa costuma existir três vezes dentro da operação: como razão social no ERP, como conta com nome fantasia no CRM e como organização identificada por domínio de e-mail no helpdesk. Para quem trabalha ali, os três registros são a mesma conta. Para um modelo de linguagem, são três clientes distintos, e a resposta sai com a soma errada. O modelo chega fluente em português e sem nenhuma noção do vocabulário daquela operação. O que preenche essa lacuna é uma ontologia do negócio, a camada que diz o que cada termo e cada entidade significam nesta empresa específica. Ela é um dos três componentes de um Company Brain, a camada que conhece a empresa: quais dados existem, onde vivem, como se relacionam e quem pode ver o quê.
Vale separar as três peças. O grafo de conhecimento modela as entidades e as ligações entre elas. A camada semântica traduz a pergunta em consulta com a permissão correta. Entre as duas fica a ontologia do negócio, que resolve o significado.
Pergunte a três times o que é um lead qualificado. Marketing conta quem preencheu o formulário e bate o perfil. Pré-venda conta quem aceitou a reunião. Vendas conta quem tem orçamento aprovado. Sem a ontologia registrada em algum lugar, o modelo escolhe uma das três definições em silêncio, e a escolha muda a cada pergunta.
Unificar registros de sistemas diferentes é a parte que mais consome tempo de engenharia, e é onde a decisão de arquitetura aparece com mais clareza.
A abordagem mais simples compara o nome e unifica o que parece igual. Ela quebra cedo, porque razão social, nome fantasia e domínio de e-mail raramente coincidem. O critério que usamos pontua vários atributos ao mesmo tempo, documento fiscal, domínio, endereço, histórico de reado com o cliente.
Acima do limiar, os registros viram uma entidade só. Abaixo, seguem separados. Na faixa do meio, a sugestão de merge vai para uma pessoa decidir. Escolhemos essa faixa intermediária porque um merge errado custa mais caro que um duplicado: ele mistura o histórico de duas empresas, entra no sistema com cara de verdade e ninguém percebe até alguém cobrar a fatura da conta errada. Cada unificação fica registrada com o critério que a sustentou, o que permite desfazer e auditar depois.
Um relacionamento em banco de dados é uma chave estrangeira. O modelo recebe algo como customer_id e precisa adivinhar o que aquilo significa naquela operação.
Por isso cada relação na ontologia do negócio carrega uma descrição em linguagem natural, escrita com o vocabulário da empresa. A ligação entre pessoa e empresa deixa de ser um campo e passa a ser uma frase: esta pessoa fez uma compra desta empresa. A ligação entre contrato e conta diz qual cláusula vale para quem.
Isso muda o resultado por um motivo direto. O modelo consome linguagem, e é o protocolo aberto que conecta modelos a fontes de dado, o MCP, que entrega esse recorte verbalizado no momento da pergunta. Quando a relação chega descrita, a resposta consegue apontar o caminho percorrido, e quem revisa confere sem abrir quatro telas.
Essa é outra decisão de arquitetura, e ela reduz custo já no primeiro mês de projeto.
Conectar uma fonte não significa ingerir tudo o que existe nela. O primeiro passo é mapear o schema e listar o que está disponível. O segundo é sentar com quem conhece a operação e escolher as tabelas que respondem pergunta de negócio. A maior parte de um banco de produção é log, fila e tabela auxiliar que nunca aparece em pergunta de diretoria. Ingerir esse volume gera custo de processamento e ruído na modelagem.
Documento entra pelo mesmo critério. Contrato e aditivo viram fonte de entidade quando estão em formato consultável, com as partes, as datas e as cláusulas extraídas e ligadas à conta no grafo.
Existe hoje um caminho de geração totalmente automática, em que a ferramenta lê o schema e devolve uma ontologia pronta. Ele funciona para a estrutura e falha na intenção. O schema mostra que existe uma coluna chamada status_2. Ele não diz qual status conta como venda fechada no relatório que o conselho olha.
Escolhemos geração semiautomática com aprovação humana. O fluxo é: discovery do schema, seleção das tabelas relevantes, entrevista com as pessoas do negócio para extrair as regras que não estão em lugar nenhum, e então a geração da ontologia do negócio a partir desse material.
A mesma regra vale depois da entrega. Quando um conector novo entra, o agente compara a estrutura nova com o que já está modelado e sugere a atualização. Nada é aplicado sem aprovação de alguém da empresa. Versões diferentes de ontologia podem rodar em comparação para descobrir qual responde melhor às perguntas reais do time.
A primeira versão vai estar errada em algum ponto. Isso se corrige com uso, quando as perguntas reais mostram onde a modelagem não bate com a operação.
Ela também depende de alguém do negócio com mandato para bater o martelo sobre definição de termo. Time só técnico entrega uma ontologia que o comercial e o financeiro não reconhecem como a operação deles.
Um catálogo mínimo de dados também encurta o trabalho. Empresa que já sabe quais sistemas são fonte de verdade para cada assunto encurta a fase de discovery pela metade. Quem ainda não tem isso pode começar pelo inventário: quais sistemas existem, quem é dono de cada um e quais termos cada área define de um jeito diferente.
Escolha uma pergunta que hoje atravessa três sistemas e leva dois dias para ter resposta. Liste as entidades que ela toca, os termos ambíguos que aparecem no caminho e os lugares onde a mesma empresa está cadastrada duas vezes. Esse é o recorte inicial, e ele cabe em algumas semanas de trabalho.
Se quiser testar o recorte da sua com quem está modelando isso todo dia, me chama aqui.
Fale com um especialista da Strattum sobre ontologia do negócio, resolução de entidade e o Company Brain da sua empresa.