RAG Es Más Sencillo de lo que Crees
La generación aumentada por recuperación (RAG) se presenta como menos novedosa de lo que sugiere su fama, y muchos sostienen que en esencia es recuperación de información tradicional más un LLM, y que los equipos a menudo la complican en exceso con bases de datos vectoriales y embeddings. Los comentaristas enfatizan repetidamente que la búsqueda de texto completo y BM25 siguen siendo potentes, más baratos y más fáciles de controlar para muchos casos reales, especialmente la búsqueda técnica y de código, y que los embeddings a menudo están sobrevalorados, son difíciles de ajustar y tienen un coste operativo elevado. También hay escepticismo sobre el contenido explicativo generado por IA en torno a RAG, junto con llamadas a patrones de diseño más claros, mejores evaluaciones y un enfoque de “empezar simple, añadir complejidad solo cuando sea necesario”.
Qué es realmente RAG
- Muchos comentarios dicen que RAG es esencialmente “recuperación de información clásica + LLMs”, no algo fundamentalmente nuevo.
- Varios señalan que “RAG ≠ búsqueda vectorial”: cualquier recuperación (grep, SQL, FTS, búsqueda web) cuyos resultados se alimentan al LLM es RAG.
- Otros en el hilo siguen tratando implícitamente RAG como “embeddings + base de datos vectorial”, lo que muestra que la confusión continúa.
Embeddings vs. búsqueda de texto completo / por palabras clave
- Tema recurrente: la búsqueda de texto completo (FTS/BM25/Lucene/Elasticsearch/Postgres FTS) está infravalorada y normalmente debería probarse primero.
- Argumentos a favor de FTS: más simple, determinista, herramientas maduras, más fácil de depurar, escala bien y a menudo funciona mejor para consultas técnicas o similares a código.
- Argumentos a favor de embeddings: buenos para consultas poco especificadas o descriptivas, sinónimos, búsqueda multilingüe y cuando los usuarios no conocen los términos exactos.
- Algunos reportan decepción en el mundo real con embeddings: similitud semántica más débil de lo esperado, alta carga operativa, canalizaciones de reranking complejas.
- Otros reportan buenos resultados con búsqueda semántica simple basada en embeddings o enfoques híbridos BM25+vector.
Fragmentación, escala y estructura de documentos
- El tamaño de los fragmentos se cita repetidamente como algo crítico; una mala fragmentación puede arruinar la recuperación sin importar el modelo.
- Los documentos largos (libros, informes, PDFs) plantean problemas: límites de tokens, referencias entre fragmentos (“it” refiriéndose a algo anterior) y explosión del tamaño del índice al incrustar muchos segmentos superpuestos.
- Hay debate sobre si fragmentos moderadamente grandes (512–1024 tokens) suelen ser suficientes para capturar el contexto temático; algunos creen que sí, otros dicen que la información relacional sigue perdiéndose.
Casos de uso: código, documentos empresariales, multilingüe
- Para código: varias herramientas y equipos informan que grep simple o FTS junto con agentes inteligentes a menudo superan a RAG; algunos incluso eliminaron la recuperación por completo sin que los usuarios lo notaran.
- Para bases de código enormes y búsquedas abstractas de “conceptos”, la recuperación aún puede ayudar.
- En documentos empresariales/financieros con mucha jerga y acrónimos, BM25 puede quedarse corto; los embeddings o configuraciones entre idiomas pueden funcionar mejor.
- Los embeddings se presentan como un “espacio común” agnóstico al idioma para la búsqueda cruzada entre lenguas, pero depurarlos es más difícil.
Diseño del sistema, agentes y orquestación
- Muchos ven que los verdaderos “dragones” no están en los embeddings sino en el diseño de la recuperación: frescura, control de acceso, versionado, documentos superpuestos, evaluaciones y ranking.
- La reescritura agentiva de consultas sobre búsqueda clásica es popular: dejar que el LLM construya e itere consultas, y usar debajo una infraestructura léxica/FTS estable.
- Algunos ven RAG como un problema de orquestación: mezclar módulos (búsqueda exacta, vectorial, SQL, etiquetado, reglas) según el caso de uso y los requisitos de calidad.
Costes, herramientas y consejos prácticos
- Un bando dice “incrusta todo una vez, sigue los cambios y guarda los vectores en algo como BigQuery”, asumiendo corpus de tamaño moderado.
- Otros advierten sobre el bloqueo con proveedores y sugieren elegir tecnología portable, Postgres/BM25/pgvector sencillos, o SQLite FTS5 con SQL generado por LLM.
- Hay frustración porque muchos tutoriales de RAG no vinculan los métodos con evaluaciones; la gente quiere benchmarks y guía sobre cuándo cada receta de recuperación mejora realmente los resultados.
Escepticismo, hype y estilo de escritura
- Algunos comentaristas argumentan que el artículo parece “AI slop” generado por LLM: encabezados exagerados, listas superficiales de “qué” con un “por qué” débil, y recetas híbridas que parecen ensambladas por máquina.
- Otros aun así encuentran el contenido útil en la práctica pese al estilo.
- Aparece un rechazo más amplio: fatiga con la prosa generada por IA, afirmaciones de que RAG se usa en exceso, “magic beans”, o “tan 2024”, y llamados a empezar con la búsqueda más simple que funcione y añadir complejidad solo cuando sea claramente necesario.