Cómo crear un chatbot para Moodle LMS y Moodle Workplace con la API de OpenAI: guía paso a paso y cálculo real de costos

Guía técnica para construir, integrar y operar un chatbot dentro de Moodle LMS y Moodle Workplace usando directamente la API de OpenAI. Incluye código, cálculo de costos para un curso de 50 estudiantes y una conversación honesta sobre cuándo un chatbot realmente ayuda a aprender.

Por qué escribimos este post

En los últimos dos años apareció en el mercado de EdTech una ola de soluciones comerciales que prometen “IA para tu LMS”. La mayoría comparte el mismo patrón técnico: un widget de chat embebido en Moodle, conectado a la API de OpenAI o de Anthropic, con algo de ingeniería de prompts encima. El precio que pagan universidades, gobiernos y corporaciones por esas soluciones suele ir desde unos cientos hasta varios miles de dólares mensuales por institución, a veces con esquemas por estudiante o por interacción.

Hay dos preguntas que esos modelos comerciales prefieren que no te hagas:

1. ¿Cuánto cuesta realmente construir y operar uno de estos chatbots por tu cuenta?
2. Un chatbot, por sí solo, ¿mejora el aprendizaje de tus estudiantes?

Este post responde las dos. La primera es matemática. La segunda es pedagógica. Las dos son incómodas para el modelo de negocio que no es más que una conexión a un API de OpenAI, pero son justas para la institución que paga la factura.

Si después de leer decides que la solución comercial que usas vale lo que pagas, perfecto. Pero al menos lo vas a decidir con los números y la pedagogía clara sobre la mesa, no sobre la promesa de marketing.

---

Qué es realmente un chatbot en un LMS

Antes de construir tu primer ChatBot con IA para Moodle, demistifiquemos qué es. Un chatbot de Moodle con IA, en su forma más común, tiene cuatro piezas:

1. Un widget flotante en el navegador (HTML + CSS + JS). Es lo que el usuario ve, la ventana del ChatBot.
2. Un endpoint en el servidor Moodle que recibe el mensaje del usuario, lo enriquece con contexto y lo envía al modelo que realmente razona y responde, usualmente OpenAI o Claude, aunque puede usarse cualquier API de cualquier modelo capaz.
3. Un cliente HTTP que llama a la API de OpenAI (u otro proveedor) con el mensaje + contexto, y recibe la respuesta.
4. Opcional pero recomendable: RAG — un mecanismo para buscar fragmentos relevantes del contenido del curso e inyectarlos en el contexto, para que el bot responda en base a ese material y no a su entrenamiento genérico.

Eso es todo. No hay magia. No hay modelo propietario. La inteligencia vive en OpenAI; lo que tú construyes es la plomería que conecta tu Moodle con esa inteligencia. Cualquier desarrollador con experiencia razonable en PHP y JavaScript puede armar un MVP funcional en 2 a 4 días de trabajo apoyado en VibeCoding. Lo mismo aplica si trabajas sobre Moodle Workplace: la base técnica es idéntica.

---

Lo que vas a necesitar

Si todo esto te suena familiar, vamos adelante.

---

Paso 1 — Definir el alcance del chatbot

Este paso lo saltan casi todos y es donde la mayoría de chatbots educativos fallan. Antes de escribir una sola línea de código, decide qué hace y qué no hace tu ChatBot. Tres preguntas concretas:

¿Qué tipo de preguntas va a responder?

Cuatro alcances típicos, ordenados de más simple a más complejo:

1. Logística del curso — fechas de entrega, dónde está el syllabus, cómo subir una tarea. Esto se puede responder con datos estructurados del propio Moodle, sin LLM siquiera. Costo cero por consulta.
2. FAQ del contenido — el bot responde sobre el material del curso (lecturas, videos, presentaciones). Requiere RAG sobre el contenido cargado por el instructor. Este es el caso de uso más común y el que cubrimos en este post.
3. Asistencia conceptual — el bot explica conceptos, resuelve dudas teóricas, da ejemplos. Aquí entra terreno pedagógicamente peligroso (ver sección sobre descarga cognitiva más abajo).
4. Resolución de problemas o tareas — el bot ayuda al estudiante a resolver ejercicios. Aquí ya estás básicamente entregando respuestas y vas a generar más daño que valor en la mayoría de situaciones. Está demostrado que el uso indiscriminado de IA en estas situaciones genera efectos adversos en el aprendizaje.

