Arthur Guttilla Head of Product Marketing, Strattum Com passagens na Amazon Web Services e no Google, Guttilla trabalhou diretamente com fundadores de startups e empresas de capital de risco, compreendendo as necessidades de empresas tecnológicas em estágio inicial na interseção entre tecnologia e negócios.
Em resumo
Quando alguém pergunta se um cliente está em dia, a resposta raramente está em um único sistema. O contrato fica na gestão de contratos, as faturas no ERP, os chamados no helpdesk e o histórico comercial no CRM. Cada sistema guarda bem os próprios registros, e nenhum deles guarda a ligação com os registros dos outros. O grafo de conhecimento é a estrutura que registra essas ligações. Ele é um dos três componentes do Company Brain, a camada que conhece a empresa: quais dados existem, onde vivem, como se relacionam e quem pode ver o quê.
A estrutura tem dois elementos. Os nós representam as entidades do negócio, como cliente, contrato, pedido, chamado, produto e pessoa. As arestas representam as relações entre elas, e cada relação tem nome: o cliente assinou o contrato, o contrato originou o pedido, o pedido gerou a nota fiscal, o cliente abriu o chamado.
Cada nó carrega atributos, como vigência, valor, status ou severidade. As arestas também podem carregar atributos, como a data em que a relação começou. Com isso, saber a situação de um cliente passa a ser um percurso pelas relações que partem daquele nó, em vez de uma busca em quatro telas.
O conceito ganhou visibilidade em 2012, quando o Google apresentou o Knowledge Graph como forma de tratar buscas como coisas do mundo real, com mais de 500 milhões de objetos catalogados na primeira versão. Algumas traduções usam o nome gráfico de conhecimento. Nas empresas, um grafo de conhecimento opera em escala menor e resolve o mesmo problema: entender a qual entidade um nome se refere e quais outras entidades estão ligadas a ela.
Bancos relacionais também ligam registros, por meio de chaves estrangeiras. A diferença está no alcance. Uma chave liga tabelas dentro do mesmo sistema, e o ERP não tem chave para o chamado do helpdesk nem para a oportunidade do CRM. As ligações entre sistemas costumam existir apenas na memória de quem conhece a operação ou em planilhas de conciliação mantidas à mão.
O grafo também guarda a história das relações. Quando um contrato é renovado, o vínculo anterior continua registrado com a data de encerramento, e uma pergunta sobre o ano passado é respondida com as relações que valiam naquele período. Planilhas de conciliação raramente preservam essa linha do tempo, porque cada versão sobrescreve a anterior.
O grafo de conhecimento torna essas ligações explícitas e consultáveis. Uma pergunta como quais clientes com renovação nos próximos noventa dias têm chamado crítico aberto atravessa três sistemas. Em um modelo tabular, ela exige junções entre bases que não foram desenhadas para conversar. No grafo, ela é um caminho de duas relações a partir dos contratos.
Antes de ligar registros, é preciso saber quais registros representam a mesma coisa. A mesma empresa aparece no CRM pela razão social, no ERP pelo CNPJ e no helpdesk pelo domínio de e-mail. A mesma pessoa pode ter um cadastro como contato comercial e outro como usuária do produto. Esse trabalho se chama resolução de entidades, e por isso o termo grafo de entidades também circula no mercado.
A resolução combina regras determinísticas, como o mesmo CNPJ, com critérios de semelhança, como nome e endereço parecidos. Os casos ambíguos vão para revisão de uma pessoa da área, porque juntar dois clientes diferentes em um único nó contamina todas as respostas que passam por ele.
Cada vínculo criado fica registrado com a regra que o originou e com os sistemas envolvidos. Quando alguém questiona por que dois cadastros foram tratados como o mesmo cliente, a resposta está no próprio grafo, e a correção de um vínculo errado se propaga para todas as consultas seguintes.
Um modelo de linguagem recebe texto e devolve texto. Sozinho, ele não tem como saber que um chamado pertence ao mesmo cliente do contrato que vence no próximo mês. Quando o contexto chega como trechos soltos de documentos, o modelo preenche a lacuna com a continuação mais provável, e daí vem boa parte das respostas erradas em ambiente corporativo.
Com o grafo de conhecimento, o agente consulta a entidade e recebe as relações relevantes já resolvidas. No Company Brain, esse recorte é servido via MCP, o protocolo aberto que conecta modelos a fontes de dados, e cada relação aponta o sistema de onde veio. A resposta passa a ter um caminho verificável: este cliente, por este contrato, com estes chamados.
Um grafo de conhecimento sem definições acordadas liga registros com rótulos ambíguos. Se vendas e finanças discordam sobre o que é cliente ativo, o nó cliente ativo carrega duas verdades. Essa definição é papel da ontologia do negócio, o segundo componente do Company Brain.
O grafo também precisa respeitar quem pode ver o quê. A relação entre um contrato e a margem negociada interessa à controladoria e deve ficar restrita a quem já tem esse acesso no ERP. No Company Brain, a permissão é herdada do sistema de origem, e o grafo devolve a cada pessoa apenas as relações que ela já pode ver.
Modelar a empresa inteira antes de responder a primeira pergunta é uma forma frequente de travar o projeto. O ponto de partida recomendado é uma pergunta recorrente que hoje atravessa dois ou três sistemas, como o briefing de uma conta antes da reunião comercial. Ela define as primeiras entidades, as primeiras relações e as primeiras fontes.
A partir daí, cada novo caso de uso reaproveita o que já foi modelado e acrescenta apenas o que falta. O grafo de conhecimento ganha valor com o tempo porque cada projeto parte das entidades e relações que os anteriores deixaram resolvidas.