Fundamentos de Amazon Bedrock: APIs, acceso a modelos, precios, tipos de inferencia y evaluaciones

Amazon Bedrock es el servicio que el examen AIF-C01 nombra más que ningún otro, y también es el servicio que más rápido cambia. Esa combinación es peligrosa: memorizar una lista de modelos o un precio por token es una estrategia de estudio con caducidad de semanas, mientras que memorizar mecanismos, cómo se comportan de verdad bajo demanda, batch, Provisioned Throughput, los niveles de servicio y los perfiles de inferencia entre Regiones, sigue siendo correcto durante años. Esta lección está construida alrededor de esa división. Cada cifra de abajo está anclada a una fuente AWS de primera parte en octubre de 2026, y todo lo que AWS no confirma se marca en lugar de enseñarse.

Al final de esta lección podrás:

• explicar qué significa operativamente «totalmente gestionado, serverless, API única» y nombrar los dos endpoints de Bedrock;
• enunciar las reglas de acceso a modelos de 2026, incluido el formulario de Anthropic que la mayoría de los candidatos olvida;
• elegir entre bajo demanda, batch y Provisioned Throughput, y entre los cuatro niveles de servicio, usando precio, latencia, compromiso y compatibilidad de funciones;
• elegir el perfil de inferencia adecuado para coste frente a residencia de datos y predecir qué registrará CloudTrail;
• recorrer un árbol de decisión de selección de modelo y defender una elección con precios por token verificados;
• nombrar las cuatro rutas de personalización y decir cuál requiere Provisioned Throughput;
• seleccionar evaluación automática, humana o LLM-as-a-judge para una métrica dada;
• defender el veredicto comparativo entre Bedrock, SageMaker autogestionado, un servicio de IA prefabricado y construirlo tú mismo.

---

1. Qué es Amazon Bedrock

1.1 La definición que usa AWS

Amazon Bedrock es un servicio totalmente gestionado y serverless que te da una única API para invocar modelos fundacionales de muchos proveedores. Tres palabras cargan toda la propuesta de valor:

• Totalmente gestionado: AWS ejecuta la infraestructura, el escalado y el alojamiento del modelo; nunca ves una instancia, una URL de endpoint ni una GPU.
• Serverless: pagas por token (bajo demanda y batch) o por hora (Provisioned Throughput); no hay factura de capacidad ociosa salvo que la compres deliberadamente.
• API única: una forma de petición, un SDK, un conjunto de acciones de IAM; cambiar de Anthropic Claude a Amazon Nova es un cambio de modelId, no una reescritura.

Esa última propiedad es la frase más examinable de esta lección. Una pregunta que dice «sin reescribir la lógica de la aplicación» apunta a la API unificada, y cada otra opción de esa pregunta (enrutamiento entre Regiones, Provisioned Throughput, importación de modelos) es un mecanismo completamente distinto.

1.2 El catálogo de proveedores

AWS lista más de 100 modelos fundacionales sin publicar un recuento exacto. La lista de proveedores de primera parte verificada en octubre de 2026 es:

📚 ¿Sabías que…? DeepSeek es compatible oficialmente: DeepSeek V3.2, V3.1 y R1 aparecen todos en la página Models at a glance de AWS, y V3.2 funciona tanto en bedrock-runtime como en el endpoint compatible con OpenAI bedrock-mantle. Los candidatos que se saltan el catálogo actual suelen asumir que DeepSeek solo está disponible a través de un marketplace o de una pila autogestionada; en el examen, «Amazon Bedrock no aloja DeepSeek» es un distractor por construcción.

1.3 Los dos endpoints

Bedrock expone dos endpoints de servicio, y el examen prueba qué operaciones viven en cada uno:

La distinción importa en la práctica: bedrock-mantle existe para que una aplicación escrita para el SDK de OpenAI o Anthropic pueda apuntar a Bedrock con un cambio de URL base y de clave, mientras que bedrock-runtime es el hogar de Converse: la API que te da herramientas, Guardrails y paridad multiproveedor en una sola forma de petición.

1.4 Arquitectura: una API, muchos modelos

1.5 Qué promete AWS sobre tus datos

Dos compromisos aparecen en la visión general de la documentación de Bedrock y ambos tienen forma de examen:

