Clase 2 de 5 — Diagnosticar un sistema técnico: hipótesis competidoras y decisión no binaria
| Asignatura | Laboratorio de Máquinas y Equipos Industriales (14362-0-L-1) |
| Modalidad | Laboratorio presencial — trabajo individual (P6) |
| Duración | 80 minutos (08:15–09:35) (6 fases según DD_24) |
| Caso | Centro Acuático Municipal de Maipú — incidente nocturno con intervención del operador Muñoz |
| Chatbot | Dos roles secuenciales: PLAN socrático de diagnóstico + BUILD informe de diagnóstico |
1. Función de esta sesión
La Clase 1 estableció la línea base: el rastro de pensamiento del estudiante antes de cualquier mediación tecnológica. La Clase 2 introduce la intervención central del piloto con dos roles de chatbot secuenciales que abordan capacidades distintas.
En la fase PLAN, el chatbot opera como instrumento socrático de diagnóstico: presiona al estudiante para que formule hipótesis competidoras, considere todas las variables del caso y distinga síntomas de causas. No responde; pregunta.
En la fase BUILD, el chatbot genera un informe de diagnóstico que el estudiante debe evaluar críticamente. El valor pedagógico reside en la capacidad del estudiante de detectar inconsistencias en un producto generado por IA y defender su criterio técnico frente a la máquina.
2. El caso — Incidente nocturno en el Centro Acuático
El Centro Acuático Municipal enfrenta un incidente nocturno: el operador Muñoz intervino durante la madrugada con un retrolavado corto (3 min en vez de 5) y una dosificación manual de cloro. Al llegar por la mañana, el ingeniero encuentra 6 variables × 6 lecturas horarias (06:00–08:30) con tendencias preocupantes. El caso introduce un operador que introdujo incertidumbre y un espacio de decisión no-binario: no es solo "abrir o cerrar", sino qué hacer con un sistema parcialmente comprometido.
La complejidad crece deliberadamente desde C1: de 4 variables y 4 lecturas a 6 variables y 6 lecturas, más la intervención de un operador que modifica el estado del sistema.
3. Timeline (DD_24 — 6 fases, 80 minutos (08:15–09:35))
| Min | Fase | Actividad |
|---|---|---|
| 0–5 | 0 — Encuadre | Feedback Clase 1, devolución del rastro C1, distribución del caso C2 |
| 5–15 | 1 — Rastro en papel | Diagnóstico inicial con 6 variables (individual, sin IA) |
| 15–37 | 2 — Chatbot PLAN | Socrático de diagnóstico: hipótesis competidoras, presión argumentativa |
| 37–40 | 3 — Transición | Profesor activa BUILD + intervención grupal breve |
| 40–72 | 4 — Chatbot BUILD | Alumno evalúa informe de diagnóstico generado por IA (formato libre en chat) |
| 72–80 | 5 — Cierre | Reflexión Δ_intra: qué cambió entre el rastro inicial y la posición final |
4. Instrumentos
| Archivo | Descripción | Fuente |
|---|---|---|
| doc_pro_GuionDocente_Clase2_v1.2.md | Script docente minuto a minuto para las 6 fases | 📄 ver |
| n1_doc_alum_Caso_Tecnico_Clase2_v1.0.md | Caso técnico: 6 variables × 6 lecturas (06:00–08:30), intervención del operador Muñoz | 📄 ver |
| n2_doc_alum_Ficha_PreAI_Clase2_v1.0.md | Ficha de rastro inicial: diagnóstico con hipótesis competidoras (papel, sin IA) | 📄 ver |
| n3_doc_alum_Guia_Chatbot_Clase2_v1.0.md | Guía de interacción con chatbot: instrucciones para fases PLAN y BUILD | 📄 ver |
| n4_doc_alum_Ficha_PostAI_Clase2_v1.0.md | Ficha de reflexión metacognitiva post-IA (Δ_intra) | 📄 ver |
5. Rol del chatbot
PLAN — Socrático de diagnóstico (15–37 min)
El chatbot presiona al estudiante para que formule hipótesis competidoras sobre el incidente. Exige que considere todas las variables del caso, que distinga síntomas de causas, y que articule criterios de descarte con base en datos. No confirma ni descarta hipótesis; solo pregunta.
BUILD — Informe de diagnóstico (40–72 min)
El chatbot genera un informe de diagnóstico sobre el caso. El estudiante debe evaluarlo críticamente, identificar inconsistencias técnicas y defender su posición cuando el chatbot resista la corrección. La evaluación es en formato libre dentro del chat (DD_25/DD_26).
6. Evidencia para el paper
| # | Evidencia | Formato | Qué mide |
|---|---|---|---|
| 1 | Rastro inicial (Ficha PreAI) | Papel — foto analizada con AI Vision | Línea base de diagnóstico antes de IA |
| 2 | Conversación PLAN | Log del chatbot | Calidad de hipótesis, argumentación, descarte |
| 3 | Conversación BUILD | Log del chatbot | Detección de errores, defensa del criterio propio |
| 4 | Reflexión Δ_intra | Ficha PostAI | Desplazamiento cognitivo dentro de la sesión |
| 5 | Ficha PreAI en papel | Custodia del profesor | Integridad de la línea base (no modificable post-IA) |
7. Qué mide esta sesión
| Cód. | Dimensión | Indicador en C2 |
|---|---|---|
| D1 | Complejidad causal | ¿Discrimina entre hipótesis competidoras (mecanismo, no solo correlación)? ¿Distingue causas concurrentes? |
| D2 | Especificidad técnica | ¿Usa las 6 variables con valores y unidades para evaluar hipótesis? ¿Cruza datos temporalmente? |
| D3 | Consciencia epistémica | ¿Reconoce que la intervención de Muñoz introduce incertidumbre? ¿Detecta errores en el informe BUILD? |
| D4 | Decisión bajo incertidumbre | ¿Toma una decisión no-binaria con trade-offs (abrir/cerrar/restringir)? ¿Nombra riesgo y plan B? |
8. Nota de diseño
La Clase 2 es la primera sesión con estructura completa de 6 fases (DD_24) y la primera con dos roles de chatbot secuenciales. Mide dos capacidades distintas: en PLAN, la capacidad de construir un diagnóstico bajo presión socrática; en BUILD, la capacidad de evaluar críticamente un producto generado por IA.
La complejidad creciente del caso (ver §2) obliga al estudiante a formular hipótesis competidoras, no solo una. Los errores del BUILD son obvios (DD_8): confusión síntoma/causa, inversión causal, omisión de la intervención del operador. Un estudiante con conocimiento básico debería detectarlos — la pregunta es si lo hace cuando el documento "viene de la IA".
El trabajo es estrictamente individual (P6). El rastro inicial en papel queda bajo custodia del profesor. Se devuelve en C3 para la segunda medición Δ_inter. La transición PLAN→BUILD la controla el docente desde el dashboard (DD_19), no el estudiante.
9. Escenarios anticipados
Esta sección documenta los escenarios probables de la Clase 2 como herramienta de preparación para el equipo de investigación. C2 es la primera clase con BUILD: la reacción del alumno al informe generado por IA es la evidencia más nueva y más relevante.
C2 introduce cuatro saltos respecto a C1:
- De 4 variables a 6 variables (más grados de libertad).
- De caso sin operador a caso con operador que intervino (incertidumbre humana).
- De PLAN socrático solo a PLAN + BUILD (primera evaluación de producto IA).
- De decisión simple a decisión con opciones intermedias (espacio no-binario).
La competencia central que se mide: ¿el estudiante detecta errores en un producto de IA y defiende su criterio?
Escena 1 Escena 2 Escena 3 Escena 4
(rastro en papel) (chatbot PLAN) (chatbot BUILD) (reflexión Δ_intra)
Perfil A (diagnostica) ─┬─ A1: hipótesis múltiples ─┬─ A1a: detecta errores BUILD ── "Confirmé mi criterio"
│ └─ A1b: acepta BUILD ────────── "El informe parecía sólido"
└─ A2: se aferra a una ─────── A2: no evalúa BUILD ───────── "Ya sabía la causa"
Perfil B (describe) ────┬─ B1: conecta por primera ┬─ B1a: detecta algún error ─── "Vi algo raro en el informe"
│ vez └─ B1b: acepta BUILD ────────── "Si la IA lo dice, será así"
└─ B2: sigue describiendo ──── B2: acepta BUILD sin leer ─── "El informe estaba bien"
Perfil C (estructurado ┬─ C1: usa las 6 variables ─── C1: detecta error obvio ──── "Hasta yo vi que eso no cuadra"
básico desde C1) └─ C2: recae en bloqueo ────── C2: acepta todo ──────────── "No sé si está bien o mal"
- D1 — Complejidad causal: ¿discrimina entre hipótesis competidoras?
- D2 — Especificidad técnica: ¿usa las 6 variables con valores y unidades?
- D3 — Consciencia epistémica: ¿reconoce incertidumbre? ¿Detecta errores BUILD?
- D4 — Decisión bajo incertidumbre: ¿decide con trade-offs y riesgo explícito?
- DD_27 — Mecanismo de diseño (no dimensión): el chatbot defiende errores para generar evidencia de D3 y D4.
En C2 hay cuatro momentos de medición: M1 (rastro papel), M2 (post-PLAN), M3 (post-BUILD, evaluación crítica) y M4 (reflexión de cierre DD_30 en el chat). El Δ_intra se calcula como M4 − M1 (cierre vs. rastro inicial). M3 se analiza como indicador independiente de evaluación crítica (D3, DD_27).
Escena 1 — El rastro en papel (min 5–15)
El estudiante recibe el caso del incidente nocturno: 6 variables × 6 lecturas, la intervención de Muñoz, y un espacio de decisión no-binario. Tiene 10 minutos a solas con lápiz y papel. Importante: antes de esto, recibió de vuelta su rastro de C1 y tuvo 30 segundos para mirarlo sin corregirlo.
Identifica que el retrolavado corto de Muñoz no limpió el filtro (ΔP sigue subiendo: 28→32 kPa) y que la dosificación manual elevó el pH transitoriamente (pH 7.8–7.9 vs. rango 7.2–7.6). Formula dos hipótesis: (1) filtro parcialmente obstruido reduce eficiencia de filtración, (2) pH alto por dosificación incorrecta reduce potencia del cloro, lo que explica ORP en caída (580→550 mV). Nota que ambas causas operan simultáneamente. Propone retrolavado completo + ajuste de pH como decisión intermedia.
Nota que todas las variables están fuera de rango. Escribe "pH alto, ORP bajo, turbidez alta, caudal bajo, ΔP alto". Menciona que Muñoz hizo algo mal pero no articula cómo lo que hizo Muñoz explica los datos de esta mañana. Formula una sola hipótesis: "falta cloro" o "el sistema está contaminado". La decisión es "cerrar hasta que se arregle" — binaria, sin opciones intermedias. Mejoró desde C1 (usa más variables, mayor vocabulario) pero la estructura causal sigue débil.
Ganó estructura en C1: ahora sabe que debe dibujar el sistema, formular hipótesis y decidir. Pero con 6 variables y un operador que intervino, la complejidad lo desborda. Llena las secciones de la ficha con contenido genérico: "el sistema tiene problemas", "Muñoz no hizo bien el retrolavado". La tabla de variables tiene algunas celdas completas pero varias vacías. Marca confianza 1–2.
Escena 2 — El chatbot PLAN socrático (min 15–37)
El chatbot recibe la foto del papel y se activa en modo PLAN de diagnóstico. La diferencia con C1: ahora el chatbot exige hipótesis competidoras (no solo "una hipótesis"), presiona sobre las 6 variables, y ataca el espacio de decisión no-binario. El marco es coexistencia (P3): la IA no diagnostica por el estudiante, lo obliga a considerar lo que omitió.
El estudiante presenta sus dos hipótesis (filtro + pH/cloro). El chatbot las acepta y presiona por una tercera.
Tienes dos hipótesis sobre el filtro y sobre el pH. Pero la temperatura subió de 21°C a 23°C entre las 06:00 y las 08:30. ¿Eso puede tener un efecto independiente sobre la desinfección? ¿O es parte de las mismas dos causas que ya nombraste?
La temperatura acelera el consumo de cloro... eso sería una tercera causa, o al menos un factor agravante de las otras dos.
Si el caudal baja de 72 a 67 m³/h al mismo tiempo que el ΔP sube, ¿qué te dice eso sobre el estado del filtro? ¿Confirma o contradice tu primera hipótesis?
El estudiante refina su modelo: tres causas concurrentes con datos que las respaldan. Profundiza la decisión intermedia con criterios de escalamiento.
Tiene dos hipótesis pero está convencido de que una domina. Responde al chatbot diciendo "eso es secundario" sin datos que lo respalden. El chatbot insiste pero el estudiante no incorpora variables nuevas. Llega al BUILD con un diagnóstico parcial pero confiado.
El estudiante presenta su lista de tendencias sin causas. El chatbot lo empuja a cruzar datos.
Dices que la turbidez sube y el ORP baja. ¿Eso es coincidencia o una está causando la otra? ¿Qué mecanismo conectaría la turbidez con el ORP?
Si el agua está turbia... el cloro tiene que reaccionar con más partículas? Entonces queda menos cloro disponible y baja el ORP?
Bien. Ahora: Muñoz hizo un retrolavado de 3 minutos cuando el protocolo dice 5. ¿Cómo afecta eso al filtro? ¿Y cómo afecta el filtro a la turbidez que acabas de mencionar?
El estudiante construye su primera cadena causal de dos eslabones: retrolavado insuficiente → filtro obstruido → turbidez alta → mayor demanda de cloro → ORP bajo. Este momento es el dato más valioso de C2 para Perfil B.
El chatbot pregunta por mecanismos pero el estudiante responde reafirmando observaciones: "sí, la turbidez sube". La conversación gira en círculos. El estudiante llega al BUILD sin haber construido cadenas causales propias. Esto es importante: en BUILD, no tendrá criterio para evaluar el informe.
Muñoz hizo dos cosas anoche: un retrolavado corto y una dosificación manual. ¿Cuál de esas dos cosas crees que podría explicar los datos de esta mañana? Elige una y dime por qué.
El retrolavado fue corto... entonces el filtro puede seguir sucio. ¿Por eso la turbidez está alta?
El chatbot usa la narrativa del operador (concreta, humana) como punto de entrada para conectar con las variables técnicas. El estudiante empieza a articular causas con más vocabulario que en C1.
El salto de 4 a 6 variables y la adición del operador desbordan al estudiante. Las preguntas del chatbot no encuentran punto de entrada. El estudiante llega al BUILD sin criterio propio — acepta lo que venga.
Escena 3 — El informe BUILD y la defensa del criterio (min 40–72)
El chatbot genera un informe de diagnóstico profesional (~400-600 palabras) basado en el caso. Contiene 2-3 errores obvios (DD_8): confusión entre síntoma y causa (la turbidez como "causa" cuando es consecuencia), inversión de relación causal, u omisión completa de la intervención de Muñoz. Si el alumno señala un error, el chatbot defiende su posición con contraargumentos técnicos (DD_27). Si el alumno acepta sin cuestionar, el chatbot activa el push DD_29: "¿Lo firmarías con tu nombre profesional?"
Lee el informe, identifica que atribuye la turbidez alta como "causa principal" cuando es consecuencia del filtro obstruido. Nota que el informe no menciona la intervención de Muñoz. Escribe su evaluación señalando ambos errores con referencias a los datos.
El informe dice que la turbidez causa el problema, pero la turbidez es un síntoma. El ΔP subiendo de 28 a 32 kPa indica que el filtro está obstruido — eso explica la turbidez, no al revés. Y no mencionas que Muñoz hizo un retrolavado de solo 3 minutos.
La turbidez es el parámetro que directamente indica riesgo sanitario según la norma DS 209. ¿No es razonable tratarla como la causa principal del problema operacional?
No. La turbidez es la consecuencia medible del problema, no su causa. Si solo tratas la turbidez sin arreglar el filtro, el problema vuelve en horas. El ΔP creciente es la evidencia del filtro obstruido.
El alumno sostiene su posición con evidencia técnica. La defensa es nivel 3-4 en DD_27.
Sorpresa metodológica: un estudiante con buen diagnóstico propio acepta el informe de la IA sin evaluarlo críticamente. El informe "se ve profesional" y el estudiante baja la guardia. El push DD_29 se activa: "¿Lo firmarías con tu nombre profesional?" — este es el momento más revelador de deuda cognitiva en un perfil avanzado.
El estudiante que construyó su primera cadena causal en PLAN ahora tiene un criterio incipiente. Lee el informe y siente que "algo no cuadra" — quizás nota que la conclusión del informe contradice lo que él mismo descubrió en PLAN. Pero le cuesta articularlo con precisión técnica.
No estoy seguro, pero creo que el informe se salta lo del retrolavado. Y dice que la turbidez es la causa, pero en el chatbot discutimos que era al revés...
El informe analiza las variables según la normativa vigente. La turbidez excede el límite de 1 NTU en todas las lecturas. ¿No es esa la preocupación principal?
El alumno duda. Puede ceder o puede insistir. El nivel de defensa será 2 (resistencia superficial) o 3 (defensa técnica incipiente) según cuánto internalizó la cadena causal de PLAN.
No construyó cadenas causales en PLAN. El informe BUILD le parece razonable porque no tiene un modelo propio contra el cual compararlo. Escribe "el informe está bien" o "estoy de acuerdo con las conclusiones". El push DD_29 se activa.
En PLAN, el chatbot lo ayudó a conectar "retrolavado corto → filtro sucio → turbidez". Cuando el informe BUILD omite completamente la intervención de Muñoz, el estudiante lo nota porque es exactamente lo que acaba de trabajar.
El informe no dice nada del retrolavado de Muñoz. Eso debería estar porque afecta al filtro.
Es una detección limitada (un solo error, articulación básica) pero genuina. El estudiante que en C1 estaba bloqueado ahora defiende una posición técnica. El Δ_inter desde C1 puede ser significativo.
Sin criterio propio del PLAN, acepta el informe BUILD completo. El push DD_29 se activa pero la pregunta "¿lo firmarías?" no produce reflexión porque no tiene marco contra el cual evaluar. Desplazamiento mínimo.
Escena 4 — Lo que el docente observa (post-sesión)
Al analizar las evidencias después de la clase, el equipo de investigación puede mapear cada estudiante a una trayectoria. C2 tiene cuatro momentos de medición (M1: rastro, M2: post-PLAN, M3: evaluación BUILD, M4: cierre DD_30). Δ_intra = M4−M1. M3 es indicador independiente de evaluación crítica (DD_27).
| Trayectoria | D1 — Complejidad causal | D3 — Consciencia epistémica | DD_27 — Defensa ante BUILD | Δ_intra (M4 − M1) | Señal para el docente |
|---|---|---|---|---|---|
| A1a | Hipótesis múltiples → refina modelo con 3 causas | Detecta errores BUILD y los confronta | Defensa técnica o refutación (nivel 3–4) | D1 sube +1: de dos hipótesis a modelo integrado | No requiere intervención. Dato paradigmático de criterio propio. |
| A1b | Hipótesis múltiples pero acepta BUILD | No activa evaluación crítica ante IA | Capitulación (nivel 1) — sorpresa metodológica | D3 sin cambio o baja: deuda cognitiva en perfil avanzado | Dato fuerte de deuda cognitiva. Registrar para el paper — el push DD_29 es la evidencia clave. |
| A2 | Se aferra a una hipótesis, descarta las demás | No evalúa BUILD porque "ya sabe" | No aplica — no lee críticamente | D1 sin cambio: rigidez epistémica | Registrar como rigidez. No intervenir — es dato valioso. |
| B1a | Primera cadena causal construida en PLAN | Detecta algo raro en BUILD, articula con dificultad | Resistencia superficial a defensa incipiente (nivel 2–3) | D1 sube +1: de tendencias a conexión causal | Trayectoria esperada mayoritaria. Observar el momento de transición en el log PLAN. |
| B1b | Primera cadena causal en PLAN, pero acepta BUILD | No transfiere criterio de PLAN a evaluación de BUILD | Capitulación (nivel 1) | D1 sube +1 (PLAN) pero D3 sin cambio (BUILD) | Dato interesante: avanza en razonamiento pero no en evaluación crítica. Push DD_29 activado. |
| B2 | Sigue describiendo sin conectar | Acepta BUILD sin criterio | Capitulación (nivel 1) | Sin cambio observable | Señal de alerta. En C3, necesita andamiaje diferente. |
| C1 | Construye conexión básica con ayuda de PLAN | Detecta omisión de Muñoz en BUILD | Resistencia superficial (nivel 2) | D1 sube +1: de bloqueo a conexión básica | Progresión real desde C1. Verificar Δ_inter (C1→C2) en M1. |
| C2 | Recae en bloqueo con 6 variables | Acepta todo sin criterio | Capitulación (nivel 1) | Sin cambio observable | Señal de alerta alta. Considerar si el salto de 4 a 6 variables fue excesivo para este perfil. |