Por qué un RAG conectado al LMS sigue alucinando

Un asistente recibe esta pregunta: «¿Puedo entregar el trabajo el lunes?». El buscador semántico encuentra la guía de la asignatura, un aviso del profesor y una copia del calendario. Los tres fragmentos hablan de la entrega y parecen pertinentes, por lo que el modelo responde que sí.

La respuesta puede seguir siendo falsa: la guía pertenece al curso anterior, el aviso se dirigía a otro grupo y el calendario general no recoge la ampliación individual registrada para ese alumno en el LMS. Ninguno de estos conflictos se resuelve buscando el fragmento con mayor similitud. Hace falta saber qué fuente tiene autoridad, desde cuándo rige, para quién es visible y si el estado actual contradice el documento.

Ese es el problema de muchos RAG educativos: conectan los datos correctos con el modelo mental equivocado. Tratan el LMS como una colección de textos y confían en que el modelo complete la respuesta a partir de los pasajes recuperados. Sin embargo, un LMS también contiene estados transaccionales, reglas, identidades, ámbitos, versiones y decisiones con efectos sobre personas concretas.

La tesis de este artículo es que un RAG para aprendizaje no debe recuperar texto y responder; debe reunir evidencia autorizada para una pregunta clasificada. Recuperar es una de las operaciones. Determinar la fuente de verdad, detectar huecos, resolver conflictos y abstenerse son operaciones distintas.

Un fragmento puede ser relevante para la pregunta y, al mismo tiempo, no estar autorizado para responderla.

RAG no convierte una fuente en verdadera

La generación aumentada con recuperación introduce información externa en la entrada del modelo. Eso suele mejorar las respuestas a preguntas que dependen de conocimiento ausente o cambiante, pero no altera la naturaleza generativa del sistema. NIST clasifica la confabulación como un riesgo propio de los modelos generativos: producen respuestas plausibles mediante predicción estadística y pueden introducir afirmaciones falsas.

La investigación específica sobre RAG confirma el límite. RAGTruth reunió casi 18.000 respuestas generadas con RAG y anotó afirmaciones no respaldadas o contradictorias. Astute RAG encontró que, en los conjuntos estudiados, alrededor de una quinta parte de las preguntas no tenía la respuesta correcta en ninguno de los pasajes recuperados y que los conflictos entre conocimiento interno y externo aparecían de forma apreciable. NoMIRACL mostró otro dilema: los modelos tienen dificultades tanto para abstenerse cuando los pasajes no contienen la respuesta como para reconocer la evidencia cuando sí está presente.

Esos resultados no miden un LMS concreto y no deben trasladarse como una tasa esperable en un entorno real. Sí desmontan una premisa: conectar una base vectorial no garantiza que los pasajes sean suficientes ni que el modelo los use de forma fiel.

Tampoco basta con aumentar top-k. Más fragmentos pueden mejorar la cobertura y empeorar la precisión, introducir versiones incompatibles o diluir la evidencia importante. El problema no es maximizar texto recuperado. Es construir el conjunto mínimo de evidencias que permite responder una pregunta determinada.

En un LMS hay cuatro fuentes de verdad diferentes

«Datos del LMS» parece una categoría homogénea hasta que se intenta responder una pregunta real. Separaría al menos cuatro regímenes:

Un índice vectorial funciona bien para localizar explicaciones dentro de contenido no estructurado. Es una mala fuente primaria para confirmar si un intento sigue abierto o si una calificación ya es visible. Esos son hechos de estado y deben leerse del sistema que los conserva. Del mismo modo, una rúbrica recuperada no responde por sí sola si el usuario tiene derecho a ver la retroalimentación de otra persona.

El error arquitectónico aparece cuando todo se transforma en fragmentos, se mezcla y se entrega al modelo con idéntico peso. La similitud semántica termina sustituyendo tres decisiones que no puede tomar: autoridad, vigencia y permiso.

Esta separación amplía una idea que ya defendí al hablar de evidencia gobernada para RAG y MCP: la entrada del modelo no es una bolsa de texto, sino un producto con procedencia, contrato y política.

La pregunta debe clasificarse antes de buscar

Antes del recuperador hace falta un planificador pequeño y verificable. No tiene que resolver la pregunta; tiene que decidir qué evidencias serían necesarias para resolverla. En un sistema educativo, estas clases cubren buena parte del tráfico:

