
Aplicaciones de Foundation Models: Diseño y Prompt Engineering
Exploremos cómo llevar los Foundation Models de la teoría a aplicaciones reales de IA generativa. Vamos a aprender a seleccionar un modelo según criterios como costo, modalidad, latencia y capacidad; conover cómo RAG y Amazon Bedrock Knowledge Bases permiten incorporar información externa y actualizada; y veremos diferentes estrategias de personalización como in-context learning, fine-tuning, model distillation y pre-training.
Series: Reto de Certificación AI Practitioner (9 articles)
- …
- 4Aplicaciones de Foundation Models: Diseño y Prompt Engineering This article
🧠 ¿De dónde vienen los Foundation Models?
Antes de utilizar un Foundation Model (FM), debemos entender que existen diferentes formas de obtenerlo.
👉 Modelos preentrenados
Son modelos que ya fueron entrenados previamente con grandes cantidades de datos.
En lugar de entrenar un modelo desde cero, una organización puede utilizar un modelo existente y adaptarlo a su necesidad.
Por ejemplo, Amazon Bedrock permite acceder a modelos de diferentes proveedores sin tener que construir toda la infraestructura necesaria para entrenarlos.
👉 Modelos personalizados
Otra opción es entrenar un modelo utilizando datos propios, ya sea desde cero o partiendo de un modelo base.
Esto proporciona mayor control y especialización, pero también implica:
- mayor costo
- mayor tiempo
- mayor complejidad técnica
- necesidad de grandes cantidades de datos y recursos
🎯 ¿Cómo elegir el Foundation Model adecuado?
No existe un modelo que sea simplemente "el mejor". El modelo adecuado depende del caso de uso.
Al seleccionar un FM, hay que considerar:
| Criterio | Pregunta que debes hacerte |
|---|---|
| 💰 Costo | ¿Cuánto cuesta procesar los tokens de entrada y salida? |
| 🖼️ Modalidad | ¿Necesito texto, imágenes, audio, video o varias modalidades? |
| ⚡ Latencia | ¿Qué tan rápido necesito obtener una respuesta? |
| 🌎 Multilingüe | ¿Necesito trabajar con varios idiomas? |
| 🧠 Tamaño | ¿Necesito un modelo grande o uno más pequeño puede resolverlo? |
| 🔬 Complejidad | ¿Qué nivel de razonamiento necesita la tarea? |
| 📏 Input/Output | ¿Cuánto contexto necesito enviar y cuánto texto necesito generar? |
| ♻️ Prompt caching | ¿Puedo reutilizar partes de prompts que se repiten para reducir costo y latencia? |
Ejemplo
Imagina un chatbot que responde preguntas sencillas de clientes.
Podrías priorizar:
bajo costo + baja latencia + buena capacidad de comprensión
Pero si estás construyendo una aplicación que necesita analizar documentos complejos y realizar razonamiento avanzado, probablemente otros criterios tendrán mayor peso.
👉 La selección del modelo es una decisión de negocio y técnica al mismo tiempo.
🎛️ Parámetros de inferencia
Una vez seleccionado el modelo, podemos modificar ciertos parámetros durante la inferencia.
Uno de los más importantes es:
🌡️ Temperature
La temperatura controla qué tan variable o creativa puede ser la respuesta.
Temperatura baja
Produce respuestas más:
- predecibles
- consistentes
- conservadoras
Puede ser útil para tareas donde buscamos precisión, por ejemplo:
"Clasifica este ticket como urgente o no urgente."
Temperatura alta
Produce respuestas más:
- variadas
- creativas
- impredecibles
Puede ser útil para:
"Dame 10 ideas para una campaña de marketing."
⚠️ Importante
Temperatura ≠ longitud de respuesta.
La temperatura afecta la variabilidad de la respuesta.
La longitud de salida determina cuánto contenido puede generar el modelo.
📚 RAG: darle al modelo información que necesita
Retrieval-Augmented Generation (RAG)
Los Foundation Models tienen conocimiento proveniente de sus datos de entrenamiento, pero una aplicación puede necesitar información:
- actualizada
- privada
- específica de una empresa
- que no formaba parte del entrenamiento
Aquí entra RAG.
🔄 ¿Cómo funciona?
Imagina que una empresa tiene cientos de documentos:
📄 Manuales
📄 Políticas
📄 FAQs
📄 Documentación interna
📄 Políticas
📄 FAQs
📄 Documentación interna
El flujo sería aproximadamente:
Documentos → Chunks → Embeddings → Vector Store
Cuando un usuario hace una pregunta:
Pregunta → Embedding → Búsqueda semántica → Documentos relevantes → Prompt → Foundation Model → Respuesta
Es decir, en lugar de pedirle al modelo que responda únicamente con lo que aprendió durante su entrenamiento, le proporcionamos información relevante como contexto.
🌟 ¿Qué beneficios tiene?
RAG permite:
- incorporar información externa y actualizada
- utilizar conocimiento privado de una organización
- reducir alucinaciones
- evitar modificar o reentrenar el modelo
Por ejemplo:
Usuario: "¿Cuántos días de vacaciones tengo según la política de la empresa?"
En lugar de esperar que el modelo "conozca" la política, RAG puede recuperar el documento correspondiente y utilizarlo como contexto para generar la respuesta.
☁️ Amazon Bedrock Knowledge Bases
Construir un sistema RAG desde cero implica resolver varias piezas:
- dividir documentos en chunks
- generar embeddings
- almacenarlos
- realizar búsquedas
- recuperar información relevante
Amazon Bedrock Knowledge Bases automatiza gran parte de este proceso.
Esto permite construir aplicaciones de RAG sin tener que implementar manualmente cada componente de la arquitectura.
⚠️ Importante
RAG reduce las alucinaciones, pero no las elimina por completo.
El modelo todavía puede interpretar incorrectamente la información recuperada.
🧩 ¿Dónde almacenamos los embeddings?
Los embeddings son representaciones numéricas del significado de la información.
Para RAG necesitamos almacenarlos en un sistema que permita realizar búsquedas por similitud.
Entre los servicios que debes conocer están:
🔎 Amazon OpenSearch Service
Servicio de búsqueda y análisis con capacidades de búsqueda vectorial.
Es una opción frecuente para arquitecturas RAG.
🗄️ Amazon Aurora
Base de datos relacional que puede utilizar capacidades de búsqueda vectorial.
🕸️ Amazon Neptune
Base de datos orientada a grafos que también soporta búsqueda vectorial.
Puede ser especialmente útil cuando necesitamos representar relaciones complejas entre entidades.
🐘 Amazon RDS for PostgreSQL
Permite almacenar y consultar embeddings mediante capacidades como
pgvector.🛠️ Personalización: ¿RAG, Fine-tuning o algo más?
Una de las preguntas importantes es:
¿Qué técnica debería utilizar para adaptar un Foundation Model a mi necesidad?
No existe una respuesta única.
Depende de qué quieres cambiar.
🟢 In-context learning
Proporcionamos instrucciones o ejemplos directamente en el prompt.
Úsalo cuando:
- necesitas una solución rápida
- la tarea es puntual
- no quieres modificar el modelo
🔵 RAG
Agregamos información externa durante la inferencia.
Úsalo cuando:
- necesitas información actualizada
- necesitas conocimiento privado
- la información cambia frecuentemente
"Quiero que el modelo conozca información externa." → RAG
🟣 Fine-tuning
Ajustamos un modelo preentrenado utilizando datos específicos.
Úsalo cuando necesitas cambiar de manera consistente:
- estilo
- tono
- formato
- comportamiento
🟠 Model Distillation
Entrenamos un modelo más pequeño para aproximarse al comportamiento de uno más grande.
Puede requerir esfuerzo durante el entrenamiento, pero posteriormente puede ayudar a:
- reducir costos
- reducir latencia
- utilizar modelos más pequeños
🔴 Pre-training
Entrenar un Foundation Model desde cero.
Es la alternativa de:
- mayor costo
- mayor esfuerzo
- mayor complejidad
💡 Ojo: estas técnicas pueden combinarse.
Por ejemplo:
Fine-tuning + RAG + prompt engineering
pueden formar parte de una misma aplicación.
✍️ Prompt Engineering: aprender a comunicarnos con el modelo
Un modelo potente no garantiza una buena respuesta si no sabemos cómo darle instrucciones.
El Prompt Engineering consiste en diseñar instrucciones que ayuden al modelo a producir el resultado esperado.
Un prompt puede incluir:
📌 Contexto
Información que ayuda al modelo a entender la situación.
"Eres un asistente de soporte técnico para una empresa de ..."
🎯 Instrucción
Lo que queremos que haga.
"Resume el problema del cliente en máximo tres puntos."
🚫 Prompts negativos
Indicaciones sobre lo que no debe hacer.
"No utilices lenguaje técnico."
🧪 Técnicas de Prompt Engineering
Zero-shot
No proporcionamos ejemplos.
"Clasifica este comentario como positivo, negativo o neutral."
El modelo debe realizar la tarea basándose únicamente en la instrucción.
One-shot / Single-shot
Proporcionamos un ejemplo antes de solicitar la respuesta.
Ejemplo:
"Me encantó el producto" → Positivo, ahora clasifica:
"El producto llegó tarde."
Few-shot
Proporcionamos varios ejemplos para mostrar el patrón esperado.
Esto puede ayudar a mejorar la consistencia cuando la tarea requiere seguir un formato específico.
📌 Recuerda
Más ejemplos pueden mejorar el comportamiento, pero también hacen que el prompt sea más largo y, por lo tanto, pueden aumentar el costo.
🧠 Chain-of-thought
Se solicita al modelo que trabaje un problema mediante una secuencia de razonamiento.
Puede resultar útil especialmente en tareas que requieren razonamiento lógico o matemático.
🧩 Prompt Templates
Son estructuras reutilizables que contienen variables.
Por ejemplo:
"Resume el siguiente texto para un público {audiencia} en máximo {número_palabras} palabras."
La misma plantilla puede utilizarse con diferentes valores.
Esto ayuda a conseguir:
✅ Consistencia
✅ Reutilización
✅ Eficiencia
✅ Reutilización
✅ Eficiencia
💡 ¿Qué hace que un prompt sea bueno?
Un buen prompt no necesariamente es un prompt enorme.
Debe ser:
🎯 Específico
Decir claramente qué queremos.
✂️ Conciso
Evitar información innecesaria.
🧩 Estructurado
Separar instrucciones complejas en partes más claras.
🧪 Probado
Experimentar con diferentes versiones y comparar resultados.
🛡️ Seguro
Incluir instrucciones y mecanismos que ayuden a mantener el comportamiento esperado.
Prompt Engineering suele ser una de las formas más rápidas y económicas de mejorar los resultados de un modelo sin cambiarlo ni hacer fine-tuning.
🔐 Riesgos de Prompt Engineering
El prompt también puede convertirse en una superficie de ataque.
Debemos conocer cuatro riesgos importantes:
👀 Exposure
Información sensible puede ser revelada accidentalmente.
Por ejemplo:
- Información confidencial
- Instrucciones del sistema
- Datos incluidos en el contexto
☠️ Poisoning
Se manipulan los datos utilizados por el sistema para provocar comportamientos incorrectos.
En un sistema RAG, por ejemplo, podrían introducirse documentos maliciosos en la fuente de conocimiento.
🏴☠️ Hijacking
Un atacante intenta conseguir que el modelo ignore sus instrucciones originales y siga instrucciones maliciosas introducidas dentro de la entrada.
Está relacionado con prompt injection.
🔓 Jailbreaking
Se intenta evadir las restricciones de seguridad del modelo para conseguir que genere contenido que normalmente debería rechazar.
🧠 Diferencia clave
Hijacking: "Ignora las instrucciones originales y sigue estas otras."Jailbreaking: "Encuentra una manera de saltarte las restricciones de seguridad."
Aunque pueden estar relacionados, el objetivo del ataque es diferente.
🗂️ Versionar nuestros prompts
En una aplicación real, los prompts también evolucionan.
Podemos tener:
Prompt v1 → Prompt v2 → Prompt v3 → Prompt v4
¿Por qué necesitamos controlar estas versiones?
Porque queremos saber:
- Qué cambió.
- Qué versión está en producción.
- Qué versión produce mejores resultados.
- Cómo regresar a una versión anterior si algo falla.
☁️ Amazon Bedrock Prompt Management
Amazon Bedrock Prompt Management permite crear, gestionar y versionar prompts de manera centralizada.
Esto facilita la:
📌 Trazabilidad
📌 Colaboración
📌 Experimentación
📌 Gestión de versiones
📌 Colaboración
📌 Experimentación
📌 Gestión de versiones
Piensa en un prompt de producción como en cualquier otro artefacto de software:
Si cambia, debe poder rastrearse.
✨ Mantente al día con todas las novedades
AWS Tech Girls
Series: Reto de Certificación AI Practitioner (9 articles)
- …
- 4Aplicaciones de Foundation Models: Diseño y Prompt Engineering This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article