Sistema de Asistencia Académica Inteligente

Mirar lo que ya está

Este no es un día de funcionalidad nueva. Es el día en que la plataforma se recorrió entera, pantalla por pantalla, con una sesión real y no con pruebas automáticas.

Esa distinción importa, y ya había dado una lección antes en este proyecto: las pruebas comprueban que el programa hace lo que se le pidió, y no tienen forma de saber que lo que se le pidió resulta incómodo de usar. Los seis defectos que salieron hoy tenían todas las comprobaciones en verde.

Seis cosas que estorbaban

Los nombres de los materiales no se leían. La lista ocupaba 883 píxeles de ancho dentro de un hueco de 561, así que para leer el nombre completo de un archivo había que desplazar la lista de lado. La causa es una regla de maquetación que, sin una indicación concreta, deja que una lista crezca todo lo que quiera en vez de recortar los nombres largos.

Cambiar de pantalla la dejaba abierta por la mitad. Si se venía de una pantalla larga que se había bajado hasta el final, la siguiente aparecía con su título por encima del borde: parecía que le faltaba la cabecera. El navegador normalmente se encarga de esto solo, pero aquí lo que se desplaza no es la ventana sino el panel de contenido, y de ese no se encarga nadie.

El estado del aula virtual salía donde no venía a cuento. Ocupaba unos 180 píxeles en las cinco pestañas del curso: también sobre la lista de estudiantes, y también sobre el botón que elimina el curso. Habla de los temas y los materiales, así que ahora acompaña solo a eso.

Dos pestañas distintas enseñaban lo mismo. «Miembros» y «Padrón» mostraban el mismo formulario con el mismo título, de modo que cambiar de una a otra parecía no cambiar nada. El formulario es realmente el mismo —y debe serlo, porque una sola operación reparte los correos entre las dos listas—, pero ahora cada pestaña lo titula por lo que se va a hacer con él.

Un aviso de tres líneas se repetía en cada archivo. En un curso con diez documentos del mismo tipo aparecían diez copias del mismo párrafo, y lo que se perdía de vista era precisamente cuál de los diez lo tenía. Ahora en la lista es una etiqueta de dos palabras, con el texto completo al pasar por encima, y sigue dicho entero en la pantalla del documento, que es donde hace falta leerlo.

Tres pantallas pegaban su título al borde del menú. Eran las únicas sin margen, y se notaba.

Las explicaciones no se borraron: cambiaron de sitio

Esta plataforma explica mucho, y lo hace a propósito: hay cosas que son verdad, sorprenden, y callarlas sería mentir por omisión —que nada se actualiza solo, que un recuento sale de un sitio y otro de otro, qué le pasa a la lista de estudiantes si se carga en el orden equivocado—.

El problema no era lo que dicen, sino dónde estaban: delante de los controles. Eso obliga a leer un párrafo para encontrar un botón, y tiene un efecto que se vuelve en contra de lo que se buscaba —a la décima visita ya nadie los lee, los salta, y al saltarlos se salta también la línea de encima, que es la única que había cambiado—.

No se ha quitado ni una frase. Todas están donde estaban, a un clic, bajo la pregunta que lleva a alguien a buscarlas: «¿por qué no se actualiza solo?», «¿cómo se lee el archivo?». La pantalla abre por donde se trabaja, y quien necesita el porqué lo despliega.

Y hay una excepción escrita a conciencia: los avisos no se pliegan. El que recuerda asignar el grupo antes de cargar la lista de estudiantes y el que advierte de que un archivo de exportación lleva datos personales siguen a la vista, siempre, porque cambian lo que alguien está a punto de hacer y uno de los dos no tiene vuelta atrás.

El color

Hasta hoy los cursos eran indistinguibles entre sí: cinco tarjetas iguales en la portada y cinco iconos iguales en el menú. Ahora cada curso tiene su color, y ese color se calcula a partir de su código —no lo elige nadie, no hay que configurarlo y no ocupa sitio en ninguna base de datos—.

Se calcula del código y no de un identificador interno, y eso tiene una consecuencia buscada: la misma asignatura conserva su color de un semestre a otro y entre sus distintas secciones. El color contesta «qué asignatura es esta», que es lo que se busca de un vistazo en una lista; de qué sección se trata ya lo dice el texto de al lado.

Los colores se construyen en un espacio donde la claridad es la que percibe el ojo y no un número que significa cosas distintas según el tono. Dicho sin tecnicismos: en el sistema habitual, un amarillo y un azul descritos con la misma cifra de claridad se ven completamente distintos —uno deslumbra y el otro es casi negro—, así que una regla única habría dejado ilegibles a unos cursos y apagados a otros. Aquí los veinticuatro tonos pesan lo mismo en pantalla, y el contraste del texto se garantiza una sola vez para todos.

Los tonos se mantienen además deliberadamente suaves: el rojo intenso está reservado en esta plataforma para una sola cosa —lo que no se puede deshacer—, y ningún curso debe competir con él.

Un error que solo se vio mirando

El primer intento pintó los cinco cursos del mismo azul, con todas las comprobaciones en verde y el cálculo del tono funcionando correctamente: cada curso tenía su número de color bien calculado, y aun así todos salían iguales.

El motivo era una regla del lenguaje de estilos poco intuitiva: un color definido en términos de una variable se resuelve en el sitio donde se define, no en el sitio donde se usa. Definido una vez para toda la plataforma, se quedaba con el valor por defecto para siempre.

Se corrigió, y el porqué quedó escrito en los dos sitios donde alguien podría intentar «simplificarlo» de vuelta al error.

Lo que todavía no está resuelto

• Dos cursos pueden compartir color. Con veinticuatro tonos y cinco cursos, dos de ellos coincidieron. Se probaron repartos más finos —treinta, treinta y seis, cuarenta y ocho y sesenta tonos— y todos daban colores distintos pero amontonados en la misma zona: con treinta, los cinco cursos salían en distintos azules, que se distingue peor que una coincidencia franca. Es una consecuencia inevitable de calcular el color sin consultar a nadie más, y evitarla exigiría que el color dependiera de la lista de cada persona: entonces un curso cambiaría de color según quién lo mire, y se perdería justo lo que lo hacía útil.
• El modo oscuro no tiene interruptor. Los colores nuevos tienen su versión oscura y se comprobó que funciona, pero todavía no hay forma de activarlo desde la propia plataforma.
• El nombre de la cuenta llega en mayúsculas desde la cuenta institucional, y la portada saluda gritando. Viene del perfil, no de la plataforma, pero se ve.

Siguiente paso

Repetir este mismo recorrido con una sesión de estudiante, que es la que va a usar la mayoría y la única que todavía no se ha mirado pantalla por pantalla.

Qué cambió

Hasta hoy, incorporar un curso del aula virtual al sistema era trabajo de quien sabe escribir instrucciones técnicas: había que buscar un número en la dirección del curso, redactar una orden a mano y ejecutarla en una consola. Traer sus archivos, lo mismo. Y una parte del material —lo que el docente escribe directamente en el aula, los avisos y los resúmenes de cada semana— entraba al sistema pero no se podía leer desde ninguna pantalla.

Las tres cosas se arreglaron. Pero la que más importa no estaba en la lista.

Un material puede tener su texto listo y no servir de nada

El asistente solo puede citar material que esté en su índice de búsqueda. Y tener el texto no es estar en el índice: son dos pasos, y el segundo puede quedarse a medias sin que falle nada.

Contando el material curso por curso apareció un documento con su archivo guardado, su texto extraído entero y sin índice. No había ningún error registrado: la extracción había terminado bien y la pantalla decía que su texto estaba listo. Pero ese documento el asistente no lo podía citar, y nadie tenía forma de saberlo.

Ahora cada material lo dice. Y el aviso usa el mismo criterio con el que el sistema decide qué material hay que rehacer, y no una aproximación parecida: la pantalla afirma exactamente lo que el sistema va a hacer.

El aviso se encendió donde no debía, y eso es lo que se aprendió

Con todas las comprobaciones automáticas en verde, el aviso nuevo salía en los 66 materiales de un curso donde 63 estaban perfectamente indexados. El motivo era sutil: el programa preguntaba «¿la fecha de indexado está vacía?» y daba por vacía también la respuesta de un servicio que todavía no enviaba ese dato. Un dato que no llega no significa «no indexado»: significa «no lo sé».

Se corrigió separando los tres casos, y el criterio que queda escrito es el que importa: un aviso que grita cuando no sabe enseña a no mirarlo, y entonces deja de servir el día que tiene razón.

Solo se vio abriendo la pantalla. Ninguna prueba automática lo habría encontrado, porque todas pasaban.

Conectar un curso y traer su material

Conectar un curso es ahora un campo más al darlo de alta: si se rellena con el identificador que el aula virtual muestra en la dirección del curso, el sistema se conecta y trae su estructura de semanas. El campo explica de dónde sale ese número —hay que copiarlo a mano, porque el permiso que la facultad concedió al sistema permite leer un curso concreto pero no listar el catálogo— y avisa de algo que antes no decía nadie: un curso creado sin esa conexión ya no se puede conectar después.

Traer los archivos tiene botón, y antes de arrancar dice cuántos son y cuánto pesan. Que no arranque solo es deliberado: descargar cientos de megabytes es una decisión, y quien la toma debe poder tomarla a la vista del tamaño. Lo que faltaba era justamente eso, el sitio donde tomarla.

La pantalla dice además dos cosas incómodas y ciertas: que el detalle minuto a minuto se pierde si el servicio se reinicia —aunque los archivos ya traídos no se pierdan— y que nada de esto se actualiza solo: si el docente sube algo nuevo al aula virtual, alguien tiene que pedirlo.

Lo que todavía no está resuelto

• El servidor del sistema se quedó sin camino hacia el aula virtual a media tarde. Al mediodía sincronizaba con normalidad. Desde fuera de la red de la universidad el aula responde en dos décimas de segundo; desde el servidor, los paquetes se pierden dentro de la propia red interna. No es un fallo del sistema ni del permiso concedido, pero mientras dure no se puede conectar ningún curso nuevo ni traer ningún archivo. Queda planteado junto al resto de peticiones de red pendientes.
• Nada avisa cuando eso pasa. No hay registro de sincronizaciones fallidas ni de descargas pedidas, así que un corte largo se descubre mirando, no recibiendo un aviso. Con la intervención en marcha, eso hay que resolverlo.
• Queda decidir qué hacer con los avisos del tablón. Los textos que el docente escribe en el aula —«¿dudas?, ¿preguntas?», el encabezado de una semana— entran hoy como material y se pueden citar. Son unas pocas decenas de caracteres cada uno y compiten con capítulos enteros. Poder leerlos era el paso previo para decidirlo; la decisión es del responsable del proyecto y está escrita como tal.

Siguiente paso

Que vuelva el camino hacia el aula virtual para probar de punta a punta lo que hoy solo se ha podido comprobar con lo ya importado: conectar un curso nuevo y traer sus archivos.

Qué cambió

La entrada anterior dejó al asistente respondiendo con fuente. Lo de hoy es lo que hay alrededor: que el material se busque sin ruido, que las conversaciones no se pierdan, y que el estudio con el que se va a medir todo esto se pueda montar de verdad, con reparto de grupos y con los datos saliendo en un archivo.

