Experiencia con RAG en producción tras procesar más de 5 millones de documentos

• Durante 8 meses trabajando en un proyecto de RAG (generación aumentada por recuperación), se distinguieron los métodos realmente efectivos de los que solo hicieron perder tiempo
• Al inicio se usaron Langchain y Llamaindex para completar rápidamente un prototipo, pero en el feedback de usuarios reales se encontraron límites de rendimiento
• Se identificó que los factores que más mejoraron el rendimiento de la búsqueda documental fueron la generación de consultas, el reranking, la estrategia de chunking, el uso de metadatos y el enrutamiento de consultas
• En la práctica se construyó un pipeline personalizado eligiendo de forma flexible base de datos vectorial, embeddings, reranking y LLM, entre otros componentes
• Toda la experiencia y el know-how se publicaron concentrados en el proyecto open source (agentset-ai/agentset)

---

Resumen de 8 meses construyendo RAG en producción

• Se comparte la experiencia de construir y operar sistemas RAG sobre datasets de gran escala, como un total de 9 millones de páginas (Usul AI) y 4 millones de páginas (una empresa anónima de IA legal)
• Al principio, siguiendo tutoriales de YouTube, se pasó de Langchain a Llamaindex y se completó un prototipo en pocos días, pero al desplegarlo apareció un problema de bajo rendimiento que solo los usuarios podían notar
• A lo largo de varios meses se fueron ajustando parcialmente los componentes del sistema hasta alcanzar el mejor rendimiento

Factores que realmente aportaron a la mejora del rendimiento (por ROI)

1. Generación de consultas (Query Generation)

   • Como la última consulta del usuario no puede contener todo el contexto, se usa un LLM para revisar la conversación y generar varias consultas semánticas y de palabras clave
   • Estas consultas se procesan en paralelo y luego se envían a un reranker para ampliar el alcance de la búsqueda y compensar sesgos de la búsqueda híbrida

2. Reranking

   • El impacto del reranking en el rendimiento, implementable con unas 5 líneas de código, es mucho mayor de lo que uno imaginaría
   • En entradas con muchos chunks (por ejemplo, 50), el proceso de reordenar y seleccionar solo algunos de los mejores (por ejemplo, 15) ofrece el mayor ROI
   • Solo con reranking se puede compensar en gran medida lo que le falta a un pipeline con diseño deficiente

3. Estrategia de chunking (Chunking Strategy)

   • Fue la parte que más tiempo consumió durante todo el desarrollo
   • Es necesario entender con precisión la estructura y los patrones de los datos, hacer chunking en unidades lógicas y revisar manualmente que no se corten palabras o frases a la mitad
   • Cada chunk debe conservar un significado independiente

4. Uso de metadatos en la entrada del LLM

   • En lugar de enviar al LLM solo el texto del chunk, agregar metadatos (title, author, etc.) mejora mucho el contexto y la calidad de las respuestas

5. Enrutamiento de consultas (Query Routing)

   • Para tipos de preguntas que RAG no puede responder (por ejemplo, resúmenes de artículos o solicitudes de información del autor), se introdujo un router liviano que deriva esas consultas hacia una ruta de procesamiento con API + LLM

Stack real (Our stack)

• Base de datos vectorial: Azure → Pinecone → Turbopuffer (económico y con soporte nativo para búsqueda por palabras clave)
• Extracción de documentos: enfoque personalizado
• Herramienta de chunking: principalmente Unstructured.io; para pipelines empresariales, una implementación personalizada (Chonkie también tiene buena reputación)
• Modelo de embeddings: uso de text-embedding-large-3 (no se probaron otros modelos)
• Reranker: None → Cohere 3.5 → Zerank (no es popular, pero en la práctica rinde muy bien)
• LLM: GPT 4.1 → GPT 5 → GPT 4.1 (principalmente usando créditos de Azure)

Open source y conclusión

• Todos los aprendizajes y la experiencia práctica se consolidaron en el proyecto open source agentset-ai/agentset
• Se publica bajo licencia MIT, por lo que puede usarse libremente y se pueden hacer consultas (se proporciona contacto)

[GN⁺]

Opiniones de Hacker News