Recomendación honesta: empieza con el alcance 1 + 2. Es donde el ROI es mayor y el riesgo pedagógico menor. Los alcances 3 y 4 requieren mucho más diseño instruccional y no se resuelven con un ChatBot genérico.

¿De qué fuente saca la información?

Define exactamente qué contenido puede usar el bot como referencia. Idealmente: solo material aprobado por el instructor (PDFs de lecturas, syllabus, FAQs escritas, transcripciones de clases). Permitirle responder “desde su conocimiento general” lo convierte en un asistente impredecible, propenso a alucinar y a contradecir al profesor.

¿Qué NO debe hacer?

Hazlo explícito en el prompt del sistema: no debe dar opiniones sobre la calificación, no debe dar respuestas a tareas evaluables, no debe sugerir trampas al sistema, no debe romper el rol, etc…. Estos límites se definen en el prompt del sistema y se monitorean con logs.

---

Paso 2 — Preparar el conocimiento del bot (RAG)

RAG significa Retrieval-Augmented Generation. La idea es simple: en vez de enviarle a OpenAI “todo el contenido del curso” cada vez (caro y no cabe en el contexto), preprocesas el contenido en pedacitos, indexas esos pedacitos con embeddings, y por cada pregunta del estudiante recuperas solo los 3 a 5 pedacitos más relevantes para incluir en el prompt.

Mecánica

1. Tomar todo el contenido del curso aprobado para el bot (PDFs, texto plano, transcripciones).
2. Partirlo en chunks de ~500 a 800 tokens cada uno (aproximadamente un párrafo o dos).
3. Generar un embedding por chunk usando text-embedding-3-small de OpenAI ($0.02 por millón de tokens — casi gratis).
4. Guardar los embeddings en una tabla nueva de la base de Moodle (local_chatbot_chunks con columnas: id, course_id, content, embedding).
5. Cuando llega una pregunta del estudiante: generar embedding de la pregunta, calcular similitud coseno contra los embeddings guardados, traer los top 3–5 chunks más cercanos.
6. Incluir esos chunks en el system prompt del LLM.

Sobre la búsqueda vectorial

Si tu Moodle corre sobre PostgreSQL, puedes usar la extensión pgvector, que hace la búsqueda eficiente. Si corre sobre MySQL o MariaDB, hacer la similitud coseno en PHP iterando sobre los chunks funciona perfectamente hasta unos miles de chunks por curso (un curso promedio raramente tiene más de 200 a 500 chunks, así que es trivial); o en últimas versiones de MariaDB podrás encontrar soporte directo para vectorización.

---

Paso 3 — Crear el plugin Moodle mínimo

Estructura mínima de archivos para un plugin tipo local:

local/edulabs_chatbot_diy/
├── version.php
├── settings.php
├── lang/en/local_edulabs_chatbot_diy.php
├── db/
│   ├── access.php
│   └── services.php
├── classes/
│   ├── openai_client.php
│   ├── rag_retriever.php
│   └── external/
│       └── chat_handler.php
├── amd/src/
│   └── widget.js
├── templates/
│   └── widget.mustache
└── styles.css

version.php declara el plugin:

<?php
defined('MOODLE_INTERNAL') || die();
$plugin->component = 'local_edulabs_chatbot_diy';
$plugin->version   = 2026053000;
$plugin->requires  = 2024100100; // Moodle 4.5+
$plugin->maturity  = MATURITY_ALPHA;
$plugin->release   = '0.1';

settings.php define los settings del admin (API key, modelo a usar):

<?php
defined('MOODLE_INTERNAL') || die();
if ($hassiteconfig) {
    $settings = new admin_settingpage('local_edulabs_chatbot_diy',
        get_string('pluginname', 'local_edulabs_chatbot_diy'));
    $ADMIN->add('localplugins', $settings);

    $settings->add(new admin_setting_configpasswordunmask(
        'local_edulabs_chatbot_diy/openai_api_key',
        'OpenAI API Key',
        'Tu API key de OpenAI Platform.',
        ''
    ));

    $settings->add(new admin_setting_configtext(
        'local_edulabs_chatbot_diy/model',
        'Modelo de OpenAI',
        'Recomendado: gpt-4o-mini para costo, gpt-4o para mejor calidad.',
        'gpt-4o-mini',
        PARAM_TEXT
    ));
}

