Blog sobre educación

Categoría: Vibe coding (Página 1 de 3)

Cómo preguntar a la IA sobre tus documentos: un Gemini Notebook en tu propio ordenador

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

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

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

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.

Nota: Este artículo tiene nivel 4 en el Marco para la integración de la IA generativa.

Metodología para la creación de sistemas educativos adaptativos bayesianos

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í:

  • Test adaptativo de cultura general. Una prueba sencilla para comprobar la evaluación adaptativa.
  • Itinerario para aprender a despejar la incógnita x. Ejercicios con ecuaciones de primer grado para probar los itinerarios de aprendizaje adaptativos.
  • 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) = \frac{P(r \mid H_i) \cdot P(H_i)}{\sum_j P(r \mid H_j) \cdot P(H_j)}$$

El significado de cada término es el siguiente.

  • \(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.

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:

$$P(A \mid \theta, q) = c_q + (1 – c_q) \cdot \frac{1}{1 + e^{-a(\theta – b_q)}}$$

El significado de cada parámetro es el siguiente.

  • θ 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.

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:

$$IG(q) = H(P) – \big[P(A)\, H(P_{post,A}) + P(F)\, H(P_{post,F})\big]$$

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:

$$I_q(\theta) = \frac{[P'(\theta)]^2}{P(\theta)\,(1-P(\theta))}$$

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:

$$H_{stop} = -p_{min} \log_2 p_{min} – (1-p_{min}) \log_2!\left(\frac{1-p_{min}}{n-1}\right)$$

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:

$$l_z = \frac{l_0 – E[l_0]}{\sqrt{\mathrm{Var}[l_0]}}$$

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):
  • 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:

$$\text{utilidad} = \alpha \cdot IG_{normalizada} + (1-\alpha) \cdot \text{ajuste de dificultad}$$

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.

AspectoCAT clásico / plataformas con big dataEsta metodología bayesiana
Estado del alumnoUn valor puntual θ̂ tras cada respuesta.Una distribución de probabilidad completa sobre varias hipótesis.
Criterio de selecciónFunció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 preguntasRequiere 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 fiabilidadSuele 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 modeloPensado sobre todo para evaluación.Protocolo único aplicable a evaluación, itinerarios, práctica, refuerzo y recomendación.
AutoríaRequiere 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 finalPuntuació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/

Para resolver dudas concretas está disponible el asistente de IA, Fundamentos de los Sistemas Educativos Adaptativos Bayesianos, entrenado sobre el protocolo completo: https://notebooklm.google.com/notebook/1a4ee089-8c41-416e-ae43-28d24681bdc5.

Bibliografía recomendada

  • 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.

Nota: Este artículo tiene nivel 4 en el Marco para la integración de la IA generativa.

Creación de recursos educativos adaptativos mediante vibe coding

Este artículo ha sido ampliado y reemplazado por Metodología para la creación de sistemas educativos adaptativos bayesianos

Los recursos educativos adaptativos permiten que una actividad cambie según las respuestas del alumno. En este artículo veremos dos ejemplos y un protocolo para crear este tipo de recursos con IA. Para el que lo desee hay también un anexo matemático con la metodología utilizada.

Introducción a los recursos adaptativos

Los recursos educativos suelen ser lineales, por ejemplo, un test de evaluación es el mismo para todos. De la relación entre aciertos y errores obtendremos una calificación y, con suerte, un análisis de lo que cada alumno ha fallado y lo que le conviene mejorar.

Si esa misma evaluación la hacemos adaptativa, el sistema se acomoda a las respuestas del alumno, aprende de sus fallos y aciertos y ambos se convierten en información: El sistema debe usar las respuestas del alumno como evidencias para actualizar hipótesis sobre su estado de aprendizaje. Estas hipótesis pueden ser niveles de aprendizaje, de dificultad, errores conceptuales, etc. El sistema adaptativo no hace las mismas preguntas a todos, sino que las adapta según las respuestas realizadas hasta el momento por el alumnado.

El sistema adaptativo aprende de las respuestas del alumno para proponerle preguntas adaptadas a su nivel, de refuerzo si detecta errores o de ampliación y continuación más avanzada si detecta que puede hacerlo.

Esto puede hacerse con cualquier recurso, no estamos limitados a la evaluación. Por ejemplo, con un itinerario de aprendizaje, un juego educativo, un tutorial interactivo y cualquier recurso educativo digital en el que tenga sentido la adaptación a las diferentes tipologías y necesidades del alumnado.

Ejemplo 1: Test adaptativo para la evaluación diagnóstica

Hemos hecho dos ejemplos. El primero es un test de evaluación de cultura general. Fue el primero, hecho a modo de demo educativa, y permite evaluar nuestros conocimientos en tres niveles: básico, medio y avanzado. Cada vez que respondemos una pregunta, el sistema nos hace otra, de forma que la información que recibe de la respuesta es máxima para conocer nuestro nivel. De esta forma va adaptando las preguntas hasta que tiene información suficiente para decidir el nivel que tenemos en este tema. Para que esto sea significativo, las preguntas deben estar correctamente clasificadas en los 3 niveles. Las preguntas han sido generadas mediante IA, pero podríamos habérselas suministrado ya clasificadas cada una en su nivel.

El programa no solo determina el nivel del usuario, proporcionando el porcentaje de la probabilidad de pertenencia a cada uno, sino que crea un informe con aquellos aspectos en los que se puede mejorar y los que ya se dominan. Estos aspectos son los diferentes temas motivo de las preguntas (ciencias, historia, etc.).

Es importante remarcar que 7/10 no debe entenderse como una nota, ya que las preguntas han sido hechas para diagnosticar el nivel de conocimientos y lo que realmente importa es el nivel alcanzado. De ahí que sea una evaluación diagnóstica, pero no calificadora. Podríamos tener notas superiores o inferiores, de forma un tanto aleatoria, según los niveles en los que hubiésemos respondido. Es decir, un alumno que solo es capaz de responder cuestiones de nivel básico podría sacar un 8/10 y otro capaz de responder preguntas con más dificultad un valor inferior, precisamente porque, al ser capaz de responder preguntas más complejas, se le han hecho más de este tipo. Estas preguntas han servido para hacer un diagnóstico, pero no determinan una nota. No se hace un número fijo de preguntas; cuando el sistema tiene la certeza de que el alumno pertenece a una categoría determinada, entonces para de hacerlas. En el anexo se explica con más detalle el método utilizado.

Ejemplo 2: Itinerario adaptativo

El siguiente ejemplo es una aplicación, llamada Despejar la incógnita x, que permite practicar la técnica para despejar incógnitas en una ecuación de primer grado. El itinerario consta de tres etapas.

En primer lugar, muestra la técnica que se usará en cada etapa. Se le pueden pedir tantos ejemplos resueltos como se quiera.

Cuando se decide practicar la etapa, el sistema examina las respuestas para determinar si se domina o no la técnica correspondiente. En este programa se ha limitado a un mínimo de 4 respuestas para el que las resuelva correctamente y un máximo de 10 para el que no.

En el caso de no superar una etapa, el programa dará la oportunidad de repetirla de nuevo o continuar con el resto del itinerario.

Una vez terminadas las 3 etapas, el sistema da una indicación del progreso (iniciando, avanzando o dominando) y un informe de los puntos fuertes y débiles.

Debemos destacar que el número de ejercicios propuestos, las ayudas recibidas y el avance por las etapas vienen determinados por las respuestas del alumno. El itinerario mantiene una estructura progresiva, pero se adapta dentro de cada etapa y decide cuándo conviene avanzar, reforzar o repetir.

Cómo crear aplicaciones educativas con vibe coding

Hemos preparado la web Recursos educativos adaptativos bayesianos desde donde podrás descargar el archivo llamado Protocolo de recursos adaptativos bayesianos, con instrucciones para la inteligencia artificial. Este archivo deberás proporcionárselo a la IA para que sepa qué debe hacer. Este mismo documento lo puedes consultar en formato web en la página anterior.

Casi con toda seguridad, la inteligencia artificial no hará bien el programa a la primera, por lo que deberás comprobar si lo que ha hecho se adapta a tus necesidades y, a través del diálogo con la IA, adaptar el recurso hasta que esté realmente preparado.


Pódcast del artículo realizado por NotebookLM

Anexo: Metodología matemática utilizada

Esta parte solo es para los interesados en conocer los entresijos matemáticos que forma la metodología adaptativa utilizada por el protocolo anterior.

Inferencia bayesiana

El teorema de Bayes permite actualizar la probabilidad de una hipótesis cuando obtenemos una nueva evidencia. Es decir, partimos de una idea inicial sobre el nivel (o la categoría que hayamos definido) del alumno y la vamos modificando a medida que responde preguntas.

En un recurso adaptativo, las hipótesis pueden ser, por ejemplo: el alumno tiene un nivel básico, medio o avanzado.

Al comenzar, el sistema todavía no sabe cuál de estas hipótesis es la más probable, así que se asigna la misma probabilidad a todos:

  • \(P(\text{básico}) = 33.3%\)
  • \(P(\text{medio}) = 33.3%\)
  • \(P(\text{avanzado}) = 33.3%\)

Estas probabilidades iniciales se llaman probabilidades previas. Representan lo que el sistema cree antes de observar la respuesta del alumno.

Cuando el alumno contesta una pregunta, aparece una nueva evidencia, ya que ha acertado o ha fallado una pregunta de cierto nivel. Esa respuesta modifica las probabilidades anteriores. Si acierta una pregunta avanzada, aumentará la probabilidad de que pertenezca al nivel avanzado. Si falla varias preguntas básicas, aumentará la probabilidad de que necesite refuerzo en ese nivel.

En forma matemática, el teorema de Bayes se expresa así:

\[
P(H \mid E) = \frac{P(E \mid H) \cdot P(H)}{P(E)}
\]

  • Donde \(P(H \mid E)\) es la probabilidad de la hipótesis después de observar la evidencia. En nuestro caso, sería la probabilidad de que el alumno tenga un determinado nivel después de ver su respuesta.
  • \(P(H)\) es la probabilidad previa de esa hipótesis, antes de la respuesta.
  • \(P(E \mid H)\) es la probabilidad, llamada verosimilitud, de observar una determinada respuesta del alumno si una hipótesis concreta fuera cierta. Por ejemplo, qué probabilidad habría de que un alumno de nivel avanzado acertara una pregunta avanzada.
  • \(P(E)\) es la probabilidad de observar esa evidencia, sin saber todavía cuál es el nivel real del alumno. En nuestro ejemplo, sería la probabilidad global de que el alumno acierte una pregunta avanzada, antes de decidir si pertenece al nivel básico, medio o avanzado.

Aplicado a un test adaptativo, el razonamiento sería el siguiente:

Si un alumno fuera de nivel avanzado, sería bastante probable que acertara esta pregunta difícil.
Si fuera de nivel básico, sería poco probable que la acertara.
Como la ha acertado, aumenta la probabilidad de que sea de nivel avanzado.

Y al contrario:

Si un alumno falla una pregunta básica, esa respuesta es más compatible con la hipótesis de que necesita refuerzo. Por tanto, el sistema aumenta la probabilidad de que esté en un nivel inicial o de que tenga dificultades en ese contenido.

Lo importante es que el sistema no toma una única respuesta como definitiva. Cada respuesta modifica un poco el diagnóstico. Después de varias preguntas, las probabilidades se van separando: una hipótesis gana peso y otras lo pierden.

Por ejemplo, después de varias respuestas, el sistema podría obtener algo así de un alumno en particular:

  • \(P(\text{básico}) = 12%\)
  • \(P(\text{medio}) = 31%\)
  • \(P(\text{avanzado}) = 57%\)

Esto no significa que el alumno tenga una nota de 5,7 ni que haya acertado el 57 % de las preguntas. Significa que, según las respuestas observadas, el sistema considera que la hipótesis más probable es que el alumno se encuentre en el nivel avanzado.

Esta es la diferencia principal respecto a un test tradicional. En un test lineal, las respuestas se acumulan para obtener una puntuación. En un test adaptativo bayesiano, las respuestas se utilizan como evidencias para actualizar un diagnóstico.

El mismo principio puede aplicarse a otros tipos de recursos. En un itinerario de aprendizaje, la hipótesis no tiene por qué ser “nivel básico, medio o avanzado”, sino que puede ser “domina la técnica”, “está en proceso” o “necesita refuerzo”. Cada ejercicio resuelto aporta una nueva evidencia y permite decidir si conviene avanzar, repetir, ofrecer una explicación adicional o proponer actividades de mayor dificultad.

La inferencia bayesiana permite que el recurso educativo no siga un camino fijo, sino que tome decisiones a partir de la información que va obteniendo del alumno.

Verosimilitudes y modelo IRT 3PL

Para que Bayes actualice las probabilidades, el sistema calcula las verosimilitudes. En las preguntas o actividades organizadas por niveles de dificultad, estas verosimilitudes se generan mediante el modelo IRT 3PL (Item Response Theory, three-parameter logistic model), es decir, el modelo logístico de tres parámetros de la teoría de respuesta al ítem.

La idea general es que la probabilidad de acertar una pregunta aumenta cuando el nivel hipotético del alumno supera la dificultad de la pregunta, y disminuye cuando la dificultad supera el nivel hipotético del alumno.

El modelo usado es:

\[
P(\text{acierto}\mid H_i,q)=
c_q+(1-c_q)\cdot
\frac{1}{1+e^{-a(\theta_i-b_q)}}
\]

Donde \(\theta_i\) representa numéricamente la hipótesis o nivel \(H_i\), \(b_q\) representa la dificultad de la pregunta o actividad, \(a\) es el parámetro de discriminación y \(c_q\) es la probabilidad mínima de acierto por azar.

En el modelo IRT 3PL, estos tres parámetros tienen una función concreta: \(b_q\) sitúa la dificultad del ítem, \(a\) indica cuánto discrimina entre niveles próximos y \(c_q\) establece el suelo de probabilidad de acierto.

En preguntas de opción múltiple, este suelo se calcula a partir del número de opciones:

\[
c_q=\frac{1}{m_q}
\]

Por ejemplo, en una pregunta de cuatro opciones:

\[
c_q=\frac{1}{4}=0{,}25
\]

Esto significa que la probabilidad de acierto no se considera inferior al 25 %, porque incluso un alumno que responde al azar tiene esa probabilidad de acertar.

Si el alumno falla, se usa la probabilidad complementaria:

\[
P(\text{fallo}\mid H_i,q)=1-P(\text{acierto}\mid H_i,q)
\]

Estas probabilidades de acierto y fallo son las verosimilitudes que utiliza Bayes para actualizar el diagnóstico.

El modelo IRT 3PL no sustituye al teorema de Bayes. Su función es generar las verosimilitudes que Bayes necesita para hacer la actualización.

En recursos que no son tests, la misma lógica se aplica a preguntas, pasos, retos o actividades autocorregibles, siempre que se representen mediante una dificultad, una respuesta observable y una interpretación del resultado. La evidencia es un acierto, un fallo, un paso superado, una pista solicitada, un intento adicional o un error detectado, siempre que el recurso haya definido cómo se traduce esa actuación en una evidencia utilizable.

Cuando las hipótesis no son niveles ordenados, por ejemplo, distintos errores conceptuales, el modelo IRT 3PL no es el adecuado, porque presupone una escala común de nivel o dominio. En esos casos, las verosimilitudes se definen según la relación diagnóstica entre cada actividad y cada hipótesis. La actualización bayesiana sigue siendo la misma; lo que cambia es la forma de obtener las verosimilitudes.

Entropía de Shannon

La incertidumbre del sistema se mide mediante la entropía de Shannon:

\[
H=-\sum_i p_i\log_2(p_i)
\]

Donde \(p_i\) es la probabilidad actual de cada hipótesis.

Cuando las probabilidades están muy repartidas, la entropía es alta. Por ejemplo, si básico, medio y avanzado tienen probabilidades parecidas, el sistema todavía no tiene un diagnóstico claro.

Cuando una hipótesis concentra la mayor parte de la probabilidad, la entropía baja. En ese caso, el sistema tiene más seguridad sobre el estado del alumno.

La entropía se usa para tres cosas: medir la incertidumbre del diagnóstico, seleccionar actividades que aporten información y decidir si el proceso finaliza.

Selección adaptativa y ganancia de información

Después de actualizar las probabilidades, el sistema decide qué pregunta, explicación, pista, ejercicio o actividad presenta a continuación.

Esta selección no se basa simplemente en subir la dificultad tras un acierto y bajarla tras un fallo. El método utilizado es la ganancia esperada de información. Es decir, el sistema estima qué actividad reduce más la incertidumbre sobre el estado del alumno.

Como la incertidumbre se mide con la entropía de Shannon, la ganancia de información se calcula como una reducción esperada de entropía. De forma simplificada:

\[
IG(q)=H(\text{antes})-H(\text{después, esperado})
\]

Para cada posible actividad, el sistema calcula qué ocurre si el alumno la supera y qué ocurre si no la supera. En cada caso estima cómo cambian las probabilidades de las hipótesis y qué entropía tiene la nueva distribución. Después compara la entropía actual con la entropía esperada tras esa actividad.

La actividad más adecuada es la que distingue mejor entre las hipótesis que todavía son plausibles. Por eso, la mejor pregunta no siempre es la que coincide exactamente con el nivel más probable. Si el sistema duda entre nivel medio y avanzado, una pregunta difícil resulta más informativa que una pregunta media. Si duda entre nivel básico y medio, selecciona una pregunta más sencilla o intermedia.

Cuando varias actividades tienen una ganancia de información muy parecida, el sistema introduce diversidad de contenidos. Así evita repetir siempre el mismo tipo de pregunta o el mismo concepto cuando hay varias opciones igualmente útiles.

Criterio de parada y resultado final

El proceso se detiene cuando el sistema alcanza una confianza suficiente, cuando la entropía baja por debajo de un umbral previsto, cuando se llega al número máximo de preguntas o pasos, o cuando las actividades disponibles ya no aportan información relevante.

El resultado final no se limita a una etiqueta ni a una puntuación. Se presenta como una interpretación pedagógica: qué parece dominar el alumno, qué dificultades muestra, qué conviene reforzar y con qué grado de seguridad se propone el diagnóstico.

Si la incertidumbre sigue siendo alta, el sistema lo indica claramente. En ese caso, el resultado se presenta como una estimación provisional basada en las evidencias disponibles, no como una conclusión definitiva.

Esta es la diferencia principal respecto a un recurso educativo lineal. En una secuencia fija, todos los alumnos recorren el mismo camino y sus respuestas solo sirven para avanzar, retroceder o recibir una puntuación. En un recurso adaptativo bayesiano, cada respuesta o actuación se utiliza como evidencia para actualizar un modelo del estado del alumno y decidir cuál debe ser el siguiente paso: una nueva pregunta, una explicación, una pista, una actividad de refuerzo, una propuesta de ampliación, un cambio de itinerario o una recomendación de recursos.

Nota: El texto del artículo tiene nivel 1 en el Marco para la integración de la IA generativa y el anexo nivel 4.

Este artículo ha sido ampliado y reemplazado por Metodología para la creación de sistemas educativos adaptativos bayesianos

La elección de herramientas para el Vibe Coding Educativo

Pódcast del artículo

En este año 2025 ha empezado a consolidarse un enfoque de trabajo que muchos docentes ya practican de manera intuitiva y que recibe un nombre específico: vibe coding educativo. Este concepto no se refiere a una tecnología concreta ni a un lenguaje de programación determinado, sino a una forma de crear recursos digitales y aplicaciones educativas apoyándose en asistentes de inteligencia artificial, priorizando la intención pedagógica, la rapidez de iteración y la coherencia funcional por encima del dominio exhaustivo del código.

El vibe coding educativo parte de una idea sencilla: el docente define qué quiere conseguir, una simulación, una app sencilla, un recurso interactivo, un generador de actividades, y dialoga con la IA para ir construyendo ese artefacto digital de manera progresiva. El código deja de ser un fin en sí mismo y pasa a ser un medio. Esto no elimina la necesidad de comprender lo que se está haciendo, pero sí reduce de forma notable la barrera de entrada y el tiempo necesario para obtener resultados funcionales.

En este contexto, la elección de herramientas adquiere un papel relevante. Conviene aclarar que la selección presentada en esta infografía y en este artículo es una selección personal, centrada de forma intencionada en los grandes chatbots generalistas y sus entornos de trabajo asociados, por ser actualmente los más conocidos y accesibles para el profesorado. Además, esta práctica se apoya cada vez más en comunidades docentes donde se comparten ejemplos reales, dudas y soluciones. Un punto de referencia destacado es el grupo de Telegram Vibe Coding Educativo (https://t.me/vceduca), que reúne a más de 1500 docentes interesados en aplicar este enfoque en el aula. No todas las soluciones sirven para lo mismo, ni todas encajan con el nivel técnico, el tiempo disponible o la infraestructura del centro educativo. La infografía distingue dos grandes categorías: herramientas vía web y herramientas locales, cada una con subtipos claramente diferenciados.

Herramientas vía web

Las herramientas vía web se ejecutan directamente en el navegador, sin necesidad de instalación. Esta característica las convierte en una opción muy adecuada para empezar, para trabajar desde equipos con recursos limitados o para contextos educativos donde no es posible instalar software adicional.

Para prototipado rápido (una página)

Este tipo de herramientas permite generar interfaces visuales, pequeños scripts o recursos interactivos de manera inmediata. Son especialmente útiles para demostraciones rápidas, actividades puntuales o pruebas de concepto en el aula.

Para desarrollo estructurado (multipágina)

Estas herramientas facilitan el diseño de aplicaciones más complejas, con varias vistas, lógica interna y cierta arquitectura de proyecto, manteniendo el acceso desde el navegador.

Herramientas locales (instaladas en tu equipo)

Las herramientas locales requieren instalación previa y aprovechan directamente la potencia del hardware del equipo. A cambio, ofrecen mayor control sobre los archivos, la estructura del proyecto y los procesos de ejecución.

Editores gráficos (IDE)

Proporcionan un entorno visual completo para gestionar proyectos de programación, con acceso a código, recursos y asistentes de IA integrados.

Terminal (CLI)

Permiten interactuar con la línea de comandos para crear, modificar y automatizar proyectos completos mediante instrucciones textuales. CLI significa interfaz de línea de comandos (Command Line Interface).

Otras herramientas y enfoques complementarios

La lista de herramientas no es cerrada ni pretende ser exhaustiva. Existen otras plataformas y entornos que también se utilizan en prácticas cercanas al vibe coding educativo, aunque con enfoques algo distintos. Por ejemplo, Canva (https://www.canva.com/) incorpora funciones de generación asistida que facilitan la creación de recursos interactivos y prototipos visuales sin apenas código, especialmente orientados al diseño educativo. Por su parte, Cursor (https://cursor.sh/) es un editor de código con IA integrada que permite desarrollar aplicaciones completas a partir de instrucciones en lenguaje natural, con un enfoque más cercano al desarrollo profesional.

Estas y otras herramientas muestran que el ecosistema es amplio y diverso, y que cada docente puede encontrar combinaciones distintas en función de sus objetivos, su experiencia previa y el contexto de uso.

Comunidad docente y aprendizaje compartido

El vibe coding educativo se ve reforzado cuando el trabajo individual se complementa con el intercambio colectivo. Espacios como el grupo de Telegram Vibe Coding Educativo (https://t.me/vceduca) permiten conocer experiencias de otros docentes, descubrir nuevas herramientas, resolver problemas técnicos y contrastar enfoques didácticos. Esta dimensión comunitaria facilita una adopción más realista y sostenible del vibe coding en contextos educativos diversos.

Criterios para elegir la herramienta adecuada

El vibe coding educativo no impone una única vía de trabajo. Para actividades rápidas o recursos sencillos, las herramientas vía web suelen ser suficientes. Para proyectos más estables y reutilizables, las herramientas locales ofrecen ventajas claras en términos de control y escalabilidad.

En muchos casos, ambas aproximaciones se combinan de forma natural: se inicia un recurso en la nube, se valida su utilidad didáctica y, si el proyecto crece, se traslada a un entorno local más robusto. Esta flexibilidad es una de las características que hacen del vibe coding educativo una práctica especialmente adecuada para el ámbito escolar.

Quizás también te interese:

Nota: Este artículo tiene nivel 4 en el Marco para la integración de la IA generativa.

Creación de herramientas educativas con inteligencia artificial: guía para docentes

La incorporación de la inteligencia artificial (IA) en el ámbito educativo representa una oportunidad para ampliar las posibilidades didácticas. Más allá de su papel como asistente de redacción o generador de contenido, los sistemas basados en IA permiten la creación de recursos digitales adaptados a contextos específicos de enseñanza y aprendizaje utilizando únicamente el lenguaje natural.

La elaboración de juegos de preguntas, fichas de lectura interactivas o formularios de repaso puede realizarse actualmente sin conocimientos de programación, únicamente mediante la redacción de instrucciones claras en lenguaje natural, es lo que se llama Vibe Coding (o programación por vibraciones). De este modo, la IA se consolida como un instrumento creativo al servicio del profesorado.

En este artículo hablaremos exclusivamente de la generación de programas a través de los chatbots disponibles de forma gratuita en la web y dejaremos de lado métodos más avanzados que se ejecutan desde el propio ordenador, como la programación mediante consola o versiones CLI de los chatbots.

Si te interesa estar al día, resolver dudas y compartir aplicaciones y conocimientos, apúntate a la comunidad Vibe Coding Educativo.


Paso 1: selección del chatbot o servicio de IA adecuado

Un chatbot de inteligencia artificial puede definirse como un sistema capaz de mantener una interacción conversacional y ejecutar tareas complejas en función de las instrucciones recibidas. Entre las opciones disponibles destacan los siguientes. Todos disponen de canvas, lienzo o visualizador del recurso educativo que estamos creando:

  • Gemini (Google): con funciones como Canvas que permiten estructurar proyectos completos. https://gemini.google.com
  • ChatGPT (OpenAI): ampliamente extendido por su versatilidad y facilidad de uso. También dispone de canvas o lienzo. https://chat.openai.com
  • Qwen (Alibaba): orientado a la generación de código y con herramientas específicas de desarrollo web. Utiliza un canvas. https://qwen.ai
  • Claude (Anthropic): reconocido por su claridad en la explicación de procesos y capacidad de depuración. Para la programación utiliza artefactos que no son editables por el usuario, es decir, donde no podemos editar directamente el código generado. https://claude.ai
  • Deepseek: con un enfoque técnico que también resulta útil en entornos educativos. Como Claude, no puede modificarse el resultado mediante edición directa. https://deepseek.com

Además de los chatbots, se pueden utilizar plataformas que ofrecen la posibilidad de programar, aunque su enfoque es diferente.

  • Canva Pro: herramienta de diseño gráfico, gratuita para docentes, que permite crear presentaciones, infografías y materiales visuales de apoyo. https://www.canva.com/education
  • Lovable: servicio especializado en creación de aplicaciones y prototipos mediante IA. https://lovable.dev
  • Websim: plataforma para generar y simular páginas web a partir de instrucciones en lenguaje natural. https://websim.ai

La elección de las versiones más avanzadas, como por ejemplo Gemini 2.5 Pro o ChatGPT con el modo pensamiento activado, facilita la creación de aplicaciones educativas gracias a su mayor capacidad de generación y corrección de código. Si hay una opción de «pensar» o «razonar» deberemos marcarla.

Paso 2: inicio del proceso de creación

Para garantizar la correcta producción de recursos, es necesario activar las funciones de programación que cada chatbot ofrece.

En el caso de Gemini y ChatGPT, la función Canvas (lienzo) organiza el trabajo en un entorno que permite generar, revisar y editar código. Qwen, por su parte, dispone de la opción desarrollo web, con la que se preparan estructuras en HTML, CSS o JavaScript (HTML se utiliza para estructurar el contenido de una página web, CSS para definir su aspecto visual y JavaScript para añadir interactividad). Cuando creamos un programa simple con un chatbot, estos tres elementos ya van incorporados dentro del código generado.

Este tipo de funciones operan como un “taller digital” en el que la IA recibe las herramientas necesarias para elaborar materiales educativos adaptados a las necesidades planteadas.

Paso 3: comunicación con la IA: transformar ideas en realidad mediante prompts sencillos

La forma de crear un recurso educativo es mediante lenguaje natural, explicando con el máximo detalle posible lo que deseamos. Conviene indicar siempre que sea una aplicación en HTML, de este modo no nos creará programas en Python y otros lenguajes de programación que no nos servirían para compartir en la web.

De forma opcional, pero recomendable en muchos casos, podemos también indicar:

De cara a la creación de los prompts podemos utilizar dos enfoques. La primera es cuando sabemos lo que queremos, pero no cómo lo queremos. Por ejemplo:

  • Crear una página HTML con un formulario básico para que los alumnos ingresen su nombre y respondan tres preguntas sobre el sistema solar.
  • Generar un programa en HTML para un mini-juego de adivinar animales con pistas.
  • Diseñar una plantilla HTML para una ficha de lectura con campos para título, autor y resumen.
Prompt: Diseñar una plantilla HTML para una ficha de lectura con campos para título, autor y resumen. Hecho con Gemini 2.5 Pro. Su funcionalidad es limitada ya que no se puede guardar el resultado.

El segundo enfoque es especificar detalles que ya tengamos pensados o que queremos incorporar después de una conversación previa con la IA. Por ejemplo:

Crea una aplicación de una sola página para gestionar fichas de lectura. Necesito que tenga las siguientes características:

  • Un formulario para introducir título, autor y resumen.
  • Que los datos se guarden localmente en el navegador.
  • Una tabla que muestre todas las fichas guardadas.
  • Botones para poder editar y borrar cada ficha de forma individual.
  • Exportar todas las fichas a un archivo CSV.
  • Un botón para borrar todas las fichas guardadas, con un aviso de confirmación.»

Pocas veces llegaremos al resultado deseado a la primera, por lo que deberemos decirle en cada interacción aquello que deseamos modificar hasta obtener el resultado deseado. Conviene ir guardando copias intermedias por si acabamos estropeando el programa. Una forma de hacerlo es compartirlo y guardar la URL que nos llevará siempre a esa versión concreta.

Características adicionales de canvas y visores integrados

Es importante remarcar que los programas que hagamos a través de los chatbots, en principio, tienen una serie de limitaciones:

  • Excepto en Deepseek, en el resto tenemos un botón para compartir el resultado (que Qwen llama desplegar) para poder compartir lo que hemos hecho y que sea visible para los demás.
  • En todos ellos, si queremos visualizar el resultado en el mismo chatbot, nos tenemos que limitar a un único archivo HTML. Esto ya lo tienen en cuenta los propios chatbots, que siempre nos ofrecerán un documento con todo lo necesario en su interior. No obstante, esto limita su aplicación en proyectos más complicados. Para proyectos complejos, una vez se dominen los chatbots, recomendamos el uso de las versiones de terminal de las IA (ver Guía básica para usar la inteligencia artificial desde la terminal).
  • Todos tienen medidas de seguridad que impiden la ejecución de determinado tipo de código. Por ejemplo, la opción de guardar datos en el propio navegador no funciona nunca dentro de los visores integrados, por lo que no pueden recordar datos. En estos casos no quedará más remedio que pasarlo a una plataforma externa como GitHub. Ver GitHub para alojar recursos educativos abiertos (REA) y presentarlos en formato web.
  • Canvas de Gemini:
    • Los programas de Gemini que incluyan inteligencia artificial solo podrán funcionar desde el propio entorno de Gemini. Deberemos tener en cuenta si los alumnos de nuestro centro los podrán usar (normalmente las cuentas educativas no lo permiten).
    • Las cuentas educativas no tienen la opción de compartir. Por lo tanto, la recomendación es utilizar siempre cuentas personales para crear los programas o nos encontraremos con un programa que solo podremos utilizar nosotros (a no ser que lo subamos a un servicio como GitHub).
  • Las aplicaciones que hayamos compartido a partir del canvas en Gemini, ChatGPT y Claude podrán ser modificadas pulsando el botón para hacer copia que llevan integrado. De este modo podemos adaptar cualquier aplicación compartida según nuestras necesidades. Qwen permite compartir el recurso con otros usuarios, pero no les deja modificarlo.

Particularidades del canvas de Gemini

El canvas de Gemini tiene dos características únicas de las que merece la pena citar, aunque sea brevemente. Son la posibilidad de incorporar inteligencia artificial a nuestros productos y la herramienta gráfica para seleccionar sobre el propio recurso y pedir modificaciones.

Añadir características de IA a nuestro recurso

En Gemini podemos añadir IA a nuestra propia aplicación para hacerla inteligente. Deberemos tener en cuenta varios aspectos importantes:

  • La aplicación solo funcionará dentro de Gemini, es decir, utilizando el botón compartir y proporcionando a los alumnos el enlace. No podríamos ponerla en Moodle, GitHub o nuestra página personal.
  • Las versiones corporativas (educativas) no permiten compartir los recursos creados, por lo que es obligatorio hacerlo desde una cuenta personal.
  • Las funciones de Gemini suelen estar desactivadas para el alumnado, por lo que debemos asegurarnos que pueden usar Gemini con las cuentas de centro o, en su defecto, deberán utilizar cuentas personales.

Una vez tenemos claro lo anterior, al crear un recurso educativo, en la parte inferior derecha veremos una pequeña barra de herramientas:

Presentación creada por Gemini con el prompt: «Crea una presentación HTML que explique mediante fichas el concepto evolutivo actual a alumnos de 4º de ESO». El botón señalado añadirá opciones de intelegencia artificial. Pulsa sobre la imagen para acceder.

Al pulsar el botón para añadir IA, nos aparecerán funciones inteligentes decididas por el mismo Gemini.

Presentación con funciones inteligentes determinadas por Gemini. Pulsa sobre la imagen para acceder.

Si no nos convence lo que acaba de hacer, podemos pulsar el botón «Versión anterior» para deshacer los cambios.

No es necesario pulsar el botón de IA para añadirla a nuestra aplicación, también le podemos indicar lo que queremos exactamente en el prompt inicial o más tarde, una vez tengamos la aplicación hecha. Por ejemplo, si a la versión que todavía no tiene IA le indicamos: Añade en cada ficha un cuadro de texto para que los alumnos puedan hacer preguntas a la IA y ampliar la información. El resultado será:

Cada ficha dispone de un espacio para escribir con el que el alumnado podrá hacer preguntas. Pulsa sobre la imagen para acceder

Herramienta para editar gráficamente el recurso

Recientemente, se ha añadido un botón que permite seleccionar una parte de la aplicación generada para pedirle a Gemini que cambie cualquier aspecto del contenido que tenemos en pantalla.

Al pulsarla, podemos seleccionar cualquier parte de la pantalla y decirle qué cambios queremos, por ejemplo, que modifique el título:

Paso 4: manejo de errores: identificación y solución

La aparición de errores forma parte habitual del proceso de generación de código. Este procedimiento de corrección recibe el nombre de depuración.

Los chatbots como Gemini, ChatGPT o Claude suelen ofrecer mecanismos de autocorrección y sugerencias para resolver fallos detectados. Ante un error, resulta recomendable interpretar el mensaje generado, solicitar a la IA una revisión del código.

Aparte de los mecanismos de autocorrección, una forma que muchas veces resulta útil es copiar el contenido a un archivo HTML, utilizando el bloc de notas o programa similar de texto (nunca Word o LibreOffice)

Paso 5: consulta con otro chatbot para errores persistentes

Cuando un error no se resuelve de forma satisfactoria, es posible recurrir a otro sistema de IA como apoyo complementario. El procedimiento consiste en trasladar el código con el fallo al nuevo chatbot, recibir una propuesta de solución y, posteriormente, proporcionar las correcciones indicadas a nuestra IA para que las ponga en práctica.

Esta estrategia se asemeja a la colaboración entre colegas: diferentes perspectivas contribuyen a encontrar soluciones más eficaces.

Paso 6: publicación de la creación: compartir la aplicación educativa con alumnos

Una vez finalizado el recurso, existen varias opciones para su difusión:

  • Opción A (inmediata): compartir el proyecto y ejecutarlo directamente desde la plataforma de IA utilizada. Esta opción es obligatoria si nuestra app de Gemini utiliza en su interior la IA.
  • Opción B (directa): guardar el archivo en formato HTML y abrirlo en un navegador web. Este archivo puede compartirse a través de plataformas educativas o entornos digitales de aprendizaje.
  • Opción C (avanzada): utilizar espacios de almacenamiento y difusión como GitHub, que permiten compartir proyectos con mayor alcance. GitHub para alojar recursos educativos abiertos (REA) y presentarlos en formato web.

Dispones de más información y la forma de publicarlo en otros lugares como Google Sites o Moodle en la página: Dónde publicar las aplicaciones.

Resumen de características

Chatbot Lo mejor Limitaciones clave Cuándo elegirlo
Gemini (Google) Canvas con edición directa y posibilidad de añadir funciones de IA dentro de la app. Las apps con IA solo funcionan dentro de Gemini; con cuenta educativa de Google no se puede compartir. Si quieres incorporar IA en el recurso y trabajas con cuenta personal de Google; adecuado para prototipos rápidos con edición en el lienzo.
ChatGPT (OpenAI) Muy versátil y sencillo para generar, editar y compartir desde un lienzo. Los diseños que genera son pobres y simples. Útil para continuar programas ya empezados por otros o para corregir errores, pero poco recomendable para iniciar proyectos desde cero debido a sus diseños básicos.
Qwen (Alibaba) Opción “desarrollo web” orientada a HTML, CSS y JS con visor integrado. Comparte el recurso pero no permite que otros lo modifiquen. Cuando necesitas estructuras web algo más elaboradas y no requieres edición colaborativa del recurso compartido.
Claude (Anthropic) Excelente explicando procesos y ayudando a depurar código. El diseño de los artefactos es más elegante y cuidado. No permite edición directa del recurso: solo se pueden leer los artefactos o hacer una copia para trabajar aparte. Cuando priorizas comprender y refinar el código, o si valoras un entorno más claro y estético aunque sin edición directa.
Deepseek Visor integrado útil para revisar y validar código con enfoque técnico. No ofrece botón de compartir ni edición en el visor. Como apoyo técnico para revisar soluciones, más que para crear y distribuir recursos finales desde el visor.

Conclusión: integración de la IA en el aula para el futuro de la educación

La inteligencia artificial se presenta como una herramienta transformadora en la práctica docente, al posibilitar la creación de recursos personalizados sin necesidad de programación. Su valor radica en la capacidad de adaptar materiales al contexto de aprendizaje y potenciar la creatividad en el diseño de actividades educativas.

El desarrollo responsable y ético de estas tecnologías constituye un aspecto esencial. Al integrarse en el aula, la IA no solo amplía las metodologías disponibles, sino que también proyecta una visión de futuro en la que la innovación y la enseñanza avanzan de manera conjunta.

Nota: este artículo tiene nivel 3 en el Marco para la integración de la IA generativa.


Pódcast del artículo

Resumen creado por NotebookLM

FAQ creada por NotebookLM

1. ¿Qué es el «Vibe Coding» y cómo facilita la creación de herramientas educativas con IA?

El «Vibe Coding» o programación por vibraciones es la capacidad de crear recursos digitales mediante la redacción de instrucciones claras en lenguaje natural, sin necesidad de conocimientos de programación. En el ámbito educativo, esto permite a los docentes diseñar juegos de preguntas, fichas de lectura interactivas o formularios de repaso de forma sencilla, utilizando chatbots de IA. La IA se convierte así en un instrumento creativo al servicio del profesorado, transformando ideas didácticas en aplicaciones funcionales.

2. ¿Cuáles son los chatbots de IA recomendados para docentes que buscan crear herramientas educativas y qué ofrecen?

Existen varios chatbots de IA útiles para docentes, cada uno con características particulares:

  • Gemini (Google): Ofrece funciones como Canvas para estructurar proyectos completos y la posibilidad de añadir inteligencia artificial a las aplicaciones creadas, aunque las apps con IA solo funcionan dentro de Gemini y las cuentas educativas no permiten compartir.
  • ChatGPT (OpenAI): Ampliamente extendido por su versatilidad y facilidad de uso con un lienzo integrado para generar, editar y compartir, aunque sus diseños suelen ser básicos.
  • Qwen (Alibaba): Orientado a la generación de código con una opción de «desarrollo web» y un visor integrado, pero no permite que otros modifiquen los recursos compartidos.
  • Claude (Anthropic): Destaca por su claridad en la explicación de procesos y capacidad de depuración, con diseños más elegantes, pero no permite la edición directa del código generado.
  • Deepseek: Con un enfoque técnico, útil para revisar y validar código con un visor integrado, aunque no ofrece botón de compartir ni edición en el visor.

Además de los chatbots, plataformas como Canva Pro (diseño gráfico), Lovable (creación de apps y prototipos) y Websim (simulación de páginas web) también pueden ser de utilidad.

3. ¿Qué pasos básicos debe seguir un docente para crear un recurso educativo con IA utilizando un chatbot?

El proceso de creación de recursos educativos con IA se resume en los siguientes pasos:

  1. Selección del chatbot o servicio de IA: Elegir la herramienta más adecuada según las necesidades, como Gemini, ChatGPT, Qwen, Claude o Deepseek, considerando sus funcionalidades de Canvas o visualizador.
  2. Inicio del proceso de creación: Activar las funciones de programación del chatbot (como Canvas en Gemini y ChatGPT, o la opción de desarrollo web en Qwen).
  3. Comunicación con la IA mediante prompts: Redactar instrucciones claras y detalladas en lenguaje natural, especificando siempre que se desea una aplicación en HTML y, opcionalmente, que sea responsiva y con una licencia de uso. Se puede partir de una idea general o especificar detalles concretos.
  4. Manejo de errores (depuración): Interpretar los mensajes de error, solicitar a la IA una revisión del código o copiar el contenido a un archivo HTML para revisar.
  5. Consulta con otro chatbot (si los errores persisten): Trasladar el código con el fallo a un segundo chatbot para obtener una propuesta de solución y aplicarla en la IA original.
  6. Publicación de la creación: Compartir el proyecto directamente desde la plataforma de IA, guardar el archivo HTML para abrirlo en un navegador, o usar plataformas de almacenamiento y difusión como GitHub.

4. ¿Qué son los «prompts» y cómo se utilizan eficazmente para generar herramientas educativas con IA?

Los «prompts» son las instrucciones que el usuario da a la IA en lenguaje natural para que genere un determinado recurso. Para utilizarlos eficazmente en la creación de herramientas educativas, es crucial:

  • Ser lo más detallado posible: Explicar con precisión lo que se desea que la IA cree.
  • Especificar el formato HTML: Es importante indicar que se quiere una aplicación en HTML para asegurar que el programa sea compartible en la web y no se generen códigos en otros lenguajes.
  • Indicar características opcionales: Recomendar que la aplicación sea «responsiva» (adaptable a diferentes dispositivos) y, si se desea, la licencia de uso.

Existen dos enfoques principales para los prompts:

  • Ideas generales: «Crear una página HTML con un formulario básico para alumnos…»
  • Especificar detalles concretos: «Crea una aplicación de una sola página para gestionar fichas de lectura con un formulario, guardado local, tabla de fichas, botones de edición/borrado y exportación a CSV.»

5. ¿Qué limitaciones tienen los programas creados con chatbots de IA para docentes y cómo se pueden abordar?

Los programas creados directamente con chatbots de IA, especialmente en sus visores integrados, presentan algunas limitaciones:

  • Un solo archivo HTML: Generalmente, se limitan a un único archivo HTML, lo que restringe su aplicación en proyectos más complejos. Para estos, se recomienda el uso de versiones de terminal de la IA.
  • Medidas de seguridad: Impiden la ejecución de cierto tipo de código, como guardar datos en el propio navegador, lo que significa que no pueden recordar información. Para guardar datos de forma persistente, es necesario trasladar el proyecto a plataformas externas como GitHub.
  • Funcionalidades de IA en Gemini: Si una aplicación de Gemini incluye IA, solo funcionará dentro del entorno de Gemini y no podrá ser compartida desde cuentas educativas, requiriendo el uso de cuentas personales.
  • Edición de recursos compartidos: Mientras que Gemini, ChatGPT y Claude permiten hacer una copia y modificar aplicaciones compartidas, Qwen permite compartir pero no editar el recurso por otros usuarios.

Para abordar estas limitaciones, se sugiere utilizar plataformas externas para proyectos complejos o para guardar datos, y considerar las particularidades de cada chatbot al momento de la creación y difusión.

6. ¿Cómo se puede integrar la inteligencia artificial directamente en una aplicación educativa creada con Gemini?

Gemini ofrece la posibilidad de añadir características de IA a una aplicación educativa, lo que la hace «inteligente». Para lograrlo, se deben considerar algunos aspectos importantes:

  • Funciona solo dentro de Gemini: La aplicación solo funcionará y podrá ser utilizada dentro del entorno de Gemini, mediante el enlace compartido. No se podrá integrar en otras plataformas como Moodle o GitHub.
  • Cuentas personales: Es obligatorio crear y compartir estos recursos desde una cuenta personal, ya que las versiones corporativas o educativas no permiten compartir aplicaciones con funciones de IA.
  • Disponibilidad para el alumnado: Hay que asegurarse de que los alumnos puedan usar Gemini con sus cuentas de centro o, si no es posible, deberán usar cuentas personales para interactuar con la aplicación.

Una vez que se tiene claro lo anterior, al crear el recurso, se puede pulsar un botón específico en la barra de herramientas inferior derecha para añadir opciones de IA que Gemini determine. Alternativamente, se puede indicar directamente en el prompt inicial o en interacciones posteriores qué funciones inteligentes se desean, por ejemplo: «Añade en cada ficha un cuadro de texto para que los alumnos puedan hacer preguntas a la IA y ampliar la información.»

7. ¿Qué opciones de publicación y difusión existen para las aplicaciones educativas creadas con IA?

Una vez finalizado el recurso educativo, hay varias opciones para su difusión, dependiendo de las necesidades y características de la aplicación:

  • Opción A (inmediata): Compartir el proyecto directamente desde la plataforma de IA utilizada. Esta es la opción obligatoria si la aplicación de Gemini utiliza funciones de IA internas.
  • Opción B (directa): Guardar el archivo generado en formato HTML y abrirlo en un navegador web. Este archivo puede compartirse fácilmente a través de plataformas educativas o entornos digitales de aprendizaje.
  • Opción C (avanzada): Utilizar espacios de almacenamiento y difusión como GitHub, que permiten compartir proyectos con un alcance mayor, especialmente útil para recursos educativos abiertos (REA) y para alojar aplicaciones más complejas que requieren guardar datos o múltiples archivos.

Además, se menciona la posibilidad de publicarlo en otros lugares como Google Sites o Moodle, para lo cual se recomienda consultar la página «Dónde publicar las aplicaciones».

8. ¿Qué estrategias de depuración o resolución de errores se recomiendan al crear código con chatbots de IA?

La aparición de errores es una parte normal del proceso de generación de código con IA. Para manejarlos eficazmente, se recomiendan las siguientes estrategias:

  • Interpretación del mensaje de error: Los chatbots como Gemini, ChatGPT o Claude suelen ofrecer mensajes claros que explican el error. Es fundamental leerlos y comprenderlos.
  • Solicitar revisión a la IA: Pedir a la propia IA que revise el código y sugiera soluciones para el fallo detectado.
  • Copiar el contenido a un archivo HTML externo: Una técnica útil es copiar el código generado a un archivo HTML simple usando un bloc de notas (nunca programas de procesamiento de texto como Word o LibreOffice). Esto permite una revisión manual más sencilla.
  • Consulta con otro chatbot: Si un error persiste y no se resuelve satisfactoriamente, se puede recurrir a un segundo sistema de IA. El procedimiento consiste en trasladar el código con el fallo a este nuevo chatbot para que proponga una solución, la cual luego se aplica en la IA original. Esta estrategia aprovecha diferentes perspectivas para una depuración más eficaz.
« Entradas anteriores

© 2026 Bilateria

Tema por Anders NorenArriba ↑