Hacer una ficha interactiva a partir de un PDF tiene dos partes. Una
es decidir qué se pregunta. La otra es colocar los campos: abrir el
documento, dibujar una caja encima de cada línea de puntos, ajustar el
tamaño, escribir la solución, repetirlo veinte veces y descubrir al
final que un campo tapa el enunciado siguiente.
Desde la versión 1.29, OpenWorksheets puede hacer
ese trabajo por nosotros. No con un botón dentro de la aplicación, sino
desde la conversación con la inteligencia artificial que ya usemos: se
le dice dónde está el PDF y ella lo abre, lee la página, coloca los
campos donde tocan, mira cómo ha quedado y guarda la
ficha lista para abrir en el editor. Y no solo convertir: si no partimos de ningún documento, podemos pedirle la ficha entera sobre un tema, y la escribe sobre hojas en blanco.
«Convierte en ficha interactiva de OpenWorksheets este PDF:
energia.pdf»
Este artículo explica qué es lo que hace posible eso (un servidor
MCP), qué se le puede pedir, qué hace falta para instalarlo y, sobre
todo, dónde están sus límites, que los tiene.
Pódcast del artículo realizado por Gemini Notebook
Qué es un servidor MCP
Una IA de las de conversar sabe redactar preguntas, pero no puede
abrir un archivo de nuestro disco ni escribir uno. Vive dentro de su
ventana de chat. El MCP (Model Context
Protocol, «protocolo de contexto del modelo») es el estándar que le
da manos: un programa pequeño que se instala en el ordenador y le ofrece
a la IA una lista de operaciones concretas que puede ejecutar.
El servidor MCP de OpenWorksheets ofrece las operaciones propias para
fabricar una ficha: abrir un PDF, leer el texto de una página
con las coordenadas de cada línea, colocar campos de
respuesta, tapar una zona, ver el resultado y guardar el paquete
.owpkg. La IA decide qué preguntar y dónde ponerlo; el
servidor hace el trabajo material y le dice cuándo se está
equivocando.
Que sea un programa local tiene una consecuencia práctica: el
archivo no se sube a ningún servicio. El PDF se abre en nuestro
ordenador, las páginas se dibujan ahí y la ficha se guarda ahí, sin
pasar por ninguna web de conversión.
Conviene no confundir eso con privacidad total, porque no lo es. La
IA con la que hablamos sí ve el contenido: para colocar
los campos necesita el texto de las páginas, y para comprobar el
resultado necesita mirar la imagen de la ficha. Ambas cosas viajan a los
servidores de quien preste el servicio (Anthropic, OpenAI, Google,
etc.), igual que si pegásemos el documento en el chat. Con datos
personales del alumnado, o con material que no deba salir del centro,
hay que tenerlo presente. La única forma de que no salga nada es usar un
modelo que corra en el propio ordenador, con LM Studio, aunque de
momento lo usa muy poca gente, sobre todo porque necesita de un
ordenador muy potente para poder funcionar de forma fluida.
Formas de hacer una ficha
Sobre un documento propio. Es el caso para el que
nació. Partimos de un PDF o de una imagen (un examen antiguo, una ficha
fotocopiada, un esquema) y los campos se colocan encima, cada uno en su
sitio, respetando el diseño original. El alumnado ve el documento de
siempre, pero relleno de huecos que podrá completar y que se corrigen
solos.
Desde cero, sobre hojas en blanco. Le decimos el tema, el nivel y cuántos ejercicios, y la ficha se escribe entera: enunciado, campo de respuesta, separación y salto de página cuando hace falta. Es lo mismo que ya permitía la opción Crear una ficha con IA de la aplicación, la de copiar un prompt y pegar la respuesta, pero sin copiar ni pegar nada y con una diferencia importante: el servidor valida el formato sobre la marcha, así que si algo viene mal, la IA se entera al momento y lo corrige, en lugar de entregarnos un archivo que no abre.
Las dos formas se mezclan: se puede partir de un PDF y añadir al
final tres preguntas nuevas sobre hoja en blanco.
La vista previa es lo que lo hace fiable
Una IA colocando cajas sobre una página, a ciegas, se puede equivocar. Si pone el campo dos centímetros por debajo de donde iba, tapa media palabra del enunciado, deja a la vista la solución impresa en el margen. Por eso el paso importante no es colocar, sino comprobar: el servidor monta la página con el mismo visor que verá el alumnado y le devuelve a la IA una captura de cómo ha quedado, con el contorno y el número de cada campo dibujados encima. Con esa imagen delante, la IA corrige lo que esté desplazado antes de guardar nada.
Lo que ve la IA después de colocar los campos: la ficha real
montada con el visor del alumnado, con el contorno y el número de cada
campo añadidos encima. Esta ficha se ha hecho para el artículo con el
propio servidor, a partir de un PDF de una hoja.
Qué se le puede pedir
Todo en lenguaje normal, en la conversación, sin tocar la
aplicación:
«Convierte en ficha interactiva de OpenWorksheets este
PDF»
«Crea una ficha interactiva de OpenWorksheets con 10 ejercicios
y nivel de 1.º de ESO sobre la célula»
«El ejercicio 5 prefiero que lo cambies por una pregunta de
respuesta múltiple, en lugar de verdadero o falso»
«Tapa las soluciones que están impresas al pie de la
página»
«Enséñame la página 3 antes de guardar»
Los tipos de campo que sabe colocar son casi todos: respuesta corta,
numérica, fórmula, respuesta larga, opción única y múltiple,
desplegable, verdadero/falso, huecos en el texto, huecos dibujados sobre
el documento, casillas, tabla editable, emparejar, ordenar, arrastrar a
zonas y grabación de voz.
Qué hace falta
1. Una IA instalada en el ordenador. Esto no se puede hacer desde la web de ChatGPT, de Claude ni de Gemini: el navegador no puede instalar ni ejecutar nada en nuestro equipo. Hacen falta las aplicaciones de escritorio o herramientas de terminal como Claude Code o Codex CLI. Y en las aplicaciones de escritorio de ChatGPT y de Claude no vale el chat de siempre: hay que pedírselo desde su pestaña de código (Codex en ChatGPT, Claude Code en Claude), que es la parte que puede trabajar con archivos y programas. También sirven LM Studio, Antigravity, Cursor y VS Code.
2. Node.js 18 o superior y un navegador basado en
Chromium (Chrome, Chromium o Edge). Node es lo que ejecuta el
servidor; el navegador, que trabaja sin abrirse ni verse, es lo que
dibuja las páginas del PDF y monta la vista previa. Es probable que ya
estén instalados; si falta alguno, la propia IA puede
encargarse de instalarlo o guiarnos en el proceso.
3. El servidor, instalado una sola vez. Hay que
destacar que no lo instalamos nosotros, lo instala la
IA. En el editor de OpenWorksheets, en Archivo → Crear o
convertir fichas con IA (MCP), hay un prompt para copiar y pegarle
en su chat. Ella descarga la carpeta, la registra en su propia
configuración y comprueba que responde. Claude Code, Codex CLI, la
aplicación de escritorio de ChatGPT, Antigravity, Cursor y VS Code lo
pueden hacer; LM Studio no puede tocar su configuración, así que al
final nos dará escrito el texto que hay que pegar y nos dirá en qué
archivo va. Aunque si tenemos alguna de las IA anteriores, le podemos
decir que nos lo instale en LM Studio.
El diálogo del editor con las instrucciones que se le pegan a la
IA para que instale el servidor.
Para actualizarlo, hacemos lo mismo, escribimos en el chat: «Actualiza el servidor MCP de OpenWorksheets a la última versión y dime en cuál se ha quedado».
Límites que conviene conocer antes de empezar
Un PDF escaneado da mucho más trabajo. Si la página
es una fotografía, sin capa de texto, no hay coordenadas que leer y la
IA tiene que colocar los campos mirando la imagen y afinando por
aproximación. Sale, pero cuesta varias vueltas. Con un PDF generado
desde un procesador de textos, en cambio, es más sencillo.
Las respuestas las propone la IA. En preguntas
cerradas suele acertar; en las abiertas, y en cualquier cosa que dependa
de un criterio nuestro, hay que revisar la ficha antes de repartirla. La
ficha se abre en el editor como cualquier otra y podremos corregir lo
que haga falta.
No sustituye al editor, lo alimenta. Lo que devuelve
la IA es un .owpkg normal, que se abre en OpenWorksheets,
se retoca, se le puede modificar la puntuación y las opciones de
corrección, y se comparte como siempre.
Para qué sirve esto realmente
El cuello de botella de las fichas interactivas nunca ha sido la
falta de material: el profesorado tiene carpetas llenas de PDF buenos.
El cuello de botella es el rato de trabajo mecánico que separa ese PDF
del material interactivo, y que hace que muchos no lleguen a dar el
paso. Eso es exactamente lo que esto quita de en medio.
Con la ventaja de que no cambia el resto: la ficha resultante es una ficha de OpenWorksheets como cualquier otra, sin cuentas, sin servidores, sin depender de ninguna plataforma.
La misma ficha sin las marcas de trabajo: así la abre el
alumnado. El documento original se conserva intacto; los campos se
corrigen solos.
Cualquier persona que trabaje con documentación acumula un fondo de
textos que consulta una y otra vez: normativa, actas, memorias, apuntes,
artículos. Preguntarle a una inteligencia artificial sobre ese material
choca siempre con el mismo muro: hay que subirlo a algún sitio, o
pegarlo en la conversación, o confiar en que el modelo lo recuerde de su
entrenamiento, cosa que no ocurre.
Este artículo explica qué es un RAG (Retrieval Augmented
Generation, en español «generación aumentada por recuperación»),
qué es el protocolo MCP (Model Context Protocol, en español
«protocolo de contexto del modelo») que hace posible esa conexión, cómo
funciona el conjunto y cómo montarlo sin escribir una línea de
código.
Si solo quieres las instrucciones, ve directamente a la guía rápida del final: reúne las tres
que hacen falta, listas para copiar y pegar. El resto del artículo
explica qué hace cada una y por qué, que es lo que permite juzgar si el
resultado es bueno.
El código está publicado: el sistema completo que se
describe aquí, con un fondo documental de ejemplo ya indexado, está en
github.com/jjdeharo/cuadernos-rag,
con licencia libre. Quien prefiera verlo antes de leer nada más, puede
empezar por ahí.
Pódcast del artículo realizado por Gemini Notebook
Qué es un RAG
Un buscador colocado delante de una inteligencia artificial.
Un modelo de lenguaje, que es el programa que hay detrás de ChatGPT,
Claude o Gemini, no puede leer mil páginas cada vez que recibe una
pregunta porque no caben en una consulta y, aunque lo hiciese,
resultaría lento y costoso. Lo que hace un RAG es localizar primero los
pocos fragmentos que hacen falta para responder a esa pregunta concreta,
y entregar solo eso. El modelo no aprende los documentos ni los
memoriza: los consulta, como haría cualquiera con un libro delante, e
indica de dónde ha salido cada afirmación.
La consecuencia práctica es doble. Por un lado, deja de haber límite
de volumen: da igual que el fondo documental sean quinientas páginas o
veinte mil, porque en cada consulta solo viajan unos pocos fragmentos.
Por otro, y más importante, cada respuesta puede citar su fuente. En
materia normativa o técnica, una respuesta sin fuente no tiene ningún
valor.
Qué es el MCP
El servidor declara sus herramientas una vez y cualquier
asistente compatible puede usarlas.
Un RAG, por sí solo, es una herramienta de línea de comandos: se le
hace una pregunta y devuelve fragmentos. Útil, pero incómodo.
MCP son las siglas de Model Context Protocol, un estándar
abierto propuesto por Anthropic a finales de 2024 y adoptado después por
los demás asistentes. Resuelve un problema muy concreto: cómo permitir
que una IA use herramientas externas sin que haya que programar una
integración distinta para cada combinación de herramienta y asistente.
Con MCP, quien construye la herramienta la describe una sola vez, y
cualquier asistente compatible sabe cómo usarla.
Aplicado a un RAG, el cambio es importante, ya que en lugar de
ejecutar búsquedas a mano y pegar los resultados en una conversación, el
asistente busca por su cuenta, tantas veces como necesite. Ante una
pregunta que cruza tres documentos distintos, hace tres búsquedas con
vocabulario distinto, compara lo que encuentra y responde citando cada
fuente. El fondo documental deja de ser un archivo aparte y pasa a estar
dentro de la conversación.
Un servidor MCP no es más que un programa que declara qué sabe hacer.
En el caso de un RAG documental, cuatro operaciones bastan: buscar
pasajes, listar los documentos disponibles, ampliar el contexto de un
pasaje concreto y recorrer un documento entero. El asistente decide
cuándo usar cada una.
Conviene añadir una instrucción que gobierne su uso, porque sin ella
el asistente tenderá a responder de memoria. Basta con una regla
explícita: no afirmar nada que no proceda de una búsqueda, buscar varias
veces reformulando con el vocabulario propio de cada fuente, citar
siempre el identificador del pasaje, y decir con claridad cuándo el
fondo documental no cubre la pregunta.
Cómo funciona por dentro
Arriba, la preparación: se hace una vez. Abajo, lo que ocurre en
cada pregunta: dura un segundo.
Son cuatro piezas, y solo la última tiene que ver con la inteligencia
artificial tal y como la entiende la mayoría.
Convertir a texto. PDF, páginas web, documentos de
Word, audio transcrito: todo tiene que acabar siendo texto plano. Un PDF
no guarda un texto, guarda dónde va cada letra en la página; al leerlo
hay que reconstruir el orden, y en tablas o en textos a dos columnas se
falla a menudo. Es la pieza menos vistosa y la que estropea el resultado
con más frecuencia.
Trocear. Consiste en partir cada documento en
fragmentos manejables y, aunque parezca un detalle de poca importancia,
es lo que más determina la calidad final. Un troceado rudimentario corta
cada mil palabras sin atender a dónde cae el corte, mientras que uno
cuidadoso respeta la estructura del texto: en una norma, por ejemplo, un
fragmento por artículo. La diferencia se aprecia en cuanto se formula
una consulta concreta, porque en el primer caso llega un trozo que
empieza a mitad de un artículo y se interrumpe antes de acabar el
siguiente, mientras que en el segundo llega el artículo completo, con su
título.
Convertir cada fragmento en números. De esto no se
encarga un asistente de los que conversan, sino un programa mucho más
pequeño, entrenado para una sola tarea: no redacta ni responde nada,
solo lee un texto y devuelve números. A cada fragmento le asigna una
lista de más de mil números que funciona como unas coordenadas: igual
que una latitud y una longitud sitúan un lugar en un mapa, esos números
sitúan el fragmento en un espacio donde la posición depende del
significado. Los textos que hablan de lo mismo quedan cerca unos de
otros, aunque estén escritos con palabras distintas; los que hablan de
cosas diferentes quedan lejos.
A partir de ahí, buscar deja de ser comparar palabras y pasa a ser
medir distancias. La pregunta se convierte también en un punto de ese
mapa, y el sistema devuelve los fragmentos que han quedado más cerca.
Por eso una consulta como «¿cuánta gente hace falta para que la reunión
sea válida?» encuentra un párrafo que habla del «quorum de
constitución», sin que compartan una sola palabra.
Buscar y citar. La búsqueda por significado es muy
eficaz y tiene un punto ciego: los nombres propios y las referencias
exactas. Ante una consulta por un artículo numerado o por unas siglas,
falla, porque esas expresiones no significan nada, solo nombran. Por eso
se hacen dos búsquedas a la vez (la de significado y la literal, por
palabras) y se combinan los resultados. Después, un segundo modelo igual
de mudo, llamado reranker, relee los mejores candidatos junto a
la pregunta y los reordena. De ahí salen los fragmentos que se entregan
al asistente, cada uno con su procedencia.
Todo esto ocurre en el propio ordenador, y conviene distinguir las
tres piezas que intervienen, porque en la jerga a las tres se las llama
«modelos» y no son lo mismo:
El conversor a números, o modelo de
embeddings, que traduce cada fragmento a su lista de coordenadas.
Ocupa unos dos gigabytes.
El reordenador, o reranker, que afina la
lista de candidatos que ha devuelto la búsqueda. Ocupa algo más de
uno.
El asistente, Claude, ChatGPT, Gemini, que es el
que redacta la respuesta final.
Los dos primeros viven en el disco, se descargan una vez y funcionan
sin conexión y sin coste. Mientras se consulta, además, se cargan en memoria: conviene tener unos cuatro gigabytes de RAM libres, aparte de los tres y medio que ocupan en el disco. Es un gasto que solo dura lo que dura la consulta, porque un sistema bien montado los suelta cuando pasan unos minutos sin preguntas. No conversan ni generan texto: entra un texto
y sale un resultado numérico. Solo el tercero es lo que la mayoría llama
«una IA», y no ve el fondo documental entero, sino los pocos fragmentos
que la búsqueda le pone delante. Ningún documento sale del equipo.
Cómo montarlo sin saber
programar
Hacen falta dos cosas: los documentos y un asistente que trabaje
dentro del ordenador, con permiso para escribir programas y ejecutarlos.
Hoy hay tres opciones equivalentes, y todas están disponibles tanto en
el terminal como en una aplicación de escritorio, para quien prefiera no
escribir órdenes:
Claude, de Anthropic: la orden claude
en el terminal, o la aplicación de escritorio, que reúne tres modos:
conversación, Claude Code y Cowork.
Codex, de OpenAI: la orden codex en el
terminal, o su aplicación de escritorio, disponible para macOS, Windows
y Linux.
Antigravity, de Google: un entorno de escritorio
propio y la orden agy en el terminal, que desde junio de
2026 sustituye al anterior Gemini CLI.
Cualquiera de ellas sirve, y se instalan en un minuto. Lo único que
importa es que el asistente pueda leer y escribir ficheros en las
carpetas del equipo y ejecutar órdenes en él.
Esas tres son las que montan el sistema, y para eso
conviene un modelo potente. Pero una vez montado, quien lo consulta a
diario puede ser otro, y ahí entra una cuarta posibilidad: un modelo
instalado en el propio ordenador. LM Studio es el
camino sencillo, una aplicación de escritorio para Windows, macOS y
Linux con una tienda de modelos integrada, que además reconoce el
servidor del RAG igual que lo haría cualquier asistente comercial.
llama.cpp es la alternativa para quien no quiera
aplicación gráfica, con algo más de soltura técnica a cambio.
Merece la pena por una razón concreta. Con un asistente comercial, los documentos no salen del equipo, pero los pocos fragmentos que la búsqueda selecciona viajan con cada pregunta. Para normativa pública da igual; para un expediente o unas actas con nombres propios, no. Con un modelo local no sale nada: ni los documentos, ni los fragmentos, ni las preguntas. El precio es real, eso sí: sin una tarjeta gráfica potente, la respuesta tarda decenas de segundos, y los modelos que caben en un ordenador corriente citan con menos rigor. Para material sensible compensa; para material público, el asistente de siempre responde mejor y antes.
Conviene comprobar un detalle en las modalidades que trabajan dentro
de una máquina virtual aislada, como el modo Cowork: si esa máquina es
remota, los documentos salen del ordenador, que es justo lo que se
pretendía evitar. Las versiones que operan directamente sobre las
carpetas locales no plantean ese problema.
A partir de ahí basta con encargar el trabajo. La instrucción que
sigue está escrita para el asistente, no para quien la copia: no hace
falta entender cada línea, porque cada una le pide una decisión técnica
concreta y le impide tomar el atajo de cobrar por el servicio o de subir
el material a algún sitio.
Quiero poder preguntarte sobre mis documentos sin que
salgan de mi ordenador. Móntame un RAG local.
Pregúntame dónde están los documentos y decide tú
dónde conviene instalar todo lo demás.
- Todo en local y gratis: embeddings con fastembed
(multilingual-e5-large) y un reranker multilingüe.
- Índice en SQLite con sqlite-vec y FTS5, búsqueda
híbrida (significado + palabras exactas) fusionada
con RRF.
- Trocea respetando la estructura del documento
(artículos, apartados) y limpia las palabras que
los PDF parten al maquetar.
- Cada respuesta debe citar documento y artículo.
- Móntalo como servidor MCP, para poder consultarlo
en lenguaje natural.
- Los dos modelos ocupan más de tres gigabytes en
memoria y habrá un proceso del servidor por cada
programa conectado: cárgalos solo en la primera
búsqueda y suéltalos tras unos minutos sin usarse.
- Que el indexado sea incremental: añadir un
documento no puede obligar a rehacerlo todo.
Antes de ponerte, mira qué documentos hay y explícame
en lenguaje llano cómo piensas partirlos y por qué.
Si algo de lo que te pido no encaja con este material,
dímelo y propón otra cosa.
Esa última petición es la más importante de todas, y conviene no
saltársela: obliga al asistente a enseñar cómo piensa partir los
documentos antes de ponerse a trabajar, que es donde se decide casi
todo. Basta con leer su propuesta y comprobar que respeta la estructura
del material (los artículos de una norma, los puntos del orden del día
de un acta, los capítulos de un informe) en lugar de cortar cada tantas
palabras.
Las tres condiciones finales también merecen explicación. La de las
citas separa una herramienta de consulta de un generador de respuestas
plausibles. La de la memoria evita el descuido más caro de todos: un
servidor que carga los dos modelos nada más arrancar y se queda con tres
gigabytes ocupados aunque nadie pregunte nada, multiplicado por cada
programa que lo tenga conectado. Y la del indexado incremental evita un error frecuente: una
primera versión que rehace el trabajo entero cada vez que se añade o
corrige un documento, con tres cuartos de hora de cálculo en cada
ocasión.
La alternativa a construirlo desde cero es partir de algo que ya
funciona. El código de un sistema así, con todo lo descrito, está
publicado en github.com/jjdeharo/cuadernos-rag
bajo licencia libre. Incluye, a modo de ejemplo, un fondo documental de
quince normas y guías sobre uso ético y legal de la IA en educación (el
RGPD, la LOPDGDD, el reglamento europeo de inteligencia artificial,
guías de la Agencia Española de Protección de Datos, marcos de la
UNESCO), ya indexado y listo para consultar. Ese ejemplo concreto
importa poco: lo aprovechable es la estructura, que sirve igual para
actas municipales, bibliografía académica o documentación técnica de una
empresa.
Añadir nuevos cuadernos
El motor y los modelos se instalan una sola vez; cada tema añade
solo sus documentos y su índice.
Esta es la parte que suele quedar sin explicar, y es la que convierte
un experimento en una herramienta de uso diario.
Quien viene de Gemini Notebook está acostumbrado a tener un cuaderno
por tema: uno de normativa, otro de actas, otro con la bibliografía de
un curso. Aquí funciona igual, y con una ventaja: lo que ocupa espacio,
que son los programas y los dos modelos, más de tres gigabytes, se
instala una sola vez y lo comparten todos los cuadernos. Cada tema nuevo
añade únicamente sus documentos y su índice, unos pocos megabytes. No
hay límite de cuadernos ni cuota que agotar.
Crear uno nuevo no exige tocar nada por dentro: basta con pedírselo
al asistente en la misma conversación de siempre, indicando dónde están
los documentos y qué nombre quieres darle. Él prepara la carpeta,
convierte los PDF a texto, repara las palabras que la maquetación parte
con guiones, descarta lo que no sea texto aprovechable y construye el
índice. Un cuaderno de unos cuantos PDF está listo en unos minutos.
La instrucción, otra vez escrita para el asistente y no para quien la
copia:
Ya tengo montado el RAG. Quiero un cuaderno nuevo,
aparte del que ya existe.
Los documentos están en <carpeta>. Llámalo <nombre>.
- Aprovecha lo que ya está instalado: los programas,
el entorno y los dos modelos. No descargues ni
instales nada otra vez.
- El cuaderno nuevo va aparte: sus documentos y su
índice, sin tocar los del anterior.
- Trocea y limpia igual que en el primero.
- Déjalo accesible desde el mismo servidor MCP, para
poder preguntar por su nombre.
Antes de empezar, dime qué documentos has encontrado
y cómo piensas partirlos.
Lo importante es la primera condición. Sin ella, el asistente puede
ponerse a instalarlo todo de nuevo, con otra copia de los modelos, y el
ordenador acaba con tres gigabytes repetidos por cada cuaderno.
Añadir documentos a un cuaderno que ya existe es todavía más simple:
se dejan los ficheros nuevos y se pide que lo actualice. Aquí importa
una de las condiciones que se le exigieron al montarlo, la del indexado
incremental: el sistema guarda una huella de cada documento y solo
procesa los que han cambiado, así que incorporar un PDF cuesta el tiempo
de ese PDF, alrededor de un minuto por cada cien mil caracteres, y no el
del fondo entero. Sin esa condición, añadir una circular de dos folios
obligaría a rehacerlo todo.
Al preguntar, con un solo cuaderno no hace falta decir cuál; con
varios, se nombra el que interesa. El asistente los ve todos y, si la
pregunta lo pide, puede buscar en el que corresponda.
Cuándo montar un RAG
Con poco material no hace falta montar nada.
Los modelos actuales procesan cientos de miles de palabras de una sola vez. Por debajo de unas trescientas páginas, basta con dejar los documentos en una carpeta y pedirle al asistente que los lea directamente. Buscando por su cuenta, acierta más que cualquier RAG, porque puede leer, releer y afinar la búsqueda tantas veces como haga falta. Entre trescientas y mil quinientas páginas hay una zona intermedia: el material cabe, pero se relee entero en cada pregunta, y eso resulta lento y caro en una consulta diaria, por lo que se aconseja montar el RAG. Por encima de mil quinientas páginas ya no cabe, y el RAG deja de ser opcional.
El criterio es el volumen de texto, no el número de archivos.
Cincuenta circulares de dos folios no llegan a cien páginas; tres
memorias anuales pueden superar las mil.
Guía rápida
Las tres instrucciones, sin explicaciones. Se pegan tal cual en
Claude, Codex o Antigravity, sustituyendo lo que va entre ángulos.
1. Montar el primer cuaderno. Una sola vez.
Quiero poder preguntarte sobre mis documentos sin que
salgan de mi ordenador. Móntame un RAG local.
Pregúntame dónde están los documentos y decide tú
dónde conviene instalar todo lo demás.
- Todo en local y gratis: embeddings con fastembed
(multilingual-e5-large) y un reranker multilingüe.
- Índice en SQLite con sqlite-vec y FTS5, búsqueda
híbrida (significado + palabras exactas) fusionada
con RRF.
- Trocea respetando la estructura del documento
(artículos, apartados) y limpia las palabras que
los PDF parten al maquetar.
- Cada respuesta debe citar documento y artículo.
- Móntalo como servidor MCP, para poder consultarlo
en lenguaje natural.
- Los dos modelos ocupan más de tres gigabytes en
memoria y habrá un proceso del servidor por cada
programa conectado: cárgalos solo en la primera
búsqueda y suéltalos tras unos minutos sin usarse.
- Que el indexado sea incremental: añadir un
documento no puede obligar a rehacerlo todo.
Antes de ponerte, mira qué documentos hay y explícame
en lenguaje llano cómo piensas partirlos y por qué.
Si algo de lo que te pido no encaja con este material,
dímelo y propón otra cosa.
2. Crear otro cuaderno, reutilizando lo ya
instalado.
Ya tengo montado el RAG. Quiero un cuaderno nuevo,
aparte del que ya existe.
Los documentos están en <carpeta>. Llámalo <nombre>.
- Aprovecha lo que ya está instalado: los programas,
el entorno y los dos modelos. No descargues ni
instales nada otra vez.
- El cuaderno nuevo va aparte: sus documentos y su
índice, sin tocar los del anterior.
- Trocea y limpia igual que en el primero.
- Déjalo accesible desde el mismo servidor MCP, para
poder preguntar por su nombre.
Antes de empezar, dime qué documentos has encontrado
y cómo piensas partirlos.
3. Añadir documentos a un cuaderno que ya existe. Lo
más frecuente con el tiempo.
Añade estos documentos al cuaderno <nombre>:
<carpeta o lista de ficheros>
- Trátalos igual que los que ya están: mismo troceado
y misma limpieza.
- Aprovecha el indexado incremental: procesa solo lo
nuevo, sin rehacer el índice entero.
- Al terminar, dime qué has añadido y qué documentos
contiene ahora el cuaderno.
En los tres casos conviene leer lo que responde antes de dejarle
continuar. Si su plan no respeta la estructura de los documentos (los
artículos de una norma, los puntos del orden del día de un acta), es el
momento de decírselo, porque de ese detalle depende la calidad de todas
las respuestas posteriores.
Los boletines de los grupos de Telegram ChatGPT-IA-edu y Vibe Coding
Educativo se publican desde 2023 y, por primera vez, su creación se ha
automatizado por completo. Una simple instrucción pone en marcha un
agente de IA que se encarga absolutamente de todo, desde la creación y
publicación hasta la difusión en redes sociales. Le he pedido a Claude
Code Opus 5 que escriba el artículo que hay a continuación. Utiliza sus
propias palabras y forma de ver todo el asunto, incluyendo sus menciones
a mi persona. Únicamente le indiqué el público docente al que va
encaminado el artículo y le he hecho algunas correcciones, tanto de
contenido como de estilo (cosa que él explica perfectamente más
abajo).
Juan José de Haro
Hacer el boletín semanal de dos comunidades educativas era una tarea
de tarde entera. Hoy el boletín está hecho y publicado en media hora —y
difundido en redes en un cuarto de hora más—, y lo ejecuta entero un
agente de IA.
La palabra importa, y merece una aclaración temprana. Un
asistente responde: le preguntas algo y te contesta. Un
agente actúa: recibe un encargo y lo lleva a cabo por
su cuenta, ejecutando programas, entrando en servicios, comprobando
resultados y corrigiendo el rumbo cuando algo falla. La diferencia no es
de inteligencia, sino de permisos y de autonomía: al agente no se le
pregunta, se le encarga.
Conviene decirlo desde el principio, porque es lo que suele
malinterpretarse: todos los pasos que vienen a continuación los
ejecuta el agente, incluidas las decisiones de redacción y las
comprobaciones intermedias. Juan José de Haro, que coordina las dos
comunidades, no ejecuta ninguno de ellos.
Lo que sí hace es lo que ninguna máquina puede hacer por él:
encarga, revisa, valida y, cuando algo no está a la altura, lo
manda repetir. La última palabra es suya, y la ejerce. Este
mismo artículo pasó por varias correcciones suyas antes de llegar aquí:
un dato mal atribuido, un cierre que se leía como una enmienda al propio
trabajo, unos diagramas con la letra demasiado pequeña para la columna
del blog. Nada de eso lo detectó el agente que los produjo.
Esa es la división real del trabajo: la ejecución es automática de
principio a fin; el criterio sobre si el resultado vale, no.
De qué estamos hablando
Cada semana, dos grupos de Telegram —ChatGPT-IA-edu y Vibe Coding Educativo—
generan cientos de mensajes: enlaces, dudas, hallazgos, debates,
aplicaciones que alguien ha creado y comparte. Es material valioso, pero
se pierde: quien no entra un par de días ya no lo recupera.
El boletín semanal existe para rescatarlo. Y no es solo un texto. De
cada semana y de cada grupo salen:
un boletín escrito, publicado en una web
consultable;
una infografía que resume visualmente la
semana;
un pódcast de quince o veinte minutos, en formato
conversación;
un vídeo de unos seis minutos, publicado en
YouTube;
y la difusión de todo ello en Telegram, X y
LinkedIn.
Todo está abierto y se puede consultar sin cuenta ni permiso:
Seis archivos multimedia, dos boletines, dos vídeos publicados y una
veintena de mensajes en redes. Cada semana. Hecho a mano, eso son
horas.
Todo el recorrido, de un vistazo. Lo importante es la
bifurcación: después de exportar, hay dos caminos que no se
estorban.
La idea de
fondo: una skill, que es una receta escrita
Lo primero que hay que entender es que la automatización no empezó
por programar, sino por escribir. Todo el proceso está
documentado en un único archivo que actúa como receta: qué se hace, en
qué orden, qué puede fallar y qué decisiones no se pueden tomar a la
ligera.
Ese archivo tiene nombre propio en el mundo de los agentes de IA: es
una skill. Conviene explicarlo porque el término se va
a oír cada vez más.
Una skill («habilidad», aunque casi nadie la
traduce) es un documento escrito en lenguaje corriente que le enseña a
un agente de IA a hacer una tarea concreta de la forma en que tú quieres
que se haga. No es un programa: es un texto, con sus instrucciones, sus
advertencias y sus ejemplos. El agente lo lee cuando toca hacer esa
tarea, y actúa en consecuencia.
La comparación que mejor funciona es la del profesorado sustituto. Si
dejas escrito «segunda hora, 3.º B, seguid por la página 84; a Marcos
hay que sentarlo delante; el proyector solo va con el cable HDMI de la
derecha», quien llegue podrá dar la clase decentemente aunque no conozca
al grupo. Una skill es eso mismo: el conocimiento acumulado de hacer
algo muchas veces, puesto por escrito para que otro pueda ejecutarlo sin
haber estado allí. La del boletín pasa de las setecientas líneas, y buena
parte son cosas que solo se aprenden fallando: que hay que acotar el
resumen a la semana o saldrá el histórico entero, o que la transcripción
confunde los nombres propios.
Como está escrita en lenguaje corriente y no en código, no
está atada a un agente concreto: puede seguirla cualquiera de
los que hoy existen —Claude Code, Codex, Antigravity CLI (Agy CLI)—, y
de hecho el boletín no siempre lo hace el mismo. De ahí la consecuencia
práctica que conviene tener presente al montar algo así: lo valioso, lo
que cuesta construir y no debe perderse, es el documento. El agente es
intercambiable.
De esa skill cuelgan una serie de pequeños programas —los llamamos
scripts— que son simplemente listas de órdenes que el ordenador
ejecuta solo. Nada exótico: es el equivalente informático de una macro
de hoja de cálculo, pero capaz de hablar con Telegram, con Google o con
YouTube. La skill es el guion; los scripts son las manos.
Cómo transcurre una semana
1. Recoger la conversación y poner a
trabajar a Gemini Notebook
Un programa se conecta a los dos grupos de Telegram y descarga todos
los mensajes de la semana pasada, de lunes a domingo. Con ellos monta
dos cosas: un archivo de datos que servirá para redactar, y un
PDF con la conversación ordenada y legible. Tarda dos o
tres segundos por grupo.
Con ese PDF entra en juego la pieza que más sorprende a quien no la
conoce.
Gemini Notebook —el nombre actual de lo que hasta hace
poco se llamaba NotebookLM— es la herramienta de Google que lee
documentos y produce resúmenes, esquemas, audios y vídeos a partir de
ellos. Lo habitual es usarla desde su página web (notebooklm.google.com),
subiendo archivos a mano.
En este proceso se le habla directamente, sin abrir el navegador: se
le sube el PDF de la semana y se le encargan de golpe las seis piezas
—infografía, pódcast y vídeo para cada grupo— con instrucciones que
están guardadas y son siempre las mismas. Eso garantiza que el boletín
de esta semana se parezca al de la anterior y al de dentro de tres
meses.
Un detalle que costó aprender: cada cuaderno de Gemini Notebook
acumula una fuente por semana desde 2025. Si no se le
dice explícitamente «resume esta semana», resume el histórico
entero y produce un material que no sirve para nada. Es el tipo de error
que no da ningún mensaje de fallo: simplemente sale mal.
Estas generaciones tardan entre veinticinco y treinta y cinco
minutos. Y aquí está el truco que ahorra media hora: se lanzan
antes de escribir nada. Mientras Google genera, el agente
redacta.
La barra amarilla es espera pura. El ahorro no está en hacer las
cosas más rápido, sino en colocarlas dentro de un hueco que ya
existía.
2. Redactar el
boletín (aquí el agente decide)
Con los mensajes de la semana delante, el agente redacta cada boletín
siguiendo una guía de estilo propia para cada comunidad —tienen tonos
distintos— y tomando como referencia boletines reales ya publicados. No
es un resumen mecánico: selecciona qué merece contarse, agrupa temas,
redacta un cuerpo de al menos seiscientas palabras, prepara un apartado
de preguntas frecuentes y extrae las palabras clave.
Este es uno de los dos puntos del proceso donde hay juicio de verdad,
no ejecución.
3. Publicar la fila en
la hoja de cálculo
Los boletines viven en una hoja de cálculo de Google, que es lo que
alimenta las webs públicas donde se consultan: chatgpt-ia-edu.github.io/boletin
y vibe-coding-educativo.github.io/boletin.
Cada boletín tiene además una dirección propia, con el año y la semana,
para poder enlazar uno concreto:
Un programa escribe cada boletín en su hoja, y lo hace con tres
precauciones que conviene destacar porque son las que evitan
desastres:
comprueba justo antes de escribir si esa semana ya
está publicada, para no duplicarla;
escribe en la primera fila libre, sin tocar nada más;
y después vuelve a leer lo que ha escrito y lo
compara campo a campo con lo que debía escribir. Si algo no cuadra, se
detiene y avisa.
Esa última comprobación es la diferencia entre automatizar y confiar.
Un proceso automático que no verifica su propio resultado es un proceso
que falla en silencio.
4. Recoger las seis piezas
Cuando Gemini Notebook termina, otro programa descarga los seis
archivos, les pone nombres consistentes y convierte los
audios. Aquí hay un detalle práctico: Gemini Notebook entrega
el pódcast en un formato innecesariamente pesado para voz
hablada, así que se reconvierte a uno más ligero y queda en la cuarta
parte de su tamaño, sin pérdida audible. Importa para quien lo escuche desde el
móvil con datos.
5. Los
vídeos a YouTube (y el segundo punto donde decide)
Antes de subir un vídeo hay que describirlo. Y para describirlo hay
que saber qué dice. El proceso lo transcribe automáticamente en
el propio ordenador, sin enviar nada a ningún servicio
externo.
Ahora bien: la transcripción automática se equivoca con los nombres
propios y con el vocabulario técnico. En las pruebas apareció «Resulen»
por resumen, «bargas de agua» por marcas de agua y «a
Yafgos» por hallazgos. Por eso la skill obliga a un paso más:
el agente relee la transcripción entera, corrige lo que está mal
escrito y comprueba que el texto tiene sentido antes de resumir
nada. Solo después redacta la descripción del vídeo.
Es una revisión de verdad, no un trámite: si la transcripción dice
algo incoherente, corregirlo exige entender de qué se estaba hablando
esa semana.
Y una advertencia que parece obvia y no lo es: la descripción debe
resumir el vídeo, no el PDF de conversaciones. El vídeo
dura seis minutos y cubre una parte de los temas de la semana. Resumir
el PDF produce descripciones que prometen contenidos que el vídeo no
tiene.
Hecho eso, la subida es automática: publica, añade el vídeo a su
lista de reproducción y escribe la dirección resultante en la hoja de
cálculo. Cada comunidad tiene la suya, y ahí están todas las semanas
seguidas:
Los audios se alojan en Internet Archive, la
biblioteca digital sin ánimo de lucro. Es una decisión deliberada: un
enlace estable, gratuito y que no depende de que una empresa decida
cerrar el servicio. Hay una colección por comunidad y por año, con todos
los pódcast juntos:
También aquí hubo que aprender algo: Internet Archive acepta el
archivo al instante pero tarda uno o dos minutos en indexarlo. Durante
ese rato el enlace no funciona, y parece un error sin serlo. El programa
espera a que el archivo esté realmente disponible antes de anotar la
dirección. Si no lo estuviera, no la escribe: prefiere dejar la casilla
vacía a dejar un enlace roto.
Cada pieza se aloja donde mejor se conserva y donde mejor se
encuentra. La fila de la hoja de cálculo es la que mantiene unido todo
lo demás.
7. La difusión en redes
La última fase publica en Telegram, X y LinkedIn. Es la fase que se
trata con más respeto, porque es la única que no se puede
ensayar: cualquier ejecución es visible al instante para toda
la comunidad.
Por eso existe un comando previo que lo revisa todo —los archivos,
sus formatos, sus duraciones, los textos, los enlaces— y muestra una
vista previa sin publicar nada. La IA lo ejecuta y lee
el resultado siempre, sin excepción, antes de tocar nada público.
Telegram y X se publican con sus respectivas conexiones automáticas.
LinkedIn es otra historia, y es la parte más curiosa de todo el
proceso.
LinkedIn no ofrece una puerta de entrada para programas como esta, y
tampoco vale el atajo habitual —copiar las credenciales de la sesión a
un navegador automatizado—, porque puede invalidar la sesión. Así que la
solución fue otra: el agente usa el navegador que ya está
abierto en el ordenador, exactamente como lo usaría una
persona. Trae al frente la ventana de Firefox, teclea la
dirección, pulsa el botón Vídeo, elige el archivo, pega el
texto y publica. Mueve el ratón y el teclado igual que tú.
¿Y cómo sabe si el clic ha funcionado? Haciendo una captura
de pantalla después de cada paso y mirándola. Esa es toda la
verificación que hay: mira si el diálogo se abrió, si el texto es el
correcto, si el aviso de Procesando ya desapareció. Si algo no
está donde debía, se detiene en lugar de seguir haciendo clics a
ciegas.
Es un método poco elegante y frágil —un rediseño de LinkedIn lo
rompe—, pero resuelve un problema real: cuando un servicio no ofrece
forma de automatizarlo, queda la de usarlo como lo usa una persona.
Lo que tarda cada cosa
Estos tiempos no son estimaciones: cada fase deja una marca
al empezar y otra al terminar, y un comando las suma al acabar.
Son de una semana normal, con los dos grupos.
Paso
Tiempo
Exportar la semana de un grupo de Telegram
2-3 segundos
Que Gemini Notebook indexe el PDF
30 s a 2 min
Generar una infografía
unos 3 min
Generar un pódcast
13-16 min
Generar un vídeo
18-24 min
Redactar un boletín
ocurre dentro de la espera anterior
Publicar una fila en la hoja
2-3 segundos
Convertir un audio a MP3 ligero
3-5 segundos
Transcribir un vídeo
1-2 min
Subir un vídeo a YouTube
5-10 segundos
Subir un audio a Internet Archive
10 s, más 1-2 min de indexado
Publicar en Telegram
1-2 min
Publicar en X
3-5 min
Publicar en LinkedIn
5-10 min
Hasta tenerlo todo publicado
25-35 min
Con la difusión en redes incluida
40-50 min
Dos cosas llaman la atención en esa lista. La primera, que lo
que tarda no es el trabajo, sino la espera: generar el vídeo y
el pódcast se lleva la mitad del tiempo, y ahí no hay nada que hacer
salvo aprovecharlo. La segunda, que publicar en LinkedIn a mano
cuesta más que todo el proceso de creación, y es justo la parte
que ningún programa puede acortar.
De la redacción no hay cronómetro: es lo único que no ejecuta un
script, y sucede mientras Google genera, así que no añade tiempo al
total.
Qué he aprendido de todo
esto
La automatización no elimina el criterio, lo
reparte. Dentro del proceso hay dos momentos que exigen pensar
—decidir qué merece contarse de la semana y comprobar que lo transcrito
tiene sentido—, y esos los ejerce el agente. Pero por encima queda un
tercero que no se delega: decidir si el resultado vale.
Ese sigue siendo de quien firma la publicación, y es el que corrige las
cosas que el agente no puede ver desde dentro. Lo que ha desaparecido es
el trabajo mecánico que rodeaba a todos ellos: descargar, renombrar,
convertir, pegar, subir, verificar.
Lo que no se verifica, falla en silencio. Cada paso
comprueba su propio resultado, porque un proceso que publica sin mirar
acaba publicando basura durante semanas sin que nadie se entere.
Ha llegado a ocurrir: una de las seis generaciones se encargó
correctamente, pero su identificador no llegó a quedar anotado en la
lista de encargos pendientes. La descarga
terminó con cinco piezas de seis, informó de que todo había ido bien y
no dio ningún error. Lo delató contar los archivos. El proceso ya
comprueba que eso no vuelva a pasar, pero la lección es la de siempre:
un programa solo detecta los fallos que alguien previó.
Pero hay errores que ninguna comprobación automática
detecta. Un resumen de la semana equivocada pasa todos los
controles técnicos con sobresaliente: el archivo existe, pesa lo que
debe y el enlace funciona. Todo perfecto salvo lo único que importaba,
que es el contenido. Por eso la revisión final es de otra naturaleza
—abrir la infografía y leerla, escuchar un fragmento del audio— y por
eso la hace también una persona: quien produce algo tiende a darlo por
bueno, y la mirada que puede decir «esto no vale, hazlo otra vez» tiene
que venir de fuera.
Para quien esté
pensando en algo parecido
No hace falta empezar por aquí. Este sistema funciona porque se
construyó en el orden correcto: primero haciendo el boletín a mano,
hasta entender bien cada paso; después escribiendo esa experiencia como
skill; y solo entonces automatizando lo que ya se hacía siempre
igual.
Y la parte más aprovechable no es la más técnica. Escribir la skill
—dejar por escrito, con precisión, cómo se hace algo que ya sabes hacer—
es una tarea docente de toda la vida, y sirve para cualquier rutina que
se repita cada curso: preparar las actas, montar los grupos, redactar
los informes trimestrales. Ese documento vale por sí solo, aunque nunca
llegue a automatizarse nada.
El resultado, al final, no es un ahorro de tiempo. Es que cada semana
de conversación de dos comunidades docentes queda recogida, resumida,
escuchable y consultable, en vez de perderse en el desplazamiento
infinito de un grupo de Telegram. Eso antes no se hacía porque no había
tiempo material para hacerlo. Ahora se hace todas las semanas.
Artículo redactado por Claude (Anthropic) bajo
la guía de Juan José de Haro. El sistema que aquí se
describe —los scripts, la skill que lo documenta y las soluciones a los
problemas que fueron surgiendo— se construyó entre los dos: él
decidiendo qué debía hacer el proceso, probándolo, señalando lo que
fallaba y exigiendo que se rehiciera cuando hacía falta; el agente
escribiendo el código, la documentación y este texto. Otros agentes
ejecutan el proceso algunas semanas, y alguno ha revisado puntualmente
este trabajo.
Este artículo describe los fundamentos básicos de la metodología utilizada para crear recursos educativos que se adaptan a las respuestas del alumno. Puedes ver ejemplos aquí:
Laboratorio de combinatoria (sección: Práctica – Resuelve problemas). Ejercicios de combinatoria para aprender y comprobar la multidimensionalidad del modelo, donde no solo se evalúan conocimientos, sino también habilidades transversales de forma adaptativa.
¿Cómo comparas los decimales? Un recurso adaptativo que no solo comprueba si el alumno acierta o falla al comparar decimales, sino que intenta averiguar qué tipos de errores conceptuales hay detrás de sus respuestas. Es un ejemplo de evaluación de ítems no ordenados (cada error conceptual es independiente de los otros).
¿Frío o caliente? Parte de dos errores comunes en la concepción del calor y determina si se tiene uno de los dos o ninguno.
Si lo que quieres es implantarlo mediante IA en algún recurso nuevo o que ya tengas hecho, en la web Recursos educativos adaptativos tienes un archivo para adjuntar a la IA de forma que sepa cómo debe actuar para crear una página web con el recurso adaptativo y, aunque no es necesario, también hay una guía para el docente.
Planteamiento general de la metodología
Una actividad fija, sea una prueba, un ejercicio o cualquier otro recurso, plantea las mismas preguntas, en el mismo orden, a todo el alumnado, sin tener en cuenta su nivel de partida: mide, pero no se ajusta a quien la responde. La metodología que se describe en este artículo resuelve esa limitación haciendo que cada pregunta dependa de las respuestas anteriores dadas por el alumno.
El teorema de Bayes, la teoría de respuesta al ítem y la entropía de Shannon, que se utilizan, ya existen por separado desde hace décadas en la literatura de medición educativa; lo que aporta esta metodología es la forma de combinarlos y, sobre todo, que todo el procedimiento está escrito como un protocolo reproducible que una inteligencia artificial puede ejecutar para generar un recurso nuevo en cualquier materia, sin equipo de psicometría ni datos de miles de alumnos.
Representación probabilística del estado del alumno
El sistema no calcula una nota al final del proceso, sino que mantiene una distribución de probabilidad sobre varias hipótesis de nivel del alumno, por ejemplo, tres hipótesis sobre su nivel: H1 (básico), H2 (medio) y H3 (avanzado), cada una con un valor asociado de habilidad θ (theta).
Al empezar, el sistema no sabe nada del alumno, así que reparte la probabilidad de pertenencia a un nivel en partes iguales: P(H1) = P(H2) = P(H3) = 0,33. A medida que el alumno responde preguntas, esa probabilidad se va desplazando hacia la hipótesis que mejor explica lo que está ocurriendo. Nunca hay un único número que resuma al alumno, sino una distribución completa de lo probable y lo improbable en ese momento, lo que permite representar también la duda: un alumno con un patrón de respuestas contradictorio queda reflejado como una probabilidad repartida entre varias hipótesis, en vez de forzarlo a encajar en una etiqueta.
Actualización bayesiana de las hipótesis de nivel
El mecanismo que desplaza esa probabilidad entre diferentes niveles al responder se llama actualización bayesiana, y se apoya directamente en el teorema de Bayes:
\(P(H_i \mid r)\) es la probabilidad a posteriori: la probabilidad de la hipótesis \(H_i\) (por ejemplo, «nivel avanzado») una vez conocida la respuesta r del alumno. Es el resultado que interesa, la creencia ya actualizada tras una respuesta.
\(P(H_i)\) es la probabilidad a priori: la probabilidad que se le daba a esa misma hipótesis antes de conocer la respuesta.
\(P(r \mid H_i)\) es la verosimilitud: la probabilidad de que se produjera esa respuesta concreta si la hipótesis \(H_i\) (el nivel de habilidad que se está evaluando, por ejemplo, «nivel avanzado») fuera cierta. La calcula el modelo de respuesta al ítem que se describe en la sección siguiente.
\(\sum_j P(r \mid H_j) \cdot P(H_j)\) es el término de normalización: la suma de esa misma cantidad para todas las hipótesis, que garantiza que las probabilidades finales sumen 1 y no tiene otra función que esa.
La fórmula dice que la nueva creencia sobre cada hipótesis (la probabilidad a posteriori, \(P(H_i \mid r)\)) es proporcional a dos cosas: lo bien que esa hipótesis explica la respuesta que se acaba de observar (la verosimilitud, \(P(r \mid H_i)\)) y la creencia que ya se tenía sobre ella (la probabilidad a priori, \(P(H_i)\)). Las hipótesis que hacían más probable la respuesta observada ganan peso; las que la hacían improbable lo pierden.
Ejemplo numérico del proceso de actualización
El siguiente ejemplo aplica el mecanismo a un caso concreto. Se parte de tres hipótesis con su habilidad ya fijada: H1 (θ₁ = −2, nivel básico), H2 (θ₂ = 0, nivel medio) y H3 (θ₃ = +2, nivel avanzado). El estado del alumno se representa como un vector de probabilidad P = (P(H1), P(H2), P(H3)), con un valor para cada hipótesis (el nivel al que pertenece) en ese orden y que siempre suma 1; al principio, sin ninguna respuesta todavía, ese vector es una probabilidad a priori uniforme, P = (0,33; 0,33; 0,33). Cada pregunta tiene además una dificultad b, en la misma escala que θ, que se explica con detalle en la sección siguiente: por ahora basta con saber que b = −1 corresponde a una pregunta fácil y b = 0 a una pregunta de dificultad media.
El alumno falla una pregunta fácil (dificultad b = −1). La verosimilitud de fallar es alta bajo H1 y baja bajo H3, así que el vector de probabilidad se desplaza a P = (0,81; 0,18; 0,01): la probabilidad de H1 sube a 0,81, y las de H2 y H3 bajan a 0,18 y 0,01.
El alumno acierta la siguiente pregunta, de dificultad media (b = 0). El vector pasa a P = (0,65; 0,32; 0,03): la probabilidad de H1 baja ligeramente y la de H2 sube, porque acertar una pregunta de dificultad media es más compatible con un nivel medio que con uno básico.
La figura 1 muestra esa evolución junto con la entropía de cada paso (concepto que se explica en la sección siguiente). Entre el segundo y el tercer paso, la incertidumbre aumenta en lugar de disminuir, porque el acierto en una pregunta media reparte de nuevo la probabilidad entre H1 y H2. Se trata de un comportamiento correcto del modelo, no de un error: cada respuesta aporta la evidencia que aporta y no siempre reduce la incertidumbre. Este ejemplo se limita a dos preguntas y, como se explica en el criterio de finalización más adelante, una implementación real no daría por buena la convergencia solo por cruzar los umbrales de entropía y confianza, sino que exige además un número mínimo de preguntas respondidas.
Figura 1. Actualización bayesiana de las tres hipótesis de nivel a lo largo de dos preguntas, con la entropía de cada paso.
Este cálculo se repite tras cada respuesta, de manera que la creencia sobre el alumno nunca queda congelada. Si un alumno empieza fallando, pero después encadena varios aciertos, el sistema revisa su estimación y se aleja del diagnóstico inicial: no existe un bloqueo irreversible en una categoría equivocada, algo que sí puede ocurrir en sistemas más simples que solo suben la dificultad tras un acierto y la bajan tras un fallo.
El modelo de respuesta al ítem y la dificultad de las preguntas
La verosimilitud \(P(r \mid H_i)\) que exige el teorema de Bayes no puede inventarse pregunta a pregunta y hace falta un modelo que relacione el nivel del alumno con la probabilidad de acertar una pregunta de una dificultad determinada. Esta metodología usa para ello la teoría de respuesta al ítem (TRI o, en inglés, IRT), en concreto el modelo logístico de tres parámetros (3PL), ya empleado en evaluación educativa desde los trabajos de Birnbaum en los años sesenta:
θ es el nivel del alumno en la hipótesis que se está evaluando.
\(b_q\) es la dificultad de la pregunta q: el punto en el que la probabilidad de acierto (descontado el azar) llega al 50 %.
\(a\) es la discriminación: la pendiente de la curva. Cuanto mayor es \(a\), más bruscamente distingue la pregunta entre un alumno justo por debajo y justo por encima de su dificultad.
\(c_q\) es el suelo de azar: la probabilidad mínima de acertar sin saber nada, que depende del número de opciones (0,25 en una pregunta de cuatro opciones, 0,5 en un verdadero/falso, 0 en una respuesta numérica abierta).
La figura 2 dibuja esa curva para tres preguntas de dificultad fácil, media y difícil, con a = 1,5 y c = 0,25, valores ilustrativos (el protocolo no fija a directamente: parte de una discriminación efectiva \(a_{ef} = 1.25\) y deriva a según el azar de cada pregunta). Se observa por qué una pregunta fácil es poco útil para un alumno avanzado (su probabilidad de acierto ya está pegada a 1) y por qué la zona más informativa de cada curva es la que rodea su propia dificultad, donde el resultado todavía podría ser acierto o fallo.
Figura 2. Curvas características del ítem para tres niveles de dificultad, con el suelo de azar y las tres hipótesis de nivel marcadas.
Estos valores de a, b y c no proceden de una calibración empírica con miles de respuestas reales, como ocurriría en un banco de ítems de una prueba estandarizada. Se generan a partir de valores por defecto respaldados por la literatura en TRI (Birnbaum, 1968; van der Linden y Hambleton, 1997), con a = 1,5 como punto de partida razonable, y de la estructura de cada pregunta. Es una limitación reconocida de manera explícita en la documentación técnica: son estimaciones a priori, útiles para poner en marcha el sistema, pero no medidas contrastadas con una muestra real de alumnado.
La entropía de Shannon como medida de incertidumbre
En este contexto, la incertidumbre no se refiere a una duda genérica, sino al grado en que la probabilidad sobre el nivel del alumno sigue repartida entre varias hipótesis. Si, tras algunas respuestas, las hipótesis H1, H2 y H3 tienen probabilidades parecidas, el sistema todavía no puede inclinarse con claridad por un diagnóstico. En cambio, si una de ellas concentra casi toda la probabilidad, la incertidumbre es baja, porque el estado del alumno está mucho mejor definido.
El sistema necesita cuantificar esa incertidumbre para tomar dos decisiones concretas a lo largo de la prueba. Por un lado, para decidir cuándo dejar de preguntar, es decir, cuándo la creencia sobre el nivel del alumno ya es lo bastante firme como para dar el diagnóstico por bueno, algo que se desarrolla en el criterio de finalización más adelante. Por otro, para comparar qué pregunta, de entre las disponibles, reduciría más esa incertidumbre si se planteara, que es el criterio de selección que se explica en la sección siguiente. La magnitud elegida para cuantificarla es la entropía de Shannon, tomada directamente de la teoría de la información.
$$H(p) = -\sum_{i} p_i \log_2 p_i$$
Se mide en bits. Con tres hipótesis equiprobables (0,33 cada una), la entropía es máxima: \(H = \log_2 3 \approx 1{,}58\) bits, la ignorancia total del punto de partida de la figura 1. Cuando una hipótesis concentra casi toda la probabilidad, la entropía cae hacia 0: por ejemplo, una distribución (0,95; 0,04; 0,01) tiene una entropía de solo 0,32 bits.
La entropía es preferible a mirar simplemente «cuál es la hipótesis con más probabilidad», porque distingue matices que un máximo por sí solo no recoge: dos distribuciones pueden compartir la misma hipótesis ganadora con la misma probabilidad y, sin embargo, repartir el resto de un modo muy distinto, lo que la entropía sí refleja. Por ejemplo, P = (0,80; 0,15; 0,05) y P = (0,80; 0,19; 0,01) comparten la misma hipótesis ganadora con la misma probabilidad (0,80), así que mirar solo el máximo sugeriría el mismo grado de confianza en ambos casos. Sus entropías, sin embargo, son distintas: 0,88 bits y 0,78 bits respectivamente, porque en la segunda distribución el 20 % restante está mucho más concentrado en una sola hipótesis (0,19 frente a 0,01) que en la primera (0,15 frente a 0,05). En la práctica, eso significa que la entropía captura matices de la distribución que el máximo no recoge, y por eso es la magnitud con la que el sistema mide la incertidumbre y valora cuánto la reduciría cada pregunta. Para cerrar el diagnóstico, en cambio, lo que decide es la confianza mínima de la hipótesis ganadora junto con el mínimo de preguntas: cuando el umbral de entropía se deriva de esa misma confianza, la condición de confianza ya implica la de entropía, de modo que comprobar ambas es inofensivo, pero no añade exigencia.
Selección de preguntas por ganancia esperada de información
Aquí aparece uno de los puntos donde esta metodología se aparta de la práctica habitual en los test adaptativos informatizados (CAT, por sus siglas en inglés). El criterio para elegir la siguiente pregunta es la ganancia esperada de información, es decir, cuánto se espera que baje la entropía si se hace esa pregunta, promediando los dos resultados posibles:
donde \(P(A)\) y \(P(F)\) son las probabilidades esperadas de acierto y fallo bajo la distribución actual, y \(P_{post,A}\), \(P_{post,F}\) son las probabilidades a posteriori que resultarían en cada caso. El sistema calcula esta ganancia para todas las preguntas disponibles y elige la que promete reducir más la incertidumbre, sea cual sea la respuesta.
El criterio dominante en los CAT clásicos no es este, sino la función de información del ítem (FII), basada en la información de Fisher:
La FII mide cuánta información aporta una pregunta en un punto concreto de la escala continua de habilidad θ (por ejemplo, θ = −1,5 podría corresponder a un alumno con dificultades notables, θ = 0 a uno de nivel medio y θ = +1,5 a uno con un dominio alto, pero también son válidos valores intermedios como θ = 0,7, a diferencia de las tres hipótesis discretas que maneja el enfoque bayesiano de este trabajo). Para evaluarla, el sistema clásico reduce todo lo que sabe del alumno a un único número: la estimación puntual θ̂, calculada habitualmente por máxima verosimilitud a partir de las respuestas dadas hasta ese momento. Es decir, mientras que el enfoque bayesiano de este artículo mantiene un vector completo de probabilidades sobre las hipótesis de nivel, por ejemplo P = (P(H1), P(H2), P(H3)), el CAT clásico colapsa esa misma información en un único valor θ̂ sobre la recta real (por ejemplo, θ̂ = 0,4) y evalúa la FII de cada pregunta candidata justo en ese punto, no en el resto de valores que θ podría tomar. El criterio bayesiano descrito aquí es preferible cuando el estado del alumno se representa como una distribución completa y no como ese punto único, por dos razones: usa toda la distribución en vez de forzar un colapso a un único valor antes de decidir, si, por ejemplo, la probabilidad está repartida casi por igual entre H1 y H2, θ̂ caerá en un punto intermedio que no representa bien a ningún alumno real, y la FII evaluada justo ahí puede recomendar una pregunta que no sea útil para distinguir entre esas dos hipótesis; y no exige que las hipótesis estén ordenadas en una única escala, lo que permite aplicarlo también a diagnósticos de errores conceptuales sin relación de orden entre sí. Ahora bien, nominal no significa siempre excluyente: si los errores son realmente alternativos, puede usarse una hipótesis por error; pero si varios errores pueden coexistir, el modelo correcto pasa a ser multifactorial o por perfiles completos, y la evidencia ideal no es solo la probabilidad de acierto, sino también qué distractor elige el alumno. El propio protocolo detalla estas variantes cuando las hipótesis no tienen orden.
Cuando varias preguntas tienen una ganancia casi idéntica, algo frecuente cuando comparten dificultad y número de opciones, el sistema no elige siempre la misma: aplica una selección aleatoria ponderada que favorece la variedad de categorías, para evitar que dos sesiones distintas generen la misma secuencia de preguntas.
Criterio de finalización y umbral de entropía
La prueba termina cuando se cumple alguna de estas dos condiciones: se alcanza una convergencia fiable, o se agota el número de preguntas disponibles sin haberla alcanzado. La convergencia fiable exige tres condiciones a la vez, no solo dos: haber respondido un número mínimo de preguntas, que la entropía caiga por debajo de un umbral \(H_{stop}\), y que la hipótesis más probable supere una confianza mínima \(p_{min}\).
El número mínimo de preguntas evita aceptar como firme una estimación basada en muy poca evidencia: antes de alcanzarlo, el sistema sigue preguntando aunque la entropía ya haya cruzado el umbral y una hipótesis ya supere la confianza mínima. De hecho, en el ejemplo numérico de la sección anterior esto ya ocurre tras la primera respuesta: al fallar Q1 la entropía baja a 0,764 bits (por debajo del umbral de 0,92 que se calcula más abajo) y la probabilidad de H1 sube a 0,81 (por encima de 0,80); sin un mínimo de preguntas exigido, el sistema daría ya por bueno un diagnóstico de nivel básico con una sola respuesta. Ese mínimo depende del diseño del recurso: en una etapa breve de práctica puede bastar con 4 preguntas; en un test diagnóstico más amplio puede exigirse un mínimo mayor, por ejemplo 8, junto con una cobertura mínima de dificultades o categorías.
La confianza mínima \(p_{min}\) tampoco es un valor universal: el protocolo puede trabajar con 0,80, 0,85 o cualquier otro valor según el tipo de recurso, la longitud esperada de la prueba, el número de hipótesis y el grado de prudencia deseado. Lo importante es que el umbral de entropía se derive de la confianza mínima elegida y del número de hipótesis consideradas:
Con \(p_{min}=0{,}80\) y n = 3 hipótesis, ese umbral vale aproximadamente 0,92 bits, la línea roja discontinua de la figura 1.
Se exige, además, que entropía y confianza mínima se cumplan juntas y no una sola de ellas, porque no equivalen a lo mismo: una distribución puede tener entropía baja sin que la hipótesis ganadora llegue a esa confianza mínima, si parte de las hipótesis quedan prácticamente descartadas, pero todavía existe una segunda hipótesis con una probabilidad apreciable, en vez de que el resto de la probabilidad se reparta por igual entre todas las demás (de hecho, la condición de confianza implica la de entropía cuando el umbral se deriva de ella; lo que realmente decide el cierre son el mínimo de preguntas y la confianza mínima).
Si el test termina sin cumplir las tres condiciones, el informe final lo indica de forma explícita: el diagnóstico se presenta como provisional, en lugar de ofrecer una falsa seguridad.
Comprobaciones de fiabilidad sin datos empíricos
Como los parámetros del modelo son estimaciones a priori (sección anterior), la metodología incorpora dos comprobaciones que permiten detectar cuándo el resultado no merece confianza, sin necesitar una muestra empírica de alumnado. Es, junto con el criterio de selección por entropía, el segundo punto donde este enfoque se separa de una implementación ingenua de un test adaptativo.
El índice person-fit (\(l_z\)). Detecta si el patrón de respuestas de un alumno concreto es coherente con el nivel que el modelo le ha asignado. Compara la log-verosimilitud observada del patrón de respuestas con la que cabría esperar bajo ese nivel, y estandariza la diferencia:
Bajo el modelo, \(l_z\) se distribuye aproximadamente como una normal estándar. Valores muy negativos (orientativamente \(l_z < -2\)) señalan un patrón improbable bajo el nivel estimado, típicamente acertar preguntas difíciles y fallar las fáciles, o responder al azar, lo que implica que el diagnóstico, aunque el sistema lo presente como «seguro», puede no ser fiable para ese alumno en concreto. La entropía dice cuán segura está la creencia del modelo; el person-fit dice si esa seguridad está justificada por el propio patrón de respuestas.
La validación por simulación (Monte Carlo). Responde a una pregunta distinta: no si un alumno concreto encaja en el modelo, sino si el banco de preguntas en su conjunto distingue bien los niveles. El procedimiento genera alumnos sintéticos situados exactamente en el θ de cada hipótesis, les hace responder de forma simulada (con la misma probabilidad de acierto que marca la curva IRT) y construye una matriz de confusión que compara el nivel real con el nivel diagnosticado. Es una comprobación de la coherencia interna del diseño, calculable antes de aplicar el test a nadie, aunque con un límite importante: los alumnos simulados se generan con el mismo modelo que después los clasifica, así que mide si el diseño discrimina los niveles, no si los parámetros reflejan la realidad de un aula concreta.
Diagnóstico multidimensional por habilidades
En uno de los recursos construidos con esta metodología, un laboratorio de combinatoria, el sistema no se limita a estimar un nivel general por tipo de problema. Mantiene, en paralelo, una distribución bayesiana independiente por cada habilidad transversal implicada (por ejemplo, la lectura del enunciado frente a los pasos de resolución), y todas se actualizan con la misma respuesta del alumno: el resultado global modifica la creencia sobre el nivel, y cada componente de la respuesta modifica la creencia sobre su dimensión correspondiente. Así, la estimación de nivel indica qué tipo de problema conviene practicar, y el diagnóstico por dimensión indica qué paso concreto conviene explicar o reforzar. Este punto no es un adorno técnico: cuando varias dificultades pueden coexistir, separarlas por dimensiones o por perfiles es la forma correcta de no forzar como excluyentes errores que en realidad pueden darse a la vez.
Cuando el ejercicio se corrige por pasos, la respuesta no es únicamente un acierto o fallo: se resume en una puntuación s entre 0 y 1, y la verosimilitud se construye combinando de forma geométrica la de acierto y la de fallo (con exponentes s y 1−s). Así, una respuesta a medias no empuja simplemente hacia el dominio: desplaza la creencia hacia el nivel cuya probabilidad de acierto prevista se parece más a esa puntuación; una puntuación intermedia refuerza un nivel intermedio.
Hipótesis sin relación de orden: la clasificación completa
Todos los ejemplos anteriores comparten un rasgo: sus hipótesis se pueden ordenar. Un nivel básico es menos que un nivel medio, y este menos que uno avanzado, por lo que tiene sentido asignar a cada hipótesis un valor de habilidad θ y usar la función logística de la TRI para generar las verosimilitudes. Pero no todas las preguntas que interesan a un docente son de tipo «cuánto nivel tiene este alumno». A veces la pregunta es «qué le pasa»: si confunde la masa con el peso o la velocidad con la aceleración, si resuelve con la estrategia A o con la B, si su dificultad está en la lectura del enunciado o en el procedimiento. Estas hipótesis son categorías sin relación de orden entre ellas, y la función logística deja de ser el modelo adecuado, porque asume una escala única de «más o menos nivel» que aquí no existe.
La solución no exige cambiar la metodología, sino la fuente de las verosimilitudes. En lugar de calcularlas con una fórmula, se definen directamente para cada pregunta: probabilidad de acierto alta bajo la hipótesis que la pregunta diagnostica bien y probabilidad baja bajo las hipótesis que induce a confusión. Por ejemplo, ante la pregunta «¿la masa de un objeto cambia en la Luna?», un alumno que confunde masa con peso tenderá a fallar (probabilidad de acierto en torno a 0,20), mientras que uno que confunde velocidad con aceleración no se ve afectado por esa pregunta (en torno a 0,80) y uno con dominio correcto acertará casi siempre (0,95). La actualización bayesiana, la entropía y el criterio de parada funcionan exactamente igual; solo cambia de dónde salen las verosimilitudes.
Queda un último caso: cuando varios errores o necesidades pueden darse a la vez. Un alumno puede confundir dos conceptos y, además, leer mal los enunciados. Forzar esas situaciones dentro de una única lista de hipótesis excluyentes sería un error de diseño, porque el sistema se vería obligado a elegir una sola etiqueta para alguien que merece varias. En ese caso se mantiene una distribución separada por cada factor o, si los factores interactúan con fuerza, una única distribución sobre todos los perfiles posibles (todas las combinaciones de presencia y ausencia de cada factor).
La infografía siguiente resume esta clasificación. Cruza dos preguntas de diseño: si las hipótesis se pueden ordenar y si son excluyentes o pueden coexistir. De ahí salen los cuatro casos: ordinal unifactorial (los test de nivel clásicos), ordinal multidimensional (como el laboratorio de combinatoria del apartado anterior), nominal unifactorial (categorías excluyentes con verosimilitudes explícitas) y nominal multifactorial (factores coexistentes, con dimensiones separadas o perfiles completos). Decidir en cuál de los cuatro se está es el primer paso al diseñar un recurso con esta metodología: determina la arquitectura de datos y el modelo matemático antes de escribir la primera pregunta.
Los ejemplos que hay a continuación pueden ayudar a entender los diferentes tipos de hipótesis. Estos programas han sido hechos proporcionándole a la IA el documento llamado Especificación Operativa para IA que está en la web: Recursos educativos adaptativos bayesianos y que tiene las instrucciones necesarias para la implantación completa del método. No es necesario indicarle el tipo de hipótesis que queremos utilizar porque la IA adaptará nuestra petición al que mejor se ajuste.
Ordinal unifactorial (A):
Test adaptativo de cultura general. Se centra en la evaluación y en la asignación del usuario a un grupo de conocimiento (bajo, medio y avanzado).
Ordinal multifactorial (B): Laboratorio de combinatoria. Consta de una fase inicial diagnóstica seguida de otra de refuerzo de los conceptos. Para cada concepto (permutaciones, variaciones y combinaciones, todas con y sin repetición, 12 en total) se proponen ejercicios en aquellos en los que más se falla. También se proporcionan informes sobre habilidades transversales (detección del tipo, conocimiento de la fórmula, repetición o no, etc.).
Nominal unifactorial (C): ¿Frío o caliente? Plantea dos errores mutuamente excluyentes sobre el calor y determina si se tiene alguno de los dos o ninguno.
Nominal multifactorial con factores separados (D): ¿Cómo comparas los decimales? Comprueba varios errores comunes relacionados con los decimales. Son errores no excluyentes, de forma que el programa puede determinar más de uno.
Diagnóstico inicial y refuerzo dirigido en la práctica prolongada
El mismo razonamiento se aplica, por ejemplo, en un itinerario de aprendizaje sobre ecuaciones de primer grado construido con este protocolo, donde decide cuándo dar por superada una etapa y cuándo insertar una tarjeta de refuerzo tras errores repetidos. En estos recursos de práctica prolongada, el diagnóstico no persigue solo un instante final, sino que la selección de preguntas se organiza en dos fases sucesivas, con un objetivo distinto cada una.
Fase diagnóstica inicial. Mientras existan categorías o tipos de problema con muy pocos intentos todavía (por ejemplo, menos de dos), el sistema los prioriza, para evitar sacar conclusiones de una muestra demasiado pequeña. Dentro de esas categorías, elige la pregunta con mayor ganancia esperada de información, igual que en la evaluación descrita en las secciones anteriores.
Fase de refuerzo. Una vez que todas las categorías tienen ya una muestra mínima, el sistema deja de repartir preguntas por igual entre ellas y prioriza la categoría con menor dominio estimado. Además, la pregunta concreta ya no se elige solo por su ganancia de información: se combina con una medida de cercanía a la dificultad del alumno, mediante una puntuación de utilidad del tipo:
con α entre 0,6 y 0,7. Esta separación en dos fases evita un uso excesivo de la entropía: la entropía responde a «dónde tengo más incertidumbre», pero no siempre a «qué necesita practicar más el alumno», y en un recurso de refuerzo interesan ambas preguntas. Para el alumno, esto se traduce en que la práctica no se convierte en una sucesión de ejercicios cada vez más difíciles: una vez detectado en qué tipo de problema falla más, el sistema le da más ejercicios de ese tipo, pero ajustados a una dificultad que todavía puede abordar, en vez de plantarle directamente los más exigentes solo porque son los más informativos para el diagnóstico.
En un recurso de práctica, el alumno aprende mientras practica, y la actualización bayesiana pura da el mismo peso a la primera respuesta que a la última, de modo que la estimación puede quedarse anclada en un estado que el alumno ya ha superado. Para evitarlo, la metodología incorpora un olvido exponencial: en la fase de refuerzo, la creencia acumulada se atenúa ligeramente antes de cada actualización (elevándola a una potencia λ = 0,95 y renormalizando), de modo que la respuesta de hace k ejercicios pesa λᵏ y el sistema recuerda de forma efectiva las últimas ~20 respuestas. Las recientes pesan más que las antiguas y la estimación sigue al alumno cuando mejora. Durante el diagnóstico inicial no se aplica (λ = 1), para no distorsionar el informe inicial. Es la versión mínima de los modelos de transición tipo Bayesian Knowledge Tracing (Corbett y Anderson, 1995), y el laboratorio de combinatoria citado arriba lo implementa.
Diferencias respecto a otros recursos adaptativos
La siguiente tabla resume los puntos en los que esta metodología se aparta de dos referencias habituales: los test adaptativos informatizados (CAT) clásicos de la psicometría, y las plataformas comerciales de aprendizaje adaptativo apoyadas en modelos entrenados con datos masivos de estudiantes.
Aspecto
CAT clásico / plataformas con big data
Esta metodología bayesiana
Estado del alumno
Un valor puntual θ̂ tras cada respuesta.
Una distribución de probabilidad completa sobre varias hipótesis.
Criterio de selección
Función de información del ítem (Fisher), evaluada en θ̂.
Ganancia esperada de información (reducción de entropía) sobre toda la distribución.
Calibración de las preguntas
Requiere datos de una muestra amplia de alumnado real.
Valores a priori razonables, basados en valores de referencia ya publicados en estudios previos de TRI y en la estructura de cada pregunta.
Control de fiabilidad
Suele depender de validaciones estadísticas externas con datos reales.
Person-fit (\(l_z\)) y validación por simulación Monte Carlo, calculables sin datos empíricos.
Alcance del modelo
Pensado sobre todo para evaluación.
Protocolo único aplicable a evaluación, itinerarios, práctica, refuerzo y recomendación.
Autoría
Requiere una plataforma o un equipo de psicometría.
Protocolo documentado y portable, ejecutable por una IA a partir de la especificación del propio docente; los recursos resultantes pueden funcionar enteramente en el navegador del alumno, sin servidores externos.
Resultado final
Puntuación o nivel.
Interpretación pedagógica: dominio, errores probables, recomendación y grado de firmeza del diagnóstico.
La fila de autoría de la tabla anterior requiere una aclaración, porque es la que hace posible el resto de diferencias: el teorema de Bayes, la TRI y la entropía de Shannon no son ideas nuevas, tienen décadas de recorrido en psicometría. Lo que sí es más reciente es formalizarlos como un protocolo escrito, con reglas explícitas, pensado para que una inteligencia artificial genere un recurso completo (banco de preguntas, verosimilitudes, criterio de parada, informe final) a partir de la descripción de un tema, un curso y unos objetivos dados por el docente, sin exigir conocimientos de estadística ni acceso a una base de datos de respuestas de otros alumnos. Eso traslada una técnica hasta ahora reservada a grandes proveedores educativos al alcance de cualquier profesor que quiera construir su propio recurso a medida de un contenido concreto.
Límites de la metodología
Esta metodología no sustituye el criterio docente. Sus resultados deben interpretarse con prudencia cuando hay pocas preguntas disponibles, cuando el banco no está bien calibrado, cuando el alumno responde al azar o cuando la entropía final sigue siendo alta pese a haber terminado la prueba. El propio índice \(l_z\) tiene además una limitación técnica: es una aproximación asintótica, y con pocas preguntas su distribución se aleja de la normal, por lo que el umbral de −2 debe tomarse como una señal de cautela y no como una prueba formal. De la misma manera, la validación por simulación mide la coherencia interna del diseño bajo el propio modelo, no una validez empírica: para eso siguen haciendo falta datos reales de alumnado, algo que esta metodología no pretende sustituir.
Creación de recursos adaptativos con IA, dudas y profundización en la metodología
Los ejemplos citados en este artículo, un test adaptativo de cultura general, un itinerario sobre ecuaciones y un laboratorio de combinatoria, son implementaciones construidas con este protocolo. La implementación utilizando inteligencia artificial (vibe coding) junto con la documentación técnica completa (protocolo y fundamentos matemáticos) está disponible en la web de recursos educativos adaptativos del autor: https://jjdeharo.github.io/recursos-adaptativos/
Birnbaum, A. (1968). Some latent trait models and their use in inferring an examinee’s ability. En Lord, F. M. y Novick, M. R., Statistical Theories of Mental Test Scores. Addison-Wesley. Referencia fundacional del modelo logístico de tres parámetros.
Rasch, G. (1960). Probabilistic Models for Some Intelligence and Attainment Tests. Danmarks Paedagogiske Institut (reeditado por University of Chicago Press, 1980). Modelo de dificultad de ítems.
Cover, T. M. y Thomas, J. A. (2006). Elements of Information Theory (2.ª ed.). Wiley. Entropía de Shannon e información mutua.
Corbett, A. T. y Anderson, J. R. (1995). Knowledge tracing: Modeling the acquisition of procedural knowledge. User Modeling and User-Adapted Interaction, 4(4), 253–278.
van der Linden, W. J. y Hambleton, R. K. (Eds.) (1997). Handbook of Modern Item Response Theory. Springer. Referencia enciclopédica de modelos y aplicaciones de la TRI.
van der Linden, W. J. y Glas, C. A. W. (Eds.) (2010). Elements of Adaptive Testing. Springer. Selección adaptativa de ítems e información.
Drasgow, F., Levine, M. V. y Williams, E. A. (1985). Appropriateness measurement with polychotomous item response models and standardized indices. British Journal of Mathematical and Statistical Psychology, 38(1), 67-86. Índice estandarizado de ajuste de la persona ($l_z$).
López Pina, J. A. (2026). Teoría de la Respuesta al Ítem: Fundamentos y modelos. Editum, Ediciones de la Universidad de Murcia. DOI: 10.6018/editum.3178. En español y de acceso abierto.
Wainer, H. (Ed.) (2000). Computerized Adaptive Testing: A Primer (2.ª ed.). Lawrence Erlbaum. Fundamentos de la evaluación adaptativa.
Gelman, A. et al. (2013). Bayesian Data Analysis (3.ª ed.). CRC Press. Inferencia bayesiana general.
OpenWorksheets (OWS) es una aplicación web libre para crear fichas interactivas y autocorregibles a partir de un PDF, una imagen o una hoja en blanco.
Pantalla inicial de OpenWorksheets
El profesorado prepara su ficha, coloca encima los campos de respuesta y define las soluciones. Después, el alumnado la resuelve desde el navegador y el docente puede revisar las entregas, ver la puntuación y exportar los resultados.
OWS tiene como bandera la libertad, privacidad, portabilidad y reutilización sin depender de una plataforma cerrada. No necesita cuentas de usuario ni servidores externos, ya que todo funciona en el navegador del profesorado y en el del alumnado. La comunicación entre ambos se realiza mediante archivos de entrega cifrados, que tienen extensión .owsub (OpenWorksheets submissions) o a través de una URL (también cifrada) que se envía directamente al docente.
Pantalla inicial del editor con las diferentes formas de crear una ficha.
Las formas que tenemos para crear una ficha (proyecto) son:
Añadir PDF o imagen, esta es la forma habitual. Podemos abrir un PDF o una imagen para dibujar encima los campos autocorregibles de forma que podemos aprovechar documentos ya existentes.
Abrir una ficha ya creada con extensión .owpkg (OpenWorksheets package). Podremos continuar trabajando en un proyecto guardado anteriormente.
Comenzar con una hoja en blanco sobre la cual podremos crear nuestra ficha.
Crear con IA (prompt) permite producir una ficha a partir de una página en blanco con los parámetros que definamos (nivel, tema, tipos de campos deseados, etc.). Se utilizan los tipos de campo que pueden generarse automáticamente; quedan fuera los que dependen directamente de recortes o zonas del PDF. OWS generará un prompt que podremos pegar en nuestra IA de cabecera. No hay que instalar nada.
Crear o convertir fichas con IA (MCP). Es el camino más potente y el único que puede partir de un documento propio: instalando el servidor MCP de OpenWorksheets, la IA abre nuestro PDF o nuestra imagen, coloca los campos encima, cada uno en su sitio, y nos enseña el resultado antes de guardarlo. También puede inventar la ficha entera desde cero sobre hojas en blanco. El archivo no se sube a ningún servicio, lo abre nuestro propio ordenador, aunque la IA sí ve el contenido de las páginas para poder trabajar. Requiere instalar un programa una sola vez, y se explica en un artículo aparte.
Un proyecto abierto (ficha). En la parte izquierda accedemos a los botones para crear campos, las miniaturas y a la derecha la lista de todos los campos y sus propiedades cuando se selecciona uno.
Además, las fichas pueden guardarse como archivo propio (.owpkg), exportarse como página web autónoma y compartirse mediante enlace (previa subida a la nube obteniendo un enlace público), como web incrustada en otra o integrarse en Moodle y otros LMS mediante SCORM 1.2.
La aplicación admite muchos tipos de respuesta: texto corto, respuesta numérica, fórmulas matemáticas o químicas, verdadero/falso, opción única o múltiple, desplegables, huecos, tablas editables, emparejamientos, ordenar elementos, arrastrar a zonas, unir con flechas, respuesta larga y grabación de voz. También permite insertar imágenes, audio, vídeo, contenido HTML, paquetes de eXeLearning, IMS CP y SCORM.
Como profesor de matemáticas y ciencias, soy especialmente sensible a la posibilidad de crear fórmulas. Cualquier texto de la ficha puede incluir fórmulas LaTeX. Además, el editor de fórmulas de elaboración propia, EdiCuaTeX, se integra de forma natural para permitir la edición visual sin conocimientos de LaTeX, tanto en la parte del profesorado como en la del alumnado. No obstante, soy consciente de que una gran parte del profesorado no usará nunca fórmulas en sus fichas, por ese motivo se pueden desactivar en la configuración de la ficha.
OpenWorksheets también incorpora opciones de seguridad y privacidad: cifrado de la ficha, cifrado de entregas, verificación de integridad, restricciones de acceso, tiempo límite y supervisión ligera durante la realización. Un semáforo de seguridad indica su nivel en la barra superior.
Flujo de trabajo
El flujo de trabajo más habitual es compartir la ficha mediante un enlace o código QR:
El profesor crea la actividad en el editor a partir de un PDF, una imagen, IA o una hoja en blanco.
Añade los campos de respuesta y configura las soluciones, la puntuación y las opciones de corrección.
Exporta la ficha como paquete .owpkg.
Sube ese paquete a Google Drive o a otro alojamiento público.
En Google Drive, activa la opción Cualquier persona con el enlace y copia la URL pública del archivo.
Pega esa URL en OpenWorksheets para generar el enlace final del alumnado.
Comparte ese enlace con los estudiantes.
El alumnado abre la ficha en el navegador, la completa y entrega sus respuestas mediante archivo o enlace de entrega.
El docente abre las entregas en OpenWorksheets, comprueba su integridad, revisa las respuestas, ajusta las correcciones manuales si las hay y exporta los resultados a CSV.
Además de este flujo principal, OpenWorksheets permite otras formas de uso:
Exportar la ficha como página web autónoma, para publicarla a través de una página web.
Integrarla en Moodle u otro LMS mediante SCORM 1.2.
Exportarla como IMS Content Package.
Embeberla en otra página mediante un iframe.
Cuadro de diálogo para compartir una ficha. Antes se tiene que subir la ficha a un servicio público de almacenamiento como Google Drive.
Una ficha tal como la ve el alumnado. En la esquina inferior derecha tiene la opción de finalizarla.
OpenWorksheets permite crear, compartir y corregir fichas interactivas con un enfoque abierto, portable y respetuoso con la privacidad. La intención es que el profesorado pueda conservar el control sobre sus materiales y utilizarlos en distintos contextos, sin depender de una plataforma cerrada.
Puedes ver una descripción de las posibilidades más completa en la página de las características del programa.
Nota: Este artículo tiene nivel 4 en el marco MIAE.
Sería insensato, y contradictorio en sí mismo, pensar que es posible hacer lo que hasta ahora nunca se ha hecho por procedimientos que no sean totalmente nuevos.
Comentarios recientes