1. Las entradas y salidas no se comparten con proveedores de modelos de terceros.
2. Las entradas y salidas no se usan para entrenar los modelos fundacionales base. El fine-tuning, en cambio, entrena una copia privada del modelo que pertenece a tu cuenta: que es la razón por la que un modelo personalizado es tuyo y por la que se factura de forma distinta.

📚 ¿Sabías que…? La garantía de «no se usa para entrenar los modelos base» es precisamente la razón por la que el fine-tuning se describe como la creación de un modelo personalizado privado: tu JSONL etiquetado va a S3, un job de entrenamiento produce un checkpoint que solo tu cuenta puede invocar, y el FM base que usan otros clientes no se toca. El hecho complementario que los candidatos pierden es que invocar un modelo fine-tuneado supervisadamente requiere Provisioned Throughput, bajo demanda no lo ejecutará, mientras que Custom Model Import (trae tus propios pesos) sí puede ejecutarse bajo demanda.

1.6 Cuatro cosas que Bedrock no es

Confusiones que producen opciones equivocadas más a menudo que cualquier otro hecho sobre Bedrock:

---

2. Acceso a modelos: qué desbloquea de verdad una invocación

El acceso a modelos solía ser un opt-in con clic por modelo. En 2026 el flujo es más simple, con una excepción que todavía tropieza a los candidatos:

Después del paso 4, InvokeModel/Converse tienen éxito; antes, obtienes un error de acceso que parece un problema de IAM y no lo es.

---

3. La superficie de la API: Invoke, Converse y los endpoints de compatibilidad

3.1 Familias de operaciones

3.2 Parámetros de inferencia de Converse: exactamente cuatro

La InferenceConfiguration base de la API Converse contiene cuatro parámetros y nada más:

Los ajustes específicos del modelo (por ejemplo topK o el presupuesto thinking de un proveedor) van a additionalModelRequestFields, que se pasa al modelo. Una opción que afirma que Converse expone cinco o seis parámetros base de primera clase está probando si conoces el límite entre la API portable y el escape hatch específico del proveedor.

3.3 Streaming

El streaming usa InvokeModelWithResponseStream (familia Invoke) o ConverseStream (familia Converse), con la acción IAM bedrock:InvokeModelWithResponseStream. Si un modelo dado puede hacer streaming es comprobable por programa: GetFoundationModel devuelve responseStreamingSupported. Si una pregunta pregunta «¿cómo confirmas la compatibilidad con streaming antes de prometerlo en la UI?», esa bandera es la respuesta.

3.4 Uso de herramientas y elección forzada de herramienta

toolChoice tiene exactamente tres valores:

Esa tercera fila es un micro-hecho clásico de examen: forzar una herramienta con nombre no es universal, y una opción que lo generaliza a todos los modelos de Bedrock es incorrecta.

3.5 Salida estructurada

Existen dos rutas para JSON conforme al esquema:

1. Uso forzado de herramientas (toolChoice: {any: {}} o {tool: {name:...}}): la ruta histórica, porque constreñir el modelo al esquema JSON de una herramienta es estructural en lugar de advisory.
2. Salida estructurada nativa: añadida a Converse/ConverseStream el 2026-02-04 mediante outputConfig.textFormat.type = "json_schema" junto con toolSpec.strict.

La brecha de fiabilidad es grande y publicada por AWS: una prueba de la comunidad con 102 muestras en AWS Builder Center encontró que el JSON solo con prompt («devuelve JSON válido») tenía éxito aproximadamente el 70 to 80% de las veces frente al 99%+ con uso forzado de herramientas. Convierte eso en una cifra operativa: 10.000 documentos de factura con un 70% de éxito solo con prompt significan unos 2.500 análisis y reintentos fallidos; al 99% significan unos 100.

Ejemplo resuelto 1, elegir el mecanismo correcto para 10.000 extracciones estructuradas. El trabajo necesita JSON estricto, sin interactividad y resultados para la mañana. Respuesta: Converse bajo demanda o en nivel Flex con outputConfig.textFormat.type = "json_schema", porque la inferencia por lotes no admite salida estructurada ni tool calling, y tampoco admite modelos provisionados. Dos trampas separadas, una pregunta.

