Recuperación basada en evidencias y familia: Lograr que el contexto RAG cubra cada parte de una pregunta

Cinco fragmentos relevantes aún pueden dejar a un sistema RAG sin lo que necesita la pregunta completa. La paradoja desaparece cuando resulta que una pregunta requiere pruebas de varios tipos diferentes. Imagine a alguien preguntando cómo deben gestionarse los ajustes de la aplicación, las credenciales y los permisos otorgados a las cargas de trabajo como parte de una sola configuración. Un recuperador podría devolver cinco pasajes excelentes sobre la configuración. Todos son relevantes, pero el contexto queda incompleto si no menciona nada sobre las credenciales o los permisos.

Esta es una debilidad inherente a la recuperación simple top-k: clasificar los fragmentos uno por uno no indica si todos los conceptos necesarios para la respuesta están presentes.

La relevancia no es la completitud

Un pipeline convencional clasifica los fragmentos y mantiene los primeros k. Eso funciona bien cuando un tipo de evidencia resuelve la cuestión, pero resulta insuficiente cuando se requiere comparación, síntesis o varias fuentes de información. Supongamos que los cinco fragmentos más destacados tratan todos sobre Secretos, pero la respuesta también necesita la identidad de ServiceAccount y autorización RBAC. La clasificación es razonable a nivel local, pero incompleta a nivel global.

Aumentar el valor de top_k podría ayudar, pero no de forma fiable. Un contexto más amplio puede generar duplicados, ruido, demoras y costos adicionales, sin garantía de que aparezca el concepto faltante; además, si un grupo de fuentes domina entre los candidatos, podría ocupar por sí solo las 20 posiciones principales. El objetivo requiere una restricción de cobertura:

Useful context = relevance + required-family coverage + trusted provenance - noise

La recuperación por familias de evidencias añade esa restricción manteniendo al mismo tiempo el ranking de relevancia habitual.

Qué se considera una familia

Una familia de evidencias es un conjunto de fuentes o pasajes que pueden cumplir con una obligación en una pregunta. No necesariamente debe equivaler a un archivo, etiqueta de tema, clúster de embeddings, estrategia de recuperación o bloque de texto. Imagine una pregunta sobre cómo exponer una aplicación de forma segura: sus familias podrían ser el enrutamiento de ingreso, el descubrimiento de servicios y el comportamiento de disponibilidad. Varios documentos pueden calificar para la familia de Servicios, y un documento puede pertenecer a más de una familia si sus metadatos y contenido lo permiten.

Planifique las evidencias antes de la selección final

Para los tipos de preguntas compuestas reconocidos, el proyecto utiliza un planificador de evidencias determinista. Conceptualmente, su salida es un conjunto de pares (source_pattern, rescue_query), con una entrada para cada familia que la pregunta necesita:

def evidence_plan(question: str):
    # Returns list of (family_pattern, rescue_query) tuples
    # for recognized composite question shapes
    if asks_about_workload_identity(question):
        return [
            (SECRET_SOURCE_PATTERN,      "Kubernetes Secret credentials Pod"),
            (SERVICE_ACCOUNT_PATTERN,    "Pod ServiceAccount workload identity"),
            (RBAC_SOURCE_PATTERN,        "RBAC least privilege RoleBinding"),
        ]
    return []  # unknown shapes continue through normal retrieval

El alcance es deliberadamente modesto, muy lejos de una planificación autónoma sin límites. Las preguntas cuya importancia se conoce cuentan con reglas de cobertura predecibles, mientras que todo lo demás se maneja mediante búsquedas habituales. La propiedad clave es la inspeccionabilidad: un plan puede ser examinado y probado, de modo que un equipo que detecte la ausencia de una familia puede rastrear el problema hasta la detección de preguntas, la clasificación de fuentes, la recuperación de candidatos, el reordenamiento, el filtrado o el recorte final.

Reconocimiento de la pertenencia

En el estudio de caso, la pertenencia a una familia se determina mediante la coincidencia de una expresión regular con el nombre de la fuente del fragmento:

pattern.search(str(chunk.source))

Se trata de un contrato de origen determinista, no de agrupamiento semántico. Lo que se obtiene es precisión y posibilidad de auditoría: un documento coincide con la familia declarada o no. Lo que se paga es el mantenimiento, ya que los archivos con nombres cambiados y las nuevas colecciones requieren que se actualicen sus mapeos. Una plataforma reutilizable debería dar prioridad a los metadatos explícitos sobre los patrones de nombres de archivo:

{
  "source": "security-policy.pdf",
  "document_id": "doc-123",
  "chunk_index": 17,
  "evidence_family": "access-control",
  "authority_tier": "official",
  "version": "2026-07"
}

La verificación de membresía se reduce entonces a una búsqueda: chunk.metadata["evidence_family"] == required_family.

Rescatar familias faltantes

Después de la recuperación en el primer paso, el proceso cuenta los candidatos que coinciden para cada familia planificada. Si una familia tiene menos elementos de los deseados, se inicia una búsqueda específica con la consulta de rescate correspondiente a esa familia:

for family_pattern, rescue_query in plan:
    matches = [c for c in candidates if family_pattern.search(c.source)]

    if len(matches) < desired_candidate_count:
        # Targeted rescue — bounded, not an open retry loop
        rescued = sparse_search(rescue_query, top_k=wide_limit)
        candidates.extend(
            c for c in rescued if family_pattern.search(c.source)
        )

La búsqueda de rescate solo se realiza para familias desaparecidas, utilizando una consulta específica vinculada al contrato de la familia, y devuelve varios candidatos para que el reclasificador pueda elegir al más adecuado en lugar de conformarse con el primer pasaje disponible.

El reclasificador elige pasajes, no familias

La fase de planificación decide qué familias deben estar representadas, mientras que el reclasificador determina qué fragmentos disponibles responden mejor a la pregunta. Ambos procesos son complementarios. El reclasificador del proyecto combina una mezcla ponderada de señales:

0.4 × normalized cross-encoder score
+ 0.3 × normalized retrieval score
+ 0.3 × lexical overlap
+ conditional exact-token bonus

Una vez clasificados los candidatos, el proceso de selección sensible a las necesidades familiares reserva el grupo mejor clasificado que se ajuste a cada familia requerida y, posteriormente, llena los espacios restantes según el ranking general:

selected = []

# Step 1: reserve best chunk per required family
for family in required_families:
    best_match = first_ranked_match(family, ranked_chunks)
    if best_match:
        selected.append(best_match)

# Step 2: fill remaining slots by global rank
selected.extend(c for c in ranked_chunks if c not in selected)

final_chunks = selected[:top_k]  # constrained top-k, not an alternative to ranking

Por qué los fragmentos de una misma fuente pueden necesitar permanecer juntos

Una versión inicial de la selección sensible a la familia cometió un error al eliminar duplicados basándose únicamente en el nombre del archivo. Imagine un documento NetworkPolicy con secciones separadas sobre el comportamiento de denegación por defecto, reglas de entrada y reglas de salida, todas necesarias para responder a una misma pregunta compuesta. Si la selección solo permite un fragmento por nombre de archivo, dos secciones esenciales desaparecen. La política correcta de eliminación de duplicados depende de la obligación de proporcionar evidencia: debe reducir la redundancia sin perder la cobertura, y una misma fuente puede legítimamente ofrecer varias secciones complementarias siempre que cada una cumpla con una obligación diferente.

Autoridad versus relevancia

Un artículo de investigación ruidoso puede ser semánticamente similar a una pregunta de producción, y una guía genérica de panel de control puede compartir muchos términos de consulta. Ninguno de los dos debe reemplazar un manual operativo aprobado que responda directamente a la pregunta. Tres señales deben mantenerse distintas:

Relevance:  Does this passage discuss the question?
Authority:  Is this an approved source of truth?
Coverage:   Which required evidence obligation does it satisfy?

Una puntuación no debería sustituir silenciosamente a las tres. Los metadatos de autoridad también deben resistir procesos como la ingesta, recuperación, fusión, reclasificación, almacenamiento en caché y serialización mediante API, y no limitarse a permanecer en la base de datos vectorial.

RAG correctivo sin perder cobertura

El RAG correctivo evalúa los fragmentos recuperados y puede intentarlo de nuevo cuando la evidencia parece débil. Aumenta la precisión, pero puede entrar en conflicto con la planificación de evidencias, ya que un pasaje limitado que parece solo parcialmente relevante por sí mismo puede ser vital para una síntesis de múltiples documentos. Si CRAG lo descarta, una familia necesaria desaparece de la respuesta. Para evitarlo, la implementación considera un plan validado como política del dominio: después de que CRAG realice el filtrado, ejecuta una nueva búsqueda amplia para cada familia planificada y selecciona el pasaje de autoridad más sólido. El orden es importante:

Retrieve broadly
→ shape and rerank candidates
→ reserve family coverage
→ grade evidence (CRAG)
→ restore validated required families
→ build context

Un diseño maduro puede utilizar varios niveles de planificación, elegidos en función del grado de comprensión de la estructura de la pregunta. Las reglas deterministas son adecuadas para casos de alto riesgo o regulados en los que es importante contar con una auditoría completa, mientras que los niveles más flexibles abarcan dominios más amplios y preguntas compuestas novedosas, siempre validados contra una taxonomía controlada. Este patrón también se aplica en otros contextos. Que un asistente financiero pregunte si una transferencia está permitida y qué aprobación se necesita no puede compensar la falta de datos de cuenta, ni tampoco cinco pasajes relevantes de las políticas pueden resolver ese problema; la planificación familiar hace que esas obligaciones sean explícitas.

Midiendo la cobertura

Solo la relevancia de los fragmentos no basta para validar un sistema capaz de entender el contexto familiar. Una métrica simple de recuperación de información familiar revela esa brecha:

Evidence-family recall = covered required families / total required families

# Example: Secret + RBAC covered, ServiceAccount missing
Evidence-family recall = 2/3 = 0.67

# This failure is invisible to standard chunk-relevance metrics

Las suites de pruebas deben incluir la recuperación de familias faltantes, la supervivencia mediante reclasificación y a través de CRAG, fuentes alternativas válidas, fragmentos complementarios de un mismo documento, filtrado por autoridad, un valor top-k inferior al número de familias requeridas, y preguntas que no deben activar ningún plan.

Modos de fallo

• Un planificador que activa de forma demasiado amplia, ya que una palabra clave genérica desencadena un plan no relacionado. Utilizar combinaciones de frases y casos negativos.
• Un plan incompleto, en el que se recuperan las familias declaradas pero aún así no se puede responder a la pregunta. El concepto faltante debe incluirse tanto en el plan como en las pruebas de regresión.
• Cambios de nombre en las fuentes que hacen que la coincidencia mediante expresiones regulares se detenga silenciosamente. Las pruebas de contrato del corpus deben confirmar que las familias planificadas se resuelvan en fuentes reales.

Las consultas de rescate se sobreajustan a las preguntas de evaluación. Redáctalas en torno a conceptos del dominio y verifíquelas mediante paráfrasis y muestras reservadas selladas.

Reservas que protegen pruebas débiles. Obtenga varios candidatos por familia y reordénelos antes de reservar, aplicando aún las verificaciones de autoridad y relevancia mínima.

Demasiadas familias para el presupuesto de contexto, lo que significa que el planificador debe priorizar, fusionar pruebas compatibles o solicitar aclaraciones.

Un modelo que ignora parte de las pruebas. La recuperación completa no garantiza una síntesis total, por lo que los prompts y las verificaciones de fidelidad deben reflejar el plan.

Siguientes mejoras

Varias mejoras merecen realizarse próximamente. Se debe incluir la identidad familiar en los metadatos por versiones en lugar de en los nombres de los archivos. Es necesario crear una taxonomía de evidencias de dominio que indique a los propietarios y las reglas de autoridad. Para preguntas compuestas inusuales, se debe añadir un planificador estructurado con restricciones estrictas, y ajustar por separado la barra de relevancia mínima para cada familia. La selección podría ponderar conjuntamente la relevancia, la cobertura, la redundancia y el presupuesto de tokens. El seguimiento del proceso debe permitir visualizar el plan y el grado de cobertura de la familia. Además de la capacidad de recuperación, hay que medir cuán preciso es el planificador, probar automáticamente la existencia de cambios en el corpus y fuentes con nombres modificados, y comparar los planificadores basados en reglas, clasificadores y LLM en conjuntos de datos aislados. Finalmente, el sistema debe indicar abiertamente cuando no se puede encontrar una familia necesaria.

El objetivo no es complicar la recuperación de información para cada consulta. Se debe invertir esfuerzo adicional solo cuando una pregunta realmente necesita varios tipos de evidencia. Top-k determina qué fragmentos parecen más relevantes, y la recuperación por familias de evidencia plantea una segunda pregunta: ¿el contexto final contiene todo tipo de evidencia necesaria para obtener una respuesta completa? La relevancia indica si un fragmento es útil, la autoridad indica si se puede confiar en él, y el alcance indica si la respuesta puede ser completa. El RAG de producción necesita los tres elementos.