Le Quité el Volante a mi RAG: Managed KB vs. Chunking Manual

En abril publiqué un benchmark comparando 5 estrategias de chunking en Amazon Bedrock Knowledge Bases. La conclusión práctica fue simple: FIXED_SIZE con S3 Vectors como backend, y listo, a menos que tus datos justifiquen algo más complejo.

Tres meses después, AWS le quitó la pregunta al problema. Amazon Bedrock Managed Knowledge Base no te pide elegir estrategia de chunking. Smart Parsing decide el parsing por tipo de documento, AWS administra el vector store, y si tus preguntas son complejas, AgenticRetrieveStream planifica una estrategia de retrieval en vez de hacer una sola búsqueda por similitud.

Suena a que la discusión de abril quedó obsoleta. Así que hice la pregunta que me pareció honesta: ¿cuánto cuesta en calidad que te quiten el volante, y bajo qué condiciones se recupera esa pérdida?

No tenía una tesis antes de correr esto. La tengo ahora, y no es la que esperaba.

🎯 Spoiler: El retrieval gestionado simple prácticamente empata con mi configuración manual de abril. Lo que no funcionó es el planner agéntico —la pieza que justifica el “agentic” del nombre— con el modelo que AWS te da por defecto: no descompuso una sola consulta en 80 preguntas evaluadas.

En este artículo va la metodología completa: cinco configuraciones de retrieval sobre el mismo corpus, dos sets de preguntas —las 25 de un salto de abril sin tocar, y 15 nuevas multi-hop redactadas contra el texto real de los documentos—, tres planners distintos, y los 6 gotchas de infraestructura que hubo que resolver antes de poder medir nada. Porque el hallazgo del planner tiene una vuelta: depende enteramente de qué modelo planifica, y eso no lo supe hasta que dejé de usar el que viene por defecto.

📌 TL;DR — Datos clave antes de seguir leyendo

• Managed KB con Retrieve simple ≈ mi configuración manual de abril en Correctness (0.88 vs 0.84, diferencia dentro de lo esperable).
• Smart Parsing ingesta sin fallar los dos PDF que en abril reventaron SEMANTIC y NONE — y lo hace más rápido que mi pipeline manual (183s vs 407s). Incluso ingesta y recupera correctamente un PDF sin capa de texto extraíble.
• AgenticRetrieveStream con el planner por defecto (MANAGED) nunca generó una sola sub-query en 80/80 preguntas evaluadas, incluidas las que un retrieval simple demostrablemente no podía resolver.
• En preguntas multi-hop, eso hizo que el retriever “agéntico” quedara por debajo del retrieval simple (0.50 vs 0.567 de Correctness).
• Con planner CUSTOM pequeño (Claude Haiku 4.5), sí aparece descomposición real — pero en preguntas que ya no la necesitaban, no en las 5 que sí.
• Con planner CUSTOM grande (Claude Sonnet 4.6, el mismo modelo que mi generador), la Correctness en multi-hop saltó de 0.50 a 1.00, sostenido en dos corridas independientes — pero el planner y el generador comparten modelo en esa prueba, y lo digo explícito como salvedad, no como letra chica.
• El corpus no es byte-idéntico al de abril: mi bucket original fue destruido y tuve que re-descargar los documentos. Lo digo explícito, no lo escondo.

Por Qué Me Importa Esto

No es una curiosidad académica. Si estás evaluando si migrar un RAG de producción hacia Managed Knowledge Base, la pregunta real no es “¿es mejor?” — es “¿qué pierdo al dejar de controlar el chunking, y qué gano si dejo que el servicio también decida cuándo y cómo buscar más de una vez?”

Esa segunda parte es la que casi nadie mide. AWS presenta AgenticRetrieveStream con números de un benchmark académico (MuSiQue) que muestran mejoras de hasta +37 puntos de recall en preguntas de 4 saltos. Son números reales, publicados en su blog oficial sobre agentic retrieval, y los desgloso más abajo. Pero un benchmark académico no te dice qué pasa cuando el planner que obtienes por defecto, sin tocar ningún parámetro, se enfrenta a tu propio corpus.

