Desmontando RAG, del protocolo rígido a la abstracción flexible

Source: Dev.to

Nota del autor

Este artículo lo escribí originalmente en septiembre de 2025, poco antes de la consolidación de arquitecturas como GraphRAG. Quedó guardado en un “cajón digital”, pero al revisarlo hoy me sorprendió ver cuánto de su diagnóstico arquitectónico sigue vigente. Decidí publicarlo manteniendo intacto el texto original para preservar el contexto del análisis, añadiendo solo una breve nota al final sobre cómo ha evolucionado el ecosistema RAG en los últimos meses.

---

Esta definición es amplia y potente. No prescribe cómo debe ser esa recuperación. Sin embargo, en la práctica, el ecosistema ha convergido masivamente en una implementación muy específica: la búsqueda de similitud vectorial sobre bases de datos de texto no estructurado. Esta técnica es tan dominante que ha empezado a moldear no solo nuestra percepción de lo que es RAG, sino también las herramientas y protocolos que construimos a su alrededor. Y es aquí donde, como arquitectos, debemos pararnos a analizar las consecuencias.

Cuando la API refleja el mecanismo y no la intención

Cuando una aplicación cliente necesita interactuar con un retriever como servicio externo, lo hace a través de una API. Aunque no existe un estándar formal, el patrón de facto es claro, en gran parte popularizado por el auge de las bases de datos vectoriales como Pinecone, Weaviate o Chroma:

• APIs RESTful sobre HTTP/S (con JSON)
• gRPC para mayor rendimiento

El diablo, como siempre, está en los detalles de estas APIs. Una llamada típica a un servicio de retriever vectorial se parece a esto:

{
  "vector": [0.12, 0.54, ..., -0.08],
  "topK": 5,
  "metric_type": "cosine"
}

Observemos el lenguaje de esta API. Sus “verbos” y “sustantivos” son vector, topK (los K vecinos más cercanos) y metric_type. Es un lenguaje intrínsecamente geométrico y estadístico. Esta API no está diseñada para “recuperar información”; está diseñada para “encontrar los vecinos más cercanos a un punto en un espacio de N dimensiones”.

Implicación profunda: cualquier cliente que se programe contra esta API queda fuertemente acoplado, no al concepto abstracto de RAG, sino a una de sus posibles implementaciones. La capa de transporte nos ha encerrado en un único paradigma.
¿Qué pasaría si nuestro “retriever” no trabajara con vectores?
¿Y si fuera una base de datos SQL?
¿O una API meteorológica?
¿O un grafo de conocimiento lógico?

La API actual no tiene el vocabulario para expresar esas preguntas.

Subiendo a la capa de aplicación

Este problema de acoplamiento entre la aplicación y el “motor” subyacente no es nuevo en nuestra industria. Lo vivimos hace décadas con las bases de datos, donde cada fabricante tenía su propio protocolo. La solución fue la creación de una capa de abstracción a nivel de aplicación: ODBC y JDBC.

Hoy estamos viendo exactamente la misma solución en el ecosistema RAG, liderada por librerías como LangChain. En lugar de forzar a los desarrolladores a codificar contra una API de transporte rígida, proponen un contrato a un nivel superior.

La interfaz BaseRetriever de LangChain

En LangChain, esta es la interfaz BaseRetriever. Su método principal es de una simplicidad que desarma:

get_relevant_documents(query: str) -> List[Document]

Análisis de este contrato

Un cliente que programa contra esta interfaz ya no sabe, ni le importa, qué hay debajo. El BaseRetriever puede ser:

• PineconeRetriever – convierte internamente el query en un vector y hace la llamada HTTP que vimos antes.
• SQLRetriever – traduce la pregunta en lenguaje natural a una consulta SQL estructurada, ya sea mediante un modelo de lenguaje o un conjunto de reglas.
• Cualquier otro tipo de retriever que se nos ocurra.

Esta flexibilidad no es solo un ejercicio teórico; es la llave que abre la puerta a problemas que la búsqueda por similitud vectorial simplemente no puede resolver.