La clasificación puede ser incierta. En ese caso el sistema pregunta o elige la ruta más restrictiva; no inventa el ámbito. «¿Cuándo termina?» necesita curso, actividad y zona horaria. «¿Qué me falta?» necesita saber si habla de finalización, calificación, competencia o documentación. Pedir precisión no es un fallo de experiencia: es impedir que una pregunta ambigua active una respuesta categórica.

El planificador produce un contrato de evidencia: hechos que deben estar presentes, fuente autorizada para cada hecho y condiciones de visibilidad. Solo después entran en juego los buscadores o las herramientas del LMS.

Cada evidencia necesita una ficha, no solo un fragmento

Un fragmento típico guarda texto, vector, identificador y quizá título. Para un LMS inteligente es insuficiente. La unidad recuperada debería viajar dentro de una ficha de evidencia parecida a esta:

{
  "source_id": "activity-policy-482-v7",
  "source_type": "policy",
  "authority": "course-official",
  "scope": { "course": 41, "group": "B" },
  "audience": ["student", "teacher"],
  "effective_from": "2026-09-01T00:00:00+02:00",
  "effective_until": null,
  "version": 7,
  "retrieved_at": "2026-10-04T18:22:10+02:00",
  "supports": ["deadline-rule"],
  "content": "..."
}

No todos los campos pertenecen al vector. Algunos se filtran antes de buscar; otros se validan después. Lo importante es que lleguen a la decisión. El modelo no debe deducir que un documento es oficial porque su tono parece normativo ni adivinar que una fecha de edición invalida otra versión.

La ficha permite aplicar reglas deterministas:

• excluir lo que el usuario no puede consultar antes de que llegue al modelo;
• priorizar una fuente oficial frente a una nota informal;
• rechazar versiones fuera de vigencia;
• detectar que dos evidencias autorizadas se contradicen;
• comprobar si cada hecho requerido está cubierto;
• construir una cita que apunta a una fuente identificable.

La procedencia visible no es solo una función de interfaz. Es información de control para el sistema y evidencia para evaluar después por qué contestó así.

La arquitectura tiene que resolver cuatro fallos distintos

El rótulo «alucinación» agrupa problemas que pertenecen a componentes diferentes. Si no se separan, el equipo ajusta el prompt para reparar un índice malo o cambia el modelo para compensar permisos mal aplicados.

1. Fallo de cobertura

La evidencia necesaria no se recuperó. Puede faltar por segmentación, consulta, índice, filtros excesivos o porque el dato vive en una API y nunca debió buscarse como texto. Se corrige en ingestión, planificación, recuperación o conexión con la fuente de estado.

2. Fallo de autoridad o conflicto

Se recuperan pasajes pertinentes pero incompatibles. Un anuncio posterior modifica la guía; una política corporativa y otra local cubren ámbitos distintos; el modelo recuerda una norma general que contradice la fuente oficial. Reordenar los pasajes por similitud no resuelve las precedencias. Hace falta una regla de autoridad y, cuando no exista, exponer el conflicto y escalarlo.

3. Fallo de utilización

La evidencia correcta está presente, pero el modelo omite una condición, mezcla dos pasajes o añade una afirmación no respaldada. Es un problema de generación y verificación. RAGChecker resulta útil como referencia porque separa diagnósticos de recuperación y generación, en vez de resumir todo en una puntuación final.

4. Fallo de autorización

La respuesta es correcta en los hechos y aun así no debería haberse producido para ese usuario. Recuperar la retroalimentación de otro alumno no es una «alucinación»; es una filtración. Los controles de curso, grupo, rol y persona deben ejecutarse antes de reunir las evidencias y volver a comprobarse en la fuente viva.

Esta taxonomía cambia la observabilidad. Cada respuesta debería registrar identificadores o huellas del plan, de las fuentes y de sus versiones, las decisiones de descarte, el tipo de conflicto y el resultado del verificador. No copiaría la consulta, la evidencia ni identificadores directos salvo que fueran imprescindibles para una finalidad documentada. El acceso, la conservación y el borrado de esa traza deben quedar definidos y sujetos al mismo ámbito de autorización que la respuesta. Sin un rastro proporcionado, «mejoramos el RAG» no significa nada comprobable.

Responder exige demostrar suficiencia

Después de recuperar la información y consultar el estado actual, un consolidador construye una matriz de afirmaciones. Para la pregunta del lunes podría exigir:

Con una pieza crítica sin cubrir, la respuesta «sí» o «no» sería una invención. El sistema debería limitarse a informar del plazo general y su zona horaria, reconocer que no puede confirmar una ampliación individual y señalar dónde verificarla. Esa respuesta es menos fluida y mucho más útil.

