RAPTOR: un árbol de resúmenes para consultar grandes colecciones de documentos

Fri, 16 Oct 2026 00:00:00 +0200

Portada conceptual generada con IA. Evoca una colección documental y sus síntesis; no representa la arquitectura del método ni resultados experimentales.

Estos días me rondaba por la cabeza cuánto código se estaría generando con IA en el mundo y cuántos programadores seguirían escribiéndolo todo a mano. Para investigar esas preguntas habría que mirar en muchos sitios: encuestas, estudios de repositorios de GitHub, publicaciones de Stack Overflow e informes empresariales. Cada fuente podría aportar una parte de la historia, pero habría que comprobar qué permite medir y qué conclusiones podemos extraer de ella.

Enseguida me surgió otra cuestión: ¿cómo trabajamos con miles de documentos e información desestructurada para acabar obteniendo una explicación coherente? Para concretar el problema, imaginemos que reunimos cien documentos de esas fuentes. El conjunto completo no cabe en el contexto del LLM que vamos a utilizar. Además, leer cada documento por separado no basta para responder algunas preguntas.

La primera idea que se me ocurrió fue un sistema en embudo: dividir el material, producir resúmenes parciales y combinarlos en varias etapas hasta obtener una síntesis que quepa en el contexto. Parece una solución razonable, aunque esa síntesis ya no contiene toda la información original. Antes de decidir cómo construirla, conviene pensar qué queremos preguntarle. Volvamos al caso de la adopción de IA.

«¿Qué población estudió esta encuesta?» exige localizar un detalle. «¿Qué diferencias metodológicas explican que estos informes ofrezcan resultados distintos?» pide relacionar definiciones, muestras y procedimientos repartidos entre varias fuentes.

Pronto aparece una trampa: el porcentaje de desarrolladores que usa IA no equivale al porcentaje de código generado por IA. Una persona puede utilizar un asistente para explicar una función sin aceptar una sola línea. Otra puede generar mucho código y descartarlo antes de integrarlo. Incluso «código generado» puede referirse a sugerencias mostradas, aceptadas, confirmadas en Git o conservadas después de una revisión.

Necesitamos seleccionar información sin borrar esas diferencias.

Tirando de ese hilo, encontré dos trabajos que ayudan a entender el problema. En Recursively Summarizing Books with Human Feedback, de Jeff Wu y colaboradores (2021), el objetivo es resumir libros completos: dividir el texto en fragmentos, resumirlos y combinar esos resúmenes recursivamente hasta obtener una síntesis del libro. Es una aplicación concreta de esa idea del embudo.

El componente de feedback humano pertenece al entrenamiento: las personas escriben ejemplos de resúmenes y comparan salidas del modelo; esas señales sirven para ajustar su comportamiento. La investigación también busca facilitar la supervisión de una tarea demasiado larga para evaluarla de una vez. No implica que una persona revise cada resumen cuando después se utiliza el sistema. Las secciones 2.2 y 2.3 del paper explican la descomposición y el entrenamiento.

El siguiente paso que me interesó aparece en RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval, de Parth Sarthi y colaboradores (2024). Su propuesta conserva los fragmentos y añade resúmenes de grupos relacionados, de modo que ambos puedan recuperarse según la pregunta. El interés pasa de producir una síntesis final a consultar el contenido a distintas escalas. ¿Qué ganamos con esa estructura y qué podemos perder al construirla?

Antes del árbol: conseguir documentos no es comprenderlos

Un crawler recorre direcciones y obtiene documentos. Puede ayudarnos a recopilar páginas, pero no determina por sí mismo si una encuesta representa al conjunto de desarrolladores, si dos noticias repiten el mismo comunicado o qué significa una métrica.

Los cien documentos son un ejemplo conceptual. Podrían llegar de un crawler, de varios, de una carpeta o de una descarga manual. Imaginar cien crawlers tampoco implica recomendar uno por documento ni una arquitectura distribuida. RAPTOR pertenece a la organización y recuperación del contenido, después de adquirirlo, no a la adquisición web ni a la comprobación de su fiabilidad.

