¿RAG vectorial, indexación o grafos? Cómo elegir la forma en que tu LLM recupera información en 2026

Arranco una serie corta de "field" notes sobre lo que los que estan construyendo —comparando notas en la trinchera— están usando hoy en día. Primer tema: cómo sacamos información de los documentos, porque la respuesta que todos adoptaron por defecto durante dos años se está cuestionando en silencio.

Esa respuesta por defecto es RAG: partís tus documentos en chunks, los embebés, los guardás en una base de datos vectorial, recuperás los top-k más cercanos a una pregunta y los metés en el prompt [1]. Funciona, y por un tiempo fue el reflejo —la jugada que hacés antes de haber mirado bien el problema—. Últimamente, en las comunidades de developers que sigo, veo que ese reflejo se cuestiona cada vez más. Un hilo reciente lo resumió bien: algunos ya prefieren la "indexación" al RAG por velocidad y simplicidad, otros defienden el RAG para corpus empresariales grandes, y unos cuantos están yendo hacia los grafos. La señal útil no es quién ganó, sino que el debate esté pasando. Eso suele significar que un default se está corriendo.

Hacé coincidir el método de recuperación con la forma de tus datos — y medí lo que elijas.

Qué quiere decir el bando de la "indexación"

La versión más visible del argumento vino de Andrej Karpathy, cuyo post de 2026 sobre "bases de conocimiento para LLMs" circuló mucho [2]. La idea: en lugar de usar el modelo solo como chatbot, hacer que compile la información cruda en una wiki viva e interconectada en Markdown —artículos más un índice— que va creciendo y reorganizando con el tiempo. Su afirmación es que, una vez que la wiki está bien estructurada, conseguís razonamiento multi-hop sólido sin ninguna base de datos vectorial: el modelo lee el índice y las páginas relevantes, igual que haría una persona.

PageIndex, liberado como open-source por VectifyAI, es ese instinto convertido en herramienta [3][4]. Sin embeddings, sin chunking: construye un árbol jerárquico de tabla de contenidos de un documento y deja que el modelo razone hacia abajo —elige el capítulo, después la sección, y responde con una cita—. El enfoque está explícitamente inspirado en la búsqueda en árbol de AlphaGo. En FinanceBench —un benchmark de presentaciones reales ante la SEC, donde el chunking suele destrozar las tablas— reportan alrededor de 98,7% de exactitud frente a aproximadamente 50% del RAG vectorial tradicional [5].

Eso reformula todo en una línea: el RAG vectorial pregunta "¿qué es lo más cercano a esta pregunta en el espacio vectorial?", mientras que la indexación pregunta "¿dónde buscaría un lector atento?". Para algunos problemas, la segunda pregunta es sencillamente la mejor.

Dónde los vectores siguen ganando

En mi trabajo de consultoría para empresas armé un framework de RAG reutilizable para detección de cambios regulatorios en el sector energético —corpus grandes, desordenados y multilingües, donde un equipo de compliance necesita detectar qué cambió de un año a otro—. Ese es el terreno natural de los vectores: millones de pasajes no estructurados, la misma obligación redactada de diez formas distintas, sin una tabla de contenidos limpia para navegar. Lo que lo hizo confiable, igual, no fue el almacén vectorial: fue que medimos la calidad de la recuperación con herramientas como Ragas y Langfuse [6][7] en vez de adivinar.

Dónde recurrí a los vectores por costumbre

Como contraste, un asistente de ventas por WhatsApp que construí para un cliente de retail. "Recuperación sobre un catálogo de productos", así que —RAG, obvio—. Salvo que el catálogo era modesto y muy estructurado: categorías, tipos de local, dimensiones de góndola. Lo difícil era respetar esa estructura y controlar el costo (migramos la capa vectorial de pgvector a DynamoDB + FAISS sobre todo por economía). Visto en retrospectiva, buena parte de eso era una búsqueda estructurada disfrazada de RAG: un modelo recorriendo un índice limpio habría hecho gran parte del trabajo con mucha menos infraestructura.

Una forma de decidir

Tres preguntas, antes de "¿qué base vectorial?":

1. ¿Qué tan grande y desordenado es el corpus? Millones de pasajes no estructurados y llenos de paráfrasis apuntan a vectores. Unos pocos cientos de documentos bien organizados apuntan a un índice que el modelo pueda navegar —más fácil de construir y de debuggear—.

2. ¿Dónde vive la respuesta? Si solo se puede armar leyendo a lo ancho y conectando menciones dispersas —"cualquier cosa que toque los límites térmicos a lo largo de estos informes"—, eso es recall semántico, y los vectores están hechos para eso. Si está en un único lugar conocible —"la cláusula de garantía del contrato de 2024", "la ficha técnica del producto X"—, eso es una búsqueda navegable, donde un índice le gana a adivinar por vecino más cercano.

3. ¿Lo podés medir? Elijas lo que elijas, instrumentalo antes de confiar en ello —la vieja frase de Tom DeMarco, "no podés controlar lo que no podés medir", sigue valiendo [8]—. Elegí la opción más liviana, puntuá su recuperación y dejá que los números te digan cuándo sumar complejidad.

Y muchas veces, la respuesta es ambas

Los sistemas más fuertes no eligen una tribu: un filtro barato achica el espacio, los vectores se encargan del recall semántico dentro de ese espacio, y una capa de grafos entra cuando las relaciones entre documentos —citas, dependencias— son la verdadera señal. GraphRAG de Microsoft es una buena referencia para esa última pieza [9].

Hacia dónde va esto

Hay un cambio más grande escondido dentro de la idea de la indexación. Una vez que una base de conocimiento es algo que el modelo lee, navega y reescribe, básicamente describiste cómo funcionan los nuevos "harnesses" de agentes —agentes que usan un sistema de archivos como scratchpad y memoria de largo plazo en lugar de meter todo en la ventana de contexto—. Los Deep Agents de LangChain lo hacen concreto con "backends" enchufables para exactamente eso [10][11], y se alinea con cómo equipos como Anthropic describen hoy la construcción de agentes efectivos [12]. Esa convergencia —la recuperación y la memoria de los agentes volviéndose el mismo problema— es hacia donde va esta serie.

Por ahora, la línea que atraviesa todo, de boca de los que están shippeando de verdad: el default merece una segunda mirada. Hacé coincidir el mecanismo con la forma de tus datos, mantenelo lo más liviano posible, y medí antes de sumar.

¿Qué estás usando vos últimamente, y dónde se te rompe? Estoy juntando estas field notes, así que respondé y contame.

Referencias

1. Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (2020) — arxiv.org/abs/2005.11401
2. A. Karpathy, post sobre "LLM knowledge base" (2026) — x.com/karpathy/status/2039805659525644595
3. PageIndex (VectifyAI), GitHub — github.com/VectifyAI/PageIndex
4. PageIndex, "Vectorless, Reasoning-based RAG" — pageindex.ai/blog/pageindex-intro
5. FinanceBench (Patronus AI) — arxiv.org/abs/2311.11944 · cobertura del resultado — VentureBeat
6. Ragas (evaluación de RAG) — docs.ragas.io
7. Langfuse (observabilidad de LLMs) — langfuse.com
8. T. DeMarco, Controlling Software Projects (1982) — Wikiquote
9. Microsoft GraphRAG — github.com/microsoft/graphrag · paper — arxiv.org/abs/2404.16130
10. LangChain Deep Agents, docs — docs.langchain.com/oss/python/deepagents/overview
11. LangChain, "How agents can use filesystems for context engineering" — blog.langchain.com
12. Anthropic, "Building Effective Agents" — anthropic.com/research/building-effective-agents