grep superó a la búsqueda vectorial en pruebas de memoria de agentes, y el sistema de integración fue igualmente importante.

Los sistemas de recuperación mejorada por información han se basado durante mucho tiempo en una creencia: la recuperación vectorial supera a la búsqueda por palabras clave porque captura el significado. Una solicitud de “documentos sobre ganancias trimestrales” encuentra un “informe de ingresos del Q3”, aunque las dos frases no compartan palabras, ya que el espacio de embedding las considera similares. Esa creencia ha impulsado enormes inversiones en infraestructura, desde Pinecone y Weaviate hasta Chroma y Qdrant. Los primeros trabajos sobre recuperación de pasajes densos demostraron que superaba al algoritmo escaso BM25 en la respuesta a preguntas en dominios abiertos; el campo adoptó esos resultados y la búsqueda vectorial se convirtió en la opción por defecto.

Un estudio de 2026 realizó un experimento diferente. A los agentes se les asignó una tarea de recuperación de información proveniente de LongMemEval, una prueba de referencia en la que un agente debe responder preguntas buscando entre historiales de conversaciones extensos. La prueba comparó el método grep, que consiste en una búsqueda exacta de cadenas de texto, con la recuperación vectorial. Se llevó a cabo en varios entornos para agentes: uno personalizado llamado Chronos, además de las herramientas de línea de comandos propias de los proveedores, como Claude Code, Codex y Gemini CLI.

En la configuración principal, grep superó a la recuperación vectorial en términos de precisión, y lo hizo en todos los entornos, no solo en uno.

La versión resumida

• Configuración: 116 preguntas de LongMemEval, comparación entre grep y recuperación vectorial, cuatro entornos, datos de conversación idénticos.
• Resultado principal: al mostrar los resultados directamente, grep superó a la recuperación vectorial en precisión en todos los casos en los que se probó.

Segundo hallazgo: el arnés tenía casi la misma importancia que el método de recuperación. El mismo enfoque de recuperación produjo niveles de precisión muy diferentes con arneses distintos.

Por qué grep gana aquí: las preguntas buscan hechos específicos: nombres, fechas, frases exactas. La similitud semántica añade ruido a ese tipo de búsquedas, ya que grep devuelve la cadena en sí mientras que la búsqueda vectorial devuelve pasajes que solo se le asemejan.

El problema del arnés: la forma en que se muestra el resultado de una herramienta al modelo determina si este lo utiliza correctamente. Un resultado perfecto presentado de mala manera se desperdicia.

La pregunta complicada: ¿hasta qué punto la ventaja atribuida a una mejor recuperación en los sistemas RAG en producción se debe realmente a un mejor diseño del arnés?

Por qué grep es adecuado para preguntas sobre memoria

El mecanismo es fácil de explicar. LongMemEval pregunta cosas como qué restaurante alguien mencionó como su favorito en una conversación en una fecha determinada, o el título de un libro que una persona recomendó. Cada respuesta es una cadena específica que se encuentra en algún punto de la historia.

La recuperación vectorial incrusta la pregunta, encuentra segmentos de conversación con incrustaciones cercanas y los devuelve. El problema es que estar cerca en significado no es lo mismo que contar con el hecho exacto. Un segmento sobre comida en general se encuentra cerca de “restaurante favorito” en el espacio de incrustaciones. Puede que nunca nombre al restaurante, pero aún así obtiene una alta clasificación y no contiene respuesta alguna.

Buscar con grep la palabra “restaurante” devuelve todos los segmentos que incluyen esa palabra, incluido aquel en el que se mencionó el favorito. grep es preciso, mientras que la recuperación vectorial es aproximada; para búsquedas de hechos exactos, la aproximación solo añade ruido.

Vector retrieval:  high recall on semantically related segments
                   lower precision on exact-fact queries
                   noise from semantically similar but fact-absent segments

grep:              perfect precision on string matches
                   lower recall on paraphrased or implicit facts
                   no noise from semantic neighbors

Las preguntas del benchmark están redactadas de tal manera que exigen una recuperación exacta, por lo que la distribución de evaluación favorece la coincidencia exacta de cadenas de texto. Esto no demuestra que grep sea mejor que la recuperación vectorial en general; muestra que es la distribución de tareas la que determina qué método gana. La pregunta relevante es cuál es la verdadera combinación de tareas de recuperación en las implementaciones de agentes en producción, y qué método prevalece en esa combinación.

El efecto harness