Eso es todo el scaffolding inicial. Si nunca creaste un plugin Moodle, este tutorial oficial te lleva paso a paso por la estructura.

---

Paso 4 — Cliente OpenAI desde PHP

El cliente HTTP es la pieza más simple. Una clase de unas 50 líneas:

<?php
namespace local_edulabs_chatbot_diy;
defined('MOODLE_INTERNAL') || die();

class openai_client {
    private const ENDPOINT = 'https://api.openai.com/v1/chat/completions';

    public function chat(array $messages): string {
        $apikey = trim(get_config('local_edulabs_chatbot_diy', 'openai_api_key'));
        $model  = get_config('local_edulabs_chatbot_diy', 'model') ?: 'gpt-4o-mini';

        $payload = [
            'model'       => $model,
            'messages'    => $messages,
            'max_tokens'  => 500,
            'temperature' => 0.3,
        ];

        $ch = curl_init(self::ENDPOINT);
        curl_setopt_array($ch, [
            CURLOPT_POST           => true,
            CURLOPT_RETURNTRANSFER => true,
            CURLOPT_HTTPHEADER     => [
                'Authorization: Bearer ' . $apikey,
                'Content-Type: application/json',
            ],
            CURLOPT_POSTFIELDS     => json_encode($payload),
            CURLOPT_TIMEOUT        => 30,
        ]);
        $response = curl_exec($ch);
        curl_close($ch);

        $data = json_decode($response, true);
        return $data['choices'][0]['message']['content'] ?? 'Sin respuesta.';
    }
}

temperature: 0.3 baja la “creatividad” del modelo, lo cual conviene en un FAQ educativo donde queremos respuestas consistentes y ajustadas al material.

---

Paso 5 — Endpoint y widget

El endpoint (classes/external/chat_handler.php) recibe el mensaje vía AJAX, recupera los chunks relevantes con RAG, arma el prompt, llama a OpenAI y devuelve la respuesta:

public static function handle(string $message, int $courseid): string {
    // 1. Recuperar chunks relevantes via RAG
    $retriever = new rag_retriever();
    $chunks    = $retriever->topk($message, $courseid, 4);
    $context   = implode("\n---\n", array_column($chunks, 'content'));

    // 2. Armar system prompt
    $system = "Eres un asistente del curso. Responde solo en base al material a continuación. "
            . "Si la respuesta no está en el material, di 'No tengo esa información en el material del curso'. "
            . "No des respuestas a tareas evaluables ni opines sobre calificaciones, eso le compete al profesor.\n\n"
            . "MATERIAL:\n$context";

    // 3. Llamar a OpenAI
    $client = new openai_client();
    return $client->chat([
        ['role' => 'system', 'content' => $system],
        ['role' => 'user',   'content' => $message],
    ]);
}

El widget (amd/src/widget.js) es un botón flotante que abre un panel con input + lista de mensajes. Para el MVP, unas 150 líneas de JS vanilla resuelven. Si quieres ahorrar tiempo y tu Moodle no tiene restricciones de estilo estrictas, puedes reutilizar cualquier componente open source de chat widget (hay decenas en npm).

---

Paso 6 — Probar y desplegar

Antes de subir a producción:

• Probar con datos reales del curso. Cargar el material verdadero, no lorem ipsum. Verificar que las respuestas se ajusten al material y digan “no tengo esa información” cuando corresponda.
• Probar el manejo de errores. ¿Qué pasa si la API de OpenAI cae? ¿Si la API key está mal? ¿Si el usuario no tiene permisos en el curso? Cada uno necesita un mensaje claro.
• Logging de uso. Guarda una tabla local_chatbot_log con (timestamp, userid, courseid, message, tokens_in, tokens_out). Sin esto, no puedes medir costos ni calidad.
• Permisos. Asegúrate de que solo usuarios matriculados en el curso pueden hacer preguntas sobre ese curso.
• Privacidad. Si vas a enviar a OpenAI datos potencialmente sensibles, verifica que tu acuerdo con OpenAI usa data de manera consistente con la regulación local (Habeas Data en Colombia, GDPR si tienes usuarios en la UE, etc.).

Una vez probado, instala en producción como cualquier plugin Moodle: subir al servidor, navegar a Site administration → Notifications, confirmar la instalación, configurar settings, eso es todo.

---

Costos reales: el cálculo que nadie quiere que hagas

Aquí viene la parte que las aplicaciones comerciales prefieren que no leas. Hagamos el cálculo concreto sobre un caso real.

