Inventario: qué se probó y qué quedó verificado como viable
← Volver a la página de la ponencia
Reúne todo lo que se exploró en el laboratorio del 7 y el 8 de noviembre de 2026,
ordenado por los objetivos del proyecto y por el escenario del docente. No describe cómo se hizo cada cosa: cuenta qué se probó y qué
quedó verificado.
Cómo leer el estado de cada ítem
| Estado | Qué significa |
|---|---|
| Verificado | Se probó de punta a punta y funcionó, con los registros guardados |
| Verificado (local) | Además corrió en el equipo, sin internet y sin placa de video |
| Verificado (modelo de la clase) | Funcionó con un modelo de pesos abiertos de hasta 31 mil millones de parámetros, la clase que el proyecto define como compacta, pero servido desde la nube porque el equipo no tiene placa de video. Falta repetirlo en el servidor del proyecto |
| Con límites | Funciona, pero la prueba mostró un límite concreto |
| Pendiente | Está pensado o planificado, sin verificar |
La estrategia que se puso a prueba
Asistentes focalizados, no agentes de alcance global. En vez de un agente al que se le da una tarea amplia y se
confía en que el modelo la resuelva, cada asistente tiene un solo propósito, atado a una actividad. Lo sostiene una
estructura determinística sólida: el código decide el recorrido, cuenta, valida y guarda. El modelo de lenguaje se
usa solo para lo que no se puede programar: redactar, interpretar, clasificar.
Lo que la sostiene, con evidencia:
- Una herramienta general no sabe qué se está aprendiendo. La IA integrada de Moodle escribió una tarea completa
en 2,5 segundos cuando una estudiante se la pidió. El asistente de esa misma tarea se negó dos veces y la guio.
- Lo que controla el código se cumple siempre. Las reglas que solo están en la instrucción se cumplen casi
siempre: una sola respuesta correcta, sin caminos sin salida, con tildes, sin inventar estados.
- Un prompt grande no se vuelve confiable con más reglas. El asistente de análisis de foros, escrito para un
modelo grande, funcionó en uno compacto recién cuando el código pasó a conducir la conversación. Los pedidos al
modelo para una síntesis bajaron de 25 a 7.
- Una regla abstracta puede no alcanzar, y hay que medirla. La primera corrección de un asistente no cambió nada
en tres de tres pruebas. Funcionó nombrar la conducta y mostrar un ejemplo.
- Cuando el esquema no alcanza, el modelo improvisa. Esas improvisaciones señalan qué capacidad falta agregar a la
estructura.
Por objetivo específico del proyecto
OE1. Indagar los modelos compactos de código abierto y sus requerimientos
| Qué | Estado | Lo que se observó |
|---|---|---|
| Un modelo de 31 mil millones de parámetros (Gemma 4, pesos abiertos) para todo el texto: asistentes, informes, guiones, recursos | Verificado (modelo de la clase) | Asistentes en 2 a 5 s; las piezas de un recurso, válidas casi siempre al primer o segundo intento |
| Un modelo chico (Gemma 4 E2B) en una notebook sin placa de video | Verificado (local) | Funciona como respaldo, pero lento: 115 s por respuesta. Sirve para tareas acotadas |
| Búsqueda en el material del curso (embeddings) | Verificado (local) | Liviana en CPU |
| Voz rioplatense (Piper) | Verificado (local) | Tres veces más rápida que el audio, en CPU |
| Transcripción de voz con un modelo abierto | Con límites | Más lenta que el audio en CPU; pasa el voseo a tuteo («puedes» por «podés») y confunde palabras |
| Leer capturas de pantalla con un modelo chico con visión | Verificado (local) | Nombres, fechas y textos exactos; omitió una oración. 46 a 118 s |
| Generar imágenes con modelos de difusión | No viable en CPU | Las imágenes se resolvieron con diagramas e infografías dibujadas por código |
| Requisitos de memoria | Verificado | En 15 GB de RAM entra un modelo local a la vez; el equipo se trabó una vez por falta de memoria |
| Rendimiento de los modelos de hasta 31B en el servidor del proyecto (placa de consumo) | Pendiente | Es el próximo paso del cronograma |
OE2. Beneficios de ejecutar los modelos localmente
| Qué | Estado | Lo que se observó |
|---|---|---|
| Que el modelo nunca vea un nombre de estudiante | Verificado | El código cambia nombres por rótulos antes de cada pedido. Una prueba automática de 6 conversaciones (23 turnos) revisó todo lo que salía: ningún nombre |
| Anonimizar un texto sin que salga del equipo | Verificado (local) | Reglas para documentos, teléfonos, correos y domicilios, más un modelo chico local para los nombres sueltos. Unos 2 minutos por página en CPU |
| El modelo chico para lo privado y lo acotado | Verificado (local) | Anonimizar, transcribir capturas y servir de respaldo: es el papel natural de un modelo chico |
| Moodle como memoria institucional | Verificado | Los foros, los avisos a docentes, el registro de cada uso de IA y las notas quedan en la plataforma de la institución |
| Respaldo sin internet para la IA de Moodle | Verificado (local) | Moodle pasa solo al modelo local si la nube no responde |
| Formatos abiertos y recetas reproducibles | Verificado | Todo se reinstala desde cero con recetas versionadas; los recursos quedan en HTML y SCORM |
| Costo: todo con software libre en una notebook | Verificado | Sin licencias. La inferencia de texto grande se probó con un modelo abierto alojado |
| Lengua: voseo, lenguaje claro, sin marcas de género | Verificado, con límites | Se logra con reglas y controles. Los modelos de transcripción todavía no respetan el voseo |
OE3. Prototipo integrado a Moodle para el aprendizaje autónomo y la personalización
| Qué | Estado | Lo que se observó |
|---|---|---|
| IA integrada de Moodle (generar texto, resumir, explicar) conectada a modelos propios | Verificado | Respuestas en 1 a 3 s; política de uso y registro de cada pedido. Sin guion: sirve a la docente, no protege la tarea |
| Ayudante de la tarea: explica la consigna, no la resuelve | Verificado (modelo de la clase) | Se negó dos veces a escribir la tarea y guio |
| Evaluador socrático sobre una lectura | Verificado (modelo de la clase) | Pregunta de a una y cierra con una síntesis |
| Examen oral de práctica | Verificado (modelo de la clase) | Distingue respuestas buenas y flojas y devuelve qué repasar |
| Orientador en el foro de un trabajo grupal o individual | Verificado (modelo de la clase) | Con 6 estudiantes en 2 grupos: 9 respuestas, 1 pregunta derivada a la docente, silencio cuando no correspondía |
| Coordinador del foro: avisa a la docente lo que nadie atendió | Verificado | Cada pregunta, una sola vez, con enlace |
| Informes para la docente: resumen del foro, borradores de devolución, preguntas para el banco | Verificado (modelo de la clase) | Borradores, nunca publicados sin la docente |
| Recursos interactivos con nota en el libro de calificaciones | Verificado | Autoevaluaciones, historias ramificadas y explorables. Una autoevaluación de 6 preguntas en unos 20 s; la nota llegó al libro (67 y 63) |
| Láminas y videos narrados con voz rioplatense | Verificado | Desde un pedido, un PDF, una presentación o un proyecto de láminas |
| Agentes para un Moodle que no se puede configurar | Verificado | Ver el escenario 2 |
| El límite entre orientar y resolver | Con límites | El ayudante y el orientador dieron a veces ejemplos demasiado cercanos a la respuesta |
OE4. Evaluar el prototipo con distintos perfiles de estudiantes
| Qué | Estado |
|---|---|
| Casos simulados: una semana con una docente y tres estudiantes; foros con seis estudiantes en dos grupos | Verificado, con cuentas de prueba y textos de guion |
| Medición de cada cambio de instrucción: las mismas escenas, tres veces antes y tres después | Verificado |
| Piloto en el campus virtual del CURZA con estudiantes reales | Pendiente (año 3 del cronograma) |
| Evaluación de autonomía, personalización e inclusión, pre y post | Pendiente |
Por escenario del docente
Escenario 1. Moodle propio, en su última versión, con los servidores complementarios
La institución o el docente puede instalar y configurar Moodle desde cero y sumar los servicios de IA (servidor de
modelos, automatizaciones, chat, estudio de recursos). Tiene a disposición todo lo verificado:
- la IA integrada de Moodle con modelos propios y respaldo local;
- asistentes por actividad para estudiantes: ayudante de la tarea, socrático, oral;
- asistentes en el foro: orientador y coordinador, con el foro como memoria;
- informes y borradores para la docente;
- recursos con nota en el libro de calificaciones;
- todo lo del escenario 2 y lo común a los dos.
Escenario 2. El Moodle de la institución, que no se puede configurar
El docente no elige la versión ni instala nada en Moodle, pero puede usar las demás herramientas. Hay dos puentes,
según lo que pueda dar:
| Lo que puede dar | Qué se verificó |
|---|---|
| Una dirección del aula y un usuario con contraseña, el suyo o el de una cuenta de asistente que él mismo matricula | Un asistente entra al aula como lo haría una persona, lee los foros que el docente nombra y le arma un informe: preguntas sin responder, las que solo respondió un asistente, quién no escribió. Con la cuenta del docente solo lee; con la de asistente también responde en el foro y le escribe al docente. Si la institución tiene habilitada la app oficial de Moodle, la misma cuenta usa esa vía |
| Solo la exportación del foro (la puede hacer cualquier docente) | Informe de foro: devolución por participante, artefactos y preguntas con evidencia. Síntesis de foro: preguntas frecuentes, un mensaje de portada y qué hilos se pueden podar. Con cada exportación nueva, qué cambió. El modelo no ve ningún nombre |
Límites verificados: no se automatiza un ingreso con doble factor, captcha o inicio de sesión institucional único;
en ese caso queda la exportación. El asistente por navegador se probó en Moodle 5.3; falta probarlo en un Moodle
institucional y en versiones anteriores.
Común a los dos escenarios
No depende de tocar Moodle:
- láminas desde un pedido en lenguaje natural;
- videos explicativos narrados con voz rioplatense y subtítulos, desde un PDF, una presentación o un proyecto de
láminas;
- recursos interactivos (autoevaluaciones, historias ramificadas, explorables) que se suben como paquete SCORM
con nota, o como archivo; funcionan en el celular y sin internet;
- diseñadores conversacionales en el chat para producir esos materiales;
- el anonimizador, para compartir textos sin datos personales.
Ideas de trabajo con modelos locales
Ordenadas por el equipo que hace falta. Las de la notebook ya se verificaron en local; las demás son propuestas a
medir en el servidor del proyecto.
| Equipo | Idea | Estado |
|---|---|---|
| Notebook sin placa de video | Narrar en voz rioplatense recursos, consignas y textos, para accesibilidad | Verificado (local) |
| Notebook sin placa de video | Anonimizar informes, registros y casos antes de compartirlos o de mandarlos a cualquier modelo | Verificado (local) |
| Notebook sin placa de video | Buscar en el material del curso para responder solo con lo que dice | Verificado (local) |
| Notebook sin placa de video | Transcribir capturas de un foro o de un aula sin que salgan del equipo | Verificado (local) |
| Notebook sin placa de video | Respaldo cuando no hay internet: lento, pero el aula no se queda sin herramienta | Verificado (local) |
| PC con placa de video de consumo | Los asistentes por actividad y los informes de foros con el modelo en la institución | Pendiente: medir calidad y tiempos |
| PC con placa de video de consumo | Producir recursos interactivos, láminas y videos sin depender de la nube | Pendiente |
| Cualquiera | Repaso desde el foro: las dudas que detecta el coordinador generan una autoevaluación | Propuesta |
| Cualquiera | Del recurso al asistente: al final de una autoevaluación, un enlace al asistente de esa actividad | Propuesta |
Lo que todavía no está confirmado
- La calidad de los textos con modelos locales en una placa de consumo: el diseño lo hace posible, pero no se midió.
- El efecto con estudiantes reales y docentes reales.
- La transcripción de voz fiel al voseo.
- El límite entre orientar y resolver.
- Un registro único de todas las interacciones, para la investigación.