Los carteles del aula ya no ganan las búsquedas

Un aula virtual no solo tiene documentos: tiene carteles, esas líneas que el docente coloca para separar semanas y que dicen «ACTIVIDADES» o «MATERIAL FORMATIVO». El sistema los estaba tragando como si fueran material. Eran 23, con una media de 25 caracteres, y ocho de ellos decían solo una palabra.

No era un detalle estético. Una consulta real —pedir el material formativo del curso— devolvía cuatro veces el mismo cartel con una puntuación de 0,6471, muy por encima del umbral de 0,40 que el sistema usa para decidir si tiene algo que decir. Es decir: el asistente contestaba con seguridad usando un cartel vacío. Hoy esas dos consultas se abstienen, que es la respuesta correcta.

El límite a partir del cual un texto cuenta como material se fijó en 40 caracteres, y se eligió midiendo: el separador más largo del curso tiene 18 caracteres y el texto con contenido más corto tiene 65, así que entre esos dos números no hay nada que perder. No se puso más alto a propósito, porque un límite de 250 habría borrado un resumen de 111 caracteres que es la única instrucción escrita a mano por un docente que existe en el curso. El filtro se dejó deliberadamente estrecho: nunca toca un texto que una persona haya validado ni nada que el asistente ya haya citado.

Las conversaciones se conservan y se pueden revisar

Se puede abrir un chat nuevo y volver a cualquiera de los anteriores, cosa que antes no. Al construirlo apareció un fallo que ya estaba causando daño en silencio: la pantalla pedía la conversación más reciente y solo esa, así que 12 mensajes repartidos en 3 conversaciones estaban fuera de alcance. Volvieron a verse.

Los roles por encima del estudiante pueden leer y analizar esas conversaciones. Para que leer no contaminara lo que se va a medir se usó un testigo fuerte: el contador interno de la evidencia avanza incluso si una escritura se deshace, de modo que si la lectura escribiera algo, el contador lo delataría. Cuatro pasadas de lectura y no se movió.

También se corrigió la redacción asistida de la guía del tema, que hasta hoy pisaba sin avisar lo que el docente hubiera escrito. Ahora produce un borrador y el docente elige entre reemplazar, añadir al final o descartar. Se comprobó dejando una guía escrita a mano antes de pedir el borrador: quedó idéntica.

El reparto de los grupos, con constancia

Un estudio con grupo experimental y grupo de control necesita que alguien diga qué sección es cuál. Esa pieza no existía: la tabla llevaba semanas vacía y no había forma de escribirla.

Ahora existe, y con tres decisiones que importan más que la pantalla. El reparto es por sección entera y nunca por estudiante, como exige el proyecto aprobado. El interruptor que enciende el asistente en una sección ya no se puede tocar por separado: se deriva del reparto, en la misma operación, así que no puede haber una sección con el asistente encendido y sin grupo asignado. Y cada reparto deja una fila en una constancia que solo admite escribir: se intentó borrar una y la base de datos respondió con su propio mensaje de error, negándose.

Escribirla dejó a la vista el estado real, que es el motivo de que esto sea urgente: hay tres secciones con el asistente encendido y ninguna con grupo asignado, y una de ellas arrastra ya cuatro conversaciones registradas sin grupo, que asignarlo ahora no repara. El orden correcto es reparto primero, lista de estudiantes después.

La lista de estudiantes se carga desde un archivo

Ya no hay que pegar los correos a mano. Tolera lo que trae de verdad una lista universitaria —marcas invisibles al principio del archivo, separadores mezclados, nombres con coma entre comillas, el formato de nombre con el correo entre ángulos— y enseña qué entendió antes de enviar nada. El rechazo que más vale es el de una fila con dos direcciones de correo: no elige, avisa. En una lista universitaria esa fila es lo normal, y elegir mal significa convocar a alguien que nunca podrá entrar.

Los datos salen en dos archivos

El último instrumento de la investigación era una exportación, y estaba especificada sin construir. Hoy son dos archivos de hoja de cálculo: uno con una fila por intervención y otro con una fila por cita, que se cruzan entre sí. Se generaron sobre datos verdaderos y las cuentas cuadran entre los dos archivos.

Dos decisiones de fondo. El archivo sale identificado, con nombre y correo, porque el diseño de la investigación lo exige y no porque sea lo cómodo de programar. Y aun así el identificador de sesión no sale: se comprobó que no aparece en ningún byte de los archivos generados, porque exportar ese dato no entrega un dato más, entrega la capacidad de entrar a leer la conversación desde fuera.

Sin pedir una sección concreta, el archivo sale vacío. No es un fallo: el alcance por omisión es el estudio, y el estudio todavía no tiene ninguna sección repartida. El archivo está diciendo la verdad.

Lo que todavía no está resuelto

• El sorteo de las secciones no es trabajo de programación. El sistema ya sabe registrarlo; hace falta decidir qué sección es cuál, con qué procedimiento y quién lo firma. Bloquea el experimento entero.
• La pantalla que recoge el consentimiento está por construir. Hoy el sistema da por dado que el estudiante aceptó, y eso tiene que dejar de ser un supuesto del código para convertirse en un paso explícito y registrado antes de que el estudio empiece a medir. Es un requisito previo, no una tarea pendiente más.
• Que el estudiante sepa que su docente lee sus preguntas cambia cómo pregunta. Eso actúa sobre lo que el estudio mide, así que tiene que documentarse como característica del diseño y comunicarse igual a los dos grupos, o el sesgo deja de ser parejo y rompe la comparación.
• Ningún servicio arranca solo tras un reinicio, y la búsqueda depende de una sola máquina con tarjeta gráfica.

Siguiente paso

Cerrar los dos bloqueos que no son código —el sorteo y el consentimiento— porque sin ellos el semestre corre sin poder medirse, y dejar los servicios arrancando por su cuenta antes de que el estudio dependa de que alguien los levante a mano.

Qué cambió

Hasta hoy el asistente conversaba, pero quien escribía la respuesta era un sustituto de pruebas: una pieza que imitaba a la inteligencia artificial para poder construir todo lo demás sin depender de ella. Hoy responde un modelo real, y responde sobre el material del curso.

La diferencia se nota en una sola línea de cada respuesta. Si el estudiante pregunta algo que el material del curso explica, el asistente contesta y dice de dónde lo sacó: el documento y la página. Si pregunta algo que el material no explica, dice que no lo encuentra en el material del curso, en vez de ofrecer una respuesta verosímil salida de ninguna parte.

Esas dos conductas son el objetivo del proyecto, no un adorno. Un asistente que responde sin fuente obliga al estudiante a creerle, y un asistente que nunca se abstiene acaba enseñando cosas que el curso no dice.

Cómo se comprobó

No se dio por buena la respuesta porque pareciera buena. Se hizo lo contrario: se tomó la cita que el asistente puso al final —un documento y un número de página—, se abrió ese documento en esa página y se leyó. La página 167 dice lo que la respuesta decía que decía.

Es una comprobación de una sola respuesta y no sustituye a la evaluación, pero es la que distingue una cita de verdad de una cita inventada, que es el fallo típico de estos sistemas.

El material, ya consultable

Para poder citar hay que haber leído antes. El material de un curso real quedó convertido en 17.256 fragmentos con su representación numérica, y una búsqueda sobre ellos tarda 16 milisegundos. Rápido no es lo llamativo aquí: lo llamativo es que a esa velocidad la búsqueda puede ocurrir dentro de la conversación, mientras el estudiante espera, y no como un proceso aparte.

Lo que todavía no está resuelto

Conviene decirlo, porque se midió y el resultado fue incómodo. Para saber si el material responde o no a una pregunta, el sistema se apoya hoy en una puntuación de parecido. Se evaluaron 186 preguntas con jueces que no veían esa puntuación, y los rangos se solapan: hay aciertos con puntuación baja y respuestas inútiles con puntuación alta. O sea que ningún número aislado separa limpiamente lo que el material responde de lo que no.

El corte actual se mantiene porque no descarta ni un acierto y elimina algo más de la mitad de lo inservible, pero la conclusión honesta es que abstenerse de forma fiable necesita una comprobación adicional, no un corte más exigente. Queda anotado como trabajo pendiente y no como detalle.

Siguiente paso

Terminar de traer los archivos del aula virtual de la facultad al circuito de lectura, para que lo consultable sea todo el material del curso y no una parte, y atacar esa comprobación adicional que permita abstenerse con garantías.

Qué cambió

Hasta ahora el docente subía su material a la plataforma a mano, y así estaba previsto para esta fase: conectar el sistema con el aula virtual de la institución figuraba como trabajo de una etapa posterior. Se adelantó, y el resultado es que el curso del asistente puede quedar conectado al curso real del aula virtual.

El sistema solo lee. No escribe notas, ni matrículas, ni entregas, ni ninguna otra cosa en el aula virtual de la facultad. El permiso con el que opera está limitado a esa única capacidad, que es exactamente lo que necesita y nada más.

Los dos tiempos, que no son el mismo

Un docente que acaba de publicar un archivo quiere verlo en el asistente. Conviene separar dos cosas que suenan iguales y no lo son:

• Verlo aparecer cuesta unos 320 milisegundos. Tan poco que no hace falta consultar el aula virtual cada tanto por si acaso: se consulta al abrir el curso, y hay un botón para forzarlo.
• Poder preguntarle cuesta lo que cueste convertir el documento en texto, que en un escaneo de muchas páginas son minutos. No es un problema de la conexión: es el precio de leer una imagen.

El material aparece enseguida, indicando que todavía se está procesando, y pasa a ser consultable cuando termina. Decirlo así es más honesto que fingir que todo es inmediato.

Lo que el aula virtual no puede dar

Conviene dejarlo escrito, porque es una decisión de diseño y no un detalle. El permiso con el que el sistema lee el aula virtual no da acceso al padrón de estudiantes, y está bien que así sea. La identidad de quien usa el asistente sigue saliendo del inicio de sesión institucional, y el aula virtual aporta material, no personas.

Que no se pierda nada por el camino

Dos cuidados que parecen menores y no lo son. Un material identificado por su nombre se rompe en cuanto el docente renombra el archivo; por eso cada documento se reconoce por el identificador que le da el propio aula virtual, y renombrarlo o moverlo de semana no lo convierte en otro. Y un material que el docente retira del aula virtual no se borra: se marca como retirado y se puede seguir leyendo, porque una cita que el asistente ya emitió tiene que llevar a algún sitio.

Siguiente paso

Traer los archivos y procesarlos, que es lo que los vuelve consultables. Ahí aparece el trabajo de verdad: entre el material real hay escaneos de más de cien páginas que hay que leer como imagen.

Qué cambió

El SAAI busca por significado y no por palabra exacta: para eso convierte cada fragmento de material —y cada pregunta del estudiante— en una representación numérica. Ese cálculo ocurre en la máquina que tiene la tarjeta gráfica del servidor. Hoy quedó conectada con el resto del sistema.

Trabajo realizado

