Última revisión: junio de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen AI-103. Lee de arriba a abajo o salta a una sección.
Una función de chat se ejecuta con un gran volumen de interacciones cortas y sencillas, y un presupuesto ajustado de latencia y costo.
Implementar un small language model (SLM) como Phi del catálogo de modelos de Foundry en lugar de un LLM de vanguardia.
Por qué: Los SLM reducen el costo y la latencia para tareas específicas; reservar los LLM grandes para el razonamiento complejo. Haga coincidir el tamaño del modelo con la tarea, no con la marca.
Un único agent debe razonar sobre imágenes y texto subidos por el usuario en una sola solicitud.
Elegir un modelo multimodal (por ejemplo, la familia GPT-4o) en el catálogo de Foundry en lugar de encadenar un modelo de visión en un LLM solo de texto.
Por qué: Los modelos multimodales nativos aceptan imágenes y texto en un solo prompt; un modelo solo de texto fuerza una transferencia de subtítulos con pérdida de información que elimina los detalles visuales.
Las respuestas deben estar fundamentadas en una base de conocimiento corporativa privada, no en el preentrenamiento del modelo.
Construir una capa de recuperación: indexar el corpus en Azure AI Search con vector embeddings y fundamentar el modelo a través de RAG sobre ese índice.
Por qué: La grounding inyecta contexto recuperado y citable en la inferencia; el fine-tuning integra el conocimiento de forma estática y no puede citar ni actualizar a bajo costo.
Un agent necesita llamar a API REST internas y también recuperar de un almacén de documentos indexado.
Registrar las API como tools de agent (function/OpenAPI) y adjuntar el índice de AI Search como fuente de conocimiento en el agent de Foundry.
Por qué: Las tools dan al agent capacidad de acción; las fuentes de conocimiento dan recuperación fundamentada. Son superficies de integración distintas, no el mismo conector.
Varios equipos necesitan configuraciones de agent, conexiones e implementaciones aisladas bajo una gobernanza compartida.
Utilizar un hub de Foundry con proyectos de Foundry por equipo; cada proyecto delimita sus propias conexiones, implementaciones y accesos.
Por qué: El hub centraliza la red, la política y los recursos compartidos; el proyecto es la unidad de espacio de trabajo para una aplicación o un equipo. No comparta un proyecto entre equipos.
Una aplicación de producción necesita residencia de datos predecible y rendimiento reservado para una implementación de modelo.
Utilizar una implementación Standard (regional) o de rendimiento aprovisionado (PTU) en lugar de una implementación Global para cargas de trabajo de alta tasa de transferencia sensibles a la residencia.
Por qué: Las implementaciones Global enrutan a cualquier región para obtener capacidad; Standard fija la región, y PTU reserva capacidad para una latencia estable. Elegir según las necesidades de residencia y SLA.
Las definiciones de prompt y agent deben pasar de desarrollo a producción con revisión y reversión.
Almacenar las definiciones de flujo de prompt / agent como código en un repositorio y promoverlas a través de entornos con pipelines de Azure DevOps o GitHub Actions.
Por qué: Tratar los prompts y la configuración del agent como artefactos versionados; las ediciones manuales en el portal en producción no tienen un registro de auditoría o una ruta de reversión.
Un pico de tráfico activa errores 429 en una implementación de modelo.
Aumentar la cuota de TPM/RPM de la implementación donde esté disponible, añadir reintentos del lado del cliente con retroceso exponencial, y considerar una implementación PTU para capacidad garantizada.
Por qué: La cuota es el límite de tokens por minuto; el retroceso suaviza la limitación transitoria. Poner en marcha recursos duplicados sin una planificación de cuotas solo traslada el cuello de botella.
El gasto es impredecible y está dominado por prompts RAG largos.
Limitar el máximo de tokens de salida, recortar el contexto recuperado a top-k, almacenar en caché el contexto de sistema reutilizable y realizar un seguimiento del uso de tokens por implementación en Azure Monitor.
Por qué: El costo se escala con los tokens de entrada más los de salida; reducir el contexto y las salidas es la palanca directa. Cambiar de región o SKU rara vez cambia significativamente el precio por token.
Con el paso de las semanas, la calidad de las respuestas y la fidelidad de la grounding parecen degradarse en producción.
Ejecutar evaluaciones en línea continuas en Foundry para groundedness, relevancia y coherencia en el tráfico en vivo muestreado y alertar sobre caídas en las puntuaciones.
Por qué: Los evaluadores programados detectan desviaciones que no se pueden ver en las métricas de latencia en bruto; los paneles de CPU/latencia por sí solos nunca revelan una regresión de grounding.
Las respuestas RAG se vuelven obsoletas porque no se recuperan documentos nuevos.
Supervisar el historial de ejecución del indexador de AI Search y el recuento de documentos; programar la indexación incremental y alertar sobre las ejecuciones fallidas del indexador.
Por qué: La calidad de la recuperación se rompe silenciosamente cuando el indexador falla o se retrasa; las métricas del lado del modelo parecen correctas porque la brecha está en el pipeline de datos.
Una aplicación debe llamar a una implementación de modelo de Foundry sin secretos en la configuración.
Habilitar una managed identity en la aplicación y otorgarle el rol "Cognitive Services OpenAI User"; autenticarse con tokens de Entra ID, no con claves de API.
Por qué: La autenticación sin claves de Entra elimina los secretos que pueden filtrarse y centraliza el RBAC; almacenar claves de API, incluso en Key Vault, todavía deja una clave para rotar y proteger.
El tráfico de Foundry nunca debe atravesar la internet pública.
Colocar el recurso de Foundry y sus dependencias detrás de private endpoints, deshabilitar el acceso a la red pública y resolver a través de zonas DNS privadas.
Por qué: Los private endpoints anclan el tráfico a la VNet; las listas de permitidos de IP del firewall aún enrutan a través de endpoints públicos y son un aislamiento más débil.
Las respuestas generadas ocasionalmente incluyen contenido de odio o violento.
Aplicar un filtro de Azure AI Content Safety en la implementación con los umbrales de gravedad apropiados para las categorías de odio, sexual, violencia y autolesiones.
Por qué: Los filtros de contenido examinan los prompts y las completions en el servidor; confiar solo en una instrucción de prompt del sistema es fácilmente eludido por los jailbreaks.
Un agent autónomo puede ejecutar acciones irreversibles, como emitir reembolsos.
Configurar una puerta de aprobación con intervención humana para tools de alto impacto y restringir el agent a un conjunto de acciones permitidas.
Por qué: Los modos de aprobación y las restricciones de acceso a las tools limitan la autonomía; un agent autónomo sin restricciones no tiene freno ante una llamada a una tool destructiva.
Los auditores necesitan ver qué fuentes y tool calls produjeron una respuesta dada.
Habilitar el tracing en Foundry (OpenTelemetry) para capturar prompts, citas recuperadas, invocaciones de tools y salidas por solicitud.
Por qué: Los traces de extremo a extremo proporcionan procedencia y reproducibilidad; las métricas agregadas de tokens por sí solas no pueden reconstruir la cadena de razonamiento de una única respuesta.
Un servicio backend debe llamar a modelos y agents definidos en un proyecto de Foundry.
Utilizar el SDK de Azure AI Foundry (AIProjectClient) con la cadena de conexión del proyecto y una DefaultAzureCredential para obtener clientes de modelos y agents.
Por qué: El cliente de proyecto resuelve conexiones e implementaciones de forma centralizada; codificar los endpoints y claves de cada modelo elude la gobernanza del proyecto.
Construir una aplicación de preguntas y respuestas basada en documentos de política.
Incrustar e indexar los documentos, recuperar top-k chunks por consulta y pasarlos como contexto a la completion de chat con una instrucción de citar las fuentes.
Por qué: RAG mantiene el conocimiento actualizado y citable sin volver a entrenar; pasar el corpus completo al prompt agota la ventana de contexto y aumenta el costo.
El modelo debe consultar el estado de un pedido en vivo durante una conversación.
Definir una tool con un JSON schema, permitir que el modelo emita una tool call, ejecutarla en el servidor y devolver el resultado para que el modelo lo resuma.
Por qué: La function-calling/tool calling permite que el modelo invoque sistemas reales de forma determinista; pedirle que "adivine" el estado produce fabricaciones.
Una tarea necesita varias tool calls dependientes antes de una respuesta final.
Ejecutar un bucle de uso de tools: devolver cada resultado de la tool al modelo e iterar hasta que devuelva un mensaje final, con un límite máximo de iteraciones.
Por qué: Los bucles de tool iterativos soportan el razonamiento multifase; un solo viaje de ida y vuelta no puede encadenar búsquedas dependientes, y un bucle sin límite puede descontrolarse.
Antes de la publicación, cuantificar con qué frecuencia una aplicación RAG "alucina" o se desvía del tema.
Ejecutar evaluadores de Foundry para groundedness, relevancia y coherencia sobre un conjunto de pruebas etiquetado y restringir la publicación en función de las puntuaciones umbral.
Por qué: Los evaluadores incorporados proporcionan señales medibles de calidad y seguridad; revisar unos pocos ejemplos a ojo no detecta la fabricación sistemática.
Definir un agent de soporte con una persona, objetivos y límites claros.
Establecer las instrucciones del sistema del agent (rol, objetivos, reglas de rechazo) y adjuntar solo las tools que necesita para su alcance.
Por qué: Las instrucciones estrictas más el acceso mínimo a las tools mantienen al agent en su tarea; las instrucciones amplias y todas las tools invitan a la expansión del alcance y a acciones inseguras.
Un agent debe recordar el contexto a lo largo de las interacciones dentro de una sesión.
Utilizar los threads del Servicio de Agent de Foundry, que persisten el historial de mensajes por conversación para que cada ejecución vea las interacciones anteriores.
Por qué: Los threads proporcionan memoria de conversación gestionada; reenviar toda la transcripción manualmente en cada llamada es frágil y fácil de truncar incorrectamente.
Un agent necesita web grounding y ejecución de código sin una implementación personalizada.
Adjuntar tools de agent de Foundry incorporadas como Grounding con Bing Search y el Code Interpreter en lugar de implementar integraciones manualmente.
Por qué: Las tools gestionadas se gobiernan y soportan de forma predeterminada; las reimplementaciones personalizadas añaden mantenimiento y omiten los controles de seguridad de la plataforma.
Un agent primario debe delegar preguntas de facturación a un agent de facturación especializado.
Utilizar connected agents: exponer el agent de facturación como una tool que el agent principal puede llamar, de modo que enrute las subtareas a especialistas.
Por qué: Los connected agents permiten la delegación jerárquica; meter todos los dominios en un solo mega-agent hincha las instrucciones y degrada la precisión.
Un flujo de trabajo necesita un planificador, un investigador y un escritor colaborando con un estado compartido.
Orquestarlos con un framework multi-agent (Semantic Kernel / AutoGen en Foundry) utilizando un patrón de orquestación definido y contexto compartido.
Por qué: Los frameworks gestionan los turnos, el estado y la terminación; el paso ad-hoc de cadenas entre agents no tiene coordinación ni condición de parada.
Un agent se ejecuta sin supervisión durante la noche y no debe realizar acciones arriesgadas por sí solo.
Limitarlo con tools permitidas, presupuestos por acción, filtros de contenido y un punto de control que eleve los pasos de alto impacto para su aprobación.
Por qué: Las salvaguardias en capas mantienen la autonomía segura; un bucle autónomo con acceso completo a las tools y sin puerta de aprobación puede causar daños irreversibles.
Un agent falla intermitentemente a mitad de una tarea y debe encontrar el paso fallido.
Inspeccionar los pasos trazados y las entradas/salidas de tool-call de la ejecución en Foundry para localizar la tool fallida o el argumento malformado.
Por qué: Los traces a nivel de paso señalan dónde falló una ejecución; un único mensaje de error final oculta qué tool call o paso de razonamiento falló realmente.
Las salidas son inconsistentes e ignoran las instrucciones de formato.
Utilizar un mensaje de sistema claro, ejemplos few-shot y restricciones de salida explícitas; para una forma estricta, habilitar structured outputs / JSON schema.
Por qué: El prompting estructurado y las salidas forzadas por esquema hacen que los resultados sean fiables; aumentar la temperature o reintentar a ciegas no corrige el seguimiento de instrucciones.
Una tarea de copia creativa se siente demasiado repetitiva; una tarea de extracción de datos es demasiado aleatoria.
Aumentar temperature/top-p para la tarea creativa y reducirlos hacia 0 para la extracción para hacerla determinista.
Por qué: Los parámetros de muestreo intercambian diversidad por determinismo; cambiar de modelo es excesivo cuando la configuración del parámetro es la causa real.
Un reasoning agent comete errores lógicos evitables en tareas difíciles.
Añadir un paso de reflexión / autocrítica donde el agent revise y corrija su borrador, o utilizar un modelo de razonamiento para el paso.
Por qué: Chain-of-thought y la autocrítica mejoran la precisión en tareas difíciles; un único paso hacia adelante no tiene oportunidad de detectar su propio error.
Operaciones necesita el gasto de tokens, la latencia y las señales de seguridad por solicitud en producción.
Emitir traces y métricas de OpenTelemetry desde la aplicación a Azure Monitor / Application Insights, capturando tokens, latencia y banderas de content-safety.
Por qué: La observabilidad unificada relaciona el costo, el rendimiento y la seguridad; el raspado manual de logs no puede correlacionar una interacción lenta con su uso de tokens.
Una aplicación mezcla clasificación económica con razonamiento complejo ocasional.
Orquestar múltiples implementaciones: enrutar interacciones simples a un SLM y escalar interacciones difíciles a un LLM de vanguardia detrás de una capa de aplicación.
Por qué: El enrutamiento de modelos optimiza el costo y la calidad por interacción; usar un modelo premium para todo es un sobrepago para la mayoría fácil.
Una aplicación de marketing debe generar imágenes originales a partir de prompts de texto.
Implementar un modelo de generación de imágenes (por ejemplo, DALL-E / GPT-image en el catálogo de Foundry) y llamarlo con el prompt de texto y los parámetros de tamaño.
Por qué: Los modelos generativos de imágenes sintetizan nuevos elementos visuales; la API de Image Analysis (vision) solo describe imágenes existentes, no puede crearlas.
Reemplazar solo el fondo de una foto de producto existente, manteniendo el producto intacto.
Utilizar el endpoint de edición de imagen (inpainting) con la imagen de origen más una máscara que marca solo la región editable.
Por qué: Una máscara limita las ediciones al área pintada; una llamada simple de text-to-image regenera todo el encuadre y pierde el producto original.
Producir clips de vídeo cortos generados a partir de una descripción de texto.
Utilizar un modelo de text-to-video como Sora en el catálogo de Foundry con parámetros de prompt, duración y resolución.
Por qué: La generación de vídeo es una familia de modelos distinta; los modelos de imagen producen fotogramas individuales y no pueden generar movimiento temporal.
Los usuarios hacen preguntas de formato libre sobre una imagen de gráfico subida.
Enviar la imagen más la pregunta a un LLM multimodal (GPT-4o) para respuestas a preguntas visuales y una respuesta en lenguaje natural.
Por qué: El chat multimodal maneja preguntas y respuestas visuales abiertas; el etiquetado de imágenes de taxonomía fija devuelve etiquetas, no respuestas a preguntas arbitrarias.
Generar automáticamente texto alternativo descriptivo para miles de imágenes para accesibilidad.
Utilizar la capacidad de caption / dense-captions de Image Analysis para producir descripciones legibles por humanos a escala.
Por qué: El captioning produce directamente texto alternativo conciso; la detección de objetos devuelve bounding boxes que aún necesitan ser convertidas en prosa.
Extraer campos estructurados e información a nivel de segmento de vídeos grabados largos.
Utilizar Azure AI Content Understanding con un analizador de vídeo para obtener una salida estructurada y definida por esquema a lo largo de la línea de tiempo.
Por qué: Content Understanding produce salida estructurada fundamentada a través de modalidades; las llamadas a imágenes fotograma a fotograma no proporcionan una estructura consciente de la línea de tiempo.
Un agent multimodal lee imágenes de usuario que pueden contener texto de instrucción oculto.
Habilitar prompt shields / detección de indirect-injection y tratar el texto dentro de las imágenes como datos no confiables, no como instrucciones.
Por qué: El texto de imagen incrustado es un vector clásico de indirect prompt-injection; pasar texto OCR'd directamente al prompt del sistema permite a los atacantes secuestrar al agent.
Extraer nombres, fechas y cantidades de correos electrónicos a un registro JSON tipado.
Generar un prompt a un LLM con un JSON schema objetivo y habilitar structured outputs para que cada campo se devuelva en una forma fija.
Por qué: La extracción por LLM con restricciones de esquema maneja formatos abiertos y garantiza JSON parseable; las regex frágiles se rompen ante la variedad del lenguaje natural.
Producir un resumen conciso y reescrito de transcripciones de soporte largas.
Utilizar un LLM para la abstractive summarization con una instrucción de longitud y enfoque, o la skill de summarization del servicio Language.
Por qué: Los resúmenes abstractivos parafrasean la idea principal; la extracción de frases solo copia oraciones y puede perder el punto general.
Clasificar mensajes de clientes por sentimiento y marcar el tono agresivo.
Utilizar un LLM (o la API de sentiment de Language) para etiquetar la polaridad y detectar el tono, devolviendo una categoría y confianza.
Por qué: El análisis de sentimiento/tono es una tarea de clasificación con etiquetas definidas; la generación de texto libre sin un esquema de etiquetas es difícil de enrutar en procesos posteriores.
Traducir grandes volúmenes de cadenas de UI de forma precisa y económica en 30 idiomas.
Utilizar Azure AI Translator para traducción masiva y determinista; reservar un LLM para pasajes con matices y mucho contexto.
Por qué: Translator está diseñado para su propósito, es más económico y consistente a escala; un LLM por cadena cuesta más y puede variar en tono entre ejecuciones.
Un voice agent debe transcribir audio de llamadas en tiempo real.
Utilizar el servicio Speech speech-to-text en tiempo real (o transcripción rápida) para alimentar texto en el pipeline del agent.
Por qué: El STT en streaming proporciona transcripciones parciales de baja latencia para conversaciones en vivo; la transcripción por lotes es para archivos sin conexión, no para interacciones en vivo.
La transcripción malinterpreta nombres de productos y jerga médica.
Entrenar un modelo de Custom Speech con audio de dominio y listas de frases para mejorar el reconocimiento de vocabulario especializado.
Por qué: Custom Speech adapta el modelo acústico/de lenguaje a sus términos; el modelo base no tiene exposición a su jerga privada.
El agent debe responder con audio hablado de sonido natural.
Utilizar neural Text to Speech con una voz apropiada y SSML para controlar la prosodia, las pausas y la pronunciación.
Por qué: Neural TTS más SSML produce un habla realista y controlable; el texto plano sin SSML produce un fraseo monótono en números y nombres.
La recuperación solo basada en vectores omite coincidencias exactas de palabras clave e identificadores de código.
Utilizar hybrid search en Azure AI Search (vector más palabra clave) con semantic ranking para reordenar los resultados fusionados.
Por qué: Hybrid search más reranking semántico supera a cualquiera de las señales por separado; la búsqueda puramente vectorial puede omitir términos literales, la puramente por palabras clave omite la paráfrasis.
El corpus incluye PDFs escaneados cuyo texto no es seleccionable.
Añadir una cognitive skill de OCR (Document Intelligence / Vision) al skillset de indexación para que el texto escaneado se extraiga antes del chunking y el embedding.
Por qué: El enriquecimiento con OCR extrae texto de imágenes para su recuperación; indexar el PDF escaneado sin procesar no produce nada que se pueda buscar.
Durante la ingesta, necesita OCR, extracción de frases clave y traducción aplicada por documento.
Definir un skillset de AI Search que encadene las cognitive skills necesarias, proyectando las salidas en los campos del índice que el indexador rellena.
Por qué: Un skillset orquesta declarativamente el enriquecimiento en tiempo de indexación; hacerlo en el código de la aplicación por consulta repite el trabajo y rompe la reutilización.
Quiere que el chunking y el embedding se manejen dentro del pipeline de índice, no en el código de la aplicación.
Utilizar la integrated vectorization de AI Search para dividir documentos y llamar a un embedding model durante la indexación y en tiempo de consulta.
Por qué: La integrated vectorization mantiene la coherencia del chunking/embedding entre la ingesta y la consulta; el embedding personalizado en el lado del cliente arriesga una falta de coincidencia del modelo.
Extraer campos estructurados de facturas con diseños variados.
Utilizar un modelo de factura preconstruido de Document Intelligence, o entrenar un modelo personalizado, para devolver campos tipados con confianza y regiones delimitadoras.
Por qué: Document Intelligence comprende el diseño y devuelve campos tipados; un volcado solo con OCR proporciona texto sin procesar sin semántica de campo.
Necesita una representación markdown limpia y fundamentada de documentos mixtos para RAG.
Utilizar analizadores de Content Understanding para producir salida estructurada / markdown que preserve encabezados, tablas y la grounding de campos.
Por qué: El markdown fundamentado mantiene la estructura y las citas para la recuperación; el texto plano aplanado pierde tablas y el contexto de sección que el modelo necesita.
Un agent de Foundry debe recuperar información de su índice de búsqueda enriquecido en tiempo de ejecución.
Añadir el índice de AI Search como fuente de conocimiento / tool en el agent para que cada ejecución base las respuestas en resultados recuperados y citados.
Por qué: Conectar el índice como una tool de agent proporciona recuperación fundamentada en vivo; pegar fragmentos estáticos en las instrucciones no puede mantenerse actualizado con el corpus.