RAG es más simple de lo que crees: 6 arquitecturas para no sobre-ingeniería
RAG Is Simpler Than You Think
La mayoría de los equipos sobre-ingenierizan sus sistemas RAG, saltando directamente a embeddings y bases vectoriales. Este artículo presenta 6 arquitecturas de recuperación, desde la búsqueda de texto completo con BM25 hasta el pre-embedding completo, y explica cuándo usar cada una según la frescura de los datos, las características del corpus, los patrones de consulta, la escala y las capacidades del equipo. Incluye un enfoque práctico: empezar simple, medir y solo añadir complejidad cuando los datos lo justifiquen. Destaca el reescritura de consultas con LLM como una alternativa económica y flexible a los embeddings, y el uso de niveles calientes/fríos para equilibrar latencia y frescura.
La mayoría de los problemas de 'búsqueda semántica' son en realidad problemas de formulación de consultas.
- usernametaken29
Trabajé en sistemas RAG a gran escala antes y puedo decir que la gente subestima enormemente la búsqueda de texto completo y sobreestima enormemente los embeddings. La búsqueda de texto completo es realmente fácil, portátil y escalable y te lleva muy lejos, se aplica la regla del 80/20. Los embeddings parecen agradables y mágicos, pero cuando realmente te metes en ellos te das cuenta: la similitud semántica no es tan buena como crees y ciertamente no hará felices a todos. Inevitablemente terminarás teniendo que re-embedding más o diferentes fragmentos de tu texto para acomodar una búsqueda de embeddings cada vez más precisa, momento en el que irás la última milla y harás reranking, etc., todo mientras tienes que soportar la carga operativa de la búsqueda vectorial.
Luego te das la vuelta y construyes una consulta de búsqueda con 500 palabras clave y seguro que es doloroso, pero simplemente funciona, se adapta a todos los casos de uso, escala y en general es menos molesto de mantener.
- alansaber
He construido sistemas usando todos estos enfoques (todos en tándem). En su mayor parte, el esfuerzo no vale la pena (en construir una estrategia de recuperación de información altamente optimizada para un corpus específico) excepto en unos pocos casos marginales. La cantidad de discusión técnica supera con creces el caso de uso de RAG.
- jillesvangurp
RAG es básicamente la buena y vieja recuperación de información con LLMs haciendo las consultas. Esto puede incluir búsqueda vectorial, pero también funciona sin ella. Tratar la búsqueda vectorial como polvo mágico de hadas que hace que la búsqueda sea genial sin esfuerzo no necesariamente va a funcionar tan bien. Además, puede añadir mucho costo y complejidad a la ecuación. Y si no se ajusta adecuadamente, no necesariamente obtienes buenos resultados.
Lo clave con RAG es obtener la información correcta en el contexto con el menor número de consultas posible. Eso requiere un buen recall (asegurando que si está ahí, se pueda encontrar con una consulta razonable) y precisión (asegurando que lo mejor esté arriba y minimizando falsos positivos).
Con la búsqueda, y por extensión con RAG, se aplica el principio de basura entra, basura sale. La mayor parte de lo que los equipos de búsqueda hicieron antes de la IA y RAG sigue siendo la mejor manera de optimizar la experiencia con RAG. Y si lo arruinas, la búsqueda no va a funcionar tan bien y ninguna cantidad de IA puede compensar eso, o solo a un gran costo en tokens y tiempo. Así que tener un pipeline ETL para preprocesar lo que indexas, probar y comparar la calidad de la búsqueda, etc., todo es útil.
La buena noticia es que no necesitas muchas habilidades con codificación agéntica para construir algo medio decente para esto. Este código casi se escribe solo. E incluso un poco de esfuerzo en extraer estructura antes de indexar puede marcar una gran diferencia.
- jrochkind1
Más texto generado por LLM sobre LLMs.
¿Alguien más encuentra realmente cada vez más difícil leer texto generado por LLM? Lo encuentro bastante agotador, mi cerebro simplemente no quiere terminarlo.
- Angostura
Tengo una antipatía particular por los artículos demasiado perezosos para deletrear los acrónimos en su primer uso.
Así que: https://en.wikipedia.org/wiki/Retrieval-augmented_generation
- yipinwong
Solo aquellos que dominan el oficio hacen que su trabajo parezca simple.
La IA que escribió esto podría ser el maestro, no el escritor, ya que esto parece escrito por IAs.
Usaré los agentes del autor, no leeré sus artículos ni lo contrataré para el trabajo.
- refactor_master
Aquí hay una versión aún más simple: simplemente incrusta todo la primera vez, luego rastrea lo que cambió. Usa un modelo barato para resumir y limpiar los documentos/chats con resumen y palabras clave. A menos que tengas bibliotecas enteras de libros para incrustar, serán unos cientos de dólares en llamadas API.
Luego, tíralo todo en BigQuery. Maneja todo lo vectorial de forma nativa.
Espolvorea una interfaz de agente bot por encima para que parezca omnisciente y mágico.
Supongo que otros proveedores además de Google tienen un enfoque similar con todo incluido que puedes simplemente conectar.
- klm127
RAG significa Retrieval Augmented Generation. El propósito es buscar en un corpus de texto por significado en lugar de coincidencia exacta.
Tuve que buscarlo.