Escenario: un diplomado universitario de 4 meses, 50 estudiantes matriculados, con un chatbot tipo FAQ-de-contenido (alcance 1 + 2 de la sección anterior).

Volumen estimado de uso (conservador)

• Tasa de adopción realista: ~60% de los estudiantes lo usa con regularidad → 30 usuarios activos.
• Frecuencia: cada usuario activo hace 2 consultas por semana en promedio.
• Cada consulta dura ~4 turnos (pregunta inicial + 3 follow-ups).
• Total por semana: 30 × 2 × 4 = 240 turnos.
• Total mensual: ~1,000 turnos.

Hagamos el cálculo con un escenario “agresivo” para no quedarnos cortos: usemos 2,400 turnos/mes, equivalente a 50 estudiantes usándolo activamente con alta intensidad.

Tokens por turno (con RAG)

• Input: ~500 tokens (system prompt) + ~500 tokens (historial) + ~50 tokens (pregunta) + ~1,500 tokens (4 chunks recuperados) = ~2,550 tokens input.
• Output: ~300 tokens promedio (una respuesta de un par de párrafos).

Costo con GPT-4o-mini (el modelo recomendado para este caso)

Precios públicos de OpenAI Platform:

• GPT-4o-mini input: $0.15 por millón de tokens.
• GPT-4o-mini output: $0.60 por millón de tokens.

Cálculo mensual:

• Input total: 2,400 turnos × 2,550 tokens = 6,120,000 tokens → 6.12M × $0.15 = $0.92
• Output total: 2,400 × 300 = 720,000 tokens → 0.72M × $0.60 = $0.43
• Embeddings (indexación inicial + re-indexación ocasional): centavos.

Costo mensual de API: $1.35 USD.
Menos de un café por mes.

Costo con GPT-4o (modelo más capaz, usualmente innecesario para FAQ)

• Input: 6.12M × $2.50 = $15.30
• Output: 0.72M × $10.00 = $7.20
• Total mensual: ~$22.50 USD.

Aún en el peor caso, con el modelo premium y uso elevado, no llegamos a $25 al mes.

Costo total de propiedad (TCO), seamos honestos

El API es solo una parte. Sumemos el resto:

Concepto	Costo	Notas
Desarrollo inicial usando VibeCoding (40–80 h)	$500 – $1,200 una vez	Equipo interno apoyado por VibeCoding
Hosting	$0 adicional	Corre dentro de tu Moodle existente
API mensual (uso real)	$10 – $100	Según volumen y modelo
Mantenimiento (2–4 h/mes)	$60 – $100/mes	Updates de OpenAI, bugs, prompts

Comparación honesta con solución comercial

Una solución comercial promedio en este mercado cobra entre $200 y $1000+ USD mensuales por institución para algo equivalente, sin contar setup ni horas de integración.

• Comercial año 1: $2,400 – $12,000
• Comercial año 2: $2,400 – $24,000
• Comercial 5 años: $12,000 – $60,000

• Self-build año 1: $1,000 – $2,000 (la mayoría es desarrollo inicial)
• Self-build año 2: $700 – $3,000
• Self-build 5 años: $3,500 – $15,000

A 5 años, el rango bajo del self-build cuesta una fracción del rango alto del comercial. Y el self-build es tuyo, con tus datos, tu API key, sin dependencias, sin SLA ajenos.

Las diferencias se vuelven más dramáticas cuando la institución tiene 200, 500 o 2,000 estudiantes. Los proveedores comerciales suelen escalar precio por estudiante o por interacción; el costo real del API escala más lentamente (más estudiantes hacen más preguntas, pero el costo por token es plano y predecible).

Si tu institución tiene 1,000 estudiantes y paga $5/estudiante/mes a un proveedor, son $60,000/año. El API real para esos 1,000 estudiantes, incluso con uso intenso, probablemente costaría $200–800/mes ($2,400–9,600/año). La diferencia anual es de unos $50,000 USD que podrías invertir en otras cosas, como más cursos, más docentes, infraestructura, becas.

Conclusión de la sección de costos

El costo de operación de un chatbot LMS en OpenAI no es la barrera. La barrera es el desarrollo inicial (~500 a mil dólares una sola vez) y la decisión de tomar control de la tecnología. Si tu institución tiene equipo técnico interno o relación con un proveedor de desarrollo, el cálculo build-vs-buy se inclina fuerte hacia build apenas pasas del primer año.

