PageIndex en RAG: reemplazo para la búsqueda vectorial

PageIndex como alternativa a la búsqueda vectorial en RAG: análisis y configuración local

PageIndex propone reemplazar la búsqueda vectorial en RAG con una estructura jerárquica de documentos. El documento se segmenta en páginas, y un LLM construye un árbol de contenido con resúmenes de nodos. Las consultas de búsqueda se dirigen al LLM para seleccionar nodos relevantes, seguidos de páginas extraídas como contexto. No se requieren fragmentación, incrustaciones o bases de datos vectoriales.

Limitaciones de escalabilidad

PageIndex está optimizado para documentos individuales. Para colecciones, se sugieren las siguientes opciones:

• Filtrado por metadatos (en desarrollo, similar a almacenes vectoriales).
• Búsqueda mediante descripciones generadas (para volúmenes pequeños).
• Búsqueda semántica (recurre a incrustaciones vectoriales).

El índice con resúmenes comprime el contexto entre 4 y 5 veces. Alternativas como TF-IDF o BM25 requieren indexación. Almacenar el índice para miles de documentos sigue sin resolverse. Aquí, el LLM reemplaza la búsqueda por similitud con búsqueda por relevancia, similar a navegar por texto complejo mediante una tabla de contenidos.

Se afirma una precisión del 98,7% en FinanceBench (frente a ~90% para búsqueda vectorial), lograda mediante razonamiento. El costo es decenas de veces mayor. Probado en gpt-4o y gpt-5.4.

Experimentos con modelos locales

Probado en un artículo académico sobre Cyberpunk 2077 (PDF, ~17k tokens). La canalización de Markdown es similar a MarkdownTextSplitter de LangChain—división por encabezados.

La canalización de PDF extrae encabezados automáticamente, pero con problemas:

• Errores en la salida JSON—procesamiento de texto (eliminación de bibliografías, citas).
• Umbral de precisión del 60%—reducido mediante la variable de entorno ACCURACY_THRESHOLD.
• Baja precisión debido a que el LLM empareja nodos y fragmentos—aumentado MAX_TOKENS de 20k.

Modelos:

• gemma3:27b—alucina el índice (precisión <60%).
• gpt-oss:20b—precisión 57–63%, estable.
• qwen3:14b—precisión 69,57%, pero con errores JSON.

Tiempo en GPU de 16GB: ~30 min (la corrección de errores domina).

Ejemplo de índice (gpt-oss:20b, precisión 0,63):

{
  "doc_name": "2077.pdf",
  "structure": [
    {
      "title": "Introducción",
      "node_id": "0000",
      "start_index": 1,
      "end_index": 3,
      "summary": "El artículo examina cómo el videojuego Cyberpunk 20...",
      "text": "Una perspectiva de Cyberpunk 2077 sobre la predicción y..."
    },
    {
      "title": "Revisión de literatura",
      "node_id": "0001",
      "start_index": 3,
      "end_index": 3,
      "summary": "El documento parcial presenta una revisión de literatura ...",
      "text": "contextualizando Cyberpunk 2077 dentro del marco más amplio ...",
      "nodes": [
        // ... subnodos
      ]
    }
    // ... nodos restantes
  ]
}

Configuración y puesta en marcha local

Instalación: liteLLM==1.82.0 (versiones más recientes son vulnerables). No usar pip install pageindex—eso es para la API.

Cuadernos: MinimalPageindexLocalPDF.ipynb, MinimalPageindexLocalMD.ipynb.

Modificaciones en utils.py: OLLAMA_HOST, OLLAMA_TIMEOUT.

page_index.py: ACCURACY_THRESHOLD, MAX_TOKENS.

Proceso:

• Cargar documento (PDF/MD).
• LLM construye el índice (find_toc_pages).
• Segmentación en páginas/líneas.
• Construcción del árbol de nodos con resúmenes.
• Corrección de precisión.
• Búsqueda: LLM selecciona nodos por consulta → extracción de página → RAG final.

PageIndex integra LLM en la recuperación para búsqueda rastreable con referencias de página/sección. Adecuado para documentos complejos, pero intensivo en recursos para producción.

Conclusiones clave

• Escalabilidad: Sin solución lista para colecciones grandes sin búsqueda vectorial.
• Precisión: Dependiente del modelo; local (qwen3:14b) alcanza 69% pero con errores.
• Costo: +8–9% de precisión por x10–xN recursos comparado con RAG vectorial.
• Formatos: PDF con detección automática de encabezados; MD mediante estructura markdown.
• Modificaciones: Variables de entorno necesarias para umbrales y tokens en hardware débil.

— Editorial Team