• Se siente que la parte sobre la generación de consultas sintéticas es realmente importante; en la práctica, muchos usuarios escriben consultas de forma muy imprecisa, así que al principio el LLM generaba consultas sintéticas, pero como los resultados variaban mucho según la consulta generada cada vez, se hizo que en una sola llamada al LLM se produjeran tres versiones distintas de la consulta, luego se buscaran en paralelo y se combinara una lista sólida de resultados con reciprocal rank fusion; para la búsqueda se usa hybrid dense + sparse bm25; dense por sí solo es débil con la terminología especializada; al agregar además un reranker, la mayoría de los problemas relacionados con la búsqueda quedan resueltos
  • Resulta interesante usar un enfoque híbrido (bm25 + dense search) para compensar la debilidad de los modelos dense con los términos técnicos; modelos v3 como SPLADE, que equilibran bien la búsqueda semántica y léxica, también parecen rendir bien, pero siempre queda la duda de si podrían sustituirse por una solución más simple
  • Se enfatiza que este tipo de generación/optimización detallada de consultas es, al final, algo de lo que deberían ocuparse los proveedores de soluciones RAG como Amazon, Microsoft y OpenAI
  • Aunque es cierto que estos métodos son actualmente best practices, sigue quedando la sensación de que falta algo en las estrategias adicionales que podrían llevar el rendimiento un nivel más arriba, como el branching selectivo de modelos de embedding o distintas combinaciones de re-rankers
  • Como consejo final, se propone mostrarle al usuario, junto con los resultados, cómo interpretó el LLM la intención de búsqueda, para que el propio usuario pueda verificar si la comprensión del modelo fue correcta
• Hay confusión respecto a la opción self-hosted; al ver la documentación relacionada, se señala que se necesitan al menos 6 cuentas de servicios de terceros, y que eso se aleja demasiado de lo que debería significar un verdadero self-hosted
  • Se explica que el código en sí sí puede alojarse directamente por cuenta propia; se piensa que el término “self-hosted” no tiene un criterio oficial claramente definido; por ejemplo, aunque un servicio self-hosted tenga función de respaldo offsite, sigue siendo self-hosted y simplemente está bien diseñado
  • Este tipo de marketing de self-hosted puede parecer natural, pero dado que el modelo de negocio original de la empresa está en vender la versión alojada, no necesariamente tiene la obligación de ofrecer un producto self-hosted completamente independiente
  • Se comparte experiencia trabajando en entornos de red restringidos; como se ha trabajado durante los últimos 20 años en redes internas totalmente aisladas, se piensa que quizá se han dejado pasar muchas olas tecnológicas recientes; casi no se ve YouTube salvo para reparación de autos, y hay cierta reticencia hacia tendencias tecnológicas que requieren conexión constante en línea
  • En lo personal, se está usando la versión open source con mucha satisfacción; si no se quieren dependencias de hosting, la opinión práctica es que siempre se puede escribir todo directamente en Rust
• Se recomienda probar sí o sí rerankers basados en LLM grandes (como Qwen3-reranker), porque muestran el rendimiento que desde hace tiempo se quería ver en cross-encoders, aunque el costo computacional es considerable; además, la información de metadatos/tablas es información básica demasiado obvia para las personas, pero como no se repite en los chunks de texto, al inyectarla en la entrada del LLM este se ve mucho más “inteligente”; hay que tener cuidado con consultas complejas que RAG simple no maneja bien (por ejemplo, resumir los 20 documentos más recientes); por eso, se enfocó la UI en la búsqueda, reduciendo el chat UX, y haciendo que el usuario vea solo la misma información que realmente ve el modelo
  • Se coincide por completo con la opinión de que es muy difícil lograr que los usuarios entiendan correctamente cómo procesa el contexto un LLM; hay pocos casos públicos que se alejen del chat UX, y queda la duda de si las grandes empresas lo intentaron y abandonaron de verdad porque “no daba resultados”; en aplicaciones de consumo masivo, el costo de contexto/razonamiento es un costo principal que debe gestionarse, por lo que parece que las UI con contexto explícito quedaron relegadas; en cambio, en sistemas RAG internos de empresa, la carga de costos es menor y se percibe empíricamente que se pone mucho más foco en la calidad del resultado y el ahorro de tiempo de los empleados
  • Las optimizaciones técnicas también importan, pero se quiere saber más sobre casos reales de cuánto mejoró la eficiencia laboral de los clientes; de lo contrario, no sería más que otra moda tecnológica
