Cuando los Clientes Piden RAG en 2026: Nuestro Árbol de Decisión (y Por Qué Raramente Empezamos por Ahí)

Seguimos construyendo pipelines de RAG para los clientes que lo solicitan, pero en 2026 rara vez los recomendamos primero. El stack de herramientas para agentes de 2024, el que convirtió la generación aumentada por recuperación en la respuesta predeterminada a cualquier pregunta sobre conocimiento, quedó en gran medida obsoleto entre enero y abril de este año. Esta publicación presenta el árbol de decisión que recorremos con cada prospecto y el stack que entregamos cuando el árbol apunta en otra dirección.

La mayoría de las agencias que venden RAG hoy en día están vendiendo un manual de 2024. Es probable que ya le hayan presentado uno: una línea de base de datos vectorial, una estrategia de fragmentación, un cron de reindexado, un roadmap de seis meses antes de que el sistema responda su primera pregunta. Si ya tiene una propuesta sobre su escritorio, envíenosla antes de firmar y recorreremos el árbol juntos. A continuación explicamos por qué cambió la forma en que se le dijo que debía construir agentes con conciencia de contexto, y qué entregamos en su lugar.

Conclusiones Clave

• Construimos RAG cuando los clientes insisten. Rara vez lo recomendamos primero en 2026. El cambio en las herramientas es real, y nuestro trabajo es señalarlo antes de que usted firme.

• Sam Hogan declaró obsoleto la mayor parte del stack de herramientas de LLM de 2024 el 18 de abril de 2026. RAG, orquestación multi-agente, frameworks ReAct, gestión de prompts, LLMOps, herramientas de evaluación, gateways, bibliotecas de fine-tuning. Los conceptos siguen siendo válidos. Las implementaciones populares se quedaron atrás respecto al salto de los modelos.

• Zep cambió su posicionamiento de memoria a context engineering. Que una empresa financiada renombre su propia categoría es la señal de mercado más clara de hacia dónde se dirige la infraestructura para agentes.

• Los skill graphs reemplazaron la búsqueda vectorial como nuestro sustrato predeterminado. Una carpeta de archivos markdown más cinco comandos de shell resuelve más trabajos de clientes que cualquier pipeline de RAG que hayamos entregado.

• RAG sigue siendo válido en cuatro trabajos específicos. Corpus multimodales, millones de documentos con alta frecuencia de actualización, filtros de metadatos estrictos en tiempo de recuperación y contenido adversarial no confiable. Todo lo demás es un skill graph.

El Árbol de Decisión que Ejecutamos Antes de Construir Cualquier Cosa

Cada compromiso con un cliente comienza con las mismas cuatro preguntas, y nueve de cada diez veces las respuestas apuntan en dirección contraria a RAG. Construimos este árbol a partir de una encuesta de 450 repositorios sobre herramientas de memoria de agentes y gestión de contexto en GitHub, publicada el 15 de abril de 2026. Casi nadie traza la línea entre los dos de forma explícita. Nosotros sí lo hacemos, porque esa línea determina el costo.

La mayoría de los corpus de clientes que vemos son wikis internas, playbooks de ventas, guías de incorporación, documentación de producto y SOPs. Pequeños, estables, mantenidos por pocas personas. Todos esos son trabajos para un skill graph. El argumento del corpus pequeño con cifras reales y la guía completa de configuración de la capa de conocimiento cubren la versión práctica.

Qué Quedó Obsoleto Entre Enero y Abril de 2026

Sam Hogan publicó el diagnóstico más preciso del cambio el 18 de abril de 2026. Su tesis: la mayor parte de la categoría de herramientas de LLM fue construida para un mundo que ya no existe en su mayoría, y gran parte quedó obsoleta en los tres meses anteriores. La lista que mencionó:

• RAG y GraphRAG. El enfoque de recuperación construido para ventanas de contexto menores a 32K.

• Frameworks de orquestación multi-agente. Las capas de coordinación codificadas a mano desplazadas por la coordinación a nivel de runtime.

• Frameworks ReAct. Andamiajes de razonamiento estructurado que los modelos más recientes producen sin necesidad de andamiaje.

