Resumen Técnico: KRROOD – Representación del Conocimiento y Razonamiento con Diseño Orientado a Objetos

1. Planteamiento del Problema

El artículo identifica un "desajuste de impedancia" crítico entre las prácticas modernas de ingeniería de software y los sistemas de Representación del Conocimiento y el Razonamiento (KR&R). Mientras que la Programación Orientada a Objetos (OOP) es el estándar para construir aplicaciones complejas (particularmente en robótica e IA), los marcos de KR&R existentes suelen depender de ontologías externas, lenguajes de lógica especializados y razonadores externos.

Esta separación obliga a los desarrolladores a mantener dos sistemas de representación distintos: uno para la lógica de la aplicación (código imperativo) y otro para el conocimiento del dominio (programación lógica o lógica de descripción). Esto conduce a:

• Fricción de Integración: Los desarrolladores deben alternar constantemente entre paradigmas, sincronizando el estado a través de las fronteras del sistema.
• Falta de Integración Nativa: Ningún marco mantenido activamente proporciona una integración nativa y orientada a objetos tanto de la representación del conocimiento como del razonamiento avanzado dentro de los sistemas de IA basados en Python.
• Problemas de Escalabilidad y Mantenimiento: La necesidad de exportar el estado del dominio, invocar razonadores externos y procesar los resultados crea un flujo de trabajo de "proceso por lotes" que dificulta la introspección en tiempo real y la explicabilidad en sistemas autónomos.

2. Metodología: El Marco KRROOD

Los autores proponen KRROOD (Knowledge Representation and Reasoning with Object Oriented Design), un marco que trata el conocimiento como una abstracción de programación de primera clase dentro de Python. En lugar de separar el conocimiento del código, KRROOD los unifica utilizando estructuras de clases nativas de Python. El marco consta de cinco componentes principales:

A. Representación Orientada a Objetos Nativa

Las entidades del dominio se modelan como clases de Python (usando dataclasses). Los conceptos son clases, las relaciones son atributos y las relaciones taxonómicas son herencia. Esto permite que el código de la aplicación acceda directamente a las entidades del dominio sin tener que mapearlas a estructuras de ontologías externas.

B. Lenguaje de Consulta de Entidades (EQL)

Para consultar estas estructuras de objetos, los autores introducen EQL, un lenguaje declarativo que extiende los patrones de consulta conjuntiva.

• Sintaxis: Sigue un patrón Select-Where-From pero opera sobre objetos Python.
• Semántica: Basada en el fragmento existencial y de solo conjunciones de la Lógica de Primer Orden (FOL), extendida con:
  • Uniones de consultas conjuntas (coincidencia disyuntiva).
  • Negación como falla (ausencia operacional de evidencia).
  • Cuantificación universal restringida sobre el dominio activo.
• Funcionalidad: EQL permite que las variables representen conjuntos de valores y soporta computaciones específicas del dominio (por ejemplo, llamar a métodos de objetos) directamente dentro de las restricciones de la consulta.

C. Reglas de Ripple Down (RDRs) para el Razonamiento

KRROOD implementa una versión de Ripple Down Rules (RDR) nativa de Python para manejar el razonamiento basado en reglas y las actualizaciones incrementales de conocimiento.

• Mecanismo: Las reglas se añaden de forma iterativa. Cuando un nuevo caso entra en conflicto con las reglas existentes, el sistema solicita a un experto que proporcione una condición distintiva. Esta condición se añade automáticamente como una regla de refinamiento en el árbol de reglas.
• Extensiones: A diferencia de las RDR tradicionales, la implementación de KRROOD permite:
  • Casos Flexibles: Objetos Python arbitrarios como entradas.
  • Condiciones Expresivas: Las condiciones de las reglas son código Python ejecutable, lo que permite el uso directo de APIs de dominio (por ejemplo, simulaciones físicas, geometría).
  • Mantenibilidad: Las bases de reglas se materializan como módulos de Python auto-generados y ejecutables que pueden ser modificados directamente dentro de IDEs estándar.

D. Ontomatic (Conversión OWL)

Para cerrar la brecha con las ontologías heredadas, Ontomatic convierte automáticamente archivos Web Ontology Language (OWL) en estructuras de datos de Python.

• Conversión de T-Box: Genera clases y propiedades, infiriendo la subsunción y los dominios/rangos.
• Gestión de Desajustes:
  • Hermanos no disjuntos: Utiliza un "patrón de Rol" (composición) para permitir que los individuos pertenezcan a múltiples clases hermanas, abordando el conflicto entre la semántica de OWL y la herencia de OOP.
  • Axiomas: Los axiomas complejos de OWL (por ejemplo, restricciones de cardinalidad) se codifican como métodos a nivel de clase utilizando predicados EQL.
• Carga de A-Box: Los individuos se cargan como instancias. Para optimizar el rendimiento, el sistema aplica encadenamiento hacia adelante (forward chaining) en el momento oportuno, excluyendo propiedades transitivas/simétricas de la inferencia temprana para evitar un crecimiento exponencial de tiempo, computando en su lugar componentes débilmente conectados en un paso de post-procesamiento.