Separar estas responsabilidades importa: un sistema puede recuperar perfectamente un texto que contiene una interpretación equivocada. El índice no convierte una afirmación en evidencia.

Qué hace un RAG basado en fragmentos

RAG significa Retrieval-Augmented Generation: generación apoyada en información recuperada. En una configuración sencilla, primero dividimos los documentos en fragmentos manejables. Después calculamos para cada uno un embedding, una lista de números que representa características del texto aprendidas por un modelo. Textos relacionados suelen quedar próximos según una medida de similitud; eso permite buscar por algo más que coincidencias literales de palabras.

Guardamos esos vectores y su relación con el texto en un índice. Al recibir una pregunta, calculamos su representación, buscamos fragmentos relacionados y entregamos al LLM la pregunta junto con ese contexto. El modelo redacta una respuesta a partir de esa selección. La similitud entre vectores es una señal de relevancia, no una medida de veracidad ni una prueba de que dos cifras sean comparables.

Esta descripción es un punto de partida, no una definición de todos los RAG. Hay búsqueda por palabras como BM25, combinaciones de búsqueda léxica y vectorial, filtros por metadatos, reordenación de candidatos y consultas en varios pasos. Una recuperación por fragmentos puede resolver preguntas transversales si consigue reunir las piezas necesarias.

El problema aparece cuando el presupuesto solo permite recuperar unos pocos fragmentos y cada uno contiene una parte de la explicación. Una búsqueda sobre «adopción de IA» puede devolver titulares muy parecidos y dejar fuera la sección metodológica. Aumentar el tamaño del fragmento aporta contexto local, pero también consume más espacio y puede mezclar asuntos.

Una ventana de contexto mayor amplía lo que podemos incluir. No selecciona fuentes fiables, no elimina duplicados ni resuelve automáticamente contradicciones. Aunque todos los documentos cupieran, seguiría haciendo falta distinguir sus poblaciones y denominadores.

Construir síntesis de abajo arriba

RAPTOR significa Recursive Abstractive Processing for Tree-Organized Retrieval. «Abstractivo» indica que el resumen puede reformular y sintetizar información, en lugar de limitarse a copiar frases. La propuesta de Parth Sarthi y colaboradores consiste en añadir textos de síntesis al material disponible para recuperar. Su paper de 2024, sección 3, describe una construcción de abajo arriba:

Fragmentar el material. Los fragmentos originales forman las hojas, el nivel de mayor detalle.
Calcular sus embeddings. Estas representaciones permiten comparar contenido.
Agrupar fragmentos relacionados. El clustering busca grupos en esas representaciones, sin exigir que los textos sean consecutivos.
Resumir cada grupo con un LLM. El resumen se convierte en un nodo nuevo, relacionado con los nodos que lo originaron.
Calcular embeddings de los resúmenes. Así también pueden agruparse y recuperarse.
Repetir el ciclo. Los niveles siguientes sintetizan los anteriores hasta detener la construcción.

Los niveles superiores ofrecen una visión más condensada; los inferiores conservan mayor detalle. Eso no significa que un nivel alto sea más verdadero ni que conserve todas las salvedades. Es otra representación del material.

Cómo decide qué textos agrupar

Las representaciones vectoriales pueden tener muchas dimensiones. Para facilitar el agrupamiento, RAPTOR utiliza UMAP, una técnica que reduce el número de dimensiones intentando conservar relaciones de vecindad. Pensemos en obtener una representación más compacta para agrupar, no en resumir el texto con UMAP. La reducción transforma la geometría y tampoco garantiza conservar cada relación importante.

Sobre esas representaciones aplica modelos de mezclas gaussianas, o GMM. En términos prácticos, ajusta varios componentes probabilísticos a los puntos y estima la pertenencia de cada punto a ellos. El número de componentes se elige comparando candidatos con el criterio BIC, que equilibra ajuste y complejidad. No descubre un número objetivamente correcto de temas.

El procedimiento combina una agrupación global con agrupaciones locales dentro de ella. El número de vecinos de UMAP ayuda a controlar esa escala. Si un grupo resulta demasiado grande para resumirlo dentro del límite de entrada, se vuelve a agrupar. Son operaciones de construcción del índice, anteriores a la pregunta del usuario.