• Se identificó por qué el sistema principal no lograba usar el servicio: no era un fallo del programa, que funcionaba correctamente de forma aislada, sino el cortafuegos de la máquina, que descartaba las peticiones entrantes.
• Se habilitó el acceso con el criterio de mínimo privilegio: solo el servidor de aplicación puede consultarlo, y nada queda expuesto fuera de la red interna del proyecto.
• Se verificó la ruta completa con una llamada real: la máquina de cómputo devolvió la representación numérica esperada, con la misma configuración de modelo que usará la carga de materiales.
• Se documentó esa máquina por primera vez: inventario, servicio que ejecuta, reglas de acceso y procedimiento de administración. Las otras dos máquinas del sistema ya tenían su ficha desde agosto; esta, que es la que hace el cálculo pesado, no.

Resultado

La cadena que convierte un material del curso en algo consultable queda unida de extremo a extremo, y el procedimiento para administrar la máquina de cómputo deja de depender de la memoria de quien la configuró.

Siguiente paso

Dejar el servicio arrancando por sí solo tras un reinicio, para que no dependa de relanzarlo a mano.

Qué pasó

Un día después de recuperar el acceso, uno de los dos servidores del proyecto dejó de responder otra vez por el canal privado con el que se administran a distancia, al filo de la medianoche del martes 15. Como a inicios de mes, no fue un fallo de la plataforma ni del trabajo del equipo: lo que se cortó fue el camino hasta la máquina.

Qué se hizo el jueves 17

El equipo volvió al laboratorio a revisar la conexión y restablecerla. Hacia las 17:20 el servidor respondió de nuevo y a las 17:30 los dos servidores quedaron operativos por su canal de administración.

La recuperación duró poco. El primero dejó de responder a las 17:30, minutos después de dejarlo operativo, y el segundo a las 19:29. Ninguno respondió en los días siguientes, y el calendario lo muestra en rojo desde ese mismo día.

Por qué cuenta como avance

Igual que el 14, un día de reconexión no añade ninguna función a la plataforma, pero es trabajo del proyecto: sin acceso a los servidores no hay despliegue ni pruebas donde tienen que correr. Por eso el día se muestra en verde con borde rojo: hubo el trabajo de reconectar y hubo, ese mismo día, un nuevo obstáculo externo.

Actualización del 23 de setiembre

Seis días después, uno de los dos servidores volvió a responder por su canal de administración hacia las 11:40 del martes 23, y con él se retomó el trabajo sobre la plataforma. El otro sigue sin acceso remoto.

Siguiente paso

Recuperar el acceso remoto al servidor que sigue caído. Hasta entonces, lo que quedó en espera el 14 sigue en espera.

Qué pasó

Desde el 5 de setiembre los dos servidores del proyecto dejaron de responder por el canal privado con el que se administran a distancia. No fue un fallo de la plataforma ni del trabajo del equipo: lo que se cortó fue el camino hasta las máquinas, y sin ese camino no hay despliegue, ni pruebas contra la infraestructura real, ni forma de saber desde fuera qué estaba pasando dentro.

El registro del servidor de aplicación cuenta la parte que se puede contar con datos. No hay ninguna sesión remota entre el 4 y el 14 de setiembre. El sábado 12 la máquina virtual arrancó de nuevo por la tarde, señal de que el equipo físico volvió a encenderse, pero nadie pudo entrar: el canal seguía cortado.

Qué se hizo el lunes 14

Cuando un problema no se puede resolver a distancia, se resuelve presencialmente. El equipo fue al laboratorio donde están los servidores a restablecer la conexión de red, revisando una a una las conexiones físicas. A las 17:10 volvió la primera sesión remota, y al final del día los dos servidores respondían otra vez por su canal de administración.

Por qué cuenta como avance

Un día de reconexión no añade ninguna función a la plataforma, y sin embargo es trabajo del proyecto: sin él, ninguna de las funciones siguientes se podría desplegar ni probar donde tiene que correr. Por eso el calendario lo muestra en verde con el borde rojo del bloqueo que ese mismo día terminó: hubo un obstáculo externo, y hubo también el trabajo de quitarlo.

Siguiente paso

Con el acceso recuperado, retomar lo que quedó en espera: publicar la evidencia acumulada y seguir con el recorrido de la plataforma desde una cuenta de estudiante.

Qué pasó

Al día siguiente de cerrar el ciclo de vida del curso, la plataforma se usó de verdad por primera vez desde la pantalla de un docente: abrir un curso, leer un tema, revisar el texto de un material, subir una presentación de clase. En una tarde salieron cuatro cosas. Ninguna se había visto en las pruebas automáticas, y eso es lo primero que conviene decir: las pruebas comprueban lo que se les pidió comprobar, y lo que un usuario hace con la pantalla no estaba entre ello.

Tres fallos de interfaz, corregidos el mismo día

El curso no se desplazaba. Un tema con varios materiales se cortaba por abajo sin barra de desplazamiento. El panel de lectura tenía la orden de desplazarse desde el principio; lo que no tenía era un tamaño que respetar. La fila que lo contiene se estiraba con el contenido en lugar de medir lo que sobra en la pantalla, y lo que sobresalía se recortaba en silencio. El arreglo es de una línea de estilo, pero explica algo general: un contenedor no se desplaza porque se le diga, se desplaza porque tiene un límite.

Revisar el texto de un material tapaba el PDF. Al desplegar el texto extraído debajo del documento, el visor cedía su espacio pero el documento no puede medir menos de una altura mínima, y el texto acababa pintado encima. Ahora el visor llena el panel cuando no hay nada más que mostrar y crece cuando lo hay, y es el panel el que se desplaza.

Una presentación de clase no subía, y el mensaje culpaba a quien no era. La pantalla decía «respuesta ilegible del servidor». El servidor no había respondido nada: el proxy que publica el dominio de desarrollo corta cualquier envío de más de un megabyte, que es su límite de fábrica, y devuelve una página de error que la plataforma no sabía leer. Se comprobó desde el propio servidor con dos envíos, uno de medio megabyte que pasa y otro de tres que no. El PDF que sí había subido pesaba medio megabyte, por eso nadie lo había notado. Desde ahora la pantalla dice exactamente qué límite se superó y dónde hay que subirlo.

El fallo que se escondía debajo

Al investigar el tercero apareció un cuarto, más viejo y más serio. Cuando el servicio rechaza una subida antes de recibirla entera —porque la sesión caducó, porque la ficha del material ya no existe, porque quien sube no es docente de ese curso—, la respuesta se perdía por el camino y el docente veía «el servicio no responde». Justo lo contrario de lo ocurrido: el servicio había respondido con todas sus letras.

La causa está en el nivel más bajo de la red. El servicio recibe los archivos en flujo, sin guardarlos en memoria, y por eso no lee el cuerpo hasta que alguien lo pide. Si contesta sin pedirlo y cierra la conexión con datos sin leer, el sistema operativo no cierra con cortesía: corta en seco, y ese corte descarta en el otro extremo todo lo que aún no había leído, que era precisamente la respuesta. Se reprodujo con un envío de doscientos kilobytes. No hacía falta un archivo grande; hacía falta que el servicio tuviera algo que decir pronto.

El primer intento de arreglarlo fue en el lado equivocado, en el intermediario que traduce la sesión del navegador, y no sirvió: ningún cliente puede leer lo que su sistema ya tiró. Se descartó. El arreglo está en el servicio, que ahora consume lo que quede del envío antes de cerrar. Cuesta recibir el archivo entero para decir que no, y ese coste se acota de dos formas: el tope de tamaño que ya regía las subidas, y un corte previo en el intermediario para el caso más común, la sesión ausente, donde no se envía ni un byte.

Se verificó contra el servicio real con dos clientes distintos y envíos de doscientos kilobytes a treinta megabytes: antes, corte sin respuesta en todos; después, la respuesta completa en todos. Las pruebas automáticas quedaron escritas de una forma que merece contarse. La primera versión abría una conexión de red de verdad y pasaba igual con y sin el arreglo, porque una conexión de prueba no tiene la carrera del sistema operativo. Una prueba que no distingue no protege nada, así que se reemplazó por dos que comprueban el contrato: con el arreglo, tras responder no queda nada por leer; sin él, queda el envío entero.

Una barrera que se deja escrita

El límite del proxy de desarrollo no se cambia todavía. Es una decisión, no un olvido: ese servidor no se administra desde la máquina de desarrollo, y tocarlo es un acto aparte. Queda anotado como barrera en el mapa del trabajo, con el bloque de configuración exacto listo para el día que se decida, y con la pantalla diciendo con sus palabras qué pasa mientras tanto. Hasta entonces, el material real se prueba con archivos pequeños.

Resultado

Una tarde de uso real valió más que la batería de pruebas para encontrar lo que faltaba, y dejó tres arreglos verificados, un fallo de fondo corregido en el sitio correcto y una barrera con nombre. La lección práctica queda en el plan: antes de construir el tablón, recorrer la plataforma con una cuenta de estudiante, que es lo único que sigue sin hacerse.

Siguiente paso

Ese recorrido con cuenta de estudiante, y después el tablón de anuncios.

Qué cambió

Dos cosas que la entrada anterior dejó como deuda declarada, y una que no estaba en ninguna lista hasta que se escribió el plan de esta semana.

La primera cuenta administradora existe. Hasta ayer la pantalla que reparte permisos la podía usar solo quien tuviera administración, y nadie la tenía: el arranque era un paso manual sobre la base de datos. Ese paso se dio una vez, sobre una cuenta que ya había entrado a la plataforma, y no hace falta volver a darlo. A partir de aquí nombrar a un docente es una pantalla, no una sentencia.

Un curso deja de ser solo un código y un nombre. Tiene descripción, periodo académico y sección, y con ello desaparece un límite que con un solo curso piloto nadie había notado: el código del curso era único en toda la plataforma, así que «IND-301» no se podía dictar dos semestres seguidos ni en dos secciones a la vez. Lo que identifica una edición del curso es ahora la terna código, periodo y sección. Se cambió ahora, con tres cursos dentro, porque es la clase de cambio que solo es barato mientras el segundo curso no existe.

Un curso puede terminar sin borrarse. La única salida que tenía un curso era el borrado, y el borrado se llevaba todo —temas, materiales, la lista de la sección— sin decir qué. Ahora el final normal de un curso es archivarlo: desaparece de entre los activos, queda legible para todos los que lo cursaron y nadie salvo la administración puede escribir en él. Su docente puede restaurarlo si lo archivó por error. Borrar sigue existiendo, pero pasa a ser cosa de la administración, y antes de confirmar la pantalla cuenta y nombra lo que se perdería: tantos temas, tantos materiales, tantas personas, tantas conversaciones. Un «¿estás seguro?» no es una pregunta; eso sí lo es.

Un detalle de orden que importa

Cuando un docente intenta escribir en un curso archivado, el sistema le responde que el curso está archivado y que lo restaure. Pero esa comprobación va después de la de si es docente de ese curso, no antes. La razón es que un docente ajeno al curso debe seguir recibiendo la misma negativa de siempre, la que no dice nada: si el estado se comprobara primero, por la forma de la negativa podría deducir si un curso que no es suyo está archivado o no. Es un dato pequeño, pero es un dato que no le corresponde.

Cómo se trabajó

La interfaz y el servicio viven en repositorios distintos y los construyeron dos agentes en paralelo, cada uno el suyo, contra un contrato de la API fijado por escrito antes de que ninguno empezara. La integración se verificó después sobre el conjunto: compilación, análisis estático, pruebas contra la base de desarrollo, migración aplicada y servicio reiniciado. Nada de esto se recorrió todavía en el navegador con una cuenta de estudiante; ese recorrido sigue anotado como pendiente, y es el siguiente paso antes del tablón de anuncios.