El hallazgo más importante no es el uso de grep con vectores, sino el sistema de soporte utilizado. Con el mismo método de recuperación, los mismos datos y las mismas preguntas, la precisión varía mucho dependiendo del sistema de soporte. Las cifras presentadas muestran la magnitud de esta diferencia: un modelo Claude Opus alcanza el 93,1% con Chronos y el 76,7% con Claude Code; por lo tanto, cambiar el sistema de soporte tiene un efecto similar al cambiar el herramienta de recuperación dentro de un mismo sistema de soporte. La mayor diferencia entre grep y los métodos basados en vectores se observó en Chronos con Gemini 3,1 Flash-Lite, con un 86,2% frente al 62,9%.

Un sistema de soporte realiza cuatro funciones:

1. Llama a la herramienta de recuperación con una consulta.
2. Recibe los resultados.
3. Presenta esos resultados al modelo.
4. El modelo analiza esos resultados para responder.

Para un método de recuperación dado, los pasos uno, dos y cuatro son los mismos en todas partes. El paso tres difiere, y la forma en que se presentan los resultados cambia lo que el modelo hace con ellos. Las opciones de presentación incluyen las siguientes:

• Formato: una lista ordenada, el mejor resultado o todo concatenado.
• Contexto: si cada resultado incluye su fuente, marca de tiempo y texto circundante.
• Resaltado: si la parte relevante se marca o si el modelo debe buscar dentro de ella.
• Filtrado: si los resultados de baja confianza se descartan o si se muestran todos.

Nadie ha estandarizado estas opciones, y cada proveedor crea su propia interfaz de línea de comandos. Resultó que el estilo de entrega era de gran importancia. Entregar los resultados directamente favorecía a grep, mientras que pasarlos como archivos para que el modelo los leyera por separado modificaba la comparación: la recuperación vectorial superó a grep en aproximadamente la mitad de las combinaciones de conjuntos de datos y modelos. Una configuración de Codex pasó del 93.1% con grep en formato inline al 55.2% cuando los resultados de grep se entregaron como archivos.

Si es así, los estudios que comparan métodos de recuperación manteniendo constante el conjunto de datos podrían estar midiendo la variable incorrecta. Un recuperador mejor dentro de un conjunto de datos peor puede perder frente a un recuperador peor dentro de uno mejor.

Incorporación de elementos distractores

Un segundo experimento partió de los pasajes de conversación correctos e incorporó cantidades cada vez mayores de historial de conversación no relacionado, luego monitoreó la precisión a medida que aumentaba la interferencia.

Ambos métodos pierden precisión a medida que aumentan los elementos distractores, lo cual es esperado. Sin embargo, las curvas son diferentes: en las consultas basadas en hechos exactos, grep se degrada de manera más gradual. Cuando el pasaje relevante contiene la cadena de la consulta, grep la encuentra sin importar cuántos elementos distractores la rodeen, ya que estos no coinciden con la cadena y nunca aparecen en los resultados.

La recuperación vectorial disminuye más rápidamente. Los elementos distractores que se asemejan semánticamente a la consulta sí aparecen en los resultados, por lo que la proporción de resultados útiles entre los primeros resultados disminuye a medida que aumenta el ruido, y el modelo debe buscar la respuesta entre un conjunto más caótico.

Accuracy = f(retrieval_precision × harness_quality)

grep retrieval precision: high for exact facts, stable with distractors
vector retrieval precision: moderate, degrades with semantically similar distractors

Para los agentes que trabajan con grandes almacenamientos de contexto mixto, que cuentan con historiales de conversación extensos, varios tipos de documentos y un nivel de relevancia desigual, esa resistencia a los factores distractores representa una verdadera ventaja práctica en tareas que requieren precisión factual.

Qué significa esto para la literatura sobre recuperación de información

Los artículos que comparan la recuperación densa con la dispersa, los modelos de embedding o las estrategias de reclasificación suelen mantener constante el marco de trabajo y variar únicamente el recuperador, tratando dicho marco como un valor fijo. Los hallazgos aquí indican que no es un valor fijo; interactúa con el método de recuperación. Un marco de trabajo ajustado para la recuperación vectorial podría dar resultados deficientes con métodos como grep, y lo mismo ocurre al revés.

Es posible que los métodos de recuperación hayan sido ajustados teniendo en cuenta marcos de trabajo que favorecen los enfoques vectoriales. Las comparaciones absolutas podrían seguir siendo válidas, pero no las clasificaciones relativas.