La pertenencia es suave: un fragmento puede participar en más de un grupo. En el código de clustering consultado, se asignan los componentes cuya probabilidad supera un umbral. Un texto sobre la metodología de una encuesta y sus resultados puede alimentar dos síntesis.

Por tanto, «árbol» es el nombre del método, pero no debemos imaginar una clasificación con un solo padre obligatorio por nodo. Las relaciones entre niveles pueden compartir descendientes, como en un grafo dirigido sin ciclos. Tampoco hace falta terminar con una sola raíz: la implementación puede conservar varios nodos en el nivel superior.

Esquema didáctico, no ejecución del algoritmo. Las flechas van del material al resumen que produce. El doble enlace de F2 muestra un solapamiento posible; se omiten embeddings, UMAP y otros grupos. Los identificadores corresponden al ejemplo sintético de más abajo. Abre la figura para ampliarla.

El paper y el repositorio son referencias diferentes

La configuración experimental del paper utiliza fragmentos de aproximadamente 100 tokens, embeddings SBERT y gpt-3.5-turbo para resumir. Son decisiones de aquellos experimentos, no requisitos universales de RAPTOR.

La revisión del repositorio oficial consultada, identificada por el commit f50d917, ya incorpora otras opciones. Sus clases predeterminadas usan LiteLLM, text-embedding-ada-002 para embeddings y gpt-4o-mini para resúmenes. El constructor tiene un máximo configurable de niveles y se detiene también cuando quedan pocos nodos respecto a la dimensión de reducción. Puede dejar de construir antes de llegar a una única síntesis.

Estas diferencias se comprueban en construcción, parada del agrupamiento, embeddings y resúmenes. Ejecutar hoy los valores predeterminados del repositorio no reproduce automáticamente el paper.

Consultar el árbol no obliga a recorrer una sola rama

El paper describe dos estrategias. Ambas comparan la pregunta con representaciones de nodos; difieren en qué candidatos consideran.

Tree traversal, o recorrido por niveles, empieza en los nodos del nivel superior y selecciona los k más próximos a la pregunta. Después reúne sus hijos y vuelve a seleccionar los k mejores de ese conjunto. Repite hasta la profundidad elegida y concatena los textos seleccionados en los distintos niveles. No tiene por qué elegir una sola rama: k puede ser mayor que uno y los descendientes pueden estar compartidos. Una mala selección inicial, eso sí, puede excluir detalles útiles antes de compararlos con la consulta.

Collapsed tree considera conjuntamente los nodos de todos los niveles: hojas y resúmenes compiten en la misma búsqueda. Ordena por similitud y selecciona contexto dentro de un presupuesto de tokens. «Colapsar» aquí no significa borrar los originales ni resumir todo una vez más; significa buscar sobre el conjunto de nodos sin seguir sus enlaces de padre a hijo.

Comparación conceptual simplificada. El recorrido reúne candidatos de varios padres; collapsed tree puede seleccionar simultáneamente R1, F2 y F3. La selección dibujada es ilustrativa, no un resultado medido ni una predicción para una pregunta concreta. No se muestran todos los solapamientos.

Los autores eligen collapsed tree para sus resultados principales, con hasta 2.000 tokens de contexto; para UnifiedQA usan 400 por la ventana de ese modelo. Los métodos de referencia reciben el mismo presupuesto de contexto en esas comparaciones. Esos límites corresponden al texto recuperado: al preparar una llamada real también debemos reservar espacio para instrucciones, pregunta y respuesta. Véanse la sección de consulta y la figura 3.

El código añade un matiz operativo. En retrieve_information_collapse_tree, examina como máximo top_k candidatos ordenados y se detiene cuando el siguiente excedería max_tokens; no salta ese nodo para buscar otros menores. En la rama de recorrido, el método acumula selecciones por nivel y no aplica ese mismo límite de tokens. Una integración debe comprobar el presupuesto total, sin asumir que ambos caminos lo gestionan igual.

