Ontologias de negócios portáteis para agentes de IA

O termo “ontologia” está em alta. Por quê? Os agentes, e os LLMs que os alimentam, precisam de contexto empresarial relevante.

Antes de investir em uma ontologia, pergunte ao fornecedor: “Quando a ontologia descreve incorretamente o nosso negócio, como as nossas equipes podem corrigi-la — e o que ainda depende de você?” A resposta dirá muito sobre o modelo de negócio no qual você está investindo. Ela também aponta para questões mais amplas: sua capacidade de aprimorar esse modelo à medida que o negócio muda e de manter esse investimento útil caso você mude de plataforma.

É útil distinguir uma ontologia de um grafo de conhecimento, embora os dois muitas vezes se sobreponham.

Ontologia: que tipos de coisas existem, o que significam as relações e quais regras se aplicam. Equipamentos, componentes, equipes, funções, processos. Por exemplo, uma ontologia pode definir um tipo “Equipamento” e uma relação “Contém” com um “Componente”. Em seguida, um grafo de conhecimento pode afirmar: “A bomba P-101 contém o selo S-7”: duas entidades específicas e a relação entre elas.

Imagine que você peça a um agente: “Calcule o crescimento das vendas em mesmas lojas, mas mostre uma comparação lado a lado: uma com todas as lojas e outra excluindo as lojas abertas há menos de 2 anos; depois, divida os dois lados em nacional, internacional e combinado.”

Esse pedido depende de detalhes que um agente não pode adivinhar:

• quais lojas existem e quando foram abertas
• onde ficam
• a definição interna de “vendas em mesmas lojas”

Uma política pode excluir as lojas até que estejam abertas há um ano; o grupo solicitado de dois anos acrescenta outro filtro. Mesmo assim, você compara os meses do calendário assim que uma loja se qualifica ou só a inclui depois de um ano fiscal anterior completo?

A ontologia precisa relacionar essas lojas à política que rege o cálculo. Encontrar fatos relacionados ajuda; aplicar a regra certa é o que torna a resposta útil.

Antes de responder a uma pergunta, um agente pode usar as relações no grafo para recuperar contexto relevante. E não é de admirar que sejam úteis, já que os domínios de conhecimento podem se tornar muito complexos.

Figura 1: Grafo: modelos públicos combinados de SysML: TMT Thirty Meter Telescope (Open-MBEE/JPL, Apache-2.0), CubeSat System Reference Model (© 2022 INCOSE SSWG & OMG SDTF, CC BY 4.0), Architecting Spacecraft with SysML (Friedenthal & Oster, BSD-2-Clause), além de conteúdo fictício da constelação MDC e especificações públicas (IS-GPS-200, IS-GPS-705, GSFC-STD-7000B). Renderizado no Kamiwaza Kaizen.

Mas a extração também pode registrar erros. As equipes podem usar nomes diferentes para a mesma entidade, criando duplicatas. As fontes podem divergir ou ficar desatualizadas. Até mesmo uma fonte confiável pode ser interpretada incorretamente por um LLM. Fazer esses erros parecerem oficiais não os torna menos perigosos.

Esses riscos aumentam quando um modelo do negócio se torna um sistema que atua sobre ele. Uma relação incorreta pode então desencadear uma ação errada, e não apenas uma resposta errada.

Riscos dos produtos de ontologia

Primeiro, desconfie de modelos inflexíveis. Em nome de oferecer uma solução “com tudo incluído”, um fornecedor pode tratar as próprias entidades como elementos de primeira classe, limitando o que as suas podem fazer. A personalização não basta se os tipos personalizados perderem recursos de pesquisa, validação ou ação.

Segundo, procure um caminho da descoberta à governança. Uma ferramenta deve permitir que você crie uma versão inicial de um grafo com base no que um LLM identifica e, em seguida, valide-o em relação a restrições explícitas. Você deve poder encaminhar exceções às pessoas e preservar o conhecimento exploratório sem tratá-lo como dado empresarial aprovado.

O maior risco é vincular os processos de negócio a uma plataforma da qual você não pode sair. Sua ontologia representa o seu negócio: seu conhecimento, processos e relações. Esse investimento em curadoria e lógica de negócios deve continuar sendo útil mesmo que você troque de ferramenta. Por que um fornecedor deveria poder manter tudo isso a sete chaves?

Onde os embeddings de grafos ajudam

