Inteligencia artificial · Moodle · RAG · Arquitectura
IA local en Moodle: guía para entender la arquitectura, RAG y los modelos
La IA local en Moodle permite ejecutar modelos de inteligencia artificial dentro de una infraestructura controlada por la institución. Pero instalar un modelo es solo una pequeña parte del problema: para construir un servicio útil necesitas integrar permisos, documentos, RAG, embeddings, modelos, colas, observabilidad y gobierno.
Cuando una institución conecta por primera vez un chatbot a Moodle, la demostración suele resultar sorprendente. El alumno pregunta, la inteligencia artificial responde y parece que la parte difícil ya está resuelta.
Sin embargo, una prueba que funciona con diez personas todavía está muy lejos de representar un servicio capaz de atender a todo un campus virtual.
En producción aparecen preguntas menos vistosas, pero mucho más importantes: ¿qué datos estamos procesando?, ¿quién puede consultar cada documento?, ¿qué ocurre cuando llegan doscientas preguntas simultáneas?, ¿cómo corregimos una respuesta equivocada?, ¿cómo actualizamos el conocimiento?, ¿cuánto costará mantener el sistema?
La IA local intenta responder a parte de esos problemas ejecutando los modelos dentro de infraestructura controlada por la propia organización. Puede ser un servidor físico, un centro de datos, una nube privada o una VPC aislada.
Lo importante no es que la GPU esté físicamente al lado de Moodle. Lo importante es entender quién controla el procesamiento, los modelos, los datos y las políticas de acceso.
Imagen sugerida: ia-local-moodle-arquitectura-hero.png
ALT: Arquitectura de IA local conectada con Moodle mediante RAG, modelos y una base vectorial
Leyenda: Una arquitectura privada de IA para Moodle incorpora varias capas alrededor del modelo: integración, recuperación, seguridad e infraestructura.
Prompt: Ilustración editorial horizontal 16:9 estilo AMS Notebook Sketch Software Engineering. Representar Moodle a la izquierda conectado mediante una capa segura de integración con una infraestructura privada de inteligencia artificial. Mostrar middleware, RAG, documentos, embeddings, base vectorial, motor de inferencia y modelo local. Añadir observabilidad y un perímetro de infraestructura privada. Fondo papel cálido #FAF8F5, líneas navy #0f2742, cian #06b6d4, verde #16a34a y naranja #f97316. Estética técnica artesanal, arquitectura clara, sin robots, sin aspecto futurista, sin logos comerciales y con muy poco texto integrado.
TL;DR: IA local en Moodle en seis ideas
- IA local significa ejecutar la inferencia dentro de infraestructura controlada por la institución.
- No significa entrenar un modelo desde cero. Habitualmente utilizaremos modelos ya entrenados.
- Para trabajar con temarios, normativa o documentación institucional, RAG suele ser una pieza fundamental.
- El modelo es solo una capa: también necesitamos permisos, recuperación, embeddings, colas, observabilidad y operación.
- Una API externa, una arquitectura privada y un modelo híbrido pueden ser soluciones válidas según el caso.
- El primer paso no debería ser comprar una GPU, sino definir un problema pequeño que podamos medir.
Índice de contenidos
- Qué significa realmente IA local en Moodle
- Cuatro conceptos que conviene separar
- API externa, IA local o arquitectura híbrida
- Cómo funciona realmente RAG
- Los cinco componentes de la arquitectura
- Cómo elegir modelos y hardware
- Plugin Moodle, middleware o arquitectura híbrida
- Casos de uso
- Caso práctico de tutor RAG
- Errores frecuentes
- Roadmap de implantación
- Cómo medir un sistema RAG
- Checklist de madurez
- Preguntas frecuentes
¿Qué es exactamente la IA local en Moodle?
Podemos considerar IA local en Moodle una arquitectura en la que las funcionalidades de inteligencia artificial utilizadas desde el LMS se ejecutan, total o parcialmente, en infraestructura controlada por la institución.
Imaginemos que un estudiante abre un bloque denominado “Asistente del curso” y pregunta:
¿Cuál es el plazo para solicitar la evaluación alternativa?
Con una integración basada en una API externa, Moodle podría enviar la pregunta y determinados fragmentos documentales a un proveedor.
Con una arquitectura local, Moodle envía la solicitud a un servicio privado. Ese servicio recupera la normativa que el estudiante tiene permiso para consultar, construye el contexto y llama a un modelo ejecutado dentro de la infraestructura institucional.
Para el estudiante, la experiencia puede ser prácticamente idéntica.
La diferencia se encuentra detrás: ubicación del procesamiento, control de datos, coste operativo, capacidad de auditoría, modelos utilizados y responsabilidad de mantenimiento.
Idea clave: IA local no es un producto que instalamos en Moodle. Es una arquitectura formada por decisiones sobre modelos, infraestructura, recuperación de información, permisos, operación y gobierno.
Antes de diseñar nada: cuatro conceptos que conviene separar
En muchas conversaciones sobre inteligencia artificial se utilizan indistintamente términos que describen problemas diferentes. Separarlos evita expectativas poco realistas y ayuda a dimensionar correctamente el proyecto.
1. Entrenamiento e inferencia son cosas diferentes
Entrenar un modelo significa modificar sus parámetros utilizando grandes conjuntos de datos y una cantidad considerable de capacidad de cálculo.
Inferir significa utilizar un modelo que ya está entrenado para obtener una respuesta.
La mayoría de proyectos de IA local en Moodle no necesitan entrenar un modelo desde cero. Descargan un modelo existente y construyen alrededor de él prompts, RAG, herramientas y políticas.
Es parecido a instalar PostgreSQL: utilizamos el motor, pero no necesitamos desarrollar nuestro propio sistema gestor de bases de datos.
2. Un modelo no es una base de conocimiento
Un modelo de lenguaje conoce patrones aprendidos durante su entrenamiento, pero no sabe automáticamente qué contiene la guía docente publicada ayer, qué versión de una normativa está vigente o qué documentos tiene permiso para consultar un estudiante concreto.
Para resolver ese problema aparece RAG —Retrieval-Augmented Generation—.
El sistema de recuperación aporta la evidencia. El modelo utiliza esa evidencia para construir la respuesta.
Modelo mental útil: el sistema de recuperación busca la información; el modelo ayuda a interpretarla y redactarla.
3. Local no significa necesariamente on-premise
Una solución privada puede ejecutarse dentro del edificio, en un centro de datos o en una nube privada.
La pregunta relevante no es únicamente dónde está físicamente la máquina, sino:
- quién controla la infraestructura;
- quién tiene acceso;
- dónde se procesan los datos;
- qué información se registra;
- qué modelos se utilizan;
- qué políticas de retención existen.
4. Privado no significa automáticamente seguro
Ejecutar la inferencia dentro de una red privada elimina determinados intercambios con terceros, pero no corrige unos permisos incorrectos, documentos indexados indebidamente, logs con información personal o respuestas entregadas al usuario equivocado.
La seguridad depende del sistema completo.
Vocabulario mínimo
- Token: unidad utilizada por el modelo para procesar texto.
- Ventana de contexto: cantidad de información que puede considerar en una petición.
- Embedding: representación numérica que permite comparar significado aproximado.
- Base vectorial: sistema utilizado para buscar embeddings próximos.
- RAG: patrón que recupera información antes de generar una respuesta.
- Motor de inferencia: software encargado de cargar y servir el modelo.
- Cuantización: reducción de precisión de los pesos para disminuir memoria y cálculo.
- Guardrail: mecanismo que restringe acciones o respuestas.
API externa, IA local o arquitectura híbrida
Las APIs comerciales son una forma excelente de validar ideas. Permiten comenzar rápidamente y evitan gestionar modelos e infraestructura.
El problema aparece cuando el prototipo se convierte en un servicio permanente y empiezan a importar volumen, privacidad, disponibilidad, dependencia tecnológica y coste.
API externa
Encaja bien para prototipos, bajo volumen y casos en los que los datos pueden tratarse mediante un proveedor externo.
Reduce enormemente la carga operativa inicial y facilita acceder a modelos avanzados.
IA local
Encaja bien cuando necesitamos más control sobre modelos, versiones, datos, costes o comportamiento.
A cambio, la institución asume una mayor responsabilidad técnica y operativa.
Arquitectura híbrida
Encaja bien cuando existen tareas y datos con diferentes niveles de sensibilidad.
Permite decidir qué carga se procesa localmente y cuál puede delegarse.
| Enfoque | Ventaja principal | Limitación | Cuándo encaja |
|---|---|---|---|
| API externa | Rapidez | Dependencia y coste variable | POC, bajo volumen |
| IA local | Control | Operación propia | Datos sensibles o uso recurrente |
| Híbrida | Flexibilidad | Mayor complejidad de gobierno | Distintos tipos de datos y cargas |
No existe una obligación de elegir un único enfoque. Una institución puede utilizar modelos locales para documentación interna y APIs externas para tareas genéricas sin información sensible.
Por qué una API externa puede dejar de ser suficiente
Coste variable
Mientras el uso es pequeño, el coste por consumo puede ser irrelevante. Cuando el sistema se extiende a miles de usuarios, empiezan a importar volumen, contexto y picos de demanda.
Una conversación tampoco procesa únicamente la última frase escrita. Puede incluir instrucciones, historial y contexto documental.
Protección de datos y propiedad intelectual
Las consultas pueden contener nombres, dudas académicas, calificaciones, borradores, materiales internos o información especialmente sensible.
Por eso el análisis debe realizarse sobre el flujo concreto de información, no sobre una afirmación genérica como “el proveedor cumple RGPD”.
Dependencia tecnológica
Una funcionalidad puede quedar condicionada por cambios de precios, límites, disponibilidad o retirada de modelos.
No significa que utilizar un proveedor sea una mala decisión. Significa que esa dependencia debe ser conocida.
Control pedagógico
En un LMS no siempre queremos que la IA proporcione inmediatamente una respuesta completa.
Puede interesar que aporte pistas, cite materiales, haga preguntas, evite determinadas actividades evaluables o derive al profesor cuando no dispone de evidencia.
RAG: cómo pasa un PDF de Moodle a convertirse en contexto para una respuesta
Una de las mejores formas de entender RAG consiste en separar dos procesos.
Flujo A: preparar los documentos
- Detectar el documento. Moodle registra que un contenido ha sido creado o actualizado.
- Comprobar permisos. El sistema determina si puede indexarse y dentro de qué contexto.
- Extraer el contenido. Obtiene texto de PDF, DOCX, HTML u otros formatos.
- Limpiar. Elimina ruido y conserva estructura útil.
- Fragmentar. Divide el documento en unidades recuperables.
- Crear embeddings. Convierte cada fragmento en una representación vectorial.
- Almacenar. Guarda vector, texto, versión, procedencia y permisos.
Flujo B: responder una pregunta
- Recibir la consulta.
- Resolver identidad y permisos.
- Crear el embedding de la pregunta.
- Buscar únicamente en documentos autorizados.
- Reordenar resultados cuando sea necesario.
- Construir el contexto.
- Generar la respuesta.
- Validar referencias y reglas.
- Mostrar el resultado.
El profesor no introduce realmente el PDF “dentro del LLM”. El documento se transforma en conocimiento recuperable. En cada consulta se envían únicamente los fragmentos seleccionados.
Ejemplo sencillo
Un estudiante pregunta: “¿Puedo entregar el proyecto después del 15 de mayo?”
La búsqueda semántica intenta localizar fragmentos relacionados con fecha límite, entrega o prórroga aunque no contengan exactamente las mismas palabras.
El modelo recibe esos fragmentos y redacta la respuesta. Si no existe suficiente evidencia, el comportamiento deseable es indicarlo y dirigir al estudiante hacia la fuente oficial.
Los cinco componentes de una arquitectura de IA local en Moodle
Podemos simplificar una arquitectura de este tipo en cinco capas. Seguridad, observabilidad y gobierno deberían atravesarlas todas.
1. Integración con Moodle
Es la capa que conoce el contexto real del usuario.
- usuario;
- curso;
- rol;
- grupo;
- capacidades;
- archivos;
- actividades;
- idioma;
- trazabilidad.
Puede materializarse como un bloque, una actividad, un plugin local, una herramienta dentro del editor o una tarea de fondo.
2. Orquestación y RAG
Coordina el flujo: recuperación, selección de modelo, prompts, guardrails, herramientas y tratamiento de respuestas con poca confianza.
También es un buen lugar para aplicar políticas comunes.
3. Embeddings y base vectorial
Los embeddings permiten comparar textos por proximidad semántica. La base vectorial almacena esas representaciones junto con los metadatos utilizados para filtrar los resultados.
En Moodle esos metadatos pueden incluir curso, grupo, cohorte, idioma, documento, versión o fecha de vigencia.
Una búsqueda excelente sin filtros de autorización es un problema de seguridad. Los permisos deben aplicarse antes o durante la recuperación, no después de introducir el contenido en el prompt.
4. Modelo y motor de inferencia
El modelo genera el texto. El motor de inferencia se encarga de cargarlo, gestionar memoria, recibir solicitudes y generar tokens.
Herramientas como Ollama, llama.cpp o vLLM representan aproximaciones diferentes al problema de servir modelos.
5. Infraestructura y operación
Incluye CPU, GPU, VRAM, RAM, almacenamiento, red, contenedores, colas, backups y monitorización.
Esta capa determina si tenemos una demostración o un servicio capaz de mantenerse.
La documentación también necesita ciclo de vida
Imaginemos que una normativa cambia.
Si indexamos la nueva versión pero mantenemos los vectores de la anterior, el sistema puede recuperar ambas y generar una respuesta incorrecta que parece perfectamente convincente.
Por eso conviene almacenar junto a cada documento:
- identificador;
- hash;
- versión;
- fecha de indexación;
- fecha de vigencia cuando proceda;
- estado;
- ámbito de acceso;
- procedencia.
Cuando una fuente cambia o desaparece, los vectores correspondientes deben invalidarse.
Cómo elegir un modelo sin empezar por los rankings
La pregunta “¿cuál es el mejor modelo?” está incompleta.
Un modelo puede destacar en razonamiento matemático y comportarse peor en instrucciones, español o extracción estructurada. Otro puede ofrecer gran calidad pero resultar demasiado lento para la concurrencia prevista.
Antes de elegir, prepararía un conjunto de tareas reales:
- preguntas cuya respuesta aparece en los documentos;
- preguntas que requieren combinar información;
- preguntas que deben rechazarse;
- resúmenes;
- clasificación;
- salida estructurada;
- terminología institucional;
- idiomas necesarios.
| Criterio | Pregunta práctica |
|---|---|
| Idioma | ¿Responde correctamente con la terminología del campus? |
| Instrucciones | ¿Respeta una regla como “no respondas sin evidencia”? |
| Licencia | ¿Permite nuestro uso? |
| Memoria | ¿Cabe en nuestra infraestructura? |
| Contexto | ¿Puede trabajar con el volumen de contexto necesario? |
| Latencia | ¿La espera es adecuada para el usuario? |
| Concurrencia | ¿Cuántas solicitudes puede atender? |
| Formato | ¿Genera JSON u otras estructuras de forma fiable? |
Recomendación práctica: empieza con el modelo más pequeño que alcance la calidad necesaria. Un modelo compacto suele facilitar experimentación, reducir latencia y aumentar la capacidad disponible.
Hardware: la GPU no se dimensiona por número de alumnos
VRAM
La VRAM almacena pesos y datos temporales utilizados durante la inferencia. La memoria necesaria depende del modelo, cuantización, contexto, batch, caché KV y concurrencia.
CPU o GPU
Una CPU puede ejecutar modelos pequeños y cuantizados y puede resultar perfectamente válida para procesamiento asíncrono.
Para conversación interactiva con mayor concurrencia, una GPU suele reducir significativamente la latencia.
Concurrencia
Una institución con 20.000 estudiantes puede necesitar poca capacidad si solo utiliza IA en un pequeño proceso interno. Otra con 2.000 estudiantes puede concentrar cientos de solicitudes durante determinadas actividades.
Por tanto, debemos medir:
- peticiones por segundo;
- usuarios concurrentes;
- longitud media de entrada;
- longitud media de salida;
- tiempo hasta el primer token;
- latencia total;
- tiempo en cola;
- uso de memoria.
Colas y procesamiento asíncrono
No todo necesita ejecutarse durante una petición web.
Indexar documentos, generar material en lote, clasificar recursos o recalcular embeddings son buenas candidatas para colas.
Separar este trabajo evita que una tarea costosa consuma workers PHP y afecte al funcionamiento normal de Moodle.
¿Plugin Moodle, middleware o arquitectura híbrida?
| Patrón | Ventajas | Limitaciones |
|---|---|---|
| Plugin | Acceso directo al contexto Moodle | Puede acoplar demasiada lógica al LMS |
| Middleware | Escalado y ecosistema IA independientes | Introduce otro servicio |
| Híbrido | Moodle mantiene contexto; middleware procesa IA | Requiere un contrato claro entre sistemas |
Para una arquitectura con vocación de crecer, el enfoque híbrido suele resultar especialmente interesante.
Moodle mantiene las responsabilidades que conoce mejor: usuario, curso, capacidades, archivos, eventos y experiencia.
El middleware se especializa en recuperación, embeddings, modelos, inferencia y observabilidad.
APIs de Moodle especialmente útiles
- Events API: detectar cambios.
- Scheduled y adhoc tasks: procesamiento asíncrono.
- File API: acceder correctamente a los archivos.
- Access API: capacidades y autorización.
- Privacy API: tratamiento de información personal.
- Logging: trazabilidad.
Evitaría ejecutar inferencias largas directamente dentro de una petición PHP. Moodle y el servicio de IA deberían poder escalar y degradarse de forma independiente.
Casos de uso que encajan bien con IA local
Tutor RAG
Responde preguntas utilizando únicamente contenidos autorizados del curso y puede proporcionar referencias.
Asistente docente
Puede resumir, transformar materiales, proponer preguntas o preparar borradores para revisión del profesorado.
Clasificación y extracción
Etiquetado, extracción de fechas, normalización o clasificación suelen poder resolverse con modelos relativamente pequeños.
Normativa interna
La recuperación, las citas, la vigencia y el acceso importan aquí más que la creatividad del modelo.
Casos que requieren especial cautela
- Calificación final completamente automática.
- Detección supuestamente infalible de fraude o autoría.
- Asistentes generales sin un ámbito claramente definido.
- Procesamiento de información especialmente sensible.
- Sustitución del acompañamiento humano.
Caso práctico: tutor RAG para un máster
Supongamos un máster con 30 asignaturas, 400 estudiantes y aproximadamente 200 documentos.
Problema: muchas preguntas de los foros se repiten cada edición.
Objetivo: ofrecer un tutor que utilice únicamente materiales oficiales, cite la fuente y rechace preguntas para las que no existe evidencia.
Piloto: una asignatura, veinte documentos, cincuenta estudiantes y seis semanas.
Cuando el profesor sube un PDF
- Moodle detecta el cambio.
- Se crea una tarea de indexación.
- Se obtiene el archivo mediante File API.
- Se extrae y limpia el contenido.
- Se generan fragmentos y metadatos.
- Se calculan embeddings.
- La nueva versión queda disponible.
- Las versiones anteriores se invalidan.
Cuando el alumno pregunta
- El plugin valida al usuario.
- El middleware recibe el contexto autorizado.
- La recuperación aplica permisos.
- Se seleccionan los fragmentos.
- El sistema construye el contexto.
- El modelo redacta.
- Se validan las referencias.
- Moodle muestra respuesta y fuentes.
Errores frecuentes en proyectos de IA local para LMS
1. Empezar por el modelo
Descargar el modelo de moda produce una demo. No define usuarios, datos, riesgos ni criterios de éxito.
2. Subestimar la concurrencia
Una conversación individual no representa un campus durante un pico de actividad.
3. No versionar los documentos
La recuperación puede empezar a mezclar normativa antigua y nueva.
4. Aplicar permisos demasiado tarde
Un fragmento que el usuario no puede consultar nunca debería llegar al prompt.
5. Elegir un modelo excesivamente grande
Más parámetros pueden significar menor concurrencia y mayor coste sin una mejora relevante en la tarea.
6. Confiar únicamente en el prompt
“No inventes” es una instrucción, no una garantía.
7. No observar el sistema
Sin métricas resulta difícil saber si la latencia procede de Moodle, la cola, recuperación, reranking o inferencia.
8. Guardar más información de la necesaria
Registrar todos los prompts puede facilitar la depuración, pero también crear un nuevo almacén de datos personales o contenido confidencial.
Cómo empezar: roadmap de implantación en cinco fases
Una implantación progresiva permite aumentar la inversión a medida que disminuye la incertidumbre.
Fase 1. Definir el problema
- Caso de uso.
- Usuarios.
- Datos.
- Permisos.
- Riesgos.
- Criterios de éxito.
- Preguntas de evaluación.
Criterio de salida: sabemos explicar qué resolverá el piloto y cómo sabremos si ha funcionado.
Fase 2. Prueba técnica aislada
- Modelos.
- Embeddings.
- Chunking.
- Recuperación.
- Latencia.
- Requisitos aproximados de infraestructura.
Criterio de salida: existe al menos una configuración con suficiente calidad.
Fase 3. Integración mínima
- Plugin o bloque.
- Autenticación.
- Permisos.
- Ingesta.
- Consulta.
- Respuesta.
- Fuentes.
- Métricas.
Criterio de salida: usuarios reales pueden completar el flujo.
Fase 4. Piloto controlado
- Exactitud.
- Citas.
- Negativas.
- Latencia.
- Concurrencia.
- Feedback.
- Coste.
Criterio de salida: tenemos evidencia suficiente para ampliar, modificar o detener.
Fase 5. Industrialización
- Colas robustas.
- SLO.
- Observabilidad.
- Versionado.
- Rollback.
- Capacidad.
- Runbooks.
- Gobierno.
- Responsabilidades.
Criterio de salida: el servicio puede mantenerse sin depender de una única persona.
Cómo medir la calidad de un sistema RAG
Preguntar a unas cuantas personas si “les gusta el chatbot” no constituye una evaluación suficiente.
| Dimensión | Qué queremos saber |
|---|---|
| Recuperación | ¿Encuentra los fragmentos correctos? |
| Fidelidad | ¿La respuesta está respaldada por el contexto? |
| Relevancia | ¿Responde realmente a la pregunta? |
| Citas | ¿Las referencias son correctas? |
| Negativa | ¿Se niega cuando no existe información? |
| Rendimiento | ¿Responde dentro del objetivo? |
| Operación | ¿El servicio permanece estable? |
| Impacto | ¿Mejora una tarea real? |
Las métricas automáticas pueden ayudar a iterar, pero no sustituyen la evaluación de personas que conocen el dominio.
Checklist de madurez para IA local en Moodle
Antes de ampliar el piloto
- Existe un caso de uso concreto.
- Existe un propietario funcional.
- Usuarios y permisos están identificados.
- Los datos utilizados están documentados.
- La recuperación aplica autorización.
- Los documentos tienen versión y procedencia.
- Los contenidos eliminados dejan de recuperarse.
- Existe un conjunto de evaluación.
- El modelo ha sido probado con contenido real.
- Conocemos licencia y requisitos.
- Las tareas pesadas no bloquean Moodle.
- Se ha probado concurrencia.
- Se monitorizan latencia y errores.
- Existe procedimiento de rollback.
- Los logs tienen retención definida.
- Seguridad y protección de datos conocen el proyecto.
- El profesorado participa en la evaluación.
- Existe un responsable de operación.
- Hay documentación y runbooks.
- El servicio no depende de una única persona.
Una pregunta sencilla para medir madurez
Si mañana la persona que ha construido el prototipo no está disponible, ¿puede el resto del equipo actualizar un documento, investigar una respuesta incorrecta, cambiar de modelo y recuperar el servicio?
Si la respuesta es no, probablemente seguimos teniendo una prueba de concepto.
Gobierno: quién decide qué puede hacer la IA
Una arquitectura técnica también necesita una arquitectura de responsabilidades.
| Rol | Responsabilidad |
|---|---|
| Responsable académico | Finalidad, límites y calidad |
| Equipo Moodle | Integración, permisos, archivos y experiencia |
| Backend / IA | RAG, modelos, inferencia y evaluación |
| Infraestructura | Capacidad, disponibilidad y operación |
| Seguridad / DPO | Riesgos, privacidad, controles y retención |
| Docentes | Validez de contenidos y respuestas |
| Soporte | Incidencias y escalado |
Antes de comprar una GPU, crea este documento
Para empezar no necesitas una arquitectura definitiva. Necesitas una ficha del caso de uso.
- Problema: qué queremos mejorar.
- Usuarios: quién utilizará el sistema.
- Datos: qué información necesita.
- Sensibilidad: qué información no debe salir.
- Fuentes: qué documentación utilizará.
- Permisos: quién puede recuperar qué.
- Volumen: cuántas consultas esperamos.
- Concurrencia: qué picos debemos atender.
- Calidad: cómo evaluaremos las respuestas.
- Operación: quién mantendrá el servicio.
- Criterio de salida: qué resultado justificará seguir invirtiendo.
Preguntas frecuentes sobre IA local en Moodle
¿IA local significa ejecutar el modelo dentro de PHP?
No. Lo habitual es que Moodle se comunique mediante una API privada con un servicio independiente que se responsabiliza de RAG e inferencia.
¿Hay que entrenar un modelo propio?
Normalmente no. En la mayoría de proyectos resulta más razonable utilizar modelos existentes y especializar el comportamiento mediante RAG, instrucciones, herramientas y evaluación.
¿RAG elimina las alucinaciones?
No. Puede reducir errores al proporcionar evidencia, pero sigue siendo necesario evaluar recuperación, fidelidad, citas y capacidad de negarse a responder.
¿Qué diferencia existe entre embeddings y el modelo generativo?
Los embeddings permiten buscar similitud semántica. El modelo generativo utiliza el contexto recuperado para redactar la respuesta.
¿Se puede ejecutar sin GPU?
Sí. Puede resultar suficiente para modelos pequeños y cargas asíncronas. Para conversación interactiva o mayor concurrencia suele resultar más conveniente una GPU.
¿Ollama sirve para producción?
Puede ser suficiente para escenarios moderados. A medida que aumentan la concurrencia y las necesidades de serving, conviene evaluar alternativas diseñadas para ese tipo de carga.
¿Se puede utilizar pgvector?
Sí. Puede simplificar determinados proyectos. En producción conviene evaluar cuidadosamente aislamiento, rendimiento, backups y ciclo de vida antes de compartir infraestructura con la base crítica de Moodle.
¿Cuál es el mejor tamaño de chunk?
No existe un valor universal. Debe evaluarse con documentos y preguntas reales y, siempre que sea posible, respetando unidades semánticas como secciones, artículos o pasos.
¿La IA local siempre es más barata?
No. El coste debe incluir infraestructura, electricidad o cloud, almacenamiento, operación, monitorización, desarrollo y mantenimiento. Para poco volumen puede resultar más económica una API externa.
¿Qué modelo deberíamos utilizar?
Conviene comparar varios candidatos utilizando documentos, idioma y tareas reales de la institución, valorando calidad, licencia, memoria, latencia y concurrencia.
Siguiente paso
No empieces por el modelo: empieza por una pregunta que puedas medir
Selecciona un curso, un conjunto pequeño de documentos y un tipo concreto de consulta. Prepara primero las preguntas de evaluación, prueba la recuperación y después compara modelos.
Cuando el RAG funcione con suficiente calidad, integra el flujo con Moodle y mide permisos, latencia, concurrencia y utilidad con un grupo reducido.
Solo entonces tendrás datos suficientes para decidir si necesitas una API externa, infraestructura local o una arquitectura híbrida.
Conclusión
Ejecutar un modelo local es hoy mucho más accesible que hace unos años. Pero ese no es el reto principal.
El verdadero trabajo consiste en integrar correctamente identidad, permisos, documentos, recuperación, modelos, infraestructura, operación y gobierno.
Por eso no plantearía “tener IA local” como objetivo.
Lo plantearía como una posible decisión arquitectónica para resolver un problema concreto con mayor control sobre privacidad, comportamiento, costes o dependencia tecnológica.
Y seguiría el mismo principio que en cualquier otro sistema: empezar pequeño, separar responsabilidades, medir antes de escalar y añadir complejidad únicamente cuando exista una razón para hacerlo.
Deja una respuesta