Un nuevo marco de código abierto llamado Índice de página resuelve uno de los viejos problemas de la recuperación de generación aumentada (RAG): el manejo de documentos muy largos.
El flujo de trabajo clásico de RAG (fragmentar documentos, calcular incrustaciones, almacenarlos en una base de datos vectorial y recuperar las coincidencias principales según la similitud semántica) funciona bien para tareas básicas como preguntas y respuestas sobre documentos pequeños.
PageIndex abandona por completo el método estándar de “fragmentar e incrustar” y trata la recuperación de documentos no como un problema de búsqueda, sino como un problema de navegación.
Pero a medida que las empresas intentan llevar RAG a flujos de trabajo de alto riesgo (auditar estados financieros, analizar contratos legales, navegar por protocolos farmacéuticos) están chocando con una barrera de precisión que la optimización de fragmentos no puede resolver.
AlphaGo para documentos
PageIndex aborda estas limitaciones tomando prestado un concepto de la IA de los juegos en lugar de los motores de búsqueda: la búsqueda en árbol.
Cuando los seres humanos necesitan encontrar información específica en un libro de texto denso o en un informe anual extenso, no examinan cada párrafo de forma lineal. Consultan el índice para identificar el capítulo relevante, luego la sección y finalmente la página específica. PageIndex obliga al LLM a replicar este comportamiento humano.
En lugar de calcular previamente los vectores, el marco crea un “índice international” de la estructura del documento, creando un árbol donde los nodos representan capítulos, secciones y subsecciones. Cuando llega una consulta, el LLM realiza una búsqueda de árbol, clasificando explícitamente cada nodo como relevante o irrelevante según el contexto completo de la solicitud del usuario.
“En términos de informática, una tabla de contenidos es una representación estructurada en árbol de un documento, y navegar por él corresponde a una búsqueda en árbol”, dijo Zhang. “PageIndex aplica la misma thought central (búsqueda en árbol) a la recuperación de documentos, y puede considerarse como un sistema estilo AlphaGo para recuperación en lugar de juegos”.
Esto cambia el paradigma arquitectónico de la recuperación pasiva, donde el sistema simplemente busca el texto coincidente, a la navegación activa, donde un modelo agente resolve dónde buscar.
Los límites de la similitud semántica
Hay un error elementary en cómo trapo tradicional maneja datos complejos. La recuperación de vectores supone que el texto más semánticamente related a la consulta de un usuario es también el más relevante. En el ámbito profesional, esta suposición frecuentemente fracasa.
Mingtian Zhang, cofundador de PageIndex, señala los informes financieros como un excelente ejemplo de este modo de fracaso. Si un analista financiero le pregunta a una IA sobre el “EBITDA” (ganancias antes de intereses, impuestos, depreciación y amortización), una base de datos vectorial estándar recuperará cada fragmento donde aparezca ese acrónimo o un término related.
“Varias secciones pueden mencionar el EBITDA con una redacción related, pero solo una sección outline el cálculo preciso, los ajustes o el alcance de los informes relevantes para la pregunta”, dijo Zhang a VentureBeat. “Un perro perdiguero basado en similitudes lucha por distinguir estos casos porque las señales semánticas son casi indistinguibles”.
Ésta es la brecha entre “intención y contenido”. El usuario no quiere encontrar la palabra “EBITDA”; quieren entender la “lógica” detrás de esto para ese trimestre específico.
Además, las incorporaciones tradicionales despojan a la consulta de su contexto. Debido a que los modelos de incrustación tienen límites estrictos de longitud de entrada, el sistema de recuperación generalmente solo ve la pregunta específica que se hace, ignorando los giros anteriores de la conversación. Esto separa el paso de recuperación del proceso de razonamiento del usuario. El sistema compara los documentos con una consulta breve y descontextualizada en lugar del historial completo del problema que el usuario está intentando resolver.
Resolviendo el problema de razonamiento de múltiples saltos
El impacto en el mundo actual de este enfoque estructural es más seen en consultas de “saltos múltiples” que requieren que la IA siga un rastro de rutas de navegación en diferentes partes de un documento.
En una prueba comparativa reciente conocida como FinanceBench, un sistema construido sobre PageIndex llamado “Mafin 2.5” logró una puntuación de precisión de última generación del 98,7 %. La brecha de rendimiento entre este enfoque y los sistemas basados en vectores se vuelve clara al analizar cómo manejan las referencias internas.
Zhang ofrece el ejemplo de una consulta sobre el valor complete de los activos diferidos en un informe anual de la Reserva Federal. La sección principal del informe describe el “cambio” en el valor pero no enumera el complete. Sin embargo, el texto contiene una nota a pie de página: “Consulte el Apéndice G de este informe… para obtener información más detallada”.
Un sistema basado en vectores normalmente falla aquí. El texto del Apéndice G no se parece en nada a la consulta del usuario sobre activos diferidos; probablemente sea solo una tabla de números. Como no existe una coincidencia semántica, la base de datos vectorial la ignora.
Sin embargo, el recuperador basado en el razonamiento lee la pista en el texto principal, sigue el enlace estructural al Apéndice G, localiza la tabla correcta y devuelve la cifra exacta.
La compensación entre latencia y cambio de infraestructura
Para los arquitectos empresariales, la preocupación inmediata con un proceso de búsqueda basado en LLM es la latencia. Las búsquedas de vectores ocurren en milisegundos; hacer que un LLM “lea” una tabla de contenido implica una experiencia de usuario significativamente más lenta.
Sin embargo, Zhang explica que la latencia percibida por el usuario closing puede ser insignificante debido a cómo se integra la recuperación en el proceso de generación. En una configuración RAG clásica, la recuperación es un paso de bloqueo: el sistema debe buscar en la base de datos antes de poder comenzar a generar una respuesta. Con PageIndex, la recuperación ocurre en línea, durante el proceso de razonamiento del modelo.
“El sistema puede comenzar a transmitir inmediatamente y recuperarlo a medida que se genera”, dijo Zhang. “Eso significa que PageIndex no agrega una ‘puerta de recuperación’ adicional antes del primer token, y el tiempo hasta el primer token (TTFT) es comparable a una llamada de LLM regular”.
Este cambio arquitectónico también simplifica la infraestructura de datos. Al eliminar la dependencia de las incorporaciones, las empresas ya no necesitan mantener una base de datos vectorial dedicada. El índice estructurado en árbol es lo suficientemente liviano como para ubicarse en una base de datos relacional tradicional como PostgreSQL.
Esto aborda un problema creciente en los sistemas LLM con componentes de recuperación: la complejidad de mantener los almacenes de vectores sincronizados con los documentos vivos. PageIndex separa la indexación de estructuras de la extracción de texto. Si se modifica un contrato o se actualiza una política, el sistema puede manejar pequeñas ediciones reindexando solo el subárbol afectado en lugar de reprocesar todo el corpus del documento.
Una matriz de decisión para la empresa.
Si bien las ganancias en precisión son convincentes, la recuperación mediante búsqueda de árboles no es un reemplazo common para la búsqueda de vectores. Es mejor ver la tecnología como una herramienta especializada para el “trabajo profundo” en lugar de como un comodín para cada tarea de recuperación.
Para documentos cortos, como correos electrónicos o registros de chat, el contexto completo a menudo cabe dentro de la ventana contextual de un LLM moderno, lo que hace innecesario cualquier sistema de recuperación. Por el contrario, para tareas basadas puramente en el descubrimiento semántico, como recomendar productos similares o encontrar contenido con una “ambiente” related, las incrustaciones de vectores siguen siendo la opción superior porque el objetivo es la proximidad, no el razonamiento.
PageIndex encaja perfectamente en el medio: documentos largos y muy estructurados donde el coste del error es alto. Esto incluye manuales técnicos, presentaciones de la FDA y acuerdos de fusión. En estos escenarios, el requisito es la auditabilidad. Un sistema empresarial necesita ser capaz de explicar no sólo la respuesta, sino también el camino que tomó para encontrarla (por ejemplo, confirmando que revisó la Sección 4.1, siguió la referencia al Apéndice B y sintetizó los datos allí encontrados).
El futuro de la recuperación agente
El auge de marcos como PageIndex señala una tendencia más amplia en la pila de IA: el movimiento hacia “RAG agente.” A medida que los modelos se vuelven más capaces de planificar y razonar, la responsabilidad de encontrar datos se está trasladando de la capa de la base de datos a la capa del modelo.
Ya estamos viendo esto en el espacio de la codificación, donde agentes como Código Claude y Cursor se están alejando de las simples búsquedas de vectores en favor de la exploración activa de la base de código. Zhang cree que la recuperación de documentos genéricos seguirá la misma trayectoria.
“Las bases de datos vectoriales todavía tienen casos de uso adecuados”, afirmó Zhang. “Pero su papel histórico como base de datos predeterminada para los LLM y la IA se volverá menos claro con el tiempo”.