Resultado

La plataforma ya no necesita la consola para nada de su administración diaria, y un curso tiene un ciclo de vida completo: se crea, se dicta, se archiva, y solo se borra cuando alguien con administración decide, sabiendo qué se lleva.

Siguiente paso

El tablón: la primera forma que tendrá un docente de decirle algo a toda su sección desde la plataforma.

Qué cambió

Las dos piezas ya existían por separado. El archivo del docente se guardaba en el almacenamiento del servidor desde hace unos días, y el conversor que vuelve un documento en texto con sus páginas se construyó el 27 y se midió el 28. Lo que faltaba era el cable entre ambas, y sin él el docente veía siempre lo mismo: un material subido, y debajo un estado que decía «pendiente» y no cambiaba nunca. Ese texto no iba a aparecer solo, porque nadie lo estaba pidiendo.

Desde hoy, subir un archivo arranca su conversión. El docente no tiene que pulsar nada más, y la pantalla se actualiza sola mientras el trabajo ocurre.

Por qué esto tarda, y por qué eso obliga a contarlo

Convertir un material no es instantáneo. Una presentación pasa antes por LibreOffice, que puede tardar hasta cinco minutos; un escaneo pasa por reconocimiento óptico, que puede tardar veinte. Si la conversión ocurriera dentro de la subida, el navegador del docente se quedaría esperando media hora por un archivo que en realidad ya se había guardado, y cualquier intermediario de la red cortaría antes.

Así que la subida responde en cuanto el archivo está a salvo y el trabajo sigue por su cuenta. El precio es que hay que poder preguntar en qué punto está, y de ahí que el estado de un material haya pasado de tres valores a cinco: no se ha intentado, en curso, hecho por las herramientas, revisado por el docente y falló. «En curso» y «falló» no existían, y son justamente los dos que el docente necesita ver: el primero distingue un material que se está haciendo de uno que nadie va a tocar; el segundo distingue un intento fallido de un intento que nunca ocurrió, y detrás de esa diferencia hay una acción distinta.

Mientras haya algo en curso, la pantalla vuelve a preguntar cada seis segundos. No cada segundo —serían trescientas preguntas para enterarse de una sola cosa— ni cada treinta, porque un PDF pequeño termina en segundos y medio minuto de pantalla congelada parece una avería. Con la pestaña en segundo plano no pregunta nada, y al volver a ella pregunta una vez de inmediato.

Y las conversiones se hacen de dos en dos, no todas a la vez. Un docente que arrastra los veinte PDF de su curso de una sentada lanzaría veinte procesos pesados en la misma máquina que atiende a los estudiantes: no sería «más lento», sería el servicio caído para todo el mundo, incluido el chat. Con dos a la vez, los veinte materiales tardan más en estar listos y la plataforma sigue funcionando mientras tanto. Los que esperan turno no se pierden, y hay un botón para reintentarlos.

Un error que dice a quién le toca arreglarlo

Cuando algo falla, el docente no recibe el volcado técnico de la herramienta —eso va al registro del servidor, que es donde sirve— sino una frase que se puede leer y sobre la que se puede actuar. Hay ocho motivos distintos, y lo importante es que separan dos familias que suelen confundirse:

• «Falta una herramienta de extracción en el servidor; avisa a quien lo administra.» Esto no lo arregla el docente por mucho que vuelva a subir el archivo.
• «El archivo no se pudo leer; puede estar dañado, protegido o vacío.» Esto no lo arregla el administrador; lo arregla el docente volviendo a exportar el material.

Confundir las dos hace que cada uno espere al otro, y el material se queda sin convertir mientras tanto. Es un detalle pequeño que decide si un fallo se resuelve en un minuto o se queda meses.

El texto se puede corregir, y consta quién lo hizo

De ese texto salen las respuestas que el asistente le da al estudiante, con su cita. Por eso el docente puede abrirlo, leerlo y corregirlo desde la propia plataforma: una tabla que salió torcida, un encabezado repetido, una palabra que el reconocimiento óptico leyó mal.

Y el sistema no mezcla las dos cosas. El texto que acaban de producir las herramientas queda marcado como tal; el que una persona revisó queda marcado como revisado, y ese sello solo lo escribe el docente al guardar. Que alguien haya comprobado un texto es una afirmación que únicamente puede hacer quien lo comprobó, y darla por buena automáticamente vaciaría de sentido la distinción entera.

Hay un matiz que conviene decir porque es fácil equivocarse en él: corregir a mano la salida de un reconocimiento óptico no la convierte en una transcripción fiable. Por eso, junto al texto se conserva la constancia de cómo se obtuvo —qué herramientas intervinieron, si hubo reconocimiento óptico, si la numeración de página es de fiar—, y esa constancia sobrevive a la corrección. Borrarla justo en el material que alguien se molestó en revisar sería quitar la advertencia donde más falta hace.

Volver a convertir un material descarta la revisión humana. Precisamente por eso es una acción que hay que pedir a propósito, y no algo que ocurra solo.

La salvaguarda que protege la cita

Dentro del texto van unas marcas que dicen de qué página salió cada trozo. Son comentarios que no se ven al leer el documento, y de ellas depende que la cita al estudiante diga «página 7» y no solo el nombre del material.

Al hacer ese texto editable apareció un riesgo nuevo y silencioso: quien corrige no las ve, y un editor que descarte ese tipo de anotación al guardar se las llevaría todas sin que nadie lo hubiera decidido. El material seguiría existiendo, el texto seguiría siendo correcto, y las citas empezarían a salir sin número de página sin que ningún error lo anunciara.

La regla que se implementó distingue dos casos, y la distinción es deliberada:

• Perder algunas marcas se acepta. Quitar una portada o un anexo que no es del curso es una corrección legítima, y rechazarla convertiría la revisión en una pelea con el validador. El sistema ya sabe degradar lo que no reconoce sin arrastrar al resto.
• Borrarlas todas se rechaza. Ese es el caso que ocurre por accidente, y no hay forma de reconstruir después una paginación que ya no está escrita en ninguna parte.

Además, el aviso llega antes del error: mientras el docente escribe, la pantalla le dice cuántas marcas quedan y cuántas había, y le advierte en el momento en que el aviso todavía sirve de algo. La comprobación que de verdad bloquea el guardado está en el servidor, no en el navegador, porque una comprobación que solo vive en la pantalla se salta sola.

Dos huecos que se cerraron de paso

• Un material de tipo «enlace» ya lleva a alguna parte. Se podía crear uno, pero no había dónde poner la dirección: el docente lo daba de alta y el estudiante lo abría para encontrar un aviso de que ese material todavía no tenía archivo. Era la única de las clases de material que no podía llegar a estar completa.
• Se puede sustituir el archivo de un material sin perder su identidad. Antes, subir la versión corregida de una clase obligaba a borrar el material y crear otro, y con él se iban las citas que el asistente ya hubiera dado sobre ese material. Ahora el material es el mismo y solo cambia su archivo; el anterior se retira únicamente cuando el nuevo ya está guardado y la ficha ya lo señala, de modo que una caída a mitad deje como mucho un archivo de más y nunca un material que falla al abrirse. Antes de confirmar, la pantalla dice las tres consecuencias tal cual son: el archivo anterior no se recupera, el texto se vuelve a extraer del nuevo —y con ello se pierde la revisión hecha a mano, si la había—, y el material conserva su identidad, así que las citas ya dadas siguen apuntando aquí.

Resultado

La ruta que va del archivo del docente al texto citable está completa y funciona sin que nadie la empuje a mano. El docente sube, ve el progreso, corrige si hace falta, y el sistema conserva la diferencia entre lo que hizo una máquina y lo que revisó una persona.

Siguiente paso

Convertir ese texto en algo que el asistente pueda buscar: partirlo en fragmentos e indexarlo, que es lo que queda del Sprint 1. Hasta que llegue la credencial del servicio de inteligencia artificial, el asistente sigue funcionando contra un modelo simulado, que permite construir y probar todo lo demás pero no responde de verdad.

Qué cambió

Cuando alguien entra por primera vez con su cuenta institucional, la plataforma lo registra como estudiante. Eso es deliberado y no va a cambiar: si el papel se pudiera declarar al registrarse, cualquiera podría nombrarse docente al entrar y ver los materiales y los cursos de los demás.

La consecuencia es que a los docentes hay que nombrarlos, y hasta hoy nombrarlos significaba escribir una sentencia contra la base de datos. Funcionaba mientras el único que daba de alta a la gente era quien está construyendo el sistema. Deja de funcionar en cuanto la plataforma tiene que entregarse a la universidad, porque nadie va a administrar un sistema abriendo la consola de su base de datos, y porque un error tecleado ahí no tiene ninguna red debajo.

Desde hoy hay una pantalla. Lista todas las cuentas —la más reciente primero, que es justo quien acaba de entrar y espera su permiso—, se puede buscar por nombre o por correo, y a cada una se le asigna uno de los cuatro papeles: estudiante, docente, supervisión o administración. La pantalla no existe para quien no tiene administración: no aparece apagada ni da un aviso de permiso denegado, sencillamente no está, igual que no está el catálogo de cursos para quien no está matriculado.

Las dos salvaguardas, que son la razón de que esto sea una pantalla y no un formulario

Un cambio de papel es una de esas operaciones donde el error no se nota hasta que ya no tiene arreglo. Por eso hay dos reglas que el sistema no deja saltarse:

• Nadie puede quitarse a sí mismo la administración. Es un error sin deshacer: al recargar, la pantalla que serviría para devolverse el permiso ya no se le muestra, y recuperarlo exigiría exactamente la consulta a mano que esta pantalla vino a suprimir. La cuenta propia ni siquiera ofrece el desplegable.
• No se puede degradar a la última cuenta con administración. Sin esta regla, la plataforma se queda sin nadie capaz de repartir permisos y la única salida vuelve a ser la consola.

La segunda tiene un detalle que merece contarse porque es donde suelen fallar estas cosas. Lo obvio sería contar cuántos administradores hay y, si hay más de uno, hacer el cambio. Pero entre contar y escribir cabe otro cambio: si las dos últimas cuentas administradoras se degradan a la vez, cada una de las dos comprobaciones vería un compañero todavía en pie y ambas pasarían. La cuenta va por eso dentro de la misma operación que escribe, no antes, de modo que las dos degradaciones no puedan darse por buenas en paralelo.

La comprobación de quién está autorizado a usar esta pantalla vive en el servidor, dentro de la propia operación. Que el enlace no se pinte para quien no es administración es cosmética: cualquiera puede escribir la dirección en la barra del navegador.

Lo que todavía no está

La primera cuenta con administración no existe, y crearla sigue siendo un paso manual contra la base de datos. No hay orden de arranque, ni semilla, ni variable de configuración que la cree.

Es la consecuencia lógica de la decisión de más arriba —el alta solo puede crear estudiantes— y no se resuelve sola: alguien tiene que nombrar al primero desde fuera del sistema. La pantalla resuelve todo lo demás, que es el trabajo del día a día, pero no se puede decir que la administración de la plataforma ya no toque la base de datos. Toca una vez, y solo una vez, al principio.

