Key Takeaways
- RAG = subir documentos + recuperación + respuesta del LLM local. No requiere entrenamiento.
- Cinco pasos: (1) Cargar documentos, (2) dividir en fragmentos de 500-1000 tokens, (3) generar embeddings, (4) almacenar en base de datos vectorial, (5) recuperar al hacer consultas.
- Mejor modelo de embedding: nomic-embed-text (137M, funciona localmente, vectores de 768 dimensiones).
- Mejor base de datos vectorial: Chroma (simple, integrada) para <1M documentos; Qdrant (distribuida) para producción.
- A partir de abril de 2026, el RAG local es más rápido y económico que las APIs en la nube. La calidad depende de la precisión de recuperación y el prompt engineering.
¿Cómo funciona RAG paso a paso?
- 1Ingesta de documentos: Cargar PDFs, archivos de texto o páginas web.
- 2Chunking: Dividir los documentos en fragmentos de 500-1000 tokens (superposición del 20% para evitar cortes de contexto).
- 3Embedding: Convertir cada fragmento en un vector (768-1536 dimensiones) usando un modelo de embedding local.
- 4Almacenamiento: Guardar los vectores en una base de datos vectorial (Chroma, Qdrant, Milvus) con metadatos (nombre del documento, página, timestamp).
- 5Tiempo de consulta: Convertir la pregunta del usuario en un embedding y buscar en la base de datos vectorial los K fragmentos más similares (k=5-10).
- 6Ensamblaje de contexto: Combinar los fragmentos recuperados en un prompt con instrucciones para el LLM local.
- 7Generación: El LLM local genera la respuesta basándose en el contexto recuperado.
- 8Atribución: Devolver de qué documentos proviene la respuesta.
¿Cuál es la estrategia de chunking óptima?
La estrategia de chunking determina la calidad de recuperación. Un mal chunking = información relevante dividida entre fragmentos, la recuperación falla.
Chunking semántico (recomendado): Dividir por oraciones o párrafos, preservando el significado. Ejemplo: cada párrafo = 1 fragmento.
Chunking de tamaño fijo: 500 tokens por fragmento, 20% de superposición. Simple pero puede dividir oraciones.
Chunking recursivo: Primero por párrafos, luego por oraciones si son demasiado grandes. Preserva la jerarquía.
A partir de abril de 2026, el chunking semántico con fragmentos de 500-1000 tokens y 20% de superposición es óptimo para la mayoría de los casos de uso.
# Python: ejemplo de chunking semántico
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=1000,
chunk_overlap=200, # 20% de superposición
separators=["\n\n", "\n", ".", " "] # Dividir por párrafo, luego por oración
)
chunks = splitter.split_documents(documents)
print(f"Creados {len(chunks)} fragmentos")¿Qué base de datos vectorial deberías usar?
| Base de datos | Tipo | Capacidad | Esfuerzo de configuración | Ideal para |
|---|---|---|---|---|
| Chroma | Integrada | <1M docs | pip install | Prototipado, RAG pequeño |
| Qdrant | Distribuida | Ilimitada | Docker o cloud | Producción, escalable |
| Milvus | Distribuida | Ilimitada | Complejo | Empresa, gran escala |
| Weaviate | Grafo + Vector | Ilimitada | Docker | Consultas complejas, relaciones |
| Pinecone (cloud) | Gestionada | Ilimitada | Clave API | Sin servidor, sin mantenimiento |
¿Qué modelo de embedding deberías elegir?
| Modelo | Dimensiones del vector | Velocidad | Calidad | Recomendación |
|---|---|---|---|---|
| nomic-embed-text (local) | — | Rápida | Excelente | Mejor para RAG local |
| bge-m3 (local) | — | Rápida | Excelente | Soporte multilingüe |
| OpenAI text-embedding-3 (cloud) | — | Muy rápida | La mejor de su clase | Enfoque híbrido |
| Cohere (cloud) | — | Rápida | Excelente | RAG en cloud de producción |
¿Cómo optimizas la calidad de recuperación?
La calidad de recuperación determina el éxito del RAG. Buena recuperación = buenas respuestas. Mala recuperación = alucinaciones.
- Selección de Top K: Recuperar k=5-10 fragmentos. K más alto = más contexto (más lento), K más bajo = menos distracciones.
- Umbral de similitud: Filtrar resultados por puntuación mínima de similitud (p. ej., >0,75). Evita fragmentos poco relevantes.
- Reranking: Usar un reranker (cross-encoder) para reclasificar los fragmentos por relevancia. Pequeña mejora de precisión.
- Búsqueda híbrida: Combinar búsqueda semántica (embeddings) con búsqueda por palabras clave BM25. Captura documentos con palabras clave exactas.
- Expansión de consulta: Ampliar la consulta del usuario con sinónimos o términos relacionados. Mejora el recall.
¿Cómo evalúas la calidad del RAG?
La calidad del RAG tiene dos dimensiones: (1) calidad de recuperación (¿obtuvimos fragmentos relevantes?), y (2) calidad de generación (¿respondió bien el LLM?).
Evaluación de recuperación: Crear consultas de prueba con documentos correctos conocidos. Medir la precisión (¿cuántos recuperados son relevantes?) y el recall (¿obtuvimos todos los documentos relevantes?).
Evaluación de generación: Ejecutar el LLM sobre los fragmentos recuperados y puntuar manualmente las respuestas (escala 0-5) por exactitud y completitud.
A partir de abril de 2026, las herramientas de evaluación automatizada (como Ragas) pueden medir métricas de recuperación y generación de forma automática.
Patrones RAG en producción
Para servicios en producción, utiliza estos patrones:
- Caché: Almacenar en caché los embeddings de documentos consultados frecuentemente para evitar recalcularlos.
- Indexación incremental: Añadir nuevos documentos sin reindexar todo. Qdrant y Milvus lo soportan.
- Monitoreo: Rastrear la latencia de recuperación, la tasa de aciertos en caché y los comentarios de los usuarios sobre la calidad de las respuestas.
- Fallback: Si la recuperación falla (sin fragmentos relevantes), responder con "No tengo información sobre eso" en lugar de alucinar.
- Versionado: Mantener versiones de los documentos para registros de auditoría. Almacenar qué versión se usó para cada respuesta.
Errores comunes en la implementación de RAG local
- Chunking incorrecto de documentos. Demasiados fragmentos pequeños = ruido en la recuperación. Pocos fragmentos grandes = información dividida. Probar tamaños de fragmento de forma empírica.
- No evaluar la recuperación. Construir RAG sin probar si la recuperación funciona es como construir un coche sin probar el motor. Medir siempre precisión/recall.
- Usar embeddings genéricos para documentos de dominio específico. Los documentos legales, médicos o técnicos pueden necesitar embeddings ajustados. Considerar modelos de dominio específico.
- Olvidar la frecuencia de actualización. Si los documentos cambian semanalmente, la base de datos vectorial queda desactualizada. Construir un pipeline para re-embeddings y actualizaciones.
- Esperar que RAG reemplace el fine-tuning. RAG es inyección de contexto. Fine-tuning es adaptación del modelo. Para mejores resultados, combinar ambos.
Preguntas frecuentes sobre RAG local
¿Cuántos documentos puede manejar el RAG local?
Chroma maneja entre 100K y 1M documentos en hardware de consumo. Qdrant escala a miles de millones con configuración distribuida. Por encima de 1M, usa Qdrant o Milvus.
¿Qué latencia debo esperar?
Consulta de embedding (nomic-embed-text en CPU): 50-200ms. Recuperación (Chroma en disco): 10-50ms. Generación del LLM: 2-10 segundos (depende del tamaño del modelo). Total: 2-10 segundos por consulta.
¿Puede RAG manejar actualizaciones de documentos en tiempo real?
Sí. Añade nuevos documentos a la base de datos vectorial de forma dinámica. La latencia de indexación es de 100-500ms por documento, por lo que las actualizaciones en tiempo real son viables.
¿Es el RAG local más económico que las APIs en la nube?
Sí. Sin costo por token, sin llamadas API a servicios externos. Configuración única de embeddings y luego consultas gratuitas.
¿Puedo usar embeddings en la nube con LLMs locales?
Sí. Usa embeddings de OpenAI, Cohere u otros servicios en la nube para la indexación y luego LLMs locales para la generación. Enfoque híbrido.
Fuentes
- Documentación de LlamaIndex -- docs.llamaindex.ai
- Guía RAG de LangChain -- python.langchain.com/docs/use_cases/question_answering
- Documentación de Chroma -- docs.trychroma.com
- Motor de búsqueda vectorial Qdrant -- qdrant.tech
- Artículo RAG (Lewis et al.) -- arxiv.org/abs/2005.11401