Bedrock Knowledge Base permite elegir la profundidad de búsqueda: de 0 llamadas a la LLM al RAG agéntico

Por la mañana, un empleado de banca pregunta al asistente interno de IA qué documentos necesita un empresario individual para abrir una cuenta. La respuesta está en una sola lista de comprobación. Por la tarde, el mismo empleado pregunta en qué se diferencian los requisitos para empresarios individuales, sociedades de responsabilidad limitada y sociedades con varios propietarios. La respuesta está repartida entre varios reglamentos internos. El asistente es el mismo, pero las preguntas tienen una complejidad y un coste muy distintos. Si ejecuta un ciclo agéntico pesado para ambas preguntas, pagará de más y aumentará la latencia. Si hace una sola búsqueda para ambas, perderá precisión en la pregunta compleja.

AWS cubre esta necesidad en Amazon Bedrock Managed Knowledge Base. Antes, AgenticRetrieveStream solo ofrecía el modo agéntico; ahora incorpora otros dos.

Un parámetro en lugar de dos API

Todo se controla mediante maxAgentIteration. El rango ahora es 0–5, y su valor determina cómo se procesa la consulta.

0 — solo búsqueda. El servicio garantiza una única búsqueda y no genera nada. No hay llamadas al modelo fundacional; en la práctica, equivale a la API Retrieve convencional. Este modo resulta útil para quienes ya han migrado a AgenticRetrieveStream y no quieren cambiar de API para una consulta sin generación. Si se establece generateResponse=true con el valor cero, se devuelve un error 4xx: para generar una respuesta hace falta una LLM.

1 — RAG clásico. Una búsqueda y una llamada al modelo para responder, sin planificación ni reformulación de la consulta. El ejemplo del artículo: «¿Qué documentos necesita un empresario individual para abrir una cuenta de empresa?». La lista de comprobación está en la base de conocimientos; aquí, el planificador solo añadiría latencia. Si la mayor parte del tráfico consiste en preguntas directas y bien delimitadas, AWS sugiere usar este valor de forma predeterminada.

2–5 — modo agéntico. El modelo divide la pregunta en subconsultas, realiza una búsqueda para cada una, evalúa si la información encontrada es suficiente y, si hace falta, afina la búsqueda o recupera el documento completo. Los valores 2–5 funcionan como antes, por lo que las consultas existentes seguirán funcionando.

Cómo se cuentan las iteraciones

La regla es sencilla: una iteración equivale a una llamada al modelo fundacional. La última iteración siempre se dedica a generar la respuesta. Por tanto, el valor n permite hasta n−1 rondas de planificación, y cada ronda incluye la reformulación de la consulta y una búsqueda.

Hay un matiz. La búsqueda especulativa, que se ejecuta antes del primer paso de planificación, no cuenta como iteración. No consume el límite y solo puede acelerar la consulta.

AWS también subraya que una única búsqueda no implica una única base de conocimientos. Los tres modos, incluidos 0 y 1, funcionan con varias bases. El modo agéntico añade la descomposición de la pregunta, la evaluación de las evidencias encontradas y la búsqueda iterativa; la capacidad de consultar varias bases no depende de él.

En el ejemplo del banco, funciona así. Para la pregunta sobre la lista de comprobación del empresario individual, establecemos maxAgentIteration=1 y generateResponse=true. Para comparar los requisitos de empresarios individuales y sociedades de responsabilidad limitada, incluidas las comprobaciones de no residentes, usamos 4, es decir, hasta tres rondas de planificación. Cuando el empleado necesita el propio texto del reglamento, en lugar de un resumen, usamos 0 y generateResponse=false, y la aplicación muestra pasajes con enlaces a las fuentes. Pasar de una llamada agéntica al RAG convencional requiere cambiar un solo número en el JSON.

Limitaciones y qué hacer en la práctica

Lo principal: la elección del modo sigue siendo responsabilidad de su aplicación. Aquí no hay enrutamiento automático según la complejidad de la pregunta. Hace falta un enrutador sencillo —según el tipo de caso de uso, una heurística o un clasificador pequeño— o asignar un modo fijo a cada pantalla o función.

Segundo: el formato de respuesta del modo 0 difiere del de una llamada directa a Retrieve. Los pasajes sin duplicados llegan en el evento result del stream, sin los campos score y location. Si su interfaz depende de la puntuación de relevancia o de la ubicación exacta del fragmento, compruébelo antes de migrar.

Tercero: los ejemplos del banco que aparecen en el artículo son ilustrativos. AWS no aporta mediciones de latencia, coste ni calidad. La afirmación de que single-shot reduce la latencia y el consumo del modelo frente al modo agéntico es lógica, pero no viene respaldada por cifras. No la dé por cierta sin comprobarla.

El plan práctico es el siguiente:

• Reúna un conjunto de preguntas reales con respuestas de referencia extraídas de sus documentos.
• Pruébelo con el modo 1 y con la configuración agéntica actual sobre la misma base de conocimientos.
• Mida la latencia y el coste de la consulta y compruebe que las respuestas sean correctas y estén respaldadas por los pasajes encontrados.
• Incluya preguntas cuya respuesta requiera reunir información de varios documentos. Son precisamente aquellas en las que una única búsqueda suele rendir peor.

Si actualmente usa el modo agéntico de forma predeterminada, es muy probable que en las consultas simples esté pagando por una planificación que no aporta nada. Empiece con un valor bajo para el tráfico sencillo y auméntelo cuando la precisión en preguntas complejas importe más que la velocidad. El límite de iteraciones también debe ajustarse con datos propios: más iteraciones no siempre significan una mejor respuesta.