Cambiar de modelo de IA sin perder el comportamiento de una integración educativa

Imagina una integración que ayuda al profesorado a preparar actividades. Lee materiales autorizados, propone una estructura y, cuando recibe aprobación, crea un borrador en el curso correspondiente. El equipo encuentra un modelo que redacta mejor y quiere sustituir el actual.

La comparación de respuestas parece favorable. Sin embargo, la integración también depende de que el modelo pida aclaraciones cuando falta el curso, utilice la herramienta adecuada y se detenga antes de ejecutar una acción que todavía no está aprobada. Una mejora en redacción no permite dar por conservados esos comportamientos.

Antes de hacer la sustitución hay que decidir qué debe seguir funcionando y cómo se comprobará. El ejemplo de este artículo es hipotético; el banco de casos que lo acompaña es una propuesta de trabajo, no una comparación ejecutada entre proveedores.

Separar lo que puede mejorar de lo que debe cumplirse

La claridad de una explicación, su adecuación al nivel del grupo o la utilidad de una actividad admiten grados y requieren criterio pedagógico. En cambio, crear una actividad en otro curso incumple una condición concreta, aunque el texto generado sea excelente.

No mezclaría esas dos clases de resultado en una única nota. Una media puede ocultar que un candidato redacta mejor y, al mismo tiempo, provoca efectos que la integración no debe permitir.

Definiría primero las condiciones obligatorias del recorrido: actuar sobre el curso autorizado, utilizar la versión aprobada y respetar el límite entre preparar y ejecutar. Después compararía las dimensiones de calidad para las que exista una rúbrica comprensible. El equipo responsable del uso educativo debe poder discutir esa rúbrica y revisar ejemplos de lo que se considera suficiente.

Estas condiciones tampoco deberían descansar solo en el comportamiento del modelo. Si la aprobación es necesaria, la herramienta que ejecuta debe comprobarla. La evaluación sirve para detectar cómo se comporta el conjunto, incluido el control que rechaza una llamada improcedente.

El banco necesita situaciones que cambien la decisión

Una colección de peticiones fáciles confirma que el recorrido habitual sigue disponible. Hace falta incorporar también entradas que obliguen a aclarar, rechazar o esperar.

El banco descargable de ocho casos recoge situaciones de preparación, autorización, fallo y ejecución legítima. Es una plantilla con resultados vacíos: exige concretar el estado inicial y los comprobadores antes de ejecutarla. Estos son algunos de sus casos:

El banco debe incluir también solicitudes legítimas que sí puedan completarse. Un sistema que rechaza cualquier acción puede superar varias pruebas de contención y resultar inútil para el profesorado.

Para cada caso guardaría la entrada, el rol, los datos que puede consultar, el estado inicial del curso, las herramientas disponibles y el resultado esperado. Sin esas condiciones es difícil saber si dos ejecuciones están respondiendo al mismo problema.

Diseño de comparación: superar los casos definidos no demuestra equivalencia universal. El banco descargable aún no contiene resultados de modelos.

Ver a tamaño originalCerrar

Fijar la versión del sistema que se compara

Cambiar el modelo puede exigir adaptar instrucciones, esquemas o tratamiento de errores. Es una adaptación legítima, pero entonces ya no estamos midiendo exclusivamente la sustitución del modelo: comparamos dos configuraciones del sistema.

El registro debe conservar el identificador efectivo que devuelve o permite fijar el proveedor, la fecha, los parámetros relevantes, las instrucciones, las descripciones de herramientas y las fuentes utilizadas. Un nombre comercial sin esos datos puede dejar la comparación irreproducible.

También importa registrar si una prueba utiliza respuestas simuladas de las herramientas o modifica una plataforma de ensayo. La simulación permite controlar fallos; no demuestra que el servicio externo responda igual en una integración real. Para comprobar el efecto final hace falta observar el estado de destino.

La ingeniería del sistema de IA explica por qué el comportamiento depende de más componentes que el modelo. Este banco convierte esa dependencia en casos que puedan ejecutarse y revisarse antes de una sustitución.

Leer los resultados sin esconder las diferencias

Para cada candidato conservaría el resultado de cada ejecución, las llamadas realizadas y la comprobación del estado final. Cuando el comportamiento pueda variar, repetiría los casos bajo unas condiciones y un número de ejecuciones fijados de antemano. Elegir después solo los ejemplos favorables invalida la comparación.

Las comprobaciones deterministas pueden verificar un identificador de curso, una llamada prohibida o la ausencia de un cambio. La calidad pedagógica necesita revisar el contenido con una rúbrica; un evaluador automático puede ayudar, pero su acuerdo con el criterio humano también debe comprobarse. Usar otro modelo para puntuar no vuelve objetiva la valoración.

El informe debería mostrar qué empeora, qué mejora y qué queda sin comprobar. Si una llamada indebida es rechazada por el servidor, conviene registrar tanto el intento como la eficacia del control. Que no se produzca el efecto no significa que el modelo haya interpretado correctamente el límite.

Los costes y la latencia se comparan para el recorrido aceptado, incluidos reintentos y revisión necesaria. El precio de una llamada aislada puede favorecer a un candidato que exige más trabajo para conseguir una actividad utilizable.

Del banco al uso limitado

Si aparece un incumplimiento de una condición obligatoria, hay que corregir o justificar el diseño antes de desplegar. Cuando los resultados satisfagan el alcance acordado, el siguiente paso puede ser un piloto limitado con observación y una forma de volver a la configuración anterior.

Volver al modelo anterior no deshace actividades ya creadas ni comentarios enviados. La reversión debe distinguir el cambio de configuración de los efectos que haya producido el sistema durante el piloto. La recuperación de una automatización interrumpida desarrolla el caso en el que el efecto existe, pero se ha perdido su confirmación.

El banco necesita evolucionar con las incidencias y con las nuevas funciones, conservando un núcleo que permita comparar versiones. Así el cambio de proveedor deja de depender de que unas respuestas parezcan mejores: el equipo puede decidir qué conserva, qué acepta cambiar y qué todavía no está dispuesto a delegar.