📚 ¿Sabías que…? La instrucción de JSON solo con prompt falla por una razón estructural: el modelo está muestreando, no validando. Pedirlo cortésmente en el system prompt cambia la probabilidad de que aparezcan llaves; no crea una restricción. El uso forzado de herramientas y la salida json_schema funcionan ambos porque hacen que la salida inválida sea imposible por construcción más que improbable: que es también la razón por la que la propia guía de fiabilidad de AWS trata el «solo di JSON en el prompt» como una respuesta distractor en toda pregunta de salida estructurada.

3.6 Anatomía de la petición: dónde vive cada ajuste

Dos lecturas de esta carga importan en el examen: la superficie portable (system, messages, inferenceConfig, toolConfig, guardrailIdentifier) es la misma para cada proveedor, que es lo que convierte un cambio de proveedor en un cambio de una línea; y additionalModelRequestFields es el escape hatch deliberado para todo lo específico del proveedor, que es la razón por la que la lista de parámetros base se queda en cuatro sin importar cuántos ajustes exponga un modelo dado.

---

4. Precios: cuatro mecanismos y cuatro niveles de servicio

Los precios de Bedrock no son un modelo: son un par ortogonal de elecciones: cómo compras capacidad (bajo demanda / batch / provisionado) y qué nivel de servicio aceptas (priority / standard / flex / reserved).

4.1 Los tres mecanismos de capacidad

4.2 Los cuatro niveles de servicio (el segundo eje)

serviceTier se fija por petición y aplica al tráfico bajo demanda:

Las condiciones de entrada del nivel Reserved publicadas por AWS (fuente secundaria: AWS Builder Center) son ≥ 100K tokens de entrada por minuto y ≥ 10K tokens de salida por minuto, un compromiso de 1 o 3 meses, 99,5% de tiempo activo con desbordamiento a Standard.

4.3 Ejemplo resuelto 2: aritmética pura bajo demanda

El propio ejemplo de AWS: Amazon Titan Text Lite a $0.0003 por 1K tokens de entrada y $0.0004 por 1K tokens de salida.

$$\frac{2{,}000}{1{,}000}\times \$0.0003 + \frac{1{,}000}{1{,}000}\times \$0.0004 = \$0.001 \text{ per call}$$

Con 1.000 llamadas por hora eso son $1.00 por hora. El segundo ejemplo de AWS, AI21 Jurassic-2 Mid a $0.0125 por 1K tokens en ambos sentidos, para 10.000 de entrada / 2.000 de salida:

$$\frac{10{,}000}{1{,}000}\times \$0.0125 + \frac{2{,}000}{1{,}000}\times \$0.0125 = \$0.15 \text{ per request}$$

4.4 Ejemplo resuelto 3: batch ahorra exactamente el 50%

Claude 3.5 Sonnet (Public Extended Access): $6.00 entrada / $30.00 salida por 1M de tokens bajo demanda, $3.00 / $15.00 en batch. Un job de 10M de entrada + 2M de salida:

La entrega es normalmente dentro de 24 horas, y el job no puede usar tool calling ni salida estructurada.

4.5 Ejemplo resuelto 4: Provisioned Throughput arde uses o no uses la capacidad

La aritmética documentada de AWS para una modelo unit a $16.20/hora:

$$1 \times \$16.20 \times 24 \text{ h} \times 31 \text{ d} = \$12{,}052.80 \text{ per month}$$

Tarifas horarias publicadas para Cohere Command por modelo unit: $49.50 (sin compromiso), $39.60 (1 mes, −20%), $23.77 (6 meses, −52%). Llama 2 13B/70B provisionado: $21.18 (1 mes) y $13.08 (6 meses). La regla de decisión: el provisionado solo gana cuando el coste de las horas ociosas es menor que la capacidad y el ahorro por token que realmente capturas: para Claude, Nova y la mayoría de los modelos modernos AWS no publica tarifas horarias para nada y te pide contactar con el equipo de cuenta.

4.6 Ejemplo resuelto 5: aritmética de niveles de servicio

DeepSeek V3.1 en ap-southeast-2 tiene un precio de $0.5974 entrada / $1.7304 salida por 1M de tokens en el nivel Standard. Aplicando los modificadores documentados:

Envía 10% del tráfico a Priority, 60% a Flex y 30% a Standard y la mezcla es 0.10 \times 4.07 + 0.60 \times 1.16 + 0.30 \times 2.33 \approx \1.80$: unos **23$2.33. La disciplina de niveles, no la elección del modelo, es normalmente la optimización más barata disponible.

4.7 Precios de tokens verificados (USD por 1M, Standard / bajo demanda)

Precios fijos y horarios que vale la pena conocer: almacenamiento de modelos personalizados $1.95/mes, Titan Text Embeddings V2 $0.00002 por 1K tokens, Cohere Embeddings $0.0001 por 1K tokens (una brecha de 5× en el mismo trabajo).

4.8 Dos palancas de ahorro más: enrutamiento y caché

Intelligent Prompt Routing opera dentro de una familia de modelos, Claude Sonnet ↔ Claude Haiku, Nova Pro ↔ Nova Lite, y la página de precios de AWS afirma que puede reducir el coste en hasta un 30%. La aritmética detrás de la afirmación es simple: envía los prompts fáciles al hermano barato y conserva los prompts difíciles en el modelo fuerte.

Ejemplo resuelto 10: aritmética de enrutamiento. Usa un ancla verificada: Claude 3.5 Sonnet a $6.00 / $30.00 por 1M de tokens. La tarifa por token del hermano no está publicada en las fuentes verificadas para esta lección, así que asume un modelo clase Haiku a $1.00 / $5.00 (ilustrativo) y una mezcla diaria de 10M entrada / 2M salida:

Se siguen dos lecturas. Primero, la afirmación publicada por AWS es «hasta un 30%», que es la cifra conservadora en tráfico real: nunca cites el 42% ilustrativo como una cifra de AWS. Segundo, el enrutamiento es una palanca de mezcla de tráfico más que un descuento por petición, que es exactamente lo que lo separa de batch (−50% en cada token), del nivel Flex (−50% en cada token) y de un perfil global (−10% en cada token).

Prompt caching (Amazon Nova) es la otra palanca, y sus límites son precisos: un mínimo de 1.000 tokens por checkpoint, como máximo 4 checkpoints por petición, un time to live de 5 minutos y un tope de caché de 20.000 tokens. Los tokens de entrada en caché se facturan a la tarifa de lectura de caché: para Claude 3.5 Sonnet eso es $0.60 por 1M frente a $6.00 sin caché (una reducción de 10×), mientras que una escritura de caché cuesta $7.50 por 1M (una prima del 25%). El caching por tanto solo compensa cuando un checkpoint se lee repetidamente dentro de su TTL.

Haz corresponder cada mecanismo de precios con su regla documentada:

---

5. Inferencia entre Regiones: perfiles, precio y residencia

5.1 Perfiles geográficos frente a globales

La inferencia entre Regiones se expresa mediante perfiles de inferencia, y hay dos tipos:

5.2 Qué muestra CloudTrail

Las peticiones entre Regiones pueden enrutar a Regiones que no están habilitadas manualmente en tu cuenta; los datos permanecen en la red de AWS y se cifran en tránsito. AWS CloudTrail registra dónde ocurrió realmente el trabajo en additionalEventData.inferenceRegion: que es exactamente la razón por la que una entrada de CloudTrail puede mostrar una Región distinta de la Región de origen de la petición sin implicar un error de facturación. El precio siempre usa la Región de origen, así que no hay recargo de enrutamiento.

5.3 Dos límites que los candidatos pierden

1. Los perfiles de inferencia no admiten Provisioned Throughput. La capacidad reservada por modelo unit y el enrutamiento entre Regiones son mecanismos separados; no puedes combinarlos.
2. Los perfiles de aplicación existen para el etiquetado de asignación de costes: un concepto distinto de los perfiles de enrutamiento, usado para atribuir gasto en lugar de situar cómputo.

Ejemplo resuelto 6: economía entre Regiones. Un perfil geográfico como us.amazon.nova-lite-v1:0 mantiene el procesamiento dentro de Estados Unidos a tarifas estándar. Un perfil global es aproximadamente 10% más barato pero puede ejecutarse en cualquier Región comercial. Para una carga de trabajo financiera de la UE la elección la decide la residencia, no el precio: elige el perfil geográfico (EU) y acepta la tarifa más alta.

