Cinco preguntas reales, inéditas, al estilo del examen CCA-F para Ingeniería de Prompts y Salida Estructurada (20% del examen). Intenta responder cada una tú mismo antes de revelar la explicación — así es como realmente encuentras los vacíos en tu comprensión.
Practica el conjunto completo filtrado por dominio en AICert Study →
Pregunta 1
Una categoría de revisión de código para 'variables no utilizadas' tiene una tasa de falsos positivos del 70% y los desarrolladores han empezado a ignorar todos los comentarios del bot, incluyendo los de categorías precisas. ¿Cuál es la acción más pragmática a corto plazo mientras se mejora el prompt?
- A. Agregar una instrucción adicional para 'verificar dos veces los hallazgos de variables no utilizadas' y mantener la categoría activada
- B. Deshabilitar temporalmente la categoría 'variables no utilizadas' para que las categorías precisas recuperen la confianza de los desarrolladores
- C. Aumentar el tamaño del modelo a un modelo Claude más grande y mantener la categoría activada
- D. Publicar todos los hallazgos de 'variables no utilizadas' como etiquetas de baja prioridad en vez de comentarios en línea
Ver respuesta y explicación
Respuesta correcta: B
Las categorías con altos falsos positivos socavan la confianza en todo el bot, incluyendo las categorías precisas. Deshabilitar temporalmente la categoría defectuosa restaura la confianza de los desarrolladores mientras iteras el prompt offline, y luego la reactivas cuando la precisión sea aceptable.
- Agregar una instrucción extra para 'verificar dos veces' es incorrecto. Las instrucciones vagas de autoverificación rara vez corrigen falsos positivos categóricos, y los desarrolladores siguen viendo el ruido hasta que la precisión mejore mensurablemente.
- Aumentar el tamaño del modelo es incorrecto. La causa raíz son criterios ausentes/ambiguos en el prompt; un modelo más grande sigue aplicando las mismas reglas vagas y la confianza no se recupera.
- Publicar hallazgos como etiquetas de baja prioridad es incorrecto. El ruido sigue apareciendo en el flujo y los desarrolladores siguen ignorando todo el bot; la degradación de la confianza no se debe al color de la etiqueta sino a la relación señal-ruido.
Compartir esta pregunta en LinkedIn →
Pregunta 2
Estás construyendo un sistema de extracción de facturas que debe devolver JSON conforme a un esquema fijo con campos como invoice_number, total y currency. ¿Qué enfoque ofrece la mayor garantía de que la respuesta será JSON sintácticamente válido que coincida con tu esquema?
- A. Pedirle a Claude en prosa sencilla que 'devuelva solo JSON válido' y parsear la respuesta
- B. Envolver la solicitud del usuario en etiquetas XML pidiendo salida JSON
- C. Rellenar previamente el turno del asistente con un objeto JSON parcial
- D. Definir una herramienta cuyo input_schema sea tu JSON schema y llamarla con tool_choice forzando esa herramienta
Ver respuesta y explicación
Respuesta correcta: D
Definir una herramienta con tu JSON schema como input_schema y forzar al modelo a llamarla (tool_choice = {type: 'tool', name: ...}) es el enfoque más confiable para salida estructurada conforme al esquema. El modelo produce la entrada de la herramienta según el esquema declarado, eliminando errores de sintaxis JSON y problemas de claves faltantes.
- Pedir en prosa sencilla es incorrecto. Las solicitudes en texto libre por 'JSON válido' suelen producir comentarios adicionales, code fences o pequeños errores de sintaxis que rompen los parsers.
- Rellenar previamente el turno del asistente es incorrecto. El prefill puede sugerir el formato pero no impone esquema, y aún produce texto que el parser debe validar (a diferencia de tool use, donde la salida del modelo está restringida por un esquema).
- Envolver la solicitud en etiquetas XML es incorrecto. El uso de XML mejora la claridad pero no impone nada; la respuesta sigue siendo texto sin gobernanza.
Compartir esta pregunta en LinkedIn →
Pregunta 3
Necesitas procesar 50.000 PDFs históricos durante la noche para extraer metadatos estructurados. El trabajo no es bloqueante y quieres minimizar costos. ¿Qué API es la mejor opción?
- A. La Message Batches API, que cobra el 50% del precio estándar con una ventana de procesamiento de 24 horas
- B. La Messages API síncrona estándar con solicitudes paralelas
- C. La Messages API en streaming para reducir el time-to-first-token
- D. La Files API con llamadas de extracción síncronas
Ver respuesta y explicación
Respuesta correcta: A
La Message Batches API está diseñada para cargas de alto volumen y tolerantes a latencia. Cobra el 50% del precio estándar y procesa lotes de forma asíncrona dentro de una ventana de 24 horas, lo que encaja exactamente con un trabajo nocturno de extracción de 50.000 documentos.
- Messages API síncrona estándar con solicitudes paralelas es incorrecto. Pagas precio completo y aún debes gestionar concurrencia, reintentos y límites de tasa.
- Messages API en streaming es incorrecto. El streaming reduce la latencia percibida en interfaces interactivas pero no reduce precio ni ayuda en el throughput masivo.
- Files API con llamadas síncronas es incorrecto. La Files API almacena documentos pero no ofrece un nivel asíncrono con descuento; seguirías pagando precio completo por solicitud.
Compartir esta pregunta en LinkedIn →
Pregunta 4
Una verificación de CI pre-merge debe bloquear el PR hasta que se devuelvan los hallazgos de revisión. ¿Por qué la Message Batches API es una mala opción para este flujo?
- A. Los lotes no admiten salida JSON, solo texto plano
- B. Los lotes no tienen SLA de latencia garantizada y pueden tardar hasta 24 horas, lo cual es incompatible con un gate pre-merge bloqueante
- C. Los lotes cuestan más que las llamadas síncronas, por lo que una verificación de CI sería costosa
- D. Los lotes requieren un nivel enterprise pagado al que la mayoría de los proveedores de CI no pueden acceder
Ver respuesta y explicación
Respuesta correcta: B
La Message Batches API explícitamente no ofrece garantía de latencia; la mayoría de los lotes termina en menos de una hora, pero la ventana documentada es de hasta 24 horas. Los flujos bloqueantes como las verificaciones pre-merge requieren latencia predecible y acotada y deben usar la Messages API síncrona.
- Los lotes no admiten salida JSON es incorrecto. Cualquier solicitud que se pueda enviar a la Messages API, incluyendo tool use para JSON, puede enviarse como solicitud de lote.
- Los lotes cuestan más que las llamadas síncronas es incorrecto. Los lotes son un 50% más baratos; el problema es la latencia, no el costo.
- Los lotes requieren un nivel enterprise pagado es incorrecto. La Batches API está disponible en la API estándar; el acceso no es el obstáculo.
Compartir esta pregunta en LinkedIn →
Pregunta 5
Le pides a una sola instancia de Claude que genere una revisión de código y luego le pides a la misma instancia que 'revise sus propios hallazgos y elimine los que no sean sólidos'. ¿Por qué esto a menudo no detecta falsos positivos?
- A. La autorevisión consume 2x los tokens y se agota en CI
- B. La autorevisión mantiene el contexto de razonamiento previo del modelo, haciéndolo menos propenso a cuestionar sus propias decisiones que un revisor independiente
- C. Claude se niega a criticarse a sí mismo por razones de seguridad
- D. La autorevisión solo funciona cuando el extended thinking está desactivado
Ver respuesta y explicación
Respuesta correcta: B
Cuando la instancia revisora comparte el mismo historial de conversación que la generadora, hereda el razonamiento original y está sesgada a confirmar sus conclusiones previas. Las instancias de revisión independientes que reciben solo el código y los hallazgos (sin el razonamiento previo) detectan errores sutiles de manera más confiable.
- Consume 2x los tokens y se agota es incorrecto. El uso de tokens es una preocupación de costo, no la razón por la que la autorevisión pasa por alto falsos positivos.
- Claude se niega a criticarse por seguridad es incorrecto. El modelo critica su propia salida cuando se le pide; el problema es sesgo, no negativa.
- La autorevisión solo funciona con extended thinking desactivado es incorrecto. Extended/adaptive thinking no cambia el sesgo fundamental hacia el razonamiento previo.
Compartir esta pregunta en LinkedIn →
¿Quieres más? Nuestro banco gratuito tiene cientos de preguntas de Ingeniería de Prompts y Salida Estructurada. Practícalas todas →