RAG avanzado en producción: arquitectura, herramientas y ventajas e inconvenientes.

La generación reforzada por recuperación combina un paso de búsqueda con un modelo de lenguaje. Los documentos se ingieren e indexan con antelación; se obtienen las partes relevantes cuando llega una pregunta y el modelo escribe su respuesta a partir de ese material. Sin embargo, en entornos de producción, RAG rara vez consiste únicamente en una base de datos vectorial más un LLM. Los sistemas reales añaden análisis estructurado de documentos, particionamiento consciente de la estructura, recuperación densa y por palabras clave, reclasificación, construcción de contexto, evaluación y capacidades de observabilidad.

Lo que sigue se centra en herramientas ampliamente utilizadas en sistemas reales, omitiendo las técnicas experimentales menos comunes.

Un vistazo al proceso

Un pipeline avanzado y práctico comienza con la ingesta, el análisis y la limpieza de los datos, seguido de su división en fragmentos, la gestión de metadatos, la generación de embeddings e indexación. En el momento de la consulta se lleva a cabo la comprensión de la misma, la recuperación híbrida, la fusión y el reordenamiento de resultados, seguidos de la compresión del contexto, la generación de texto con citas, y finalmente la evaluación y la capacidad de observabilidad. La combinación exacta de herramientas depende de los tipos de documentos, la escala, los objetivos de latencia, las normas de privacidad, el presupuesto y los estándares de calidad.

Ingesta

Archivos locales. Python, con las librerías pathlib, PyPDF, python-docx, openpyxl y pandas, permite manejar de forma económica archivos PDF, de Word, hojas de cálculo, CSV y texto plano, y se integra fácilmente en tareas por lotes. La desventaja es que cada formato requiere su propio analizador; los PDF escaneados y complejos necesitan técnicas especializadas de extracción, mientras que las tareas a gran escala exigen paralelismo y procesamiento incremental.

Almacenamiento de objetos. Amazon S3, Google Cloud Storage y Azure Blob Storage ofrecen un alojamiento duradero y escalable para grandes colecciones, y se integran perfectamente con la ingesta asíncrona. Se pagan los costos de configuración en la nube, control de acceso, almacenamiento y transferencia, los cuales aumentan a medida que crece la escala.

Fuentes web y API. Herramientas como requests o httpx, BeautifulSoup, Playwright y Firecrawl mantienen actualizada una base de conocimientos al extraer sitios web, APIs y páginas dinámicas. Los sitios cambian su estructura, las páginas con mucho JavaScript requieren automatización del navegador, y el rastreo web genera límites de velocidad, páginas duplicadas y una calidad de contenido desigual.

Análisis y extracción

Unstructured acepta PDF, Word, HTML, PowerPoint, imágenes y más, y extrae elementos como títulos, párrafos y tablas, lo que lo convierte en una capa versátil para usos generales. Es más lento que la extracción de texto simple, y los documentos complejos pueden seguir necesitando un manejo personalizado.

PyMuPDF es rápido para extraer texto y metadatos de PDF basados en texto, y se integra fácilmente en códigos de Python. No es un sistema completo para comprender documentos, por lo que los archivos escaneados requieren OCR y los diseños o tablas complejas necesitan un trabajo adicional.

Apache Tika abarca una amplia gama de formatos y cuenta con herramientas avanzadas para extraer texto y metadatos de colecciones mixtas. Está menos optimizado para comprender diseños modernos, por lo que los layouts visuales complejos requieren herramientas adicionales.

OCR y extracción basada en visión

Tesseract es de código abierto, funciona localmente y rinde bien con texto impreso común. La escritura a mano y los diseños complejos reducen su precisión, y las escaneos de mala calidad requieren un preprocesamiento.

PaddleOCR ofrece una solución eficaz para la detección y reconocimiento de texto en muchos idiomas, adecuada para documentos escaneados y la extracción estructurada de información. Los documentos complicados pueden seguir necesitando un postprocesamiento del diseño, y su implementación puede requerir dependencias de modelos adicionales.