📚 ¿Sabías que…? El descuento del ~10% del perfil global y la regla del «precio desde la Región de origen» apuntan en direcciones opuestas y ambas son ciertas: tu factura se calcula con la lista de precios de tu Región de origen, pero las tarifas del pool global se publican aproximadamente un 10% más bajas, de modo que enrutar globalmente ahorra dinero sin una línea de recargo. Mientras tanto Intelligent Prompt Routing, una función completamente distinta, puede reducir el coste en hasta un 30% al enrutar dentro de una familia de modelos (Claude Sonnet ↔ Claude Haiku, Nova Pro ↔ Nova Lite). Tres palancas de ahorro separadas, tres mecanismos distintos: batch (−50%), nivel Flex (−50%), perfil global (−10%), enrutamiento de prompts (hasta −30%).

---

6. Elegir un modelo: el árbol de decisión que AWS realmente enseña

6.1 El árbol de decisión

6.2 Matriz verificada de proveedor × modelo

6.3 Ejemplo resuelto 7: mismo trabajo, 5× de coste de embeddings

Un blog de AWS calculó una ingesta RAG de un documento de 5M de tokens más 0,5M de tokens de consulta = 5,5M de tokens:

Mismo corpus, mismo trabajo, una diferencia de 5×: que es la razón por la que la elección del modelo de embeddings, y no solo la del LLM, pertenece a una pregunta de coste.

Novedades de 2025 to 2026

Las secciones 6.1 to 6.3 enseñan un proceso de decisión que sobrevive a la rotación del catálogo; este subapartado registra qué rotó realmente entre finales de 2025 y octubre de 2026, para que una lista de modelos caducada nunca se convierta en una respuesta incorrecta. Cada fila de abajo está verificada contra una publicación What's New de AWS, una página de documentación de AWS, la página de precios de Bedrock o un blog de AWS: nada aquí viene de un rastreador de terceros.

Cambios de catálogo (verificados):

Cambios de capacidad (verificados):

Lo que no cambió: cada mecanismo de esta lección se comporta como está escrito: la API Converse única y sus cuatro parámetros base, batch al 50% sin tool calling y sin salida estructurada, Provisioned Throughput facturado por hora por modelo unit, la escalera de niveles +75% / default / −50% con plazo de 1 o 3 meses, los perfiles geográficos para residencia frente a los perfiles globales a ~10%, y los tres modos de evaluación sobre un dataset en S3. El catálogo es la parte que se mueve; la mecánica es la parte en la que se te examina.

📚 ¿Sabías que…? La política de ciclo de vida convierte el consejo de esta lección de «no memorices la lista de modelos» en una regla de facturación: porque un modelo Legacy rechaza los pedidos nuevos de Provisioned Throughput, un equipo que fije capacidad a un modelo el día antes de que salga de Active puede quedar bloqueado exactamente de la sección de compromiso que el 4.5 dice que necesitan los cargas fine-tuneados y de estado estable: mientras sus unidades de modelo existentes siguen funcionando. Por eso una opción de examen que nombre un modelo concreto como «disponible» o «no disponible» es casi siempre un distractor, y por eso las respuestas duraderas son mecanismos: acceso activado por defecto, permisos de Marketplace en el primer habilitamiento, el formulario Anthropic FTU, un método de pago válido.

---

7. Personalización: cuatro caminos y la regla del Provisioned Throughput

Ejemplo resuelto 8: coste del fine-tuning, el propio ejemplo de imagen de AWS. Amazon Titan Image Generator a $0.005 por imagen, 500 pasos, tamaño de lote 64:

$$\$0.005 \times 500 \times 64 = \$160.00$$

más $1,95/mes de almacenamiento del modelo personalizado y 1 hora de inferencia personalizada a $21.00 suman $182.95 en el primer mes.

7.1 Caché de prompts (Amazon Nova)

---

8. Evaluaciones: tres modos, una ubicación de dataset

8.1 Los tres modos

Tipos de tarea automáticos: generación general, resumen, preguntas y respuestas, clasificación de texto. Modelos juez disponibles: Nova Pro / 2 Lite / Micro / Premier, Claude 3.5 Sonnet v1/v2, Claude Opus 4.7/4.8, Claude Sonnet 4.0/4.5, Llama 3.1 70B, Mistral Large.

