App de Quibank: ya está en el App Store — gratis y sin conexión. Descargar ↗

22 Preguntas de Práctica de Modelos, prompting e ingeniería de contexto con Respuestas

Todas las preguntas de práctica de Modelos, prompting e ingeniería de contexto del Examen de práctica Claude Certified Architect – Professional, con la respuesta correcta y una breve explicación.

Comenzar examen de práctica →
  1. 1. Un equipo compara dos configuraciones para una carga agéntica de resolución de tickets. La más barata por token resuelve el 77% de los tickets con más turnos y reintentos; la más cara por token resuelve el 88% en menos turnos. Finanzas pregunta cuál sale más barata. ¿Cómo debe plantear la comparación el arquitecto?

    • A.Comparar las tarifas publicadas por token de entrada y salida, ya que ese precio no varía de una ejecución a otra.
    • B.Comparar el gasto total de cada configuración dividido entre los tickets que realmente resolvió: el costo por ticket resuelto.✓ Respuesta
    • C.Comparar directamente las facturas mensuales de ambos pilotos: el que facturó menos es el que conviene financiar.
    • D.Comparar los tokens promedio que cada configuración consume por solicitud, porque un pedido más chico escala más barato.

    La unidad de decisión es el costo por tarea completada, no por token. Un modelo con precio por token más alto que termina el trabajo en menos turnos, con menos reintentos y menos ejecuciones abandonadas, puede dar un costo por ticket resuelto menor; ni la tarifa por token ni los tokens por solicitud dicen cuántos intentos requiere una tarea. Las facturas tampoco informan salvo que ambos pilotos completaran el mismo volumen de trabajo.

    Ref. QB-3285H9Fuente: CCAR-P Exam Guide v1.0, Domain 2 (Claude Models, Prompting & Context Engineering) — select models based on trade-offs; Anthropic, 'Choosing the right model' / 'Optimizing for cost and intelligence' — cost per completed taskReportar un problema con esta pregunta

  2. 2. Un servicio de resúmenes de soporte envía en cada solicitud un corpus de políticas grande e invariable y nunca activó el almacenamiento en caché de prompts. La factura se duplicó. La primera propuesta del equipo es pasar la ruta a un modelo más pequeño y barato. ¿Qué debe hacer primero el arquitecto?

    • A.Pasar la ruta al modelo más pequeño de inmediato y correr después la evaluación de calidad de los resúmenes.
    • B.Activar el almacenamiento en caché del corpus estable y volver a medir, porque ese ajuste no sacrifica calidad.✓ Respuesta
    • C.Agregar registro de costo por solicitud y una alerta de gasto antes de tocar cualquier parte de la configuración.
    • D.Bajar primero el esfuerzo de razonamiento de la ruta, ya que es la perilla más barata y no cambia la solicitud.

    Las palancas de costo tienen un orden: las ganancias gratuitas que no cuestan calidad van antes que cualquier palanca que sacrifique capacidad. Un prefijo estable repetido en cada solicitud es justo el caso para el que existe el caché, y una lectura cacheada cuesta bastante menos que una sin cachear. Bajar el esfuerzo o cambiar de modelo ceden calidad y se miden después; el registro observa el problema pero no lo reduce.

    Ref. QB-JH2YW8Fuente: CCAR-P Exam Guide v1.0, Domain 4 (Evaluation, Testing & Optimization) — optimize token usage, latency and cost-performance trade-offs; Anthropic, 'Optimizing for cost and intelligence' — lever order (free wins before trade-offs)Reportar un problema con esta pregunta

  3. 3. Una tubería de revisión de documentos corre con el esfuerzo por defecto en el modelo más capaz y cuesta más de lo presupuestado. Un ingeniero propone una cascada de dos modelos en la que uno barato atiende los documentos fáciles y escala los difíciles. ¿Cuál es el mejor primer experimento?

    • A.Agregar un enlace de monitoreo que registre el gasto de tokens por documento y revelar cuáles disparan el costo.
    • B.Construir la cascada detrás de un interruptor y compararla con la tubería actual durante una semana de tráfico.
    • C.Correr el mismo modelo con un esfuerzo de razonamiento menor sobre el conjunto de evaluación ya existente.✓ Respuesta
    • D.Subir el tiempo de espera y el tope de reintentos para que los documentos difíciles terminen en el primer intento.

    El esfuerzo es el experimento más barato porque cambia un solo parámetro sobre una arquitectura que ya existe, y un esfuerzo menor en un modelo fuerte suele mantener la exactitud reduciendo el gasto. La cascada agrega una regla de enrutamiento que mantener, un modo de fallo nuevo cuando enruta mal y un segundo espacio de caché, ya que las entradas pertenecen al modelo que las escribió. Tiempos de espera y reintentos no tocan ni costo ni exactitud.

    Ref. QB-22VSB8Fuente: CCAR-P Exam Guide v1.0, Domain 2 — model selection trade-offs and tuning effort; Anthropic, 'Optimizing for cost and intelligence' — measure lower effort on the strong model before building a multi-model pipelineReportar un problema con esta pregunta

  4. 4. Un asistente envía un prompt de sistema grande y estable seguido del turno del usuario. Los tokens leídos de caché son cero en cada solicitud aunque el texto parezca idéntico. Al revisarlo, el prompt de sistema comienza con una línea que renderiza la fecha y hora actuales. ¿Cuál es la corrección?

    • A.Redondear la marca de tiempo a la hora en punto para que las solicitudes de esa hora generen el mismo texto.
    • B.Sacar la marca de tiempo del prompt de sistema y ponerla en el turno del usuario, tras el último punto de corte.✓ Respuesta
    • C.Cambiar la entrada de caché a la duración más larga para que sobreviva entre solicitudes pese a la línea variable.
    • D.Agregar un punto de corte justo después de la línea con la marca de tiempo para cachear aparte el resto del prompt.

    El caché de prompts es una coincidencia de prefijo: cualquier byte que cambie invalida todo lo que sigue. Una marca de tiempo al inicio del prompt de sistema altera los primeros bytes del prefijo, así que nada posterior se reutiliza. El contenido volátil va después del último punto de corte. Una duración mayor conserva la entrada pero no hace coincidir un prefijo distinto, y un corte ubicado tras la línea volátil queda detrás de bytes que cambian siempre.

    Ref. QB-NH4YECFuente: CCAR-P Exam Guide v1.0, Domain 2 — optimize context windows and token usage; Anthropic prompt caching documentation — prefix match, silent invalidators, placement of volatile contentReportar un problema con esta pregunta

  5. 5. Un equipo quiere una disposición de caché duradera para un agente multiturno que lleva un conjunto fijo de herramientas, un prompt de sistema largo, un expediente recuperado que cambia entre conversaciones pero no dentro de una, y la pregunta del usuario. ¿Cómo deben ordenarse?

    • A.Poner la pregunta del usuario antes del expediente para que el modelo lea el pedido antes del material de referencia.
    • B.Anteponer el expediente a las herramientas y al prompt de sistema para cachear primero el bloque más grande.
    • C.Poner un punto de corte después de cada uno de los cuatro bloques para que cada segmento caduque por su cuenta.
    • D.Dejar primero las herramientas y el prompt de sistema, luego el expediente de la conversación y el último corte tras él.✓ Respuesta

    El contenido se compone en el orden herramientas, sistema y mensajes, y el caché coincide por prefijo, así que los bloques van de lo más estable a lo más volátil. Herramientas y prompt de sistema son estables en toda conversación, el expediente lo es dentro de una, y la pregunta cambia cada turno: por eso el último corte va tras el expediente. Cortes por bloque no dan vidas independientes, porque un cambio previo invalida todo lo posterior.

    Ref. QB-52XSUBFuente: CCAR-P Exam Guide v1.0, Domain 2 — prompt reuse and context optimization; Anthropic prompt caching documentation — render order (tools → system → messages) and breakpoint placementReportar un problema con esta pregunta

  6. 6. Un producto conversacional atiende los primeros turnos de una sesión con un modelo pequeño y escala la misma conversación a uno más grande cuando la pregunta se complica. El equipo esperaba que el turno escalado leyera del caché creado en los turnos previos. ¿Por qué no ocurre?

    • A.Las entradas de caché caducan al devolverse los resultados de herramientas, así que no queda prefijo reutilizable.
    • B.Las entradas de caché pertenecen al modelo que las escribió, y el turno escalado crea una nueva en vez de leerla.✓ Respuesta
    • C.Las entradas de caché se invalidan cada vez que el asistente agrega un turno, así que solo la primera solicitud lee.
    • D.Las entradas de caché valen solo dentro de una solicitud, así que cualquier pedido posterior reconstruye el prefijo.

    El caché está acotado por modelo: una entrada escrita sirviendo a un modelo no la lee otro, así que cambiar de modelo a mitad de la conversación pierde todas las lecturas acumuladas y paga una escritura nueva. Ese es un costo real y a menudo ignorado de cascadas y enrutadores, y debe pesarse contra el ahorro previsto. Agregar turnos del asistente o devolver resultados de herramientas solo alarga el prefijo, no lo destruye.

    Ref. QB-MHRM9BFuente: CCAR-P Exam Guide v1.0, Domain 2 — model selection trade-offs; Anthropic prompt caching documentation — cache entries are scoped per modelReportar un problema con esta pregunta

  7. 7. Tras agregar puntos de corte de caché a una ruta, un ingeniero informa que el cambio empeoró las cosas: la primera solicitud posterior al despliegue mostró un costo de entrada mayor que antes. ¿Cómo debe responder el arquitecto?

    • A.Revertir los puntos de corte, ya que una configuración que encarece la primera solicitud no recupera esa diferencia.
    • B.Revisar el código que arma la solicitud, ya que una configuración de caché bien escrita nunca encarece la entrada.
    • C.Comparar el uso a partir de la segunda solicitud, porque la primera paga la escritura y solo las siguientes leen la entrada.✓ Respuesta
    • D.Mover los puntos de corte más al final, ya que una escritura tan cara indica que se marcó demasiado contenido.

    Una escritura de caché cuesta algo más que una lectura sin cachear de los mismos tokens, mientras que una lectura cacheada cuesta bastante menos: por eso la primera solicitud parece un retroceso y el ahorro recién aparece desde la segunda. El caché se verifica con los campos de uso que informan tokens de creación y de lectura, medidos sobre solicitudes repetidas y no juzgados por una sola llamada ni leyendo el código.

    Ref. QB-42KFPAFuente: CCAR-P Exam Guide v1.0, Domain 4 — monitor with logging and observability; Anthropic prompt caching documentation — cache write vs. cache read pricing direction and verification via usage fieldsReportar un problema con esta pregunta

  8. 8. Un trabajo nocturno reclasifica los tickets de soporte del día anterior y un analista lee los resultados a la mañana siguiente. Otra carga clasifica un ticket mientras el cliente espera en la página. ¿Qué uso del procesamiento por lotes es apropiado?

    • A.Enviar la reclasificación nocturna por procesamiento por lotes y dejar la ruta del cliente en solicitudes estándar.✓ Respuesta
    • B.Enviar la ruta del cliente por lotes y la tarea nocturna en solicitudes estándar, porque la nocturna es más grande.
    • C.Enviar ambas cargas por lotes y consultar con frecuencia suficiente para que la ruta del cliente siga respondiendo rápido.
    • D.Dejar ambas cargas en solicitudes estándar, porque los resultados por lotes vuelven en un orden que nadie controla.

    El procesamiento por lotes cambia latencia por costo: el trabajo se encola y vuelve de forma asíncrona, así que sirve donde nadie espera y no sirve donde alguien espera. Consultar más seguido no acorta la cola. Que los resultados vuelvan desordenados es real, pero se resuelve emparejándolos por el identificador propio del llamador y no por posición, así que no es motivo para descartar los lotes de noche.

    Ref. QB-FHYXD5Fuente: CCAR-P Exam Guide v1.0, Domain 4 — cost-performance trade-offs; Anthropic Message Batches documentation — asynchronous processing, results keyed by the caller's custom identifierReportar un problema con esta pregunta

  9. 9. Un equipo que migra un servicio antiguo pregunta cómo trasladar su presupuesto fijo de tokens de razonamiento por solicitud, ajustado a mano para sus casos más difíciles. ¿Qué debe aconsejar el arquitecto?

    • A.Conservar el presupuesto fijo como techo y sumarle encima un nivel de esfuerzo, manteniendo un tope duro y el control nuevo.
    • B.Reproducir el presupuesto fijando el tope de tokens de respuesta en la misma cifra, porque limita igual la profundidad.
    • C.Eliminar el presupuesto y dejar la profundidad sin especificar, porque todo control explícito cuesta calidad al final.
    • D.Sustituir el presupuesto fijo por razonamiento adaptativo y un nivel de esfuerzo en la ruta, que es el control moderno.✓ Respuesta

    El razonamiento adaptativo es la expresión moderna de la misma idea: en vez de una asignación fija elegida por el llamador y aplicada por igual, el modelo varía la profundidad por solicitud y el arquitecto fija un esfuerzo para la ruta. Un presupuesto ajustado a los casos difíciles derrocha en la mayoría fácil. El tope de tokens de respuesta es otro límite, impuesto y no visible para el modelo, así que no sustituye ese control.

    Ref. QB-XZSST4Fuente: CCAR-P Exam Guide v1.0, Domain 2 — model configuration trade-offs; Anthropic extended thinking documentation — adaptive thinking supersedes a fixed thinking-token budget; effort as the depth controlReportar un problema con esta pregunta

  10. 10. Una organización tiene tres rutas de Claude: un clasificador de intención en cada mensaje entrante, un asistente de chat y un agente de migración de código de largo horizonte. Un ingeniero de plataforma propone fijar un único nivel de esfuerzo compartido para las tres. ¿Cuál es el mejor diseño?

    • A.Fijar el esfuerzo por ruta: bajo en el clasificador de alto volumen y más alto en el agente de migración.✓ Respuesta
    • B.Fijar un único esfuerzo alto para las tres rutas, ya que las salidas del clasificador son cortas y baratas.
    • C.Fijar un único esfuerzo bajo y subir el tope de respuesta del agente para que aún tenga margen de terminar.
    • D.Dejar el esfuerzo sin fijar y contener el gasto con límites de tasa por ruta, para que ninguna se pase.

    Qué cargas devuelven más esfuerzo es una propiedad de la carga, no de la organización: el trabajo agéntico y de largo horizonte gana mucho con razonamiento profundo, mientras que la clasificación y otras rutas de alto volumen o sensibles a la latencia ganan poco y pagan los tokens extra en cada llamada. Por eso el esfuerzo va en la configuración por ruta. Los límites de tasa acotan la exposición pero no cambian costo ni calidad de una solicitud.

    Ref. QB-2U65UDFuente: CCAR-P Exam Guide v1.0, Domain 4 — optimize cost-performance trade-offs; Anthropic, 'Optimizing for cost and intelligence' — effort by workload type, tuned per routeReportar un problema con esta pregunta

  11. 11. Un arquitecto quiere bajar el esfuerzo por defecto de una ruta de extracción de cara al cliente. La documentación del proveedor indica que el ajuste menor cuesta bastante menos con una pequeña caída de exactitud en los benchmarks publicados. ¿Cuál es la base defendible para el cambio?

    • A.Tomar las diferencias publicadas en los benchmarks, medidas sobre un conjunto más amplio del que armaría un equipo.
    • B.Hacer una comparación directa sobre las tres solicitudes que el equipo considera más difíciles de toda la ruta.
    • C.Constatar que no hubo quejas de clientes durante una semana ejecutando en silencio el ajuste más bajo en paralelo.
    • D.Correr ambos ajustes sobre una muestra de solicitudes reales recientes de la ruta y puntuarlas con su evaluación.✓ Respuesta

    Una decisión de modelo o configuración se defiende con una medición sobre la carga real, nunca con una afirmación general sobre qué ajuste es mejor. Las diferencias de benchmark describen otra mezcla de tareas y no predicen esta ruta. Tres solicitudes elegidas a mano son muy pocas para atribuir una diferencia, y la falta de quejas es una señal tardía e insensible que ignora errores silenciosos de extracción.

    Ref. QB-JBCAEEFuente: CCAR-P Exam Guide v1.0, Domain 4 — design evaluation datasets, conduct A/B testing and iterative improvement; Anthropic, 'Optimizing for cost and intelligence' — measure on real traffic before changing a defaultReportar un problema con esta pregunta

  12. 12. Un equipo propone un enrutador que inspeccione cada solicitud entrante y mande las fáciles a un modelo más barato. La dificultad de la carga no se percibe solo por el texto de la solicitud. ¿Cuál es el argumento más fuerte contra construirlo ahora?

    • A.Un modelo barato no sirve para nada si los casos difíciles exigen el grande, así que la división no ahorra nada.
    • B.La regla exige mantenimiento y revalidación conforme cambian el tráfico y los modelos, y cada error paga una segunda corrida.✓ Respuesta
    • C.Un enrutador no se puede evaluar antes de construirlo, así que se apuesta por una arquitectura sin precisión conocida.
    • D.Cambiar de modelo dentro de una misma conversación no se admite, de modo que todo escalamiento reiniciaría la sesión.

    Un enrutador es un componente con su propia exactitud, su mantenimiento y su modo de fallo, y solo conviene cuando el ejecutor distingue barato lo difícil de lo fácil. Aquí no puede, así que las solicitudes mal enrutadas se pagan dos veces y la regla exige revalidarse ante cada cambio de tráfico o modelo. Un enrutador sí se evalúa antes de lanzarlo reproduciendo tráfico histórico, y cambiar de modelo entre turnos es posible: el costo es el caché perdido.

    Ref. QB-ZTTSNCFuente: CCAR-P Exam Guide v1.0, Domain 1 (Solution Design & Architecture) — select the simplest architectural tier that meets the need; Anthropic, 'Optimizing for cost and intelligence' — when a multi-model split does not payReportar un problema con esta pregunta

  13. 13. Una parte interesada afirma que un modelo más pequeño sería obviamente suficiente para la ruta de preguntas frecuentes. ¿Cómo debe zanjar el arquitecto la cuestión?

    • A.Pedir al modelo grande que califique una muestra de respuestas del chico y adoptarlo si la mayoría resulta aceptable.
    • B.Comparar los niveles de capacidad publicados de ambos modelos y adoptar el chico, ya que responder preguntas es fácil.
    • C.Adoptar el modelo más chico en la ruta y vigilar los votos negativos, revirtiendo si esa tasa sube por encima de la actual.
    • D.Puntuar ambos modelos sobre un conjunto reservado de solicitudes reales con respuestas calificadas y adoptar el chico si aprueba.✓ Respuesta

    La suficiencia se demuestra, no se supone: el modelo chico se adopta solo tras superar un umbral declarado sobre un conjunto reservado de solicitudes propias de la ruta con respuestas conocidas. Los niveles publicados describen posición general, no esta tarea. Lanzar primero y observar el feedback mete al cliente en el experimento y solo detecta quejas, y calificar con el modelo grande sin verdad de referencia mide coincidencia, no corrección.

    Ref. QB-HBZX8DFuente: CCAR-P Exam Guide v1.0, Domain 4 — define evaluation metrics and design evaluation datasets; Anthropic, 'Choosing the right model' — validate a downgrade against your own evaluation setReportar un problema con esta pregunta

  14. 14. Un servicio codifica su identificador de modelo en seis puntos de llamada y sus prompts se ajustaron hace dos generaciones de modelos. El equipo quiere estar listo para el próximo lanzamiento. ¿Qué debe cambiar?

    • A.Fijar el identificador en cada punto de llamada y congelarlo, para que ninguna versión nueva altere el comportamiento.
    • B.Envolver cada llamada en un reintento que vuelva al identificador anterior cuando el modelo nuevo devuelva un error.
    • C.Llevar el identificador a la configuración y mantener una evaluación que se corra antes y después del cambio.✓ Respuesta
    • D.Leer el identificador del listado de modelos al arrancar y tomar siempre el más nuevo, siguiendo cada lanzamiento.

    La elección de modelo debe vivir en la configuración y no como un supuesto incrustado en el código, y el cambio se controla corriendo la misma evaluación antes y después para poder atribuirlo. Los prompts ajustados a una generación anterior suelen requerir revisión, porque instrucciones que ayudaban a un modelo pueden limitar a otro más nuevo. Adoptar automáticamente lo más nuevo cambia el comportamiento sin evaluar, y el reintento oculta la diferencia.

    Ref. QB-YTFFGBFuente: CCAR-P Exam Guide v1.0, Domain 6 (Stakeholder Communication & Lifecycle Management) — support lifecycle phases (design, handoff, monitoring, iteration); Anthropic model migration guidance — re-evaluate prompts tuned for an earlier modelReportar un problema con esta pregunta

  15. 15. En una revisión de diseño, se le pide al arquitecto que indique de memoria la ventana de contexto y el precio por token de cada modelo candidato para llenar una tabla comparativa. ¿Cuál es la respuesta correcta?

    • A.Omitir la tabla y comparar a los candidatos solo por los resultados de la evaluación propia del equipo en la ruta.
    • B.Llenar la tabla con el listado de modelos y la documentación de precios vigentes, anotando la fecha de consulta.✓ Respuesta
    • C.Llenar la tabla de memoria y marcarla como provisional, ya que lo decisivo es el orden relativo entre los niveles.
    • D.Llenar la tabla con las cifras del documento de diseño del trimestre pasado, verificadas en aquella revisión.

    Capacidad, latencia, precio y ventana de contexto son los ejes que distinguen a los modelos, pero sus valores actuales se consultan, no se recuerdan: el listado de modelos y la documentación de precios vigente son la fuente autorizada, y cualquier lanzamiento puede cambiarlos. Anotar la fecha de consulta le dice al lector futuro qué tan vieja es la tabla. Comparar solo por evaluación ignora precio y límites de contexto, que son restricciones reales.

    Ref. QB-GBNM3CFuente: CCAR-P Exam Guide v1.0, Domain 6 — document architectures and provide implementation guidance; Anthropic Models API documentation — query the model listing for current context and capability valuesReportar un problema con esta pregunta

  16. 16. Un cliente de salud exige que la inferencia se ejecute en una geografía específica y que la plataforma de despliegue esté en su lista aprobada. El modelo candidato más capaz no se ofrece en esa plataforma dentro de esa geografía. ¿Cómo debe proceder el arquitecto?

    • A.Desplegar el modelo más capaz bajo una regla de sistema que prohíba guardar o transmitir información de pacientes.
    • B.Elegir el modelo más capaz y abrir una solicitud de excepción ante el equipo de cumplimiento mientras se construye.
    • C.Adoptar el modelo más capaz y sumar registro de respuestas con una cola de revisión antes de que las vea un paciente.
    • D.Reducir los candidatos a los modelos ofrecidos en la plataforma aprobada dentro de esa geografía, y comparar a los que queden.✓ Respuesta

    Las restricciones de cumplimiento filtran el conjunto de candidatos antes de cualquier comparación de costo o capacidad, porque la geografía de inferencia y la disponibilidad por plataforma son hechos estructurales sobre dónde puede ejecutarse legalmente la carga, no riesgos a mitigar después. Funciones y modelos de una plataforma pueden no existir en otra. Una regla en el prompt es una instrucción que el modelo puede incumplir, y el registro con revisión detecta la violación ya ocurrida.

    Ref. QB-XT45BAFuente: CCAR-P Exam Guide v1.0, Domain 5 (Governance, Safety & Risk Management) — ensure compliance with regulations (GDPR, HIPAA, FedRAMP); Anthropic platform availability documentation — model and feature availability varies by platform and inference geographyReportar un problema con esta pregunta

  17. 17. Un asistente de la página de pago tiene una meta contractual de latencia p95. La configuración con mejor puntaje en la evaluación de calidad incumple esa meta en un tercio de las solicitudes. ¿Qué debe llevar el arquitecto a la revisión con las partes interesadas?

    • A.Una comparación de las configuraciones probadas en calidad y latencia, con una recomendación que cumpla la meta.✓ Respuesta
    • B.Un ofrecimiento de lanzar la configuración con mejor puntaje junto a una alerta que avise cuando se incumpla.
    • C.Una propuesta de lanzar la configuración con mejor puntaje añadiendo al prompt la orden de responder muy breve.
    • D.Un pedido de reclasificar la meta de latencia como objetivo interno para lanzar la de mejor puntaje sin cambios.

    Una meta contractual de latencia es una restricción dura de diseño, así que legítimamente descarta la configuración más capaz, y la recomendación defendible es la que cumple la restricción declarando en términos de negocio qué calidad cuesta y respaldándolo con una medición. Una alerta informa el incumplimiento después de que el cliente lo sufre, pedir brevedad no controla la latencia de forma fiable, y degradar el compromiso en silencio es renegociar sin acuerdo.

    Ref. QB-FBAAWAFuente: CCAR-P Exam Guide v1.0, Domain 6 — communicate architectural decisions and trade-offs; manage expectation alignment including SLAsReportar un problema con esta pregunta

  18. 18. Una carga extrae campos de un contrato, los valida contra un documento de políticas y luego redacta un único resumen. Cada paso depende del anterior y todo el material entra en una sola ventana de contexto. Un ingeniero propone un orquestador con tres subagentes. ¿Cuál es el mejor diseño?

    • A.Mantener la orquestación y agregar una memoria compartida para que los subagentes no relean el mismo contrato por su lado.
    • B.Colapsar el diseño en un solo flujo secuencial dentro de un contexto, ya que ningún paso arranca antes que el anterior.✓ Respuesta
    • C.Reducir la orquestación a dos subagentes fusionando extracción con validación, para tener menos resultados que unir.
    • D.Conservar los tres subagentes pero darle a cada uno el modelo más barato, para abaratar los turnos de plan y fusión.

    La orquestación multiagente solo conviene cuando hay trabajo masivo realmente paralelo o que excede una ventana de contexto. En una cadena estrictamente dependiente que cabe en un contexto, el orquestador paga turnos de planificación, despacho y fusión que una ejecución secuencial obtiene gratis, y suma modos de fallo de coordinación. Modelos más baratos, menos subagentes o memoria compartida solo recortan el sobrecosto de una estructura que aquí no debería existir.

    Ref. QB-WTRS59Fuente: CCAR-P Exam Guide v1.0, Domain 1 — select architectural patterns (workflow, agentic, augmented LLM); choose the simplest tier that meets the needReportar un problema con esta pregunta

  19. 19. El costo de un bucle de agente está dominado por reenviar una conversación larga en cada turno. Un ingeniero propone limpiar los resultados de herramientas antiguos del historial en cada turno para reducir el gasto. ¿Qué debe decir el arquitecto?

    • A.Limpiar resultados viejos rinde más si corre en cada turno, así que conviene apretar el calendario en vez de dudar.
    • B.Limpiar resultados viejos no surte efecto hasta que la conversación excede la ventana, de modo que hoy no cambia nada.
    • C.Limpiar resultados viejos quita la evidencia en que se apoya el modelo, así que el bucle falla más en los turnos finales.
    • D.Limpiar resultados viejos cambia el prefijo y obliga a recachear, así que sirve para la ventana, no para ahorrar.✓ Respuesta

    La edición de contexto quita resultados de herramientas antiguos del historial, lo que altera el prefijo cacheado, así que toda la conversación vuelve a escribirse en caché en la siguiente solicitud. Como escribir en caché cuesta más que leer, una pasada de limpieza puede costar más que los tokens que elimina. Es una herramienta para no salirse de la ventana, no una palanca de ahorro: esa palanca es un prefijo cacheado estable.

    Ref. QB-EBXXQ9Fuente: CCAR-P Exam Guide v1.0, Domain 4 — optimize token usage and cost-performance trade-offs; Anthropic context editing documentation — context editing is a context-window mechanism, distinct from caching economicsReportar un problema con esta pregunta

  20. 20. Para acotar el gasto de un agente de programación de larga duración, un ingeniero fija un tope bajo de tokens de respuesta. Ahora las ejecuciones se cortan a mitad de una edición y se reintentan desde el principio. ¿Cuál es la configuración correcta?

    • A.Subir de nuevo el tope de respuesta a un valor holgado y marcar el ritmo con un presupuesto que el modelo ve.✓ Respuesta
    • B.Mantener bajo el tope de respuesta e indicar en el prompt que termine cada edición con los tokens que quedan.
    • C.Conservar bajo el tope de respuesta y bajar el esfuerzo, para que el margen vaya a la salida y no al razonamiento.
    • D.Dejar bajo el tope de respuesta y agregar un paso de reanudación desde el punto donde se cortó el intento.

    El tope de tokens de respuesta es un límite impuesto que el modelo nunca ve, así que es un resguardo contra salidas desbocadas y no una perilla de ajuste: alcanzarlo significa un intento fallido, y el reintento cuesta más de lo que el tope ahorró. El presupuesto de tarea es el mecanismo de ritmo, porque es orientativo y visible para el modelo, que así cierra bien dentro del margen. El prompt no puede aportar información que la solicitud no lleva.

    Ref. QB-VPFKAVFuente: CCAR-P Exam Guide v1.0, Domain 4 — optimize token usage and cost-performance trade-offs; Anthropic task budgets documentation — task budget is advisory and model-visible, distinct from the enforced response ceilingReportar un problema con esta pregunta

  21. 21. Un asistente de políticas empieza a devolver respuestas seguras que citan texto de políticas ya derogado. El cambio coincide con una actualización masiva de documentos; la versión del modelo, el nivel de esfuerzo y la latencia siguen iguales. ¿Por dónde debe empezar la investigación?

    • A.En el paso de indexación y recuperación, viendo si la actualización dejó fragmentos viejos que el buscador aún devuelve.✓ Respuesta
    • B.En los parámetros de muestreo, viendo si la temperatura alcanza para que el modelo invente texto de apariencia oficial.
    • C.En la ventana de contexto, viendo si los documentos actualizados ya no entran y se recortan antes de hacer la llamada.
    • D.En los datos de entrenamiento, viendo si el texto que el modelo memorizó es anterior a la versión del corpus nuevo.

    Respuestas seguras pero equivocadas en un hecho concreto, con un cambio de corpus como coincidencia temporal y la configuración del modelo intacta, apuntan a la capa de recuperación y no al modelo: el asistente resume fielmente los fragmentos que recibió, y esos fragmentos están vencidos. Lo primero es verificar si la actualización reindexó y eliminó el contenido derogado. Ni el muestreo ni los datos de entrenamiento cambiaron cuando cambió el comportamiento.

    Ref. QB-C7AEQUFuente: CCAR-P Exam Guide v1.0, Domain 4 — diagnose system issues (prompt failure, hallucinations, model mismatch); official sample item on stale retrieval after a document refreshReportar un problema con esta pregunta

  22. 22. Un equipo midió un modelo más barato sobre una muestra aleatoria de solicitudes de producción y encontró que igualaba al actual en el 90% de ellas. Proponen cambiar toda la ruta. ¿Qué debe exigir el arquitecto antes del cambio?

    • A.Resultados sobre las solicitudes que el modelo actual ya responde bien, porque definen el listón que hay que mantener.
    • B.Resultados sobre una muestra aleatoria más grande, ya que unos cientos más de casos despejarían la duda restante.
    • C.Resultados sobre una muestra cargada con las solicitudes más difíciles, donde se pagan los reintentos y escaladas.✓ Respuesta
    • D.Resultados revisados por los propios ingenieros del equipo sobre esa misma muestra, porque el puntaje no lo ve todo.

    Una muestra aleatoria está dominada por la solicitud mediana, pero la factura y la tasa de fallo las decide la cola difícil, donde un modelo más débil necesita escalamientos, reintentos e intervención humana. La suficiencia se cotiza sobre el décimo más duro de la carga, no sobre el caso promedio. Una muestra aleatoria mayor reproduce la misma distribución, revisar casos fáciles aporta poco, y probar solo lo que el modelo actual ya acierta oculta justo los fallos en disputa.

    Ref. QB-UP495UFuente: CCAR-P Exam Guide v1.0, Domain 4 — design evaluation datasets and test frameworks; Anthropic, 'Optimizing for cost and intelligence' — price the hard tail of the workload, not the median caseReportar un problema con esta pregunta

Otros temas de este examen

Preguntas de práctica basadas en la guía oficial del examen Claude Certified Architect – Professional (CCAR-P) y la documentación pública de Anthropic. Es una herramienta de estudio independiente, no afiliada ni respaldada por Anthropic, y no otorga certificación. Lo administra Pearson VUE; Anthropic publica el número de preguntas, el límite de tiempo, la puntuación de aprobación y la tarifa vigentes en la guía oficial del examen CCAR-P. Página oficial de la certificación →