Certificación Claude Architect · Módulo 1: ingeniería de prompts y salida estructurada

Cápsula M1-00

Panorama del Módulo 1: ingeniería de prompts y salida estructurada en el examen

Reproductor del navegador

De qué trata

Entramos al Módulo 1, dedicado al dominio de ingeniería de prompts y salida estructurada, que pesa el 20 por ciento del examen Claude Certified Architect Foundations, unas 12 de las 60 preguntas. En este episodio te doy el mapa completo: por qué pedirle a un revisor que sea más conservador no mejora su precisión, cómo se separan la estructura y el contenido cuando usas tool use con JSON Schema, y qué hacer cuando un campo obligatorio no tiene dato en el documento.

Cerramos con dos casos de práctica: un canal de televisión cuyo sistema inventa la hora de emisión cuando la parrilla no la trae, y una inmobiliaria con un bot de revisión de fichas que genera tantos comentarios menores que el equipo lo ignora.

Transcripción

Transcripción del guion de la cápsula. La voz es sintética y el contenido sigue la guía oficial del examen.

Ver la transcripción completa

Bienvenidos y bienvenidas a la cápsula cero del Módulo uno. Hoy vemos el panorama del módulo.

Este módulo corresponde al dominio cuatro de la guía, ingeniería de prompts y salida estructurada. Pesa veinte por ciento del examen, unas doce de las sesenta preguntas. La guía lo divide en seis task statements, que son las habilidades concretas que pide dominar, numerados del cuatro punto uno al cuatro punto seis.

Los dos primeros mejoran lo que le pides al modelo. El cuatro punto uno trata de criterios explícitos para reducir falsos positivos, y el cuatro punto dos, de ejemplos few-shot. El cuatro punto tres asegura la forma de la respuesta con tool use y JSON Schema, y lo vemos en dos cápsulas. El cuatro punto cuatro agrega validación, reintento y feedback. El cuatro punto cinco decide cuándo procesar en batch, y el cuatro punto seis arma revisiones con varias instancias y varias pasadas.

Casi todas las preguntas llegan envueltas en uno de dos escenarios, que son casos realistas con contexto compartido. El cinco es Claude Code en integración continua, el proceso automático que revisa y prueba el código cada vez que alguien lo cambia: revisiones de pull requests y generación de tests, con feedback accionable y pocos falsos positivos. El seis es extracción de datos estructurados: un sistema lee documentos sin formato fijo, los valida con JSON Schema, debe mantener alta precisión y manejar con elegancia los casos borde.

La guía da pistas para leerlos, y cada pista tiene su respuesta. Si los desarrolladores ignoran los comentarios, entonces piensa en criterios explícitos. Por su parte, si aparecen valores inventados, entonces piensa en campos nullable. Además, si los totales no cuadran, entonces piensa en validación. Y si son miles de documentos sin urgencia, entonces piensa en batch.

Para decidir entre opciones, la regla es esta: la correcta ataca la causa raíz con el cambio más proporcionado, y prefiere criterios explícitos y garantías estructurales a pedirle al modelo que sea más cuidadoso. Hay preguntas de una sola respuesta y de respuesta múltiple, y cada pregunta dice cuántas opciones marcar. En las de respuesta múltiple suelen ir juntas una medida de esquema y una de prompt.

Al terminar vas a poder diseñar un extractor que no inventa datos y escribir criterios que silencian el ruido de un revisor automático.

Una pregunta de calentamiento. ¿Qué técnica usarías si el modelo inventa un valor que el documento no trae?

Un campo nullable, que acepte nulo, para que el modelo pueda decir que el dato no existe. Ahora, el mismo patrón en un caso concreto.

Pregunta uno. Un canal de televisión extrae la hora de emisión desde las parrillas de programación, y a veces el sistema inventa una hora cuando el documento no la trae. ¿Qué cambio conviene? Opción A: descartar los documentos incompletos. Opción B: pedirle en el prompt que nunca invente una hora. Opción C: hacer ese campo nullable en el esquema, para que el modelo pueda devolver nulo. Opción D: bajar la temperatura a cero.

La correcta es C. Con un campo que acepta nulo, el modelo puede decir que el dato no existe, en vez de rellenarlo. La A pierde documentos que aún sirven. La B depende de una petición y el campo sigue siendo obligatorio. La D cambia la aleatoriedad, no la causa.

Pregunta dos, de respuesta múltiple. Elige dos. Una inmobiliaria usa un bot que revisa fichas de propiedades, y genera tantos comentarios menores que el equipo ya lo ignora. ¿Qué dos medidas ayudan? Opción A: agregar ejemplos few-shot de casos que sí se reportan y casos que no. Opción B: filtrar por la confianza que el propio modelo declara. Opción C: revisar todo con una segunda instancia. Opción D: definir criterios explícitos sobre qué reportar y qué omitir. Opción E: pedirle al modelo que sea más conservador. ¿Cuáles dos?

Las correctas son A y D. La A le muestra la frontera con casos reales, y la D le dice al modelo qué importa en este proyecto. La E no define qué significa conservador. La B usa una confianza que no está calibrada. La C suma costo sin atacar la causa.

Resumen: el dominio cuatro se lee con dos escenarios, y la respuesta correcta ataca la causa raíz. Si te sirvió, sigue el podcast, dale cinco estrellas y activa las notificaciones. En la próxima cápsula partimos con el cuatro punto uno, criterios explícitos, y cómo decirle al modelo qué reportar y qué omitir. Nos escuchamos en la próxima cápsula de EvoAcademy.

Fuentes

Inteligencia Artificial para los Negocios es el podcast de . Si tu equipo necesita capacitación en IA, conoce evoacademy.cl.