LLM-as-a-judge alcanzó GA el 2025-03-20 y AWS afirma hasta un 98% de ahorro de costes con resultados en horas en lugar de semanas. También ofrece respuestas de inferencia traídas por ti (bring-your-own), de modo que puedes puntuar salidas de modelos que ni siquiera están alojados en Bedrock.

8.2 Ejemplo resuelto 9: qué evaluación, qué métrica

📚 ¿Sabías que…? La función de respuestas de inferencia traídas por ti de LLM-as-a-judge convierte en silencio las Evaluaciones de Bedrock en una capa de calidad multiplataforma: envías producidas por cualquier modelo, incluidos los que se ejecutan fuera de AWS, y un juez de Bedrock los puntúa con una explicación y un histograma de puntuaciones escrito en S3. Por eso «la evaluación debe ejecutarse en el mismo proveedor que el modelo evaluado» es un distractor: AWS construyó explícitamente lo contrario.

---

9. Veredicto comparativo

---

10. Trampas de examen para esta lección

---

MDEOF wc -l content/courses/aws-aif-c01/es/09-bedrock-foundations.md

Casos Reales

Las secciones 1 to 10 construyen los mecanismos; las historias de clientes publicadas por AWS muestran a qué mecanismo recurrió realmente un equipo real, y con qué cifras. Todo lo siguiente se cita del caso de estudio de AWS o de la publicación del AWS Machine Learning Blog nombrados en la columna Fuente, consultados el 6 de octubre de 2026. Todas estas cifras son afirmaciones del cliente o de AWS y no están auditadas, y cuando una fuente dice «hasta», léelo como un techo, no como una expectativa.

Casos de un vistazo: servicios, cifras, fuentes

Expediente de caso 1: Epilot: elige el modelo con Bedrock Evaluations antes de producción. Software energético de Colonia que resume largas cadenas de correos de clientes para más de 170 empresas de servicios públicos. La cadena es API → Amazon SQS → AWS Lambda → Amazon Bedrock (Claude Sonnet), y el modelo se seleccionó con Amazon Bedrock Evaluations (valoraciones humanas entre versiones de prompt) y no por preferencia; un agente posterior escribe registros con verificación humana. Resultados: tiempo de manejo −87%, 55.000 resúmenes al mes con una tasa de fallo despreciable, 80% de usuarios diciendo que simplifica su trabajo, un MVP en 2 meses y los datos procesados mantenidos en una Región de la UE. Ángulo de examen: aquí los modos de evaluación de la §8 se usan como verdugo/gate, y la pregunta de residencia de la §5 se responde por adelantado en lugar de tras el lanzamiento. Fuente: aws.amazon.com/solutions/case-studies/epilot-genai-case-study (indexado en julio de 2026).

Expediente de caso 2, Bynder: los embeddings son una característica de producto, no solo una línea de coste. Bynder gestiona 175 millones de activos / 18 petabytes para 4.000 empresas, y la búsqueda por texto no puede expresar «encuéntrame más como este». Las imágenes y las consultas se vectorizan con Amazon Titan Multimodal Embeddings en Bedrock para búsqueda visual y contextual por similitud. Resultados: tiempo de búsqueda −75% y aproximadamente +50% de resultados utilizables por búsqueda. Ángulo de examen: la aritmética de embeddings de la §6.3 usa la misma tabla de precios que hace que Titan Text Embeddings V2 sea 5× más barato que los embeddings de Cohere, y los embeddings multimodales añaden un eje de búsqueda visual que un modelo de embeddings solo texto ni siquiera puede precificar. Fuente: aws.amazon.com/solutions/case-studies/bynder-bedrock-case-study (2025).

Expediente de caso 3, Nippon India: la mejora vino de la ingeniería de recuperación, no de un modelo más grande. El RAG ingenuo se degradaba a medida que crecía el volumen de documentos y producía alucinaciones. La solución: interpretación con FM como parser, reformulación de consultas, RAG multi-consulta, modelos reranker, GraphRAG y filtrado por metadatos en Bedrock Knowledge Bases, más Bedrock Guardrails y citas. Resultados: exactitud +>95%, alucinación −90 to 95%, generación de informes 2 días → ~10 minutos. Ángulo de examen: la evaluación RAG de la §8 existe precisamente para separar un fallo de recuperación de un fallo de generación, y AWS señala que cada técnica anterior es una característica GA de producto, no código exclusivo del cliente. Fuente: AWS Machine Learning Blog, 29 jul 2025, aws.amazon.com/blogs/machine-learning/how-nippon-india-mutual-fund-improved-the-accuracy-of-ai-assistant-responses-using-advanced-rag-methods-on-amazon-bedrock.

