Por qué los sistemas de IA para el aprendizaje necesitan ir más allá de los documentos
Un documento permite recuperar lo que está escrito. Para razonar sobre prerrequisitos, cobertura, vigencia o evaluación hacen falta relaciones explícitas.
Un asistente puede encontrar en un manual la definición de una competencia. Una pregunta muy distinta es si un curso la desarrolla, qué conceptos hay que conocer antes, qué actividades permiten practicarla y cómo se evalúa.
La primera pregunta puede resolverse buscando texto. La segunda obliga a relacionar piezas que quizá viven en sitios distintos: el programa, Moodle, una rúbrica y el sistema académico.
Cuando una organización reúne manuales, cursos, grabaciones, normativa y bancos de preguntas, es tentador tratarlo todo igual: extraer el texto, dividirlo en fragmentos y conectarlo a un modelo mediante RAG. Funciona bien para algunas consultas. Falla cuando pedimos al sistema que razone sobre relaciones que se perdieron al convertirlo todo en texto.
RAG puede recuperar la explicación correcta y, aun así, no saber si está en
el lugar adecuado, sigue vigente o cubre lo que el aprendizaje exige.
Un documento no contiene todo el diseño del curso
Un párrafo puede explicar la recursividad, la protección de datos o el uso de una herramienta. Por sí solo no indica si el concepto es obligatorio, qué prerrequisitos tiene, qué actividad permite practicarlo ni qué criterio se utiliza para evaluarlo.
Parte de esa información aparece en las guías docentes. Otra parte ya está estructurada en el LMS. Moodle distingue cursos, secciones, actividades, condiciones de acceso, criterios de finalización, calificaciones y competencias. Si convertimos esos datos en prosa y pedimos al modelo que los reconstruya, perdemos precisión para intentar recuperarla después mediante una inferencia.
Los documentos son una fuente importante. Simplemente no son la única forma de conocimiento que tiene una plataforma de aprendizaje.
Tres preguntas parecidas que exigen recorridos distintos
Pensemos en el principio de sustitución de Liskov:
- ¿Dónde lo explica el curso?
- ¿Qué actividades exigen comprenderlo antes de empezar?
- ¿Qué prueba permite comprobar que se ha alcanzado ese resultado de aprendizaje?
Para la primera pregunta buscamos pasajes y citamos la fuente. Para la segunda recorremos dependencias. La tercera exige además una decisión pedagógica: que una pregunta mencione Liskov no demuestra que evalúe su comprensión.
Un grafo puede conservar estas relaciones para no volver a deducirlas en cada consulta. Merece la pena cuando esas relaciones responden a preguntas reales y se pueden comprobar; no por el hecho de que representar una red parezca más avanzado.
Conservar primero lo que los sistemas ya saben
Si Moodle registra que una actividad pertenece a un curso o tiene una condición de acceso, no hace falta que un modelo lo adivine. Lo mismo ocurre con la versión de un documento, el programa oficial o los permisos de una fuente. Esos hechos deben conservar su identificador y proceder del sistema responsable de ellos.
La IA ayuda cuando la relación está implícita. Puede proponer que dos términos son equivalentes, que un apartado explica un concepto o que una actividad parece practicar una competencia. La propuesta ahorra trabajo, pero no tiene el mismo valor que un hecho del LMS o una relación revisada por un especialista.
Conviene distinguir tres estados:
| Estado | Ejemplo | Cómo puede utilizarse |
|---|---|---|
| Hecho de la fuente | La actividad 42 pertenece al curso 7 | Mientras la fuente mantenga el dato vigente |
| Candidato de la IA | El recurso parece explicar un concepto | Para revisión o usos de bajo riesgo claramente señalados |
| Relación validada | Un responsable confirma la correspondencia | Para los análisis autorizados por la organización |
Así evitamos que una sugerencia plausible se publique como conocimiento institucional.
Modelar desde las preguntas, no desde la tecnología
Una ontología que describa toda la organización sería cara de construir y aún más cara de mantener. El alcance debería definirse a partir de las decisiones que queremos apoyar.
Si necesitamos saber qué cambia al actualizar una norma, habrá que relacionarla con los procedimientos, materiales, cursos y evaluaciones afectados. Si queremos comprobar la cobertura de un marco de competencias, necesitaremos competencias, resultados, actividades y evidencias. Los dos modelos comparten algunas piezas, pero no son iguales.
Antes de elegir una base vectorial, un grafo o GraphRAG, escribiría las preguntas y anotaría qué exige cada una:
- recuperar un fragmento y su cita;
- filtrar por versión y permisos;
- consultar un dato directo del LMS;
- recorrer una dependencia;
- comparar lo que debería existir con lo disponible;
- enviar una propuesta a revisión.
El ejercicio revela qué tecnología hace falta y qué preguntas no pueden responderse todavía.
CASE y Moodle ya modelan parte del dominio
No todo el grafo tiene que inventarse dentro del proyecto. La especificación 1EdTech CASE 1.1 define un intercambio normalizado de estándares académicos, competencias y destrezas. Su modelo incluye marcos, definiciones, asociaciones y rúbricas, de modo que una competencia puede conservar un identificador y relaciones que varias plataformas sean capaces de interpretar.
Moodle también dispone de una API de competencias para trabajar con marcos, planes de aprendizaje, cursos, actividades y evidencias. Ni CASE ni Moodle resuelven por sí solos la validez pedagógica de una relación, pero sí evitan aplanar como texto datos que ya tienen identidad y estructura.
La decisión de arquitectura consiste en mapear esos identificadores y declarar qué sistema es responsable de cada relación. Una alineación importada desde CASE, una asociación configurada en Moodle y una propuesta inferida por la IA no adquieren la misma autoridad por terminar en el mismo grafo.
Cada relación necesita procedencia
Guardar «el concepto A requiere el concepto B» es insuficiente. También hay que saber de qué fuente salió, qué pasaje o dato la respalda, qué versión se consultó, durante qué periodo era válida y quién la propuso o confirmó.
El modelo de procedencia PROV-DM del W3C distingue entidades, actividades y agentes. No es necesario adoptar toda su ontología para aplicar la idea. Basta con poder reconstruir qué se utilizó, qué proceso produjo la relación y quién intervino.
Esta información resulta decisiva cuando algo falla. Si el asistente recomienda un material obsoleto, podremos distinguir si la búsqueda eligió mal, la fuente seguía marcada como vigente, la relación era incorrecta o el modelo ignoró la información recibida. Sin ese rastro, todos los fallos parecen «una alucinación».
Dos usos que justifican el esfuerzo
El primero es detectar lagunas. Un buscador encuentra lo que existe. Para saber qué falta debemos representar también lo que debería existir. Si una competencia requiere cinco conceptos y solo cuatro tienen recursos validados, el sistema puede detectar la ausencia. Lo mismo ocurre con una actividad sin criterio de evaluación o con un resultado sin ninguna evidencia asociada.
El segundo uso es analizar cambios. Una búsqueda documental localiza menciones directas de una norma. Un mapa de dependencias permite seguir el impacto hacia los procedimientos, materiales, cursos y evaluaciones. No decide qué hay que modificar, pero reduce lo que debe revisar la persona responsable.
El valor no procede de que el grafo sea sofisticado. Aparece cuando hacemos explícita una relación que antes estaba repartida entre sistemas o en la cabeza de alguien.
Consulta directa, RAG, grafo y GraphRAG
Estas opciones pueden convivir:
- una consulta al LMS recupera hechos actuales;
- los filtros limitan resultados por versión, idioma y permisos;
- RAG encuentra fragmentos explicativos;
- un grafo recorre relaciones explícitas;
- GraphRAG puede descubrir patrones en una colección de textos.
Como desarrolla la ingeniería de contexto, los permisos se aplican durante cada consulta. Si filtramos después de reunir un subgrafo, ya podemos haber revelado la existencia de una persona, una relación o un atributo que el usuario no debía conocer.
Un grafo de conocimiento tampoco es lo mismo que GraphRAG. Podemos construir el primero con datos directos de Moodle o de un catálogo. GraphRAG extrae entidades y relaciones de textos con ayuda de modelos. La documentación de Microsoft describe además la creación de comunidades y resúmenes para la recuperación. Esas relaciones extraídas siguen siendo propuestas hasta que el sistema les asigna la procedencia y la revisión necesarias.
Conviene empezar con una solución pequeña. Si solo queremos responder preguntas sobre un manual vigente, un RAG bien delimitado puede bastar. Un grafo añade un proceso de incorporación de datos, resolución de entidades y nuevas incoherencias posibles. Solo se justifica si permite responder preguntas que importan.
Empezar con una muestra pequeña
Yo empezaría con un fragmento del dominio y entre cinco y diez preguntas reales. Para cada una identificaría la fuente autorizada, los permisos y las relaciones necesarias. Después separaría los hechos ya estructurados de lo que la IA debe proponer y una persona validar.
La prueba tendría que incluir casos sin evidencia suficiente. También debería demostrar que una corrección en la fuente se propaga, una relación descartada deja de utilizarse y los permisos se mantienen durante toda la consulta.
Este enfoque permite comparar una consulta directa, RAG y un recorrido por el grafo sin construir antes una plataforma completa. También muestra cuánto trabajo cuesta mantener el conocimiento cuando cambian las fuentes.
Del texto encontrado al conocimiento comprobable
Los modelos y los proveedores cambiarán. Los cursos, las normas y los criterios de evaluación también. Los documentos seguirán siendo esenciales, pero ya no pueden cargar por sí solos con toda la estructura del aprendizaje.
Un sistema útil distingue entre explicar un concepto y exigirlo como prerrequisito; entre mencionar una competencia y demostrar su aprendizaje; y entre una relación propuesta por la IA y otra ya confirmada. Además sabe de dónde sale cada relación y quién puede utilizarla.
La ingeniería del sistema completo empieza por ese paso: dejar de pedir a la IA que reconstruya el diseño del curso en cada respuesta y conservar, con sus límites, las relaciones que la organización ya conoce o ha decidido validar.
Más de 22 años construyendo y evolucionando plataformas de aprendizaje en producción.
Sobre Alberto Lara y su trayectoria profesional →Lecturas recomendadas
Por qué un RAG conectado al LMS sigue alucinando
Explica por qué recuperar pasajes parecidos no resuelve la autoridad, la vigencia ni los permisos en un LMS.
El futuro del LMS: arquitectura para aprender con IA
Desarrolla la arquitectura de contratos para conectar conocimiento, decisiones y señales en plataformas de aprendizaje.
Del documento al artefacto vivo: qué estructurar antes de automatizar
Detalla el método para estructurar documentos en artefactos vivos con propietario y ciclo de vida antes de automatizar.