Y una molestia pequeña que era una fuente de desorden

Reordenar los temas de un curso se hacía escribiendo números a mano. Ahora son dos flechas junto a cada tema, que se manejan también con el teclado y se desactivan solas en los extremos.

Debajo hay algo menos evidente. Escribir posiciones a mano permitía dejar dos temas en el mismo número —nada lo impedía—, y entonces el orden que ve el docente lo decidiría la fecha de creación: mover un tema podía no cambiar nada visible, y el botón parecería roto. Cada movimiento renumera ahora la lista entera de principio a fin, así que los empates y los huecos heredados se corrigen solos la primera vez que alguien mueve algo. Y si una de esas escrituras falla a mitad, el orden anterior se restaura en lugar de quedarse a medias; si tampoco se pudiera restaurar, el aviso dice exactamente en qué estado quedó el curso, porque ahí ya no queda nada que el sistema pueda hacer sin mentir.

Resultado

La plataforma se administra desde la plataforma. Un docente nuevo se incorpora en una pantalla, y el único momento en que hace falta la base de datos es el arranque inicial de la primera cuenta administradora, que queda como deuda declarada.

Siguiente paso

Resolver ese arranque inicial, para que la plataforma se pueda entregar sin instrucciones que empiecen por abrir una consola.

El problema real

Buena parte del material que entregan los docentes son presentaciones y PDFs que son imágenes. No hay texto que extraer. Para ese material, la alternativa a un buen reconocimiento no es uno peor: es que el material no exista dentro del sistema, y que el estudiante reciba un «eso no está en los materiales» que es falso.

Existe un tipo nuevo de reconocedor, basado en modelos de lenguaje visual, mucho mejor con tablas y fórmulas que las herramientas clásicas. La duda no era si funciona mejor. Era otra.

La sospecha

Un reconocedor clásico se equivoca en caracteres: produce basura reconocible. Un modelo de lenguaje puede equivocarse en frases: escribir algo verosímil que nunca estuvo en la página.

Para este sistema eso no sería un problema de calidad sino de categoría. Todo se sostiene sobre que el asistente solo afirma lo que está en el material y que cada cita es comprobable. Un párrafo inventado que entra al índice y luego se cita pasaría todas las comprobaciones: el fragmento existe, la cita corresponde. Solo que no está en el material.

Cómo se midió

Al revés de lo habitual. En vez de buscar documentos escaneados y adivinar qué decían, se fabricaron documentos en español —prosa, tablas de datos con unidades, fórmulas, diapositivas— cuyo texto se conocía exactamente, y luego se convirtieron a imagen para borrar ese texto. Así la comparación es contra una verdad exacta.

Se contaron por separado cuatro cosas que suelen mezclarse en una sola nota: errores de carácter, texto añadido que no existía, texto omitido, y la fidelidad de los números — porque en una tabla de ingeniería un dígito equivocado importa mucho más que un adjetivo.

El resultado

La sospecha no se confirmó. Ninguno de los dos inventó nada, ni siquiera con las imágenes degradadas a propósito, donde la herramienta clásica se equivoca en dos tercios de los caracteres.

Vale la pena decirlo así de claro, porque el experimento se montó esperando lo contrario.

Pero apareció otro riesgo, y es el que importa

Los dos fallan. Lo que cambia es cómo.

La herramienta clásica, cuando falla, produce basura evidente: el estudiante abre la cita y ve al instante que algo no cuadra. El modelo produce valores plausibles: escribe 0,3652 donde el documento decía 0,9652. Son muchos menos errores —seis de doscientos cuarenta y ocho números, frente a doscientos cuarenta y tres— pero son invisibles. Ningún filtro los distingue de un acierto, y el estudiante tampoco.

Para un sistema que cita fuentes, un número silenciosamente equivocado es peor que un galimatías evidente.

La decisión

Dos herramientas, no una sustitución. Sobre material bien digitalizado la clásica es equivalente y cien veces más barata: ahí no hay ningún problema que resolver. Sobre material escaneado con mala calidad la diferencia es abismal a favor del modelo — conserva 242 de 248 números donde la otra conserva 5. Se usa cada una donde gana.

Lo que todavía no se puede afirmar

Que el modelo no invente no está demostrado: se ha observado que no lo hizo en cinco documentos limpios. El relleno aparece con evidencia mucho más degradada —manchas, páginas torcidas, texto a mano— y la prueba no llegó hasta ahí. Queda pendiente repetirla sobre escaneos reales de un curso.

Siguiente paso

Repetir esta medición con material auténtico del curso en cuanto esté disponible, que es el único banco de pruebas que decide de verdad.

Qué pasó

Un día antes se había elegido la pieza que convierte los materiales del curso en algo buscable por significado. La justificación se apoyaba en un argumento central: que del modelo recomendado no existía ninguna medición pública en español, y que por eso había que confiar en su rendimiento en otros idiomas.

Esa afirmación era falsa. La medición existía, y estaba en el mismo documento del fabricante que la justificación citaba entre sus fuentes.

Con el dato real a la vista, la conclusión se da la vuelta: el modelo recomendado era el peor de los candidatos en búsqueda en español, y quedaba por debajo del que sugería el documento contractual del proyecto. La segunda razón que sostenía la elección —que era el único con cierto formato optimizado disponible— también resultó equivocada, y en sentido contrario: el modelo descartado ofrecía cuatro veces más variantes de ese formato.

Por qué el error costó poco

La decisión se había tomado deliberadamente en dos mitades: se fijó ya la característica que quedaría grabada en la base de datos y sería cara de cambiar, y se dejó abierta la elección del modelo concreto.

Esa separación es la que hizo barata la corrección. Cambiar de modelo obliga a volver a procesar los materiales; cambiar la característica congelada habría obligado a rehacer la estructura de la base de datos. Se cambió el modelo al día siguiente sin tocar nada del diseño.

Lo que esto dice del método

Revisar el trabajo buscando el fallo, y no la confirmación, ya se había aplicado al código de este mismo sprint y había encontrado veinte defectos. Aquí se aplicó a una decisión escrita, con el encargo explícito de sostener el caso contrario y de comprobar cada cifra en su fuente original en lugar de en el resumen que la citaba.

Es una diferencia de método que se puede enunciar en una frase: una fuente citada no es una fuente leída. El argumento que se cayó no se cayó por falta de investigación —la primera había sido extensa— sino porque nadie había abierto la tabla concreta.

Resultado

La elección cambió con fundamento medido en lugar de estimado, y el proyecto no pagó ningún coste estructural por la corrección.

Siguiente paso

Confirmar la elección con preguntas reales sobre el material del curso, que es la prueba que de verdad decide, en cuanto ese material esté disponible.

Qué se preguntó

Un buscador por significado necesita, en teoría, un índice especializado: una estructura que evita comparar la pregunta con todos los documentos. Es lo que recomienda cualquier manual, y estaba en el diseño del sistema desde el principio.

La pregunta era cuál usar y con qué ajustes. La respuesta medida fue otra: ninguno.

Por qué

El asistente busca siempre dentro de un solo curso. Y el índice especializado hace las cosas en un orden que choca con eso: primero busca los mejores candidatos de toda la base de datos, y solo después descarta los que no son del curso. Con la configuración recomendada por defecto, eso deja muy pocos supervivientes.

En las pruebas, esa configuración devolvía entre cero y ocho fragmentos cuando se le pedían ocho. Cero, en algunos casos, sobre cursos que tenían miles de fragmentos disponibles. Y sin ningún mensaje de error: el asistente simplemente diría que no encuentra nada en el material, cuando el material está ahí.

Comparar con todos los fragmentos del curso, sin índice, devuelve siempre los ocho correctos y tarda seis décimas de milisegundo sobre cien mil fragmentos. El índice no era más rápido. Era más lento en cuanto se le pedía la misma calidad, y mientras tanto perdía información en silencio.

La razón de fondo

Un índice de este tipo existe para cuando comparar con todo resulta caro. Aquí no lo es: el coste crece con el tamaño del curso, no con el de la base de datos, y un curso son unos miles de fragmentos. La estructura resolvía un problema que este sistema no tiene, y a cambio introducía uno que sí importa.

Se retira del diseño. Es una pieza menos que construir, que ajustar y que explicar.

Lo que esto costó y lo que ahorra

El banco de pruebas llevó unas horas de cómputo sobre datos reales. A cambio, retira una pieza del sistema y evita un fallo que no habría dado ningún síntoma: nadie revisa por qué el asistente dijo «no está en el material» si suena razonable que no esté.

Una segunda comprobación, con el mismo resultado

En paralelo se verificó el formato comprimido del modelo que interpreta los textos —la versión ligera, pensada para funcionar sin tarjeta gráfica—. Resultó no ser equivalente a la versión completa: produce resultados lo bastante distintos como para que un documento archivado con una y una pregunta procesada con la otra dejen de entenderse entre sí.

Es notable porque «dispone de versión comprimida oficial» había sido un argumento a favor en las dos elecciones de modelo que se hicieron estos días, la primera y la que la corrigió. Medido, no valía para ninguna. Era un dato con aspecto de hecho técnico que nadie había ejecutado.

Resultado

Dos piezas del diseño quedan decididas con números propios en lugar de con recomendaciones generales, y una de ellas desaparece por innecesaria.

Siguiente paso

Construir la búsqueda dentro de los materiales con esta configuración, y confirmarla con preguntas reales sobre el material del curso.

Qué cambió

Hasta ahora existían las piezas: el registro, el motor de razonamiento, la verificación de citas. Desde hoy están conectadas y se ven funcionar. El estudiante escribe una pregunta y en pantalla aparece, en este orden y en tiempo real: el razonamiento del asistente, la búsqueda en los materiales del curso —con cuántos fragmentos encontró— y la respuesta, palabra por palabra, con sus citas.

Importante para entender el alcance: esta etapa prueba el camino, no todavía la calidad de las respuestas. El modelo y la búsqueda son piezas de prueba deliberadas, porque lo que había que demostrar aquí es que la conversación fluye de extremo a extremo.

Trabajo realizado

• La respuesta llega en tiempo real, no de golpe. Es más difícil de lo que parece: la conversación atraviesa dos servicios distintos, y basta con que cualquiera de los dos acumule texto para que la respuesta aparezca entera al final. Ese fallo no produce ningún error — simplemente se pierde la sensación de que el asistente está respondiendo—, así que se midió el tiempo de llegada de cada fragmento para comprobarlo.
• Se ve qué material está consultando. No es decoración: en un asistente anclado a los materiales de un curso, ver la búsqueda es lo que vuelve evidente que la respuesta viene del curso y no de un conocimiento general.
• El razonamiento se muestra aparte, en un panel que se despliega, separado de la respuesta.
• La conversación tiene memoria. Los turnos de una misma sesión quedan agrupados, lo que además es lo que permite medir cuánto usa el asistente cada estudiante, un dato central del estudio.
• El asistente solo aparece donde corresponde. En los cursos sin asistente ni siquiera se muestra la entrada — un botón desactivado bastaría para anunciar quién está en cada grupo del estudio.

Dos decisiones que merecen contarse

