PageIndex on KnightLi Blog

Qué es PageIndex: un índice documental RAG basado en razonamiento sin bases vectoriales

Wed, 20 May 2026 23:51:37 +0800

VectifyAI/PageIndex es un proyecto RAG interesante. No parte de “crear otra base de datos vectorial”, sino que primero organiza documentos largos en una estructura de árbol similar a una tabla de contenidos, y luego deja que un LLM haga recuperación basada en razonamiento siguiendo ese árbol.

Proyecto: VectifyAI/PageIndex

En el momento de preparar este artículo, la página de GitHub muestra unas 31.8k stars y 2.7k forks, con licencia MIT. El README lo define como Vectorless, Reasoning-based RAG: RAG sin base vectorial y basado en razonamiento.

Qué problema intenta resolver

El flujo común del RAG tradicional es: dividir en chunks, vectorizar, escribir en una base de datos vectorial y recuperar fragmentos mediante búsqueda por similitud. Es un enfoque simple, general y maduro, pero en documentos profesionales largos suele encontrar varios problemas:

La similitud no equivale a relevancia real.
La estructura del documento se rompe por el chunking, y se pierden relaciones entre secciones.
Los resultados de recuperación tienen poca explicabilidad; cuesta explicar por qué se eligió ese fragmento.
En informes financieros, documentos regulatorios, textos legales o manuales técnicos, las preguntas suelen requerir razonamiento entre secciones.

La idea de PageIndex es la inversa: primero organizar el documento como un árbol semántico, y después hacer que el modelo busque como una persona que lee el índice, entra en capítulos y localiza información por niveles.

Flujo básico de PageIndex

El README divide la recuperación de PageIndex en dos pasos:

Generar para el documento un índice en árbol parecido a Table-of-Contents.
Hacer reasoning-based retrieval mediante búsqueda en árbol.

Este árbol no es un simple directorio de archivos, sino una estructura documental pensada para LLMs. Los nodos pueden incluir títulos, rangos de páginas, resúmenes, nodos hijos y otros datos. Así, al responder una pregunta, el modelo no tiene que enfrentarse de entrada a una gran cantidad de chunks sueltos; primero puede decidir a qué sección entrar y luego seguir buscando hacia abajo.

Este enfoque encaja mejor con documentos bien estructurados pero muy largos, como:

Informes financieros y SEC filings.
Material regulatorio y documentos de cumplimiento.
Libros académicos y papers.
Documentos legales.
Manuales técnicos y documentación de producto.
PDFs grandes que superan la ventana de contexto del modelo.

Diferencias con el RAG vectorial tradicional

Los principales puntos de PageIndex se pueden resumir en cinco.

Primero, no necesita Vector DB. Usa estructura documental y razonamiento del LLM para localizar contenido, en lugar de depender solo de búsqueda por similitud vectorial.

Segundo, no usa chunking tradicional. Los documentos se organizan por secciones naturales, no por fragmentos de longitud fija.

Tercero, ofrece mejor explicabilidad. La ruta de recuperación puede asociarse con páginas, secciones y nodos del árbol, lo que es más fácil de rastrear que “este texto fue encontrado por similitud vectorial”.

Cuarto, la recuperación es sensible al contexto. La pregunta, el historial de conversación y el conocimiento del dominio pueden influir en la ruta de búsqueda por árbol.

Quinto, se parece más a cómo los expertos humanos leen documentos. Normalmente no cortamos un documento entero en trozos para calcular similitud; primero revisamos el índice, ubicamos capítulos y luego leemos detalles.

Esto no significa que las bases vectoriales no tengan valor. Una forma más precisa de verlo es que PageIndex encaja en escenarios donde “la similitud semántica no basta y se necesita estructura más razonamiento” para recuperar información en documentos largos.

Cómo ejecutarlo localmente

El README ofrece una ruta de autoalojamiento local. Primero instala dependencias:

`1`	`pip3 install --upgrade -r requirements.txt`

Después crea un archivo .env en la raíz del proyecto y escribe la LLM API key. El proyecto admite múltiples modelos mediante LiteLLM:

`1`	`OPENAI_API_KEY=your_openai_key_here`

Genera la estructura PageIndex para un PDF:

`1`	`python3 run_pageindex.py --pdf_path /path/to/your/document.pdf`

También puede procesar Markdown:

`1`	`python3 run_pageindex.py --md_path /path/to/your/document.md`

Parámetros opcionales habituales:

--model
--toc-check-pages
--max-pages-per-node
--max-tokens-per-node
--if-add-node-id
--if-add-node-summary
--if-add-doc-description

El README también advierte que la versión local de código abierto usa parsing PDF estándar. Para PDFs complejos, el servicio cloud del proyecto ofrece OCR mejorado, construcción de árbol y flujo de recuperación.

Ejemplo de Agentic Vectorless RAG

El proyecto también incluye un ejemplo de agentic vectorless RAG usando PageIndex autoalojado y OpenAI Agents SDK. Instala la dependencia opcional y ejecútalo:

1
2

pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

El valor de este ejemplo está en que lleva PageIndex de “generar un árbol documental” a “permitir que un Agent use el árbol para recuperar información”. Si estás construyendo una base de conocimiento empresarial, Q&A sobre informes financieros, preguntas regulatorias o un Agent de documentación técnica, vale más la pena correr este ejemplo que limitarse a leer el README.

Servicio cloud, MCP y API

PageIndex no es solo un GitHub repo. La página del proyecto también ofrece varias entradas:

Autoalojamiento: ejecutar el código abierto en local, adecuado para pruebas y despliegues controlados.
Chat Platform: una plataforma de análisis documental estilo ChatGPT.
MCP / API: útil para integrarse con Agents existentes o flujos de automatización.
Enterprise: orientado a despliegues privados u on-premises.

Esto muestra que su posición no es la de una simple demo. Busca convertir la “recuperación documental basada en razonamiento” en una infraestructura de inteligencia documental integrable.

Escenarios adecuados

PageIndex encaja bien con tareas como:

Preguntas y respuestas sobre PDFs largos.
Análisis de informes financieros, informes anuales, prospectos y documentos regulatorios.
Recuperación en documentos legales y de cumplimiento.
Q&A sobre manuales técnicos.
Recuperación en libros o papers con múltiples secciones.
Bases de conocimiento empresariales que necesitan rutas de recuperación explicables.
Proporcionar contexto documental estructurado a Agents.

Si tu material es corto, tiene poca estructura o es simplemente un FAQ común, embedding + vector DB tradicional puede ser suficiente. Las ventajas de PageIndex aparecen con más claridad en documentos largos, estructura fuerte, dominios profesionales y preguntas que requieren razonamiento.

Aspectos a tener en cuenta

Primero, PageIndex sigue dependiendo de LLMs. La construcción del árbol, los resúmenes y la calidad de recuperación se ven afectados por la capacidad del modelo, los prompts y la calidad del parsing documental.

Segundo, la versión local usa parsing PDF estándar. Documentos escaneados complejos, PDFs con muchas tablas y gráficos, o materiales con maquetación desordenada pueden requerir OCR y preprocesamiento más potente.

Tercero, sin base vectorial no significa coste cero. Construir el árbol también consume llamadas al modelo y tiempo, especialmente en colecciones documentales grandes.

Cuarto, PageIndex se parece más a un marco de indexación estructural y recuperación por razonamiento. No reemplaza directamente todas las pilas RAG. En producción, también puede combinarse con recuperación vectorial, búsqueda por palabras clave, control de permisos, caché y sistemas de auditoría.

Resumen

Lo interesante de PageIndex es que desplaza el foco del RAG desde la “recuperación por similitud textual” hacia “estructura documental + razonamiento LLM”. Para documentos largos y profesionales, esta dirección merece atención.

Si estás construyendo Q&A documental empresarial, análisis de informes financieros, recuperación regulatoria o Agents para manuales técnicos, PageIndex puede servir como referencia de una nueva arquitectura RAG: primero dar estructura al documento y luego dejar que el modelo razone sobre esa estructura, en lugar de trocear todo desde el principio y meterlo en una base vectorial.

Referencias:

GitHub: VectifyAI/PageIndex

OpenKB: compilar documentos en una base de conocimiento LLM que se actualiza continuamente

Sun, 17 May 2026 17:15:08 +0800

OpenKB es una herramienta de base de conocimiento LLM de código abierto creada por VectifyAI.

No es un sistema RAG tradicional que divide documentos en fragmentos, los vectoriza y vuelve a ensamblar contexto en cada consulta. OpenKB primero compila los documentos originales en una wiki estructurada: resúmenes de documentos, páginas de conceptos, referencias cruzadas, consultas posteriores y comprobaciones con lint. En otras palabras, se parece más a una CLI de base de conocimiento que organiza materiales de forma continua.

Proyecto: https://github.com/VectifyAI/OpenKB