La suficiencia no equivale a acumular fuentes. Significa que cada afirmación necesaria tiene al menos una evidencia autorizada y que los conflictos están resueltos o declarados. Para una explicación conceptual puede bastar un pasaje canónico. Para una decisión individual se necesitan la identidad y el estado actual. Para una acción, además, hacen falta autorización y un contrato de resultado; el mismo principio aparece en la guía sobre MCP y Moodle.

El contrato de respuesta debe limitar al modelo

La respuesta no debería adoptar la forma de texto libre hasta el último paso. Usaría un contrato interno con cinco elementos:

1. Respuesta directa, limitada a afirmaciones cubiertas.
2. Evidencias por afirmación, con identificador y versión.
3. Ámbito, que declara curso, grupo, usuario y fecha cuando sean relevantes.
4. Incertidumbre o conflicto, expresado como estado, no escondido en una frase ambigua.
5. Siguiente acción segura, si falta información o se requiere una persona responsable.

Un verificador posterior intenta clasificar cada afirmación como respaldada, contradicha o fuera del contrato. Puede usar otro modelo, reglas o ambos, pero su salida no es una prueba de corrección: se evalúa por separado sobre casos anotados y registra tanto el desacuerdo como la incertidumbre. Tampoco recibe únicamente el texto final, sino las evidencias y el plan. Cuando el impacto es alto o el resultado no es concluyente, fuerza la abstención o una revisión humana.

Las citas ayudan al lector, pero no bastan como verificación. Un modelo puede adjuntar una fuente pertinente a una frase que esa fuente no demuestra. La comprobación debe relacionar cada afirmación con el pasaje, estado o regla exactos que la sostienen.

Evaluar el sistema requiere seis familias de pruebas

La exactitud media esconde los fallos que más importan en educación. Construiría un conjunto de evaluación por pregunta, usuario, curso, momento y respuesta esperada, con estas familias:

Añadiría pruebas de idioma, formulaciones coloquiales, errores tipográficos, preguntas de varios turnos y ataques que intenten cambiar el rol o ignorar una política. La respuesta correcta incluye a veces una aclaración, una negativa o una derivación. Si el conjunto de evaluación solo contiene preguntas contestables, el sistema aprenderá que siempre debe responder.

Las métricas deben identificar qué componente ha fallado: la recuperación se evalúa por su cobertura y precisión; la consolidación, por la autoridad, la vigencia y los permisos; la generación, por su fidelidad; y la decisión final, por el acierto de la abstención. Una única métrica de «calidad RAG» no señala qué reparar.

El primer piloto debe acotar el corpus

No empezaría indexando todo el campus. Elegiría un curso, dos tipos de pregunta y una fuente viva:

• preguntas conceptuales sobre contenido canónico;
• preguntas de plazo sobre una actividad;
• consulta autorizada a la configuración y extensiones efectivas de esa actividad.

El alcance debe incluir versiones antiguas, un documento conflictivo, dos grupos, una excepción individual y preguntas sin respuesta. Así se prueba la arquitectura, no solo un recorrido sin fallos. Los criterios de salida podrían ser:

1. ninguna evidencia cruza curso, grupo o persona sin permiso;
2. una versión caducada nunca gana a la vigente por similitud;
3. toda afirmación factual tiene evidencia asignada;
4. los conflictos no resueltos aparecen como conflicto;
5. la ausencia de una excepción personal fuerza respuesta limitada;
6. los fallos pueden atribuirse a planificación, recuperación, consolidación o generación;
7. cambiar una fuente provoca la reevaluación de los casos afectados.

Con ese piloto se aprende más que al cargar diez mil PDF y celebrar que el chatbot cite tres. También prepara el camino hacia lo que debería ser un LMS que gobierna la evidencia y no solo genera contenido.

Recuperar mejor no es gobernar

Un RAG conectado al LMS puede tener buenos embeddings, búsqueda híbrida, reordenación de resultados y un modelo potente, y seguir dando respuestas incorrectas. Esas mejoras actúan sobre partes necesarias del sistema, pero no deciden qué fuente manda, para quién rige, cuál es el dato actual o cuándo falta evidencia.

El cambio de modelo mental consiste en dejar de preguntar «¿qué fragmentos se parecen a la consulta?» y empezar por «¿qué hechos autorizados necesito para responder a esta persona, en este curso y en este momento?».

Cuando la arquitectura puede contestar esa segunda pregunta, la recuperación empieza a tener un lugar claro. Cuando no puede, añadir fragmentos solo hace que la respuesta equivocada llegue mejor documentada.