Preguntas y escenarios oficiales: muestra del examen y escenarios 5 y 6 de prompts y salida estructurada

Bienvenidos y bienvenidas a la cápsula diez del Módulo uno. Hoy cerramos el módulo con las preguntas oficiales de la guía y con cómo leer los escenarios cinco y seis.

La pregunta once. Tu equipo quiere bajar costos de API. Hay un chequeo previo al merge que bloquea a los desarrolladores, y un reporte de deuda técnica que corre de noche. El jefe propone pasar ambos a la Message Batches API por el ahorro de cincuenta por ciento. Opción A: batch solo para el reporte y tiempo real para el chequeo. Opción B: ambos a batch con polling. Opción C: tiempo real en ambos para evitar problemas de orden. Opción D: ambos a batch con fallback a tiempo real si el lote demora. La correcta es A. Batch puede tardar hasta veinticuatro horas sin garantía de latencia, así que no sirve donde alguien espera, y sí para un reporte nocturno. B falla porque confiar en que suele ser rápido no basta en un flujo bloqueante. C parte de un error: el campo custom ID resuelve la correlación. D agrega complejidad de más.

La pregunta doce. Un pull request modifica catorce archivos. La revisión en una sola pasada sale inconsistente: comentarios profundos en unos, superficiales en otros, bugs que se escapan y feedback contradictorio. Opción A: pasadas por archivo y luego una pasada de integración para el flujo entre archivos. Opción B: exigir pull requests de tres o cuatro archivos. Opción C: un modelo mayor con ventana más grande. Opción D: tres revisiones y marcar solo lo que salga en al menos dos. La correcta es A, porque ataca la dilución de la atención. B traslada la carga a las personas. C confunde tamaño de ventana con calidad de atención. D suprime bugs reales que solo se detectan a veces.

La pregunta tres. Un agente de soporte logra cincuenta y cinco por ciento de resolución al primer contacto, contra una meta de ochenta. Escala casos simples, como un reemplazo por daño con foto, y se queda con excepciones de política. Opción A: criterios explícitos de escalamiento en el system prompt, con ejemplos few-shot. Opción B: que reporte confianza del uno al diez y escalar bajo un umbral. Opción C: entrenar un clasificador aparte. Opción D: escalar según análisis de sentimiento. La correcta es A: la causa son fronteras poco claras, y esa es la respuesta más proporcionada. B usa confianza autoinformada, mal calibrada. C es sobreingeniería antes de afinar el prompt. D resuelve otro problema.

Ahora los escenarios. En el escenario cinco, de integración continua, si los desarrolladores ignoran los comentarios, entonces piensa en criterios explícitos, exclusiones y el campo detected pattern. Si el mismo agente revisa lo que generó, entonces una instancia independiente. Si el pull request es grande, entonces pasadas por archivo más integración.

En el escenario seis, de extracción, si hay valores inventados, entonces campos nullable. Si los totales no cuadran, entonces calculated total y conflict detected. Si el dato vive en otro documento, entonces reintentar no sirve. Si son miles de documentos sin urgencia, entonces batch con custom ID.

Pregunta uno. Una cooperativa lechera quiere bajar costos. Tiene un chequeo de calidad que bloquea el despacho hasta terminar, y un informe semanal de merma que nadie espera en el momento. El gerente propone pasar ambos a la Message Batches API. ¿Qué conviene? Opción A: ambos a batch con polling. Opción B: batch solo para el informe semanal y tiempo real para el chequeo de despacho. Opción C: tiempo real en ambos por el orden de los resultados. Opción D: ambos a batch con fallback a tiempo real.

La correcta es B. Batch no garantiza latencia, así que no sirve donde el despacho espera, y sí para un informe semanal. A deja un flujo bloqueante sin garantía. C parte de un error: el campo custom ID resuelve el orden. D agrega complejidad de más.

Pregunta dos, de respuesta múltiple. Elige dos. Una ONG de ayuda humanitaria debe extraer datos de miles de informes de terreno, sin urgencia. Algunos traen totales que no cuadran, y otros no traen un dato que vive en otro documento. ¿Qué dos medidas corresponden? Opción A: procesar todo en tiempo real. Opción B: reintentar hasta que aparezca el dato que falta. Opción C: usar la Message Batches API con un custom ID en cada petición. Opción D: promediar los totales que no cuadran. Opción E: marcar con el campo conflict detected los informes cuyos totales no cuadran, sin reintentarlos. ¿Cuáles dos?

Las correctas son C y E. La C ahorra costo donde nadie espera, y la E registra la inconsistencia del informe como dato. La A paga más sin necesidad. La B insiste con un dato que no está en el informe. La D inventa un total que nadie declaró.

Resumen: la opción correcta ataca la causa raíz con el cambio más proporcionado, y cada síntoma tiene su técnica. Con esto cerramos el Módulo uno. Si te sirvió, sigue el podcast, dale cinco estrellas y activa las notificaciones. En la próxima comenzamos el Módulo dos, con las descripciones de herramientas. Nos escuchamos en la próxima cápsula de EvoAcademy.