Modelos visión-lenguaje como los de clase GPT-4, Gemini y la familia Qwen-VL comprenden texto, imágenes, gráficos y el diseño de páginas, lo cual es útil cuando el OCR por sí solo pierde el contexto visual y permite el uso de técnicas multimodales RAG. Cuestan más que los OCR tradicionales, responden con mayor lentitud y generan resultados no deterministas que deben validarse.

Fragmentación

El chunking determina qué se convierte en una unidad recuperable. Un mal chunking separa la información relevante o combina material no relacionado.

• División recursiva de caracteres (RecursiveCharacterTextSplitter de LangChain) es una base fiable que intenta respetar los límites entre párrafos y oraciones y es fácil de ajustar. Funciona con la sintaxis y no con el significado, y un tamaño fijo no sirve para todos los documentos.
• División basada en tokens divide los fragmentos según los tokens del modelo, lo que ayuda con los límites de la ventana de contexto. Los bordes de los tokens no coinciden necesariamente con los límites semánticos.
• Chunking semántico busca cambios de tema mediante la similitud, por lo que las ideas coherentes permanecen juntas mejor que con tamaños fijos. Requiere más recursos de cómputo, necesita embeddings y depende de un umbral que hay que elegir.

Fragmentación padre-hijo recupera pequeños fragmentos hijos pero los expande a un fragmento padre más grande para proporcionar contexto, mejorando la precisión sin perder el entorno circundante. Las relaciones entre índices y metadatos se vuelven más complejas, y el contexto más amplio aumenta el costo de los tokens.

Fragmentación consciente de la estructura sigue encabezados, secciones, tablas y párrafos, lo cual resulta útil para documentos técnicos y empresariales. Depende de un análisis fiable y diferentes tipos de documentos requieren reglas distintas.

Metadatos

Los campos típicos incluyen el ID del documento, el nombre del archivo, el número de página, la sección, el autor, la marca de tiempo, el tipo de documento, el inquilino o usuario, los permisos de acceso, la URL de origen y la versión. Una buena metadata permite filtrar antes o durante la recuperación, respalda las citaciones y el control de acceso, y mejora la precisión. Por otro lado, una metadata deficiente disminuye directamente la calidad de la recuperación, y los esquemas resultan más difíciles de mantener en fuentes mixtas.

Embeddings

Los embeddings convierten el texto en vectores que capturan su significado.

• Los embeddings de OpenAI son gestionados, de alta calidad y fáciles de utilizar, con una excelente capacidad de recuperación para usos generales. Las desventajas son el costo de la API, la dependencia del proveedor y el hecho de que enviar datos puede no ser adecuado para entornos sensibles.

BGE es una sólida familia de algoritmos de recuperación de código abierto que se puede alojar uno mismo, con variantes para recuperación densa y reclasificación. El alojamiento propio requiere infraestructura, y la elección del modelo así como su dimensionalidad afectan el almacenamiento y la latencia.

E5 es una familia popular de código abierto con una sólida capacidad de recuperación general, además de variantes basadas en instrucciones o prefijos. Algunas variantes requieren un formato cuidadoso de consultas y documentos, y su ejecución por parte del usuario implica más trabajo operativo.

Cohere Embed es una API gestionada que ofrece una buena capacidad de recuperación multilingüe y empresarial, dependiendo de la versión del modelo, y es fácil de desplegar. Implica costos por uso de API y una dependencia externa.

Jina embeddings son modelos orientados a la recuperación, algunos de los cuales soportan contextos largos y múltiples idiomas. Las capacidades varían según la versión, y los modelos de código abierto necesitan infraestructura para ser alojados.

Bases de datos vectoriales