Eso es lo que corrí.

El Diseño: Cinco Configuraciones, Dos Sets de Preguntas

Mantuve el generador (Claude Sonnet 4.6) y el juez (Nova Pro, cross-family) constantes en cuatro de las cinco configuraciones —la única excepción es D, donde genera el propio servicio— para aislar la capa de retrieval como única variable:

Las primeras cuatro corrieron juntas. La E la agregué un día después, como respuesta directa a lo que encontré con C — la cuento en detalle más abajo, en su propia sección, para no mezclar una corrida exploratoria con el diseño pre-registrado original.

Y dos sets de preguntas sobre el mismo corpus de 3 documentos técnicos (el Well-Architected Framework, el developer guide de AgentCore, y un blog post de RAG evaluation):

• Set 1-hop: las 25 preguntas originales de abril, de un solo salto. Sin tocar, por comparabilidad.
• Set multi-hop: 15 preguntas nuevas, multi-hop y comparativas, redactadas contra el texto real de los documentos, no contra resúmenes.

🔍 ProTip #1: Si vas a comparar un retriever “agéntico” contra uno simple, necesitas dos sets de preguntas, no uno. AWS mismo reporta que su ganancia en preguntas de un solo salto es menor a 5 puntos de recall. Correr solo preguntas de un salto contra un retriever que planifica es medir algo que se sabe de antemano que no va a mostrar diferencia — no es un benchmark, es una confirmación.

Un control de imparcialidad que me costó tiempo pero era innegociable: volví a correr la configuración A completa, no reutilicé los scores publicados en abril. Aquellos salieron del path nativo retrieveAndGenerate; B, C y D solo se pueden evaluar por el path bring your own inference responses (BYOI). Comparar scores producidos por dos mecanismos de evaluación distintos habría sido exactamente el tipo de trampa metodológica que le critico a otros benchmarks.

Primer Gotcha, Antes de Escribir una Línea de Código de Retrieval

Mi plan original era reutilizar la Knowledge Base de abril tal cual. No pude.

La KB de abril y su bucket de corpus ya no existían. No fue un descuido — los había destruido intencionalmente tras publicar el artículo, como hago con casi toda mi infraestructura de benchmark. Verificado contra la cuenta real antes de asumir nada: list-knowledge-bases devolvió cero resultados en cinco regiones, el bucket de S3 Vectors no tenía buckets, y el bucket del corpus daba NoSuchBucket.

Tuve que recrear solo el módulo FIXED_SIZE del repo de abril (Titan v2, 1024 dimensiones, 512 tokens de chunk, 20% de overlap) — sin los otros 4 módulos de chunking, que no hacían falta para este benchmark.

Y aquí viene la parte incómoda que sí hay que decir: el corpus no pudo ser byte-idéntico al de abril. La carpeta de datos estaba en .gitignore del repo original — nunca versioné el contenido real, así que no había hash ni manifest contra qué comparar. Verificado por HTTP HEAD:

El AgentCore developer guide prácticamente duplicó su tamaño en cuatro meses, lo cual tiene sentido — es el servicio que más ha evolucionado en ese periodo. Reporto esto como limitación explícita del re-run. No lo escondo, no lo minimizo, y tampoco creo que invalide la comparación: los documentos siguen siendo la misma clase de contenido (documentación técnica AWS densa), que es lo que el benchmark de abril necesitaba para ser representativo.

⚠️ ProTip #2: Si vas a publicar un benchmark que planeas revisitar meses después, versiona el corpus con un hash público (aunque no subas los archivos completos). Yo no lo hice en abril y me costó poder afirmar “byte-idéntico” con evidencia, no solo con intención.

Segundo Bloque de Gotchas: Crear y Consultar una Managed KB No Es Como Crear una Normal

Seis problemas de infraestructura reales, ninguno documentado junto en ningún lugar que haya encontrado.

1. Retrieve sobre una Managed KB rechaza vectorSearchConfiguration. Mi código de abril usaba ese parámetro sin problema contra la KB de S3 Vectors. Contra la Managed KB, el servicio respondió:

