Fundamentos de IA generativa: tokens, transformers, prompting y modelos fundacionales

Esta es la lección de mayor apalancamiento del curso. El Dominio 2 (Fundamentos de IA generativa) pesa un 24% y el Dominio 3 (Aplicaciones de modelos fundacionales) pesa un 28% del contenido puntuado, 52% en total, y casi toda pregunta dentro de esos dos dominios se construye con el mismo conjunto pequeño de objetos: un token, una ventana de contexto, un prompt, un parámetro de inferencia, un embedding y un modelo fundacional (FM). Aprende los objetos y los números pegados a ellos, y medio examen se convierte en aritmética más vocabulario en lugar de adivinación.

Al terminar esta lección sabrás:

• explicar la autoatención en términos de consulta/clave/valor y decir por qué los transformers superan a las RNN en secuencias largas;
• estimar tokens con ambas reglas publicadas por AWS (6 caracteres por token, y 4,7 caracteres por token para embeddings en inglés) y saber cuál de las dos usa la pregunta;
• presupuestar una ventana de contexto como prompt del sistema + entrada del cliente + contexto RAG + salida, y predecir qué hace un Context Window Overflow al comportamiento;
• elegir entre zero-shot, few-shot, cadena de pensamiento, autoconsistencia y encadenamiento de prompts y enunciar el coste de cada uno;
• fijar temperatura, top-p, top-k, máx. de tokens, secuencias de parada y penalizaciones para una carga de trabajo y defender la respuesta de determinismo;
• leer una tabla de modalidades y elegir la familia de FM correcta para entradas de texto, embeddings, imagen, video o imagen+texto;
• recorrer el espectro de personalización desde el prompt engineering hasta un modelo a medida y nombrar las cifras que AWS adjunta a la destilación y al fine-tuning por refuerzo;
• evaluar un FM con ROUGE, BLEU, BERTScore, LLM-as-a-judge y evaluación humana;
• aplicar las seis políticas de Guardrails y la escalera de mitigación de alucinaciones de tres pasos;
• defender el veredicto comparativo entre IA generativa, ML tradicional y sistemas basados en reglas.

---

1. Qué es la IA generativa, y qué no es

1.1 La definición que el examen realmente usa

La IA generativa es la clase de sistemas que crea contenido nuevo: texto, código, imágenes, video, audio y embeddings. Esa única palabra, nuevo, es toda la distinción. Un modelo de ML tradicional responde «¿a qué cubo pertenece esta fila?»; un modelo generativo responde «escríbeme algo que pertenezca a este cubo». Los modelos fundacionales son los motores de debajo: modelos grandes entrenados en corpus amplios que tú adaptas mediante prompting, generación aumentada por recuperación (RAG) o fine-tuning en lugar de reentrenar.

AWS es explícito sobre el intercambio. Los modelos fundacionales son no deterministas: «las mismas entradas pueden producir respuestas distintas». Esa propiedad es lo que los hace útiles para redactar y hacer lluvia de ideas, y lo que los hace peligrosos para extracción, puntuación y cualquier cosa que un auditor lea dos veces.

1.2 Las ventajas y los riesgos que nombra AWS

La guía del examen enumera cuatro ventajas y cuatro desventajas. No son decoración: cada ventaja se empareja con un control, y cada riesgo se empareja con una mitigación que se te pedirá nombrar.

1.3 El ciclo de vida del modelo fundacional

La Tarea 2.1 exige el ciclo de vida en orden. También es la forma de la mayoría de preguntas de secuenciación del examen.

• 📚 ¿Sabías que…? La propia redacción de la guía del examen para el ciclo de vida es un ciclo, no una línea: la retroalimentación vuelve a la selección de datos. Por eso «monitoriza el modelo desplegado y devuelve datos de producción al corpus» se lee como correcto en el examen, mientras que «el despliegue es el paso final» se lee como un distractor, y es el mismo bucle que hace de la desviación un problema de IA generativa y no solo un problema de ML clásico.

---

2. Tokens: la unidad en la que se mide todo

2.1 Qué es un token