• pgvector agrega búsqueda vectorial a PostgreSQL, albergando datos relacionales, metadatos y vectores en un mismo lugar, lo cual es excelente si la aplicación ya utiliza Postgres. Las cargas de trabajo vectoriales muy grandes pueden requerir sistemas especializados, y el escalado se vuelve más complicado con volúmenes elevados.
• Pinecone es una base de datos vectorial gestionada que se escala sin necesidad de trabajar en la infraestructura y ofrece filtros adecuados para entornos de producción. Paga por el servicio, depende del proveedor y debe ceder algo de control.
• Qdrant está disponible como código abierto o en la nube, filtra bien los metadatos, soporta búsquedas densas e híbridas y es adecuado para sistemas RAG autohospedados. Autohospedarlo implica tareas operativas, y las configuraciones distribuidas requieren una planificación cuidadosa de la capacidad.

Weaviate ofrece una poderosa funcionalidad de recuperación de datos, búsqueda híbrida y filtrado de metadatos, tanto en la nube como en formato autohospedado. Cada característica adicional puede aumentar la complejidad del sistema, y las cargas de trabajo grandes requieren ajustes específicos.

Chroma es adecuado para desarrolladores y práctico para prototipos y aplicaciones pequeñas, gracias a su sencilla integración con Python. Por lo general, no es la primera opción para implementaciones empresariales a gran escala, donde el escalado y las operaciones son más importantes.

FAISS es una biblioteca muy popular para búsquedas rápidas de similitud y experimentos locales sin necesidad de una base de datos externa. Se trata de una biblioteca de búsqueda y no de una base de datos distribuida, por lo que la persistencia, el filtrado, el modelo multiusuario y la distribución requieren un trabajo de ingeniería adicional.

Recuperación de datos

Búsqueda vectorial densa combina una base de datos vectorial con un modelo de embedding para encontrar contenido semánticamente similar, gestionando mejor las paráfrasis que las palabras clave. Puede pasar por alto identificadores exactos, términos raros, códigos y números, y su calidad depende en gran medida del modelo de embedding y del proceso de fragmentación.

BM25 es un método léxico sólido, excelente para términos exactos, nombres, IDs y palabras clave técnicas, y es simple e interpretable. No comprende la similitud semántica, por lo que los sinónimos y las paráfrasis escapan a su detección.

Búsqueda híbrida suele combinar BM25 con la búsqueda densa, uniendo la precisión léxica con el alcance semántico para obtener resultados más fiables en tipos de consultas mixtos. Requiere la fusión de puntuaciones o rangos, así como más infraestructura y ajustes que un recuperador único.

Transformación de consultas

• Reescritura de consultas convierte entradas conversacionales o vagas en algo adecuado para la recuperación de información, lo que facilita las preguntas posteriores. Una mala reescritura puede descartar información clave y aumenta la latencia y el costo del LLM.
• Recuperación de múltiples consultas hace que el modelo escriba varias consultas alternativas y realice búsquedas para cada una, mejorando la capacidad de recuperación e incluyendo diferentes formulaciones. Esto implica más llamadas de recuperación, mayor latencia y costo, además de búsquedas irrelevantes en ocasiones.
• HyDE (Hypothetical Document Embeddings) genera una respuesta ficticia y la incrusta para su recuperación, lo cual puede ser útil en consultas difíciles o en casos donde el vocabulario de la pregunta difiere significativamente del de los documentos. Requiere una llamada adicional al LLM, y un documento hipotético deficiente puede distorsionar los resultados.

Fusión

Fusión de rangos recíprocos combina las clasificaciones de varios recuperadores. Es sencillo, robusto y funciona bien con métodos densos además de BM25; no necesita que las puntuaciones de diferentes sistemas sean comparables. Agrega una etapa de clasificación y aún así cuenta con parámetros que se pueden ajustar.

Fusión de puntuaciones ponderadas asigna diferentes grados de importancia a señales densas, dispersas u otras, lo cual es útil cuando los recuperadores tienen fortalezas distintas. Las escalas de puntuación deben normalizarse y las ponderaciones dependen de la carga de trabajo.

Reclasificación