Si estás pagando muchos cientos o miles de dólares mensuales por una solución comercial cuya arquitectura técnica es la que describimos en este post, vale la pena hacer este cálculo internamente y tomar la decisión informada.

---

La pregunta incómoda: ¿un chatbot realmente ayuda a aprender?

Hasta aquí hablamos de cómo construir un chatbot y cuánto cuesta. Lo que pocos proveedores te van a decir es que la respuesta a “¿este chatbot mejora el aprendizaje de mis estudiantes?” no es un sí automático. En muchos casos, en la gran mayoría, es un no.

Esto no es opinión: es lo que dice la investigación pedagógica reciente sobre IA en educación. Te resumimos lo que importa.

---

El problema de la descarga cognitiva

La descarga cognitiva (cognitive offloading) es lo que hacemos cuando transferimos una tarea mental a una herramienta externa. Anotar algo en lugar de memorizarlo, usar el GPS en lugar de aprender la ruta, preguntarle a un chatbot en lugar de buscar en el material de clase.

La descarga cognitiva no es mala en sí misma. En contextos profesionales o cotidianos, descargar tareas en herramientas externas libera capacidad para problemas más complejos. Es eficiencia.

El problema es que el aprendizaje funciona al revés que la eficiencia. Los estudios de Robert Bjork y otros sobre “dificultades deseables” (desirable difficulties) muestran que el esfuerzo mental requerido para recuperar información o resolver problemas es justamente lo que produce aprendizaje duradero. Si una herramienta elimina ese esfuerzo, elimina también el mecanismo cognitivo por el que el conocimiento se consolida.

En términos concretos:

• Cuando un estudiante busca una respuesta en el material del curso, está practicando recuperación, organizando información, construyendo conexiones. Eso queda.
• Cuando le pregunta a un chatbot y recibe la respuesta sintetizada, salta esos pasos. La respuesta entra rápido y sale rápido. El conocimiento no se consolida igual.

Esto está respaldado por investigación de Henry Roediger y Jeffrey Karpicke sobre el efecto de la práctica de recuperación; por trabajos de Evan Risko y Sam Gilbert sobre los costos cognitivos a largo plazo de la descarga; y por estudios recientes específicos sobre uso de ChatGPT en contextos académicos que muestran caídas en retención cuando los estudiantes confían demasiado en el modelo para tareas conceptuales.

Implicación práctica

Un chatbot que responde con detalle a “explícame la relación entre límites y derivadas en cálculo” puede sentirse útil al estudiante en el momento, pero está sustituyendo la actividad cognitiva que el curso intenta producir. A largo plazo, lo más probable es que el estudiante aprenda menos, no más, con el chatbot disponible.

Esto no es un argumento contra la IA en educación. Es un argumento contra un cierto uso de la IA en educación: el uso que asume que “más respuestas más rápido = mejor aprendizaje”. Esa ecuación es totalmente falsa.

---

Cuándo SÍ tiene sentido un chatbot en tu Moodle

Hay usos del chatbot donde el balance se inclina a favor:

1. Logística y wayfinding. “¿Cuándo se entrega la próxima tarea?”, “¿Dónde encuentro el syllabus?”, “¿Cómo subo un archivo a esta sección?” — esto no es aprendizaje, es navegación. Un chatbot que responde estas preguntas reduce fricción y libera al instructor de responder lo mismo 50 veces. Aquí el chatbot es genuinamente útil.

2. Reducir la carga repetitiva del instructor. Cuando el chatbot responde las 10 preguntas más frecuentes del curso bien, el instructor puede dedicar su tiempo a las preguntas que sí requieren su criterio. El bot se vuelve un primer filtro, no un sustituto.

3. Acceso 24/7 a información operativa. Un estudiante que se conecta sábado a la noche para revisar fechas no tiene a quién preguntarle. Un chatbot bien diseñado resuelve eso sin esperar al lunes.

4. Triage de dudas. El bot atiende lo que puede; lo que no puede, lo escala al profesor con contexto preformateado (“el estudiante X preguntó Y, esto es lo que ya intenté responder”). El instructor entra solo cuando agrega valor real.

5. Práctica metacognitiva guiada. Un chatbot bien diseñado (no genérico) puede preguntarle al estudiante “¿qué intentaste primero?”, “¿qué parte del material revisaste?”, antes de dar cualquier respuesta. Esto invierte el flujo y obliga al estudiante a esfuerzo mental antes de recibir ayuda. Pero esto requiere diseño instruccional explícito, no se obtiene del bot por defecto.