Un token es el trozo de texto que un modelo realmente lee y escribe. Un tokenizador divide el texto bruto en tokens antes de que el modelo lo ve, y la generación ocurre un token a vez. La propiedad crítica es que la tokenización es específica del modelo: la misma frase puede ser de 12 tokens en un modelo y de 17 en otro, y por eso una fórmula fija de «palabras ÷ X = tokens» no es fiable, y por eso Amazon Bedrock expone una API CountTokens que cuenta con el tokenizador del modelo seleccionado sobre la entrada exacta que vas a invocar.

La fragmentación es el concepto compañero: cuando un documento es más largo que el límite de entrada de un modelo, lo divides en segmentos (párrafos, secciones, páginas) para que cada segmento quepa. La calidad de la fragmentación es la palanca más grande de un sistema RAG: AWS publicó un caso en el que una mejor fragmentación por sí sola elevó la relevancia contextual del 67% al 93% y eliminó alucinaciones sin cambiar el prompt.

2.2 Las dos reglas de estimación publicadas por AWS

2.3 Ejemplo resuelto 1: cuota de fine-tuning en caracteres

Un equipo quiere hacer fine-tuning de Amazon Titan Text G1 Express y tiene un prompt de muestra de 30.000 caracteres. La cuota de fine-tuning con batch size 1 para ese modelo es de 4.096 tokens de entrada+salida.

1. Convierte la cuota a caracteres: $4{,}096 \times 6 = 24{,}576$ caracteres permitidos.
2. Convierte la muestra a tokens: $30{,}000 \div 6 = 5{,}000$ tokens: 904 tokens por encima de la cuota de 4.096.
3. Convierte el exceso de vuelta a caracteres: $30{,}000 - 24{,}576 = 5{,}424$ caracteres de más.

Respuesta: la muestra supera la cuota en 5.424 caracteres; divídela en dos registros o trúncala. El distractor «50.000 caracteres» es el límite de Titan Embeddings V2, un modelo distinto con un límite distinto.

2.4 Ejemplo resuelto 2: ¿qué límite de embeddings actúa primero?

Titan Text Embeddings V2 acepta 8.192 tokens o 50.000 caracteres. ¿Cuál de los dos detiene primero un documento largo en inglés?

1. El inglés promedia 4,7 caracteres por token, así que el límite de tokens actúa en $8{,}192 \times 4.7 \approx 38{,}502$ caracteres.
2. Un artículo de 50.000 caracteres se convierte por tanto en $50{,}000 \div 4.7 \approx 10{,}638$ tokens.
3. Exceso: $10{,}638 - 8{,}192 = 2{,}446$ tokens.

Respuesta: el límite de tokens actúa primero, en unos 38.502 caracteres para inglés: 11.498 caracteres antes del techo de 50.000 caracteres. El remedio documentado por AWS es segmentar el documento en párrafos o secciones e insertar cada uno.

• 📚 ¿Sabías que…? El endpoint CountTokens de Bedrock responde una pregunta que ninguna fórmula puede: ejecuta el tokenizador del propio modelo invocado sobre tu cadena exacta. El mismo artículo de 47.000 caracteres puede estar por encima del presupuesto en un modelo y cómodamente por debajo en otro, y por eso AWS documenta CountTokens como el paso de planificación previo a cualquier llamada sensible a cuotas, y no como una comodidad opcional.

---

3. Transformers y autoatención: cómo lee un modelo una secuencia

3.1 Consulta, clave y valor

La autoatención permite que cada token de una secuencia mire a todos los demás y decida qué importa. Cada embedding de token se proyecta en tres vectores, y las descripciones de AWS son la redacción exacta que usa el examen:

Las puntuaciones de atención se calculan a partir de Q emparejada contra K, y después se usan para ponderar los vectores V. El resultado es una representación de cada token que ya contiene su contexto, y por eso «banco» en «banco del río» y «banco» en «cuenta bancaria» terminan como vectores distintos aunque fueran la misma cadena de entrada.

3.2 El bloque transformer y la codificación posicional

Un bloque transformer es, en la definición de AWS, autoatención multicabeza más una red feed-forward por posición. Varias cabezas atienden en paralelo para que cabezas distintas puedan especializarse: una siguiendo la sintaxis, otra la correferencia, otra la distancia. Como la atención en sí es ciega al orden, la codificación posicional inyecta el orden de la secuencia para que el modelo sepa qué token vino primero.