La recuperación en la primera etapa debe priorizar el recuerdo. La reclasificación, a su vez, mejora la precisión en un conjunto más reducido de candidatos.

Rerankers de codificador cruzado como BGE Reranker, Cohere Rerank y Jina Reranker evalúan conjuntamente cada par consulta-documento, generalmente superando a la similitud de embeddings simples, y funcionan bien después de una recuperación híbrida. Son más costosos que la búsqueda vectorial, por lo que deben ejecutarse solo en una lista limitada de candidatos.

Reranking con LLM pide a un modelo que juzgue la relevancia y puede manejar criterios complicados, pero es lento, consume muchos tokens y es menos determinista que un reranker dedicado.

Maximum Marginal Relevance (MMR) equilibra la relevancia con la diversidad, eliminando duplicados cuando los resultados top-k son pasajes casi idénticos. Agrega un parámetro de diversidad, y demasiada diversidad puede descartar evidencias relevantes que casualmente se repiten.

Compresión de contexto

Compresión extractiva mantiene solo las oraciones o segmentos relevantes, lo que ahorra tokens y preserva la redacción original, pero puede eliminar el contexto necesario para comprender un pasaje. Compresión basada en LLM resume el material recuperado y puede reducir significativamente el contexto en documentos grandes, con un costo y latencia adicionales, además del riesgo de que la propia compresión pierda información o genere falsedades.

Generación

Las opciones más comunes en la producción son los modelos de OpenAI, Anthropic Claude, Google Gemini, Meta Llama y Qwen. Estos ofrecen un fuerte razonamiento, y las solicitudes pueden dirigirse según el costo, la latencia y la dificultad de la tarea. Los modelos API implican costos y dependencia del proveedor, los modelos abiertos requieren infraestructura, y los modelos más grandes aumentan la latencia y el costo de inferencia.

Frameworks

LangChain cuenta con un enorme ecosistema de cargadores, recuperadores, integraciones con almacenes vectoriales e interfaces de modelos, útiles para compilar pipelines rápidamente. Las abstracciones pueden volverse complicadas, y los sistemas en producción suelen funcionar mejor con un camino de solicitud claro y sencillo.

LlamaIndex se centra en la ingesta, indexación y recuperación, ofreciendo abstracciones útiles para sistemas RAG centrados en documentos. Añade complejidad al framework, y algunos sistemas avanzados acaban pasando a SDK de nivel más bajo.

LangGraph es adecuado para flujos de trabajo con estado, ramificados y basados en agentes, que incluyen recuperación iterativa y ejecución de herramientas. Requiere más recursos de los que necesita un pipeline simple y exige un manejo cuidadoso del estado y las fallas.

Patrones avanzados

• Corrective RAG evalúa el contexto recuperado y puede provocar nuevas búsquedas, detectando resultados débiles y permitiendo una búsqueda de respaldo, aunque a costa de mayor latencia y complejidad.
• Self-RAG permite que el modelo decida cuándo realizar búsquedas y juzgue qué resultados se obtienen. Se adapta para evitar búsquedas innecesarias, pero su lógica de control es más compleja y requiere una evaluación cuidadosa además del soporte del modelo.
• Agentic RAG cuenta con un agente que planifica las búsquedas, llama a herramientas, recupera información de forma iterativa y verifica los resultados, lo que le permite abordar preguntas complejas de múltiples pasos a partir de varias fuentes. Se espera mayor latencia y costo, más posibilidades de fallo y una depuración más difícil.

Graph RAG combina un grafo de conocimiento con la recuperación de información, lo que ayuda con las relaciones entre entidades y las preguntas de varios pasos que los vectores simples no pueden abordar. Construir el grafo es costoso, la extracción de entidades introduce errores y se requiere más infraestructura.

Multimodal RAG recupera e interpreta información a partir de texto, imágenes, tablas y gráficos, siendo adecuado para informes, escaneos y diagramas; implica una ingesta e indexación más intensiva y un costo mayor en los modelos de visión.

