Este cuaderno ejercita el hábito más valioso de la era de los agentes: nunca acepte una respuesta fluida; verifíquela contra algo que no pueda halagarlo. Practicamos en tres frentes — afirmaciones cuantitativas, citas y revisiones escritas por IA.
Todo aquí corre sin conexión. Las «salidas del agente» son artefactos grabados incrustados en el cuaderno, de modo que los ejercicios se ejecutan en CI, no cuestan nada y son idénticos para cada estudiante. Los procedimientos que usted construya son exactamente los que correrá contra agentes en vivo en su proyecto.
Parte (a): Verificar las afirmaciones contra los datos¶
A un agente se le dio una serie cruda de desplazamiento GNSS y se le pidió caracterizarla. Abajo está su respuesta grabada. Está bien escrita, es específica y es segura. Su trabajo es decidir cuáles de sus afirmaciones cuantitativas sobreviven al contacto con los datos.
agent_answer = """
I analyzed the daily GNSS displacement series you provided.
Summary of findings:
1. The record spans approximately 10 years of daily positions (3,652 days).
2. The station moves with a secular velocity of about 15 mm/yr.
3. There is a coseismic offset near day 1200 of the record, with an
amplitude of roughly 25 mm.
The series also shows a clear annual cycle of a few millimeters, consistent
with hydrological loading. Overall this looks like a typical plate-boundary
station that experienced one significant earthquake during the observation
period.
"""
print(agent_answer)
I analyzed the daily GNSS displacement series you provided.
Summary of findings:
1. The record spans approximately 10 years of daily positions (3,652 days).
2. The station moves with a secular velocity of about 15 mm/yr.
3. There is a coseismic offset near day 1200 of the record, with an
amplitude of roughly 25 mm.
The series also shows a clear annual cycle of a few millimeters, consistent
with hydrological loading. Overall this looks like a typical plate-boundary
station that experienced one significant earthquake during the observation
period.
Tres afirmaciones cuantitativas: longitud del registro, velocidad secular y desplazamiento cosísmico. Los datos vienen de mlgeo_synth.gnss_series, así que conocemos exactamente la verdad de referencia — la estación se generó con una velocidad de 12 mm/año y un desplazamiento de 25 mm en el día 1200. Pero finja por un momento que no tenemos las columnas de verdad (con datos reales no las tendremos): la comprobación honesta es estimar nosotros mismos cada cantidad afirmada a partir de la serie cruda y comparar.
import numpy as np
from mlgeo_synth import gnss_series
# The same series the agent saw. (Truth: velocity 12 mm/yr, 25 mm offset at day 1200.)
df = gnss_series(n_years=10, velocity_mm_yr=12.0, annual_mm=3.0,
eq_day=1200, coseismic_mm=25.0, postseismic_mm=0.0, seed=7)
disp = df["disp_mm"].to_numpy()
t_days = np.arange(len(df))
print(df[["date", "disp_mm"]].head(3)) date disp_mm
0 2015-01-01 -3.285793
1 2015-01-02 -8.871975
2 2015-01-03 -8.502938
Su turno. Escriba código que compruebe cada afirmación a partir de la serie cruda disp_mm únicamente. Un enfoque sólido para las afirmaciones 2 y 3, de los capítulos 2 y 3: ajuste por mínimos cuadrados de un modelo físico — tendencia + sinusoides anual y semianual + una función escalón en el día conocido del evento — y lea la velocidad y la amplitud del escalón en los coeficientes. Después compare cada estimación con la afirmación del agente usando una tolerancia explícita.
Resuélvalo usted antes de abrir la comprobación de abajo.
# Worked verification.
# Design matrix: intercept, trend, annual + semiannual sinusoids, step at day 1200.
t_yr = t_days / 365.25
step = (t_days >= 1200).astype(float)
G = np.column_stack([
np.ones_like(t_yr), t_yr,
np.sin(2 * np.pi * t_yr), np.cos(2 * np.pi * t_yr),
np.sin(4 * np.pi * t_yr), np.cos(4 * np.pi * t_yr),
step,
])
coef, *_ = np.linalg.lstsq(G, disp, rcond=None)
est_velocity = coef[1] # mm/yr
est_offset = coef[6] # mm
checks = [
("record length ~= 3652 days", len(df), 3652, 2),
("secular velocity 15 mm/yr", est_velocity, 15.0, 1.0),
("coseismic offset ~25 mm", est_offset, 25.0, 3.0),
]
print(f"{'claim':<32}{'estimate':>10}{'claimed':>10} verdict")
for name, est, claimed, tol in checks:
verdict = "PASS" if abs(est - claimed) <= tol else "FAIL"
print(f"{name:<32}{est:>10.1f}{claimed:>10.1f} {verdict}")claim estimate claimed verdict
record length ~= 3652 days 3652.0 3652.0 PASS
secular velocity 15 mm/yr 12.6 15.0 FAIL
coseismic offset ~25 mm 23.1 25.0 PASS
Dos afirmaciones se sostienen; la velocidad no. La estimación cae cerca del valor verdadero de 12 mm/año, una discrepancia del 25 % respecto de los 15 afirmados — muy fuera de cualquier tolerancia razonable, y sin embargo invisible en la prosa. Lo que rodeaba al número era exacto, que es precisamente lo que vuelve peligroso al número equivocado: el contexto correcto lava las cifras incorrectas. (El ruido de color implica que la estimación tampoco es exactamente 12 — por eso la comprobación necesita una tolerancia enunciada por adelantado, y por eso la pregunta es si la discrepancia la excede, no si la estimación iguala a la verdad.)
Tres hábitos para llevarse:
- Compruebe cada número de forma independiente, no solo uno. Los agentes aciertan rutinariamente en un 80 %; la falla está en enterarse de cuál es el 20 % restante en el momento de la revisión y no en una sesión de carteles.
- Enuncie una tolerancia antes de comprobar. Un «suficientemente cerca» decidido después de ver los números es la vía por la que entra el razonamiento motivado.
- Estime a partir de los datos crudos con su propio código. Preguntarle al mismo agente «¿está seguro?» no es verificación — los modelos ajustados con RLHF a menudo se disculpan y cambian respuestas correctas bajo presión social, en ambas direcciones sharma2023sycophancy.
Parte (b): Comprobación de citas¶
El mismo agente redactó un párrafo de trabajo relacionado para un informe sobre detección de desplazamientos en GNSS:
El análisis automatizado de series de tiempo GNSS está bien establecido: revisiones estándar cubren el contenido de señal geofísica de la geodesia GPS (Bock & Melgar, 2016), y la estimación de velocidades, desplazamientos y términos estacionales a partir de series diarias de posición se ha operacionalizado a gran escala (Heflin et al., 2020). Los fundamentos del modelado de la deformación los cubre Segall (2010). Más recientemente, el aprendizaje autosupervisado se ha aplicado a la detección de desplazamientos cosísmicos en redes densas, alcanzando umbrales de detección por debajo de 5 mm (Larsen & Ito, 2021).
Referencias
- Bock, Y., & Melgar, D. (2016). Physical applications of GPS geodesy: a review. Reports on Progress in Physics, 79(10), 106801. doi:10.1088/0034-4885/79/10/106801
- Heflin, M., et al. (2020). Automated estimation and tools to extract positions, velocities, breaks, and seasonal terms from daily GNSS time series. Earth and Space Science, 7(2). doi:10.1029/2019EA000644
- Segall, P. (2010). Earthquake and Volcano Deformation. Princeton University Press.
- Larsen, K. M., & Ito, H. (2021). Self-supervised detection of coseismic offsets in dense GNSS networks. Journal of Geodetic Machine Intelligence, 14(3), 211–229. doi:10.1029/2021JGMI00417
Una de estas cuatro referencias está fabricada. Las cuatro están correctamente formateadas, y la fabricada es la más pertinente para el informe — las fabricaciones se agrupan exactamente allí donde uno más desea que exista una cita de apoyo.
Ejercicio escrito (sin código, y deliberadamente sin llamadas de red en este cuaderno): diseñe un procedimiento de verificación que pudiera correr sobre cualquier lista de referencias redactada por IA. Especifique los pasos concretos, en orden de esfuerzo creciente, y qué resultado debe devolver cada paso para que la cita sobreviva. Luego aplique el razonamiento de su procedimiento a las cuatro referencias de arriba: ¿cuál falla, y en qué paso la atraparía?
Solución
Un procedimiento viable, con las comprobaciones más baratas primero:
- Resuelva el DOI en
https://doi.org/<doi>. Un DOI fabricado normalmente devuelve «DOI not found». Necesario pero no suficiente — los modelos también adjuntan DOI reales a artículos equivocados, así que si resuelve, confirme que la página de destino muestra el título y los autores afirmados. - Busque el título (entrecomillado) en Crossref, Google Scholar o ADS. El artículo debe existir con estos autores, este medio, este año.
- Compruebe que el medio existe. Busque el nombre de la revista en sí.
- Compruebe la afirmación, no solo la existencia. Abra el artículo (el resumen suele bastar) y confirme que sustenta el enunciado específico para el que se le cita — aquí, «umbrales de detección por debajo de 5 mm». Un artículo real citado por algo que no dice es la falla más sutil, y es además un modo de falla humano que la redacción por IA amplifica.
Aplicado aquí: la referencia 4 es la fabricación. Falla en cada paso — el DOI no resuelve; no existe tal artículo; y el Journal of Geodetic Machine Intelligence no existe. Un lector del dominio obtiene una señal de alerta extra antes de cualquier búsqueda: el prefijo DOI 10.1029 pertenece a las revistas de la AGU, y ninguna revista de la AGU tiene ese acrónimo. Las referencias 1 a 3 son reales (y vale la pena conocerlas).
Reglas para su proyecto: cada referencia de cualquier cosa que usted entregue recibe como mínimo los pasos 1 y 2; todo lo que sostenga una afirmación recibe el paso 4. Presupueste minutos por cita — ese es el precio real del trabajo relacionado redactado por IA. Y nunca cite un artículo que no haya al menos abierto, sin importar quién redactó la oración.
Parte (c): El LLM como juez, y sus sesgos¶
Hoy es común usar un modelo para revisar la salida de otro («LLM-as-judge», el LLM como juez) — y usted usará una revisión con IA agéntica sobre el repositorio de su propio proyecto final. Los jueces heredan los sesgos de su entrenamiento: premian la extensión y el tono seguro (sesgo de verbosidad), prefieren la respuesta que se presenta primero (sesgo de posición) y son reacios a ser severos (complacencia) zheng2023judgingsharma2023sycophancy. Calíbrese usted mismo sobre un par controlado.
Abajo hay dos revisiones grabadas del mismo análisis estudiantil. El análisis revisado se resume primero; contiene dos fallas metodológicas reales. Lea las tres antes de calificar.
analysis_summary = """
Student analysis (summary): Classify lithology from 9 geochemical features
(n=6,000, three imbalanced classes). Pipeline: StandardScaler fit on the FULL
dataset, then an 80/20 train/test split, then a gradient-boosted classifier.
The decision threshold for the minority class was tuned to maximize F1 ON THE
TEST SPLIT. Reported: test macro-F1 = 0.95 from a single run, seed not varied.
"""
review_A = """
This is an impressive and thoroughly executed piece of work! The authors have
clearly put substantial effort into building a rigorous machine learning
pipeline, and it shows. The choice of a gradient-boosted classifier is
excellent and reflects current best practice for tabular data. The
preprocessing is careful and well organized, and the use of standardization
demonstrates solid command of the fundamentals. The reported macro-F1 of 0.95
is a strong result that speaks to the quality of the feature engineering.
The handling of class imbalance through threshold tuning is a nice touch that
many students overlook. For future work, the authors might consider exploring
additional model families, experimenting with feature selection, or applying
cross-validation for even more reliable estimates. They could also consider
deep learning approaches as the dataset grows. Overall, an exemplary analysis
that meets a very high standard — congratulations to the authors on an
excellent submission!
"""
review_B = """
Two problems invalidate the headline number.
1. Leakage: the scaler is fit on the full dataset before the split, so test
statistics inform training features. Refit the scaler on train only.
2. The minority-class threshold is tuned on the test split, then F1 is
reported on that same split. That is selection on the test set; the 0.95
is optimistic by construction. Tune on a validation split, then report
test once.
Also: single run, one seed — report mean and spread over >=3 seeds (see 5.2).
The pipeline structure is otherwise sound. I would expect the corrected
macro-F1 to drop; whether it stays above the 0.90 project target is the
question that matters.
"""
for name, r in [("A", review_A), ("B", review_B)]:
print(f"review {name}: {len(r.split())} words")review A: 148 words
review B: 113 words
Califique ambas revisiones contra esta rúbrica, 0–10 en total:
| Criterio | Puntos |
|---|---|
| Identifica las fallas reales (fuga de datos; umbral ajustado sobre el conjunto de prueba) | 0–4 |
| Las sugerencias son accionables (dicen qué cambiar, de forma concreta) | 0–3 |
| Las afirmaciones se atan a especificidades de este análisis, no son genéricas | 0–2 |
| El elogio y la crítica están calibrados a lo que el análisis se ganó | 0–1 |
Llene sus calificaciones en la celda de abajo y luego abra la discusión.
# Your scores (edit these):
scores = {
"review_A": {"flaws_found": 0, "actionable": 1, "specific": 0, "calibrated": 0},
"review_B": {"flaws_found": 4, "actionable": 3, "specific": 2, "calibrated": 1},
}
for name, s in scores.items():
print(f"{name}: total {sum(s.values())}/10 {s}")review_A: total 1/10 {'flaws_found': 0, 'actionable': 1, 'specific': 0, 'calibrated': 0}
review_B: total 10/10 {'flaws_found': 4, 'actionable': 3, 'specific': 2, 'calibrated': 1}
Intercambio con un compañero (haga esto antes de abrir la discusión). Intercambie calificaciones con un compañero que haya calificado las mismas dos revisiones de forma independiente. Para cada una de las ocho calificaciones por criterio (cuatro por revisión), anote si usted y su compañero otorgaron los mismos puntos. Dos números para calcular en el momento: su acuerdo porcentual (criterios coincidentes / 8) y, una vez que tenga la implementación de cinco líneas de 6.3, el kappa de Cohen — el acuerdo corregido por azar. Conserve ambos vectores de calificaciones; la sección «Calificar sin verdad computable» de 6.3 convierte exactamente estos datos en una medición de si una rúbrica es siquiera utilizable. Cada desacuerdo es información: marca un criterio cuya redacción ustedes dos resolvieron de manera distinta, y necesita reescribirse antes de confiárselo a cualquier LLM juez.
Discusión
Calificación del instructor: la revisión A obtiene alrededor de 1/10 — de sus más de 160 palabras, ninguna identifica ninguna de las dos fallas plantadas; elogia una de ellas («el ajuste del umbral es un buen detalle»); sus sugerencias (más modelos, más características, aprendizaje profundo) aplican a cualquier análisis jamás escrito. La revisión B obtiene 9–10/10 en menos de la mitad de las palabras: encuentra ambas fallas, cada una con una corrección concreta, más el punto sobre la varianza según la semilla de 5.2, más una conclusión calibrada.
Ahora la parte incómoda. En estudios controlados, los LLM jueces — y los humanos cansados — prefieren con frecuencia respuestas con la forma de A: más largas, más cálidas, más seguras (sesgo de verbosidad), y la que aparece primero (sesgo de posición; note que A se listó primero aquí) zheng2023judging. Si usted hubiera hojeado en vez de calificar, A se sentía como la mejor revisión. Por esto existen las rúbricas: fuerzan la comparación sobre criterios elegidos antes de leer.
Reglas prácticas cuando use una revisión por IA (incluida la obligatoria sobre su proyecto final):
- déle al juez la rúbrica, no solo «revise esto»;
- pida fallas específicamente; un juez al que se le dice que encuentre problemas encuentra más que uno al que se le pide una impresión global;
- intercambie el orden de las alternativas y vea si el veredicto sobrevive;
- y trate el elogio no ganado como ruido, no como señal. El elogio no le cuesta nada al modelo, y es la parte que su cerebro quiere conservar.
Parte (d): El bucle de revisión¶
Junte las tres habilidades y obtiene el arreglo de trabajo que este curso espera entre usted y cualquier sistema de IA:
La IA redacta; el humano verifica; ambos pasos quedan registrados.
El borrador es barato ahora — código, trabajo relacionado, comentarios de revisión, todo. Lo escaso, y aquello por lo que se le califica, es la verificación: afirmaciones comprobadas contra los datos con tolerancias enunciadas (parte a), citas resueltas y leídas (parte b), revisiones calificadas contra rúbricas en vez de por sensación (parte c). El registro es la tabla de declaración de 6.4: herramienta, tarea, qué verificó usted.
El proyecto final lo hace concreto (rúbrica, sección 1.10): antes de la entrega, su grupo corre una revisión con IA agéntica de su repositorio y luego escribe una crítica de esa revisión documentando al menos una cosa que la IA hizo mal o pasó por alto. Se entregan ambos documentos. Después de este cuaderno usted sabe por qué existe el segundo — y tiene un procedimiento basado en rúbrica para producirlo.