3.3 Por qué los transformers superan a las RNN y por qué los modelos tipo GPT son pilas de decodificadores

Los transformers procesan la secuencia completa en paralelo, donde una RNN debe recorrerla una posición a vez. Las consecuencias son las dos cosas que vale la pena memorizar: entrenamiento más rápido y la capacidad de manejar secuencias mucho más largas. Los modelos tipo GPT son pilas de bloques de decodificador y son autorregresivos: producen un token, lo añaden a la entrada y vuelven a ejecutar.

---

4. Embeddings, vectores y bases de datos vectoriales

4.1 De las tablas one-hot al espacio de embeddings

Antes de los embeddings, los datos categóricos vivían en tablas one-hot: un vector alto y disperso donde cada palabra era una columna independiente y no existía noción de significado entre ellas. Los embeddings reemplazan eso con un vector denso en el que palabras semánticamente similares quedan unas cerca de otras. La recompensa es aritmética que el one-hot encoding nunca pudo hacer: el ejemplo documentado por AWS es París − Francia + Alemania ≈ Berlín, donde la dirección entre dos embeddings codifica una relación.

4.2 ¿Quién calcula la similitud: el modelo o la base de datos?

Un detalle que decide muchos puntos: el modelo produce el vector; la base de datos vectorial calcula la similitud, usando similitud coseno o k vecinos más cercanos (k-NN). La recuperación en un pipeline RAG es por tanto una operación de base de datos, y la guía del examen nombra los almacenes de embeddings que espera que reconozcas.

4.3 Los modelos de embeddings y sus límites verificados

4.4 Ejemplo resuelto 3: lo que un almacén de vectores te cuesta realmente en bytes

Titan Text Embeddings V2 devuelve 1.024 dimensiones. Asumiendo floats de 32 bits (4 bytes por valor: una asunción, no una cifra publicada por AWS), un vector es:

$$1{,}024 \times 4\ \text{bytes} = 4{,}096\ \text{bytes} \approx 4\ \text{KB}$$

Para una base de conocimiento de 100.000 pasajes:

$$100{,}000 \times 4\ \text{KB} = 400{,}000\ \text{KB} \approx 400\ \text{MB}$$

Respuesta: aproximadamente 400 MB de carga útil de vectores en bruto antes de la sobrecarga del índice, los metadatos y el sharding. Ese es el número que te llevas a la elección entre OpenSearch, Aurora (pgvector), Neptune, DocumentDB y RDS for PostgreSQL, y es la razón por la que la reducción de dimensionalidad a 512 o 256 (ambas admitidas por V2) es una palanca de coste legítima: al mitad las dimensiones, la carga útil en bruto se reduce a unos 200 MB.

• 📚 ¿Sabías que…? La aritmética de embeddings no es un truco de fiesta: es evidencia de que el espacio de vectores codifica relaciones como direcciones. París − Francia + Alemania ≈ Berlín funciona porque el desplazamiento de «capital de» es coherente entre países. En el examen esto aparece de forma indirecta: cuando una pregunta dice que los vectores colocan elementos semánticamente similares cerca unos de otros, la respuesta pretendida casi siempre trata sobre similitud coseno en una base de datos vectorial, no sobre el modelo releyendo el texto.

---

5. Prompt engineering: la primera palanca que siempre debes tirar

5.1 El vocabulario de los shots

5.2 La tabla de técnicas

5.3 Cadena de pensamiento: qué compra y qué cuesta

Amazon Bedrock documenta que la cadena de pensamiento, comercializada como model reasoning en la consola, «a menudo puede mejorar la precisión del modelo al darle al modelo la oportunidad de pensar antes de responder». El coste es igual de explícito: latencia aumentada y tokens de salida aumentados. Y la exclusión importa tanto como el beneficio: AWS afirma que las tareas simples no son buen candidato para la cadena de pensamiento. Pedir a un modelo que razoné extensamente para clasificar un ticket de soporte en una de cuatro colas es pagar tokens de salida sin precisión.

5.4 El árbol de decisión del prompt engineering

5.5 Ejemplo resuelto 4: lo que el few-shot prompting cuesta de verdad