Datos estructurados

Text-to-SQL permite al modelo convertir preguntas en lenguaje natural en consultas para bases de datos estructuradas, lo cual es excelente para el análisis de datos recientes. El SQL generado puede ser incorrecto o inseguro, por lo que se necesita la recuperación de esquemas, validación y control de acceso.

Texto híbrido y SQL RAG utiliza la recuperación vectorial o por palabras clave para el conocimiento no estructurado y SQL para los datos estructurados, abarcando PDFs, documentos, CSVs y bases de datos en un mismo diseño. Requiere una gestión del paso entre modos diferentes y dificulta las pruebas así como la seguridad.

Evaluación

Un sistema en producción necesita evaluación tanto a nivel de recuperación como de generación.

Las métricas de recuperación (Recall@K, Precision@K, MRR, NDCG y tasa de aciertos) determinan si el sistema encontró las pruebas adecuadas. Las métricas de generación (fidelidad, relevancia de la respuesta, corrección de la respuesta, relevancia contextual, precisión contextual y recall contextual) evalúan si el modelo utilizó esas pruebas de manera adecuada.

Ragas está diseñado para la evaluación RAG, abarca ambos niveles y es útil para pruebas de regresión. Muchas de sus métricas se basan en evaluadores de LLM o embeddings, por lo que las puntuaciones no sustituyen completamente la revisión humana y los modelos evaluadores pueden presentar sesgos. La evaluación humana es la mejor opción para garantizar calidad en dominios específicos y detectar lo que las métricas automatizadas pasan por alto, pero es costosa, lenta y requiere pautas consistentes.

Observabilidad

LangSmith realiza el seguimiento de cadenas, llamadas de recuperación, prompts y resultados, y ayuda a depurar pipelines y comparar experimentos. Es una plataforma gestionada que tiene en cuenta aspectos relacionados con los costos y la privacidad. Langfuse ofrece funcionalidades de seguimiento, gestión de prompts y métricas, en formato de código abierto para autohospedaje o en la nube; sin embargo, el autohospedaje es responsabilidad del usuario y requiere instrumentación adicional. OpenTelemetry es el estándar abierto para seguimiento, métricas y registros, y permite integrar RAG en infraestructuras existentes, aunque implica más trabajo de ingeniería que una plataforma lista para usar.

Caché y rendimiento

Un caché semántico reutiliza respuestas para consultas similares, reduciendo las llamadas repetidas al LLM, la latencia y los costos. Pero las preguntas similares pueden requerir respuestas diferentes una vez que cambian los datos, y su invalidación es difícil. Un caché de embeddings evita volver a calcular los vectores para textos repetidos, lo cual es una ventaja sencilla que debe invalidarse cada vez que cambia el modelo de embeddings. La recuperación asíncrona y paralela ejecuta recuperadores independientes al mismo tiempo y acorta la latencia de punta a punta, aunque el manejo de errores se vuelve más complejo y los servidores deben soportar cargas concurrentes.

Seguridad

• Inyección de prompts. Los documentos recuperados pueden contener instrucciones destinadas a secuestrar el modelo.
• Recuperación con control de acceso. Los usuarios solo deben obtener los documentos para los cuales están autorizados a verlos.

Manejo de PII. Los datos personales deben ser localizados y enmascarados, o gestionados de otra manera, antes de llegar al índice.

Aislamiento de inquilinos. Con varios inquilinos, las consultas necesitan filtros de metadatos que tengan en cuenta al inquilino, y la propia base de datos requiere separación.

Envenenamiento de datos. Se pueden escribir documentos provenientes de fuentes no confiables con el fin de engañar intencionadamente.

Ninguna instrucción única resuelve los problemas de seguridad. Se necesitan controles en todas las etapas: ingestión, almacenamiento, recuperación, autorización, ejecución de herramientas y generación.

Despliegue