Conservar las hojas permite recuperarlas. No garantiza que una consulta concreta las seleccione ni que el LLM respete lo recuperado. Incluso una respuesta basada en un resumen correcto puede omitir una condición que nunca llegó al contexto.

Un ejemplo sintético: personas, sugerencias y código integrado

Los siguientes documentos, cifras y resúmenes son inventados para explicar el mecanismo. No describen la adopción real de IA, no proceden de encuestas existentes y no son salidas de una ejecución de RAPTOR.

Fragmento	Documento sintético y contenido
F1	A, encuesta: 60 de 100 participantes dicen haber usado un asistente de IA al menos una vez durante el último mes.
F2	A, metodología: muestra voluntaria de un foro; «uso» incluye explicar código. No se inspeccionaron repositorios ni se midió código generado.
F3	B, informe interno: en un equipo de 10 personas, 20 de 100 sugerencias mostradas por una herramienta fueron aceptadas durante una semana. No se midió qué parte sobrevivió a la revisión.
F4	C, noticia: reproduce el resultado de A y enlaza a esa encuesta; no recoge una muestra adicional.

Una agrupación posible reúne F1, F2 y F4 alrededor de la encuesta y su difusión. Otra reúne F2 y F3 alrededor de las diferencias de medición. F2 participa en ambas: su definición de «uso» importa para entender la encuesta y para compararla con el informe interno.

Escribimos manualmente dos resúmenes didácticos:

R1, a partir de F1, F2 y F4: A mide uso declarado en una muestra voluntaria, incluyendo explicaciones de código; C repite A y no aporta observaciones independientes.
R2, a partir de F2 y F3: uso declarado y aceptación de sugerencias tienen unidades y poblaciones distintas; ninguno mide la proporción de código finalmente integrado atribuible a IA.

Una síntesis superior S podría conservar esa incompatibilidad. También podría degradarla y producir «la IA tiene una adopción elevada y genera una parte del código», una frase que introduce una valoración y una conclusión que los documentos sintéticos no sostienen.

Para «¿qué población estudió A?», F2 contiene el detalle decisivo. Para «¿por qué no se pueden comparar directamente A y B?», R2 puede orientar, pero convendría contrastarlo con F2 y F3. Esto último es una política de evidencia que propondríamos, no un paso garantizado por collapsed tree.

La respuesta justificable en este ejemplo sería: A cuenta personas que declaran algún uso durante un mes; B cuenta sugerencias aceptadas por un equipo durante una semana. Ni el 60 % de participantes ni el 20 % de sugerencias permite calcular el porcentaje de código integrado generado por IA. No debemos promediar esos porcentajes, multiplicarlos ni contar C como una segunda encuesta.

El teléfono escacharrado puede subir de nivel

Resumir repetidamente recuerda al teléfono escacharrado: cada etapa recibe una versión transformada del mensaje. El LLM no solo reduce palabras; decide qué conservar y cómo relacionarlo. Si una salvedad desaparece en un nivel, el siguiente puede no tener forma de reconstruirla.

En nuestra investigación imaginaria, los errores podrían adoptar formas concretas:

Omitir condiciones: convertir «participantes voluntarios de un foro» en «desarrolladores» en general.
Confundir asociación y causa: transformar «quienes usaban el asistente declaraban mayor productividad» en «el asistente aumentó la productividad».
Mezclar métricas: sustituir «sugerencias aceptadas» por «código integrado».
Borrar discrepancias: conservar el patrón mayoritario y eliminar un estudio que observa un efecto distinto o no lo detecta.
Fabricar consenso: tratar diez páginas que reproducen A como diez mediciones independientes.
Añadir contenido sin respaldo: completar una explicación plausible con información que no figura en los documentos.

Los fallos pueden estar correlacionados. Hacer muchas llamadas al mismo modelo sobre materiales parecidos no equivale a disponer de observaciones independientes: una misma tendencia a simplificar denominadores puede repetirse en varios grupos y reaparecer en su síntesis. No hay motivo para asumir que los errores se compensarán.