Una instrucción cuesta 80 tokens; un ejemplo etiquetado cuesta 60 tokens.

Respuesta: un prompt de 5-shot cuesta 4,75× los tokens de entrada del zero-shot por la misma única respuesta. Como AWS dice que de 3 a 5 ejemplos bastan para clasificación simple de texto, 3 shots es el punto óptimo: obtienes control de formato a 3,25× en lugar de 4,75×. Y si después añades cadena de pensamiento, el coste se mueve al lado de la salida, donde el maxTokenCount predeterminado de Titan Text de 512 empieza a morder; súbelo antes de activar el razonamiento.

• 📚 ¿Sabías que…? La guía de prompt engineering de AWS esconde dos hábitos que separan un prompt que funciona de una demo: pon la pregunta o la instrucción al final del prompt (para que los tokens más relevantes queden más cerca de donde empieza la generación), y mantén un conjunto reservado de prompts que nunca enseñes al equipo mientras iteras. Sin el conjunto reservado, «el prompt mejoró» es una anécdota: la misma disciplina que un conjunto de prueba reservado en ML clásico, aplicada al texto.

---

6. Parámetros de inferencia: dirigir el siguiente token

6.1 La tabla completa de parámetros

Cada número de aquí está verificado contra las páginas Inference response generation y Titan Text de Bedrock.

6.2 Los valores predeterminados que debes saber de memoria

6.3 Ejemplo resuelto 5: tres cargas de trabajo, tres conjuntos de parámetros

Un equipo ejecuta tres trabajos sobre el mismo modelo Titan Text Express. Asume el mismo prompt y el mismo tope de salida predeterminado de 512 tokens.

1. Extracción de cláusulas contractuales (debe ser auditable): temperatura 0,0, top-p bajado de 0,9 hacia 0,1 to 0,3. Efecto: la distribución se pronuncia, el conjunto de candidatos se encoge, y las re-ejecuciones convergen en la misma extracción.
2. Lluvia de ideas de titulares de campaña: temperatura 1,0, top-p dejado en 0,9. Efecto: la distribución se aplana, más de la cola es alcanzable, y la diversidad sube: al coste de la reproducibilidad.
3. Razonamiento de cadena de pensamiento sobre una respuesta de 400 tokens: temperatura 0,2, pero maxTokenCount subido de 512 a al menos 1.024, porque los tokens de razonamiento son tokens de salida. Dejar el predeterminado trunca la cadena en medio de la derivación.

Respuesta: el determinismo se compra con temperatura y top-p; la creatividad con temperatura; y la capacidad de razonamiento con máx. de tokens: el parámetro que más a menudo se olvida, porque el fallo parece un error y no un ajuste.

---

7. Ventanas de contexto: el presupuesto que falla en silencio

7.1 Qué cabe realmente

La ventana de contexto es el número máximo de tokens que un modelo considera a la vez, y es un presupuesto sobre todo en la llamada:

$$\text{context window} \ge \text{system prompt} + \text{client input} + \text{RAG context} + \text{output}$$

Fija maxTokenCount por sustracción: ventana − tokens de entrada − margen de seguridad. Nunca por intuición.

7.2 El buffer circular FIFO y el Context Window Overflow

El blog de seguridad de AWS describe la ventana de contexto como un buffer circular FIFO. Una vez lleno, cada token nuevo expulsa en silencio el token más antiguo, sin error, sin advertencia, solo comportamiento a la deriva. El fenómeno tiene nombre en AWS: Context Window Overflow (CWO). La historia de terror práctica es que el prompt del sistema suele ser el contenido más antiguo, así que bajo CWO las instrucciones que definen el comportamiento de tu agente son lo primero en desaparecer, y la aplicación sigue devolviendo 200 OK mientras ignora sus propias reglas.

7.3 Ejemplo resuelto 6: un presupuesto de ventana de contexto

Prompt del sistema 400 + pasajes RAG 1.600 + historial de conversación 900 + pregunta 100:

$$400 + 1{,}600 + 900 + 100 = 3{,}000\ \text{input tokens}$$