Caso de uso: un dominio que necesita lógica espacial

Pensemos por un momento en un dominio donde la “verdad” no es un texto similar, sino una estructura lógica y espacial: un Sistema de Información Geográfica (SIG).

Ejemplo de consulta:
“¿Qué parcelas de cultivo se encuentran a menos de 500 metros de un cauce de agua que haya sufrido una sequía en los últimos dos años?”

¿Qué ocurre con un retriever vectorial tradicional?

Buscaría documentos que contengan las palabras parcela, cauce, sequía y 500 metros. El resultado sería una lista de textos (informes técnicos, noticias, etc.), pero nunca una respuesta directa y precisa a la pregunta.

¿Cómo actúa un hipotético GeoRetriever?

1. Interpretar la pregunta

   • El LLM, en colaboración con el retriever, descompone la consulta en sus componentes espaciales y temporales:
     • tipo: parcela
     • relación: distancia < 500 m
     • condición: sequía en los últimos 2 años

2. Ejecutar la lógica espacial

   • Se consulta una base de datos geoespacial (por ejemplo, PostGIS) para obtener las parcelas que cumplen la condición de distancia y la restricción temporal.

3. Construir la respuesta

   • Los resultados se formatean y se devuelven al usuario como una lista estructurada o un mapa interactivo.

Nota: Construir un GeoRetriever así es un desafío de ingeniería mayúsculo que involucra múltiples disciplinas. No lo presento como una solución trivial, sino como un ejemplo del potencial que estamos dejando sobre la mesa.

Por qué necesitamos una arquitectura flexible

Una arquitectura flexible nos permite:

• Imaginar y, eventualmente, construir soluciones a problemas que hoy parecen intratables.
• Avanzar gradualmente sin tener que demoler y reconstruir la aplicación cada vez que surge un motor de conocimiento más potente que una simple búsqueda vectorial.

Esta tensión entre una solución dominante pero limitante y la necesidad de mayor flexibilidad no es un fenómeno nuevo en nuestro campo; es un patrón recurrente en la evolución de los ecosistemas tecnológicos.

Analogía histórica: bases de datos

Durante años, cada fabricante impuso su propio protocolo de comunicación, encerrando a los desarrolladores en ecosistemas propietarios. La innovación se veía lastrada hasta que surgieron capas de abstracción como ODBC y JDBC, que liberaron a las aplicaciones de los detalles de implementación y permitieron que el ecosistema floreciera.

Lo que estamos presenciando con RAG es una repetición de ese ciclo:

• El ecosistema ha convergido rápidamente en una implementación eficiente (la búsqueda vectorial) pero acoplante.
• La respuesta no es desechar esa implementación, sino construir sobre ella una capa de abstracción que nos devuelva la libertad de innovar.

Estas capas no son solo una conveniencia técnica; son un mecanismo fundamental para la salud a largo plazo de cualquier tecnología.

Frustración del desarrollador

“La API actual es eficiente, pero es una puerta estrecha que solo deja pasar un tipo de pregunta.”

Como desarrollador, me resulta profundamente frustrante sentirme limitado no por la tecnología en sí, sino por la “puerta de entrada” que nos han dado para usarla.

Hacia APIs más flexibles

Nuestro objetivo debe ser diseñar APIs que expresen la intención del usuario, no el mecanismo interno. En lugar de una API que pregunta:

“¿Cuáles son los K vecinos más cercanos a este vector?”

Deberíamos aspirar a APIs que pregunten:

“Recupera información relevante para esta consulta, usando esta estrategia.”

Estrategias posibles

La decisión del mecanismo debería quedar, en la medida de lo posible, del lado del servidor, permitiendo que la capa de aplicación se mantenga estable mientras la infraestructura evoluciona.

Por qué importa

• Las APIs demasiado específicas sobre el “cómo” se vuelven obsoletas tan pronto como aparece un “cómo” mejor.
• Las APIs que se centran en el “qué” perduran, porque permiten que la innovación prospere bajo la superficie sin que el mundo de arriba tenga que cambiar.

Construir puertas, no solo pasillos