E. ORMatic (Persistencia)

ORMatic proporciona una capa de persistencia que mapea los objetos de dominio de Python a bases de datos relacionales (por ejemplo, PostgreSQL) utilizando SQLAlchemy.

• Principios de Diseño: Separa estrictamente los Objetos de Acceso a Datos (DAOs) de la lógica de dominio para adherirse al Principio de Responsabilidad Única (SRP).
• Integración: Opera enteramente dentro de las dataclasses de Python existentes, generando automáticamente las interfaces necesarias. Esto elimina la necesidad de definiciones de esquema separadas (a diferencia del uso de Pydantic o SQLAlchemy estándar) y asegura que el modelo de datos sea idéntico al modelo de dominio.

3. Resultados Experimentales

Los autores evaluaron KRROOD en dos frentes: el benchmark OWL2Bench y un escenario de aprendizaje de tareas robot-humano.

Rendimiento de OWL2Bench

• Configuración: Comparado contra Protégé (con Pellet), owlready2 (con Pellet), GraphDB y RDFlib sobre el perfil OWL 2 RL.
• Razonamiento: KRROD logró tiempos de razonamiento competitivos (8.3s bruto, 127.9s razonado) comparado con Protégé (5.5s bruto, 22s razonado) y superó significativamente a owlready2 (que se quedó sin memoria con datos materializados) y a RDFlib (que no logró terminar). Aunque Protégé fue más rápido, requería una memoria masiva (25GB para la exportación) y carecía de integración nativa.
• Consultas: En cuanto al rendimiento de consultas, SQLAlchemy (utilizado como base dentro de KRROOD) fue el más rápido. KRROOD con EQL no siempre fue el más rápido, pero proporcionó objetos de dominio plenamente capaces, una característica ausente en otros marcos. GraphDB fue la alternativa más viable cuando la velocidad de consulta era la única prioridad y los objetos de dominio eran innecesarios.

Aprendizaje de Tareas Humano-Robot

• Escenario: Un robot aprendió a realizar tareas de recogida e inserción utilizando una caja Montessori mediante demostración y retroalimentación humana.
• Implementación: El sistema utilizó Segmind, un marco construido sobre KRROOD.
• Proceso: El robot observó acciones, infirió las restricciones de emparejamiento objeto-agujero y utilizó árboles RDR para clasificar eventos (por ejemplo, distinguir un PickUpEvent de un FallingEvent basándose en la aceleración).
• Resultado: El sistema generalizó las reglas con éxito a través de la interacción. Los árboles RDR permitieron un razonamiento heterogéneo (geométrico, espacial, basado en física) y proporcionaron una toma de decisiones explicable al rastrear qué reglas contribuyeron a conclusiones específicas.

4. Significancia y Reivindicaciones

El artículo argumenta que KRROOD logra cerrar la brecha de paradigma entre la programación de aplicaciones y KR&R al tratar el conocimiento como un constructo de programación nativo.

• Integración: Permite a los ingenieros programar con conocimiento de manera fluida, evitando el "desajuste de impedancia objeto-ontología".
• Expresividad vs. Tractabilidad: Al utilizar estructuras nativas de Python y cuantificación restringida, el sistema mantiene la decidibilidad y la tractabilidad mientras soporta el razonamiento expresivo requerido para sistemas autónomos del mundo real.
• Explicabilidad: El marco soporta la introspección de extremo a extremo, permitiendo que los sistemas expliquen por qué se llegó a una conclusión rastreando las contribuciones de las reglas y accediendo directamente a las estructuras de conocimiento del dominio.
• IA Híbrida: Proporciona capacidades fundamentales para la IA física híbrida, donde la percepción, la planificación y el razonamiento deben estar estrechamente acoplados con la lógica de la aplicación.

5. Limitaciones y Trabajo Futuro

Los autores reconocen varias limitaciones:

• Compromisos Semánticos: EQL depende de supuestos de mundo cerrado (negación como falla), lo que difiere de la semántica de mundo abierto de la Lógica de Descripción estándar.
• Garantías Estáticas: Permitir código Python arbitrario en las reglas aumenta la expresividad pero debilita las garantías estáticas respecto al tiempo de ejecución de peor caso y la terminación.
• Conversión OWL: La conversión de OWL a OOD no es totalmente sin pérdidas debido a desajustes de modelado (por ejemplo, clases no disjuntas).
• Costos de Recursos: Materializar grafos de objetos ricos puede incurrir en altos costos de memoria y latencia, aunque los autores señalan que KRROOD es más eficiente en memoria que las alternativas basadas en OWL para el razonamiento.

El trabajo futuro incluye la definición de fragmentos de EQL más estrictos con límites de complejidad explícitos y el desarrollo de estrategias de materialización híbridas para instanciar solo subgrafos relevantes para la tarea bajo demanda. El marco está destinado a una evaluación posterior en escenarios de planificación robótica de largo horizonte y aprendizaje con explicabilidad.