El apéndice E del paper estudia alucinaciones en 150 nodos muestreados de 40 relatos. Encontraron seis con alguna alucinación: el 4 % de esa muestra. Los autores indican que no observaron propagación a los padres ni un efecto discernible en sus tareas de preguntas y respuestas. Es una observación limitada a su análisis, no una tasa universal de error ni una garantía de que los resúmenes recursivos no propaguen fallos. Tampoco mide exhaustivamente todas las omisiones metodológicas que nos preocupan aquí.

Para un sistema editorial propondríamos medidas adicionales: registrar procedencia y versiones, detectar duplicados, conservar pasajes de evidencia, asociar afirmaciones con sus fuentes y pedir revisión humana cuando una síntesis cambie el alcance de una conclusión. RAPTOR conserva enlaces entre nodos; eso no demuestra por sí solo la trazabilidad de cada afirmación ni que una cita la respalde. El resumen debe poder cuestionarse mirando el material del que procede.

Qué demostraron los autores y hasta dónde llega esa evidencia

La evaluación, sección 4, se centra en preguntas sobre textos largos:

Dataset	Material y tarea	Medidas utilizadas
NarrativeQA	Libros y guiones; respuestas abiertas sobre su contenido.	ROUGE-L, BLEU y METEOR, métricas de correspondencia entre respuestas y referencias.
QASPER	Artículos de procesamiento del lenguaje natural; preguntas sobre el texto completo.	F1 de respuesta, que combina precisión y cobertura según el protocolo del dataset.
QuALITY	Pasajes largos y preguntas de opción múltiple; incluye un subconjunto difícil.	Exactitud: proporción de opciones respondidas correctamente.

Comparan recuperación con BM25, basada en términos; DPR, un recuperador vectorial entrenado para pasajes; y SBERT. También hacen comparaciones con y sin la estructura RAPTOR manteniendo el recuperador y usando UnifiedQA-3B como lector, el modelo que responde.

Dos filas de la tabla 2 ayudan a dimensionar el efecto sin confundir configuraciones:

Comparación con SBERT y UnifiedQA-3B	Sin RAPTOR	Con RAPTOR	Diferencia
QASPER, F1 en escala 0–100	36,23	36,70	+0,47 puntos de F1
QuALITY, exactitud	54,9 %	56,6 %	+1,7 puntos porcentuales

Son cambios absolutos en las escalas indicadas. No significan que RAPTOR mejore cualquier sistema un 1,7 % o que el F1 mida directamente la fidelidad de cada afirmación.

El resultado más llamativo del artículo científico aparece en la tabla 7: RAPTOR con GPT-4 obtiene un 82,6 % de exactitud en el test de QuALITY frente al 62,3 % de CoLISA con DeBERTaV3-large, una diferencia de 20,3 puntos porcentuales. Esa comparación cambia también el lector y el sistema completo. No permite atribuir los 20,3 puntos exclusivamente al árbol. Para entender su contribución son más informativas las comparaciones controladas anteriores.

Los autores añaden ejemplos cualitativos y ablaciones, es decir, pruebas donde se modifica una parte del sistema para estudiar su contribución. El apéndice I contiene casos en los que usar todos los niveles no es la mejor opción para un relato concreto. La utilidad agregada de la jerarquía no implica una mejora uniforme en cada consulta.

Hay una distancia importante entre esas tareas y nuestra colección web. Buena parte de la evaluación pregunta por un libro, un pasaje o un artículo identificado; no comprueba la veracidad de cien fuentes heterogéneas, su independencia ni la reconciliación de encuestas incompatibles. Además, las métricas de respuesta no sustituyen una revisión de respaldo documental. El apéndice H detalla adaptaciones del script de evaluación de NarrativeQA, otro motivo para respetar el protocolo al reproducir resultados.

La jerarquía también cuesta. Hay que generar embeddings adicionales, ejecutar reducción y clustering, llamar al modelo de resumen y almacenar los nodos nuevos. El apéndice A describe una tendencia aproximadamente lineal en tiempo y consumo de tokens dentro del rango que probaron. No es una garantía de complejidad o coste para cualquier colección, modelo o configuración. Una colección estable consultada muchas veces puede amortizar la construcción; documentos que cambian a menudo pueden exigir mucho trabajo de actualización. Esa rentabilidad habría que medirla en nuestro caso.

Otra forma de organizar síntesis: GraphRAG

Microsoft GraphRAG construye otra estructura: extrae entidades y relaciones, organiza el grafo en comunidades y genera informes sobre ellas. Su búsqueda global usa informes de comunidades de un nivel de la jerarquía, genera respuestas parciales y combina las seleccionadas mediante un proceso de tipo map-reduce.

Ambos preparan síntesis para preguntas amplias, pero agrupar embeddings de textos y construir comunidades sobre un grafo de entidades son decisiones diferentes. La búsqueda global de GraphRAG tampoco equivale a ordenar todos los nodos de RAPTOR por similitud. No hemos comparado su rendimiento: estas referencias sitúan el diseño, no establecen un ganador.

Mirarlo como un pipeline de datos

Desde ingeniería de datos, el árbol es una colección de transformaciones y productos derivados. Merece las mismas preguntas que un ETL: qué entró, qué cambió, con qué versión se procesó y qué salidas dependen de ello.

Etapa	Qué registraríamos en un sistema editorial propio
Ingesta	Identificador, URL, fecha de captura, versión o hash del documento y copia de origen cuando corresponda.
Limpieza	Parser, configuración y relación entre el texto extraído y el original.
Deduplicación	Duplicados y republicaciones; vínculo con el estudio primario cuando se identifica.
Fragmentación	Documento y versión, sección y posición de cada fragmento.
Resumen	Nodos de entrada, prompt, modelo identificado cuando sea posible, parámetros y texto producido.
Indexación	Modelo de embeddings, configuración de reducción y clustering, y versión del índice.
Consulta y evaluación	Pregunta, nodos seleccionados, presupuesto, respuesta, evidencias y errores observados.

Esta tabla es una propuesta de instrumentación, no una lista de garantías incluidas por RAPTOR. La Node del código consultado guarda texto, índice, hijos y embeddings; no contiene por sí misma todo ese registro documental.

También separaríamos limpiar formato de reescribir contenido. Quitar un menú repetido busca aislar el cuerpo del documento, aunque un parser puede eliminar por error una nota al pie. Reformular una metodología para hacerla «más clara» cambia la representación semántica y puede introducir una interpretación. Conviene conservar el original y registrar ambas transformaciones con criterios de validación diferentes.

¿Qué ocurre cuando cambia un documento? Como propuesta, marcaríamos sus fragmentos y sus resúmenes dependientes como obsoletos, siguiendo todos los enlaces afectados, incluidos los compartidos. Pero regenerar únicamente los antecesores anteriores puede ser insuficiente: los embeddings nuevos pueden cambiar los grupos y sus miembros. Habría que elegir entre una reconstrucción por lotes y una estrategia incremental que evaluemos expresamente.

La función add_documents de la revisión consultada reconstruye el árbol desde el texto recibido y avisa si sobrescribe uno existente; su nombre no debe hacernos suponer una actualización incremental con trazabilidad documental.

¿Cómo rastrear una afirmación hasta la fuente? Propondríamos enlazarla con pasajes concretos y verificar que esos pasajes sostienen su alcance, población y métrica. Una ruta de padres e hijos identifica dependencias; no demuestra que cada oración del resumen se deduzca de ellas. En nuestra pregunta inicial, la comprobación tendría que llegar hasta la definición de «uso» y hasta qué código se contó, no detenerse en un titular.

Una prueba pequeña que tendría sentido hacer

No hemos ejecutado una comparativa de recuperación para este artículo. Lo siguiente es una propuesta experimental, sin resultados medidos. Los resúmenes y las selecciones dibujadas antes son ejemplos redactados para enseñar el mecanismo.

Una prueba inicial podría utilizar una colección sintética de 12 documentos breves con métricas incompatibles, limitaciones explícitas, una contradicción y republicaciones identificadas. Antes de construir el índice fijaríamos preguntas puntuales y transversales, sus evidencias necesarias y cuándo la respuesta correcta es «no se puede calcular con estos datos».