Expediente de caso 4: Adobe: el troceado y la elección de embeddings deciden la exactitud del RAG. Miles de desarrolladores obtenían resultados de búsqueda documental débiles. Adobe comparó cuatro estrategias de troceado en Bedrock Knowledge Bases: 400 tokens / 20% de solape, 1.000 tokens, jerárquico y semántico: con Amazon Titan Text Embeddings V2 escrito en Amazon OpenSearch Service y leído a través de la API Retrieve. Resultado: +20% de exactitud de recuperación en el propio conjunto de pruebas de Adobe, con la estrategia más simple (400 tokens / 20% de solape) como la más exacta. Ángulo de examen: una pregunta de base de conocimiento que ofrece «elegir un modelo más grande» está respondiendo el eje equivocado; el troceado, la elección de embeddings y la recuperación son los mandos, y la prueba se ejecuta en tu dataset. Fuente: AWS Machine Learning Blog, 11 jun 2025, aws.amazon.com/blogs/machine-learning/adobe-enhances-developer-productivity-using-amazon-bedrock-knowledge-bases.

Expediente de caso 5, Prime Focus Technologies: la latencia decidió la ubicación antes que el precio. CLEAR guarda 14 millones o más de activos (Disney Star, CBS, Lionsgate) y cubre localización más etiquetado de críquet en directo. Agentes de Amazon Bedrock + AWS Lambda automatizaron los flujos de trabajo; los resultados fueron coste de localización −20 to 30%, exactitud +20 to 30% y tiempo de respuesta −30 to 40%. La precaución documentada importa más que los porcentajes: el primer intento usó APIs externas de LLM cuya latencia era demasiado alta para el etiquetado en directo, y la latencia «cayó drásticamente» una vez la carga de trabajo se ejecutó en Bedrock en AWS. Ángulo de examen: las preguntas de enrutamiento de la §5 y el árbol de decisión de la §6 empiezan ambas con quién está esperando, la ubicación se resuelve antes de comparar precios. Fuente: aws.amazon.com/solutions/case-studies/prime-focus-case-study (2025).

Expediente de caso 6: Alnylam: las citas son la característica de cumplimiento. El triaje de quejas llevaba 3 to 4 días y encontrar una respuesta interna llevaba 15+ minutos. Con Amazon Bedrock, Amazon S3 y una capa RAG, el equipo lanzó un prototipo de ingesta y triaje en 3 meses bajo restricciones GxP, más el asistente de Slack AskALNY que sirve a 2.000 empleados + 1.000 contratistas y devuelve respuestas con enlaces a las fuentes. Resultados: triaje 3 to 4 días → horas, búsqueda 15 min → 30 s, y después 250+ casos de uso. Ángulo de examen: fundamentar y citar es exactamente el objetivo 5.1.5 de la guía del examen (detección de alucinaciones y grounding), y una respuesta regulada sin enlace a la fuente no es una respuesta. Fuente: aws.amazon.com/solutions/case-studies/alnylam-case-study (2025).

Antes y después, lado a lado

Reconstruye la arquitectura de Epilot y sus cifras publicadas:

📚 ¿Sabías que…? La única tasa de preparación para producción que publica AWS es 65%: de más de 1.000 implementaciones del Generative AI Innovation Center, 65% alcanzó producción en 2025, algunas en tan solo 45 días, usando el marco de las cinco V (Value → Visualize → Validate → Verify → Venture). Esa cifra es la razón por la que Epilot verificó la elección de su modelo con Bedrock Evaluations, por la que Sun Finance rechazó el intento 1 en lugar de desplegarlo, y por la que cada expediente anterior cita un «antes» junto al «después»: el otro 35% es lo que evitas al establecer la línea base de la métrica antes de construir.

---

Preguntas de Práctica (Practice Questions)

---