• Herramientas de gestión y versionado de prompts. Construidas para un mundo donde los prompts eran el activo. Ahora los activos son los skills y los sustratos de contexto.

• Stacks de LLMOps. Ahora más orientados al rastreo de agentes que a la gestión de prompts de un solo turno.

• Herramientas de evaluación, gateways, bibliotecas de fine-tuning. Cada una construida para un comportamiento de modelo que cambió.

Precisión importante del propio Hogan: los conceptos siguen siendo valiosos. Lo que quedó obsoleto son las implementaciones populares actuales. Algunas herramientas, concedió CrewAI explícitamente, todavía tienen vigencia. Su afirmación más profunda es la que importa para los clientes: los modelos frontera recientes con ventanas de contexto muy largas resolvieron en gran medida el problema de recuperación de hechos que RAG fue diseñado para sortear.

La señal de mercado más fuerte llegó de Zep, una empresa financiada en el espacio de memoria para agentes. Cambiaron todo su posicionamiento de memoria a context engineering. MemSearch, de la empresa de bases de datos vectoriales Zilliz, lanzó un sistema donde su propia base de datos vectorial se sitúa aguas abajo de archivos markdown simples. Que un proveedor de bases de datos vectoriales conceda que los archivos poseen el conocimiento y que el índice es la capa de acceso es el tipo de señal que tarda años en leerse en un comunicado de prensa y semanas en leerse en una actualización de producto.

Qué Reemplazó a RAG en la Mayor Parte del Trabajo con Agentes

La encuesta de 450 repositorios clasificó la memoria de agentes en dos grupos. El primero es el de los backends de memoria: extraen hechos de conversaciones, los almacenan en bases de datos vectoriales y los recuperan a pedido. Mem0 (53.100 estrellas en GitHub), MemPalace (46.200), Honcho, Cognee. Optimizados para la recuperación.

El segundo grupo es el de los sustratos de contexto: contexto estructurado y legible por humanos que se acumula entre sesiones. Zep se ubica aquí ahora. OpenClaw (358.000 estrellas) es la implementación de referencia. El vault que produce esta publicación es un sistema del segundo grupo.

El ciclo habitual del segundo grupo: el agente lee el contexto estructurado, trabaja dentro de él, escribe de vuelta, y en la siguiente sesión el contexto es más rico. Sin estrategia de fragmentación, sin modelo de embeddings que mantener, sin proceso batch de reindexado, sin suite de evaluación de recuperación. Una carpeta de archivos markdown con wikilinks entre ellos, un archivo de índice en la raíz y un puñado de comandos de lectura y escritura. Ese es el sustrato.

Shiv Sakhuja publicó el modelo de composición para este sustrato el 23 de abril de 2026, como Skill Graphs 2.0. Tres niveles: átomos (primitivas de propósito único, casi deterministas), moléculas (tareas delimitadas que componen entre 2 y 10 átomos con encadenamiento explícito), compuestos (orquestadores multi-molécula con autonomía real del agente, guiados por humanos hoy). El framework limita la profundidad del grafo de dependencias, lo que lo hace confiable donde los skill graphs planos se desvían silenciosamente más allá de tres o cuatro saltos. Para los clientes, esto se traduce en la estructura de costos: los átomos son económicos y deterministas, las moléculas son donde vive el trabajo de ingeniería, los compuestos son donde se presupuesta un operador humano.

Los Casos Límite Donde RAG Sigue Siendo la Elección Correcta

Somos una agencia. Entregamos lo que el trabajo necesita. RAG sigue superando a un skill graph en cuatro clases específicas de trabajo, y lo recomendaremos cuando el árbol de decisión llegue ahí:

• Corpus multimodales. PDFs con tablas, documentos escaneados, transcripciones de audio, informes con muchas imágenes. Un grafo de markdown asume que todo se reduce a texto. Cuando no es así, la recuperación más el embedding multimodal es la solución más adecuada.

• Actualizaciones de alta frecuencia a escala. Millones de documentos que cambian por minuto y que deben poder consultarse en segundos desde su publicación. El costo de reindexado de una base de datos vectorial es menor que el costo humano de mantener un archivo de índice a ese volumen.