Los componentes típicos son FastAPI para la capa de API, Docker para el empaquetado, Kubernetes para la orquestación a gran escala, Redis para el caché, PostgreSQL para los metadatos relacionales, S3, GCS o Azure Blob para el almacenamiento de objetos, Prometheus para las métricas, Grafana para los paneles de control, OpenTelemetry para el rastreo y MLflow para el seguimiento de experimentos. El objetivo es un sistema RAG que sea reproducible, observable, escalable y mantenible, y no uno que solo parezca preciso en un cuaderno de notas.

Una pila práctica

Un diseño versátil y robusto puede mantenerse bastante simple. Los documentos pasan por Unstructured, PyMuPDF o PaddleOCR, luego por un procesamiento en bloques con consideración de la estructura o recursivo, seguido de embeddings provenientes de OpenAI, BGE, E5 o Cohere, y finalmente por pgvector, Qdrant o Pinecone. La recuperación de información se realiza mediante BM25 más búsqueda densa, combinada con RRF, reordenada por un cross-encoder, comprimida y entregada al LLM, junto con citas que sirven como referencia. Ragas y revisiones humanas evalúan la calidad, mientras que LangSmith, Langfuse u OpenTelemetry monitorean el tiempo de ejecución.

No todo sistema necesita todos los componentes. Una pequeña base de conocimientos interna puede funcionar con PostgreSQL, pgvector, embeddings y un LLM. Solo se deben añadir mecanismos de recuperación híbrida, reclasificación, bucles agentes, recuperación a partir de grafos y procesamiento multimodal después de que la evaluación demuestre que el diseño más simple es insuficiente.

Elegir la herramienta adecuada para el trabajo

• Texto PDF simple: PyMuPDF. Tipos de documentos mixtos: No estructurado. Escaneos: PaddleOCR. Páginas visualmente complejas: un modelo visión-lenguaje.
• División en fragmentos básica: un divisor recursivo. Límites semánticos: segmentación semántica. Contexto padre e hijo: recuperación padre-hijo.
• Embebidos gestionados: OpenAI o Cohere. Embebidos abiertos: BGE o E5.
• Ya disponible en PostgreSQL: pgvector. Almacén de vectores gestionado: Pinecone. Autohospedado: Qdrant. Prototipo: Chroma o FAISS.
• Búsqueda basada en significado: vectores densos. Palabras clave exactas: BM25. Cobertura fiable: híbrido. Fusión de rankings: RRF. Mayor precisión: un reordenador con codificador cruzado. Menos duplicados: MMR.
• Preguntas complejas de múltiples pasos: RAG agente. Relaciones entre entidades: Graph RAG. Tablas y bases de datos: texto a SQL.

Evaluación: Ragas. Rastreo: LangSmith o Langfuse. Telemetría estándar: OpenTelemetry. API a gran escala: FastAPI con Docker o Kubernetes.

Comience por lo pequeño

El mayor error arquitectónico es tratar al LLM como el sistema completo. La calidad proviene de la recuperación de información, el contexto, la generación, y posteriormente de la evaluación y la capacidad de observabilidad. Un modelo más grande no puede compensar de manera fiable la falta de evidencias.

Un ciclo de mejora útil consiste en establecer una línea base, evaluar, identificar la etapa problemática, cambiar un componente, volver a evaluar, desplegar y monitorear. Para la mayoría de los sistemas en producción, comience con un análisis sólido y un particionamiento consciente de la estructura, buenos embeddings, recuperación híbrida y un reordenador, y luego añada la generación basada en evidencias y la evaluación. Introduzca la recuperación por agentes, Graph RAG, pipelines multimodales, ciclos correctivos o ajuste fino solo cuando los requisitos medibles justifiquen su costo y complejidad.

Una buena ingeniería de RAG no se trata tanto de recopilar todas las tecnologías disponibles, sino más bien de elegir la arquitectura más sencilla que cumpla con los objetivos establecidos en cuanto a calidad, latencia, costo, seguridad y mantenibilidad.