• Se comparte una nota de resumen escrita hace año y medio sobre procesamiento RAG de millones de páginas (especialmente material técnico): https://jakobs.dev/learnings-ingesting-millions-pages-rag-azure/
  • También se construyó el año pasado un sistema RAG para búsqueda técnica, y al verlo ahora se siente que muchas partes siguen siendo casi idénticas
• Desde la perspectiva de quien quiere construir o adoptar un sistema RAG así, se pregunta si sería una arquitectura práctica subir documentos por API a carpetas de Google Workspace y luego buscarlos con Google AI search API, separándolos en carpetas distintas por usuario, o si algo similar podría implementarse también en Azure
• Se pregunta cómo gestionar el versionado de embeddings; cómo hacerlo cuando hay actualizaciones de datos, cuando se quiere exponer una versión específica o filtrar por fecha, y se está considerando incluso agregar la versión de contexto al inicio de cada chunk
  • Basta con guardar en el vector store el texto original junto con los metadatos, incluida la información de versión; por ejemplo, en turbopuffer el filtrado por atributos es cómodo, y se comparte la documentación
  • Se siente que esta pregunta en sí misma es bastante útil e importante
• Resulta extraño por qué la secuencia de uso de versiones de LLM fue GPT 4.1 → GPT 5 → de vuelta a GPT 4.1, y la falta de coincidencia con las versiones de otros componentes del stack (por ejemplo, text-embedding-large-3)
  • Respuesta del OP: se probó GPT-5 apenas salió, pero al darle mucho contexto (hasta 100 mil tokens) rindió peor que GPT-4.1, así que se volvió a 4.1; en concreto, a) seguía mal las instrucciones y no respetaba bien el system prompt, b) las respuestas se volvían demasiado verbosas y eso perjudicaba mucho la UX, c) el límite de ventana de contexto de 125 mil tokens hacía que entradas muy grandes terminaran en error; estos problemas se notaban especialmente en “RAG” cuando se pasaban muchos chunks, aunque en tareas más generales GPT-5 podría ser mejor
• Aunque no se sea defensor de AWS, se enfatiza que S3 Vectors es actualmente state-of-the-art en esta área; si además se conecta con Bedrock Knowledge Base, Discovery/Rebalance también se simplifica, así que sería la solución más simple del mercado; se cree que cuando salga oficialmente dejará atrás a la mayoría de sus competidores
  • En tono de broma, se corrige que la palabra correcta no es “schlep” sino “shill”
  • Surge la duda de por qué S3 Vectors sería SOTA (de vanguardia); al final, ¿no es solo un vector store?
• RAG basado en embeddings no llega a ser realmente el mejor método; para tareas únicas o demos funciona bien, pero en escenarios reales a menudo se topa con límites
  • También hay experiencia de que no necesariamente es así; el producto Query Assistant de Honeycomb, en el que se trabajó, también se basó en data query desde 2023, y precisamente por estar diseñado con un objetivo simple, se siente más bien como una dirección ideal para productos basados en LLM; conviene combinarlo con procesamiento no-LLM
  • rag sigue reinterpretándose de distintas maneras y tiene muchos usos; se integró como una herramienta dentro de agentic search, y al mismo tiempo se mezclan búsqueda en fuentes en tiempo real y el enfoque tradicional de chunks; con las ventanas de contexto grandes que vienen pronto, se prevé que también será posible meter documentos completos en una sola solicitud
  • Se pregunta qué alternativa se recomendaría exactamente, si se refiere al método de generación de consultas
  • También en el caso de ChatGPT, RAG es eficaz para obtener información reciente, y se enfatiza que esta utilidad práctica real es la razón por la que hoy todos los grandes proveedores lo ofrecen
  • Se pregunta con claridad cuál es el punto de comparación
• Se dijo que la estrategia de selección de chunks consume mucho tiempo y esfuerzo, y se quiere escuchar con más detalle qué estrategias concretas se usaron