Feedback loops: el campo detected pattern para mejorar prompts y esquemas

Bienvenidos y bienvenidas a la cápsula seis del Módulo uno. Hoy vemos la segunda parte del task statement cuatro punto cuatro: los feedback loops, o ciclos de retroalimentación, que usan los errores del sistema para mejorar prompts y esquemas.

Un sistema en producción tiene que aprender de sus fallas de forma sistemática. Para eso, la salida estructurada debe traer información que permita analizar después qué es lo que falla. La guía oficial da el ejemplo del campo detected pattern: cada hallazgo de una revisión de código registra qué construcción del código lo disparó. Cuando los desarrolladores descartan hallazgos, agrupas esos descartes por patrón y ves cuáles son falsos positivos sistemáticos.

Esto importa porque, sin ese campo, solo sabes que hubo muchos descartes. Con el campo, descubres que, por ejemplo, el setenta por ciento viene del mismo patrón, como el uso de un decorador que el equipo considera correcto. Esa información alimenta lo que vimos en la cápsula uno. Si un patrón se rechaza siempre, entonces agregas una exclusión explícita al prompt y un ejemplo que contraste el caso aceptable con un problema real. Por su parte, si una categoría entera genera puro ruido, entonces la desactivas mientras la afinas.

En el ejemplo de la guía, los descartes se concentran en el patrón try sin except específico de los scripts de migración, donde el equipo lo usa a propósito. La arquitecta agrega esa exclusión y un ejemplo del caso aceptable, y esos descartes bajan.

Cada hallazgo del revisor puede traer cinco campos: la ubicación, el problema, la severidad, el arreglo sugerido y detected pattern.

En extracción pasa lo mismo. Si registras el tipo de error de validación, el campo afectado y el tipo de documento, entonces sabes si el problema está en el prompt o en el esquema, y si se concentra en una clase de documentos.

En el examen, cuando un revisor genera descartes frecuentes, las respuestas que diseñan captura de datos estructurados, como el campo detected pattern más el registro de cada descarte, son mejores que ajustar el prompt a ojo o subir el umbral de confianza. Esas dos no te dicen dónde está el problema.

Una pregunta. ¿Cómo sabes qué patrón de hallazgo rechaza siempre el equipo?

Registrando el campo detected pattern en cada hallazgo, y agrupando los descartes por ese patrón.

Pregunta uno. Una cadena de cines usa un revisor automático para los textos de sus promociones. Cada hallazgo ya trae el campo detected pattern. Después de un mes, el equipo ve que casi todos los descartes de severidad media vienen del mismo tipo de comentario. ¿Qué conviene hacer? Opción A: eliminar la severidad media. Opción B: pedirle al modelo que se autocorrija. Opción C: subir el umbral de confianza para todos los hallazgos. Opción D: agrupar los descartes por el campo detected pattern, y ajustar o desactivar la categoría que el equipo más rechaza.

La correcta es D. Los datos del trabajo real dicen qué patrón rechaza el equipo, y con eso se afina la instrucción. La A quita información sin tocar la causa. La B no tiene datos para corregir nada. La C castiga también a los hallazgos que sí sirven.

Pregunta dos, de respuesta múltiple. Elige dos. Una empresa de hospedaje de mascotas usa un revisor de fichas de clientes que entrega hallazgos sin trazabilidad, y nadie sabe cuáles hallazgos se aceptan y cuáles se rechazan. ¿Qué dos medidas ayudan? Opción A: pedirle al modelo explicaciones más largas. Opción B: agregar a cada hallazgo la ubicación, el problema, la severidad, el arreglo sugerido y el campo detected pattern. Opción C: eliminar los hallazgos de baja severidad. Opción D: registrar la decisión de aceptar o descartar cada hallazgo, para analizarla por patrón. Opción E: esperar a que el equipo se queje. ¿Cuáles dos?

Las correctas son B y D. La B deja cada hallazgo con la información para analizarlo, y la D permite cruzarlo con lo que el equipo decidió. La A agrega texto, pero ninguna estructura para el análisis. La C elimina hallazgos sin saber si eran los problemáticos. La E reemplaza los datos por quejas, que llegan tarde.

Resumen: la salida estructurada debe traer metadatos para analizar qué falla. Con el campo detected pattern agrupas los descartes y mejoras las instrucciones con datos del trabajo real, en vez de intuiciones. Si te sirvió, sigue el podcast, dale cinco estrellas y activa las notificaciones. En la próxima cápsula vemos el procesamiento batch, para ahorrar costo cuando nadie está esperando. Nos escuchamos en la próxima cápsula de EvoAcademy.