A Web Semântica não falhou pelas ontologias
As ontologias estão vivendo um momento de novo. A engenharia de IA está redescobrindo RDF e OWL como jeito de manter agentes probabilísticos dentro de fronteiras determinísticas, e recorrendo a vocabulários prontos como schema.org e Dublin Core porque os modelos já os viram. A Latent Space cobriu o revival depois de Frank Coyle, da UC Berkeley, argumentar na AI Engineer World’s Fair que modelos probabilísticos precisam de barreiras lógicas, e de Emil Eifrem, presidente da Neo4j, defender uma camada semântica compartilhada sobre a qual agentes leves rodariam em vez de cada um ser ligado às próprias fontes à mão.
Vi três grandes esforços para tornar conhecimento legível por máquina em escala: os Smart Tags na Microsoft em 2001, que ajudei a construir; os dois SharePoints que saíram no mesmo ano, que acompanhei do outro lado da empresa; e a resposta a perguntas no google.com em 2005, em que fui responsável pelo produto e depois liderei o time de engenharia. Cada um entregou tecnicamente e ainda assim bateu num muro. Manutenção é a razão que costuma ser dada.
É o terceiro de três problemas difíceis. Alguém precisa desenhar o esquema. Alguém precisa povoá-lo antes de ele valer alguma coisa. E alguém precisa mantê-lo em dia para sempre. Três problemas, resolvidos por pessoas, vez após vez, e por duas décadas nada que valesse o esforço. Nenhum dos três projetos era um projeto de Web Semântica, e esse é o ponto: os formalismos diferiam, os problemas não. O que mudou é que um agente pode fazer a manutenção, e o retorno chegou, ou ao menos gente suficiente acredita que chegou para RDF e OWL voltarem à mesa. Quero dizer de saída que estou construindo uma empresa nesse espaço.
Acreditei nos três projetos na época. O que torna este revival diferente não é eu acreditar com mais força, e sim que manter um modelo em dia agora acontece como subproduto do trabalho, em vez de ser serviço de alguém.
Três tentativas
Antes de entrar na Microsoft em 1998 para trabalhar com anotação semântica, fiz um doutorado em processamento de linguagem natural. Levamos pesquisa de laboratórios e universidades a produto e entregamos os Smart Tags no Office XP em 2001.
Um parêntese: a história mais conhecida dos Smart Tags é a do navegador. A Microsoft tirou aquele recurso do Internet Explorer 6 em junho de 2001 depois de editoras reclamarem de a Microsoft transformar as palavras delas em links de escolha própria. Aquela briga era sobre quem controla uma página da web. A versão do Office foi entregue, e se apagou por outra razão.
Todo smart tag tinha dois componentes: um reconhecedor e uma ação. O reconhecedor decidia que uma sequência de texto era de certo tipo. A ação te oferecia verbos para ela. Mandar e-mail a esta pessoa, pôr esta data na agenda, consultar esta ação. Entregamos isso e deixamos você construir os seus.
A Microsoft entregou um SDK para as empresas definirem os tipos que importavam no negócio delas e anexarem as ações que valia tomar sobre eles. Foi ali que quebrou, antes de manutenção sequer ser a questão. Quem desenvolvia não era bom em identificar esses tipos, nem em inventar os verbos que iam com eles. Nenhuma das duas coisas é trabalho de engenharia de software. E não era realmente serviço de ninguém.
Se ninguém é dono do trabalho, há duas saídas: torná-lo serviço de alguém, ou construir algo que não dependa dele. A Microsoft tentou as duas ao mesmo tempo, e eu tinha assento na primeira fila. Em 2001 ela entregou dois SharePoints. O Portal Server, liberado para fabricação naquele março, era o sério. Ele organizava documentos por categoria, com pastas de categoria, perfis de documento e definições de propriedade como objetos de primeira classe. Foi feito para as empresas mais bem equipadas para fazer isso direito, grandes o bastante para ter alguém, ou um time inteiro, cujo serviço de verdade era ser dono da taxonomia. O Team Services era o outro, amplamente disponível em maio com o Office XP e o FrontPage 2002. Era um lugar para pôr arquivos e subir um site, e não exigia conhecimento nenhum em especial.
O Portal Server, e os recursos de taxonomia curada por pessoas nele, estava armado para o sucesso. A Microsoft o apoiava, e os clientes dele eram grandes o bastante para contratar quem entendia de taxonomia. A outra versão é que pegou. O Team Services virou Windows SharePoint Services em 2003 e SharePoint Foundation em 2010, e é dessa linhagem, e não da do Portal Server, que toda versão posterior descende.
Duas apostas, mesma empresa, mesmo ano, e tudo desde então foi construído sobre a que não exigia conhecimento especializado. Preço não é a explicação. Clientes desse tamanho compravam software da Microsoft em acordos corporativos, em que o custo incremental do Portal Server era pequeno. A diferença era demanda.
Lançamos a resposta a perguntas no google.com em 2005. Ela oferecia respostas factuais curtas acima dos resultados. O sistema por trás se chamava DAFFIE, Database of All Fact, Fiction, Information and Exaggeration, e escrevi sobre como ele organizava tudo em torno de entidades e atributos. A abordagem invertia os Smart Tags. Em vez de pedir que quem desenvolvia definisse tipos, varríamos a web e tirávamos os atributos e valores nós mesmos.
Onde a página já tinha estrutura, isso generalizava. Uma tabela é uma tabela, e você lê uma sem conhecer o domínio de antemão. Em todo o resto era sob medida, código escrito à mão para uma fonte por vez, com as ferramentas de extração de informação da época.
Uma linha do post de lançamento diz exatamente onde estava o limite. O DAFFIE sabia sobre “celebridades, países do mundo, os planetas, os elementos, eletrônicos, filmes, e qualquer outra coisa em que tenhamos pensado até agora”.
“Qualquer outra coisa em que tenhamos pensado até agora.” Nada era digitado à mão. Mas os extratores genéricos só alcançavam a estrutura que já existia, e além disso cada domínio novo precisava de alguém de engenharia escrevendo o próprio.
Esse é o problema da partida a frio, e é separado da manutenção: antes de qualquer coisa envelhecer, alguém precisa decidir quais entidades existem e pôr as primeiras. O esquema era uma armadilha nas duas direções. Restrinja e você deixa informação na mesa, porque a web é mais variada que qualquer lista que você consiga sentar e escrever. Deixe aberto e você recebe absurdo, porque a web é caótica. Entidades escritas errado (quem consegue escrever Britney Spears?), atributos sem sentido (clique aqui: 12), valores que não batem com os atributos (altura: azul).
Britney Spears era uma estrela pop quando construímos isso. Ela tinha álbuns, dava shows, tinha cerca de 1,63 m e nasceu em dezembro. Havia também uma contadora em Ohio chamada Britney Spears: outra altura, outro aniversário, sem álbuns. E uma cadela, mais baixa que as duas e bem mais leve, sem álbuns conhecidos. Manter as três separadas era uma luta, mas perder essa luta não te deixa com um buraco nos dados. Te deixa com uma entidade sobre a qual o sistema tem certeza, com a altura média de uma estrela pop, uma contadora e uma cadela. E igualmente errada sobre quase todo o resto.
De volta à Microsoft, a mesma escolha estava sendo feita uma segunda vez. A história do SharePoint não terminou em 2001. Em 2003 a capitulação virou arquitetura. O Portal Server foi reconstruído sobre o Windows SharePoint Services, e a Microsoft disse isso: a versão nova “estende as capacidades do Windows SharePoint Services”. O produto que liderava com uma taxonomia passou a ser uma camada paga sobre o motor que não pedia nenhuma.
A taxonomia voltou mais uma vez. O SharePoint Server 2010 acrescentou o Managed Metadata Service, um repositório central de termos e uma ferramenta de gestão. Mas veja para quem a Microsoft disse que era: a gestão corporativa de metadados é um conjunto de recursos “que permitem que pessoas de taxonomia, biblioteconomia e administração criem e administrem termos e conjuntos de termos na organização”.
Nove anos depois, a resposta para manter o vocabulário de uma empresa em dia ainda era um cargo que você precisava preencher. Isso não é o problema da manutenção resolvido. É o problema da manutenção precificado com base em salários.
As partes da Web Semântica que sobreviveram são aquelas em que o vocabulário é problema de outra pessoa: a marcação schema.org e o JSON-LD, em que você etiqueta contra um vocabulário compartilhado que não teve que inventar. O que nunca chegou é aquilo sobre o que muitas propostas corporativas falavam: uma ontologia do seu próprio negócio, mantida exata a um custo razoável pela sua própria gente. O revival está pegando as partes que funcionaram.
Três problemas, e não um
Manutenção é a razão que costuma ser dada, inclusive por Richard MacManus, que escreveu o texto da Latent Space, e está certa até onde vai. Também é a última de três, e as duas primeiras já tinham parado a maioria dos projetos antes de a manutenção virar a questão.
Desenhar o esquema. Decidir quais tipos importam num negócio não é engenharia de software, e não era serviço de ninguém. Os Smart Tags entregaram um SDK exatamente para isso, mas os tipos nunca vieram. O Portal Server supunha alguém em taxonomia e foi adotado pelas organizações que podiam contratar. No DAFFIE tentamos as duas pontas do espectro e nenhuma funcionou. Restrinja o esquema e você perde a maior parte da web, abra e uma estrela pop, uma contadora e uma cadela colapsam numa entidade só.
Povoá-lo. Um esquema vazio não vale nada, e as primeiras entradas são as caras. Esse é o problema da partida a frio, e é separado da manutenção: antes de qualquer coisa envelhecer, alguém precisa decidir quais entidades existem e pôr as primeiras. O DAFFIE rodava sem ninguém digitar um fato, mas cada domínio novo dependia de alguém de engenharia escrever o extrator primeiro.
Mantê-lo em dia. É esta que as pessoas costumam nomear, e é a que nunca terminava. Eis o que manter uma ontologia construída à mão de fato envolvia.
Uma ontologia é a descrição de um mundo que continua se mexendo. Alguém precisa acrescentar a linha de produto nova, aposentar a descontinuada, conciliar os dois times que usam a mesma palavra para coisas diferentes, e notar quando uma relação que era de um para um virou de um para muitos. Em geral era uma pessoa só, muitas vezes com outro serviço. O negócio mudava mais rápido do que ela conseguia editar.
Então o esquema se afastava da realidade. E isso é pior que esquema nenhum, porque os sistemas continuam confiando nele.
Você não precisa acreditar em mim sobre como era esse trabalho. Em dezembro de 2005, a Unisys documentou a implantação de SharePoint dela para o grupo corporativo do Dublin Core. Os metadados pertenciam a uma pessoa com o cargo de Arquiteta de Conhecimento Corporativo. Os atributos e os detalhes eram “mantidos numa planilha”. Eles tinham sido “incapazes de povoar automaticamente as listas de vocabulários controlados”, e o controle de mudança era “um problema com este método”. É uma empresa grande e competente fazendo tudo certo, e o estado da arte exigia uma pessoa ou um time dedicado e uma planilha.
Essa é a história da manutenção e, sozinha, ela explica menos do que parece, porque muitas tecnologias difíceis e tediosas ganharam mesmo assim. A autópsia de sempre acrescenta que a Web Semântica era acadêmica demais, complicada demais, distante demais do que quem desenvolvia queria. O SQL é o contraexemplo. Ele saiu de um artigo de pesquisa de 1970, se apoia em álgebra relacional, e pede que as pessoas pensem de um jeito para o qual nada na vida comum prepara. Ganhou por completo mesmo assim. Dificuldade não foi o que decidiu isso.
O que difere é quem consome a estrutura, e se esse consumidor já existe. Modele bem o seu próprio banco e o consumidor é a aplicação que você está construindo. Você escreve o esquema para ela, entrega, e o seu projeto anda.
Ponha o mesmo cuidado em RDF e o consumidor, e o benefício, podem ser hipotéticos. Você pode estar estruturando dados para a sua própria aplicação, mas pode igualmente estar pavimentando o caminho para aplicações que ninguém construiu. É aproximadamente o que aconteceu por volta de 2001. Os vocabulários eram a metade fácil. O que nunca chegou foi a população de agentes que deveria percorrê-los, então as anotações ficaram lá esperando quem as lesse.
É isso que de fato mudou, e não tem nada a ver com o formalismo. Um agente de IA hoje pode ser um consumidor de propósito geral de dados estruturados. Ninguém precisa construir uma ferramenta para ler o que você registrou, o que significa que estrutura criada hoje de manhã pode ser usada hoje à tarde. A espera entre fazer o trabalho e se beneficiar dele vai de anos, ou nunca, para o mesmo dia.
O schema.org é o caso que mostra o mecanismo. Ponha a marcação no cabeçalho das suas páginas e os buscadores leem, e podem mostrar um resultado mais rico para a sua própria listagem. A recompensa chega rápido e é sua, e é uma das partes dessa pilha que foi adotada em escala.
Recompensa adiada é por que qualquer modelo de empresa mantido à mão decai. É exatamente o que acontece com o wiki que ninguém atualiza desde que a pessoa que o escreveu saiu. Benefício futuro potencial não basta para levar as pessoas a trabalhar, a menos que elas sejam apaixonadas por aquilo.
O que de fato é diferente agora
Quem mantém já não precisa ser uma pessoa. Prasenjit Sarkar, citado no texto da Latent Space, colocou isso mais ou menos do melhor jeito possível: quando um agente mantém a ontologia como parte da própria operação, atualizando definições ao esbarrar em casos de exceção, o problema da manutenção muda de natureza. Ele não desaparece. Ele muda de um serviço que alguém tem que lembrar de fazer para algo que acontece como subproduto do trabalho.
Isso importa porque manutenção é a única das três que nunca termina. Você desenha o esquema uma vez e faz as primeiras entradas uma vez, mas a manutenção continua enquanto alguém depender dele.
As outras duas seguem abertas. A IA pode enfrentá-las também, mas é cedo para dizer. Povoar um modelo automaticamente é trabalho inicial, e decidir quais tipos um negócio usa é ainda mais difícil. Não vi ninguém fazer nenhuma das duas.
A objeção óbvia é a que o meu próprio exemplo da Britney levanta. Um agente também pode estar confiantemente errado, e um modelo que se afasta em silêncio é pior que um wiki que todo mundo sabe estar velho. A diferença é o que a escala faz com a ambiguidade. Na web aberta, Britney Spears é uma estrela pop, uma contadora em Ohio, uma cadela e um álbum, e o DAFFIE tinha que separá-los em cada página que usava o nome. Achamos heurísticas que ajudavam. Ainda assim continuou sendo um problema de pesquisa. Nas mensagens que um negócio troca com parceiros e fornecedores, a Perot Systems é uma empresa, e uma segunda Perot Systems dificilmente aparece em alguma corrente. A ambiguidade não desaparece nessa escala. O mesmo nome pode ser um cliente numa corrente e um fornecedor em outra, e duas pessoas nos seus contatos podem ter o mesmo nome. Mas algumas centenas de entidades que em geral têm um referente cada são um problema de outra escala que a web aberta, em que um nome só pode significar uma estrela pop, uma contadora e uma cadela.
Nada disso significa que um agente vai sempre acertar. Significa que o sistema tem que ser construído para resiliência, e há dois princípios que eu sugeriria a quem o desenhar. Exija que uma pessoa aprove qualquer mudança significativa, antes de ela entrar e não num relatório que você lê depois. E torne o resultado editável, para quem vir uma linha errada poder corrigir no lugar em vez de abrir um chamado contra um processo. Um agente que escreve num modelo que ninguém pode corrigir é o problema de 2005 com um motor mais rápido.
Isso é mais barato do que parece, porque a conferência anda junto com o uso. Faça o agente registrar o que aprendeu antes de atualizar uma página e há um registro de qual mensagem produziu qual mudança. O DAFFIE também tinha registros; o que faltava era uma quantidade revisável deles. Uma página sobre um cliente é lida por quem está prestes a falar com esse cliente, ou pelo agente escrevendo por essa pessoa, então uma linha errada é pega no curso do uso. A conferência é subproduto do trabalho, igual à atualização.
Por que manter um modelo? Ponha as mensagens num banco vetorial, deixe o agente ler, e pule o esquema. Isso funciona até o agente ter que acertar a mesma coisa duas vezes. A recuperação devolve o que se parece com a pergunta, então um agente perguntado sobre um cliente vai alegremente devolver a corrente sobre um concorrente de nome parecido, e quando você corrige, não há onde pôr a correção, então amanhã ele lê as mesmas mensagens e comete o mesmo erro.
Isso defende uma ontologia leve em vez de pesada. Os tipos carregam o peso. Saber que esta entidade é um cliente, aquela um concorrente e aquela outra um produto deixa um agente buscar o conjunto certo, e dá à correção onde se prender. Talvez você não precise da parte que afundou as tentativas anteriores, uma lista fixa de atributos que todo cliente tem que carregar.
O que construímos em 2005 tinha uma lista crescente de tipos e um conjunto crescente de atributos, e o formato era fixo: tudo tinha que ser uma entidade com atributos e valores. O que eu construiria hoje é mais estreito numa direção e bem mais largo na outra. Uma lista dos tipos que uma empresa usa, uma lista das entidades reais sob cada um, e uma página de prosa sobre cada uma em vez de uma linha de atributos. Uma página guarda qualquer coisa verdadeira sobre aquele cliente. Um está de olho nos custos porque uma linha de produto nova não pegou. Outro está distraído por uma ação de violação de patente. Nenhum dos dois cabe num CRM, e ninguém enumerou “distraído por uma ação de patente” de antemão, porque o agente que lê as mensagens não está preenchendo um formulário.
A outra metade da equação
Mesmo que os três problemas desaparecessem amanhã, isso não bastaria para tornar ontologias dignas de serem construídas. Uma ontologia pode ser simples de construir e ainda assim não pagar o esforço. Da última vez o trabalho era difícil e a recompensa nunca chegou. O que você ganha por construir uma tem que melhorar, e melhorou, por duas razões que não valiam em 2001 nem em 2005.
A primeira é que a maior parte do que uma empresa sabe nunca chega a um sistema de registro. Numa pesquisa da Panopto de 2018 com 1.001 pessoas nos EUA em organizações de 200 pessoas ou mais, feita com a YouGov, 42% do conhecimento institucional era exclusivo de quem o guardava: não registrado, e desconhecido de qualquer colega. É o lançamento que escorregou, o parceiro que ficou quieto, as duas pessoas respondendo ao mesmo cliente de jeitos diferentes. Vinte anos atrás esse conhecimento também existia, mas ficava em conversas que nada conseguia ler. Agora ele fica em mensagens, que um modelo de linguagem lê bem. Escrevi em outro lugar sobre o meio que falta no conhecimento da empresa, e Jack Dorsey e Roelof Botha defendem organizar uma empresa em torno de um modelo de si mesma em From Hierarchy to Intelligence.
A segunda é que os agentes precisam disso. Um modelo respondendo a partir do histórico bruto de mensagens re-deriva as mesmas conclusões a cada rodada e paga por isso toda vez. Uma camada mantida amortiza isso, e dá a uma correção um lugar para viver que a próxima rodada vai ler. É por isso que o revival das ontologias está acontecendo entre quem constrói agentes, e não entre quem constrói busca.
Nenhuma das duas torna o esquema mais fácil de desenhar. Elas tornam ter um mais valioso, e esse valor é o que faltava da última vez.
Barreiras são a parte fácil. Decidir o que modelar e manter em dia são as difíceis, e os três sistemas que descrevi esbarraram nas duas. Só a manutenção agora tem uma resposta plausível. Pela evidência dos últimos vinte anos, sempre que uma pessoa é quem mantém um modelo em dia, é ali que o decaimento começa.
Se é possível aprender o esquema e povoá-lo continuam sendo perguntas abertas. É por isso que estou construindo sobre esta ideia de novo, em vez de apenas te contar o que falhou antes.