ValidationException: Incompatible configuration: vectorSearchConfiguration
is not supported for managed knowledge bases. Use managedSearchConfiguration
instead.

Mismo shape interno, distinta clave contenedora. Config A usa una, config B necesita la otra.

2. Crear el data source S3 con type=S3 falla en una Managed KB. El error:

ValidationException: Unsupported data source type for MANAGED knowledge
base type.

La forma correcta —que solo encontré contra un ejemplo real de AWS, no contra la documentación de referencia del shape— es type=MANAGED_KNOWLEDGE_BASE_CONNECTOR, con la configuración del conector anidada un nivel más adentro de lo intuitivo.

3. La creación es asíncrona de una forma que no esperaba. Con Terraform, la config A acepta CreateKnowledgeBase y CreateDataSource en secuencia sin esperar. Contra una Managed KB, llamar CreateDataSource mientras la KB sigue en CREATING falla con ConflictException. Hay que hacer polling hasta AVAILABLE antes de seguir — típicamente 2-5 minutos.

4. ragSourceIdentifier en el eval job no es una etiqueta libre. Intenté ponerle un nombre descriptivo ("D-setA") y el servicio lo rechazó: tiene que coincidir exactamente con el knowledgeBaseIdentifier que trae cada línea del dataset BYOI, o falla con ValidationException.

5. El esquema de salida del eval job es distinto al que está documentado para “automated MODEL evaluation”. Ese esquema documentado usa automatedEvaluationResult.scores en la raíz. El real, confirmado contra un output crudo en S3, es conversationTurns[].results[], con un JSONL único por job en una ruta que genera el servicio.

6. El juez a veces no puede extraer un score. Un ejemplo real, verificado contra el JSONL crudo: para la pregunta “Summarize the design principles of the Operational Excellence pillar” (config A, set 1-hop), Nova Pro respondió en lenguaje natural con una explicación perfectamente coherente, pero Builtin.Faithfulness quedó en result: null con el mensaje Unable to parse score from the LLM judge response. No es que el juez haya fallado en razonar — el servicio simplemente no pudo parsear un número de esa respuesta específica. Lo cuento y lo reporto en el conteo final, no lo promedio ocultándolo.

Figura 1: La respuesta del juez es coherente y lista los principios correctamente, pero el servicio no logró extraer un score numérico de ese texto. El error queda documentado en la propia consola.

Con eso resuelto, sí pude confirmar algo que rompió a mi favor: Smart Parsing ingesta sin quejarse los dos PDF que en abril reventaron SEMANTIC (límite de 1 MB) y NONE (límite de 50,000 caracteres). El job terminó en COMPLETE, 3 de 3 documentos indexados, 0 fallidos, en aproximadamente 183 segundos — más rápido que mi pipeline manual de FIXED_SIZE + S3 Vectors sobre el mismo corpus (~407 segundos).

Fui un paso más allá para estresar Smart Parsing de verdad: generé un PDF sintético de 2 páginas sin ninguna capa de texto extraíble —confirmé con pypdf que extract_text() devuelve cadena vacía en ambas páginas, solo contenido rasterizado a imagen— y lo agregué al corpus. El ingestion job terminó igual en COMPLETE, sin fallos ni documentos saltados. Y no se quedó en “lo aceptó de nombre”: un Retrieve directo con una query sobre el contenido de ese PDF devolvió el texto correcto como primer resultado, con score 0.981, apuntando exactamente al archivo. La documentación de Knowledge Bases sí lista los documentos escaneados entre los tipos que Smart Parsing selecciona automáticamente, pero no nombra el mecanismo: que corra OCR internamente lo infiero del resultado, no de una promesa explícita.

Eso ya es un dato con peso: si tu corpus tiene archivos grandes o escaneados que rompen chunking manual, Managed KB te resuelve un problema real sin que tengas que pensarlo.

Los Resultados

Juez Nova Pro y BYOI en todas las configuraciones, con los mismos scripts para A, B, C y D. Una sola corrida por celda — no promediada sobre múltiples ejecuciones, así que tómalo como señal, no como certeza estadística.

