En mi artículo anterior, presenté Proxy-Pointer RAG, una estructura de documentos de recuperación directamente en un índice vectorial, que logra la precisión quirúrgica de los sistemas “Vectorless RAG” como PageIndex, sin su escalabilidad ni penalizaciones de costos. Ese artículo sentó las bases: el por qué, el cómo y una prometedora comparación de diez consultas sobre un único informe del Banco Mundial.
Aunque fue una prueba de concepto útil, no demostró que estuviera listo para la producción. Este artículo tiene como objetivo abordar eso.
En una empresa, la gran mayoría de los documentos en los que se aplica RAG (manuales técnicos, trabajos de investigación, contratos legales, informes de políticas, presentaciones anuales, documentos de cumplimiento) tienen títulos de sección. Eso los hace estructurados. Y esa estructura encapsula el significado, precisamente cómo un ser humano comprende y busca un documento complejo organizando el flujo de la sección en la mente. Un RAG vectorial estándar desecha la estructura cuando tritura un documento en una bolsa plana de trozos que conducen a respuestas subóptimas. En cambio, Proxy-Pointer explota esa estructura ubicua para mejorar drásticamente la precisión de la recuperación, con un costo adicional mínimo.
Para probar la arquitectura, necesitábamos los documentos estructurados más exigentes que pudiéramos encontrar, del tipo en el que un solo punto decimal mal colocado o una nota a pie de página omitida pueden invalidar un análisis completo. Eso son declaraciones financieras. Los informes anuales 10-K están profundamente anidados, tienen referencias cruzadas en múltiples estados financieros y exigen un razonamiento numérico preciso. Si Proxy-Pointer puede manejarlos, puede manejar cualquier cosa con encabezados.
Este artículo proporciona evidencia que respalda la capacidad de Proxy-Pointer. Tomé cuatro presentaciones 10-K disponibles públicamente para el año fiscal 2022: AMD (121 páginas), American Express (260 páginas), Boeing (190 páginas) y PepsiCo (500 páginas) y probé Proxy-Pointer en 66 preguntas en dos puntos de referencia distintos, incluidas consultas contradictorias diseñadas específicamente para romper sistemas de recuperación ingenuos. Los resultados fueron decisivos y se resumen a continuación.
También en este artículo, estoy abriendo el proceso completo, para que pueda ejecutarlo en sus propios documentos, reproducir los resultados y llevarlo aún más lejos.
Resumen rápido: ¿Qué es Proxy-Pointer?
El RAG vectorial estándar divide los documentos en fragmentos ciegos, los incrusta y recupera la K superior por similitud de coseno. El sintetizador LLM ve texto fragmentado y sin contexto y, con frecuencia, alucina o pierde la respuesta por completo.
En el artículo anterior, Proxy-Pointer solucionó este problema con cinco técnicas de ingeniería de costo cero:
Árbol esqueleto: analiza los encabezados de Markdown en un árbol jerárquico (Python puro, no se necesita LLM) Inyección de ruta de navegación: antepone la ruta estructural completa (AMD > Estados financieros > Flujos de efectivo) a cada fragmento antes de incrustarlo. Fragmentación guiada por estructura: divide el texto dentro de los límites de la sección, nunca a través de ellos. Filtrado de ruido: elimina las secciones que distraen (TOC, glosario, resúmenes ejecutivos) del índice. Contexto basado en punteros: usa los fragmentos recuperados como punteros para cargar el sección de documento completa e ininterrumpida para el sintetizador
El resultado: cada fragmento sabe dónde se encuentra en el documento y el sintetizador ve secciones completas, no fragmentos.
Refinamientos desde el primer artículo
Se realizaron varias mejoras significativas en el proceso antes de realizar la evaluación comparativa. Estos se describen a continuación:
Cambios en el proceso de indexación
Arquitectura independiente. La implementación original se basaba en PageIndex como dependencia para la generación del árbol esqueleto. Esto ha sido eliminado por completo. Proxy-Pointer ahora incluye un generador de árboles autónomo de Python puro de ~150 líneas que analiza los encabezados de Markdown en una estructura JSON jerárquica: cero dependencias externas, cero llamadas LLM, se ejecuta en milisegundos.
Filtro de ruido impulsado por LLM. La primera versión utilizó una lista codificada de títulos de ruido (NOISE_TITLES = {"contents", "preword", …}). Esto se rompió con variaciones como "Nota de agradecimiento" frente a "Agradecimientos" o "TOC" frente a "TABLA DE CONTENIDO". En esta versión, la nueva tubería envía el árbol esqueleto liviano a gemini-flash-lite y le pide que identifique nodos de ruido en seis categorías. Esto captura equivalentes semánticos que las expresiones regulares no pudieron.
El pipeline actualizado es el siguiente:
Cambios en el canal de recuperación
Recuperación en dos etapas: Semántica + LLM Re-Ranker. El primer artículo utilizó una recuperación simple de top-K de FAISS. El oleoducto refinado ahora opera en dos etapas:
Etapa 1 (recuperación amplia): FAISS devuelve los 200 fragmentos principales mediante la incorporación de similitud, que se deduplican mediante (doc_id,node_id) y se seleccionan en 50 nodos candidatos únicos. Etapa 2 (Reclasificación estructural): Las rutas jerárquicas de ruta de navegación de los 50 candidatos se envían a un LLM de Gemini, que los reclasifica por relevancia estructural (sin incorporar similitudes) y devuelve los 5 primeros. Este es el diferenciador clave: una consulta sobre “flujo de caja de AMD” ahora prioriza correctamente AMD > Estados financieros > Flujos de caja sobre un párrafo que simplemente menciona el flujo de caja.
Aquí está el canal actualizado:
Estas mejoras transformaron a Proxy-Pointer de un prototipo prometedor a un motor de recuperación de nivel de producción.
Benchmarking: dos pruebas, 66 preguntas, cuatro empresas
Para evaluar rigurosamente el proceso, descargué las presentaciones anuales 10-K del año fiscal 2022 de AMD, American Express (AMEX), Boeing y PepsiCo. Estos se extrajeron a Markdown usando LlamaParse y se indexaron a través del canal Proxy-Pointer.
Luego probé con dos puntos de referencia distintos:
Punto de referencia 1: FinanceBench (26 preguntas)
FinanceBench es un punto de referencia establecido de preguntas cualitativas y cuantitativas en todas las presentaciones financieras. Seleccioné las 26 preguntas que abarcan las cuatro empresas del conjunto de datos, que cubren razonamiento numérico, extracción de información y razonamiento lógico. Debido a restricciones de licencia de conjuntos de datos, las preguntas de FinanceBench y las respuestas reales no se incluyen en el repositorio de github. Sin embargo, los cuadros de mando con respuestas de Proxy-Pointer se proporcionan como referencia.
Para garantizar la reproducibilidad, el repositorio incluye un script benchmark.py que le permite ejecutar la evaluación completa usted mismo en FinanceBench (o cualquier conjunto de datos personalizado), generando registros detallados y cuadros de mando utilizando el mismo proceso.
Punto de referencia 2: Prueba de estrés integral (40 preguntas)
FinanceBench, si bien es útil, prueba principalmente el recuerdo de hechos. Necesitaba algo más difícil: consultas que rompieran un sistema que dependía de la coincidencia de fragmentos a nivel de superficie. Así que creé 40 preguntas personalizadas, 10 por empresa, diseñadas específicamente para poner a prueba el razonamiento numérico, la recuperación de múltiples saltos, la solidez del conflicto y la conciliación entre declaraciones.
Los registros completos de preguntas y respuestas utilizando el bot y los cuadros de mando que se comparan con la verdad del terreno se incluyen en el repositorio de github.
Aquí hay cinco ejemplos que ilustran la complejidad:
Numérico de saltos múltiples (AMEX): “Calcule la proporción de ingresos netos por intereses con respecto a los ingresos totales netos de gastos por intereses para 2022 y compárelo con 2021. ¿Aumentó la dependencia?”
Esto requiere ubicar dos partidas diferentes en dos años fiscales, calcular proporciones para cada una y luego compararlas: una cadena de razonamiento de tres pasos que exige una recuperación precisa del estado de resultados.
Numérico adversario (AMD): "Estime si la acumulación de inventario contribuyó significativamente a la disminución del flujo de efectivo en el año fiscal 2022".
Esto es deliberadamente contradictorio: presupone que el flujo de efectivo disminuyó (lo cual ocurrió, marginalmente) y requiere que el modelo cuantifique el impacto de una partida del balance en una métrica del estado de flujo de efectivo. Un recuperador ingenuo obtendría datos del balance pero perdería el contexto del flujo de caja.
Tasa de Reinversión (PepsiCo): “Calcule la tasa de reinversión definida como Capex dividido por (Flujo de Caja Operativo menos Dividendos)”.
Esto requiere extraer tres cifras distintas del estado de flujo de efectivo, realizar un cálculo no estándar que no se informa en ninguna parte del 10-K y llegar a una proporción precisa (1,123).
Calidad del flujo de caja (Boeing): "¿Qué porcentaje del flujo de caja operativo en el año fiscal 2022 fue consumido por cambios en el capital de trabajo?"
La respuesta aquí es contradictoria: 0%, porque el capital de trabajo fue en realidad una fuente de efectivo (+4.139 millones de dólares frente a OCF de 3.512 millones de dólares), contribuyendo con el 118% del flujo de caja operativo. Cualquier sistema que recupere la sección incorrecta o malinterprete el letrero fallará.
Atribución (AMEX): "Estime cuánto del crecimiento total de los ingresos es atribuible al aumento de los ingresos con descuento".
Esto requiere calcular dos deltas (cambio en los ingresos con descuento y cambio en los ingresos totales) y luego expresar uno como porcentaje del otro, un cálculo que no está presente en ninguna parte de la presentación misma.
Cada pregunta tiene una respuesta real precalculada con valores numéricos específicos, lo que hace que la evaluación sea inequívoca.
Resultados
k=5 Configuración (Primaria)
En esta configuración, el recuperador selecciona un conjunto de 5 nodos (k_final = 5) y las secciones correspondientes se envían al sintetizador LLM para su respuesta.
Una puntuación perfecta en las 66 preguntas. Cada valor numérico coincidía con la verdad fundamental. Cada evaluación cualitativa alineada con los datos de presentación.
Para ilustrar, aquí hay dos respuestas reales del bot de la ejecución comparativa, que muestran la ruta de recuperación y la respuesta sintetizada para las consultas citadas en la sección anterior:
PepsiCo: Tasa de reinversión: "Calcule la tasa de reinversión definida como Capex dividido por (Flujo de caja operativo menos dividendos)".
El robot recuperó el Estado de flujos de efectivo consolidado (ID: 0080) y el Estado de flujos de efectivo consolidado (continuación) (ID: 0081), luego calculó:
Gasto de capital: 5.207 millones de dólares / (Flujo de caja operativo: 10.811 millones de dólares − Dividendos: 6.172 millones de dólares) = 5.207 / 4.639 = 112,24% (es decir, 1,1224)
Verdad fundamental: 1.123. ✅ Partido. Pero el robot fue más allá: sin que se le solicitara, calculó la misma proporción para el año fiscal 2021 (79,73%) y el año fiscal 2020 (83,07%), revelando una clara tendencia de aceleración de la reinversión que ni siquiera se había solicitado.
Boeing: Calidad del flujo de caja: "¿Qué porcentaje del flujo de caja operativo en el año fiscal 2022 fue consumido por cambios en el capital de trabajo?"
El robot recuperó Boeing > Liquidez y recursos de capital > Resumen de flujo de efectivo (ID: 0082) y Estados consolidados de flujos de efectivo (ID: 0107), y luego respondió:
Los cambios en el capital de trabajo proporcionaron 4.139 millones de dólares en efectivo, mientras que el flujo de caja operativo neto fue de 3.512 millones de dólares. Debido a que el cambio en el capital de trabajo fue una fuente de efectivo más que un consumo, no consumió ningún porcentaje de OCF.
Verdad fundamental: 0% consumido; El capital de trabajo era una fuente de efectivo. ✅ Partido. Esta es una pregunta deliberadamente contraria a la intuición: la mayoría de los sistemas forzarían un porcentaje en lugar de reconocer la inversión lógica. La recuperación estructural aseguró que el robot tuviera el estado de flujo de efectivo completo y que el sintetizador interpretara correctamente el signo.
Configuración k=3 (Prueba de estrés)
Para comprender los límites de falla del sistema, volví a ejecutar ambos puntos de referencia con k_final=3, recuperando solo 3 secciones del documento en lugar de 5. Esto restringe deliberadamente la ventana de contexto para probar si la precisión de la recuperación es lo suficientemente sólida como para trabajar con menos nodos.
Los fallos en la ejecución k=3 fueron esclarecedores y proporcionan más perspectiva que las puntuaciones perfectas k=5:
FinanceBench: Una pregunta para AMD: sufrió una alucinación de cálculo: el modelo recuperó las entradas correctas ($9,981 millones / $6,369 millones) pero calculó la división incorrectamente (dando como resultado 1,78 en lugar de 1,57). La recuperación fue correcta; la aritmética del LLM no lo era. Esto no es un error de recuperación: es un error de síntesis, y un LLM más grande (que el flash-lite utilizado aquí) probablemente no habría cometido un error. Integral (AMEX Q7): La consulta “¿Las provisiones para pérdidas crediticias aumentaron más rápido que los ingresos totales?” requiere tanto la línea de provisiones como la línea de ingresos totales del estado de resultados. Con k=3, el clasificador priorizó las notas de pérdidas crediticias sobre el resumen de ingresos, dejando al sintetizador sin el denominador para su comparación. Integral (AMEX Q10): El análisis del apalancamiento operativo requiere comparar el crecimiento de los ingresos y el crecimiento de los gastos uno al lado del otro. En k=3, se excluyeron los desgloses de gastos. Integral (PepsiCo Q9): "¿Qué porcentaje de los cargos entre Rusia y Ucrania se debieron a deterioros de activos intangibles?" requiere una nota a pie de página específica que, en k=3, fue desplazada por nodos de flujo de efectivo de mayor rango.
El patrón es consistente: cada falla k=3 fue causada por una cobertura de contexto insuficiente, no por una recuperación incorrecta. El clasificador eligió las secciones primarias correctas; simplemente no tenía espacio para las consultas secundarias que exigen las complejas consultas de conciliación.
Esto confirma una idea arquitectónica importante: cuando las preguntas requieren referencias cruzadas de varias partes de los estados financieros, k=5 proporciona la cobertura necesaria, mientras que k=3 introduce lagunas de recuperación para las conciliaciones más complejas. Para la mayoría de las aplicaciones prácticas, donde la mayoría de las consultas se dirigen a una sola sección o declaración, k=3 sería perfectamente adecuado y más rápido.
Lo que no muestran los cuadros de mando
Más allá de las cifras brutas, el índice de referencia reveló fortalezas cualitativas que vale la pena destacar:
Puesta a tierra de fuente. Cada respuesta citó fuentes específicas utilizando sus rutas de navegación estructurales (por ejemplo, AMD > Condición financiera > Liquidez y recursos de capital). Un analista que reciba estas respuestas puede rastrearlas directamente hasta la sección de presentación, creando una pista de auditoría.
Robustez adversaria. Cuando se le preguntó acerca de los ingresos por criptomonedas en AMEX (que no existen), el sistema respondió correctamente "Sin evidencia" en lugar de alucinar una cifra. Cuando se le preguntó sobre la relación deuda/capital de Boeing (que no está matemáticamente definida debido al capital negativo), explicó por qué la métrica no es significativa en lugar de forzar un número. Estas son las consultas que hacen tropezar a los sistemas con una recuperación deficiente: emergen en un contexto aparentemente plausible pero irrelevante, y el LLM inventa una respuesta.
Superando a Ground Truth. En varios casos, la respuesta del robot fue posiblemente mejor que nuestra verdad básica precalculada. El cambio en la cartera de pedidos de Boeing se estimó en un “% de medio dígito” en la realidad, pero el robot calculó la cifra exacta: +7,12%. El impacto en el inventario de AMD se confirmó como “un arrastre de más de mil millones de dólares”, pero el robot identificó la acumulación específica de mil millones de dólares. Estos no son errores: son mejoras posibles porque el sintetizador vio el texto completo y sin editar de la sección, no un fragmento truncado.
Para obtener resultados detallados pregunta por pregunta, registros de comparación y cuadros de mando de semáforo, consulte el repositorio de código abierto que se menciona a continuación.
Repositorio de código abierto
Proxy-Pointer ahora es completamente de código abierto (licencia MIT) y se puede acceder a él desde el repositorio de Proxy-Pointer Github.
Está diseñado para un inicio rápido de 5 minutos:
Proxy-Pointer/ ├── src/ │ ├── config.py # Configuración centralizada │ ├── extracción/ # PDF → Markdown (LlamaParse) │ ├── indexación/ │ │ ├── build_skeleton_trees.py # Generador de árboles Pure-Python │ │ └── build_pp_index.py # Filtro de ruido + fragmentación + FAISS │ └── agente/ │ ├── pp_rag_bot.py # Bot RAG interactivo │ └── benchmark.py # Evaluación comparativa automatizada con LLM como juez ├── datos/ │ ├── pdf/ # 4 FinanceBench 10-Ks incluido │ ├── documentos/ # AMD Markdown preextraído (listo para indexar) │ └── Benchmark/ # Cuadros de mando completos y registros de comparación
Qué se incluye fuera de la caja
Un archivo Markdown preextraído para el año fiscal 2022 10-K de AMD: simplemente configure su clave API Gemini, cree el índice y comience a realizar consultas en menos de 5 minutos. Tres archivos PDF 10-K adicionales (AMEX, Boeing, PepsiCo) para usuarios que quieran ampliar su corpus. Cuadros de mando para los puntos de referencia y registros completos de preguntas y respuestas para 40 preguntas del punto de referencia integral. Un script de evaluación comparativa automatizado con evaluación de LLM como juez: traiga su propio archivo de Excel con preguntas y datos reales, y el sistema generará automáticamente cuadros de mando con marca de tiempo.
Todo el proceso se ejecuta en una única clave API de Gemini utilizando gemini-flash-lite, el modelo más rentable de la gama de Google. No se requiere GPU. No es necesario construir una infraestructura compleja ni un árbol de indexación costoso y ávido de tokens.
Simplemente clone, configure, indexe vectores, consulte.
Conclusión
Cuando publiqué el primer artículo sobre Proxy-Pointer, era una hipótesis interesante: no se necesitan costosos árboles navegados por LLM para que la recuperación sea estructuralmente consciente; solo hay que ser inteligente con lo que se incrusta. La evidencia fue una comparación de 10 consultas en un solo documento.
Este artículo va más allá de la hipótesis para llegar a la prueba.
66 preguntas. Cuatro empresas Fortune 500. 100% de precisión en k=5. Razonamiento numérico de múltiples saltos, conciliación entre declaraciones, casos extremos contradictorios y métricas financieras contraintuitivas: Proxy-Pointer los manejó todos. Y cuando deliberadamente le privamos de contexto en k=3, aún así obtuvo una precisión del 93,9%, y solo falló cuando las consultas complejas realmente requerían más de tres secciones del documento.
Esto es lo que logramos y por qué es importante para los sistemas RAG de producción:
Una arquitectura, todos los tipos de documentos. Las empresas ya no necesitan mantener dos vías de recuperación separadas: Vectorless para documentos complejos, estructurados y de alto valor (presentaciones financieras, contratos legales, informes de investigación) y el probado Vector RAG para bases de conocimiento de rutina. Proxy-Pointer maneja ambos dentro de una única canalización RAG vectorial unificada. Si un documento tiene títulos estructurales, el sistema los explota. Si no es así, se degrada elegantemente a la fragmentación estándar. Sin lógica de enrutamiento, sin casos especiales. Escalabilidad RAG vectorial completa al mismo precio. Los enfoques "sin vectores" basados en árboles requieren costosas llamadas LLM durante la indexación (un resumen por nodo para todos los nodos de un documento) y durante la recuperación (navegación en árbol LLM por consulta). Proxy-Pointer elimina ambos. El árbol esqueleto es una estructura extremadamente liviana construida con Python puro en milisegundos. La indexación utiliza solo un modelo de incrustación, idéntico al vector RAG estándar. Las únicas llamadas de LLM son el filtro de ruido (una vez por documento en la indexación) y el reclasificador, que requiere solo 50 (e incluso puede funcionar bien con la mitad de ese número) migas de pan (rutas de árbol) + sintetizador en el momento de la consulta. Modelos económicos, resultados premium. Todo el punto de referencia se ejecutó utilizando gemini-embedding-001 a la mitad de su dimensionalidad predeterminada (1536 en lugar de 3072) para optimizar el almacenamiento de la base de datos vectorial y gemini-flash-lite, el modelo más rentable en la línea de Google, para el filtrado, reclasificación y síntesis de ruido. Ni GPT-5, ni Claude Opus, ni modelos ajustados. La arquitectura compensa la simplicidad del modelo ofreciendo un mejor contexto al sintetizador. Transparente, auditable, explicable. Cada respuesta viene con un rastro estructural: qué nodos se recuperaron, sus rutas de navegación jerárquicas y los rangos de líneas exactos en el documento fuente. Un analista puede verificar cualquier respuesta abriendo el archivo Markdown y leyendo la sección citada. Este no es un sistema de caja negra, es un motor de recuperación de caja de vidrio. De código abierto y de uso inmediato. El proceso completo, desde la extracción de PDF hasta la evaluación comparativa, está disponible como un repositorio único con un inicio rápido de 5 minutos. Clonar, configurar una clave API LLM, crear el índice y comenzar a realizar consultas. Sin GPU, sin Docker, sin infraestructura compleja.
Si su sistema de recuperación tiene problemas con documentos estructurados y complejos, el problema probablemente no sea su modelo de incrustación. Es que su índice no tiene idea de dónde se encuentra algo en el documento. Dale estructura y la precisión seguirá.
Clona el repositorio. Pruebe sus propios documentos. Déjame saber tus pensamientos.
Conéctese conmigo y comparta sus comentarios en www.linkedin.com/in/partha-sarkar-lets-talk-AI
Todos los documentos utilizados en este punto de referencia están disponibles públicamente en las presentaciones 10-K del año fiscal 2022 en SEC.gov. El código y los resultados de las pruebas comparativas son de código abierto bajo la licencia MIT. Las imágenes utilizadas en este artículo se generan con Google Gemini.