🏗️ RAG en Producción: Lo que Nadie Te Cuenta
En mis 30 años construyendo sistemas, he aprendido que el infierno está en los detalles que los tutoriales nunca muestran. Con RAG (Retrieval-Augmented Generation) pasa exactamente eso.
Todos los artículos te enseñan a montar un RAG en 10 minutos con LangChain y ChromaDB. Nadie te cuenta lo que pasa cuando tienes 10 millones de documentos, usuarios en 3 husos horarios y un SLA de 200ms.
Vamos al barro.
📦 1. El Problema del Chunking No es Técnico, es Semántico
El 90% de los tutoriales te dicen: "chunks de 512 tokens con overlap de 50". Y funciona... en el tutorial.
En producción real, el chunking óptimo depende de la estructura de tu documento:
- Documentos técnicos: Los párrafos son unidades semánticas. Chunkear por párrafo (no por tokens) preserva el contexto.
- Código: Chunkear por función/clase. Ignorar esto es mezclar lógica no relacionada.
- Conversaciones/Chunks: Chunk por turno de diálogo. El contexto conversacional se pierde con splits arbitrarios.
- PDFs con tablas: El infierno. Necesitas extracción semántica pre-chunking.
Mi enfoque: Uso chunking jerárquico. Primero divido por estructura del documento (secciones, párrafos), luego ajusto por tokens si es necesario. El overlap no es fijo; depende de la densidad semántica de cada sección.
🧠 2. Embeddings: La Religión del Modelo Correcto
No todos los embeddings son iguales. Y no, text-embedding-ada-002 no es siempre la respuesta.
| Escenario | Embedding Recomendado | Por qué |
|---|---|---|
| Documentos técnicos/legales | voyage-2 o e5-mistral-7b | Mejor con vocabulario especializado |
| Código | code-search-* o stella-code | Entiende sintaxis y semántica de programación |
| Multilingüe | multilingual-e5-large | Cruza idiomas sin perder precisión |
| Latencia < 100ms | gte-small local con ONNX | Pierdes un 5% de precisión pero ganas 10x en velocidad |
La trampa de los vectores: El embedding no es el bottleneck. El recálculo de vectores cuando actualizas documentos sí lo es. Diseña tu pipeline pensando en actualizaciones incrementales desde el día 1.
⚡ 3. Latencia: Donde los Proyectos Mueren
El RAG añade 3 saltos de latencia que los prototipos no te muestran:
- Embedding de la query: 50-200ms (depende del modelo y si está cacheado)
- Búsqueda vectorial: 10-100ms (depende del índice y el tamaño)
- Generación con contexto: 500-3000ms (depende del LLM)
Total: 560ms a 3.3s. Para un chatbot interno puede valer. Para una API pública, es letal.
Mis trucos en producción:
- Caching semántico: Antes de embedder, hash semántico de la query. Si es similar a una ya respondida, sirve respuesta cacheada.
- Búsqueda híbrida: BM25 + vectorial. Para queries factoides, BM25 es más rápido y igual de preciso.
- Modelos locales para ranking: Un re-ranker pequeño (5-10ms) que filtra los top-20 resultados antes de mandarlos al LLM grande.
- Streaming progresivo: Muestra resultados parciales mientras el LLM completa la generación.
💰 4. El Coste Oculto de los Pipelines RAG
Los tutoriales hablan de precisión. Nadie habla de coste.
Coste mensual RAG = Coste(embeddings) + Coste(vector DB) + Coste(LLM generación) + Coste(mantención pipeline)
En una implementación con 100k consultas/día y contexto de 4k tokens por consulta:
- API embedding: ~$300/mes
- Vector DB (Pinecone/Pgvector): ~$500/mes
- LLM (GPT-4o): ~$3000/mes
- Pipeline y monitorización: ~$500/mes
Total: ~$4,300/mes. Para muchas startups, esto es más que el salario de un dev. Y lo peor: el coste escala linealmente con el uso, no se amortiza.
Mi estrategia: Modelos locales para el 80% de las consultas (Mistral 7B cuantizado con vLLM) y GPT-4o solo para casos complejos. Reduces el coste LLM un 70-80%.
🔧 5. Evaluación: El Talón de Aquiles
No puedes mejorar lo que no mides. En RAG hay 3 métricas que monitorizo en producción:
- Precision@K: ¿Están los documentos relevantes en el top-K recuperado?
- Answer Relevancy: ¿La respuesta generada responde realmente a la query?
- Faithfulness: ¿La respuesta alucina o se ciñe a los documentos recuperados?
Herramienta: Uso RAGAS o LangSmith para evaluaciones periódicas y Arize para monitorización continua.
Conclusión
RAG no es un plug-and-play. Es un sistema distribuido con sus propias complejidades de latencia, coste y calidad. La diferencia entre un prototipo y un sistema en producción son meses de ajuste en chunking, selección de modelos y optimización de pipeline.
Pero cuando funciona bien —cuando un usuario obtiene una respuesta precisa con contexto relevante en <1s— la magia es real.
¿Estás construyendo un sistema RAG? Comparte tus problemas de latencia conmigo.