Figura 2: Las 8 combinaciones del diseño original (configuraciones A-D × 2 sets) terminaron Completed en la consola de RAG evaluations. Ninguna quedó a medias ni falló silenciosamente.

La fila E corrió un día después que A-D, como seguimiento directo al hallazgo del planner — el detalle completo, incluida la salvedad de que ahí el planner y el generador comparten modelo, está en su propia sección más abajo.

Y el veredicto de las cinco hipótesis que pre-registré antes de correr nada:

Figura 3: Vista de comparación nativa de RAG evaluations, config B (Retrieve simple) contra config C (AgenticRetrieveStream) sobre el set multi-hop. El retriever “agéntico” pierde en 3 de 4 métricas y empata en la cuarta.

Cuatro de cinco hipótesis se sostuvieron. La que se cayó es la interesante, y no se cayó por poco.

Con una salvedad de alcance sobre H3. Lo que esa hipótesis evalúa es el planner MANAGED, el default. Más adelante vas a ver que con un planner CUSTOM grande el patrón que H3 predecía sí aparece — y eso no la rescata, porque quedó refutada tal como la escribí y para el planner que medía. Lo que sí deja es la pregunta que persigo en el resto del artículo: ¿lo que importa es el tamaño del planner, o el hecho de que ese planner grande acabe compartiendo modelo con el generador?

El Hallazgo Principal: El Planner Nunca Planeó

H3 no es un “no ayudó mucho”. Es una regresión medida: en el set de preguntas donde el retriever agéntico debería lucirse, terminó peor que el retrieval simple de un solo paso.

Y tiene una causa mecánica identificada, no es un misterio estadístico. Revisé el trace completo de las 80 preguntas agentic ejecutadas (configuraciones C y D, ambos sets completos). En el 100% de los casos, la estructura fue idéntica: un único step Retrieval —la pasada especulativa con la query cruda— seguido de un Planning que devolvió "actions": []. Nunca apareció un segundo step Retrieval. Nunca apareció FullDocumentExpansion. El planner nunca generó una sola sub-query, ni siquiera en las preguntas del set multi-hop donde ya sabía —por una verificación aparte que hice antes de correr el benchmark— que el retrieval de un solo paso no alcanzaba ambos documentos relevantes.

Un ejemplo concreto. Para la pregunta “¿qué componente de AgentCore aplica una lógica similar a ‘Keep people away from data’ de la Security pillar para ejecución de código?”, el Retrieval especulativo inicial trajo únicamente contenido del developer guide de AgentCore —Code Interpreter, aislamiento de sesiones, controles de seguridad— y nada del Well-Architected Framework. El paso de Planning subsiguiente decidió que eso ya bastaba.

Figura 4: Trace crudo de esta misma pregunta. Tras el único step Retrieval, el evento Planning con "message": "Agent planning completed" devuelve "actions": [] — el planner consideró el trabajo terminado sin generar una sola sub-query.

🎓 ProTip #3: Si vas a medir “iteraciones” de un retriever agéntico, no cuentes steps del trace — cuenta sub-queries reales. Un step Planning que devuelve actions: [] sigue contando como una iteración en el campo iterations que expone el SDK, pero no representa ningún trabajo de descomposición. Es la diferencia entre “el planner corrió” y “el planner planificó”.

¿Es Esto un Bug? Fui a Verificarlo Contra la Fuente

Antes de publicar esto como hallazgo, lo contrasté contra el post oficial de AWS dedicado enteramente a esta capacidad, Agentic retrieval for Amazon Bedrock Managed Knowledge Base — el mismo que es fuente de los números de MuSiQue que cito arriba. Tres cosas se confirman, una se matiza.

Confirma que no es un problema de mi captura de datos. La documentación describe el step Retrieval/FullDocumentExpansion como “un evento por cada sub-query ejecutada”. Mi código loggea cualquier step que llegue en el stream, sin filtrar por nombre. Si el planner hubiera descompuesto aunque fuera una sola vez en 80 preguntas, habría aparecido en el trace. Nunca apareció.

Confirma que salir temprano es comportamiento documentado, no un error. La doc dice explícitamente que el planner “puede salir temprano después de que su paso de evaluación determine que la evidencia es suficiente”. El 100% de mis casos son justamente eso — un estado normal del servicio, no una falla.

