Ofrezca a su LLM acceso a sus datos sin ajuste fino. RAG cierra la brecha entre los modelos de lenguaje de propósito general y el conocimiento específico del dominio.

Desea construir un asistente de IA que responda preguntas sobre los documentos de su organización: contratos, políticas, bases de conocimiento, documentación de productos, registros médicos. Ajustar un LLM en sus datos es costoso, lento y crea un modelo que está 'congelado' en el momento del entrenamiento. Necesita una arquitectura donde el LLM pueda acceder a información actualizada y específica del dominio en el momento de la consulta, citar sus fuentes y evitar 'alucinaciones' de hechos que no estén en sus documentos. RAG (Generación Aumentada por Recuperación) es como se llega allí.
Explore more design patterns and system architectures
Nuestros arquitectos pueden ayudarle a diseñar y construir sistemas utilizando este patrón para sus requisitos específicos.
Ponte en ContactoRAG aumenta la generación de LLM con contexto recuperado de una base de conocimiento. En el momento de la consulta, el sistema convierte la pregunta del usuario en un embedding, busca en una base de datos vectorial fragmentos de documentos semánticamente similares e incluye los fragmentos más relevantes como contexto en el prompt del LLM. Esto basa la respuesta del modelo en documentos reales, permite la citación de fuentes y mantiene la base de conocimiento actualizable sin reentrenamiento. Un pipeline RAG de producción maneja la ingesta (parsing, chunking, embedding), la recuperación (búsqueda vectorial, reranking, búsqueda híbrida) y la generación (construcción de prompt, streaming, guardrails).
La arquitectura tiene dos pipelines. El pipeline de ingesta procesa documentos mediante parsing (extracción de PDF, DOCX, HTML), chunking (semántico o de tamaño fijo con solapamiento), embedding (a través de un modelo de embedding) y almacenamiento (base de datos vectorial + almacén de documentos). El pipeline de consulta toma una pregunta del usuario, genera un query embedding, recupera fragmentos candidatos de la base de datos vectorial, los rerankea por relevancia, construye un prompt con los fragmentos principales como contexto y transmite la respuesta del LLM con citaciones de fuentes.
text-embedding-3-large, Cohere embed-v4, o alternativas de código abierto (BGE, E5). Procesamiento por lotes para ingesta, procesamiento de consulta única para búsqueda| Layer | Technologies |
|---|---|
| Análisis de Documentos | Unstructured, Apache Tika, LlamaParse, Docling, custom OCR (Tesseract, AWS Textract) |
| Embedding | OpenAI text-embedding-3-large, Cohere embed-v4, BGE-M3, E5-large-v2 |
| Base de Datos Vectorial | Milvus, Pinecone, Qdrant, Weaviate, pgvector (for small-scale) |
| Búsqueda por Palabras Clave | Elasticsearch, OpenSearch, PostgreSQL full-text search |
| Reranking | Cohere Rerank, BGE Reranker, ColBERT v2, FlashRank |
| LLM | Claude (via AI Gateway), GPT-4, Gemini — agnóstico del proveedor a través de AI SDK |
| Orquestación | LangChain, LlamaIndex, o pipeline personalizado (preferencia de MW para producción) |
| Use When | Avoid When |
|---|---|
| Los usuarios necesitan respuestas basadas en los documentos específicos de su organización | La base de conocimiento tiene < 50 páginas — simplemente inclúyalo en el prompt del sistema |
| Los documentos se actualizan con frecuencia y la IA necesita información actual | Necesita que el modelo aprenda una nueva habilidad/comportamiento, no que acceda a nuevos hechos (ajuste fino en su lugar) |
| La citación de fuentes y la auditabilidad son requisitos (legal, cumplimiento, atención médica) | Las preguntas son puramente conversacionales y no requieren una base fáctica |
| Múltiples grupos de usuarios necesitan acceso a diferentes subconjuntos de documentos (RAG con filtrado por permisos) | Está construyendo una herramienta de escritura creativa donde la precisión fáctica no es el objetivo |
MW construye pipelines RAG desde la calidad de la recuperación hacia afuera — evaluamos la precisión de la recuperación antes de tocar el prompt del LLM. Un sistema RAG con una recuperación mediocre y un gran LLM produce respuestas erróneas que suenan convincentes. Nuestro pipeline estándar incluye un arnés de evaluación de recuperación: un conjunto de consultas de prueba con documentos conocidos y relevantes, medidos por MRR@5 y NDCG@10. Iteramos en chunking, modelo de embedding y reranking hasta que las métricas de recuperación alcanzan los umbrales objetivo antes de optimizar la generación. Hemos construido sistemas RAG para revisión de documentos legales, bases de conocimiento de atención médica y soporte al cliente multilingüe — y la lección común es que la calidad de la recuperación representa el 80% de la calidad de la respuesta.
La búsqueda de incrustaciones es fácil con 10K vectores. Con 100M vectores y P99 por debajo de 100ms, es un problema de infraestructura, y eso es lo que resuelve este patrón.
MicrocosmWorks implementa la resolución de conflictos en los pipelines RAG a través de la clasificación de autoridad de la fuente, la ponderación de la recencia basada en timestamp, y la puntuación de confianza que evalúa qué tan sólidamente cada pasaje recuperado respalda su afirmación. Cuando se recuperan pasajes contradictorios, nuestro pipeline presenta la respuesta de mayor autoridad mientras muestra de forma transparente el desacuerdo y las citas de las fuentes para que los usuarios puedan tomar decisiones informadas. También construimos bucles de retroalimentación donde los expertos del dominio pueden marcar resoluciones incorrectas, lo que mejora la clasificación de recuperación con el tiempo.
MicrocosmWorks utiliza chunking consciente del contenido que aplica diferentes estrategias basadas en la estructura del documento—división semántica de párrafos para prosa, chunking a nivel de fila o a nivel de sección para tablas con el contexto del encabezado preservado, y chunking a nivel de función para código con sentencias import adjuntas. Enriquecemos cada chunk con metadatos incluyendo título del documento, jerarquía de sección y tipo de contenido para que la etapa de recuperación pueda aplicar puntuación específica por tipo. Este enfoque supera consistentemente el chunking ingenuo de tamaño fijo en un 25-40% en los benchmarks de relevancia de recuperación en nuestros proyectos de cliente.
MicrocosmWorks construye arneses de evaluación que prueban los pipelines de RAG en tres dimensiones: relevancia de recuperación (¿se encuentran los fragmentos correctos?), fidelidad de la respuesta (¿la respuesta generada realmente refleja el contenido recuperado?) y completitud de la respuesta (¿aborda la pregunta completa?). Creamos conjuntos de pruebas de referencia con expertos del dominio que incluyen consultas con respuestas conocidas, casos límite adversariales y preguntas que requieren síntesis multi-documento. Esta evaluación se ejecuta automáticamente en CI/CD para que cada cambio en el pipeline sea comparado con métricas de calidad de referencia antes del despliegue.
MicrocosmWorks selecciona bases de datos vectoriales basándose en su escala, patrón de consulta y requisitos operativos: Pinecone para una simplicidad gestionada, Weaviate para búsqueda híbrida de palabras clave y vectores, pgvector para equipos que ya invierten en PostgreSQL, y Qdrant para despliegues autoalojados de alto rendimiento. A escalas inferiores a 10 millones de vectores, la mayoría de las opciones ofrecen una latencia inferior a 100ms, pero las diferencias se vuelven significativas en cientos de millones de vectores donde el tipo de índice, la cuantificación y la estrategia de sharding importan enormemente. Comparamos sus dimensiones de embedding reales y patrones de consulta con las opciones preseleccionadas durante nuestra fase de diseño de arquitectura.
MicrocosmWorks construye pipelines de ingesta incremental que monitorean los repositorios de documentos fuente en busca de cambios, re-chunk y re-embed solo las secciones modificadas, y actualizan el vector store sin requerir una reindexación completa. Implementamos document fingerprinting que detecta cambios de contenido a nivel de sección, así una edición de un solo párrafo no activa el reprocesamiento de un documento completo de 200 páginas. Para clientes con requisitos de frescura en tiempo real, añadimos una capa de recuperación en vivo que consulta directamente el sistema fuente en busca de documentos modificados recientemente y fusiona esos resultados con los aciertos de la búsqueda vectorial.