Los bancos de preguntas con IA para Moodle y Canvas pueden importarse sin mostrar un solo error. Y estar mal. Un XML válido solo demuestra que la plataforma entiende el archivo. No demuestra que cada pregunta mida lo que debe, que la respuesta sea defendible o que la conversión haya conservado su significado.
Lo comprobé con un banco que, a primera vista, parecía terminado: veinte preguntas visibles en Moodle y ningún error durante la importación.
Después abrí el cuestionario como estudiante.
Ahí cambió la historia.
Una pregunta tenía dos respuestas defendibles, aunque solo una estaba marcada como correcta. Otra evaluaba un concepto ausente de la fuente. Varias pedían recordar definiciones cuando el objetivo era aplicar. Técnicamente, el XML era válido. Pedagógicamente, el banco todavía era un borrador.
Ese fue el punto de partida de QTI Question Bank Generator: una skill que convierte contenidos, textos, preguntas guía y resultados de aprendizaje en bancos revisables. La IA propone enunciados, respuestas y distractores. El código se ocupa de lo que no debería variar entre ejecuciones: validar el modelo, detectar incoherencias y construir los formatos finales.
La diferencia parece pequeña, pero cambia el enfoque completo. Dejamos de generar texto para pegar y empezamos a construir un activo de evaluación: algo que debe poder explicarse, revisarse, versionarse y moverse entre plataformas sin fingir que todos los formatos significan lo mismo.
He publicado el proyecto completo en GitHub. El repositorio incluye la skill, el modelo JSON canónico, los exportadores, los tests y ejemplos reproducibles para revisar cómo funciona antes de utilizarla.
La pregunta ya no es si una IA puede redactar diez preguntas. La pregunta es si podemos convertir esa capacidad en un proceso educativo repetible, auditable e importable.
Bancos de preguntas con IA: seis decisiones clave
- Partir de una fuente. No de una petición aislada.
- Diseñar antes de redactar. El blueprint decide qué debe medir el banco.
- Separar significado y formato. Un JSON canónico conserva la fuente de verdad.
- Validar dos veces. La estructura con código; la evaluación con criterio humano.
- Exportar por destino. QTI, Moodle XML y GIFT no son envoltorios equivalentes.
- No degradar en silencio. Si una interacción no cabe en el formato, el proceso se detiene y lo explica.
Generar bancos de preguntas con IA no es pedir una lista
Una lista de preguntas cabe en una respuesta del chatbot. Un banco tiene que sobrevivir fuera de esa conversación.
Necesita nombres internos, identificadores estables, categorías, resultados de aprendizaje, dificultad, nivel cognitivo, respuestas correctas, distractores, feedback, puntuación, referencias y estado de revisión. También necesita una respuesta incómoda: qué parte de toda esa información sobrevivirá al llegar al formato de destino.
Cuando toda esa lógica vive en un único prompt, el proceso se vuelve resbaladizo. Una ejecución incluye feedback y la siguiente lo olvida. Aparecen identificadores repetidos. El XML parece correcto hasta que el LMS lo rechaza. Peor aún: una interacción compleja puede convertirse en otra más simple para que la exportación “funcione”, aunque por el camino haya cambiado lo que queríamos evaluar.
El mayor riesgo no es que la IA genere una mala pregunta. El mayor riesgo es que una pregunta no revisada termine dentro de un banco oficial y parezca válida solo porque el archivo se ha importado correctamente.
Por eso separé dos controles que suelen mezclarse:
- Calidad pedagógica: comprueba qué evalúa la pregunta, si la respuesta es defendible, si los distractores son plausibles y si el feedback ayuda a aprender.
- Calidad técnica: comprueba que el modelo sea consistente, que el XML esté bien formado, que el paquete incluya su manifiesto y que no existan identificadores duplicados.
Por eso, una pregunta puede pasar uno de los controles y fallar en el otro. Conviene recordarlo: importar bien no significa evaluar bien.
Por qué un prompt se queda pequeño para crear bancos de preguntas con IA
Mi primera reacción fue escribir mejores instrucciones. Después, instrucciones para corregir las instrucciones. El prompt acumuló reglas para distractores, excepciones por formato, ejemplos, validaciones y recordatorios. Cada parche resolvía una ejecución y hacía más difícil entender la siguiente.
En ese momento dejó de ser un problema de prompting. Necesitaba contratos, pruebas y una memoria controlada. Para ordenar el salto me resultó útil pensar las skills por niveles de madurez. No es un estándar oficial; es una forma práctica de saber cuándo una colección de instrucciones empieza a comportarse como una herramienta.
| Nivel | Qué incorpora | Aplicación en esta skill |
|---|---|---|
| 1 | Instrucciones reutilizables | Reglas de generación, revisión y exportación |
| 2 | Plantillas y formatos de salida | Blueprint y banco JSON de ejemplo |
| 3 | Referencias especializadas | Pedagogía, accesibilidad, tipos de ítem e interoperabilidad |
| 4 | Scripts y validación determinista | CLI Python para validar, exportar y verificar |
| 5 | Evaluaciones y aprendizaje controlado | Evals de activación, pruebas de calidad y Learnings.md |
La versión resultante se mueve entre los niveles 4 y 5. El agente puede razonar sobre el diseño del banco. No le confío las piezas que deben comportarse igual cada vez. El agente redacta. Los scripts validan y serializan.
Un modelo de lenguaje es muy útil para proponer un distractor basado en un error conceptual frecuente. Es bastante menos fiable recordando cada detalle de un manifiesto, escapando caracteres o aplicando siempre la misma política ante un tipo incompatible.
Por ese motivo, prefiero código aburrido. Precisamente porque es predecible.
La arquitectura combina razonamiento probabilístico donde aporta valor y ejecución determinista donde necesitamos garantías.
La skill para bancos de preguntas con IA por dentro
La skill no es un prompt con otro nombre. SKILL.md funciona como puerta de entrada: explica cuándo actuar, qué pasos seguir y qué recursos consultar. El conocimiento especializado vive en las referencias. Las garantías repetibles, en los scripts y las pruebas. Esa separación evita que una sola pieza tenga que pensar, recordar y ejecutar a la vez.
qti-question-bank-generator/
├── SKILL.md
├── README.md
├── Learnings.md
├── CHANGELOG.md
├── references/
│ ├── canonical-model.md
│ ├── pedagogy-and-quality.md
│ ├── item-types.md
│ ├── accessibility.md
│ ├── interoperability.md
│ └── output-contract.md
├── assets/
│ ├── question-bank.schema.json
│ ├── bank.template.json
│ ├── blueprint.template.json
│ ├── example-source.md
│ └── example-bank.json
├── scripts/
│ └── qbank.py
├── tests/
│ └── test_qbank.py
└── evals/
├── trigger-evals.json
└── quality-evals.jsonAsí evito convertir el archivo principal en una enciclopedia. La skill carga las reglas detalladas cuando hacen falta y ejecuta los scripts sin llenar el contexto con cientos de líneas de código. Menos ruido. Más control.
Qué contiene SKILL.md
El frontmatter define el nombre, la descripción, la compatibilidad, la licencia y los disparadores. Ahí aparecen expresiones como “generar un banco de preguntas”, “QTI 2.1”, “QTI 3.0”, “Moodle XML”, “GIFT”, “Canvas” o “banco de ítems”. Son las pistas que ayudan al agente a decidir cuándo debe cargar la skill.
El cuerpo marca el recorrido: comprobar la entrada, construir el blueprint, generar en lotes pequeños, producir el JSON canónico, validar, exportar, verificar los artefactos y cerrar con revisión pedagógica. El orden importa. Si genero antes de diseñar el banco, el resto del flujo solo maquilla una mala distribución.
Qué aportan las referencias
- Pedagogía y calidad: claridad, distractores, feedback, dificultad y alineación.
- Tipos de ítem: reglas específicas para elección, respuesta corta, numérica, ensayo, matching u ordenación.
- Accesibilidad: lenguaje comprensible, recursos alternativos y eliminación de pistas visuales innecesarias.
- Interoperabilidad: matriz de soporte y política de pérdida semántica.
- Modelo canónico: contrato de datos común a todos los exportadores.
Qué hacen los scripts
El CLI de scripts/qbank.py hace cuatro tareas poco glamurosas y muy necesarias: crear una plantilla, validar un banco, exportarlo y verificar paquetes QTI. Funciona con Python 3.10 o superior y no necesita dependencias externas.
python3 scripts/qbank.py validate bank.json --strict
python3 scripts/qbank.py export bank.json \
--format all \
--output dist
python3 scripts/qbank.py verify \
dist/mi-banco-qti21.zip
La decisión que ordenó todo: no pedir el XML a la IA
La pieza central no es QTI. Tampoco Moodle XML. Es un JSON canónico propio que representa el banco antes de adaptarlo a cada destino. Suena menos vistoso que “la IA genera un paquete compatible”. También es bastante más importante.
La IA trabaja sobre ese modelo. Ahí quedan los metadatos, los objetivos de aprendizaje, el blueprint, los ítems, las respuestas, el feedback, la justificación, las referencias y el estado de revisión. Si mañana cambia el destino, el significado del banco no tiene que cambiar con él.
{
"bank": {
"id": "cybersecurity-authentication",
"title": "Contraseñas y autenticación multifactor",
"language": "es-ES",
"status": "draft",
"learning_objectives": [
{
"id": "LO1",
"text": "Identificar buenas prácticas de autenticación"
}
],
"blueprint": [],
"items": []
}
}Desde ahí sale cada exportador. Por ejemplo, no genero QTI para convertir después ese QTI a Moodle XML. Tampoco uso GIFT como estación intermedia. Las conversiones encadenadas parecen cómodas hasta que empiezan a soltar equipaje por el camino: feedback, metadatos, tolerancias, rúbricas o tipos de interacción.
Una fuente de verdad, varios exportadores. Esta decisión reduce la variabilidad y permite añadir nuevos formatos sin reescribir el proceso pedagógico.
Flujo para crear bancos de preguntas con IA importables
La arquitectura solo tiene sentido si cambia lo que ocurre entre la fuente y el LMS. En estos bancos de preguntas con IA, el flujo de la versión 1.0 identifica los puntos en los que el proceso debe continuar, volver atrás o detenerse.
1. Analizar la fuente y declarar supuestos
Primero pone las cartas sobre la mesa: fuente, audiencia, nivel, objetivos, cantidad, dificultad, tipos de ítem, idioma, LMS y restricciones. Sin ese contexto, “genera veinte preguntas” es una orden rápida. También es un diseño de evaluación muy pobre.
Si faltan detalles menores, aplica valores prudentes y deja constancia. Puede proponer, por ejemplo, una distribución inicial del 30 % de preguntas fáciles, 50 % medias y 20 % difíciles. Si la ausencia cambia la validez de la evaluación, no improvisa: se detiene o deja el banco en borrador.
2. Construir un blueprint antes de redactar
El blueprint reparte el banco antes de escribirlo. Cada fila conecta objetivo, contenido, evidencia esperada, nivel de Bloom, dificultad, tipo y cantidad.
| Objetivo | Contenido | Bloom | Dificultad | Tipo | Cantidad |
|---|---|---|---|---|---|
| LO1 | Contraseñas seguras | Comprender | Fácil | Verdadero/Falso | 2 |
| LO1 | Autenticación multifactor | Aplicar | Media | Elección única | 3 |
| LO2 | Riesgos de reutilización | Analizar | Media | Respuesta múltiple | 2 |
Es una tabla sencilla. Su valor aparece al final, cuando no descubres que diecisiete de las veinte preguntas repiten el primer apartado del tema y apenas rozan el resto.
3. Generar en lotes pequeños
La skill trabaja con grupos de entre cinco y quince ítems. Los lotes pequeños no son una limitación accidental. Permiten revisar el rumbo antes de multiplicar un error por cincuenta.
Para cada pregunta define primero qué evidencia debe aportar el estudiante. Después redacta el enunciado, determina la respuesta correcta, crea distractores basados en errores conceptuales y añade feedback. Empezar por la evidencia reduce preguntas bonitas que no demuestran nada.
Además, aplica reglas de higiene: nada de dobles negaciones, opciones solapadas, pistas gramaticales, “todas las anteriores”, datos sin unidades o preguntas de recuerdo cuando el objetivo exige aplicar o analizar.
4. Producir y validar el JSON canónico
El banco debe cumplir un JSON Schema. El validador busca problemas que una lectura rápida deja pasar: respuestas correctas inexistentes, objetivos desconocidos, identificadores duplicados, puntuaciones incoherentes o estructuras incompletas.
La salida separa errores, advertencias y métricas. Un error bloquea la exportación. Una advertencia obliga a revisar o a dejar una decisión documentada. No todo merece detener el proceso, pero nada relevante debería desaparecer.
5. Generar una salida de revisión humana
Antes de abrir el LMS, genero una versión en Markdown o CSV. Es la mesa de trabajo del revisor: enunciado, respuesta, feedback, dificultad, Bloom, objetivos y referencias a la vista. Nadie debería necesitar leer XML para decidir si una pregunta es buena.
| ID | Tipo | Enunciado | Respuesta | Dificultad | Objetivo | Estado |
|---|---|---|---|---|---|---|
| Q1 | Elección única | ¿Qué práctica añade una segunda barrera de acceso? | Activar MFA | Fácil | LO1 | Draft |
| Q2 | Verdadero/Falso | Reutilizar una contraseña reduce el riesgo. | Falso | Fácil | LO1 | Draft |
El estado solo cambia a reviewed después de una revisión humana o una aprobación explícita. La IA puede proponer. No puede firmarse a sí misma el examen.
6. Exportar sin esconder incompatibilidades
Si el destino no admite un tipo de pregunta, la exportación falla por defecto. La opción --on-unsupported skip permite omitirlo, pero deja por escrito qué ítem se ha quedado fuera y por qué.
No convierto automáticamente una ordenación en elección múltiple. Tampoco elimino una tolerancia numérica para conseguir que el archivo “salga”. Prefiero un error visible a una evaluación silenciosamente distinta.
7. Verificar y probar en el LMS
La verificación QTI abre el ZIP y comprueba lo básico: existe imsmanifest.xml, los recursos declarados están presentes, el XML está bien formado y no hay identificadores duplicados.
Finalmente, queda la prueba que ningún validador local puede sustituir: importar una muestra en la versión concreta del LMS, mirar cómo se representa y responderla como estudiante. El último metro de la interoperabilidad siempre se recorre dentro del producto real.
Formatos para exportar bancos de preguntas con IA
La versión 1.0 exporta siete representaciones. Siete salidas no significan siete equivalentes. Cada una resuelve un problema distinto y conserva una parte diferente del modelo.
| Formato | Uso principal | Observaciones |
|---|---|---|
| QTI 2.1 ZIP | Intercambio e importación en plataformas compatibles | Es la salida QTI que debe probarse para Canvas |
| QTI 3.0 ZIP | Interoperabilidad basada en la versión moderna del estándar | No debe presentarse como importación garantizada en Canvas |
| Moodle XML | Importación en el banco de preguntas de Moodle | Formato específico de Moodle |
| GIFT | Edición textual e importación sencilla en Moodle | No conserva toda la riqueza del modelo |
| CSV | Revisión tabular | Útil para docentes y control de calidad |
| Markdown | Revisión legible y versionado | Ideal para Git y comentarios |
| JSON | Fuente canónica y automatización | Conserva la representación más completa |
Moodle XML: una salida práctica, pero específica
Moodle XML permite representar preguntas de elección, verdadero/falso, respuesta corta, numéricas, emparejamiento, ensayo y otros tipos. La skill genera XML bien formado, utiliza UTF-8 y conserva categorías, feedback, puntuaciones y las propiedades compatibles con cada interacción.
La propia documentación de Moodle recomienda este formato cuando interesa conservar la mayor cantidad posible de datos, incluido el feedback. Aun así, no he convertido un DTD en el centro del proyecto. La prioridad es validar el XML, probar el subconjunto implementado y contrastarlo con una importación real. Para ampliar el exportador, la referencia más útil sigue siendo bastante terrenal: crear la pregunta en Moodle, exportarla y comparar la estructura.
Canvas: QTI 2.1, no una promesa genérica de QTI
Aquí conviene afinar. La documentación de Canvas New Quizzes admite paquetes QTI 1.2 y 2.x, pero avisa de que algunos tipos o extensiones de terceros pueden no funcionar. Por eso la salida orientada a Canvas es QTI 2.1 y se prueba siempre en una instancia concreta.
Además, la skill genera QTI 3.0 porque la línea QTI 3 de 1EdTech moderniza la presentación, la accesibilidad y el uso de tecnologías web. Sin embargo, producir QTI 3.0 no obliga a Canvas a entenderlo. El estándar describe un contrato; cada producto decide qué parte implementa.
“Compatible con QTI” no es una propiedad binaria. Depende de la versión, del perfil implementado, de los tipos de interacción y de las extensiones que interprete cada producto.
GIFT, CSV y Markdown: menos semántica, más revisión
GIFT es cómodo, legible y rápido para cargas masivas, pero no conserva toda la riqueza de rúbricas, accesibilidad o metadatos. CSV y Markdown ni siquiera intentan competir con un formato importable: convierten el banco en algo que una persona puede revisar sin pelearse con etiquetas XML.
El docente revisa contenido. El equipo técnico conserva la representación completa y automatiza exportaciones. Cada perfil trabaja con la vista que necesita, sin inventar dos fuentes de verdad.
Tipos de ítem en bancos de preguntas con IA
El modelo canónico de la versión 1.0 contempla ocho tipos. La lista es deliberadamente más pequeña que todo lo que permiten los estándares: prefiero soportar un subconjunto conocido a declarar una compatibilidad de escaparate.
- elección única;
- respuesta múltiple;
- verdadero/falso;
- respuesta corta;
- respuesta numérica;
- ensayo;
- emparejamiento;
- ordenación.
| Tipo canónico | QTI 2.1 | QTI 3.0 | Moodle XML | GIFT |
|---|---|---|---|---|
| Elección única | Sí | Sí | Sí | Sí |
| Respuesta múltiple | Sí | Sí | Sí | Sí |
| Verdadero/Falso | Sí | Sí | Sí | Sí |
| Respuesta corta | Sí | Sí | Sí | Sí |
| Numérica | Sí | Sí | Sí | Sí |
| Ensayo | Sí | Sí | Sí | Sí |
| Emparejamiento | Sí | Sí | Sí | Sí |
| Ordenación | Sí | Sí | No estándar en esta skill | No |
Cuando el destino no puede representar un tipo, el comportamiento predeterminado es detenerse. El usuario puede elegir omitirlo, pero recibe la lista exacta de elementos excluidos.
En principio, puede parecer una política estricta. Lo es. A cambio, evita una de las trampas clásicas de la interoperabilidad: celebrar que el archivo se ha importado después de haber cambiado la evidencia que debía aportar el estudiante.
Cómo instalar y usar la skill de bancos de preguntas con IA
La skill está disponible en el repositorio público andreums/qti-question-bank-generator-skill. Puedes descargar una versión, revisar el código o clonar el proyecto con git clone https://github.com/andreums/qti-question-bank-generator-skill.git.
En Claude Code, la documentación de skills distingue entre instalación personal y de proyecto. La carpeta contiene SKILL.md como punto de entrada y puede incluir referencias, recursos y scripts.
# Disponible para todos los proyectos
mkdir -p ~/.claude/skills
cp -R qti-question-bank-generator ~/.claude/skills/
# Disponible solo en el repositorio actual
mkdir -p .claude/skills
cp -R qti-question-bank-generator .claude/skills/Después puede activarse automáticamente cuando la petición coincide con su descripción o invocarse de forma explícita:
/qti-question-bank-generator
Genera un banco de 20 preguntas a partir de tema-ciberseguridad.md.
Audiencia: profesorado no técnico.
Objetivo: identificar y aplicar buenas prácticas de autenticación.
Formatos: Markdown de revisión, Moodle XML y QTI 2.1.
No inventes contenido no respaldado por la fuente.En definitiva, ahí está la ventaja frente al prompt guardado en un documento: la skill ya conoce el procedimiento, los contratos y los límites. El usuario aporta el caso. No tiene que reconstruir la herramienta en cada conversación.
No hace falta empezar siempre con un documento
Un PDF o un temario completo ofrece más trazabilidad, pero no es la única puerta de entrada. Los bancos de preguntas con IA también pueden partir de un texto pegado, una pregunta guía, unos resultados de aprendizaje o un banco existente. Lo que cambia es el grado de incertidumbre. Cuanto más abierta sea la entrada, más importante resulta declarar el alcance y separar lo que procede de la fuente de lo que asumimos como conocimiento del dominio.
La petición no necesita contener todo el diseño del banco. Sí debe explicar, como mínimo, para quién es, qué debe demostrar el alumnado y dónde se importará. Si pedimos más de cinco ítems, la skill construye primero el blueprint.
Ejemplo 1: crear un banco desde un texto pegado
Este es el caso más directo. Tenemos una explicación breve y queremos comprobar comprensión y aplicación sin preparar antes un archivo.
Usa $qti-question-bank-generator para crear un banco a partir del siguiente texto:
La autenticación multifactor combina dos o más factores de categorías distintas: algo que sabes, algo que tienes y algo que eres. Añadir dos contraseñas no constituye MFA porque ambas pertenecen a la misma categoría.
Audiencia: personal no técnico.
Nivel: iniciación.
Cantidad: 8 preguntas.
Tipos: opción múltiple y verdadero/falso.
Objetivo: distinguir MFA de una autenticación basada en un único tipo de factor.
Destino: Moodle 5.0.
Primero crea el blueprint. Genera los ítems en lotes, mantenlos en estado draft y entrégame Markdown para revisarlos. No exportes todavía a Moodle XML.Así, la última línea evita el atajo habitual. El primer resultado útil no es el XML: es una versión legible que todavía podemos discutir.
Ejemplo 2: partir de una pregunta guía
A veces no existe todavía un contenido cerrado. Solo hay una cuestión que queremos trabajar. También sirve, siempre que aceptemos que la skill tendrá que acotar el dominio o pedir contexto antes de redactar.
Usa $qti-question-bank-generator tomando como punto de partida esta pregunta:
¿Cómo puede una organización modernizar progresivamente una aplicación legacy sin detener el negocio?
Quiero un banco de 12 ítems para desarrolladores sénior.
Nivel: intermedio.
Evidencias: reconocer riesgos, priorizar fronteras de extracción y elegir una estrategia de migración justificable.
Tipos: opción múltiple, respuesta múltiple y emparejamiento.
Formatos de revisión: JSON canónico y Markdown.
Antes de crear preguntas, propón el alcance y los supuestos de conocimiento del dominio. Si una decisión cambia materialmente el banco, pregúntame. Después prepara el blueprint, pero no redactes los ítems hasta que lo apruebe.En este caso, la pausa es deliberada. Una pregunta guía puede abrir demasiados caminos. Aprobar el blueprint antes de generar evita terminar con doce ítems correctos sobre un temario distinto del que teníamos en mente.
Ejemplo 3: diseñar desde resultados de aprendizaje
Cuando ya existen resultados observables, la skill puede repartir la evaluación sin depender de un documento narrativo. Es una entrada especialmente útil al preparar una asignatura, una formación interna o una prueba de diagnóstico.
Usa $qti-question-bank-generator para diseñar un banco desde estos resultados de aprendizaje:
1. Explicar la diferencia entre autenticación y autorización.
2. Detectar permisos excesivos en un caso sencillo.
3. Elegir una medida correctora aplicando mínimo privilegio.
Audiencia: equipo de soporte de primer nivel.
Cantidad: 15 ítems.
Distribución de dificultad: 30 % fácil, 50 % media y 20 % difícil.
Bloom: comprensión, aplicación y análisis.
Puntuación total: 20 puntos.
Destino previsto: Moodle 5.0.
Crea un blueprint que relacione cada ítem con un resultado, una evidencia, un nivel de Bloom, una dificultad y una puntuación. Señala cualquier porcentaje o reparto que necesite redondeo. No inventes una fuente documental: identifica como conocimiento de dominio todo contenido añadido.Ejemplo 4: generar desde un documento sin perder trazabilidad
Con una guía, un capítulo o un manual, la petición debería exigir referencias precisas. “Basado en el documento” es demasiado vago si luego no podemos localizar de dónde salió una respuesta.
Usa $qti-question-bank-generator con el documento adjunto.
Audiencia: alumnado de segundo curso.
Cantidad: 20 preguntas.
Tipos: opción múltiple, verdadero/falso, respuesta múltiple y emparejamiento.
Idioma: español.
Destino: Canvas mediante QTI 2.1.
Requisitos:
- Cita la sección o fragmento fuente que respalda cada ítem.
- No evalúes contenidos ausentes del documento.
- Crea primero el blueprint.
- Genera en dos lotes de 10 y valida cada lote.
- Produce Markdown para revisión humana.
- Mantén el banco en draft y no construyas el paquete QTI hasta recibir mi aprobación.Ejemplo 5: revisar un banco que ya existe
La skill no solo genera. También puede actuar como una segunda lectura sobre un banco canónico: buscar ambigüedades, respuestas discutibles, distractores débiles, desajustes con los objetivos o campos estructurales incompletos.
Usa $qti-question-bank-generator para revisar bank.json.
Comprueba por separado:
1. Calidad pedagógica: alineación, ambigüedad, pistas involuntarias, distractores y feedback.
2. Calidad estructural: esquema, identificadores, puntuaciones, respuestas y referencias.
3. Interoperabilidad: tipos que no conservarían su semántica en Moodle XML y QTI 2.1.
No modifiques el archivo todavía. Devuélveme un informe priorizado con errores, advertencias y propuestas de corrección. Distingue claramente entre validación determinista y juicio pedagógico.Ejemplo 6: corregir, aprobar y exportar
La conversación no termina cuando aparecen las preguntas. El siguiente mensaje debería registrar las correcciones y solo después autorizar el cambio de estado y los artefactos de importación.
Aplica estos cambios al banco en draft:
- Reescribe el ítem SEC-004: admite dos respuestas defendibles.
- Sustituye el distractor C de SEC-007 por un error conceptual plausible.
- Reduce la dificultad de SEC-011.
- Añade feedback específico a las respuestas incorrectas de SEC-013.
Valida de nuevo el JSON y muéstrame los cambios. No exportes todavía.Cuando la revisión ya está cerrada, la aprobación debe ser explícita:
Apruebo esta versión del banco.
Cambia su estado según el contrato del modelo y exporta:
- JSON canónico.
- Markdown de revisión final.
- Moodle XML.
- QTI 2.1.
Verifica los XML y el paquete QTI. Incluye el resultado de validación, los supuestos, cualquier ítem omitido y una lista breve de pruebas que debo ejecutar en Moodle 5.0 y Canvas antes de usarlo en producción.“El ZIP se abre” no es el criterio de aceptación. La salida queda estructuralmente validada, no certificada. Hay que importar una muestra en la versión exacta del LMS, responderla como estudiante, revisar puntuación y feedback y, si es posible, volver a exportarla para comparar qué semántica ha sobrevivido.
Una plantilla reutilizable
Los ejemplos cambian de entrada, pero comparten una estructura. Esta plantilla basta para la mayoría de los casos:
Usa $qti-question-bank-generator.
Entrada: [documento, texto pegado, pregunta guía, objetivos o bank.json]
Audiencia: [...]
Nivel: [...]
Idioma: [...]
Cantidad de ítems: [...]
Objetivos o evidencias: [...]
Tipos de pregunta: [...]
Dificultad y Bloom: [...]
LMS y versión: [...]
Formatos finales: [...]
Restricciones de accesibilidad o contenido: [...]
Primero crea el blueprint si habrá más de cinco ítems.
Genera en lotes de 5 a 15 y valida cada lote.
Mantén el banco en draft.
Entrega Markdown o CSV para revisión humana.
No exportes al LMS hasta que lo apruebe explícitamente.
No transformes ni omitas interacciones incompatibles sin informarme.No es un prompt mágico. Es un contrato de trabajo. La diferencia es que cada petición deja claro dónde entra el criterio humano, qué debe validar el código y cuándo está permitido construir el archivo final.
Qué demuestra esta versión de los bancos de preguntas con IA
La versión 1.0 incluye un banco de demostración con siete ítems y quince puntos. Cubre varios tipos de pregunta y pasa la validación con cero errores y cero advertencias. Es una base pequeña, pero suficiente para comprobar el circuito completo.
La suite automatizada protege cinco comportamientos que no quiero dejar a la memoria del modelo:
- El banco de ejemplo valida sin errores ni advertencias.
- Todos los exportadores crean los archivos esperados.
- Una elección única sin respuesta correcta se rechaza.
- Un ítem que referencia un objetivo inexistente se rechaza.
- Una ordenación no se exporta silenciosamente a Moodle.
Asimismo, los paquetes QTI se abren como ZIP, incluyen manifiesto, declaran recursos existentes y contienen XML bien formado. Moodle XML también pasa por un parser. Es la diferencia entre “parece un archivo” y “cumple las invariantes que hemos decidido comprobar”.
Esto demuestra integridad estructural local, no certificación oficial ni compatibilidad universal. La siguiente capa de pruebas debe realizarse importando bancos en versiones concretas de Moodle, Canvas y otros LMS.
Lo que falta antes de hablar de compatibilidad real
Los tests locales ya demuestran que el banco conserva las invariantes que hemos decidido comprobar. Eso es necesario. Pero todavía no responde a la pregunta que importa fuera del repositorio: ¿qué ocurre cuando el paquete entra en una versión concreta de un LMS real?
Por supuesto, añadir otro exportador haría la lista más vistosa. No haría la skill necesariamente mejor. Antes prefiero cerrar cuatro huecos menos llamativos y bastante más útiles.
- Construir una matriz de compatibilidad real. Un banco de referencia por interacción, importado y respondido en versiones concretas de Moodle y Canvas. La ficha debe incluir fecha, versión, resultado y pérdida observada.
- Mejorar la revisión humana. Markdown y CSV son un comienzo. Una interfaz que permita comentar, aprobar y comparar cambios reduciría la barrera para equipos docentes no técnicos.
- Observar cada exportación. El informe de ejecución debe registrar ítems exportados, omitidos, advertencias, versión del exportador, destino y decisiones tomadas.
- Probar el viaje de vuelta. Importar, volver a exportar desde el LMS y comparar la semántica, no solo los bytes.
No espero igualdad byte a byte. Busco algo más importante: saber qué significado se conserva, cuál se transforma y cuál desaparece.
La compatibilidad deja de ser marketing cuando lleva al lado una versión, una fecha y una prueba reproducible.
Límites de los bancos de preguntas con IA
Una primera versión útil no es la que promete cubrirlo todo. Es la que marca con precisión dónde termina. Hoy la skill no implementa:
- puntuación parcial avanzada para todas las interacciones;
- Computer Adaptive Testing;
- Portable Custom Interactions;
- Results Reporting;
- empaquetado completo de recursos multimedia;
- perfiles específicos de cada proveedor;
- certificación de conformidad 1EdTech;
- validación automática de la veracidad de cualquier dominio;
- sustitución de la revisión docente o del juicio experto.
Del mismo modo, tampoco la usaría como una tubería automática para publicar evaluaciones de alto impacto, certificaciones reguladas o pruebas clínicas, legales o de seguridad crítica. En esos contextos hacen falta controles institucionales, especialistas de dominio y una trazabilidad bastante más exigente. Poner ese límite no hace más débil el proyecto. Evita que parezca fiable justo donde todavía no lo es.
Seis atajos que salen caros
Durante la construcción aparecieron varios atajos tentadores. Casi todos ahorran minutos al principio. Y los cobran con intereses cuando el banco crece.
Pedir muchas preguntas con una fuente insuficiente
Cuando la fuente no sostiene el número solicitado, el modelo empieza a rellenar huecos con aplomo. La salida correcta es reducir alcance, marcar los ítems dudosos o pedir otra fuente. Inventar profundidad sigue siendo inventar.
Confundir dificultad con redacción complicada
Una pregunta difícil no necesita sonar como un contrato. La dificultad debe salir de la tarea cognitiva y del contenido, no de una redacción hostil.
Generar distractores absurdos
Un distractor útil representa una confusión razonable. Si tres opciones son disparatadas, no estamos midiendo comprensión. Estamos midiendo quién sabe descartar.
Redactar el XML directamente con el modelo
Puede funcionar una vez. Quizá diez. El problema aparece cuando hay que probarlo, mantenerlo y ampliar formatos sin romper los anteriores. El modelo canónico y los exportadores recortan esa variabilidad.
Tratar todos los QTI como equivalentes
QTI 2.1, QTI 2.2 y QTI 3.0 no son pegatinas intercambiables. Los LMS tampoco implementan las mismas partes. La compatibilidad se declara por destino y se demuestra con ejemplos.
Considerar terminado el banco al exportarlo
El ZIP es un artefacto, no la meta. El banco termina cuando alguien lo ha revisado, importado, visto en pantalla y probado como estudiante.
La automatización reduce trabajo mecánico, no elimina la responsabilidad sobre la evaluación.
El patrón que me llevo a otros recursos educativos
El banco de preguntas es solo un caso visible. El patrón sirve para cualquier recurso en el que el significado importe más que el formato final:
- rúbricas con un modelo canónico y exportadores;
- resultados de aprendizaje y mapas de competencias;
- actividades H5P;
- paquetes SCORM;
- credenciales y evidencias;
- contenidos LTI o flujos de evaluación conectados.
En todos esos casos, el salto de calidad llega al dejar de pedir la salida final directamente al modelo. Primero diseñamos una representación intermedia. A continuación, añadimos reglas de validación y adaptadores por plataforma. De este modo, la IA deja de ser una impresora de texto y pasa a trabajar dentro de un sistema.
La IA educativa escala mejor cuando genera objetos gobernados, no únicamente texto.
Conclusión: los bancos de preguntas con IA no terminan en el ZIP
Conseguir que una IA redacte veinte preguntas ya no es la parte difícil. La parte difícil es poder defender las veinte.
Hay que demostrar de dónde sale cada ítem, qué objetivo evalúa, quién lo ha revisado, qué formato puede representarlo y qué ocurre al importarlo en una versión concreta del LMS.
QTI Question Bank Generator intenta acortar esa distancia. No sustituye al docente ni promete compatibilidad universal. Construye un camino verificable entre una fuente educativa y un banco que puede revisarse, versionarse, exportarse y probarse.
La decisión más importante no fue elegir QTI o Moodle XML. Fue separar el razonamiento pedagógico de la serialización técnica y conservar una fuente de verdad independiente del destino.
Al principio del artículo, el archivo se importaba sin errores y parecía terminado. Ahora sabemos que aquello solo demostraba una cosa: el LMS había entendido su estructura.
Faltaba comprobar si la evaluación seguía diciendo lo que nosotros creíamos que decía.
Preguntas frecuentes sobre bancos de preguntas con IA
¿La skill genera directamente Moodle XML y QTI?
No desde el contenido libre. Primero crea un JSON canónico, lo valida y después utiliza exportadores deterministas para producir Moodle XML, QTI 2.1, QTI 3.0 y otros formatos.
¿Qué formato debería utilizar para Canvas?
La salida orientada a Canvas en esta skill es QTI 2.1. Canvas New Quizzes documenta importaciones QTI 1.2 y 2.x, aunque algunos tipos o extensiones de terceros pueden no ser compatibles. Por eso hay que probar el paquete en la instancia concreta.
¿Por qué generar también QTI 3.0?
QTI 3 representa la evolución moderna del estándar y mejora aspectos de presentación, accesibilidad e interoperabilidad web. Sin embargo, generar QTI 3.0 no implica compatibilidad garantizada en Canvas.
¿La validación técnica garantiza que las preguntas sean buenas?
No. La validación detecta problemas estructurales y de consistencia. La exactitud, la dificultad, la alineación y la calidad de los distractores requieren revisión pedagógica humana.
¿Qué ocurre si un formato no soporta un tipo de pregunta?
La exportación se detiene por defecto. Puede configurarse para omitir el ítem, pero la skill registra el elemento excluido y no lo transforma silenciosamente en otro tipo.
¿Puedo instalarla en Claude Code?
Sí. La carpeta puede copiarse en ~/.claude/skills para todos los proyectos o en .claude/skills dentro de un repositorio concreto.
Referencias externas
- Repositorio de QTI Question Bank Generator en GitHub
- Patricio Iturraspe: Cómo armé 70+ skills para Claude
- Claude Code: Extend Claude with skills
- Agent Skills specification
- 1EdTech: Question & Test Interoperability
- Canvas: importar un quiz desde un paquete QTI
- Canvas: importar preguntas QTI en un Item Bank
- MoodleDocs: Moodle XML format
Prueba la skill, revisa el código y llévala a tu LMS
He publicado QTI Question Bank Generator para que el proceso no se quede en la teoría de este artículo. Puedes descargarlo, instalarlo, ejecutar sus pruebas y revisar cada decisión técnica directamente en GitHub.
Accede al repositorio qti-question-bank-generator-skill en GitHub
Esta sigue siendo una primera versión: la validación es estructural, no una certificación oficial ni una garantía de compatibilidad universal. Por eso, el siguiente paso no es confiar en el ZIP. Es probar una muestra en la versión exacta de Moodle, Canvas o el LMS de destino, revisar el resultado y documentar cualquier diferencia.
Si encuentras una incompatibilidad, un tipo de pregunta mal representado o una mejora útil, puedes abrir una incidencia o proponer un cambio en el repositorio. Esos casos reales son los que harán crecer la matriz de pruebas.
La IA educativa útil no es la que produce más preguntas. Es la que nos permite construir evaluaciones que podamos explicar, revisar y defender.
Deja una respuesta