Diseño de aplicaciones con modelos fundacionales

Diseñar una aplicación con modelos fundacionales no consiste únicamente en elegir un modelo y enviarle un prompt. En un escenario real hay que decidir qué modelo usar, cómo se le entrega el contexto, qué datos puede consultar, qué acciones puede ejecutar, cómo se controla el coste, cómo se mide la calidad y qué mecanismos de seguridad y gobierno se aplican antes de producción.

1. Qué significa diseñar una aplicación con modelos fundacionales

Un modelo fundacional es una pieza central de la solución, pero no es toda la solución. La aplicación completa suele incluir una interfaz de usuario, autenticación, control de acceso, prompts, recuperación de contexto, almacenamiento de conversaciones, monitorización, validaciones, guardrails, integración con APIs y mecanismos de evaluación.

2. El modelo más grande no siempre es el mejor

Una de las ideas más importantes para el examen es que no siempre se debe escoger el modelo más potente. Un modelo más grande puede mejorar la calidad en tareas complejas, pero también puede aumentar coste, latencia y consumo de tokens. En producción, normalmente se elige el modelo que cumple el requisito con el equilibrio adecuado.

3. Diseño básico: prompt directo

El diseño más simple consiste en enviar una instrucción al modelo y recibir una respuesta. Puede ser suficiente para tareas generales como resumir un texto proporcionado por el usuario, reescribir contenido, clasificar una entrada sencilla o generar un borrador.

Este patrón deja de ser suficiente cuando la aplicación necesita conocimiento interno actualizado, permisos por usuario, trazabilidad documental o acciones sobre sistemas externos.

4. Diseño con contexto: prompt engineering y plantillas

El prompt engineering mejora cómo se comunica la aplicación con el modelo. Una plantilla de prompt puede incluir instrucciones del sistema, rol esperado, formato de salida, restricciones, ejemplos y criterios de calidad. Para AIF-C01 debes recordar que muchas mejoras pueden resolverse con prompt engineering antes de pasar a técnicas más costosas.

5. Diseño con RAG: cuando hace falta conocimiento externo o actualizado

RAG, o generación aumentada por recuperación, es un patrón clave. La aplicación busca información relevante en una fuente externa, normalmente una base de conocimiento o una base vectorial, y entrega esos fragmentos al modelo para que genere una respuesta fundamentada.

RAG es muy importante cuando el modelo debe responder sobre documentación privada, políticas internas, manuales técnicos, contratos, procedimientos o información que cambia con frecuencia.

6. Diseño con agentes: cuando el modelo debe actuar

Un agente no solo responde texto. Puede interpretar una intención, decidir qué herramienta usar, consultar una API, buscar información, crear una tarea o ejecutar una acción. En AWS, este patrón se asocia con Agents for Amazon Bedrock.

Los agentes son útiles para flujos donde el usuario expresa una intención en lenguaje natural y la aplicación debe coordinar pasos. Por ejemplo: consultar disponibilidad de un producto, crear una incidencia, revisar estado de un pedido o recuperar información de varias fuentes.

7. Parámetros de inferencia

Los parámetros de inferencia controlan cómo genera la respuesta el modelo. No todos los servicios exponen exactamente los mismos parámetros, pero el examen puede usar conceptos generales como temperatura, longitud máxima de salida o tamaño de contexto.

8. Seguridad y gobierno en el diseño

La seguridad no se añade al final. En una aplicación con modelos fundacionales hay que decidir desde el principio qué datos pueden entrar al modelo, qué contexto se recupera, qué usuarios pueden consultar cada fuente y qué salidas se bloquean o revisan.

9. Coste y rendimiento

El coste de una aplicación GenAI puede crecer por tres motivos principales: usar modelos más caros de lo necesario, enviar demasiado contexto o generar respuestas demasiado largas. La latencia también aumenta cuando el prompt es grande, el modelo es más pesado o la aplicación recupera demasiados documentos.

10. Cuándo usar prompt engineering, RAG, fine-tuning o entrenamiento

En el examen, muchas preguntas se resuelven identificando cuál es el problema real: formato, conocimiento, comportamiento o necesidad de crear un modelo propio.

11. Evaluación antes de producción

No se debe pasar a producción solo porque una demo funcione bien. La evaluación debe usar preguntas representativas, casos límite, contenido sensible y escenarios de error. También debe medir coste, latencia y satisfacción de usuario.

12. Servicios AWS que debes asociar

13. Errores frecuentes

• Elegir siempre fine-tuning. Si el problema es conocimiento cambiante, RAG suele ser más adecuado.
• Confiar solo en el prompt para seguridad. El diseño debe incluir permisos, control de acceso, guardrails y auditoría.
• Ignorar el coste de tokens. Prompts largos y respuestas largas elevan coste y latencia.
• Permitir agentes sin límites. Las acciones reales requieren validación, confirmación y mínimo privilegio.
• No evaluar con casos reales. Una demo controlada no garantiza comportamiento fiable en producción.

Resumen final

Diseñar aplicaciones con modelos fundacionales requiere pensar como arquitecto: elegir el modelo adecuado, diseñar el prompt, decidir si hace falta RAG, controlar permisos, limitar coste, medir calidad y proteger datos. El modelo es solo una parte de la solución.

Para AIF-C01, recuerda el patrón mental: si el problema es estilo, empieza por prompt engineering; si es conocimiento actualizado o privado, piensa en RAG; si el modelo debe actuar, piensa en agentes con controles; si hay riesgo de contenido o seguridad, añade guardrails, permisos y auditoría; si hay coste o latencia, revisa modelo, tokens y contexto.