RAG para agentes: anclar respuestas sin ahogarse en contexto
La generación aumentada por recuperación suele presentarse como tubería: incrustar la pregunta, traer los mejores fragmentos, pegarlos, generar. Eso funciona para una caja de preguntas. Dentro de un agente es la forma equivocada, porque el agente no sabe qué necesita hasta haber dado un paso.
La versión que funciona trata la recuperación como una herramienta que el agente llama cuando decide que necesita pruebas: a veces dos veces con consultas distintas, a veces ninguna. Ese cambio elimina mucho contexto irrelevante y hace toda la ejecución más barata y más afilada.
Recuperación como herramienta, no como preámbulo#
Expón la búsqueda como una herramienta normal con argumento de consulta y una devolución pequeña y estructurada: unos pocos pasajes, cada uno con identificador y fuente. El agente decide cuándo llamarla, puede refinar tras ver lo que vuelve y puede llamar otra herramienta si la respuesta son datos estructurados. La versión en tubería no puede nada de eso y paga el coste en cada petición.
Registra las consultas que escribe el agente. Son la descripción más honesta que tendrás de lo que preguntan de verdad tus usuarios.
Decisiones de troceado que importan más que el modelo de embeddings#
- Divide por estructura — encabezados, secciones, elementos de lista — no por número fijo de caracteres.
- Mantén cada fragmento autónomo: uno que empiece por `También requiere` es inútil fuera de contexto.
- Adjunta el título del documento y el encabezado de sección a cada fragmento.
- Guarda identificador y URL con cada fragmento para poder citar.
- Prefiere pocos fragmentos grandes y significativos; el solape es un parche a fronteras malas.
El híbrido gana a los vectores puros en corpus reales#
| Tipo de consulta | Búsqueda vectorial | Palabras clave | Mejor |
|---|---|---|---|
| Pregunta conceptual | Fuerte | Débil | Vectorial |
| Código exacto o texto de error | Débil | Fuerte | Palabras clave |
| Nombre propio raro | Mixto | Fuerte | Palabras clave |
| Pregunta de política reformulada | Fuerte | Débil | Vectorial |
| Tráfico real en conjunto | Mixto | Mixto | Ambos, combinados y reordenados |
Haz que cite y permite que falle#
Dos requisitos hacen casi todo el trabajo de fiabilidad. Primero, cada afirmación procedente de recuperación lleva el identificador de su pasaje y tu interfaz lo muestra como enlace: así lo no respaldado se vuelve visible en vez de plausible. Segundo, la búsqueda debe poder devolver nada, y hay que enseñar al agente que `no lo encuentro en nuestra documentación` es un resultado correcto. Un agente que no puede fallar al buscar, inventará.
Mantener honesto el índice#
La calidad de recuperación se degrada en silencio. Los documentos cambian, se borran secciones y el índice sigue sirviendo lo último que vio. Reindexa con cadencia, borra fragmentos cuyo documento ya no existe y mantén un pequeño conjunto de consultas con pasajes correctos conocidos para medir tras cada cambio. Sin eso llega el peor fallo: un agente citando con seguridad una política retirada en marzo.
Preguntas frecuentes
¿Debe recuperar siempre antes de responder?
No. Recuperar en cada petición gasta latencia y llena contexto en preguntas que no necesitan pruebas. Deja que el agente decida y mide cuántas veces debió buscar y no lo hizo.
¿Cuántos pasajes devolver?
Tres a seis bien elegidos ganan a veinte. Más texto diluye la atención, sube el coste y aumenta la probabilidad de apoyarse en un pasaje que solo parecía relevante.
¿Y si la recuperación no devuelve nada útil?
Debe ser un desenlace soportado. Devuelve un vacío explícito e instruye al agente a decir que no lo encontró y ofrecer el paso siguiente.
rag para agentesgeneración aumentada por recuperaciónbúsqueda híbridaestrategia de troceadorespuestas ancladas
