La generación aumentada de recuperación (RAG) ha evolucionado rápidamente en los últimos tiempos. El paradigma RAG original fue diseñado para ser sencillo: recuperar los fragmentos más relevantes de un corpus y utilizarlos para responder una pregunta. Si bien es eficaz para muchas consultas centradas en documentos, este enfoque comienza a tener problemas cuando las preguntas se extienden más allá de los límites de un solo documento. O cuando las preguntas son de naturaleza temporal, como rastrear la historia de una entidad a lo largo de años.
Algunos ejemplos serían los siguientes:
¿Qué empresas adquirimos durante la última década? ¿Cómo ha evolucionado nuestra estrategia de IA desde 2018? ¿Qué compromisos de sostenibilidad anunciados en informes anuales anteriores se cumplieron finalmente? ¿Cómo ha cambiado la filosofía de asignación de capital de la administración a lo largo de los años?
Recientemente, un nuevo patrón arquitectónico, LLM-Wiki, ha propuesto una solución interesante a este desafío. En lugar de buscar repetidamente documentos sin procesar durante la recuperación, un paso extenso de procesamiento semántico durante la ingestión crea una base de conocimiento persistente que consta de páginas canónicas vinculadas a través de un índice. Las consultas futuras se responden principalmente a partir de este conocimiento recopilado y no de los documentos originales.
Si bien es una idea elegante, plantea importantes cuestiones arquitectónicas como:
¿Debería compilarse semánticamente el conocimiento empresarial antes de que alguien lo pida? ¿Existe alguna manera de evitar pagar este costo de ingestión de un corpus completo de documentos de gran tamaño (por ejemplo, voluminosos informes anuales, contratos, etc.), sobre la mayor parte de cuyo contenido tal vez nunca se pueda consultar? ¿Qué debería estar presente en las páginas canónicas para que casi todas las consultas futuras puedan responderse sin consultar la fuente sin procesar? Una página canónica sobrediseñada puede ser en sí misma muy larga y, con el tiempo, crecer significativamente más que los propios documentos fuente, lo que resulta en una mayor latencia y costo de recuperación.
En este artículo, compararé LLM-Wiki con la arquitectura Proxy-Pointer (PP), un marco de recuperación consciente de la estructura que aborda el mismo problema desde una perspectiva fundamentalmente diferente. En lugar de compilar ansiosamente conocimiento semántico durante la ingesta, Proxy-Pointer preserva la organización estructural de los documentos y realiza síntesis semántica solo cuando una consulta lo requiere.
Este tipo de análisis semántico perezoso del contenido es consistente con la premisa de Proxy-Pointer de brindar precisión sin el impuesto de ingestión, que he detallado en mis artículos Proxy-Pointer RAG: Lograr precisión sin vectores a escala y costo de Vector RAG y Proxy-Pointer RAG: Structure Meets Scale – 100% de precisión con una recuperación más inteligente.
Veamos la comparación con la ayuda de un escenario de la vida real.
El enfoque LLM-Wiki
LLM-Wiki registra el contexto temporal trasladando gran parte del razonamiento al tiempo de ingestión. En lugar de tratar los documentos como artefactos aislados, cada documento entrante es procesado por un LLM que extrae conceptos, entidades, relaciones y hechos. Estos se fusionan en una colección de páginas canónicas que representan conocimiento persistente sobre la organización.
Por ejemplo, varios informes anuales pueden actualizar colectivamente páginas canónicas como "Adquisiciones", "Inteligencia artificial", "Estrategia de nube", "Sostenibilidad", "Cartera de productos", "Cadena de suministro", etc. Cada nuevo informe anual aporta conocimientos adicionales a estas páginas.
Junto a estas páginas canónicas, el sistema mantiene un índice que ayuda a localizar las páginas adecuadas para futuras consultas.
Conceptualmente, la arquitectura se parece a la siguiente:
Cuando un usuario pregunta: "¿Qué empresas adquirimos durante la última década?", el sistema busca principalmente en el índice, localiza la página canónica relacionada con la adquisición y responde directamente a partir del conocimiento compilado.
Los documentos originales siguen estando disponibles como un almacén de datos inmutable, pero lo ideal es que ya no formen parte de la ruta de consulta normal.
Desde una perspectiva arquitectónica, este es un ejemplo de recopilación de conocimientos.
¿Cómo construimos este Wiki?
Digamos que la entrada es un informe anual de 200 páginas. Para optimizar el costo informático, nos gustaría extraer información relacionada con todas las páginas canónicas de una sola vez y actualizar las páginas relevantes. Esto significaría pedirle al LLM que ejecute docenas de tareas de extracción simultáneamente:
Detectar: adquisiciones, productos, iniciativas de IA, estrategia en la nube, sostenibilidad, riesgos geopolíticos, asociaciones, cadena de suministro, cambios regulatorios, clientes, litigios, inversiones, filiales, reestructuración organizacional, tendencias tecnológicas,…..”
A medida que crece el número de objetivos semánticos, la atención del modelo se divide entre ellos. El modelo debe decidir continuamente qué piezas de información pertenecen a qué páginas canónicas, si se deben crear nuevas páginas y cómo se relacionan los hechos recién descubiertos con el conocimiento existente. A medida que aumenta la complejidad inmediata, lo que exige que el modelo se optimice para muchos objetivos simultáneamente, los LLM exhiben una degradación de la extracción de información de alta dimensión. Especialmente en el caso de documentos largos y densos, esto puede reducir la recuperación, aumentar las omisiones y perder información menos destacada.
Más fundamentalmente, el sistema enfrenta un difícil problema de predicción.
Debe decidir durante la ingesta qué información vale la pena materializar en la base de conocimiento canónica y al mismo tiempo anticipar todas las posibles preguntas que los usuarios harán en el futuro.
Por ejemplo, "¿Cómo ha evolucionado la contribución a los ingresos de la filial X desde su adquisición?"
La evidencia relevante para la consulta anterior puede estar dispersa en múltiples informes anuales, incluida en estados financieros detallados, notas a pie de página o tablas de informes por segmentos. Materializar cada partida financiera potencialmente relevante en páginas canónicas aumentaría significativamente el tamaño y el costo de mantenimiento de la base de conocimientos. Por el contrario, omitir tales detalles significa que algunas consultas futuras requerirán inevitablemente revisar los documentos originales.
Esto ilustra una compensación fundamental de la compilación semántica preventiva: el sistema debe equilibrar continuamente la integridad, la mantenibilidad y el costo de ingesta, a pesar de no saber qué aspectos de los documentos de hoy serán necesarios y suficientes para las preguntas del mañana.
El enfoque del puntero proxy
Proxy-Pointer aborda el mismo problema desde una dirección diferente.
En lugar de crear una base de conocimiento semántico preventivo, Proxy-Pointer crea una representación estructural (árbol esquelético) de cada documento en el momento de la ingesta. Este proceso se basa exclusivamente en expresiones regulares, no utiliza un LLM y no genera costo alguno. La compilación semántica real se pospone hasta el punto de recuperación para un razonamiento y una respuesta justo a tiempo. Veamos cómo funcionará esto:
Proxy-Pointer aprovecha los índices vectoriales estándar con modificaciones importantes. Los fragmentos se crean dentro de los límites de la sección y nunca se permite que se superpongan con secciones posteriores. Cada fragmento está etiquetado con metadatos que apuntan a la sección de donde proviene y límites (números de línea) para su recuperación. Cuando llega una consulta, el canal de reclasificación de búsqueda de vectores + LLM selecciona las secciones top-k más relevantes para el contexto.
El proceso anterior está diseñado para utilizar la estructura de sección/subsección de un documento complejo como un mapa semántico para mostrar con precisión el contenido correcto necesario para responder la pregunta del usuario. Como se demuestra en los enlaces mencionados al principio del artículo, el proceso de recuperación ofrece precisión quirúrgica en consultas complejas.
¿Funciona esto para consultas entre documentos?
Consideremos la pregunta
“¿Qué pasó con las empresas que adquirimos durante la última década?”
La respuesta no se almacena en un solo documento. La respuesta debe construirse correlacionando la información sobre fusiones y adquisiciones distribuida en múltiples informes anuales. Una empresa adquirida en 2016 puede aparecer mencionada repetidamente durante los años siguientes antes de desaparecer de informes posteriores tras integrarse plenamente en la organización matriz.
El método LLM-Wiki habría creado una página canónica que registraría todas las fusiones y adquisiciones tras la ingesta de cada informe anual durante la última década. Y, por lo tanto, puede proporcionar esa página como contexto para el LLM.
Proxy-Pointer, por otro lado, razonaría que la consulta requiere informes anuales de la empresa durante los últimos 10 años. Y dado que cada uno de los metadatos fragmentados en el índice vectorial tendría referencia al año (filtrado de metadatos mediante rutas de navegación estructurales, por ejemplo, Año: 2024 > Sección: Fusiones y adquisiciones), el canal podría recuperar las k secciones principales de cada uno de los informes relevantes para fusiones y adquisiciones.
Suponiendo k=5, esto daría como resultado 50 secciones. Si esto excede la ventana de contexto de LLM, los documentos se pueden analizar en grupos para extraer la información de adquisición y luego proporcionarse a la llamada de LLM de generación de respuesta final como contexto.
Diferencias clave con el enfoque LLM-Wiki
La diferencia más obvia, como se mencionó anteriormente, es que no existe un costo de ingesta inicial, más allá de la creación de un índice vectorial estándar. La compilación y el análisis semántico son diferidos (perezosos); ocurre si la consulta lo necesita.
La segunda es que incluso durante la recuperación, el análisis de la consulta en la sección anterior puede necesitar solo 50 secciones. Esto es mucho más eficiente que analizar 10 informes anuales, cada uno de 200 páginas, por adelantado para formar las páginas canónicas en el método LLM-Wiki.
La tercera diferencia es que Proxy-Pointer aprovecha la estructura del árbol como mapa semántico, lo que le permite reducir las secciones a analizar en función de la consulta del usuario. LLM-Wiki, por otro lado, realiza un análisis exhaustivo de todo el documento para extraer entidades y relaciones para construir la base de conocimientos que el usuario desea almacenar, la mayor parte de la cual quizás nunca se solicite.
Finalmente, el usuario se ahorra la necesidad de tomar por adelantado decisiones difíciles de diseño sobre qué consultas es probable que surjan en el futuro. Crear un compilador que pueda organizar con precisión hechos, conceptos, relaciones y otra información con la expectativa de que casi todas las consultas puedan responderse sin consultar el documento fuente es una tarea desafiante.
Las grandes organizaciones mantienen habitualmente repositorios que contienen millones de páginas. Estos incluyen informes anuales, presentaciones reglamentarias, especificaciones de ingeniería, políticas, contratos, manuales técnicos y mucho más. Los usuarios solo consultan una pequeña fracción de esto. La mayoría de las consultas se dirigen a la versión actual y más reciente de los informes y políticas. Incluso dentro de las consultas realizadas por los usuarios, las consultas temporales forman un pequeño subconjunto.
Proxy-Pointer solo analizaría tanto como sea necesario, cuando sea necesario, lo que podría reducir los costos significativamente. Para una consulta temporal única, analiza solo las secciones necesarias para la pregunta, mientras que LLM-Wiki ya analizó cada informe anual durante la ingesta. Si se repiten consultas temporales similares, la respuesta sintetizada (o resúmenes intermedios) se puede almacenar en caché y reutilizar, lo que permite a Proxy-Pointer amortizar el costo del razonamiento semántico sin necesidad de compilar semánticamente cada documento por adelantado.
Explicabilidad de las respuestas.
Los sistemas de IA empresarial operan cada vez más en entornos regulados donde la explicabilidad es tan importante como la corrección. Para un usuario "¿Cuál es la respuesta?" siempre viene con "¿Por qué debería confiar en él?".
Proxy-Pointer realiza el razonamiento directamente sobre las secciones de origen y la trazabilidad se conserva de forma natural. La evidencia utilizada durante el razonamiento está inmediatamente disponible para su inspección.
LLM-Wiki puede preservar la explicabilidad a través de citas a páginas y documentos fuente, pero el razonamiento principal de las respuestas ocurre a través de representaciones compiladas. A medida que esas representaciones evolucionan a través de repetidas actualizaciones, esto se convierte en otro aspecto del sistema que debe mantenerse y verificarse a lo largo del tiempo.
Conclusión
El debate entre LLM-Wiki y Proxy-Pointer no se trata realmente de recuperación. Se trata de cuándo debería ocurrir la comprensión semántica.
LLM-Wiki supone que el conocimiento empresarial es lo suficientemente valioso como para justificar su compilación durante la ingesta, de modo que las consultas futuras sean económicas. Proxy-Pointer hace la suposición opuesta. Sostiene que la mayor parte del contenido empresarial nunca será consultado y, por lo tanto, el razonamiento semántico debe realizarse sólo cuando una pregunta demuestre que el cálculo es necesario.
Las organizaciones con corpus estables y consultas conceptuales altamente repetitivas pueden encontrar valor en mantener una base de conocimientos compilada. Por el contrario, los grandes repositorios empresariales caracterizados por documentos en evolución, preguntas impredecibles y análisis temporales ocasionales pueden beneficiarse al diferir la compilación semántica hasta la recuperación.
La lección más amplia se extiende más allá de estas dos arquitecturas. A medida que los sistemas de IA empresarial evolucionan desde la recuperación de documentos hasta el razonamiento del conocimiento, los arquitectos deben equilibrar cada vez más el costo con el valor. ¿Deberían compilarse los conocimientos porque algún día podrían ser útiles, o deberían sintetizarse sólo cuando un usuario lo solicite?
Proxy-Pointer hace una elección arquitectónica clara. En lugar de predecir las preguntas del mañana, permite que las preguntas del mañana decidan qué conocimiento debe crearse.
Repositorio de código abierto
Proxy-Pointer es completamente de código abierto (licencia MIT) y se puede acceder a él desde el repositorio de Proxy-Pointer Github.
Clona el repositorio. Pruebe los casos de uso. Déjame saber tus pensamientos.
Conéctese conmigo y comparta sus comentarios en www.linkedin.com/in/partha-sarkar-lets-talk-AI