La idea principal

OpenKB merece atención por tres razones:

Exporta la base de conocimiento como archivos Markdown normales, no como datos encerrados en una base de datos específica.
Usa PageIndex para procesar PDFs largos, con recuperación de documentos largos sin depender de una base vectorial.
Pone el foco en la “compilación de conocimiento”: el LLM genera resúmenes, páginas de conceptos y enlaces cruzados, en vez de buscar desde cero en cada pregunta.

Esto hace que OpenKB encaje bien en escenarios de acumulación de conocimiento a largo plazo: lectura de papers, documentación de proyectos, materiales internos, normas técnicas, investigación de productos y bases de conocimiento personales.

No es un reemplazo universal. Si necesitas Q&A online de alta concurrencia, permisos complejos, panel web de administración, auditoría empresarial o multitenancy a gran escala, OpenKB hoy se parece más a una herramienta para desarrolladores y a un prototipo de base de conocimiento que a una plataforma empresarial completa.

Qué es OpenKB

OpenKB significa Open Knowledge Base.

Funciona como una CLI: convierte, organiza, resume y genera un conjunto de archivos wiki a partir de los documentos añadidos. El README oficial lo explica de forma directa: OpenKB usa LLMs para compilar documentos originales en una base de conocimiento estilo wiki, estructurada e interconectada, con PageIndex para recuperación de documentos largos sin vectores.

Los formatos de entrada soportados incluyen:

PDF
Word
Markdown
PowerPoint
HTML
Excel
Texto plano
Otros formatos convertibles con markitdown

La base de conocimiento generada vive en wiki/ e incluye principalmente:

index.md: visión general de la base de conocimiento
log.md: línea de tiempo de operaciones
AGENTS.md: estructura e instrucciones de mantenimiento
sources/: textos fuente convertidos
summaries/: resúmenes de cada documento
concepts/: páginas de conceptos entre documentos
explorations/: resultados de consultas guardados
reports/: informes de lint

La mayor ventaja de este diseño es la transparencia. Puedes abrir los archivos Markdown directamente, en lugar de recibir respuestas únicamente desde una interfaz de recuperación opaca.

Diferencia con el RAG tradicional

Un flujo RAG tradicional suele ser:

Dividir los documentos en chunks.
Generar embeddings.
Guardarlos en una base vectorial.
Recuperar fragmentos relevantes al consultar.
Pasar esos fragmentos al LLM para generar una respuesta.

Este flujo está maduro y funciona bien para sistemas de preguntas y respuestas. Pero tiene un problema: el conocimiento no se acumula realmente. Cada pregunta vuelve a buscar fragmentos, recomponer contexto y generar una respuesta.

OpenKB sigue más bien la lógica de “organizar primero, preguntar después”:

Los documentos entran en raw/.
Los documentos cortos se convierten a Markdown mediante markitdown.
Los PDFs largos pasan por PageIndex para generar índices en árbol y resúmenes.
El LLM genera resúmenes de documentos.
El LLM lee páginas de conceptos existentes y crea o actualiza conceptos entre documentos.
Se actualizan el índice, el log y los enlaces cruzados de la base de conocimiento.

El resultado es que añadir un documento no solo crea otro archivo recuperable. Puede actualizar una docena de páginas wiki. El conocimiento se escribe en páginas de conceptos y se conecta con materiales existentes.

Esto se parece más a cómo una persona mantiene una base de conocimiento: cuando llega material nuevo, no basta con archivarlo; también hay que actualizar páginas temáticas, resumir diferencias y añadir referencias.

Qué problema resuelve PageIndex

Los documentos largos siempre han sido difíciles para RAG y para las bases de conocimiento con LLM.

Si divides directamente un PDF largo en muchos chunks, aparecen varios problemas:

Se pierden las relaciones entre capítulos.
Tablas, imágenes y notas al pie son difíciles de manejar.
Los fragmentos recuperados son demasiado pequeños y la respuesta pierde estructura global.
Aunque la ventana de contexto sea grande, no conviene meter todo el documento en el prompt.
Las cadenas largas de resumen pueden comprimir y perder detalles importantes.

OpenKB usa PageIndex para procesar PDFs largos. Según la descripción del proyecto, PageIndex crea índices en árbol y resúmenes para documentos largos, de modo que el LLM razona sobre el árbol del documento en lugar de leer todo el documento directamente.

