AWS Builder Center
Aplicaciones de Foundation Models: Diseño y Prompt Engineering

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)

  1. …
  2. 4
    Aplicaciones de Foundation Models: Diseño y Prompt Engineering This article
☁️ AI & Cloud | 🚀 AWS Community Builder | ✨ Speaker & Mentor

🧠 ¿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:
CriterioPregunta 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
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

💡 ¿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
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)

  1. …
  2. 4
    Aplicaciones de Foundation Models: Diseño y Prompt Engineering This article
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article