• Filtrado estricto de metadatos en tiempo de recuperación. Cuando las consultas deben filtrar por rangos de fechas, tipo de documento o autor antes de ejecutar la búsqueda semántica, las bases de datos vectoriales con conciencia de metadatos como Pinecone y Qdrant realizan la composición de forma limpia.

• Contenido no confiable o adversarial. Cuando el corpus proviene de muchos autores con agendas en conflicto y ningún humano puede encargarse de mantener un índice curado, conviene usar recuperación que no asuma supervisión editorial.

Si su proyecto cae en uno de esos cuatro casos, RAG es la herramienta correcta y lo construiremos. Si no es así, el skill graph es más barato de entregar, más barato de operar y más fácil de mantener. Hable con nosotros antes de encargar cualquiera de los dos y recorreremos el árbol de decisión con su corpus específico.

Qué Usamos Internamente y Qué Hemos Entregado a Clientes

Nuestra wiki interna tiene 22 páginas de conocimiento estructurado, mantenidas con cinco comandos de shell. Sin base de datos vectorial, sin embeddings, sin cron de reindexado. La configuración completa está en nuestra publicación anterior.

Este mismo sustrato produce el blog de webvise que usted está leyendo: 76 publicaciones traducidas a 7 idiomas a través de un único skill graph de contenido. Sin equipo de contenido. Sin red de freelancers. Un skill, siete salidas por publicación, entregadas desde la misma carpeta que la documentación de ingeniería.

En el lado de los clientes, nuestro trabajo de producción con agentes se apoya en la misma arquitectura. Hermes, la plataforma de agentes auto-mejorables que documentamos el mes pasado, funciona con skills robustos y un runtime ligero. Paperclip, nuestro sistema de orquestación de IA para toda la empresa, compone moléculas sobre una base de conocimiento en markdown. Ninguno tiene una base de datos vectorial en el stack de producción y ninguno la ha necesitado.

Garry Tan cuenta la misma historia desde YC. Su CLAUDE.md personal comenzó con 20.000 líneas, con cada particularidad, cada patrón, cada lección que había encontrado. La atención del modelo se degradó bajo ese peso, y el propio Claude Code le indicó que lo redujera.

Su solución fue 200 líneas de punteros a documentos que se cargan bajo demanda. Las 20.000 líneas completas siguen existiendo, pero el modelo las lee solo cuando son relevantes. Su biblioteca gstack alcanzó 23.000 estrellas en GitHub en su primera semana y entregó 600.000 líneas de código de producción en 60 días. El sustrato escala porque el sustrato son archivos, no infraestructura.

Qué Preguntar a un Proveedor Antes de Firmar un Contrato de RAG en 2026

Si ya tiene una propuesta de RAG sobre su escritorio, haga estas cinco preguntas antes de firmar:

• ¿Cuál es el tamaño del corpus hoy y en 24 meses? Si en ambos casos es menor de 1.000 documentos, la base de datos vectorial es una línea de presupuesto que no necesita.

• ¿Quién escribe el contenido? Si son pocas personas internas que se preocupan por la precisión, un archivo de índice mantenido supera a los embeddings en calidad de recuperación. Si son miles de autores adversariales o anónimos, RAG gana.

• ¿Con qué frecuencia se actualiza? Si cambia una vez a la semana, no necesita un pipeline de reindexado. Si cambia cada minuto a escala, sí lo necesita.

• ¿La consulta requiere filtros estrictos de metadatos en tiempo de recuperación? Si es así, una base de datos vectorial con conciencia de metadatos se justifica. Si no, la lógica de filtrado es más económica de ejecutar en la capa de skill.

• ¿Cómo se ve la cotización del proveedor en 18 meses? Los costos de las bases de datos vectoriales se componen con el crecimiento de documentos. Los costos del skill graph no. La diferencia importa en la renovación.

Si las respuestas apuntan hacia RAG, construya RAG. Si apuntan hacia un skill graph, la parte difícil es desaprender el manual de 2024. En webvise, recorremos el árbol de decisión con usted sobre su corpus real, entregamos la arquitectura a la que apunta el árbol y destinamos el ahorro al trabajo que realmente necesita el presupuesto. Contáctenos antes de que el proveedor que escuchó en un podcast le envíe la factura.