Design de Sistemas de Conhecimento

A maioria das empresas opera com múltiplos vocabulários sobrepostos, parcialmente incompatíveis para os mesmos conceitos. O mesmo cliente é registado em diferentes formatos entre sistemas; o mesmo produto é classificado de forma diferente pelas vendas e operações; o mesmo risco é descrito em linguagem incompatível pelo trading e conformidade. Uma ontologia é o modelo explícito e acordado desses conceitos — o que conta como uma instância, quais atributos são obrigatórios, como os conceitos se relacionam — e é o substrato do qual os sistemas de conhecimento a jusante dependem.

Desenhamos ontologias pragmaticamente em vez de filosoficamente. O objetivo não é uma representação perfeita do mundo, mas uma representação útil da parte do mundo em que o sistema atua. Começamos pelas consultas que o sistema precisa de responder e pelas decisões que precisa de apoiar, e modelamos apenas os conceitos e relacionamentos que essas consultas exigem, com espaço explícito para extensão à medida que novos casos de uso surjam.

Padrões — schema.org, FIBO, SNOMED CT, GS1, modelos de referência específicos da indústria — são reutilizados onde se encaixam, adaptados onde quase se encaixam e ignorados onde não se encaixam. O risco de começar de uma tela em branco é maior do que o risco de herdar a complexidade acumulada, mas o inverso é verdadeiro no longo prazo.

• Design de ontologias e taxonomias de domínio
• Reutilização e adaptação de padrões
• Integração de dados semânticos
• Gestão de dados de referência
• Estratégia de versionamento e evolução
• Ferramentas para governança e revisão

Um grafo de conhecimento concretiza uma ontologia com dados reais. Clientes, produtos, fornecedores, transações, eventos e os relacionamentos entre eles tornam-se uma estrutura conectada e consultável em que os sistemas a jusante — pesquisa, recomendação, deteção de fraude, conformidade, fundamentação de IA generativa — podem confiar. O valor não está no grafo em si, mas nos produtos que ele possibilita.

Construímos grafos de conhecimento nas tecnologias apropriadas para a carga de trabalho — Neo4j, Amazon Neptune, JanusGraph, AnzoGraph, lojas RDF nativas, ou camadas de grafos de propriedades sobre armazéns relacionais onde se ajustam melhor. Prestamos muita atenção à resolução de entidades, uma vez que um grafo em que a mesma entidade do mundo real aparece como múltiplos nós é pior do que nenhum grafo, e implementamos práticas de integração contínua para que o grafo evolua previsivelmente com os dados e a ontologia a montante.

Onde o caso de uso justificar, estendemos o grafo com representações baseadas em embeddings que suportam pesquisa de similaridade, recomendações e o tipo de recuperação semântica que fundamenta aplicações de modelos de linguagem grandes, sem exigir que esses modelos se lembrem de tudo. A combinação de grafo estruturado e embeddings aprendidos é invulgarmente poderosa e cada vez mais comum.

“O grafo em si raramente é o resultado final. Os produtos que ele possibilita são.”

Quando as decisões são regidas por políticas complexas — elegibilidade, preços, classificação de riscos, conformidade regulamentar, percursos clínicos — os modelos estatísticos puros são a ferramenta errada. A lógica de política é melhor expressa como lógica de política: como regras legíveis, tabelas de decisão estruturadas e motores de inferência que podem derivar consequências de factos e de um corpo de regras. O resultado é um sistema cujo comportamento é totalmente rastreável e que pode ser atualizado por especialistas no domínio sem a necessidade de retreinar um modelo.

Utilizamos plataformas modernas de gestão de decisões (Camunda DMN, Drools, ferramentas de Modelagem e Notação de Decisões) onde se ajustam ao caso de uso, e motores de regras personalizados onde não se ajustam. Prestamos particular atenção ao processo editorial: quem pode alterar uma regra, com que revisão, com que testes contra casos históricos, e com que implementação faseada. Sem esse processo, as bases de regras degeneram rapidamente em acumulações ilegíveis.

As arquiteturas híbridas combinam o melhor de dois mundos. Um modelo neural trata da perceção ou reconhecimento de padrões onde as regras não podem ser escritas; um motor de regras trata da conformidade da política e da tomada de decisão final onde as regras podem ser. O componente neural fornece entradas ao motor de regras — entidades extraídas de um documento, uma probabilidade calibrada, uma classificação — e o motor de regras chega a uma decisão que pode ser defendida contra qualquer auditoria. Desenhamos explicitamente essas arquiteturas, com uma clara separação entre componentes de aprendizagem e raciocínio e interfaces explícitas entre eles.

A explicabilidade não é uma funcionalidade que se adiciona a um modelo após o facto. É uma propriedade da arquitetura como um todo. Os sistemas baseados em conhecimento são explicáveis por construção: cada decisão é o produto de factos e regras que podem ser inspecionados, e a explicação é um rastreamento direto da cadeia de inferência, em vez de uma reconstrução 'post-hoc'.

Quando componentes de aprendizagem de máquina fazem parte do sistema, associamo-los a ferramentas de explicação apropriadas à classe do modelo — atribuição de características para modelos tabulares, atenção e extração de justificativa para modelos de sequência, explicação baseada em protótipos para modelos de imagem — e exibimos essas explicações juntamente com a saída do sistema, numa linguagem que um especialista no domínio pode usar. O objetivo não é tornar o modelo interpretável no abstrato; é dar ao revisor humano a evidência de que precisa para anular ou aceitar a recomendação do sistema.

Trabalhamos em estreita colaboração com as funções de risco e conformidade para definir os padrões que as explicações devem cumprir, e testamos esses padrões contra casos reais como parte da aceitação. Uma explicação que satisfaz um cientista de dados, mas confunde um gestor de casos, não é aceite.

Os sistemas de conhecimento requerem cuidados contínuos. As ontologias evoluem à medida que o negócio muda; os grafos precisam de manutenção de resolução de entidades à medida que novas fontes são conectadas; as bases de regras precisam de poda, deduplicação e revisão contra resultados reais. Projetamos o modelo operacional juntamente com a tecnologia: os papéis editoriais, a cadência de revisão, o processo de controlo de alterações, os painéis de monitorização de desempenho. O resultado é um sistema cuja meia-vida é medida em anos, não em meses.

Muitas das nossas implementações são acompanhadas de serviços gerenciados leves que tratam desses cuidados contínuos, especialmente nos primeiros anos, antes que as equipas internas do cliente absorvam as práticas. Ficamos igualmente satisfeitos quando os clientes assumem a propriedade operacional imediatamente; o design acomoda ambas as situações.