Confirma los números de MuSiQue que ya cité, con sus valores exactos: +22.8, +31.9 y +37.3 puntos de recall en preguntas de 2, 3 y 4 saltos, con ganancias por debajo de 5 puntos en preguntas de un solo salto.

Y matiza algo importante: los dos ejemplos de código oficiales del post —single-KB y multi-KB— usan foundationModelType: "CUSTOM" con un modelo explícito. Ninguno usa el valor por defecto (MANAGED). El mismo post recomienda como best practice “empezar con un planner pequeño y rápido”, lo cual implica elegir un modelo a propósito, no confiar en el default.

Eso me lleva a la conclusión más honesta que puedo dar: no puedo afirmar “AgenticRetrieveStream no descompone” en general. Solo puedo afirmar, con evidencia de 80 de 80 preguntas, que el planner gestionado por defecto —el que obtiene cualquiera que no haya leído este blog post de AWS— nunca ejerció su capacidad de descomposición en mi corpus, ni siquiera cuando la evidencia recuperada era insuficiente. Que toda la documentación de referencia oficial use CUSTOM es, en sí mismo, un dato: sugiere que AWS tampoco espera que el modelo gestionado descomponga de forma confiable sin que el usuario elija su propio planner.

Probé la Salida Obvia: Un Planner Propio

Configuré foundationModelType=CUSTOM con Claude Haiku 4.5 como planner —un modelo “pequeño y rápido”, justo lo que recomienda AWS, y distinto tanto del generador (Sonnet 4.6) como del juez (Nova Pro), para no contaminar ninguno de los dos roles.

Guardé esta corrida por separado; no reemplaza los resultados oficiales de la configuración C, que siguen siendo con el planner gestionado, porque es lo que el diseño del benchmark mide a propósito.

Sí cambió algo. Con Haiku 4.5 como planner, 3 de las 15 preguntas del set multi-hop mostraron planning_actions > 0 — el planner generó sub-queries reales, algo que nunca pasó ni una sola vez en las 80 preguntas con el planner gestionado. En el set de un salto, 0 de 25 descompusieron, lo cual es coherente: ahí no hace falta.

Pero no cambió lo que de verdad importaba. Las 5 preguntas cross-document donde el Retrieve simple demostrablemente fallaba en traer evidencia de ambos documentos —confirmé por separado que el contenido faltante sí estaba bien indexado, no era un problema de ingesta— siguieron trayendo un solo documento, exactamente igual que con el planner gestionado. El planner CUSTOM descompuso preguntas que ya tenían evidencia suficiente en una sola pasada, y no tocó las que genuinamente necesitaban las dos fuentes.

💡 ProTip #4: Cambiar de planner gestionado a uno propio no es un botón mágico que arregla el multi-hop cross-document, al menos con un modelo “pequeño y rápido” como recomienda AWS. El resultado publicable, con lo que tengo hasta aquí, es: cambiar el planner ayuda a que el planner trabaje, no garantiza que trabaje en las preguntas correctas.

Quedaba una pregunta obvia sin responder: ¿y si el planner no es solo distinto, sino grande? La probé, y el resultado me obligó a reescribir esta sección dos veces.

Subí de Categoría: Un Planner Grande (Y una Colisión de Roles que Hay que Nombrar)

El blog oficial de AWS menciona dos candidatos como planner “grande”: Claude Sonnet 4.6 y Amazon Nova Premier. Antes de correr nada, verifiqué cuál seguía siendo viable contra la cuenta real, no contra la doc — y encontré un problema.

Figura 5: Nova Premier aparece marcado Legacy en el catálogo de modelos. Verificado con más detalle: startOfLifeTime=2025-04-30, legacyTime=2026-03-13, endOfLifeTime=2026-09-14 — doce días después de esta sesión.

Nova Premier queda descartado no por preferencia de diseño, sino porque cualquiera que intente reproducir este benchmark después del 14 de septiembre no podría usarlo aunque quisiera. Eso me dejó una sola alternativa “grande” citada por AWS: Sonnet 4.6, el mismo modelo que ya uso como generador constante en A, B, C y D.

Aquí hay que ser explícito sobre lo que esto rompe: mi propia regla de diseño para la corrida con Haiku fue mantener el planner aislado del generador y del juez, precisamente para no contaminar ningún rol. Config E rompe esa regla a propósito, documentada como desviación, no como descuido. El resultado que sigue no se puede leer como “planner grande puro” — hay que leerlo como “planner grande que además es el mismo modelo que genera la respuesta después”.

Con esa salvedad ya puesta sobre la mesa, los números:

Sonnet 4.6 descompuso casi el triple de veces que Haiku. De las 5 preguntas cross-document que ni MANAGED ni Haiku resolvían (b04, b08, b09, b11, b14), verificado buscando vocabulario específico del Well-Architected Framework en los chunks recuperados:

• b04 y b14 se corrigen — ahora sí traen contenido del WAF.
• b08 mejora parcialmente — algo de WAF, no tanto como las anteriores.
• b09 y b11 siguen sin el lado que faltaba — b09 incluso generó una sub-query, pero no hacia el documento correcto; b11 ni siquiera descompuso.

Figura 6: b14 resuelta con el planner Sonnet 4.6. La pregunta cruza el principio de sostenibilidad Maximize utilization del Well-Architected Framework con el modo Instances de AgentCore Runtime — dos documentos distintos. La respuesta cita los pasajes recuperados 11 y 13, coincide con el ground truth, y el juez le da Correctness 1.

Es decir: un planner más grande descompone más, pero no garantiza que descomponga bien. Dos de cinco preguntas problemáticas siguen rotas incluso con el modelo más capaz que pude probar.

Y el eval job con Nova Pro, mismas 4 métricas:

Figura 7: Comparación nativa de los dos eval jobs sobre el set multi-hop. El área de E domina a C en las cuatro métricas medidas, con la brecha más ancha en Correctness. Los demás ejes del radar quedan en 0 porque esos evaluadores no formaban parte del job.

En el set de un salto la diferencia es pequeña (0.90 vs 0.88 de Correctness), consistente con H2: un planner, del tamaño que sea, no debería aportar mucho cuando un solo paso ya alcanza. En el set multi-hop el salto es grande: Correctness pasa de 0.50 (C) a 1.00 (E) — por encima incluso de B (Retrieve simple, 0.567) y de D (planner MANAGED + generación del servicio, 0.70).

¿Es Real, o Suerte de una Sola Tirada?

Antes de publicar un salto de esa magnitud, repetí la corrida completa de C y E sobre el set multi-hop al día siguiente — mismas 15 preguntas, mismo corpus, mismos modelos, pipeline de retrieval, generación y evaluación corrido de cero, con su propio job de evaluación independiente.

El resultado sostiene. Correctness de E salió exactamente 1.00 en las dos corridas independientes — no es un artefacto de una tirada con suerte. C se mantiene bajo en ambas, con una diferencia de 0.033 entre corridas que es ruido normal de juez, no una tendencia. La brecha entre C y E en Correctness es estable; las otras tres métricas varían un poco más entre corridas (hasta 0.05) pero sin cruzar nunca la brecha entre configuraciones.

⚠️ ProTip #5: Un salto de 0.50 a 1.00 en una sola corrida de 15 preguntas es exactamente el tipo de número que invita a sospechar de un artefacto — un promedio inflado por registros descartados, un null_result mal contado. Antes de publicar cualquier salto así de grande, repite la corrida completa de cero. Si no sostiene, era ruido. Si sostiene, como en este caso, tienes evidencia real de que vale la pena reportar con confianza.

La lectura honesta, con todas sus salvedades:

1. N=15 sigue siendo un set chico. El patrón se repite en 2 corridas, pero eso no reemplaza un N mayor. La dirección del efecto está bien sostenida; los valores exactos de Completeness, Faithfulness y Helpfulness tienen más ruido de corrida en corrida que Correctness.
2. El planner y el generador comparten modelo, la desviación ya declarada arriba. No puedo descartar que parte de la ganancia venga de que Sonnet 4.6, como planner, “sepa mejor qué se le va a preguntar a sí mismo después” — un efecto de auto-consistencia, no necesariamente de mejor razonamiento de descomposición en abstracto.
3. No cierra el problema por completo. b09 y b11 siguen sin resolverse incluso con el planner más capaz que pude probar — la ganancia es real, pero parcial: 2 de 5 preguntas arregladas, 1 parcial, 2 sin cambio.
4. La comparación limpia (Nova Premier) no está disponible por la fecha de EOL. Esta corrida no puede aislar “planner más grande” de “planner que además es el generador” — esa separación hubiera requerido un tercer modelo grande sin ese conflicto de rol.

La conclusión que sí sostiene la evidencia: un planner CUSTOM más grande que Haiku descompone más veces (8/15 contra 3/15 en el set multi-hop) y, cuando descompone hacia el lado correcto, mueve las métricas de forma sustancial — algo que Haiku nunca llegó a demostrar. Lo que no puedo separar limpiamente, con este diseño, es cuánto de esa ganancia es “modelo más capaz” y cuánto es “mismo modelo que ya genera la respuesta final”.

Lo Que Cambió Desde Abril (Y Lo Que No)

Una afirmación de abril quedó desactualizada, y dos supuestos con los que arranqué este benchmark resultaron equivocados. Los tres se corrigen acá.

Claude Sonnet 4.6 ya está en la allowlist de jueces para evaluación RAG/KB específicamente. En abril tuve que usar Nova Pro por esa restricción, así que dejé la nota de actualización correspondiente en el artículo original en vez de dejar el dato colgado allá. Aun así, mantuve Nova Pro como juez en este benchmark: el diseño pide un juez cross-family como control de imparcialidad independiente, para evitar el sesgo de auto-preferencia conocido en LLM-as-judge cuando el juez comparte familia con el generador (que sigue siendo Sonnet 4.6 en A, B y C). La disponibilidad nueva no cambia esa lógica de diseño.

Los otros dos son correcciones a mi propio research previo, no a lo publicado en abril.

foundationModelType acepta CUSTOM y MANAGED, con MANAGED como default. Esto no estaba claro en la primera revisión de la documentación pública que hice antes de ejecutar — solo se documentaban ejemplos con CUSTOM. Confirmado tanto contra la referencia de API actualizada como contra el shape real de botocore en la cuenta.

La primera versión de boto3/botocore que soporta AgenticRetrieveStream es la 1.43.32 — esa release lanzó la operación y “Managed Knowledge Bases” juntos, en el mismo commit de API. El Python global de mi máquina traía una versión anterior; tuve que aislar el proyecto en un virtualenv propio.

Tabla de Decisión

Con los datos en la mano, esto es lo que le diría hoy a alguien evaluando esta migración:

Lo Que Queda Pendiente

Este benchmark, como el de abril, tiene scope acotado a propósito:

• Aislar tamaño de planner de colisión de rol. Config E usa Sonnet 4.6 como planner y como generador a la vez. La separación limpia hubiera sido un modelo grande distinto de ambos — Nova Premier era la única opción citada por AWS, y quedó fuera de alcance por su fecha de fin de vida (14 de septiembre de 2026).
• N mayor en el set multi-hop. 15 preguntas, aunque replicadas en dos corridas, siguen siendo pocas para intervalos de confianza serios.
• Multi-KB routing, la otra capacidad central de AgenticRetrieveStream que no toqué aquí — este benchmark usó una sola Managed KB en todas las configuraciones.
• Costo por consulta comparado entre planners. Este benchmark mide calidad y latencia, no costo. Y la pregunta que queda abierta es bastante concreta: si un planner grande descompone casi el triple de veces, ¿cuánto sube la factura por consulta contra la ganancia en Correctness? Eso se responde midiendo tokens de planning por query, no mirando el gasto agregado de la cuenta.
• Corpus en español, fuera de scope igual que en abril.
• Resolver b09 y b11, las dos preguntas cross-document que ni el planner gestionado ni ningún planner CUSTOM que probé lograron resolver del todo.

