RAG para conocimiento empresarial: fuentes, recuperación, permisos y evaluación · Módulo 3: Recuperar y responder con evidencia

Diseñar consulta, recuperación y reranking

Pipeline para transformar consultas de forma trazable, recuperar candidatos suficientes y aplicar reranking solo cuando resuelve fallos medidos.

Objetivo de aprendizaje

Construir un pipeline reproducible de consulta, filtros, recuperación de candidatos y reranking que preserve la intención y permita diagnosticar exclusiones.

La pregunta del usuario no siempre es una buena consulta de búsqueda. Puede contener pronombres, referencias a la conversación, varios subproblemas o condiciones que deberían convertirse en filtros. El pipeline de recuperación debe transformar lo necesario sin cambiar silenciosamente la intención.

Separa la pregunta visible de la consulta ejecutada

Conserva la pregunta original. Cualquier reescritura, expansión o descomposición debe quedar registrada para poder explicar por qué se recuperaron determinados documentos.

Una transformación puede:

  • resolver una referencia conversacional;
  • extraer producto, región o versión como filtros;
  • añadir sinónimos;
  • separar una pregunta compuesta;
  • generar varias consultas candidatas.

El riesgo aparece cuando la transformación introduce hechos que el usuario no dijo. Si una pregunta no especifica región y la región cambia la respuesta, inventarla en la query produce una recuperación precisa para el caso equivocado.

Empieza por la estrategia más simple que funcione

No necesitas descomposición multiquery, rerankers costosos o agentes de búsqueda para cada pregunta. Primero mide una recuperación base.

Una progresión razonable puede ser:

consulta original → filtros → búsqueda híbrida → top-k

Si el benchmark muestra fallos concretos, añade transformación o reranking y compara.

La complejidad debe responder a un patrón de error observado.

Genera candidatos con suficiente cobertura

El primer recuperador prioriza recall: debe incluir la evidencia relevante en el conjunto candidato. Si la fuente correcta queda fuera, el reranker no puede inventarla.

Aumentar el número de candidatos puede mejorar cobertura y también elevar coste y ruido. Mide cómo cambia el recall y cuánto tarda la etapa posterior.

No fijes top_k como dogma. El valor depende del corpus, del tamaño de fragmentos y de cuánta evidencia necesita la tarea.

Usa reranking para precisión, no para seguridad

Un reranker puede evaluar de nuevo consulta y candidato con una señal más rica y mover los pasajes más útiles hacia arriba. Puede ayudar con preguntas donde la similitud inicial recupera contenidos próximos pero no suficientemente específicos.

Sin embargo:

  • no sustituye filtros de acceso;
  • no corrige documentos ausentes;
  • no resuelve una fragmentación mala;
  • no sabe qué versión es autoritativa si no recibe ese dato;
  • añade latencia y coste.

Por tanto, mide su valor sobre fallos reales.

Conserva los motivos de exclusión

Durante depuración necesitas distinguir:

  • documento no indexado;
  • excluido por permiso;
  • excluido por región;
  • recuperado pero fuera de top-k;
  • recuperado y descartado por reranking;
  • enviado al modelo;
  • citado en la respuesta.

Esa trazabilidad evita culpar al modelo generativo de errores que ocurrieron antes.

Trata consultas de varias partes de forma explícita

Una pregunta como «¿Cuál es el plazo y qué excepción existe para clientes premium?» puede requerir dos pasajes. Puedes recuperar con una sola query si el índice lo permite o descomponer en subconsultas.

La descomposición debe preservar que ambas respuestas forman parte de la misma pregunta y que no se mezclen ámbitos incompatibles.

Si una subpregunta no tiene evidencia, el resultado final debe reflejarlo en vez de completar la parte ausente con conocimiento general.

Ejemplo: procedimiento y excepción

El usuario pregunta: «¿Puedo cancelar una solicitud después de aprobarla y qué ocurre con el anticipo?».

La recuperación básica encuentra el procedimiento de cancelación, pero no la política financiera. Un análisis del benchmark muestra que las preguntas con dos consecuencias distintas pierden la segunda fuente.

En lugar de aumentar indiscriminadamente el contexto, se puede descomponer la consulta en «cancelación después de aprobación» y «tratamiento del anticipo en cancelación», aplicar los mismos filtros de usuario y combinar los candidatos. Después se evalúa si la mejora compensa coste y complejidad.

Controla expansión, descomposición y consultas generadas

Una reescritura automática puede mejorar recall, pero también introducir vocabulario o supuestos que sesgan la búsqueda. Guarda la consulta original y todas las variantes generadas.

En preguntas simples, evita expansión innecesaria. En preguntas complejas, compara:

  • consulta única;
  • varias reformulaciones;
  • descomposición en subpreguntas;
  • recuperación por campos específicos.

La mejor estrategia es la que mejora el benchmark con un coste operativo aceptable, no la que contiene más etapas.

Diseña presupuestos de latencia y contexto

Cada etapa consume tiempo y, en algunos diseños, dinero: generación de query, múltiples búsquedas, reranking y generación final.

Define un presupuesto aproximado por fase. Si el usuario necesita respuesta interactiva, un reranking que añade varios segundos puede ser inaceptable aunque mejore marginalmente una métrica. Si el uso es una investigación de fondo, el mismo coste puede ser razonable.

También controla cuánto contexto final envías. Más chunks no equivalen necesariamente a mejor respuesta: pueden aumentar ruido, contradicciones y coste.

Ejercicio: pipeline de recuperación

Escoge diez preguntas difíciles y documenta:

  1. pregunta original;
  2. transformación;
  3. filtros;
  4. consultas ejecutadas;
  5. candidatos;
  6. ranking inicial;
  7. reranking;
  8. fragmentos finales;
  9. latencia;
  10. coste estimado;
  11. fuente esperada;
  12. resultado.

Compara baseline y versión mejorada. Solo conserva una transformación si mejora métricas relevantes sin introducir errores nuevos en otros segmentos.

Entregable

El entregable de esta lección es un pipeline de consulta y recuperación medible: sabes qué se transformó, qué filtros se aplicaron, qué candidatos se recuperaron y qué reordenó el sistema. Ahora puedes diseñar la generación sin tratar el contexto recuperado como si garantizara una respuesta correcta.