Los equipos que llevan la Generación Aumentada por Recuperación (RAG) de una demostración a un servicio de producción se enfrentan a una serie de decisiones que distinguen a un asistente útil de uno ruidoso. Cinco elecciones de diseño —chunking, modelo de embedding, almacén de vectores, búsqueda híbrida y evaluación— controlan la precisión, la recuperación (recall) y la latencia que experimentan los usuarios reales.

Por qué el salto del prototipo a la producción es importante

La mayoría de los tutoriales logran poner en marcha un pipeline de RAG con unas pocas docenas de líneas de código, pero se quedan cortos en el rigor de ingeniería necesario para el tráfico en vivo.

1. Estrategia de chunking – la primera puerta de calidad

El tamaño del chunk es lo más importante. Los chunks grandes ahogan la señal con texto irrelevante; los chunks diminutos eliminan el contexto circundante que el modelo necesita para generar respuestas coherentes. La división de tamaño fijo ignora la estructura natural del material de origen.

Regla práctica

  • Dividir en límites lógicos: encabezados en documentos, saltos de párrafo en artículos, definiciones de funciones en código.
  • Mantener los chunks lo suficientemente pequeños para una recuperación precisa, pero conservar la sección "padre" más grande para el paso de generación del LLM. Este patrón de "padre-hijo" permite que el recuperador presente un fragmento preciso mientras el generador ve suficiente contexto para mantenerse fiel a los hechos.

2. Modelos de embedding – cómo se juzga la similitud

El modelo de embedding convierte el texto en vectores que el motor de búsqueda de similitud compara. Un modelo de propósito general sólido, como text-embedding-3-large de OpenAI, proporciona una base sólida para la mayoría de los dominios. Si el corpus pertenece a un campo altamente especializado —opiniones legales, registros médicos, especificaciones técnicas—, prueba un modelo específico del dominio, pero solo después de haber medido una mejora tangible en tus propios datos.

Cuándo cambiar

  • Cambia solo si observas una mejora medible en las puntuaciones de relevancia que importan para tu aplicación (por ejemplo, una mayor precisión del contexto).

3. Base de datos vectorial – escalando el almacenamiento

Elige un almacén de vectores que se adapte a tu infraestructura existente y al número esperado de vectores.

  • pgvector se ejecuta dentro de PostgreSQL y maneja cómodamente hasta aproximadamente un millón de vectores. Es ideal para equipos que ya operan una base de datos relacional y necesitan una solución de bajo mantenimiento.
  • Qdrant destaca en el rango de 1 M a 100 M, ofreciendo un mayor rendimiento (throughput) y una menor latencia para corpora más grandes.
  • Pinecone ofrece un servicio en la nube totalmente gestionado, eliminando la carga operativa de la autogestión (self-hosting).

4. Búsqueda híbrida y reranking – equilibrando el significado y la exactitud

La búsqueda vectorial pura destaca en la similitud semántica, pero puede omitir coincidencias exactas de palabras clave que los usuarios esperan. La búsqueda híbrida superpone un índice de palabras clave BM25 tradicional sobre el índice vectorial y luego fusiona ambas listas de resultados. El Reciprocal Rank Fusion (RRF) asigna a cada candidato una puntuación basada en su posición en ambas listas y las combina, potenciando los elementos que aparecen en posiciones altas en cualquiera de ellas.

El reranking añade un filtro de precisión final. Tras la recuperación híbrida, se pasan los N mejores candidatos (comúnmente 50) a un cross-encoder, un modelo que puntúa conjuntamente un par consulta-documento. Las puntuaciones del cross-encoder reemplazan los números de similitud originales, lo que permite elegir el chunk más relevante antes de pasarlo al LLM. Este paso adicional suele producir un salto notable en la calidad de la respuesta, especialmente en corpora largos o ruidosos.

5. Evaluación y abstención – midiendo lo que importa

No puedes mejorar un sistema que no mides. El framework RAGAS propone cuatro métricas que, en conjunto, capturan la salud de un pipeline de RAG:

  • Context Precision – proporción de chunks recuperados que realmente contienen la respuesta.
  • Context Recall – proporción de todos los chunks relevantes que fueron recuperados.
  • Faithfulness – grado en que la respuesta generada se mantiene dentro del contexto recuperado, evitando alucinaciones.
  • Answer Relevance – qué tan bien la respuesta final satisface la consulta original.

Realiza un seguimiento de estas métricas en un conjunto de pruebas continuo que refleje el tráfico de producción.

Una salvaguarda final que a menudo se pasa por alto es la abstención. En lugar de obligar al modelo a responder con baja confianza, establece un umbral en la puntuación de fidelidad o relevancia que active una respuesta de "No lo sé". Los usuarios prefieren una admisión clara de incertidumbre que una respuesta segura pero errónea, y este mecanismo de respaldo (fallback) reduce los costes de soporte posteriores.

Trata cada una de estas cinco áreas como un punto de decisión en lugar de una configuración de "ajustar y olvidar", y podrás llevar el RAG de una demostración llamativa a un servicio de producción fiable. La recompensa: un sistema que responde rápidamente, se mantiene en el tema y sabe cuándo guardar silencio.