Si alguna vez construiste un pipeline de RAG, conocés la frustración: cargás un PDF en tu base de datos vectorial, lo cortás en chunks de 500 tokens, y cruzás los dedos para que el modelo de embeddings entienda qué chunk responde la pregunta. Muchas veces no lo hace — no porque el LLM sea malo, sino porque el paso de retrieval destruyó la estructura del documento antes de que el LLM pudiera razonar sobre ella.
PageIndex, un framework open source de VectifyAI con más de 29.2K estrellas en GitHub, parte de una observación incómoda: la similitud semántica no es lo mismo que la relevancia.
El problema con el chunking
El RAG tradicional hace dos apuestas: que los documentos se deben cortar en chunks, y que la similitud vectorial va a surfacear los correctos. Para Q&A casual sobre posts de blog, esto funciona. Para documentos profesionales — reportes financieros, contratos legales, especificaciones técnicas — suele colapsar.
Un número en una celda de tabla no significa nada sin su encabezado de columna. Una nota al pie que referencia la Sección 4.2 es inútil si la Sección 4.2 quedó en otro chunk. El pipeline le arranca la estructura jerárquica al documento — la misma que lo hace legible — y después le pide al LLM que razone sobre los retazos.
VectifyAI llama a esto la trampa del “garbage in, garbage out”. PageIndex la evita por completo tirando tanto el chunking como los embeddings.
Cómo funciona PageIndex
En lugar de una base de datos vectorial, PageIndex construye un índice jerárquico en forma de árbol a partir del documento. Pensalo como una tabla de contenidos inteligente: cada nodo tiene un título, un resumen y un rango de páginas. La estructura refleja cómo el documento está realmente organizado — capítulos, secciones, subsecciones, tablas.
Cuando llega una consulta, un LLM lee el árbol y razona sobre qué nodos tienen más probabilidades de contener la respuesta. Puede seguir referencias cruzadas, reconocer cuando una pregunta con múltiples partes requiere buscar en dos secciones distintas, y devolver un trace completo del razonamiento mostrando exactamente qué nodos visitó.
Mingtian Zhang, co-fundador de VectifyAI, lo describe como “AlphaGo para recuperación de documentos” — la misma lógica de tree search que potenció las IAs de juegos ahora navega jerarquías documentales en lugar de estados del tablero. Vale aclarar: algunos reviews señalan que la comparación con AlphaGo es algo exagerada — en la práctica es un LLM razonando sobre un árbol JSON, no Monte Carlo Tree Search con redes de valor entrenadas. Funciona bien independientemente del framing.
La lista de dependencias refleja la simplicidad del enfoque: OpenAI SDK, PyMuPDF, tiktoken. Sin PyTorch, sin FAISS, sin base de datos vectorial. El sistema completo ronda las 2.500 líneas de Python.
El benchmark que hizo levantar cejas
FinanceBench es un benchmark de Q&A financiero sobre reportes SEC y earnings — uno de los problemas de retrieval más difíciles en producción, que requiere razonamiento multi-paso, referencias cruzadas entre secciones, y números exactos.
| Sistema | Precisión en FinanceBench |
|---|---|
| GPT-4o solo | ~31% |
| Perplexity | ~45% |
| RAG vectorial tradicional | ~50–60% |
| PageIndex (Mafin 2.5) | 98.7% |
Esa diferencia de casi 40–50 puntos es suficiente para que cualquier dev trabajando en pipelines de documentos lo tome en serio.
Dónde realmente brilla
PageIndex está diseñado para documentos estructurados y profesionales donde la jerarquía importa:
- Reportes financieros y filings SEC
- Contratos legales y documentación regulatoria
- Manuales técnicos y papers académicos
- Cualquier documento donde una tabla de contenidos existe por alguna razón
El bonus de trazabilidad es real: en lugar de un score de similitud coseno de caja negra, obtenés un trace completo del razonamiento. Para entornos con compliance estricto — finanzas, legal, salud — poder mostrar por qué el sistema recuperó una sección particular no es un nice-to-have: es un requisito.
Dónde los trade-offs son reales
Es importante ser directo sobre los costos:
El indexado es más caro. Construir el árbol requiere llamadas al LLM por documento. Para documentos que solo vas a consultar una o dos veces, el overhead puede no valer la pena.
La latencia es diferente, no necesariamente más lenta. El co-fundador explica que como el retrieval ocurre en línea con la generación (en lugar de como un pre-paso bloqueante), el Time to First Token puede ser comparable a una llamada LLM estándar. Pero el uso total de tokens por consulta es mayor que el retrieval vectorial.
No reemplaza la búsqueda semántica sobre colecciones grandes. Las bases de datos vectoriales siguen ganando para consultas fuzzy a través de miles de documentos. PageIndex es una herramienta de precisión para retrieval profundo dentro de documentos individuales.
Brecha entre cloud y self-hosted. La versión open source usa parseo estándar de PDFs. El servicio cloud agrega OCR mejorado y mejor manejo de layouts complejos. Para documentos con estructura visual pesada — PDFs escaneados, tablas financieras complejas — esto importa.
Cómo empezar
pip install pageindex
El repo incluye un ejemplo de RAG agéntico completo usando el OpenAI Agents SDK, y hay un servidor MCP para integración directa con agentes — compatible con Claude Code o cualquier tool que soporte MCP.
Para equipos que ya tienen pipelines de RAG sobre documentos financieros o legales y están chocando con techos de precisión, PageIndex merece una evaluación seria. Para Q&A de propósito general sobre colecciones mixtas y grandes, tu setup vectorial actual probablemente sigue siendo la decisión correcta.
→ GitHub: VectifyAI/PageIndex
→ Plataforma cloud: pageindex.ai
¿Estás construyendo pipelines de RAG en tu trabajo? ¿Qué tipo de documentos te generan más dolores de cabeza con los enfoques tradicionales?