Con maxTokenCount en el máximo de Titan Text Premier de 3.072, el total se convierte en $3{,}000 + 3{,}072 = 6{,}072$ tokens de demanda. Si la ventana del modelo es menor que eso, el desbordamiento no lanza una excepción: los 3.000 tokens más antiguos aproximadamente (empezando por el prompt del sistema) se expulsan a medida que avanza la generación, y el comportamiento se va a la deriva en lugar de fallar.

Corrige, en orden: ejecuta CountTokens sobre el prompt exacto → fija maxTokenCount = ventana − entrada − margen → acorta u ordena de nuevo los pasajes RAG → resume turnos más antiguos del historial.

7.4 El flujo de generación de extremo a extremo

• 📚 ¿Sabías que…? La ventana de contexto no se publica como un único número fijo por familia de modelo en las páginas que AWS ha verificado para este resumen, así que los ítems de «¿qué modelo tiene la ventana más grande?» dependen de anuncios y deben re-comprobarse cerca del día del examen. Lo que sí está verificado y es estable: los máximos de maxTokenCount de Titan Text (4.096 / 8.192 / 3.072), Titan Embeddings 8K tokens, Embeddings V2 8.192 tokens, la suma de entrada + salida del fine-tuning de Llama 16.000 (10.000 para el 90B), y el fine-tuning de Claude 3 Haiku 32.000 tokens. Presupuesta desde esas cifras, no desde un titular de blog.

---

8. Modelos fundacionales por modalidad, y cómo se hacen las imágenes

8.1 La tabla de modalidades

8.2 Cómo un modelo de difusión produce una imagen

El entrenamiento de difusión enseña a un modelo a eliminar ruido que se añadió a imágenes reales. La generación ejecuta ese proceso al revés: empieza desde ruido aleatorio y elimina el ruido iterativamente, cada paso condicionado por el embedding del prompt de texto. La difusión latente hace el trabajo en un espacio latente comprimido (una U-Net, o un removedor de ruido transformer) y solo entonces decodifica a píxeles.

Amazon Nova Canvas y Nova Reel son modelos de difusión latente con backbones transformer, a menudo llamados diffusion transformers, construidos con tres partes: un VAE que convierte entre píxeles y tokens visuales, un codificador de texto para el prompt, y un removedor de ruido transformer. Amazon Titan Image Generator es un FM de difusión condicionado por texto: codifica el prompt, empareja vectores en un espacio conjunto de embeddings texto/imagen, y convierte una codificación aleatoria de baja resolución en la imagen final.

8.3 Ejemplo resuelto 7: las entradas de visión también son aritmética de tokens

La fórmula publicada por AWS para los tokens de imagen en el fine-tuning de visión de Llama es:

$$\text{tokens} = \min(2, \max(H // 560,\ 1)) \times \min(2, \max(W // 560,\ 1)) \times 1601$$

Contra la cuota de fine-tuning de 16.000 de suma de entrada más salida para Meta Llama 3.2: una imagen de 1.120 × 1.120 = 6.404 ✓, dos = 12.808 ✓, tres = 19.212 ✗: por encima de la cuota.

Respuesta: dos imágenes grandes caben, tres no, y el comportamiento de fijado significa que una imagen pequeña todavía cuesta al menos 1.601 tokens.

• 📚 ¿Sabías que…? Amazon Titan Image Generator se envía con una marca de agua invisible activada por defecto y acepta como máximo 5 imágenes de referencia: ambos son hechos con forma de examen porque responden dos preguntas distintas: «¿cómo hace AWS que el contenido generado sea identificable?» (la marca de agua, un control de transparencia) y «¿cuánta personalización admite la API?» (5 imágenes, no 50). Empareja cualquiera de las dos con la Responsible AI Lens de la sección 11 cuando una pregunta pida un artefacto de transparencia.

8.4 Actualizaciones de 2025 to 2026

La tabla de modalidades de 8.1 es la línea base de la guía del examen; el roster detrás de ella se movió dos veces dentro de la ventana que AWS verificó para esta lección. Todo lo de abajo procede de AWS What's New, la guía del usuario de Amazon Bedrock y la propia cobertura de re:Invent 2025 de AWS: solo funciones y fechas publicadas por el propio AWS.

Guardrails creció junto al roster de modelos: AWS ahora documenta salvaguardas de código, un ApplyGuardrail API independiente, filtra un prompt para cualquier modelo sin invocar un FM, y salvaguardas entre cuentas que aplican un guardrail en toda una AWS Organization. El juego de seis políticas y las afirmaciones publicadas (88% de bloqueo de contenido dañino, 99% de precisión de Automated Reasoning) no cambian, así que la sección 11 todavía responde cada pregunta de política; lo que cambió es dónde pueden aplicarse esas políticas.

• 📚 ¿Sabías que…? La guía v1.1 convirtió los precios por token en un objetivo explícito (2.1.4): el examen ahora espera que razones sobre cómo los recuentos de tokens y los cambios de precios moldean el coste y el rendimiento, que es exactamente la aritmética ya practicada en las secciones 2, 5 y 7. AWS afirma que los cambios de la guía aparecen en el examen aproximadamente un mes después de su publicación, así que todo lo que añadió la v1.1 está activo: el formato sigue sin cambios en 65 preguntas (50 puntuadas + 15 sin puntuar), 90 minutos, 700/1000 para aprobar.

---

9. El espectro de personalización: prompt primero, modelo a medida al final

9.1 La escalera que publica AWS

El propio resumen de AWS: la mayoría de las cargas de trabajo nunca pasan del paso 3. Esa frase vale más en el examen que cualquier técnica individual, porque convierte «¿qué personalización debo usar?» en «¿cuál es el peldaño más barato que arregla el problema?», y cada peldaño más barato que te saltes es coste y latencia que pagas por nada.

9.2 El vocabulario de fine-tuning de la Tarea 3.3

9.3 Fine-tuning por refuerzo y destilación: las cifras

El fine-tuning por refuerzo (RFT) usa funciones de recompensa, una función Lambda de AWS que implementa verificación basada en reglas (RLVR), o un modelo como juez (RLAIF), con el método de optimización GRPO. AWS afirma hasta un 66% de mejora de precisión. Guardrails sobre la propia función: mínimo 100 registros, máximo 20.000 prompts para los modelos Nova, y el propio consejo de AWS de omitir el RFT cuando la recompensa base ya supera el 95%.

Model Distillation (GA en mayo de 2025) entrena un estudiante más pequeño sobre las salidas del profesor. AWS afirma que el estudiante puede ser hasta un 500% más rápido, un 75% más barato, con menos del 2% de pérdida de precisión.

9.4 Ejemplo resuelto 8: ¿debería este equipo hacer fine-tuning?

Un equipo de soporte quiere que su asistente adopte el estilo corporativo de la empresa. Recompensa de evaluación base en su conjunto de prompts reservado: 91%.

1. La base 91% < 95%, así que el RFT está técnicamente disponible, pero necesita ≥ 100 registros etiquetados y añade entrenamiento y mantenimiento de la función de recompensa.
2. La escalera de AWS dice intentar primero los pasos 1 to 3: prompt engineering (reglas de estilo corporativo en el prompt del sistema) y RAG (la base de conocimiento de respuestas pasadas).
3. Si el estilo todavía falla después de los pasos 1 to 3, el fine-tuning (paso 6) es el peldaño correcto, y el equipo necesita un conjunto de datos etiquetado, no más ajustes de temperatura.

Respuesta: no empieces en el paso 6. Si la recompensa base alguna vez alcanza por encima del 95%, AWS dice explícitamente que omitas el RFT por completo.

• 📚 ¿Sabías que…? El espectro de personalización es la respuesta directa a la forma recurrente del examen de «el equipo quiere hacer fine-tuning, ¿qué deberían hacer primero?», y el 66% de mejora de precisión de RFT, el 500% más rápido / 75% más barato / <2% de pérdida de precisión de la destilación y el «la mayoría de las cargas de trabajo nunca pasan del paso 3» de AWS son todas afirmaciones de AWS reproducidas tal como se publican. Úsalas como direcciones (la destilación es más barata, el RFT puede ayudar en tareas difíciles, el prompting y el RAG van primero) y no como promesas que tu arquitectura deba cumplir.

---

10. Evaluar la IA generativa

10.1 Tres familias de evaluación en Amazon Bedrock Model Evaluation

Los conjuntos de datos integrados incluyen Real Toxicity, BOLD, TREX, WikiText-2, Gigaword, BoolQ, Natural Questions y TriviaQA.

10.2 Las reglas del juez que aparecen literalmente como respuestas

• AWS afirma que LLM-as-a-judge entrega hasta un 98% de ahorro de costes frente a la revisión humana.
• Mejor práctica: usa un modelo evaluador de una familia distinta a la del generador: un juez de la misma familia hereda los mismos puntos ciegos.
• Fidelidad es la métrica de alucinación: ¿la respuesta se queda dentro del contexto recuperado?
• La revisión humana no se reemplaza; se capa: métricas de juez para la escala, workflows humanos para el visto bueno.

10.3 Las métricas clásicas de generación de texto de la Tarea 3.4

10.4 Métricas específicas de RAG

La triada de RAG es relevancia contextual, fidelidad y relevancia de la respuesta; AWS añadió precisión de citas y cobertura de citas en 2025, ambas puntuadas 0 to 1 (la cobertura no aplica cuando la respuesta es totalmente infiel). El caso publicado de AWS: una mejor fragmentación elevó la relevancia contextual del 67% al 93% y eliminó alucinaciones sin cambiar el prompt: la evidencia más clara disponible de que en RAG, la calidad de la recuperación suele ser el error, y el prompt no.

10.5 Ejemplo resuelto 9: juez más humano, con precios

Un equipo debe evaluar 2.000 generaciones:

1. LLM-as-a-judge puntúa las 2.000 en corrección, completitud, fidelidad y seguridad: AWS afirma hasta un 98% de ahorro de costes frente a hacerlo a mano.
2. Revisión humana sobre una muestra del 10% de 200 tareas a los 0,21 USD por tarea completada documentados: 200 \times 0.21 = \42.00$.
3. El modelo juez procede de una familia distinta a la del generador, así que los modos de fallo compartidos no se cancelan.

Respuesta: juez a escala para la cobertura, humanos por 42,00 USD para una muestra de 200 tareas por autoridad: el patrón que AWS documenta, en lugar de evaluación solo con juez o solo con humanos.

---

11. Guardrails, mitigación de alucinaciones e IA responsable

11.1 Las seis políticas de Guardrails

AWS afirma: 88% de bloqueo de contenido dañino, 99% de precisión de validación de Automated Reasoning, y más del 75% de las respuestas alucinadas filtradas por las verificaciones de grounding.

11.2 Verificaciones de Automated Reasoning: los límites que vale la pena memorizar

11.3 La escalera de mitigación de alucinaciones: en el orden de AWS

AWS documenta exactamente tres rutas, en esta secuencia:

1. Refina u optimiza el prompt: la más barata, sin infraestructura.
2. Usa RAG para suministrar datos relevantes: ancla la respuesta en tus documentos.
3. Prueba un modelo distinto: algunos modelos alucinan menos en tu carga de trabajo.

Después, encima de la escalera, las verificaciones de grounding contextual en Guardrails detectan respuestas que no están soportadas por la fuente (AWS afirma >75% filtradas).

11.4 Ejemplo resuelto 10: ¿cuánto te deja realmente un filtrado del 75%?

Un chatbot de producción emite 1.000 respuestas al día, y el equipo activa solo las verificaciones de grounding contextual:

$$1{,}000 \times (1 - 0.75) = 250$$

Respuesta: aproximadamente 250 respuestas sin anclar pasan todavía por cada 1.000 cuando las verificaciones de grounding son el único control, y por eso AWS apila controles: filtros de contenido al 88%, Automated Reasoning al 99% en violaciones de política, trabajos de evaluación antes de la publicación, y revisión humana para los casos que quedan. Ningún porcentaje de esta sección sustituye a la pila.

11.5 Las dimensiones de IA responsable y sus artefactos

AWS evalúa los sistemas de IA generativa en ocho dimensiones, equidad, explicabilidad, veracidad/robustez, gobernanza, transparencia, privacidad y seguridad, seguridad (safety) y controlabilidad, que están codificadas en la Responsible AI Lens de AWS Well-Architected. El artefacto de transparencia que AWS publica para sus propios servicios es la AI Service Card, y el vocabulario de esa misma lente es lo que cita un ítem de «¿de qué dimensión trata esto?».

• 📚 ¿Sabías que…? Los porcentajes de guardrail publicados por AWS (88% / 99% / >75%), el 66% de mejora de RFT, el 98% de ahorro de LLM-as-a-judge, la afirmación de destilación del 500% más rápido / 75% más barato y el caso de fragmentación del 67% → 93% son todas afirmaciones de AWS con sus propias metodologías: se reproducen aquí tal como las publica AWS. En el examen, funcionan como pistas de ordenación (qué control es más fuerte, qué paso viene primero), y no como garantías; trata cualquier opción que convierta una afirmación en un absoluto como sospechosa.

---

12. Veredicto comparativo

---

13. Trampas de examen para esta lección

---

14. Casos Reales

Todo hasta aquí es mecanismo, cómo se comportan los tokens, la recuperación, los parámetros de inferencia y Guardrails. Esta sección es evidencia: despliegues de IA generativa publicados por AWS, cada uno con los servicios usados, las cifras que AWS y el cliente imprimieron, y la fuente. Léelos como ejemplos de patrón para el Dominio 3 (Aplicaciones de modelos fundacionales, 28%): el examen rara vez pide el nombre de una empresa, pero pregunta constantemente qué forma de arquitectura entrega qué resultado, y estas son las formas que el propio AWS publica.

14.1 Seis despliegues de IA generativa, con servicios y cifras

14.2 Los tres casos de los que el examen va a tomar prestado

Sun Finance: el OCR y el razonamiento son trabajos separados. El primer prototipo enviaba fotos de identificación directamente a un LLM y fue rechazado con un 61,8% en total (43% en los números de identificación); AWS atribuye el fallo a protecciones de privacidad que bloquean la extracción directa de PII. Separar las preocupaciones: Textract lee, Claude estructura, las reglas validan: produjo 85% en el segundo intento y 90,80% en el pipeline publicado, con −91% de coste por documento y 20 horas → menos de 5 segundos por caso. Eso es la escalera de mitigación de la sección 11 aplicada antes de tocar los parámetros: arregla el pipeline, no la temperatura.

Nippon India: la recuperación gana al ajuste de parámetros. El RAG ingenuo se degradaba a medida que crecía el volumen de documentos y producía alucinaciones, así que el equipo hizo ingeniería de recuperación: FM como parser, reformulación de consultas, RAG multi-consulta, modelos reranker, GraphRAG, filtrado por metadatos, y añadió Bedrock Guardrails y citas encima: +>95% de exactitud, −90 to 95% de alucinación, informes cayendo de 2 días a unos 10 minutos. AWS señala todo esto como funciones de producto GA, y no como código exclusivo del cliente. La lectura con forma de examen: cuando un asistente anclado alucina, la escalera sigue siendo prompt → RAG → modelo distinto, y la calidad de la recuperación suele ser el error (sección 10.4).

Adobe: la fragmentación es un hiperparámetro medible. Se hicieron benchmark de cuatro estrategias de fragmentación en el propio conjunto de prueba de Adobe; fragmentos de 400 tokens con 20% de solapamiento fueron a la vez los más simples y los más precisos, dando +20% de exactitud de recuperación sobre la búsqueda existente al insertarlos con Titan Text Embeddings V2 en Amazon OpenSearch Service. Es la confirmación en vivo de la sección 2.1: la calidad de la fragmentación, no la redacción del prompt, es la palanca más grande de un sistema RAG.

14.3 Antes y después: las cifras que vale la pena llevarse al examen

• 📚 ¿Sabías que…? Los fallos documentados son la parte con más forma de examen de estos casos: la extracción solo con LLM de Sun Finance (61,8%), el primer intento de Prime Focus Technologies con APIs de LLM externos cuya latencia era demasiado alta para etiquetado en vivo, y los 4 meses de visión por computadora interna de Chronomics que nunca alcanzaron el objetivo antes de que Rekognition Custom Labels se entregara en 3 to 4 semanas con un 96,5% de exactitud / 97,9% F1. Los tres reescriben la sección 12 en forma de producción: elige el nivel deliberadamente (prefabricado → personalizado gestionado → generativo), y evalúa antes de lanzar: Epilot eligió su modelo con Bedrock Evaluations y no en un notebook.

---

Preguntas de Práctica (Practice Questions)

---