• Lo que se ve mientras se escribe no es todavía la respuesta. El texto va apareciendo antes de que el sistema termine de comprobar sus citas, así que si algo falla a mitad, ese texto se descarta en lugar de quedarse en pantalla. Mostrar una afirmación con una fuente que nunca se verificó sería precisamente el error que toda la comprobación existe para impedir.
• El curso sobre el que se conversa no lo decide el navegador. Lo determina el servidor a partir de la matrícula. De otro modo, una petición manipulada podría consultar materiales de un curso ajeno y quedar registrada como legítima.

Resultado

La conversación completa funciona de extremo a extremo y quedó verificada midiendo tiempos reales. Todo lo que ocurre se registra: la pregunta, la respuesta, qué material se consultó, qué se citó y cuánto costó cada paso.

Siguiente paso

Conectar el modelo de verdad y fijar su configuración definitiva, que a partir de ese momento no cambia durante el estudio.

Qué cambió

El asistente estaba en una pantalla propia: para preguntar había que dejar de leer. Ahora ocupa un panel junto al contenido —a un lado en computadora, debajo en el teléfono—, y el estudiante puede mover la división para dar más espacio a lo que necesite en cada momento. El tamaño que elija se recuerda.

Por qué importa más de lo que parece

No es una mejora de comodidad. El sistema registra qué estaba viendo el estudiante al preguntar —qué curso, qué tema, qué material, qué página—, y ese dato hace dos cosas a la vez: acota la búsqueda en los materiales, para que la respuesta venga de lo que se está estudiando; y es una de las variables de la investigación.

Con el asistente en una pantalla aparte, ese dato habría llegado casi siempre vacío, porque para preguntar había que abandonar lo que se estaba mirando. Con el asistente al lado se llena solo. Y es un dato que, si no se recoge mientras ocurre, después no se puede reconstruir.

Dos decisiones de acceso

• En un curso sin asistente, el panel no existe. No aparece apagado ni plegado ni vacío. El estudio compara dos grupos, y uno de ellos cursa sin asistente: un panel desactivado le anunciaría que existe algo que no tiene, igual que un botón gris.
• Tampoco aparece para docentes ni para supervisión, que no forman parte del grupo estudiado.

Otras dos, técnicas, que se notan al usarlo

• Moverse entre los temas de un curso no interrumpe la conversación: si el asistente está respondiendo, sigue respondiendo. Cambiar de curso sí abre una conversación nueva, porque es otra conversación.
• Cada mitad de la pantalla se desplaza por su cuenta: leer el material no mueve el chat, ni al revés.

Resultado

La plataforma toma su forma definitiva: el asistente acompaña el estudio en lugar de interrumpirlo.

Siguiente paso

Conectar el modelo de verdad y fijar su configuración, que a partir de ese momento no cambia durante el estudio.

Qué cambió

El asistente ya conversaba, pero sobre materiales de mentira. Este avance construye la pieza que convierte los archivos de un curso —presentaciones, documentos, PDFs— en texto que el asistente puede consultar, y sobre todo citar.

Citar es lo que distingue a este sistema de un chatbot. Cuando el asistente afirma algo, dice de qué material y de qué página lo sacó, para que el estudiante pueda ir a verlo. Eso obliga a que cada fragmento de texto recuerde de dónde salió, y a que ese recuerdo sea correcto.

La decisión que gobierna todo lo demás

Hay un error que no se ve: una cita con la página equivocada. El estudiante la lee, va al material, y encuentra otra cosa. No hay ningún mensaje de error, ninguna alarma. El sistema parece estar funcionando mejor que nunca.

Por eso la regla del sistema es explícita: si no puede garantizar la página, no la dice. Cita el material sin número de página, y el estudiante lo busca dentro. Citar sin página es correcto; citar la página equivocada, no. Un documento de Word, por ejemplo, se cita siempre sin página, porque la paginación que ve el docente en su computadora no se puede reproducir con garantías.

Lo que apareció al revisar el trabajo buscando el fallo

Cada pieza se revisó después con el encargo de romperla. De ahí salieron veinte correcciones, y tres merecen contarse porque ninguna se habría notado usando el sistema:

• Una diapositiva oculta desplazaba toda la numeración. Las presentaciones suelen llevar diapositivas ocultas —respuestas, material de respaldo— y al convertirlas desaparecían, de modo que la «página 2» del sistema era la diapositiva 3 del archivo del docente. La comprobación que existía no podía detectarlo, porque comparaba el documento convertido consigo mismo.
• Un material escaneado con la portada digital no se procesaba. El sistema medía el promedio de texto por página, y una sola página con texto bastaba para dar por bueno el documento entero. Se perdía el 88 % del material sin que nada lo indicara: las páginas quedaban vacías, pero registradas.
• Un comentario oculto en el material podía darle instrucciones al asistente. El texto de un material es corregible por el docente, y hay formas de escribir en él que no se ven al leerlo. Ese camino está cerrado: nada invisible llega al asistente.

Sobre el modelo que entenderá los materiales

Queda por elegir la pieza que convierte el texto en algo buscable por significado y no por palabras exactas. La decisión se tomó a medias, y a propósito: se fija ya la característica que quedaría congelada en la base de datos y sería costosa de cambiar, y se deja para una medición la elección del modelo concreto.

El motivo es que la evidencia disponible en español era escasa, y conviene medir antes que extrapolar. La forma en que se fijó la decisión permite cambiar de modelo sin rehacer nada del diseño — y al día siguiente hizo falta: ver la revisión que corrigió esta elección.

Resultado

Un material del curso ya se convierte en fragmentos consultables que saben de qué página vienen, y el sistema sabe cuándo no puede prometerlo.

Siguiente paso

Enseñar al sistema a buscar por significado dentro de esos fragmentos, y conectar el modelo definitivo del asistente.

Qué cambió

Ya existe el motor que decide cómo responder: busca en los materiales del curso, evalúa si lo encontrado alcanza, reformula la búsqueda si hace falta y redacta la respuesta citando de dónde sale cada afirmación. Está construido de forma que puede probarse entero sin base de datos, sin conexión a internet y sin gastar un solo token del modelo en la nube, lo que permite verificar su comportamiento de forma exhaustiva y repetible.

Trabajo realizado

• Un límite duro de trabajo por pregunta. El asistente puede buscar hasta tres veces y después responde obligatoriamente con lo que tenga. Sin ese tope, una pregunta difícil podría convertirse en un consumo sin fin.
• Las citas se verifican una por una. Cada referencia que el asistente escribe se comprueba contra el material que realmente se le entregó. La que no corresponde no se corrige: se elimina, y queda registrada. Una cita falsa que apunta a una página real sería peor que no citar.
• Rehusar es una respuesta correcta. Cuando el material del curso no cubre la pregunta, el asistente lo dice, y el sistema registra esa situación como lo que es —una respuesta honesta— y no como una falla.
• El asistente no puede ampliar su propio permiso. Decide qué buscar, nunca dónde: el alcance —el curso, el tema— lo fija el sistema y no viaja entre lo que el modelo puede pedir.
• Todo intento queda registrado, incluidos los que el sistema rechaza. Una búsqueda repetida o una petición inválida dejan rastro, porque son precisamente los casos que más dicen sobre cómo se comporta el asistente.

La auditoría

Terminado el motor, se encargó una revisión con la instrucción explícita de intentar romperlo. Encontró once problemas; todos se corrigieron antes de dar la etapa por terminada. Tres, por lo que ilustran:

• La respuesta la redactaba el modelo equivocado. El diseño usa un modelo económico para los pasos intermedios y uno mejor para la respuesta final, pero por cómo estaba escrito el ciclo, la respuesta que leía el estudiante podía salir del económico según cuántas búsquedas hubiera hecho. Eso significa que dos estudiantes con la misma pregunta podían recibir respuestas de calidad distinta — inaceptable en un estudio donde la intervención debe ser idéntica para todos.
• Si el estudiante cerraba la ventana, su interacción no quedaba registrada. Se perdían justamente las conversaciones abandonadas y las lentas, que son las más informativas, y el análisis habría quedado sesgado hacia las que salieron bien sin que nadie pudiera notarlo.
• Una cita correcta a un material sin páginas se contaba como si el asistente no hubiera citado, lo que subestimaba en silencio la medida central del proyecto.

Resultado

El motor queda terminado, corregido y cubierto por 56 pruebas automáticas. Ninguna de las correcciones habría sido posible más tarde sin perder datos del estudio.

Siguiente paso

Conectar el motor con la pantalla: que la respuesta aparezca palabra por palabra y que se vea qué material está consultando mientras trabaja.

Qué cambió

Esta mañana la plataforma ya se abría y pedía identificarse con la cuenta institucional, pero el servicio que guarda los datos todavía no comprobaba nada: cualquier persona que hubiera entrado veía el catálogo completo. Desde hoy cada consulta se verifica antes de responder.

Trabajo realizado

• La sesión se comprueba en el servicio de datos, no solo en la interfaz. Antes de devolver nada, el servicio verifica de forma criptográfica que la sesión la haya emitido de verdad el sistema de acceso institucional, que no haya expirado y que el correo esté verificado por la propia universidad.
• Tres perfiles con permisos distintos, tal como quedó acordado en el diseño del estudio:
  • Estudiante: ve únicamente los cursos en los que está matriculado, y nada más.
  • Docente: ve el curso completo y puede organizarlo —temas y materiales—.
  • Supervisión: ve exactamente lo mismo que el docente, y no puede modificar nada. La supervisión observa; no interviene.
• Nadie puede asignarse un perfil a sí mismo. Al entrar por primera vez, toda cuenta se crea como estudiante. Elevar a docente o a supervisión es un acto administrativo deliberado.
• A quien no le corresponde un curso, ese curso sencillamente no existe. No se responde «existe, pero no es tuyo», porque esa respuesta permitiría deducir el catálogo entero preguntando una y otra vez.
• Ante la duda, se cierra. Si el servicio no puede comprobar una sesión por un problema técnico, deja de responder en lugar de conceder el acceso.
• El filtro se aplica dentro de la consulta a la base de datos, no descartando resultados después: los datos que no corresponden a esa persona nunca llegan a leerse.

Resultado

El control de acceso quedó comprobado de principio a fin con una sesión institucional real, en ocho situaciones distintas, todas con el resultado esperado. Además, la comprobación de pertenencia deja resuelto de paso a qué grupo del estudio pertenece cada estudiante, que es exactamente el dato que deberá acompañar a cada interacción registrada más adelante.

Siguiente paso

Comienza el primer sprint: convertir los materiales del curso —presentaciones, documentos, PDF— en contenido que el asistente pueda consultar y citar por página.

Qué cambió

Se definió con qué se convertirán los documentos del curso —presentaciones, textos y PDF— en el material que el asistente puede consultar, y dónde se calculan las representaciones numéricas que permiten buscar por significado y no por palabra exacta.

Trabajo realizado

• El servicio principal no interpreta los documentos por su cuenta: delega esa lectura en herramientas de código abierto con años de uso, y se queda con la organización del resultado.
• Esa elección conserva la página de origen de cada fragmento tal como la entrega la herramienta, en lugar de deducirla. Es lo que permite que la respuesta cite «recurso, página N» y que la cita se pueda comprobar.
• Las presentaciones y documentos de texto siguen el mismo camino que los PDF, de modo que hay una sola ruta de conversión que mantener.
• Previsión para material escaneado: reconocimiento óptico de caracteres en español, solo cuando el documento lo requiera.
• El cálculo de las representaciones numéricas se ubica en la máquina que tiene la tarjeta gráfica del servidor, y se ofrece como servicio interno. Así el material y las preguntas se procesan siempre con el mismo modelo, requisito para que la búsqueda sea coherente.

