Moodle ya utilizaba inteligencia artificial antes de ChatGPT
En 2017, Moodle incorporó modelos predictivos al núcleo de la plataforma. Volver a su funcionamiento permite distinguir aprendizaje automático, reglas, analítica e IA generativa antes de decidir qué tecnología necesita cada problema.
Cuando hoy se habla de inteligencia artificial en Moodle, casi siempre aparecen las mismas funciones: asistentes que responden preguntas, generación de contenidos, resúmenes, imágenes o conexiones con OpenAI, Azure y otros proveedores.
Es lógico. ChatGPT se presentó públicamente el 30 de noviembre de 2022 y cambió la percepción de lo que una inteligencia artificial podía hacer. Desde entonces, buena parte de la conversación sobre IA en los LMS se ha concentrado en las funciones generativas capaces de trabajar directamente con el lenguaje y el contenido.
Moodle, sin embargo, ya incorporaba aprendizaje automático años antes.
El 13 de noviembre de 2017, Moodle 3.4 incorporó al núcleo de la plataforma su motor de analítica, presentado durante su desarrollo como Project Inspire. Una de sus aplicaciones más conocidas era identificar estudiantes con riesgo de abandonar un curso mediante un modelo predictivo entrenado con datos históricos del propio sitio.
El modelo incluido no generaba texto, no conversaba con el estudiante ni analizaba el significado del contenido del curso. Una aplicación basada en un LLM puede hacerlo ahora cuando recibe ese contenido como contexto. Analytics resolvía una tarea mucho más acotada: calculaba una serie de indicadores y estimaba la probabilidad de que se produjera un resultado definido de antemano.
Volver sobre aquel sistema resulta especialmente útil ahora porque permite separar tecnologías que con frecuencia se presentan bajo la misma etiqueta. Un informe estadístico, una regla automática, un modelo predictivo y un LLM pueden formar parte de la misma solución, pero responden preguntas distintas y necesitan pruebas diferentes.
Moodle no empezó a utilizar inteligencia artificial cuando incorporó la generación de texto. En 2017 ya incluía un motor capaz de entrenar modelos predictivos con los datos del LMS.
La secuencia histórica ayuda a entender que Moodle no cambió un mecanismo por otro. Añadió un subsistema de IA con acciones generativas a una plataforma que ya conservaba Analytics, sus reglas y sus modelos predictivos.
Antes de comparar tecnologías, conviene ordenar los conceptos
Inteligencia artificial no designa una técnica única. NIST utiliza el término para sistemas basados en máquinas que, ante objetivos definidos por personas, producen predicciones, recomendaciones o decisiones capaces de influir en entornos reales o virtuales. Dentro de esa categoría caben mecanismos distintos y no todos aprenden de los datos del mismo modo.
El machine learning o aprendizaje automático comprende métodos que ajustan su comportamiento a partir de ejemplos. Un modelo supervisado recibe casos en los que se conocen tanto las variables de entrada como el resultado y aprende una función que después puede aplicarse a casos nuevos. El modelo predictivo de Moodle Analytics pertenece a esta familia de problemas: intenta estimar un objetivo definido, no generar una respuesta abierta.
El deep learning es una parte del aprendizaje automático. Utiliza redes neuronales con varias capas para aprender representaciones sucesivas de los datos, como explicaron Yann LeCun, Yoshua Bengio y Geoffrey Hinton. Un sistema predictivo no necesita recurrir siempre a deep learning. Puede resolver una tarea bien delimitada con otros algoritmos más sencillos si los datos y la evaluación demuestran que funcionan.
La IA generativa se distingue por la tarea: produce o transforma contenido a partir de la entrada, en lugar de limitarse a estimar un objetivo definido. Puede generar texto, imágenes, audio o código, y los sistemas actuales suelen apoyarse en deep learning. En este artículo, LLM se refiere a los grandes modelos generativos especializados en lenguaje. No son sinónimos de inteligencia artificial ni de machine learning. Una aplicación de chat es, además, una interfaz construida alrededor del modelo, no el modelo completo.
Estas categorías responden a dos preguntas diferentes. Machine learning y deep learning describen familias técnicas; predictivo y generativo describen tipos de tarea. Las reglas y la analítica descriptiva añaden otras opciones que no necesitan un modelo entrenado. Una regla comprueba una condición definida de antemano y, si se cumple, desencadena una acción. La analítica descriptiva resume hechos observados. Ambas pueden compartir datos y procesos con sistemas de IA.
Qué significaba «modelo» en Moodle Analytics
La palabra modelo puede llevar a confusión porque ahora suele referirse a GPT, Claude, Gemini o cualquier otro modelo fundacional. En Moodle Analytics tenía un significado más concreto.
Un modelo predictivo combinaba un objetivo con una serie de indicadores. El objetivo era aquello que se quería predecir. Los indicadores eran valores calculados a partir de la información disponible en Moodle que podían guardar relación con ese resultado.
La API de Analytics de Moodle 5.2 conserva esa arquitectura. Moodle calcula los indicadores de las muestras históricas, comprueba el valor conocido del objetivo y utiliza ambos para evaluar el modelo. Si el rendimiento evaluado resulta suficiente, entrena el algoritmo de aprendizaje automático. Cuando aparecen nuevas muestras que cumplen las condiciones, calcula sus indicadores y estima la probabilidad de que ocurra el resultado.
La propia documentación propone un ejemplo intuitivo. Si el objetivo es saber si un estudiante completará el curso, la falta de participación o unas calificaciones bajas pueden utilizarse como posibles indicadores. En los cursos terminados se conocen las señales y el resultado. En un curso en marcha solo se conocen las señales; el algoritmo intenta estimar lo que falta.
El modelo de abandono que Moodle incluyó en 3.4 era más específico que ese ejemplo. Utilizaba indicadores de participación inspirados en el marco Community of Inquiry y necesitaba convertir el abandono en una etiqueta que pudiera calcularse. Esa decisión merece atención porque muestra dónde empieza realmente el diseño del sistema.
El algoritmo no recibía todos los datos para decidir qué importaba
Moodle Analytics no entregaba la base de datos completa a un algoritmo para que descubriera por sí mismo qué debía observar. Antes de entrenarlo había que definir los indicadores.
Un indicador podía representar una forma de participación, una interacción con una actividad o cualquier otra señal calculable a partir de los datos disponibles. La documentación de Moodle 3.4 explicaba que el núcleo incluía indicadores de implicación basados en la profundidad cognitiva y la amplitud social. La API permitía además que los desarrolladores construyeran otros indicadores y modelos.
Por tanto, una persona había decidido antes qué observar y cómo calcularlo. Cada indicador incorporaba una hipótesis acerca de la relación entre una señal visible y el resultado que se quería anticipar.
Que un estudiante acceda poco a Moodle puede aportar información sobre su participación en el LMS. Moodle registra accesos, no motivación.
Una entrega demuestra que se ha enviado un artefacto. No demuestra por sí sola cuánto ha aprendido quien lo entregó.
Veinte intervenciones en un foro indican actividad dentro de la plataforma. El recuento no permite concluir cuál es la calidad de la discusión.
Los indicadores agregan y transforman observaciones para que el algoritmo pueda utilizarlas como predictores. No aportan información sobre la parte del proceso de aprendizaje que Moodle nunca llegó a observar.
Predecir el abandono exigía definir primero qué era abandonar
La etiqueta «estudiante con riesgo de abandono» parece describir una realidad inequívoca. No lo es.
Para entrenar el modelo, Moodle tenía que convertirla en una condición que el sistema pudiera comprobar en un curso ya terminado. La documentación del modelo incluido definía el objetivo negativo, por defecto, como no registrar actividad durante el último cuarto del curso. Si la finalización del curso estaba habilitada, también podía utilizarla como medida de éxito.
Esta definición era operativa, pero no equivalía a conocer todos los abandonos ni sus causas. Un estudiante puede dejar de participar porque cambia de trabajo, pierde el interés, tiene dificultades académicas, no puede conectarse o continúa la formación fuera de Moodle. Algunos de esos casos producirán el mismo rastro en el LMS; otros no producirán ninguno.
El algoritmo podía aprender que ciertos patrones de actividad histórica precedían con frecuencia al objetivo elegido. No descubría por sí mismo qué significa abandonar un proceso formativo.
La definición condicionaba el conjunto de entrenamiento, la predicción y la interpretación posterior. Una etiqueta defectuosa no se corrige mediante un algoritmo más potente. Tampoco mediante un LLM.
La predicción se convertía en un insight, no en una explicación
El interés de Moodle Analytics no terminaba en producir una probabilidad. El sistema intentaba integrar la predicción dentro de un recorrido operativo que terminara en una actuación.
Cuando el modelo generaba una predicción, Moodle podía presentarla como un insight y notificar a las personas con la capacidad correspondiente, normalmente docentes. En el caso del riesgo de abandono, la interfaz ofrecía acciones como consultar el informe de actividad del estudiante o enviarle un mensaje.
Aquí insight no significaba una explicación profunda de lo que le estaba ocurriendo. Era la presentación operativa de una predicción para que alguien pudiera revisarla dentro de Moodle.
El sistema podía advertir de un riesgo. Eso no significaba que conociera su causa.
Incluso cuando la predicción era correcta, todavía quedaban preguntas abiertas. Quizá el estudiante necesitaba apoyo académico, tenía un problema de acceso o requería más tiempo. También podía ocurrir que el curso no respondiera a sus expectativas o que la predicción fuera un falso positivo.
Conviene separar tres preguntas:
| Pregunta | Qué puede aportar evidencia | Lo que todavía no resuelve |
|---|---|---|
| ¿Qué ha ocurrido? | Analítica descriptiva sobre actividad, entregas o resultados | El significado y la causa |
| ¿Qué es probable que ocurra? | Un modelo predictivo validado para un objetivo y una población | Qué intervención cambiará el resultado |
| ¿Qué conviene hacer? | Resultados de intervenciones anteriores y análisis del contexto, la capacidad, el riesgo y las alternativas | Si la actuación produjo el efecto esperado |
Una relación estadística entre los indicadores y el resultado no demuestra que esos indicadores sean su causa. Conocer el riesgo tampoco determina la intervención adecuada. La actuación y su resultado necesitan registrarse y evaluarse como partes distintas del sistema.
Algunos modelos de Analytics no utilizaban aprendizaje automático
Moodle Analytics también distingue los modelos que aprenden de datos históricos de los modelos estáticos. Estos últimos calculan indicadores y aplican las condiciones definidas en el objetivo sin entrenar un algoritmo.
Un ejemplo clásico es detectar que un curso próximo a comenzar aún no contiene actividad docente. La condición puede expresarse mediante reglas deterministas. No hace falta analizar miles de cursos anteriores para descubrirla.
La distinción permite ordenar varias funciones que ahora aparecen con demasiada frecuencia bajo el mismo nombre:
| Función | Mecanismo |
|---|---|
| Mostrar la evolución de accesos o calificaciones | Analítica descriptiva |
| Avisar cuando se cumple una condición definida | Reglas y automatización |
| Estimar un resultado a partir de casos históricos | Analítica predictiva con aprendizaje automático |
| Producir un resumen o una respuesta en lenguaje natural | IA generativa |
Las cuatro pueden ser útiles y pueden compartir datos, interfaces o procesos. Eso no las vuelve intercambiables. Presentar una regla como inteligencia artificial no mejora la regla, y pedir a un LLM que interprete y aplique la condición puede introducir una variabilidad que una regla determinista evita.
Las limitaciones del modelo eran también las de los datos
Un modelo entrenado con datos registrados en Moodle depende de lo que la plataforma puede observar. En una formación completamente en línea, una parte considerable de la actividad puede quedar registrada en el LMS. En un programa híbrido, el rastro será mucho más parcial.
Un estudiante puede asistir a una clase presencial, estudiar con documentación descargada, participar en una videoconferencia externa, resolver ejercicios con un compañero o utilizar una herramienta que no envía eventos al LMS. Moodle no registra esa actividad.
La cobertura parcial no es el único límite. Incluso dentro de la plataforma, abrir un recurso no demuestra que se haya leído y contar intervenciones en un foro no permite valorar la discusión. El evento registra una acción; su significado necesita otras evidencias.
Los modelos predictivos pueden encontrar patrones valiosos en esas señales. La precaución consiste en no atribuirles información que nunca recibieron. Una arquitectura de learning analytics debe conservar la diferencia entre observación, inferencia, decisión, intervención y resultado para que una etiqueta no termine sustituyendo al hecho que la originó.
Moodle 4.5 incorporó otro subsistema para otro tipo de problema
Los grandes modelos de lenguaje introdujeron otra forma de construir estas funciones. Una aplicación puede proporcionarles documentos u otros contenidos no estructurados como contexto y pedirles que resuman, expliquen, redacten o respondan en lenguaje natural sin entrenar un modelo específico para cada una de esas tareas.
Moodle 4.5 se publicó el 7 de octubre de 2024 e incorporó un subsistema específico para integrar estas funciones. Su diseño separa cuatro responsabilidades principales:
| Componente | Responsabilidad |
|---|---|
| Placement | Decide dónde aparece la función y cómo interactúa la persona con ella |
| Action | Define una operación, como generar texto, generar una imagen o resumir contenido |
| Provider | Traduce la acción al servicio externo y devuelve su respuesta a Moodle |
| Manager | Coordina las llamadas, selecciona proveedores compatibles y registra los resultados |
La separación respecto a Analytics es significativa. Moodle 4.5 no sustituyó el antiguo motor predictivo por uno generativo. Añadió otro subsistema pensado para otras operaciones.
Un proveedor recibe una acción, adapta los datos al formato que necesita el servicio externo y convierte su respuesta en el contrato que Moodle espera. El placement no necesita conocer el proveedor y el proveedor no decide cómo se presenta la función. El manager mantiene esa frontera.
La primera implementación incluyó los placements del editor de texto y de asistencia del curso; las acciones para generar texto, generar imágenes y resumir; y los proveedores OpenAI y Azure AI. Era el punto de partida del subsistema, no su estado definitivo.
El subsistema se amplió hasta Moodle 5.2 sin romper su separación de responsabilidades
El subsistema no quedó congelado en 4.5. Moodle 5.0, publicado el 14 de abril de 2025, añadió la posibilidad de explicar contenido desde la asistencia del curso y un proveedor específico para Ollama. También incorporó múltiples instancias de proveedor, configuración por modelo, orden de procesamiento e informes de uso y de aceptación de la política de IA.
Moodle 5.1, publicado el 6 de octubre de 2025, añadió el proveedor DeepSeek y controles para permitir o impedir el acceso a las herramientas de IA por curso y actividad. La versión mejoró además los mensajes de error mostrados en los placements y conservó los ajustes al cambiar de modelo.
Moodle 5.2, publicado el 20 de abril de 2026, incorporó al núcleo dos proveedores más: Amazon Bedrock y Gemini. El primero conecta Moodle con una selección de modelos fundacionales accesibles mediante Amazon Bedrock; el segundo permite utilizar la familia de modelos de Google para las acciones que implementa el proveedor.
La documentación de administración de Moodle 5.2 enumera seis proveedores: Azure AI, Amazon Bedrock, DeepSeek, Gemini, Ollama y OpenAI. Un administrador puede crear varias instancias, configurar qué acciones procesa cada una y determinar su orden. Así puede, por ejemplo, utilizar un modelo para resumir y otro para generar texto, o establecer una alternativa cuando la primera instancia no pueda atender una solicitud.
Un proveedor tampoco equivale necesariamente a un único modelo. Amazon Bedrock, por ejemplo, da acceso a modelos de Anthropic, Amazon y Meta. El proveedor es la capa de integración que traduce las acciones de Moodle al servicio externo; los modelos disponibles y las acciones compatibles dependen de esa integración y de su configuración.
Los placements documentados en 5.2 mantienen otra responsabilidad. El editor ofrece generación de texto e imágenes, mientras que la asistencia del curso permite resumir y explicar el contenido principal de una página. Están desactivados por defecto y pueden controlarse por curso y actividad. Añadir proveedores amplía las opciones para ejecutar esas acciones; no añade automáticamente una nueva función educativa ni demuestra que todos produzcan resultados equivalentes.
Esta arquitectura permite generar y transformar contenido de formas que Analytics no podía. No convierte al LLM en sustituto del modelo predictivo.
Un LLM no se vuelve un buen predictor porque responda con seguridad
Supongamos que una aplicación entrega a un modelo generativo el historial reciente de un estudiante y pregunta: «¿Corre riesgo de abandonar el curso?».
El modelo probablemente producirá una respuesta. Puede incluir motivos, cautelas y una recomendación. Incluso puede resultar convincente.
Eso no demuestra que se haya construido un sistema predictivo fiable.
En un modelo supervisado se define el resultado que se quiere anticipar, se entrena con casos históricos y se comprueba su comportamiento con datos que no ha utilizado durante el entrenamiento. Después pueden estudiarse, entre otras medidas, los falsos positivos y los falsos negativos para decidir si el sistema sirve en esa población y para esa intervención.
Si se quiere utilizar un LLM para estimar ese mismo riesgo, hay que evaluar sus salidas para ese objetivo, esa población y ese uso. La fluidez de la explicación no sustituye esa prueba.
De hecho, la explicación generativa introduce un riesgo adicional. Una aplicación puede partir de una predicción limitada pero cuantificable y pedir después a un LLM que la explique. Si el contexto no contiene información suficiente sobre la causa, el modelo puede completar el hueco con una razón plausible, un riesgo que NIST describe como confabulación. La respuesta será más fácil de leer que una puntuación de riesgo, pero no necesariamente más cierta.
Lo que la IA generativa sí cambia
La diferencia no consiste en que el texto se haya vuelto analizable: el procesamiento del lenguaje y los clasificadores predictivos ya podían trabajar con él. Moodle Analytics, en concreto, calculaba indicadores definidos de antemano y no analizaba el contenido de una entrega o de una intervención en un foro.
Los LLM han generalizado el acceso a varias tareas lingüísticas mediante instrucciones y contexto. Una aplicación puede proporcionar los materiales autorizados para responder preguntas, resumir una discusión o preparar un borrador sin desarrollar y entrenar un modelo distinto para cada operación. La salida sigue necesitando una evaluación propia: resumir, clasificar y explicar no son la misma tarea.
Esto abre posibilidades que Moodle Analytics no tenía, pero añade más datos, usos y riesgos que gobernar. Si una función analiza la intervención de un estudiante, alguien debe decidir qué datos puede utilizar, con qué finalidad, dónde se procesan, cuánto tiempo se conservan y quién verá el resultado. Si genera una explicación, hay que comprobar que se sostiene en el contexto disponible. Si recomienda una actuación, debe quedar claro hasta dónde llega esa recomendación y quién responde de la decisión.
Los permisos tampoco desaparecen al construir un prompt. Cualquier componente que reúna información de distintas partes del ecosistema debe respetar el ámbito de la persona que solicita la acción y el propósito autorizado. La capacidad tecnológica ha aumentado; las obligaciones de diseño también.
Cómo decidir qué utilizar hoy en Moodle
La selección debería comenzar con una descripción del resultado que se necesita, escrita sin mencionar ninguna tecnología. La guía de Google para formular problemas de machine learning recomienda precisamente comparar el aprendizaje automático predictivo, la IA generativa y una solución más sencilla que no utilice ML antes de elegir.
En una implantación concreta, esa elección forma parte de un recorrido más amplio: delimitar el caso de uso, los datos, los permisos y la evaluación antes de conectar un proveedor de IA a Moodle.
Lo que sigue es un mapa de elección inicial, no una receta completa de validación. En datos educativos, por ejemplo, la separación entre entrenamiento y prueba debe evitar fugas de información entre estudiantes, cursos o periodos que hagan parecer mejor al modelo de lo que funcionará en la práctica.
Si la necesidad consiste en mostrar lo que ya ha ocurrido —la evolución de las calificaciones, la participación o el progreso—, corresponde utilizar analítica descriptiva. Antes de diseñar el panel hay que acordar las definiciones y comprobar la calidad del dato; un gráfico preciso de una variable mal definida sigue siendo una mala medida.
Cuando la condición ya se conoce, una regla suele ser suficiente. Para avisar tres días antes del vencimiento de una actividad o detectar dos semanas sin acceso no hace falta que un modelo interprete nada. La ventaja no es solo el coste: el resultado puede probarse de forma determinista y explicarse mediante la condición que lo produjo.
El aprendizaje automático predictivo tiene sentido cuando se quiere estimar un resultado que todavía no se conoce y existen casos históricos representativos. Además de entrenar el modelo, hay que reservar datos para validarlo y estudiar sus errores. Si se trata de una clasificación, entre ellos estarán los falsos positivos y negativos. También hay que comprobar si la frecuencia, la distribución y el coste de esos errores son compatibles con la intervención prevista. Si no puede actuarse ante la predicción, su utilidad operativa será limitada aunque la métrica parezca buena.
La IA generativa puede aportar valor cuando la aplicación necesita producir o transformar contenido y una plantilla, una regla o un método no generativo no alcanza la calidad o la flexibilidad necesarias. Para el lenguaje puede utilizarse un LLM, que debería recibir únicamente el contexto autorizado. La aplicación tendría que evaluar sus respuestas con ejemplos del uso real y comprobar que cualquier explicación factual se apoya en las fuentes disponibles. Las reglas de acceso, la selección de datos y las decisiones irreversibles no deberían convertirse en instrucciones ambiguas dentro del prompt.
Por último, decidir qué intervención corresponde a un estudiante no es una quinta clase de modelo. Es una responsabilidad que necesita evidencia, contexto, capacidad para actuar y una persona o política identificable. Un sistema puede priorizar un caso o preparar un borrador; eso no demuestra por sí solo qué actuación será adecuada.
La comprobación cambia con el mecanismo. Una regla se prueba contra condiciones y resultados esperados. Un modelo predictivo se valida con casos no utilizados durante el entrenamiento. Un sistema generativo necesita un conjunto de evaluaciones sobre exactitud, respaldo, seguridad y utilidad. Una intervención debe medirse por su ejecución y por el resultado observado, no por la calidad aparente del mensaje que la propuso.
Un proceso actual puede combinar predicción, reglas y generación
Una intervención ante un posible abandono permite ver el conjunto.
La plataforma calcula primero señales observables: actividad reciente, entregas pendientes, progreso y resultados definidos. Un modelo validado para esa población utiliza parte de las variables para estimar el riesgo conforme a un objetivo definido. Después, unas reglas aplican el umbral y los permisos. La persona responsable confirma que existe capacidad para atender el caso y delimita la información autorizada.
Solo entonces un modelo generativo recibe el contexto autorizado y prepara, por ejemplo, un resumen para el tutor o un borrador de comunicación. El tutor contrasta la situación, decide si procede intervenir y registra qué ha hecho. Más adelante, la institución analiza si la actuación llegó a ejecutarse y qué resultado se observó.
Hay aprendizaje automático, reglas, automatización, IA generativa y decisión humana. Obligar a una sola tecnología a resolver todas las etapas dificultaría evaluar y gobernar cada una por separado.
Dos ejemplos completos para salir de la abstracción
Hasta aquí pueden entenderse las piezas, pero todavía hay que imaginar cómo se comportaría el conjunto. Los dos ejemplos siguientes utilizan cifras construidas para explicar el recorrido y la lectura de resultados. No describen el rendimiento real de Moodle Analytics ni una experiencia profesional que no esté documentada.
Un estudiante: de la señal al resultado observado
Imaginemos un curso en marcha. Moodle registra que un estudiante lleva doce días sin acceder, tiene dos entregas pendientes y ha obtenido peores calificaciones en las actividades recientes. Para este ejemplo, el modelo transforma esos indicadores en una estimación de riesgo del 78 %. La cifra permite priorizar el caso, pero no explica qué está ocurriendo.
Una regla envía a revisión las estimaciones superiores al 70 %. El tutor consulta únicamente la información autorizada y encuentra un parte de soporte que documenta un problema de acceso. Un LLM redacta un borrador con esos hechos; el tutor decide ofrecer soporte técnico y ampliar el plazo. Después, el estudiante vuelve a entrar y entrega la siguiente actividad.
El final de la secuencia es un resultado observado, no una demostración causal. El estudiante podría haber regresado sin el mensaje, y tampoco sabemos todavía si completará el curso. El registro sirve para formular una evaluación posterior; no convierte una sucesión temporal en una explicación.
Dos cohortes: del porcentaje de acierto a la experiencia operativa
Supongamos una cohorte ficticia de validación de 100 estudiantes cuyos resultados ya se conocen. El cálculo es retrospectivo y no modifica la atención que recibieron. Veinte terminan cumpliendo la definición de abandono y ochenta no. El modelo genera 25 avisos: acierta en 15 abandonos, alerta sobre 10 estudiantes que no abandonan y deja sin detectar otros 5 abandonos. Los 70 casos restantes son negativos verdaderos.
La exactitud global es del 85 %, pero esa cifra aislada oculta la distribución de los errores. La precisión de los avisos es del 60 %: solo 15 de los 25 avisos coinciden con un abandono posterior. La cobertura o recall es del 75 %: el modelo detecta 15 de los 20 abandonos. Un clasificador que predijera «no abandonará» en los 100 casos tendría una exactitud del 80 %, de modo que el porcentaje global no basta para decidir.
En otra cohorte ficticia, utilizada ya como piloto operativo, «volver a la actividad» significa registrar al menos una interacción en Moodle durante los siete días posteriores al contacto. El modelo genera 25 avisos; el equipo revisa 22 y contacta con 18 estudiantes. Entre las personas contactadas, 12 responden. Medido por separado, ocho registran una interacción en ese plazo; el ejemplo no fija cuántas pertenecen a ambos grupos.
El seguimiento muestra dos pérdidas de ejecución: quedan 3 avisos sin revisar y 4 revisiones sin contacto. Entre las 18 personas contactadas, 6 no responden y 10 no registran un retorno; estos dos grupos pueden solaparse. Esta separación también impide atribuir al modelo un resultado que depende de que varias personas actúen después.
Un análisis útil de los resultados debería mantener al menos tres vistas separadas: errores de predicción, ejecución del proceso y resultado posterior observado. Para estimar el efecto de la intervención habría que diseñar una evaluación capaz de aproximar qué habría ocurrido sin ella: por ejemplo, una asignación aleatoria cuando sea ética y operativamente viable, u otro diseño cuasiexperimental justificado. La calidad del modelo, la capacidad operativa y el efecto de la actuación son problemas relacionados, pero no son la misma medida.
El problema de fondo apenas ha cambiado
En 2017 ya era necesario decidir qué detectar, qué datos podían servir, qué representaban esos datos, cómo evaluar el modelo y qué debía ocurrir cuando aparecía una predicción.
Ahora una aplicación basada en un LLM puede recibir documentos, conversaciones y otros contenidos no estructurados como contexto. Puede generar respuestas y explicaciones, y sostener interfaces conversacionales que Moodle Analytics no proporcionaba. Es un cambio enorme, pero no sustituye las preguntas anteriores.
Para detectar abandono sigue haciendo falta definir abandono. Si se utiliza la actividad como indicador, hay que justificar qué representa y qué deja fuera. Una predicción necesita validación. Una intervención necesita una medida de su resultado. Y una explicación generada obliga a distinguir entre lo que muestran los datos y lo que el modelo ha completado.
Por eso me parece engañoso dividir la historia de la inteligencia artificial aplicada a las plataformas de aprendizaje entre un antes de ChatGPT sin IA y un después en el que todo cambia. Moodle ya incorporaba aprendizaje automático para realizar predicciones en 2017.
El nuevo subsistema ha añadido otra familia de capacidades: trabajar con el contenido y producir texto o imágenes. Los LLM, en concreto, permiten hacerlo mediante lenguaje natural. Ninguna de estas funciones ha convertido la analítica, los modelos predictivos ni la automatización convencional en tecnologías antiguas.
Estas capacidades han hecho todavía más importante saber qué problema se intenta resolver antes de decidir qué tecnología debe resolverlo.
Más de 22 años construyendo y evolucionando plataformas de aprendizaje en producción.
Sobre Alberto Lara y su trayectoria profesional →Lecturas recomendadas
Arquitectura de learning analytics: del evento a la intervención
Para diseñar la cadena completa desde el evento hasta la intervención y medir después su resultado.
Cómo gobernar la IA en una plataforma EdTech
Para convertir el inventario de funciones de IA en responsabilidades, controles y evidencias durante todo su ciclo de vida.