À medida que os grafos de conhecimento crescem muito, pode valer a pena escolher uma ferramenta ou um fornecedor que ofereça suporte a embeddings de grafos. Eles são muito semelhantes aos embeddings semânticos que alimentam muitas aplicações de RAG. Há dois benefícios importantes a considerar.

Primeiro, alguns saltos em um grafo densamente conectado podem resultar em entidades demais para processar. Ao aprender representações numéricas de entidades e relações, os embeddings oferecem outra maneira de encontrar partes relevantes do grafo. Para a tarefa certa, isso pode ser mais eficiente do que percorrer o grafo.

Segundo, os modelos de embeddings podem classificar relações ausentes candidatas. O mesmo aprendizado pode revelar padrões nos atributos e nas relações típicos de um tipo de entidade, ajudando a construir um grafo mais completo.

Por que apostar no aprimoramento progressivo

Para assumir o controle do próprio destino, evitar ficar preso a um fornecedor e modelar seu negócio real em vez de uma caricatura dele ditada por um fornecedor, como começar sem um exército de engenheiros destacados para trabalhar diretamente com você? É aí que, na minha opinião, a IA moderna se destaca, desde que as ferramentas ofereçam um caminho da descoberta à verificação.

Primeiro, use descoberta e extração automatizadas. A partir de documentos empresariais, políticas, e-mails ou mensagens do Slack, é possível construir uma visão inicial de um domínio. O ponto crucial é que não se pode confiar nela como precisa até que seja verificada.

A verificação é a segunda etapa. Suas ferramentas devem oferecer um caminho simples que leve dos candidatos extraídos a afirmações fundamentadas em fontes e a conhecimentos validados por uma pessoa responsável ou por um sistema confiável. Preserve a fonte de cada afirmação.

Manter as informações atualizadas é um trabalho contínuo. O processo para lidar com um chamado de suporte, ou a resposta à pergunta “quantas lojas existem em Nova Jersey”, pode não ser hoje o mesmo de três anos atrás. Mas atualizar o conhecimento atual não deve apagar a realidade de ontem. O momento em que um fato foi registrado pode ser diferente daquele em que se aplicava; uma ontologia útil precisa dar suporte tanto a respostas atuais quanto a uma visão histórica precisa. Ainda é preciso que alguém mantenha esse conhecimento atualizado.

O escopo pode ser imenso. Comece com um conjunto menor de documentos, mapeie um domínio útil e avance em direção a uma visão abrangente, gerando valor ao longo do caminho.

O suporte ao cliente é uma área útil para começar: chamadas recebidas, e-mails, um sistema de chamados, resoluções automatizadas, uma equipe de suporte capaz de responder aos clientes e um caminho para encaminhar bugs reais à engenharia. Isso conecta o conhecimento à ação e revela os mesmos riscos e benefícios em um domínio administrável.

O Modelo de Dados de Serviço Comum da ServiceNow ilustra essa limitação. Seu documento técnico do CSDM 5 alerta: “Sem esses dados nas tabelas especificadas, talvez você não obtenha todo o valor da ServiceNow AI Platform.” O próprio alerta impõe uma restrição de projeto e operação: adotar o modelo do fornecedor ou aceitar um risco. E se isso significar tentar encaixar uma peça redonda num buraco quadrado?

Agora, suponha que uma plataforma de ontologia também ofereça ingestão de dados, transformações, ações e regras de negócio. Talvez seja possível exportar entidades, atributos e relações. Mas também é possível migrar transformações e fluxos de ações que executam alterações nos seus bancos de dados, chamam webhooks e geram outros efeitos colaterais? Integrações fortemente acopladas podem deixar a própria empresa presa à plataforma.

Por que a flexibilidade é importante agora

O software está transformando o mundo, e a IA está transformando o software. À medida que as equipes usam a IA tanto para desenvolver software quanto para alimentá-lo, uma parcela maior da lógica de negócios pode ficar vinculada a essas plataformas. Cada automação útil também pode se tornar mais uma dependência para uma migração. É arriscado deixar que um fornecedor se interponha entre você e a agilidade.

Conclusões

É uma época incrível para estar vivo! Não é de surpreender que as pessoas estejam explorando ontologias para dar contexto aos agentes. Estender esse contexto a processos e integrações pode gerar valor real. Volte à pergunta inicial. As correções feitas pelas suas equipes devem tornar o modelo um reflexo mais fiel da sua empresa. Esse entendimento acumulado é valioso demais para ficar inacessível quando você mudar de plataforma. E também é péssimo ficar encurralado.