TECNOLOGÍAS

RAG

Retrieval-Augmented Generation

Inyecta contexto relevante en el prompt del LLM en tiempo de ejecución, sacado de tus propios datos, para que el modelo responda desde tu conocimiento y no desde sus datos de entrenamiento.

Última revisión: porKevin Riedl wiki ↗

RAG es la arquitectura que permite a un LLM responder a preguntas sobre datos en los que no fue entrenado. El mecanismo es directo: coge la pregunta del usuario, recupera los chunks más relevantes de tu corpus (vía búsqueda vectorial, por keywords o híbrida), mételos en el prompt y deja que el modelo responda. Es la capa de fundamentación bajo la mayoría de AI agents útiles.

Por qué existe RAG: entrenar un modelo con tus datos privados es caro, lento y queda obsoleto en cuanto tus datos cambian. RAG lo evita tratando los datos como contexto en tiempo de ejecución. Trade-off: la calidad de la recuperación se vuelve el cuello de botella. Un modelo con mal contexto produce respuestas erróneas con seguridad.

Ejemplo del fallo clásico: una empresa construye un bot de soporte sobre sus docs de ayuda, la demo impresiona, y luego en producción cita con seguridad la política de reembolso equivocada. El instinto es culpar al modelo y probar uno más grande. Las respuestas siguen mal, porque el problema está aguas arriba: los docs se trocearon a mitad de frase, los embeddings no distinguen «reembolso» de «devolución», y no hay reranker que suba el pasaje correcto arriba. Mete mejor chunking, búsqueda híbrida y un reranker y el mismo modelo de pronto parece listo. La lección generaliza: cuando RAG se equivoca, sospecha de la recuperación antes que de la generación casi siempre.

El trade-off honesto y dónde se rompe RAG: brilla en preguntas tipo lookup contestables desde unos pocos pasajes, y se degrada cuando la respuesta exige sintetizar entre muchos documentos o reconciliar contradicciones en el corpus. En ese punto quieres un corpus curado más pequeño, un pipeline agéntico que razone por pasos, o fine-tuning, no un retriever más grande. La verdad poco sexy es que el 80 % del trabajo es hacer buena la recuperación (chunking, embeddings, reranking, búsqueda híbrida) y el 20 % el modelo. Envolver tus fuentes de datos como servidores MCP hace portátil la capa de recuperación, pero no la hace buena. Los vendors que venden RAG como una feature de un clic venden la parte fácil.

// FAQ

Preguntas frecuentes

RAG si los datos cambian, son privados o son específicos del cliente. Fine-tuning si el conocimiento es estable y necesitas un tono o estilo muy concreto. Para casi todo lo empresarial, RAG. Fine-tuning está sobrevendido; suele ser caro, complejo y se queda obsoleto la próxima vez que cambien tus datos.
Porque el chunking, el reranking y el filtrado por metadatos son el 80 % del trabajo y nadie los hace en la demo. La búsqueda vectorial pura encuentra cosas «similares» sin saber si son relevantes. Sin reranking ni filtros, el LLM recibe contexto plausible pero equivocado y responde con seguridad falsa.
Empieza por algo barato y bien documentado (text-embedding-3-large de OpenAI, Cohere embed v3, o un open-weights como bge-large) y mide en tu corpus con un eval real. El «mejor» embedding cambia cada seis meses; el dataset de evaluación que tú construyas es lo que sigue valiendo el año que viene.