¿El RAG recupera información desactualizada sin saberlo? Cómo gestionar la frescura del índice

Los tutoriales de RAG muestran cómo indexar documentos, generar embeddings y hacer búsqueda semántica. Casi ninguno menciona lo que ocurre cuando los documentos indexados cambian. La respuesta corta: nada. El vector store no lo sabe.

Un vector store almacena representaciones numéricas (embeddings) de fragmentos de texto. No tiene campos de fecha de expiración, no monitoriza cambios en los documentos fuente, no distingue entre un chunk indexado ayer y uno indexado hace tres años. Cuando llega una query, recupera los chunks semánticamente más similares — sin importar cuándo fueron indexados ni si el contenido sigue siendo válido.

Un vector store es, en esencia, una base de datos optimizada para búsqueda por similitud coseno o producto punto en espacios de alta dimensión. Las bases de datos no tienen opinión sobre la frescura de los datos que almacenan — eso es responsabilidad de quien las opera. Un vector store tampoco.

Algunos vector stores (como Pinecone, Weaviate o Qdrant) soportan metadatos por chunk, incluyendo campos de fecha. Puedes usarlos para añadir filtros en la búsqueda ("recupera solo chunks indexados en los últimos 30 días") o para detectar chunks potencialmente obsoletos. Pero esto requiere instrumentar el pipeline de indexación expresamente para ello — no ocurre de forma automática.

from datetime import datetime

docs_with_metadata = [
    Document(
        page_content=chunk,
        metadata={
            "source": "api-docs-v2.md",
            "indexed_at": datetime.utcnow().isoformat(),
            "version": "2.1"
        }
    )
    for chunk in chunks
]

vectorstore.add_documents(docs_with_metadata)

CRAG (Corrective RAG) añade un paso de evaluación al pipeline estándar: antes de generar la respuesta, el sistema evalúa la confianza de los chunks recuperados. Si la confianza es baja (los chunks no parecen suficientemente relevantes), cae hacia una búsqueda web o una fuente externa más actualizada. Si es alta, procede con el RAG estándar.

Self-RAG va un paso más allá: el modelo genera la respuesta y luego se autocritica. Decide si la respuesta generada es suficientemente buena o si necesita re-recuperar información adicional antes de responder al usuario. Es un bucle de refinamiento automático.

Ambos patrones añaden latencia y coste. Para documentación estable (políticas de empresa, manuales técnicos con versiones controladas), el RAG naive con reindexado programado es suficiente. CRAG y Self-RAG tienen sentido cuando los datos cambian con frecuencia impredecible o cuando las consecuencias de responder con información desactualizada son significativas.