En la práctica, los equipos que desarrollan RAG agente invierten mucho esfuerzo en elegir modelos de embedding, proveedores de bases de datos vectoriales y métricas de similitud. Pocos dedican un esfuerzo comparable al mecanismo que muestra los resultados de recuperación al modelo. Estos resultados sugieren que dicho mecanismo merece al menos tanta atención en el ámbito de la ingeniería como el propio sistema de recuperación, pero la práctica ingenieril aún no ha puesto eso en práctica.

Leer los resultados con cuidado

Probablemente este campo de trabajo no recibirá la atención que merece, y no porque los resultados sean deficientes. Son inconvenientes para una industria basada en la búsqueda vectorial, ya que a veces grep resulta más eficaz y el diseño de los mecanismos de recuperación se subestima.

Deben leerse con atención igualmente. LongMemEval tiene una distribución de tareas específica que favorece la recuperación de hechos exactos, y el liderazgo de grep en este aspecto no implica que gane en todas las situaciones. La recuperación semántica rinde mejor en tareas con abundante paráfrasis, en la recuperación interlingüística y en consultas a nivel conceptual. El estudio también analizó evidencias de chats multisecciónales palabra por palabra, y la recuperación híbrida o bases léxicas más potentes no formaron parte de él.

La conclusión no es utilizar grep. Hay que adaptar el método de recuperación a la distribución de las tareas, e ingenierizar el sistema de soporte con la misma cuidadosidad que el propio mecanismo de recuperación. Ninguno de estos enfoques es aún una práctica estándar, pero ambos deberían serlo.

Preguntas para su propio sistema

Para las tareas de recuperación agente en su sistema en producción, ¿qué proporción necesita una recuperación de hechos exactos y qué proporción necesita una coincidencia de conceptos semánticos? ¿Y cuándo fue la última vez que revisó cómo su sistema presenta los resultados con el mismo cuidado que puso en la elección del modelo de embedding?

Leer más

• RAG agente: Dejar que el LLM decida cuándo y dónde recuperar información — Por qué el RAG estático falla en preguntas de múltiples pasos y sensibles al tiempo, y cómo un agente LangGraph dirige la búsqueda entre Qdrant y búsquedas en la web, con medidas de seguridad y advertencias.
• Notas prácticas: Los tres niveles de Google Cloud RAG: Búsqueda vectorial, motor RAG y recuperación por agente — Guía paso a paso de las Notas prácticas: Los tres niveles de Google Cloud RAG: Búsqueda vectorial, motor RAG y recuperación por agente: contratos, verificaciones y espacios para código listo para usar.
• Notas prácticas: RAG está muerto. LLM Wiki — La idea de Andrej Karpathy — es lo que viene después — Guía paso a paso de las Notas prácticas: RAG está muerto. LLM Wiki — La idea de Andrej Karpathy — es lo que viene después: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan RAG.
• Rastreo de un agente Voice RAG con LiveKit, Qdrant y MLflow — Crea un asistente de hipotecas de voz a voz utilizando LiveKit, LlamaIndex y Qdrant, con trazas de OpenTelemetry en MLflow que muestran cada paso de recuperación y de procesamiento por modelo de lenguaje grande.
• RAG avanzado: HyDE, compresión, autocompletado de consultas y flujos de trabajo agentes — Cuatro técnicas avanzadas de recuperación de información para RAG en entornos de producción en Haystack: HyDE, compresión contextual, autocompletado de consultas y flujos de trabajo agentes, junto con indicaciones sobre cuándo utilizar cada una.
• Capa por capa: Diseño de un pipeline real de recuperación RAG para agentes de IA — Planifique un pipeline RAG con los contratos SourceDocument y DocumentChunk, fragmentación, embeddings y ChromaDB, todo ello respaldado por un RetrievalService que mantiene estable al agente.
• Diseño de un pipeline RAG para que los agentes de IA razonen, no solo realicen búsquedas — Exponga la confianza, la diversidad de fuentes y el grado de cobertura de su capa de recuperación para que el agente pueda detectar lagunas, volver a realizar búsquedas y explicar su razonamiento.
• Notas prácticas: Los agentes de IA ya no necesitan búsqueda vectorial: Adentro de Agentic — Guía paso a paso de las Notas prácticas: Los agentes de IA ya no necesitan búsqueda vectorial: Adentro de Agentic, la pila de búsqueda que reemplazará a RAG en 2026: contratos, verificaciones y código listo para usar.