El punto no es encontrar “los párrafos con mayor similitud vectorial”, sino permitir que el modelo use la jerarquía del documento para localizar contenido relevante. Para informes de investigación, papers, manuales, prospectos y documentos de cumplimiento, esta idea tiene mucho sentido.

OpenKB puede usar por defecto la versión open-source de PageIndex de forma local. Si necesitas OCR, procesamiento de PDFs complejos o generación de estructura más rápida, puedes configurar PAGEINDEX_API_KEY para usar PageIndex Cloud.

Instalación e inicio rápido

OpenKB se puede instalar directamente con pip:

`1`	`pip install openkb`

También puedes instalar la versión más reciente desde GitHub:

`1`	`pip install git+https://github.com/VectifyAI/OpenKB.git`

Instalación editable desde el código fuente:

1
2
3

git clone https://github.com/VectifyAI/OpenKB.git
cd OpenKB
pip install -e .

Crea un directorio para la base de conocimiento:

1
2

mkdir my-kb && cd my-kb
openkb init

Añade documentos:

1
2

openkb add paper.pdf
openkb add ~/papers/

Haz una pregunta:

`1`	`openkb query "What are the main findings?"`

Inicia un chat interactivo:

`1`	`openkb chat`

Si quieres que OpenKB procese nuevos archivos automáticamente, usa el modo watch:

`1`	`openkb watch`

Después, coloca archivos en raw/ y OpenKB actualizará la wiki automáticamente.

Configuración del LLM

OpenKB usa LiteLLM para soportar varios proveedores de modelos, incluidos OpenAI, Claude y Gemini.

Puedes establecer el modelo durante la inicialización o configurarlo en .openkb/config.yaml:

1
2
3

model: gpt-5.4
language: en
pageindex_threshold: 20

Los nombres de modelos siguen el formato provider/model de LiteLLM. Los modelos de OpenAI pueden omitir el prefijo del proveedor:

`1`	`model: gpt-5.4`

Modelos como Anthropic y Gemini suelen escribirse así:

`1`	`model: anthropic/claude-sonnet-4-6`

`1`	`model: gemini/gemini-3.1-pro-preview`

La API key va en .env:

`1`	`LLM_API_KEY=your_llm_api_key`

Si activas PageIndex Cloud, añade:

`1`	`PAGEINDEX_API_KEY=your_pageindex_api_key`

Comandos habituales

Los comandos de OpenKB son cómodos para desarrolladores:

openkb init: inicializa una nueva base de conocimiento.
openkb add <file_or_dir>: añade un archivo o directorio.
openkb remove <doc>: elimina un documento y limpia páginas wiki, imágenes, registro y estado de PageIndex relacionados.
openkb query "question": hace una pregunta puntual sobre la base de conocimiento.
openkb chat: entra en una conversación de varios turnos.
openkb watch: vigila raw/ y actualiza automáticamente.
openkb lint: comprueba la estructura y la salud del contenido.
openkb list: lista documentos y conceptos indexados.
openkb status: muestra estadísticas de la base de conocimiento.

openkb chat es más adecuado que openkb query para exploración continua. Soporta reanudar sesiones, listarlas y eliminarlas, y también permite slash commands como /status, /list, /add <path>, /save y /lint.

Por qué importa una wiki Markdown

El problema de muchas herramientas de conocimiento es el coste de migración.

Cuando el material entra en una base de datos, índice o formato propietario, es difícil inspeccionarlo, editarlo, respaldarlo o migrarlo directamente. OpenKB escribe el resultado como Markdown normal, lo que lo hace compatible de forma natural con herramientas existentes.

El uso más directo es abrir wiki/ con Obsidian:

Las páginas de resumen se pueden leer directamente.
Las páginas de conceptos pueden conectarse con [[wikilinks]].
La vista de grafo muestra relaciones entre conocimientos.
Los resultados de consultas pueden guardarse en explorations/.
AGENTS.md puede definir cómo se mantiene la base de conocimiento.

Así OpenKB no es solo una herramienta de Q&A; también puede convertirse en una canalización de organización de conocimiento para personas o equipos.

Escenarios adecuados

OpenKB encaja especialmente bien en:

Lectura de papers e informes técnicos.
Organización de documentación de proyectos.
Archivos de investigación de producto.
Bases de conocimiento documentales alrededor de proyectos open-source.
Organización de normas internas, actas de reuniones y documentos explicativos.
Mantenimiento automático de una base personal en Obsidian.
Estructuración de PDFs largos, PPTs, archivos Word y materiales web.