Compararíamos un índice de fragmentos con otro que añada resúmenes mediante la implementación oficial de RAPTOR fijada a un commit. Ambos usarían los mismos documentos, fragmentos de partida, embeddings, lector y presupuesto de contexto. Registraríamos modelos, prompts, parámetros, semillas y límites de gasto antes de ejecutar nada; no bastaría con elegir los valores predeterminados.

Con una colección tan pequeña habría que comprobar que el constructor realmente produce niveles adicionales. Si se detiene antes por el número de nodos, se documentaría y se ajustaría la configuración con justificación. Forzar grupos manuales puede servir para enseñar, pero esa variante sería una implementación didáctica, no una reproducción del paper.

Aspecto	Qué observaríamos
Corrección	Si responde a la pregunta o reconoce que falta información.
Matices	Si conserva población, periodo, unidad, denominador y limitaciones.
Respaldo	Si cada afirmación se sostiene en pasajes identificables y las fuentes repetidas se reconocen.
Omisiones	Qué evidencia necesaria no se recupera o no aparece en la respuesta.
Latencia	Construcción, recuperación y generación por separado.
Coste	Llamadas y tokens de construcción y consulta; importe solo si hay tarifas y consumo verificables.

Conservaríamos documentos, preguntas, criterios, configuración, nodos, selecciones y respuestas para repetir y revisar la prueba. Una comparación solo sobre estas preguntas no mediría la adopción de IA en el mundo ni demostraría superioridad general. No se han utilizado credenciales ni ejecutado servicios de pago para una prueba RAG.

Cuándo merece la pena planteárselo

RAPTOR ofrece una idea útil cuando las preguntas necesitan moverse entre detalle y síntesis: hacer recuperables ambos tipos de texto. Puede interesar en colecciones donde varios pasajes aportan partes de una explicación y las consultas se repiten lo suficiente como para justificar preparar el índice.

Añade, a cambio, una etapa generativa antes de responder y nuevas dependencias que mantener. Si predominan búsquedas de datos exactos en documentos pequeños, conviene comprobar primero cuánto resuelve una recuperación más sencilla. Si la tarea exige comparar estudios, la calidad de las definiciones y la procedencia seguirá siendo decisiva con cualquier estructura.

En la investigación que abrió este artículo, una buena respuesta podría terminar diciendo que las fuentes no permiten calcular qué porcentaje del código fue generado por IA. Que el sistema encuentre esa limitación y la conserve sería tan valioso como recuperar una cifra.

Referencias

Sarthi, P., Abdullah, S., Tuli, A., Khanna, S., Goldie, A. y Manning, C. D. (2024). RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval. Se ha leído la versión v1 completa, incluidos los apéndices A–I; PDF de esa versión.
Implementación oficial, latentsp/raptor-rag, revisión f50d91739c6844d36d48c10970d531d961bc75eb. Consultada el 16 de octubre de 2026; archivos técnicos enlazados junto a las afirmaciones.
Wu, J. y colaboradores (2021). Recursively Summarizing Books with Human Feedback. Consultados el resumen, la introducción y las secciones 2.1–2.3 de la versión v2, sobre descomposición y entrenamiento con feedback humano.
Microsoft. Documentación de GraphRAG y Global Search. Consultadas el 16 de octubre de 2026.

Créditos del artículo

El enfoque editorial y la pregunta inicial proceden del encargo de José Pérez. La investigación de fuentes, la redacción, la traducción y los diagramas se han realizado con asistencia de IA mediante OpenAI Codex. La portada se ha generado con la herramienta integrada de imágenes; los diagramas son SVG elaborados mediante código, no imágenes científicas generadas.

Metadato	Valor
Edición	José Pérez
Estado	Revisado; listo para publicación
Revisión humana final	Completada
Tiempo de generación	No registrado
Prueba RAG propia	No ejecutada; propuesta experimental

La revisión humana del artículo está completada. No se ha ejecutado la comparativa RAG propuesta ni se presentan resultados experimentales propios.

Resúmenes el josiete.com