Si replicas esto en tu cuenta y el planner gestionado sí descompone en tu corpus, quiero saberlo — sería evidencia de que el comportamiento depende más del tipo de contenido de lo que mis datos sugieren.

Conclusión

Managed Knowledge Base no es una regresión de calidad. En retrieval simple, hace lo mismo que mi configuración manual de abril, y resuelve sin esfuerzo el problema de ingesta que en abril tumbó dos de las cinco estrategias de chunking. Si tu única pregunta es “¿pierdo calidad al dejar de administrar el chunking?”, la respuesta con estos datos es no.

Pero el nombre “agentic” en AgenticRetrieveStream promete algo que el planner por defecto no entrega, y que un planner mal elegido tampoco garantiza. No es marketing engañoso —AWS documenta el comportamiento de salida temprana como normal, y sus propios ejemplos de código nunca usan el default— pero sí es una trampa fácil de caer si activas la funcionalidad esperando que “sea más inteligente” sin elegir explícitamente quién hace el razonamiento. Con el planner gestionado, fue una regresión medida. Con un planner pequeño, fue descomposición real pero mal dirigida. Con un planner grande —aunque compartiera modelo con mi generador, una limpieza que no pude aislar del todo por la salida de Nova Premier— la Correctness en preguntas multi-hop se duplicó, sostenida en dos corridas independientes.

La consultoría real, si trabajas con esto en producción, no es “activa el retriever agéntico”. Es “activa el retriever agéntico, elige tu propio planner —y probablemente uno más grande de lo que te da pereza probar primero—, y mide en tu propio corpus si descompone las preguntas que de verdad lo necesitan”. Porque el rango que encontré en un mismo corpus, con la misma pregunta multi-hop, fue de “peor que no usarlo” a “el doble de bueno que usarlo sin pensar”, según quién planificara.

El código completo del benchmark —Terraform, scripts numerados, las 15 preguntas multi-hop con su verificación cruzada, y los datasets BYOI— está en github.com/codecr/mkb-vs-chunking.

🚀 Pro Tip Final: Antes de activar cualquier feature “agéntico” en producción, pregúntate qué modelo está tomando las decisiones de planning y si ese modelo es el que tú elegiste o el que el servicio eligió por ti. Y si eliges tú, no te conformes con el primer modelo “pequeño y rápido” que sugiera la documentación — en mi benchmark, la diferencia entre un planner pequeño y uno grande fue más grande que la diferencia entre tener planner y no tenerlo.

Si te interesa el contexto completo, el benchmark original de chunking sigue siendo la referencia para configuraciones manuales. Y si lo que quieres es exponer una Managed KB como herramienta MCP para tus agentes, ese camino pasa por AgentCore Gateway como target de Knowledge Base —el conector expone AgenticRetrieveStream y Retrieve como tools MCP— y mi artículo sobre Amazon Bedrock + MCP da el contexto del protocolo.

¡Nos vemos en el próximo artículo! Si replicaste esto o probaste un planner distinto, cuéntamelo en los comentarios — con este hallazgo en particular, entre más ojos lo verifiquen, mejor. 🚀

Recursos Oficiales 📚

• Blog: Agentic retrieval for Amazon Bedrock Managed Knowledge Base — fuente de los números de MuSiQue y de los ejemplos con foundationModelType=CUSTOM
• Blog: Build enterprise search for agents with Amazon Bedrock Managed Knowledge Base
• API Reference: AgenticRetrieveStream
• Use agentic retrieval to query a knowledge base
• Build a managed knowledge base
• Create a managed knowledge base
• Customize ingestion for a data source (Smart Parsing por defecto)
• Retrieve data and generate AI responses with Amazon Bedrock Knowledge Bases
• Connect to your knowledge base through AgentCore Gateway (KB como tool MCP)
• Amazon Bedrock Managed Knowledge Bases as Connector Target
• Evaluate the performance of RAG sources using Amazon Bedrock Evaluations
• Creating a retrieve-and-generate RAG evaluation job (path BYOI)
• Anuncio: Amazon Bedrock RAG Evaluation generally available (marzo 2025)
• Blog: Evaluate models or RAG systems using Amazon Bedrock Evaluations — now GA