Cuándo NO tiene sentido

• Responder dudas conceptuales que el curso quiere que el estudiante resuelva con el material.
• Resolver ejercicios o tareas evaluables.
• Reemplazar la retroalimentación humana en tareas formativas.
• Sustituir interacción con pares (foros, grupos de estudio, etc…).

Si el chatbot que compras o construyes hace lo de la primera lista bien y se abstiene de lo de la segunda, sumas. Si hace todo indiscriminadamente, restas y afectas a tus estudiantes seriamente.

---

Más allá del chatbot: lo que realmente mueve la aguja

El chatbot es la aplicación más visible y más fácil de demostrar de IA en educación. Por eso el mercado está saturado de esas aplicaciones. Pero hay capacidades más interesantes desde el punto de vista pedagógico, aunque sean menos espectaculares en una demo:

• Detección temprana de estudiantes en riesgo combinando señales de engagement, calificaciones y patrones de acceso. Esto se hace con datos del LMS + un modelo predictivo + un poco de LLM para explicar resultados. Permite que el instructor intervenga antes de que sea tarde.
• Análisis automático de participación en foros clasificando intervenciones (constructivas, pasivas, ausentes) y dándole al instructor un mapa de quién aporta qué.
• Generación asistida (pero no autónoma) de evaluaciones alineadas a objetivos pedagógicos explícitos, con revisión obligatoria del instructor.
• Calificación asistida de respuestas abiertas contra rúbrica, donde la IA propone y el instructor aprueba.

Estas son las capacidades donde la IA hace lo que el humano no podría hacer a escala: cruzar datos, detectar patrones, sintetizar señales débiles. El chatbot, en cambio, hace lo que el humano sí podría hacer, solo más rápido y en muchos casos, peor para el aprendizaje.

Si tu institución va a invertir en IA educativa, vale la pena pensar dónde tiene sentido. Un chatbot básico para logística probablemente puedas construirlo tú mismo siguiendo esta guía. Para lo realmente útil, vas a necesitar más que un chatbot o un plugin basado en en el API de OpenAI.

---

Cierre

Recapitulando lo que esperamos te lleves de este post:

1. Técnicamente, un chatbot LMS es un proyecto chico. Cuatro componentes, ~500 líneas de código entre PHP y JS, 2 a 4 días de un desarrollador con experiencia razonable.
2. El costo de operación es despreciable. Para un curso de 50 estudiantes, hablamos de $10 a $50 mensuales en API, según modelo y uso. El costo principal es el desarrollo inicial, que se paga una sola vez.
3. El precio de las soluciones comerciales en este mercado refleja capacidad de pago institucional, no costo real de la tecnología. Hacer el cálculo build-vs-buy a 3 a 5 años casi siempre favorece construir o contratar desarrollo a la medida, especialmente si tu institución tiene más de unos cientos de estudiantes.
4. Un chatbot, por sí solo, no mejora el aprendizaje. Para algunos usos suma (logística, triage, 24/7). Para otros usos resta (sustituye la actividad cognitiva que produce aprendizaje real). El diseño instruccional importa más que la tecnología.
5. Si vas a invertir en IA educativa, mira más allá del chatbot. Las aplicaciones de IA que realmente mueven indicadores pedagógicos son las que cruzan datos, predicen y orquestan, no las que solo responden. No son aplicaciones que dependen del API de OpenAI, son modelos propios, a la medida.

Construir tu propio chatbot con esta guía probablemente te tome menos de una semana y te ahorre, en algunos casos, decenas de miles de dólares a lo largo de los próximos años.

---

Recursos

• OpenAI Platform — pricing oficial
• Moodle Developer Documentation — Plugin types
• pgvector — extensión PostgreSQL para búsqueda vectorial
• Bjork, R. A. & Bjork, E. L. (2011). Making things hard on yourself, but in a good way. Psychology and the Real World.
• Risko, E. F. & Gilbert, S. J. (2016). Cognitive offloading. Trends in Cognitive Sciences, 20(9).
• Karpicke, J. D. & Roediger, H. L. (2008). The critical importance of retrieval for learning. Science, 319.

---

Imágenes editoriales creadas con IA por el equipo de Edu Labs. Las marcas Moodle y Moodle Workplace son propiedad de Moodle Pty Ltd.