El lanzamiento reciente de PageIndex es parte de un cambio más amplio en la arquitectura de la IA hacia el “RAG sin vector” o la “recuperación basada en el razonamiento”. En lugar del método estándar de dividir documentos en fragmentos aleatorios y buscar mediante similitud matemática, PageIndex crea una "Tabla de contenido inteligente" (un árbol jerárquico) que permite a los LLM navegar por los documentos como lo haría un experto humano. Numerosos blogs (incluido este de Microsoft) describen los principios de funcionamiento (sin base de datos vectorial, sin fragmentación, explicabilidad mejorada) junto con una precisión del 98,7% lograda en un punto de referencia financiero. Sin embargo, también tienen cuidado en señalar que Vectorless RAG es más adecuado para consultas profundas sobre documentos estructurados o semiestructurados complejos (como estados financieros), que para buscar en muchos documentos independientes, como bases de conocimiento de atención al cliente, donde deberíamos seguir usando Vector RAG.
¿Porqué es eso?
Si Vectorless RAG usando PageIndex proporciona mejores (o al menos igual de buenos) resultados en casi cualquier consulta, ¿por qué no usarlo para una gran colección de documentos? La razón principal es que el enfoque basado en árboles de PageIndex no puede escalarse prácticamente a escenarios de múltiples documentos. El índice de árbol jerárquico que es un paso de ingesta previo es lento y costoso de construir mediante un LLM. Además, la recuperación es un proceso de 2 pasos: use un LLM para recorrer el árbol, ubique los nodos más relevantes y luego use el contenido de esos nodos como contexto para el paso de síntesis de respuesta usando el LLM.
En comparación, construir un índice vectorial es rápido y económico, y el paso de recuperación utiliza un LLM solo una vez durante el paso de síntesis. Además, la ingestión utilizando un modelo de integración cuesta mucho menos que el resumen del documento completo por parte de un LLM.
¿Qué pasaría si pudiera obtener la excelente precisión del razonamiento estructural de Vectorless RAG, junto con la baja latencia y el precio de un Vector RAG, de una manera que sea escalable en toda la base de datos empresarial? En este artículo, analizaré un caso de uso real en un documento grande y complejo para construir Proxy-Pointer RAG, una canalización de ingesta y recuperación que logra esto a través de un conjunto de novedosos pasos de ingeniería. A lo largo del camino, exploraremos y demostraremos lo siguiente:
¿Por qué exactamente PageIndex es tan preciso? Y por qué es difícil escalar prácticamente el concepto a bases de conocimiento de múltiples documentos. Una comparación rápida de Vectorless RAG usando PageIndex vs Flat Vector RAG para establecer una línea de base. ¿Cómo podemos incorporar los principios de PageIndex en un índice vectorial sin la latencia ni el costo asociados? Comparación de una amplia variedad de consultas utilizando PageIndex y Proxy-Pointer para probar la calidad de las recuperaciones.
Configuración de casos de uso
Utilizaremos un informe del Banco Mundial llamado Actualización sobre el desarrollo de Asia Meridional, abril de 2024: Empleos para la resiliencia (Licencia: CC BY 3.0 IGO). Este es un informe de 131 páginas que comprende varios capítulos, gráficos complejos, tablas, contenido en cuadros, etc. y es un buen candidato para que PageIndex demuestre su capacidad. He usado gemini-3-flash como LLM para construir el árbol de índice de páginas y gemini-3.1-flash-lite para recuperaciones. Extraje el informe pdf a un archivo de rebajas usando la API de extracción de PDF de Adobe, pero cualquier otro método, como usar un VLM que preserve la integridad de las tablas, gráficos, etc., funcionaría igual de bien. Para la base de datos vectorial, se utiliza FAISS.
¿Cómo funciona PageIndex?
En lugar de “fragmentar su documento, incrustar los fragmentos, recuperar los K superiores, alimentarlos a un LLM” de un Vector RAG, PageIndex adopta un enfoque radicalmente diferente para la recuperación de documentos. En lugar de tratar un documento como una secuencia plana de fragmentos, crea un árbol semántico (un mapa jerárquico de cada sección, subsección y bloque de contenido del documento) y luego utiliza un LLM para navegar por ese árbol en el momento de la consulta.
Fase 1: Indexación (una vez por documento)
PageIndex analiza la estructura de encabezados del documento (encabezados de Markdown, esquemas de PDF, etc.) en un árbol anidado. Cada nodo obtiene:
Un título (extraído del encabezado) Un ID de nodo (identificador único como 0012) Límites de línea (línea inicial y final en el documento fuente) Un resumen (generado por un LLM; esta es la parte costosa y que requiere mucho tiempo)
El resultado es un JSON similar a este:
{ "node_id": "0011", "title": "Capítulo 1. Fuerza engañosa", "summary": "Abarca las perspectivas de crecimiento del sur de Asia, las tendencias de inflación, las vulnerabilidades financieras, los riesgos climáticos y los desafíos políticos…", "line_num": 621, "nodes": [ { "node_id": "0012", "title": "Introducción", "summary": "Resume los temas clave del capítulo, incluido el crecimiento regional impulsado por la India…", "line_num": 625 }, … ] }
Fase 2: Recuperación (Por Consulta)
Cuando un usuario hace una pregunta, PageIndex entrega el árbol completo de resúmenes a un LLM y dice: "¿Qué nodos contienen la respuesta?". Esto es diferente a un Vector RAG que se basa en la similitud matemática entre la consulta y las incrustaciones de fragmentos para construir el contexto relevante.
El LLM lee los resúmenes (no el texto completo) y devuelve una breve lista de ID de nodos. Luego, PageIndex usa los límites de las líneas para dividir la sección completa, contigua y exacta del archivo de rebajas original y la pasa al LLM de síntesis.
¿Por qué esto funciona tan bien?
PageIndex destaca por tres ventajas arquitectónicas:
1. Navegación estructural, no coincidencia de patrones
Cuando preguntamos "¿Cuáles son los mensajes principales del Capítulo 1?", PageIndex no busca fragmentos que contengan esas palabras. Lee el resumen del nodo 0011 (“Capítulo 1. Fuerza engañosa”) que dice “Cubre perspectivas de crecimiento, inflación, vulnerabilidades financieras, riesgos climáticos y desafíos políticos”, e inmediatamente sabe que este es el nodo correcto. Razona sobre relevancia, no sobre similitud semántica y léxica.
2. Extracción de contexto contiguo
Una vez que se identifican los nodos correctos, PageIndex extrae la sección completa e ininterrumpida que representa el nodo, del Markdown original: encabezados, subtítulos, viñetas, referencias de figuras y todo. El LLM de síntesis recibe un contexto que se lee como una sección de documento escrita correctamente, no como un fragmento fragmentado con límites arbitrarios.
3. Artefactos de límite de fragmento cero
No hay fragmentos superpuestos, ni oraciones divididas, ni ventanas de contexto que comiencen a mitad del párrafo. Cada parte del contexto tiene un comienzo natural (el encabezado de la sección) y un final natural (el inicio de la siguiente sección). Esto reduce drásticamente las alucinaciones provenientes de un contexto ambiguo.
Sin embargo, esta fortaleza tiene un costo, y aquí es donde el enfoque comienza a fallar.
¿Por qué esto es difícil de escalar?
Los motivos son el costo y la latencia (ingestión y tiempo de recuperación). Para nuestro informe de 131 páginas, obtenemos 137 nodos estructurales en el árbol y, por lo tanto, PageIndex necesita 137 llamadas de LLM solo para la fase de indexación: un resumen por nodo. Para un corpus de 50 documentos, son aproximadamente 7000 llamadas de LLM antes de que lo hayamos utilizado para responder una sola pregunta.
Aquí hay un costo comparativo de PageIndex vs Vector Index:
Para un único documento crítico, como un informe financiero, este costo se justifica fácilmente. ¿Busca una base de conocimientos empresariales de 500 documentos sobre SOP de servicio al cliente que se actualice semanalmente? Es imposible.
Aquí es donde PageIndex comienza a volverse poco práctico para sistemas reales a escala.
Antes de proponer una alternativa, establezcamos una línea de base: ¿cuánto mejor es PageIndex en comparación con el Vector RAG estándar?
Comparación de RAG sin vector y con vector plano
Para establecer una línea de base, comparé los resultados de una amplia gama de consultas utilizando Vector RAG plano y sin vector. Como era de esperar, la calidad de Vectorless RAG fue mejor en todos los casos. Aquí hay dos ejemplos:
Consulta sobre el contenido de la tabla.
Aquí está la respuesta de Vectorless RAG:
=== INTERACCIÓN DE RAG SIN VECTORES === Pregunta: ¿qué dice la tabla del anexo a2.1.1? Nodos recuperados: 0125, 0131 Respuesta: La tabla del anexo A2.1.1, titulada "Estudios incluidos en la revisión de la literatura", proporciona una lista completa de los artículos académicos y de políticas utilizados para estimar la elasticidad del crecimiento del empleo (Figura del anexo A2.1.1; Anexo 2.1). La tabla cataloga 25 estudios específicos, detallando la siguiente información para cada uno: * **Artículo:** El(los) autor(es) y la fuente de publicación. * **Período de la muestra principal:** El período cubierto por el estudio (desde la década de 1960 hasta 2019). * **Cobertura de muestra:** El alcance geográfico u organizativo (p. ej., mundial, Europa, sur de Asia, África, Asia). * **Región:** La región específica analizada. * **Economías:** Los países específicos incluidos en la muestra del estudio. Según el texto proporcionado, los artículos enumerados en esta tabla se seleccionaron en función de criterios específicos: se centran en la elasticidad del crecimiento del empleo utilizando estimaciones a nivel de país. La selección excluye artículos que presentan estimaciones exclusivamente subnacionales, específicas de género o de industria/sector, así como aquellos centrados únicamente en la ley de Okun y la elasticidad del crecimiento del desempleo (Anexo 2.1).
Y lo mismo usando Vector RAG, que pierde por completo el contenido.
=== INTERACCIÓN VECTOR RAG === Pregunta: ¿qué dice la tabla del anexo a2.1.1? Recuperados 5 fragmentos. Respuesta: Según el contexto proporcionado, no hay información disponible que describa el contenido de una tabla denominada "A2.1.1". Los documentos enumeran "A2.1.1" en el índice como **"Estudios incluidos en la revisión de la literatura"** (página 93). Sin embargo, el contenido detallado proporcionado en los resultados de su búsqueda pertenece a otras tablas, específicamente: * **Anexo 2.1:** Describe un resumen de la literatura sobre la elasticidad del crecimiento del empleo, señalando que "se realizó una búsqueda bibliográfica extensa de estudios sobre la elasticidad del empleo con respecto al crecimiento de la producción". * **Figura A2.1.1 del anexo (referida como A2..1.11.1 en el texto):** Titulada "Estimaciones de la elasticidad de la producción del empleo", que dice: "La literatura proporciona una amplia gama de estimaciones sobre la elasticidad del crecimiento del empleo total". * **Cuadro del anexo A2.3.3:** Proporciona datos de regresión específicos sobre las pruebas de solidez para la tasa de empleo femenino. No se proporcionan datos ni contenidos específicos para el cuadro del anexo A2.1.1 más allá de su título en el índice.
Consulta que requiere conocimiento estructural del documento.
La pregunta es ¿cuáles son las preguntas que responde el capítulo 2? Aquí está la respuesta de Vectorless RAG. Localizó con precisión el Capítulo 2 y la sección de “Preguntas” dentro de él y lo publicó palabra por palabra, junto con la información fundamentada para la explicabilidad.
=== INTERACCIÓN DE TRAPO SIN VECTORES === Pregunta: ¿Cuáles son las preguntas que responde el capítulo 2? Nodos Recuperado: 0098 Respuesta: Con base en los extractos proporcionados, el Capítulo 2 aborda las siguientes preguntas: * **¿Cómo se compara el empleo de Asia Meridional con el de otras economías de mercados emergentes y en desarrollo (EMDE)?** * **¿Cuáles son las correlaciones de las tasas de empleo a largo plazo entre las EMED?** * **¿Cómo puede Asia Meridional crear los empleos necesarios para absorber su ¿Crece la población en edad de trabajar y al mismo tiempo aumenta la productividad?** Estas preguntas se enumeran explícitamente en la sección titulada **"Preguntas".**
Los fragmentos en Vector RAG no mantienen la jerarquía estructural ni la integridad de la sección, por lo que, aunque localiza la sección "Preguntas", no puede encontrar las preguntas específicas que contiene.
=== INTERACCIÓN VECTOR RAG === Pregunta: ¿cuáles son las preguntas respondidas en el capítulo 2? Obtuve 5 fragmentos. Respuesta: Con base en el documento proporcionado, el Capítulo 2, titulado "Desarrollo del desempleo", está estructurado para abordar preguntas específicas sobre los mercados laborales y el crecimiento económico. El capítulo identifica explícitamente una sección de "Preguntas" (página 65) para enmarcar su análisis. Si bien el documento no enumera el texto específico de estas preguntas, indica que el capítulo cubre las siguientes áreas temáticas y componentes analíticos: * **Tendencias y productividad:** El capítulo examina las "Tendencias en el empleo y la productividad laboral" (página 67) y aborda el "Crecimiento de la productividad laboral" (página 73). * **Ratios de empleo:** Una parte importante del capítulo está dedicada a los "Ratios de empleo a largo plazo" (página 75) y sus diversos "correlaciones", entre ellos: * **Factores estructurales y de política:** Regímenes fiscales, incertidumbre política (página 77) y apertura comercial (página 79). * **Factores financieros y de mercado:** Acceso a financiación (página 81), así como a mercados de productos, trabajo y tierras (página 82). * **Capital humano y características de la empresa:** Educación (página 83) y tamaño del establecimiento (página 78). * **Dinámica del crecimiento:** El capítulo explora los "Motores del crecimiento de la producción en las EMED" (página 73) y la "Composición sectorial del empleo" (página 72). * **Implicaciones de política:** La investigación concluye abordando las "Opciones de política para impulsar el empleo" (página 85).
Entonces la pregunta es: ¿podemos conservar estas ventajas sin pagar el costo?
Diseñando un mejor perro perdiguero: Proxy-Pointer RAG
Construyamos Proxy-Pointer RAG para responder esa pregunta. La idea central es intuitiva y es la siguiente:
No necesita resúmenes de LLM para brindarle a una base de datos vectorial conocimiento estructural. Sólo necesitas codificar la estructura en las propias incrustaciones.
El sistema utiliza el mismo árbol estructural que utiliza PageIndex, pero sin el costoso conjunto de indicadores de resumen. La construcción de este árbol esquelético no requiere costosas llamadas de LLM durante la indexación. El árbol se construye exclusivamente a partir de la detección de encabezados basada en expresiones regulares, que se ejecuta en milisegundos.
Luego, en lugar de pedirle a un LLM que navegue por el árbol, dejamos que FAISS haga la recuperación, pero diseñamos los fragmentos para que FAISS "entienda" dónde se encuentra cada fragmento en la jerarquía del documento.
A continuación se muestra una vista del proceso de ingesta:
construir un árbol esqueleto
El analizador de árboles de PageIndex en realidad no necesita un LLM para construir la jerarquía estructural. La detección de encabezados se basa en expresiones regulares: encuentra encabezados de Markdown (#, ##, ###) y crea el anidamiento a partir de niveles de sangría. El LLM solo se utiliza para resumir cada nodo.
A la versión gratuita de LLM la llamamos Árbol esqueleto: la misma estructura, los mismos ID de nodo, los mismos límites de línea, pero sin resúmenes.
# Construir un árbol esqueleto: sin LLM, se ejecuta en milisegundos pageindex = PageIndex(doc_path, enable_ai=False) tree = pageindex.build_structure() # Análisis puro de expresiones regulares
El árbol esqueleto y el árbol resumido producido para el anterior Vectorless RAG producen estructuras idénticas: los mismos 137 nodos, las mismas profundidades de anidamiento, los mismos números de línea, los mismos títulos. La única diferencia es el campo de resumen que falta.
Costo: $0. Tiempo: < 1 segundo.
Punteros de metadatos estructurales (el diferenciador central)
Ésta es la razón por la que PageIndex funciona tan bien y el truco que adoptaremos.
En el RAG vectorial estándar, un fragmento recuperado es el contexto. Cualesquiera que sean las 500 palabras que devuelva FAISS, eso es lo que ve el LLM. Si el fragmento comienza a mitad de la oración o termina antes del punto de datos clave, la respuesta perderá por completo la intención de la consulta (como se ilustra en la sección anterior sobre la comparación entre Vectorless y Vector RAG).
PageIndex hace algo fundamentalmente diferente: el fragmento nunca es el contexto. Cada nodo del árbol conoce su posición exacta en el documento original: su título, su ID de nodo y, lo que es más importante, los números de línea inicial y final de toda la sección que representa. Cuando la recuperación selecciona un nodo, PageIndex vuelve al archivo Markdown original y corta la sección completa y contigua entre esos límites de línea.
Replicamos esto exactamente. Cada fragmento que incorporamos en el índice vectorial contiene metadatos estructurales enriquecidos del nodo del árbol:
metadata = { "doc_id": "SADU", # Qué documento "node_id": "0012", # Qué nodo estructural "title": "Introducción", # Encabezado de sección "start_line": 624, # Dónde comienza la sección en el archivo original "end_line": 672 # Dónde termina la sección }
En el momento de la recuperación, no enviamos los fragmentos coincidentes al LLM. En cambio, nosotros:
Utilice los fragmentos como servidores proxy: solo están ahí para identificar qué nodos son relevantes. Elimine combinaciones duplicadas (doc_id, node_id) para obtener un top-k único. Siga los punteros de metadatos: abra el Markdown original, corte líneas de nodos, por ejemplo, 624 a 672. Entregue las secciones completas: el LLM recibe el texto completo, prístino y estructuralmente intacto.
A continuación se muestra una vista del proceso de recuperación:
Esto significa que incluso si un fragmento solo coincide en una sola oración dentro de una sección, el LLM de síntesis obtiene la sección completa, con su encabezado, su contexto, sus figuras y sus conclusiones. El trozo era desechable; el puntero es lo que importa.
Por eso lo llamo Proxy-Pointer RAG: los vectores son sustitutos de la ubicación, los metadatos son punteros al contenido real.
Costo: $0. Impacto: transforma la calidad del contexto de fragmentos fragmentados a secciones completas del documento.
Inyección de ruta de navegación (contexto estructural)
Esto es clave para responder las consultas relacionadas con una sección específica del documento (como el Capítulo 2). RAG vectorial estándar incorpora texto sin formato:
"Si bien el crecimiento de la inversión privada se ha desacelerado tanto en el sur de Asia como en otras EMED…"
FAISS no tiene idea de que esta parte proviene del Capítulo 1, bajo Actividad Económica, dentro del Cuadro 1.1. Entonces, cuando el usuario pregunta "mensajes principales del Capítulo 1", este fragmento no tendrá una clasificación alta: no contiene las palabras "Capítulo 1" o "mensajes principales".
La inyección de ruta de navegación antepone la ruta de ascendencia completa desde el árbol esqueleto a cada fragmento antes de incrustarlo:
"[Capítulo 1. Fuerza engañosa > Actividad económica > Evolución regional > RECUADRO 1.1 Aceleración de la inversión privada] Si bien el crecimiento de la inversión privada se ha desacelerado tanto en el sur de Asia como en otras EMED…"
Ahora el vector de incrustación codifica tanto el contenido como su ubicación estructural. Cuando alguien pregunta sobre el “Capítulo 1”, FAISS sabe qué fragmentos pertenecen al Capítulo 1, porque las palabras “Capítulo 1. Fuerza engañosa” están presentes en la incrustación.
# Construir ruta de navegación desde ascendencia current_crumb = f"{parent_breadcrumb} > {node_title}" # Anteponer al fragmento de texto antes de incrustar enriched_text = f"[{current_crumb}]n{section_text}" fragmentos = text_splitter.split_text(enriched_text)
Se trata de una codificación de coste cero de la estructura de árbol en el espacio vectorial. Estamos usando la misma API de incrustaciones, el mismo índice FAISS, el mismo código de recuperación. La única diferencia es lo que introducimos en el incrustador.
Costo: $0 adicionales. Impacto: transforma la calidad de recuperación de consultas estructurales.
Fragmentación guiada por estructura (sin ventanas corredizas ciegas)
El vector RAG estándar aplica una ventana deslizante en todo el documento: una ventana de 2000 caracteres que avanza con cierta superposición, completamente ajena a la estructura del documento. Un fragmento puede comenzar a mitad de un párrafo en la Introducción y terminar a mitad de una oración en el título de una Figura. Los límites son arbitrarios y cada fragmento es una isla en sí mismo, sin conocimiento de su posición en la estructura general del documento.
Proxy-Pointer hace algo fundamentalmente diferente: recorremos el árbol, no el texto.
Para cada nodo en el árbol esqueleto, extraemos solo el texto de su propia sección (desde start_line hasta end_line) y luego aplicamos el divisor de texto a esa sección aislada. Si una sección es lo suficientemente corta, se convierte en un solo fragmento. Si es más largo, el divisor lo divide, pero estrictamente dentro de los límites de esa sección.
RAG estándar: ventana deslizante ciega en todo el documento [====fragmento1====][====fragmento2====][====fragmento3====]… ↑ puede comenzar en Introducción, terminar en el título de la figura Puntero proxy: fragmento dentro de los límites de cada nodo Introducción (líneas 624-672) → [fragmento A] [fragmento B] Actividad económica (líneas 672-676) → [fragmento C] RECUADRO 1.1 (líneas 746-749) → omitido (< 100 caracteres) Inflación (líneas 938-941) → [fragmento D]
Esto garantiza tres cosas:
Los fragmentos nunca cruzan los límites de las secciones: un fragmento de la Introducción nunca se superpondrá con la Actividad económica. Cada fragmento pertenece exactamente a un nodo, por lo que los metadatos node_id siempre son precisos. Las rutas de navegación son precisas por fragmento: reflejan el contenedor estructural real, no una suposición.
Es importante destacar que cuando se omite un nodo (porque su texto es demasiado corto, por ejemplo, un encabezado "BOX 1.1" sin contenido corporal), el recorrido del árbol aún se repite en sus hijos. El contenido real reside en nodos secundarios como “Introducción”, “Características” y “Figuras”, todos los cuales se incrustan con el título del padre en su ruta de navegación (por ejemplo: RECUADRO 1.1 Aceleración de la inversión privada > Introducción, RECUADRO 1.1 > Características de…). Nunca se pierde ningún contenido; sólo se excluyen los encabezados estructurales vacíos.
Costo: $0. Impacto: Cada fragmento es estructuralmente rastreable, lo que permite indicadores de metadatos precisos.
Filtrado de ruido (eliminación de distracciones)
Algunas secciones de cualquier documento son irrelevantes para las recuperaciones y contaminan el contexto: contienen palabras clave que coinciden con casi todas las consultas pero no proporcionan contenido útil.
Tabla de contenido: menciona el título de cada capítulo (coincide con “Capítulo 1”, “Capítulo 2”, todo) Resumen ejecutivo: parafrasea cada hallazgo clave (coincide con cada consulta temática) Abreviaturas: enumera todos los acrónimos utilizados en el documento Agradecimientos: menciona organizaciones, países y temas
Estas secciones actúan como distracciones en el espacio vectorial. Se ubican cerca del centroide de la distribución de incrustación del documento, lo que lleva la recuperación hacia un texto de descripción general superficial en lugar de un contenido analítico profundo.
Aplicamos un filtro simple basado en títulos durante la indexación:
NOISE_TITLES = { "contenido", "resumen de contenido", "tabla de contenido", "abreviaturas", "agradecimientos", "prólogo", "resumen ejecutivo", "referencias" } si title.strip().lower() en NOISE_TITLES: continuar # Omitir este nodo por completo
Este filtro eliminó 7 nodos de nuestro documento de prueba. El impacto fue inmediato: para la consulta “¿Cuáles son los mensajes principales del Capítulo 1?”, el sistema dejó de recuperar el Resumen ejecutivo y el índice y comenzó a recuperar la sección de Introducción real.
Costo: $0. Impacto: Elimina el modo de error de recuperación más común.
Eso es todo. Proxy-Pointer RAG ya está listo para realizar la prueba.
Probar canalización de puntero proxy
Si bien se menciona una comparación detallada en la siguiente sección, aquí están los resultados de las mismas dos consultas que se citaron en la sección "RAG sin vector versus vector plano". Como puede comparar, las respuestas son tan precisas y detalladas como Vectorless RAG usando PageIndex.
Consulta sobre el contenido de la tabla.
=== INTERACCIÓN PROXY-POINTER RAG === Pregunta: ¿qué dice la tabla del anexo a2.1.1? Nodos de contexto únicos extraídos: – [SADU] Nodo 0131: 'ANEXO TABLA A2.1.1 Estudios incluidos en la revisión de la literatura' | Líneas: 3952-4157 – [SADU] Nodo 0092: 'ANEXO TABLA SL.B1.1.1 Probabilidad marginal de un estudio que documente el efecto superior al promedio para los hogares pobres promedio' | Líneas: 2537-2745 – [SADU] Nodo 0052: 'TABLA R1.1.1 Correlatos de probabilidad de que se inicien aceleraciones en la inversión privada' | Líneas: 1663-1899 Respuesta: Basado en los documentos proporcionados, **Tabla del Anexo A2.1.1** se titula **"Estudios incluidos en la revisión de la literatura".** Esta tabla proporciona un resumen de varios estudios de investigación, detallando la siguiente información para cada uno: * **Artículo:** El autor(es) y el año del estudio (p. ej., Kapsos (2005), Saget (2000), Papola y Sahu (2012), etc.). * **Período de la muestra principal:** El período cubierto por el estudio (desde la década de 1960 hasta 2019). * **Cobertura de la muestra:** La escala o el número de entidades analizadas (por ejemplo, "160 países", "90 países en desarrollo", "47 países africanos"). * **Región:** El alcance geográfico de la investigación (p. ej., mundial, sur de Asia, África, Europa, Medio Oriente, Asia). * **Economías:** Los países o grupos económicos específicos incluidos en la investigación (por ejemplo, "India", "Bulgaria, República Checa, Estonia…", "países del G20"). El cuadro documenta un conjunto diverso de investigaciones que abarcan desde 1960 hasta 2019 y cubren regiones y economías de todo el mundo, incluidos datos específicos sobre economías en transición, varios países de la OCDE y regiones específicas como el sur de Asia y África.
Consulta que requiere conocimientos estructurales.
=== INTERACCIÓN PROXY-POINTER RAG === Pregunta: ¿cuáles son las preguntas respondidas por el capítulo 2 Nodos de contexto únicos extraídos: – [SADU] Nodo 0099: 'FIGURA 2.3 Modelos de crecimiento' | Líneas: 3127-3155 – [SADU] Nodo 0098: 'Preguntas' | Líneas: 3115-3127 – [SADU] Nodo 0124: 'ANEXO 2.1 Resumen de la literatura sobre la elasticidad del crecimiento del empleo' | Líneas: 3807-3812 Respuesta: Con base en el texto proporcionado, el Capítulo 2 aborda las siguientes preguntas sobre el crecimiento económico y el mercado laboral de Asia Meridional: * **¿Cómo se compara el empleo de Asia Meridional con el de otras economías de mercados emergentes y en desarrollo (EMDE)?** (Fuente: *Capítulo 2, sección de Preguntas*) * **¿Cuáles son las correlaciones de las tasas de empleo a largo plazo entre las EMED?** (Fuente: *Capítulo 2, sección de Preguntas*) * **¿Cómo se puede ¿El sur de Asia crea los empleos necesarios para absorber su creciente población en edad de trabajar, al tiempo que aumenta la productividad?** (Fuente: *Capítulo 2, sección de Preguntas*) Además, el capítulo explora estas cuestiones con el objetivo de comprender cómo la región puede aprovechar su población en edad de trabajar para acelerar la convergencia hacia los niveles de ingresos de las economías avanzadas.
Si bien hasta ahora hemos demostrado la ventaja de costos, ¿supera la arquitectura el desafío de escalabilidad de PageIndex?
¿Es escalable el puntero proxy?
He aquí por qué la arquitectura es escalable en una base de conocimiento empresarial. PageIndex paga una penalización de escalabilidad en ambos extremos: ~137 llamadas de LLM por documento durante la indexación y un paso de razonamiento de LLM adicional por consulta para la navegación en árbol. Proxy-Pointer elimina ambos.
Sin LLM en indexación. El árbol esqueleto se construye con expresiones regulares en milisegundos. Las únicas llamadas API son al modelo de incrustación, idéntico al vector RAG estándar. No hay navegación en el árbol en el momento de la recuperación. Las consultas van directamente al índice de vectores. Sin resúmenes de lectura de LLM, sin recorrido por documento.
Proxy-Pointer es un RAG vectorial estándar con metadatos inteligentes integrados. La conciencia estructural vive dentro de las incrustaciones (a través de rutas de navegación) y los metadatos fragmentados (a través de punteros de nodo), no en un ciclo de razonamiento LLM. Hereda toda la escalabilidad de Vector RAG: índices unificados de múltiples documentos, búsqueda sublineal, actualizaciones incrementales y cero sobrecarga de LLM por consulta más allá de la síntesis final.
A prueba de fallos para documentos no estructurados: si un documento no tiene encabezados (o el árbol esqueleto produce solo un nodo raíz), el sistema lo detecta durante la fragmentación y recurre a una ventana deslizante estándar. Los fragmentos se marcan con node_id y límites de línea vacíos. En el momento de la recuperación, los fragmentos marcados se utilizan directamente como contexto LLM en lugar de seguir punteros al origen. El sistema se degrada elegantemente al RAG vectorial estándar: sin errores ni necesidad de manipulación especial.
Comparemos Vectorless RAG y Proxy-Pointer cara a cara.
RAG sin vector vs puntero proxy
Realicé una variedad de consultas: estructurales amplias, referencias cruzadas, factuales específicas, cifras específicas, etc. Y dejé que Claude juzgara las respuestas para una comparación exhaustiva. Puede encontrar las respuestas detalladas de Vectorless y Proxy-Pointer junto con el informe completo de Comparación de calidad aquí.
La siguiente tabla resume el veredicto. La puntuación final: PageIndex 2 – Proxy 4 – Empates 4. En otras palabras, Proxy-Pointer iguala o supera a PageIndex en 8 de cada 10 consultas. Y todo con la escalabilidad y el precio de un Flat Vector RAG.
Aquí está el veredicto resumido:
Y aquí está la comparación de costos:
Conclusiones clave
La estructura es el ingrediente que falta en RAG. La brecha de calidad entre el ingenuo vector RAG y PageIndex no se trata de mejores incrustaciones, sino de preservar la jerarquía. No necesita un LLM para codificar estructuras. La inyección de ruta de navegación y los metadatos estructurales brindan al índice vectorial conocimiento estructural sin ningún costo. El filtrado de ruido supera a las mejores incrustaciones. Eliminar 7 nodos de bajo valor del índice tuvo más impacto en la calidad de recuperación que cualquier intercambio de modelo. Los punteros golpean los trozos. Los fragmentos actúan como representantes de la sección completa, que es lo que ve el sintetizador LLM.
Conclusión
Proxy-Pointer RAG demuestra una tesis simple: no necesitas un LLM costoso para hacer que un perro perdiguero tenga conciencia estructural; solo necesitas ser inteligente con lo que incorporas.
Cinco técnicas de ingeniería de costo cero (árboles de esqueleto, punteros de metadatos, rutas de navegación, fragmentación guiada por estructura y filtrado de ruido) cierran la brecha de calidad con un sistema completo navegado por LLM, manteniendo al mismo tiempo la velocidad y la escalabilidad del RAG vectorial estándar. En nuestro punto de referencia de 10 consultas, Proxy-Pointer igualó o superó a PageIndex en 8 de cada 10 consultas, al costo de un Vector RAG estándar.
La próxima vez que cree RAG para su repositorio de documentos estructurados (o no estructurados), no busque un modelo más grande. Busque el índice Proxy-Pointer.
Conéctese conmigo y comparta sus comentarios en www.linkedin.com/in/partha-sarkar-lets-talk-AI
Referencia
Banco mundial. 2024. Actualización sobre el desarrollo de Asia Meridional, abril de 2024: Empleos para la resiliencia — Licencia: CC BY 3.0 IGO.
Las imágenes utilizadas en este artículo se generan con Google Gemini. Código creado por mí.