Si trabajas a menudo con montones de documentos y no solo quieres “hacer una pregunta y obtener una respuesta”, sino convertir esos materiales en una base navegable, reutilizable y trazable, OpenKB va en la dirección correcta.

Aspectos a tener en cuenta

Primero, OpenKB depende de la calidad del LLM.

Resúmenes, páginas de conceptos y enlaces cruzados son generados por el modelo. Cuanto más fuerte sea el modelo, más estable será la compilación de conocimiento; si el modelo es débil, la extracción de conceptos, detección de contradicciones y síntesis entre documentos se resentirán.

Segundo, conviene estimar costes desde el principio.

Si importas muchos documentos largos a la vez, las llamadas al LLM pueden ser caras. Es mejor probar con un conjunto pequeño, verificar estructura y calidad, y luego ampliar.

Tercero, la wiki generada aún necesita revisión humana.

OpenKB puede organizar materiales, pero no garantiza automáticamente que todos los hechos sean correctos. Las bases de conocimiento importantes siguen necesitando revisión humana de resúmenes, conceptos y referencias.

Cuarto, cuidado con materiales sensibles.

Si usas LLMs en la nube o PageIndex Cloud, presta atención a privacidad, secretos comerciales y requisitos de cumplimiento. Para material interno, conviene confirmar primero el proveedor del modelo, la política de retención de datos y los límites de acceso.

Quinto, por ahora es más una herramienta CLI.

El roadmap menciona una futura Web UI, almacenamiento con base de datos, soporte para grandes colecciones e indexación jerárquica de conceptos. En la etapa actual, si el equipo no está cómodo con la línea de comandos, todavía habrá fricción de adopción.

Relación con Obsidian, NotebookLM y RAG empresarial

La relación entre OpenKB y Obsidian se entiende mejor como una “capa de organización automática” más una “capa de lectura y edición”.

Obsidian es bueno para que las personas escriban, editen, naveguen y creen enlaces. OpenKB es bueno para convertir documentos originales en una wiki que pueda entrar en Obsidian.

OpenKB y NotebookLM se diferencian más por control local y formato abierto.

NotebookLM ofrece una experiencia más directa para cargar materiales, preguntar y generar resúmenes rápidamente. OpenKB encaja mejor cuando un desarrollador quiere dejar el resultado organizado en un directorio local y seguir manteniéndolo como Markdown.

OpenKB no sustituye al RAG empresarial; lo complementa.

El RAG empresarial prioriza permisos, auditoría, despliegue como servicio, aislamiento de acceso, monitoreo y throughput estable. OpenKB sirve mejor para construir una capa de conocimiento legible, editable y acumulable. Si más adelante construyes Q&A online, la wiki generada por OpenKB también puede ser un corpus de mayor calidad.

Un flujo recomendado

Si quieres probar OpenKB, puedes empezar así:

Crea un directorio de prueba para la base de conocimiento.
Añade de 3 a 5 documentos sobre el mismo tema.
Ejecuta openkb add.
Abre wiki/ y revisa resúmenes y páginas de conceptos.
Haz algunas preguntas concretas con openkb query.
Ejecuta openkb lint para revisar la salud de la base.
Abre wiki/ en Obsidian y mira si el grafo de enlaces tiene sentido.
Cuando la calidad sea aceptable, importa una colección más grande.

No metas cientos de archivos desde el principio. Primero comprueba si entiende bien tu tipo de material, especialmente tablas, imágenes, PDFs largos y fusión de conceptos entre documentos.

Resumen

El valor de OpenKB está en adelantar un paso el flujo de una base de conocimiento LLM: en vez de armar contexto temporalmente al consultar, primero organiza los materiales como wiki y luego permite preguntar, chatear, revisar y seguir manteniendo esa wiki.

Esta ruta no sirve para todos los sistemas de Q&A, pero sí para trabajo de conocimiento que necesita acumulación a largo plazo. Archivos Markdown, compatibilidad con Obsidian, manejo de documentos largos con PageIndex, soporte multi-modelo y flujo CLI forman una herramienta útil para desarrolladores y usuarios orientados a investigación.

Si tienes muchos PDFs, informes, páginas web, papers y documentos de proyecto, vale la pena probar OpenKB. Quizá no reemplace de inmediato una base de conocimiento empresarial madura, pero puede ser una entrada práctica para organizar materiales: primero convierte documentos en conocimiento legible, enlazado y trazable, y luego deja que el LLM trabaje sobre esa base.

Referencias: