Diseño de Sistemas de Conocimiento

La mayoría de las empresas operan con vocabularios múltiples, superpuestos y parcialmente incompatibles para los mismos conceptos. El mismo cliente se registra en diferentes formatos en distintos sistemas; el mismo producto es clasificado de manera diferente por ventas y operaciones; el mismo riesgo se describe en un lenguaje incompatible por trading y cumplimiento. Una ontología es el modelo explícito y acordado de estos conceptos —qué cuenta como una instancia, qué atributos son obligatorios, cómo se relacionan los conceptos— y es el sustrato del que dependen los sistemas de conocimiento posteriores.

Diseñamos ontologías de forma pragmática, más que filosófica. El objetivo no es una representación perfecta del mundo, sino una representación útil de la parte del mundo en la que opera el sistema. Partimos de las consultas que el sistema necesita responder y las decisiones que necesita respaldar, y modelamos solo los conceptos y relaciones que esas consultas requieren, con un margen explícito para la extensión a medida que surjan nuevos casos de uso.

Los estándares — schema.org, FIBO, SNOMED CT, GS1, modelos de referencia específicos de la industria — se reutilizan donde encajan, se adaptan donde casi encajan y se ignoran donde no lo hacen. El riesgo de empezar desde un lienzo en blanco es mayor que el riesgo de heredar una complejidad acumulada, pero lo contrario ocurre en la cola larga.

• Diseño de ontologías y taxonomías de dominio
• Reutilización y adaptación de estándares
• Integración de datos semánticos
• Gestión de datos de referencia
• Estrategia de versionado y evolución
• Herramientas para la gobernanza y revisión

Un grafo de conocimiento materializa una ontología sobre datos reales. Clientes, productos, proveedores, transacciones, eventos y las relaciones entre ellos se convierten en una estructura conectada y consultable en la que pueden confiar los sistemas posteriores —búsqueda, recomendación, detección de fraude, cumplimiento, fundamentación de IA generativa—. El valor no reside en el grafo en sí, sino en los productos que hace posibles.

Construimos grafos de conocimiento con las tecnologías adecuadas para la carga de trabajo: Neo4j, Amazon Neptune, JanusGraph, AnzoGraph, almacenes nativos de RDF, o capas de grafos de propiedades sobre almacenes relacionales donde mejor se adapten. Prestamos mucha atención a la resolución de entidades, ya que un grafo en el que la misma entidad del mundo real aparece como múltiples nodos es peor que ningún grafo en absoluto, e incorporamos prácticas de integración continua para que el grafo evolucione de forma predecible con los datos y la ontología ascendentes.

Cuando el caso de uso lo justifica, extendemos el grafo con representaciones basadas en incrustaciones que soportan la búsqueda de similitudes, recomendaciones y el tipo de recuperación semántica que fundamenta las aplicaciones de modelos de lenguaje grandes sin requerir que esos modelos recuerden todo. La combinación de grafo estructurado e incrustaciones aprendidas es inusualmente potente y cada vez más común.

“El grafo en sí rara vez es el entregable. Lo son los productos que hace posibles.”

Cuando las decisiones se rigen por políticas complejas —elegibilidad, precios, clasificación de riesgos, cumplimiento normativo, vías clínicas— los modelos puramente estadísticos son la herramienta equivocada. La lógica de las políticas se expresa mejor como lógica de políticas: como reglas legibles, tablas de decisión estructuradas y motores de inferencia que pueden derivar consecuencias de hechos y un conjunto de reglas. El resultado es un sistema cuyo comportamiento es completamente rastreable y que puede ser actualizado por expertos de dominio sin necesidad de reentrenar un modelo.

Utilizamos plataformas modernas de gestión de decisiones (Camunda DMN, Drools, herramientas de Decision Model and Notation) cuando se ajustan al caso de uso, y motores de reglas a medida cuando no. Prestamos especial atención al proceso editorial: quién puede cambiar una regla, con qué revisión, con qué pruebas contra casos históricos y con qué despliegue gradual. Sin ese proceso, las bases de reglas se deterioran rápidamente en acumulaciones ilegibles.

Las arquitecturas híbridas combinan lo mejor de ambos mundos. Un modelo neuronal maneja la percepción o el reconocimiento de patrones donde no se pueden escribir reglas; un motor de reglas maneja el cumplimiento de políticas y la toma de decisiones final donde sí se pueden. El componente neuronal proporciona entradas al motor de reglas —entidades extraídas de un documento, una probabilidad calibrada, una clasificación— y el motor de reglas llega a una decisión que puede ser defendida ante cualquier auditoría. Diseñamos estas arquitecturas explícitamente, con una clara separación entre los componentes de aprendizaje y razonamiento y interfaces explícitas entre ellos.

La explicabilidad no es una característica que se añade a un modelo a posteriori. Es una propiedad de la arquitectura en su conjunto. Los sistemas basados en conocimiento son explicables por construcción: cada decisión es el producto de hechos y reglas que pueden ser inspeccionados, y la explicación es un rastro directo de la cadena de inferencia en lugar de una reconstrucción post-hoc.

Cuando los componentes de aprendizaje automático forman parte del sistema, los combinamos con herramientas de explicación adecuadas para la clase de modelo —atribución de características para modelos tabulares, atención y extracción de justificación para modelos de secuencia, explicación basada en prototipos para modelos de imagen— y mostramos esas explicaciones junto con la salida del sistema, en un lenguaje que un experto de dominio pueda comprender y actuar. El objetivo no es hacer que el modelo sea interpretable en abstracto; es dar al revisor humano la evidencia que necesita para anular o aceptar la recomendación del sistema.

Trabajamos en estrecha colaboración con las funciones de riesgo y cumplimiento para definir los estándares que deben cumplir las explicaciones, y probamos esos estándares contra casos reales como parte de la aceptación. Una explicación que satisface a un científico de datos pero confunde a un gestor de casos no se considera correcta.

Los sistemas de conocimiento requieren un cuidado continuo. Las ontologías evolucionan a medida que cambia el negocio; los grafos necesitan mantenimiento de resolución de entidades a medida que se conectan nuevas fuentes; las bases de reglas necesitan poda, deduplicación y revisión frente a resultados reales. Diseñamos el modelo operativo junto con la tecnología: los roles editoriales, la cadencia de revisión, el proceso de control de cambios, los paneles de monitoreo de rendimiento. El resultado es un sistema cuya vida útil se mide en años, no en meses.

Muchos de nuestros despliegues se combinan con servicios gestionados ligeros que se encargan de este cuidado continuo, particularmente en los primeros años antes de que los equipos internos del cliente hayan asimilado las prácticas. Nos complace igualmente cuando los clientes asumen la propiedad operativa de inmediato; el diseño se adapta a ambos.