Resultado

La lectura de materiales queda apoyada en herramientas maduras y la trazabilidad de las citas queda garantizada desde el primer paso del proceso, no reconstruida al final.

Siguiente paso

Implementar el primer sprint: conversión, segmentación e indexado del material del curso piloto.

Qué cambió

El sistema tiene dos piezas: una aplicación web, que es lo que ve el estudiante, y un servicio que hace el trabajo. Se definió que ese servicio concentre todo el trabajo y que la aplicación web se quede con lo mínimo: mostrar la conversación y saber quién está conectado.

Trabajo realizado

• Traslado del motor de conversación —búsqueda del material pertinente, diálogo con el modelo, verificación de que cada cita corresponda a un fragmento realmente recuperado— a un único servicio.
• La aplicación web conserva la dirección de chat que corresponde al alcance acordado, pero solo como puente: comprueba la sesión y retransmite la respuesta a medida que se genera.
• Un solo componente pasa a tener permiso para escribir los registros de interacción que alimentan la investigación; ningún otro puede modificarlos.
• La versión exacta del motor que atendió cada consulta queda identificada de forma automática, sin depender de que alguien la anote.

Resultado

Durante el período de uso por los estudiantes se podrá corregir la interfaz sin alterar el comportamiento del asistente, que es lo que el estudio mide. Antes, ambas cosas vivían en el mismo lugar y no se podían separar.

Siguiente paso

Construir ese servicio en el segundo sprint, con su registro completo de interacciones.

Qué cambió

El plan original construía primero la conversión de los materiales del curso y después el motor conversacional. Al revisarlo se vio que la dependencia estaba mal leída: el motor consulta el material a través de una sola herramienta, y para el motor eso es un contrato, no una implementación. Lo que faltaba construir era lo que está detrás de ese contrato.

Se invirtió el orden, por tres razones:

• El motor es quien define qué debe entregar la búsqueda. Preparar los materiales primero significa segmentarlos para un contrato que nadie ha validado todavía.
• Hay datos que no se pueden recuperar después. El registro de qué estaba viendo el estudiante al preguntar es, a la vez, lo que acota la búsqueda y una variable del estudio. Si no está desde la primera consulta, esos datos no existen.
• La configuración del asistente debe quedar fija durante el estudio, y fijarla con criterio exige haberla ejercitado antes.

Trabajo realizado

• Plan reescrito en cinco fases. Las cuatro primeras no dependen de nada externo y se pueden comprobar de inmediato; la quinta sustituye la pieza simulada por la real.
• Decisión sobre cómo habla el sistema con el modelo en la nube. Se eligió el formato que trata el razonamiento del modelo como contenido de primera clase, de modo que el asistente conserva el hilo entre los pasos de una misma consulta. La decisión no salió de leer documentación: el patrón lleva meses funcionando en otro producto de la casa, y con dos proveedores distintos, lo que además mantiene abierta la posibilidad de cambiar de modelo sin rehacer el sistema.
• Se definió qué verá el estudiante mientras el asistente trabaja. No una respuesta que aparece de golpe, sino el proceso: qué material está consultando y en qué página. En un tutor anclado a los materiales del curso eso no es decoración —es lo que hace evidente que la respuesta viene del curso y no de un conocimiento general—.
• Se separó mostrar de registrar. Lo que se guarda para la investigación es la traza del proceso —qué se consultó, qué fragmentos se usaron, cuántos pasos—, no el razonamiento interno del modelo.
• Quedó anotado, además, algo fácil de pasar por alto: decidir si se muestra o no ese proceso forma parte del tratamiento del estudio, no del diseño de la interfaz, así que se fija antes de empezar y no se cambia a mitad.

Resultado

El trabajo del núcleo puede empezar sin esperar a ninguna decisión pendiente, y el plan distingue con claridad lo que se puede demostrar hoy de lo que necesita el material del curso ya procesado.

Siguiente paso

Construir el registro de la evidencia y el motor de razonamiento, y verlos funcionar de extremo a extremo con una pieza de búsqueda simulada.

Qué cambió

Hasta ahora el proyecto era infraestructura y decisiones de diseño. Desde hoy hay una plataforma que se abre en el navegador, pide identificarse con la cuenta institucional y muestra un panel con los cursos, sus temas y sus materiales.

Es la base sobre la que se apoyan los tres sprints acordados: el asistente no es una aplicación aparte, sino una función dentro de esta plataforma.

Trabajo realizado

• Estructura académica de datos: cursos, temas, materiales y matrículas, con la separación entre los dos grupos del estudio incorporada desde el primer día, no añadida después.
• Ingreso con la cuenta institucional. No hay usuarios ni contraseñas propias: la identidad la certifica la universidad. El sistema comprueba que el correo esté verificado por ella, de modo que nadie puede declararse miembro de la institución por su cuenta.
• Panel de trabajo con navegación lateral: los cursos a la vista, y dentro de cada uno sus temas y materiales.
• Conexión cifrada para el acceso durante el desarrollo, con certificado válido.
• Se corrigieron dos defectos encontrados al probar el ingreso real. En ambos casos se rehízo la pieza afectada en lugar de aplicar un remiendo: uno provenía de una herramienta descontinuada por sus autores, y mantenerla habría dejado el sistema apoyado en una versión que ya nadie sostiene.

Resultado

El ciclo completo de ingreso funciona de principio a fin y deja registro de la cuenta institucional que entró. La plataforma pasa de ser un plan a ser algo que se puede abrir y recorrer.

Siguiente paso

Que cada persona vea únicamente los cursos en los que está matriculada. Hoy el ingreso ya está resuelto; falta que el servicio que guarda los datos compruebe esa pertenencia en cada consulta.

Qué cambió

El asistente todavía no responde, pero ya existe el lugar donde quedará registrado cada interacción. Se construyó primero, y a propósito: los datos de una investigación tienen la particularidad de que no se pueden recuperar después. Si el registro nace incompleto, esos meses de intervención simplemente no producen la información que el estudio necesita.

Trabajo realizado

• Se separó el historial de la evidencia. Lo que el estudiante ve al volver a abrir el chat y lo que se conserva para la investigación son cosas distintas: el primero se borra y se edita, la segunda no puede hacer ninguna de las dos cosas.
• La evidencia solo admite añadir. La propia base de datos rechaza modificar o borrar una interacción ya registrada. No es una regla escrita en un manual: es el motor el que se niega.
• La identidad vive separada. El registro de las interacciones no contiene el identificador real de ninguna persona, sino un seudónimo. La correspondencia se guarda en un único lugar aparte, y eso da además un camino limpio para el retiro del consentimiento: eliminar esa correspondencia rompe la reidentificación y conserva el dato agregado.
• El consentimiento se aplica en el sistema, no en la buena memoria de quien programa. Si una persona no consintió que se conserve el contenido de sus mensajes, el texto no se guarda aunque el programa lo entregue.
• Una interacción que falla también se registra. Sin esto, las conversaciones problemáticas —justo las más informativas— serían las únicas que no se podrían analizar.
• Se registran las dos mitades del anclaje: qué material se le entregó al asistente y qué citó efectivamente de él. Con una sola de las dos no se puede sostener la afirmación central del proyecto.

Revisión antes de construir

Antes de dar el diseño por bueno se sometió a una revisión adversarial: el encargo fue romperlo, no aprobarlo. Encontró cinco problemas y todos se corrigieron el mismo día. Dos ejemplos, porque ilustran el tipo de error que solo se ve si alguien lo busca:

• Dos registros escritos en el mismo instante recibían la misma marca de tiempo, de modo que no había forma garantizada de saber cuál fue antes. Funcionaba por casualidad, no por diseño.
• La ausencia de texto significaba dos cosas a la vez —«no dio su consentimiento» y «no llegó a haber texto»— y meses después habrían sido indistinguibles. Esa distinción es precisamente lo que permite demostrar bajo qué condiciones se recogió cada dato.

Resultado

La base del registro quedó construida, verificada con pruebas automáticas y protegida contra su propia modificación. Todo lo que venga después escribirá sobre un contrato ya fijado.

Siguiente paso

El motor de razonamiento: el ciclo de consultar el material, evaluar si alcanza para responder y citar lo que se usó.

Qué cambió

Las máquinas del proyecto dejaron de estar vacías. Quedó instalado y funcionando el software sobre el que se construirá el SAAI: el motor de base de datos con capacidad de búsqueda semántica, el almacén de los archivos del curso y el entorno donde correrán la aplicación web y los servicios internos.

Trabajo realizado

• Instalación del motor de base de datos con la extensión que permite buscar por significado y no solo por palabras exactas, requisito de todo el mecanismo de recuperación del asistente.
• Ubicación de los datos en el disco dedicado del proyecto, separado del disco del sistema, para que el crecimiento del contenido no comprometa la operación.
• Activación de sumas de verificación de integridad en la base, aprovechando que aún estaba vacía. Hacerlo más adelante habría exigido una interrupción del servicio.
• Instalación del almacén de archivos que guardará los materiales del curso, con arranque automático y comprobación de que un archivo sube y se recupera idéntico.
• Instalación del entorno de ejecución de la aplicación web y del lenguaje de los servicios internos, verificados compilando y ejecutando programas de prueba.
• Configuración del servidor web que publicará el asistente, preparado para entregar las respuestas del chat a medida que se generan en lugar de esperar a que estén completas.
• Comprobación de ese comportamiento midiendo la entrega real de mensajes, no solo revisando la configuración.
• Restricción de acceso: el motor de datos y el almacén no son visibles desde internet ni desde el entorno de laboratorio, y solo aceptan conexiones de la máquina de aplicación.
• Reinicio completo de ambas máquinas al terminar, comprobando que todos los servicios vuelven por sí solos y repitiendo las verificaciones después.

Resultado

La capa técnica sobre la que se apoyan los tres sprints quedó lista. El primer sprint —convertir los materiales del curso en contexto consultable— ya no tiene ningún impedimento técnico: puede empezar en cuanto estén disponibles los materiales validados del curso piloto.

Deliberadamente no se creó todavía la estructura de tablas del asistente: depende de qué modelo de comprensión de texto se adopte, decisión que se toma al inicio del primer sprint y que condiciona cómo se organizan los índices de búsqueda.

Siguiente paso

Gestionar con el área correspondiente de la universidad el nombre de dominio institucional y la apertura del acceso web seguro, único habilitante de infraestructura que sigue pendiente y que no depende del equipo de desarrollo.

Qué cambió

El proyecto definió cómo se escribe el software y cómo llega al servidor. Hasta ahora estaba resuelta la plataforma base; faltaba la disciplina de trabajo que la usa.

Trabajo realizado

