Partida a frio não é uma página em branco
Algumas semanas atrás argumentei que a Web Semântica não fracassou porque as ontologias estavam erradas. Ela fracassou por três custos. Projetar o esquema, preenchê-lo e mantê-lo atualizado. A manutenção é o que as pessoas citam, e é o último dos três. Os dois primeiros passam despercebidos com mais facilidade, e muitos projetos nunca chegaram longe o bastante para a manutenção virar o problema.
Deixei duas perguntas em aberto ali: se um esquema pode ser aprendido, e se ele pode ser preenchido sem que alguém o digite.
Agora prototipamos um subconjunto simples dos dois primeiros. Veja o que aprendemos fazendo isso.
O erro na expressão “partida a frio”
Partida a frio sugere uma página em branco. Nenhuma entidade, nenhum tipo, nada sobre o que construir, e alguém precisa sentar e digitar os primeiros mil registros. Essa visão é o motivo de preencher um modelo parecer tão caro, e é por isso que toda proposta corporativa de uma ontologia do seu próprio negócio terminava com um orçamento de serviços.
Quase nenhuma empresa está realmente começando do zero. Uma lista de entidades quase sempre já existe, está no CRM, mas é ruim: duplicada, meio abandonada, com três registros para a mesma conta e um campo que ninguém preenche desde 2023. No DAFFIE, o banco de dados de entidades por trás da resposta a perguntas que o Google lançou em 2005, enfrentamos uma versão mais rica do problema, porque a web aberta não tem lista inicial. Uma empresa tem.
Então o primeiro passo é importar, depois corrigir.
O que fizemos
Começamos pelos clientes, porque é o tipo que toda empresa tem e o que tem mais estrutura existente em que se apoiar.
Importar a lista inicial. Extraia a lista de contas do CRM. Aceite que ela está errada. O que ela dá é um ponto de partida: o conjunto de nomes com que a empresa acha que se relaciona.
Corrigir a partir do fluxo de mensagens. Mensagens são um subproduto de fazer o negócio, e atualizar um campo do CRM é uma tarefa separada que alguém precisa lembrar de fazer. Então, para uma conta com que você está trabalhando ativamente, o fluxo de mensagens geralmente está à frente do registro. Cargos, endereços, quem realmente trabalha lá agora, quais negócios estão ativos, o que foi combinado. As mensagens são a fonte e o CRM é o cache desatualizado.
Encontrar o que a lista inicial deixou de fora. Empresas com que vocês lidam o tempo todo e para as quais nunca criaram um registro. Alguém vai procurar, não encontra nada e segue em frente. A falta de completude é metade do motivo de um CRM frustrar as pessoas, e a desatualização é a outra metade. As mensagens têm essas empresas, porque a empresa esteve conversando com elas o tempo todo.
Ler a desatualização como um sinal sobre a lista. Uma conta com que ninguém trocou mensagem em dezoito meses provavelmente é um ex-cliente. O CRM ainda a chama de cliente, mas as mensagens podem dizer o contrário, então um registro que as mensagens nunca tocam é um motivo para perguntar se ele deveria estar na lista.
Nada disso exigiu que alguém digitasse um registro do zero. Exigiu que as pessoas corrigissem o que voltou, o que é um trabalho muito menor. Reagir a um registro preenchido leva segundos e dá para fazer enquanto se trabalha. Produzir um do nada foi o que tornou caro preencher um modelo em primeiro lugar.
A parte que eu não esperava que funcionasse
Clientes eram o tipo fácil. A pergunta mais difícil, a que eu disse no último texto que ninguém tinha resolvido, é em quais tipos uma empresa se apoia, para começo de conversa. Clientes, concorrentes e produtos para uma empresa; casas de show, artistas e produtores para outra.
Não resolvemos isso. O que descobrimos é que uma máquina não precisa fazer isso sozinha.
Ao processar o fluxo de mensagens, grupos de nomes próprios se comportam de forma diferente dependendo do que são. As coisas que uma empresa trata como clientes aparecem num conjunto de padrões; fornecedores em outro; as ferramentas que ela usa num terceiro. Esses padrões são fortes o bastante para propor um tipo, o que é um pedido muito menor do que decidir por um.
Então o sistema propõe e uma pessoa responde. Esse é um tipo que importa para você? Os nãos acabaram sendo tão úteis quanto os sins, porque um tipo rejeitado não precisa de mais análise.
Chame de sugestão de esquema com uma pessoa no processo, e o ciclo é curto o bastante para ninguém se incomodar.
Por que isso não cai na velha falha
O que matou as ontologias mantidas à mão não foi a ideia de tipos. Foi a rigidez: todo cliente precisa preencher estes onze atributos, e alguém é responsável por manter essa lista correta. A Unisys documentou seus metadados do SharePoint para o Dublin Core em 2005, e os vocabulários controlados eram mantidos numa planilha por um Corporate Knowledge Architect.
O que construímos é mais leve. Os tipos são essenciais: saber que a Acme é cliente e não concorrente muda o que um agente deve fazer com uma mensagem dela. Uma lista fixa de atributos não é, e foi ela que exigiu o cargo dedicado.
Você precisa de estrutura suficiente para que um agente possa agir, e não mais que isso.
O que ainda está em aberto
Tipos sem lista inicial. Clientes foram importados sem problemas porque o CRM tinha uma lista. Ninguém mantém um sistema de registro para “as regras operacionais que seguimos quando um cliente escala um problema”, e esse conhecimento é o motivo pelo qual vale a pena resolver todo esse problema. O ciclo de propostas acima ajuda, mas não termina o trabalho.
Se a lista se mantém sozinha. Nós a construímos uma vez, na importação. Uma empresa muda depois disso: começa a lidar com empresas que nunca estiveram na lista e para de lidar com outras que ainda estão. Captar as duas coisas sem ninguém vigiando é a parte que ainda não demonstramos, e é a mesma armadilha dos últimos vinte anos, porque o custo que nunca acaba é o que você não consegue avaliar em um trimestre.
Se isso se generaliza. Os tipos de entidade em que uma empresa se apoia não são os tipos de outra, e nada aqui foi testado em empresas suficientes para dizer até onde isso vale.
Por que vale a pena fazer isso agora e não valia em 2005
O argumento do último texto se mantém. A estrutura criada hoje de manhã é usada hoje à tarde, porque o consumidor finalmente existe. Em 2001 você escrevia RDF para leitores que ninguém tinha construído ainda, e o trabalho ficava esperando. Essa recompensa adiada é o motivo pelo qual todo modelo de empresa mantido à mão se deteriorou, e é exatamente o que acontece com a wiki em que ninguém mexeu desde que a pessoa que a escreveu saiu.
Um agente lê o que você registrou hoje. Isso muda a conta dos três custos, e é por isso que o segundo acabou se mostrando viável quando antes não era. O primeiro ficou mais fácil ao mesmo tempo, quando propor um tipo substituiu decidir por um.
A manutenção se divide em duas, e só metade dela tem resposta. Manter atualizados os dados sobre uma entidade é o que o último texto defendeu: um workflow que corrige um campo enquanto roda é manutenção que ninguém precisa agendar. Manter a própria lista atualizada é outro problema, e fizemos isso uma vez, na importação. Se uma empresa com que vocês começaram a lidar na semana passada entra na lista sozinha, e se uma que ficou em silêncio há um ano sai dela, ainda está em aberto.