El paradigma RAG es mucho más que la búsqueda por similitud. Es la promesa de una IA que consulta dinámicamente cualquier fuente de conocimiento para fundamentar sus respuestas.

Las APIs que dominan hoy son un pasillo estrecho que solo lleva a un destino: la búsqueda vectorial.

La solución no es abandonar ese pasillo, sino construir un vestíbulo con muchas puertas. Abstracciones como las de LangChain son el primer paso: desacoplan la aplicación del mecanismo de recuperación y nos dan un “enchufe” estándar para conectar futuros motores de conocimiento.

El próximo gran avance

El próximo gran avance en RAG no será un algoritmo vectorial un 1 % más rápido. Será una clase de Retriever completamente nueva que nadie había pensado en conectar hasta ahora. Solo podremos usarla si hemos construido una arquitectura que nos lo permita.

Reflexión: Las herramientas que construimos terminan definiendo los problemas que podemos resolver. Si solo tenemos APIs para búsqueda vectorial, solo podremos resolver problemas de similitud estadística, no problemas que requieran razonamiento estructural.

Conclusión

Como arquitectos, nuestro trabajo no es solo optimizar el camino conocido, sino asegurarnos de que tenemos la libertad para explorar los caminos que aún no existen.

---

Nota

Cuando comencé a escribir este artículo hace unos meses, la búsqueda vectorial seguía siendo el paradigma dominante en RAG. Desde entonces, el ecosistema ha evolucionado rápidamente:

• GraphRAG de Microsoft (y su variante más eficiente LazyGraphRAG)
• LinearRAG
• LightRAG

Estos proyectos ilustran la tendencia que defendía aquí: estamos pasando de un RAG rígidamente vectorial a enfoques que incorporan grafos de conocimiento, razonamiento estructurado y mecanismos de recuperación híbrida.

Estos avances no invalidan la crítica a las APIs geométricas de las bases vectoriales; al contrario, la refuerzan. Solo gracias a capas de abstracción como las que proponen LangChain o similares podremos aprovechar plenamente estas nuevas posibilidades.

LlamaIndex: Integrando nuevos retrievers sin reescribir la aplicación

El futuro que imaginábamos ya está llegando.

Para quienes quieran profundizar en los fundamentos técnicos y arquitectónicos de los sistemas RAG, y explorar más allá de la implementación dominante, aquí hay una selección de recursos clave.

📚 El Fundamento Original

• “Retrieval‑Augmented Generation for Knowledge‑Intensive NLP Tasks”
  Patrick Lewis, et al. (2020)

  Este es el paper que dio origen al acrónimo RAG. Su lectura es esencial para comprender la visión original del marco, que es deliberadamente más amplia y agnóstica al mecanismo de recuperación que muchas de las implementaciones actuales.

🔧 El Ecosistema Dominante (Búsqueda Vectorial)

• Documentación de bases de datos vectoriales

  • Pinecone
  • Weaviate
  • Chroma

  Más allá de los tutoriales, sus secciones de conceptos y arquitectura explican en detalle el “porqué” detrás de las APIs que analizamos en el artículo. Son la mejor fuente para entender el protocolo de facto que ha moldeado el ecosistema.

• “Vector Search for Practical Machine Learning”
  A. Aji, et al.

  Artículo de revisión que ofrece una visión técnica sólida de los algoritmos y estructuras de datos (como HNSW) que hacen posible la búsqueda de similitud a gran escala.

🧩 La Abstracción y el Futuro

• Documentación de LangChain y LlamaIndex sobre “Retrievers”

  • Analiza la interfaz BaseRetriever en LangChain.
  • Explora los conceptos de QueryEngine y Retriever en LlamaIndex.

  La forma más directa de ver en práctica la capa de abstracción que proponemos. Fundamental para cualquier desarrollador que quiera construir sistemas RAG flexibles y desacoplados.

• “Seven Failure Points When Engineering a Retrieval Augmented Generation System”
  Scott Barnett, et al. (2024)

  Artículo práctico que describe los riesgos comunes y cómo mitigarlos al diseñar pipelines RAG robustos.