• Decisión de desarrollar sobre el propio servidor, con el entorno de trabajo separado del entorno que atenderá a los estudiantes: distinto usuario del sistema, distinto puerto y distinta base de datos.
• Separación impuesta en el motor de base de datos y no por acuerdo: el entorno de desarrollo no tiene permiso para leer ni escribir la información del curso en producción.
• Adopción de un único gestor de dependencias para todo el ciclo, con versiones fijadas, de modo que lo que se prueba y lo que se despliega instalen exactamente lo mismo.
• Control de versiones en tres repositorios —documentación, aplicación web y servicios— con respaldo del historial fuera del repositorio principal.
• Despliegue automatizado desde el propio control de versiones, ejecutado dentro de la infraestructura institucional: verificación previa, respaldo de la base de datos, comprobación de funcionamiento y retorno inmediato a la versión anterior si esa comprobación falla.
• Regla de congelamiento durante el período de uso del sistema por los estudiantes: solo se corrigen defectos, y cada corrección queda fechada y versionada.

Resultado

Cada cambio que llegue al servidor será rastreable hasta una versión concreta, reversible en minutos y ejecutado sin poner en riesgo la información ya registrada del curso.

Siguiente paso

Dejar el proceso operativo —repositorios, entorno de desarrollo y guion de despliegue— antes de iniciar el primer sprint funcional.

Qué cambió

La universidad puede ahora consultar directamente el estado y las estadísticas de la infraestructura del proyecto, con un acceso que no permite modificar nada.

Trabajo realizado

• Habilitación de un acceso de consulta con el perfil de auditoría de la plataforma de virtualización, limitado a privilegios de lectura.
• Comprobación de que el acceso permite ver el estado y el consumo de recursos, y de que las operaciones de cambio quedan rechazadas: apagar o encender máquinas, abrir consolas remotas, crear puntos de restauración y administrar usuarios.
• Verificación hecha contra la interfaz de programación y no solo contra la pantalla, de modo que la restricción se sostiene aunque alguien intente saltarse la interfaz gráfica.
• El acceso no corresponde a una cuenta del sistema operativo, por lo que no habilita ninguna forma de conexión administrativa a los servidores.
• La consola de administración sigue sin publicarse en internet: el acceso requiere el canal cifrado del proyecto o la red interna de la universidad.

Resultado

La contraparte gana visibilidad sobre la infraestructura que financió sin que ello introduzca riesgo de cambios accidentales sobre un entorno en preparación.

Siguiente paso

Evaluar, si la supervisión pasa a ser frecuente, la publicación de un panel de métricas dedicado en lugar del acceso a la consola de administración.

Qué cambió

El proyecto adoptó una regla de registro: ningún cambio técnico, documental o de infraestructura se da por hecho hasta quedar anotado el mismo día en los dos registros.

Trabajo realizado

• Definición del formato de cada avance publicable: fecha, resultado verificable, hito asociado y evidencias.
• Definición de lo que nunca se publica: credenciales, llaves, configuración privada, direccionamiento interno y capturas sin revisar.
• Enlace de esta vista pública dentro del propio repositorio de trabajo, de manera que publicar un avance sea parte del mismo flujo que registrarlo.
• Revisión retroactiva de los avances previos para que lo registrado internamente tuviera su contraparte publicada.

Resultado

La bitácora interna y el portafolio público describen los mismos avances, con distinto nivel de detalle y sin información sensible en la vista pública.

Siguiente paso

Aplicar la misma regla durante el despliegue de servicios y los tres sprints funcionales.

Qué cambió

El entorno virtual, el almacenamiento y la estrategia de respaldo quedaron preparados para recibir los servicios del SAAI.

Trabajo realizado

• Verificación de la imagen oficial del sistema operativo y creación de una plantilla base protegida, reutilizable para todas las máquinas del proyecto.
• Despliegue de las cuatro máquinas virtuales previstas —datos, aplicación, cómputo acelerado y laboratorio— con configuración inicial automatizada, cortafuegos propio y acceso por el canal privado.
• Preparación de un volumen dedicado de datos para la base de conocimiento y el almacenamiento de archivos del asistente.
• Puesta en marcha de un servidor de respaldos en el segundo nodo, con un almacenamiento dedicado de 4 TB verificado como vacío antes de formatearlo.
• Configuración de respaldos diarios y semanales con política de retención, verificación automática de integridad y limpieza periódica.
• Prueba real de recuperación: respaldo completo de una máquina en 90 segundos y restauración a una copia temporal con red, canal privado y agente operativos; el tiempo total de recuperación observado fue de 7 minutos.

Resultado

La base de infraestructura fue aceptada mediante pruebas de operación y recuperación. La copia temporal de prueba se eliminó y el respaldo quedó conservado.

Siguiente paso

Desplegar los servicios de datos y aplicación antes de declarar el inicio formal del Sprint 1.

Qué cambió

Se habilitó y comprobó la aceleración necesaria para procesar embeddings localmente, sobre la GPU reservada previamente para el proyecto.

Trabajo realizado

• Entrega de la GPU y de su controlador de audio a la máquina virtual de cómputo.
• Instalación del controlador y del entorno de cómputo dentro de esa máquina, descartando una versión más reciente por incompatibilidad declarada por el propio fabricante.
• Prueba funcional de aceleración antes y después de un reinicio controlado de la máquina, para confirmar que la capacidad se recupera sola.
• Corrección de la telemetría de memoria de la máquina, que informaba un consumo irreal y habría distorsionado el monitoreo del servicio.

Resultado

La capacidad de cómputo superó una prueba funcional y volvió operativa después de un reinicio controlado, con el monitoreo reportando valores reales.

Siguiente paso

Integrar esta capacidad al flujo de ingesta conservando una ruta alternativa para continuidad.

Qué cambió

Producción, laboratorio y administración quedaron segmentados para evitar que las pruebas interfieran con la operación.

Trabajo realizado

• Creación de dos redes virtuales independientes, una para los servicios del SAAI y otra para los laboratorios de prueba.
• Salida a internet controlada y persistente para ambas redes, sin exponerlas entre sí.
• Comprobación de que el laboratorio no alcanza la red de producción.
• Verificación de que la consola de administración y el canal privado siguieron operativos durante todo el cambio.

Resultado

El equipo puede desarrollar y validar componentes manteniendo separados los accesos y las cargas.

Siguiente paso

Completar el despliegue de servicios y la declaración operativa del entorno.

Qué cambió

El servidor dejó de usar la GPU dedicada para sí mismo y la reservó desde el arranque para entregarla íntegra a una máquina virtual del proyecto.

Trabajo realizado

• Actualización del servidor a la versión de plataforma acordada, previa a la reserva.
• Reserva temprana de la GPU y de su controlador de audio durante el arranque del sistema, de modo que ningún otro componente los tome primero.
• Conservación de la gráfica integrada para el propio servidor, para no perder la consola local.
• Respaldos protegidos de la configuración antes y después del cambio, con su huella de integridad registrada.
• Dos reinicios completos de verificación, comprobando en cada uno la red, el acceso remoto, la consola de administración, el almacenamiento y los servicios.
• Publicación interna de los archivos de configuración necesarios para reproducir el procedimiento.

Resultado

La GPU quedó disponible en exclusiva para la máquina de cómputo del SAAI, sin afectar la operación del servidor ni el canal de administración. Este paso es el que habilita procesar los materiales del curso con aceleración local.

Siguiente paso

Instalar el entorno de cómputo dentro de la máquina virtual y comprobar la aceleración de punta a punta.

Qué cambió

El acceso de administración a los servidores institucionales dejó de depender de la presencia física y pasó a realizarse por un canal cifrado dedicado.

Trabajo realizado

• Apertura controlada del canal privado en el cortafuegos central de la red.
• Habilitación del acceso administrativo desde la estación de trabajo autorizada hacia los dos servidores del proyecto.
• Verificación de alcance y de sesión administrativa sobre ambos nodos por ese mismo canal.

Resultado

El equipo puede continuar la ejecución de forma remota y segura, sin exponer los servidores a accesos abiertos.

Siguiente paso

Homologar la plataforma de virtualización de ambos servidores antes de crear las máquinas del proyecto.

Qué cambió

Los dos servidores institucionales quedaron alineados en la misma versión de la plataforma de virtualización, punto de partida obligado para desplegar los servicios del SAAI.

Trabajo realizado

• Respaldo protegido de la configuración antes de intervenir, y verificación previa de compatibilidad de la actualización.
• Actualización mayor de plataforma y sistema base en el servidor rezagado, completada sin pérdida de la configuración de red ni del canal de administración.
• Preparación del disco de 4 TB destinado al servidor de respaldos, dejado limpio para su asignación posterior.
• Definición de la topología de trabajo: máquinas separadas para cómputo acelerado, aplicación, datos y laboratorio, con reserva de capacidad para crecimiento.

Resultado

Ambos nodos arrancaron con la nueva versión y recuperaron red, acceso remoto y servicios sin incidencias. La topología quedó decidida antes de crear la primera máquina virtual.

Siguiente paso

Reservar la capacidad de cómputo acelerado para el proyecto y levantar las máquinas virtuales.

Qué cambió

El equipo inició la ejecución presencial del proyecto sobre los servidores asignados por la institución.

Trabajo realizado

• Instalación inicial de Proxmox VE.
• Configuración de la red de gestión.
• Habilitación de WireGuard para continuar la administración de forma segura.
• Verificación de conectividad y acceso remoto a los servidores.

Resultado

Los servidores quedaron operativos y accesibles mediante el canal privado de administración. Este hito marca el inicio efectivo de la ejecución técnica del SAAI.

Siguiente paso

Completar la topología virtual, el aislamiento de entornos y la estrategia de respaldo.

Qué cambió

El inventario del servidor asignado por la institución mostró que el equipo incluye una GPU dedicada de 16 GB de memoria, capacidad que el diseño original no requería.

Trabajo realizado

• Revisión del inventario real del equipo frente a lo previsto en el diseño.
• Replanificación del uso de la capacidad adicional sin ampliar el alcance comprometido.
• Actualización de la documentación técnica, que hasta entonces asumía un equipo sin GPU.

Resultado

La capacidad extra se destina a acelerar el procesamiento de los materiales del curso, con la ruta por procesador conservada como respaldo obligatorio. El modelo de lenguaje sigue siendo el servicio gestionado en la nube, tal como estaba comprometido, y a futuro la GPU habilita transcribir las clases dentro de la propia institución.

Siguiente paso

Preparar el servidor para que esa capacidad pueda entregarse a una máquina virtual del proyecto.

Qué cambió

La contraparte autorizó formalmente el inicio del servicio.

Resultado

Se activó la etapa de preparación de infraestructura y coordinación del entorno operativo.

Siguiente paso

Cerrar los habilitantes técnicos que permiten iniciar el cronograma funcional.

Qué cambió

La primera fase quedó organizada en tres entregas funcionales.

Resultado

El alcance separa ingesta y contexto, chat RAG con trazabilidad, y dashboard con puesta en producción.

Siguiente paso

Ejecutar los sprints cuando el entorno institucional quede declarado operativo.

Qué cambió

La universidad aprobó el proyecto de investigación sobre asistencia académica con IA generativa y recuperación aumentada de información. El SAAI es el sistema que lo implementa.

Resultado

Quedó definido el marco de trabajo: un asistente que responde sobre los materiales del curso citando la fuente, y que registra las interacciones como instrumento de la investigación.

Siguiente paso

Traducir los objetivos del proyecto a un alcance técnico ejecutable por fases.