Explicación de RAG: Impida que los chatbots inventen datos de la empresa
Una guía práctica del pipeline RAG: cargadores, fragmentación, embeddings, almacenes vectoriales, reclasificación, búsqueda híbrida y RRF, además de indicaciones sobre cuándo no utilizar la recuperación de información en absoluto.
Una tarea común para los primeros chatbots es la siguiente: responder preguntas a partir de archivos de la empresa. Un prototipo rápido suele parecer impecable, pero inventa hechos. Puede afirmar que ofrece “soporte 24/7 en 12 países” cuando el soporte solo existe en un país, durante horas laborables y únicamente cuando está disponible una persona de TI específica.
Ese tipo de fallo es precisamente el objetivo del RAG (Retrieval-Augmented Generation): un modelo que puede generar una respuesta no es lo mismo que uno que cuenta con los datos reales de la organización. Sin base real, los modelos avanzados se comportan como un pariente seguro de sí mismo que inventa historias familiares en una boda: aproximadamente el cuarenta por ciento correcto y cien por ciento seguro de sí mismo.
Parte 1: ¿Qué es realmente el RAG?
RAG significa Retrieval-Augmented Generation. La idea es sencilla.
En lugar de pedirle al modelo que responda únicamente con la memoria adquirida durante su entrenamiento, el sistema primero obtiene el material relevante y luego solicita una respuesta basada en dicho material.
Considere el modelo de texto como un pasante brillante pero demasiado confiado: excelente para escribir, pero deficiente al recordar la política de recursos humanos de 2023. La función de RAG es poner la página adecuada en manos del pasante *antes* de que comience a responder.
Sin RAG: las respuestas se basan en la memoria (obsoleta, genérica o ajena a la empresa). Con RAG: las respuestas se basan en la memoria *además* de los archivos obtenidos para esa pregunta.
Una fórmula concisa que funciona:
Información correcta × Contexto adecuado × Prompt apropiado = Respuesta correcta
Parte 2: El pipeline de RAG
El aumento mediante recuperación de información no es una sola llamada mágica. Se trata de un proceso en varias etapas: si alguna etapa falla, las respuestas llegan tarde o están incorrectas.
Paso 1: Fuentes de conocimiento
¿Dónde se encuentra el material? Los archivos PDF, Word, las páginas de Notion, las tablas SQL, las exportaciones de Slack y las hojas de cálculo olvidadas cuentan todas como fuentes de conocimiento.
Paso 2: Cargadores de documentos (introducir los datos)
La ingesta convierte archivos PDF/HTML/CSV, etc., en un formato limpio y uniforme, generalmente algo como esto:
Document(
page_content="The quick brown fox...",
metadata={"source": "annual_report.pdf", "page": 12, "author": "Finance Team"}
)
Omitir un proceso de carga cuidadoso y introducir directamente los bytes brutos del PDF en el flujo tiende a convertir encabezados y pies de página en “hechos” (“Según la página 47 de 92…”). Nadie pidió ese contenido adicional.
Lección: Una ingesta deficiente genera búsquedas y respuestas defectuosas. Hay que mantener todo limpio desde el principio.
Paso 3: División en fragmentos (también conocido como “cortar la pizza”)
Un PDF de 200 páginas no puede introducirse directamente en una solicitud. Las ventanas de contexto son limitadas, y saturar al modelo con todo un libro de recetas cuando solo se solicitó una receta afecta la precisión.
Por lo tanto, los documentos se dividen en segmentos.
Estrategias comunes:
- División por tamaño fijo — se cortan cada N tokens. Rápido, pero ocurren cortes a mitad de oración.
- División por tamaño fijo con solapamiento — mismos cortes pero con un ligero solapamiento para que el contexto de los límites se mantenga. Es la opción predeterminada habitual.
- División jerárquica/recursiva — se tienen en cuenta las secciones y párrafos antes de realizar los cortes.
- División semántica — se agrupan oraciones del mismo tema mediante embeddings. Más inteligente, pero requiere más recursos computacionales.
- División basada en LLM / Agente — se le pregunta al modelo dónde deben hacerse los cortes. Costoso, útil para textos legales o médicos.
Una regla práctica, tras observar cómo se divide la frase “shall NOT be liable” después de “shall” en un contrato, es: comience con un tamaño fijo más solapamiento; añada complejidad solo cuando la calidad de la recuperación sea realmente deficiente.
Paso 4 — Embeddings (convertir palabras en coordenadas GPS)
Un embedding convierte una oración en una lista de números que captura el significado, no la ortografía. Las oraciones con significados similares aparecen cerca unas de otras incluso si no comparten palabras.
“¿Cómo se puede restablecer una contraseña?” y “Se olvidaron las credenciales de inicio de sesión” comparten casi ningún token, pero significan prácticamente lo mismo. La búsqueda por palabras clave no detecta esa relación; un sistema de embeddings la identifica al comparar los significados.
La historia ha evolucionado desde el método Bag-of-Words (que solo cuenta palabras) → TF-IDF → Word2Vec → BERT → hasta las API modernas de embeddings y modelos abiertos (OpenAI, Cohere, BGE, E5 y otros) que tienen en cuenta el contexto.
Analogía: El método Bag-of-Words es como una traducción automática palabra por palabra. Los embeddings modernos son más similares a alguien que ha vivido en ambas culturas y comprende la intención detrás de las palabras.
Paso 5 — Almacenes vectoriales (la biblioteca donde se guardan todas esas listas de números)
Una vez que los segmentos se convierten en vectores, se necesita un almacenamiento y una búsqueda rápidos: Pinecone, Qdrant, Weaviate, Milvus, ChromaDB, FAISS y sistemas similares.
Dada una consulta, se devuelven los segmentos top-K cuyos vectores están más cerca del vector de la consulta. Las opciones de indexación incluyen:
- Fuerza bruta — comparar todo. Exacto, pero lento a gran escala.
- ANN (Vecino más cercano aproximado) — ligeramente menos exacto, pero mucho más rápido. Opción predeterminada sólida.
- IVF — agrupar primero; buscar solo en los grupos prometedores.
- HNSW — recorrer rápidamente un grafo de vecinos. Común en sistemas RAG en producción.
Usar fuerza bruta con millones de vectores “para lograr una precisión perfecta” puede convertir consultas que tardan milisegundos en tener latencias similares a las de un descanso. Ajuste el índice al tamaño de los datos, no al orgullo.
Paso 6 — Recuperación (Búsqueda de similitud)
Cuando llega una pregunta, incórdénala con el mismo modelo utilizado para los archivos; mezclar modelos es un error clásico, y luego obtenga los segmentos más similares del top-K.
Similitud coseno es la medida habitual: mide cuán alineados están dos vectores en dirección, ignorando su longitud. Es un valor por defecto estable independientemente de la longitud del texto.
Paso 7: Aumentación (entregar al asistente el archivo correcto)
Los segmentos obtenidos se insertan en la prompt junto con la pregunta del usuario. Ese es el paso de “Aumentación”:
System: You are a helpful assistant. Only answer using the context below.
Context: [retrieved chunk 1] [retrieved chunk 2] [retrieved chunk 3]
Question: What is our refund policy?
Paso 8: Generación (el LLM finalmente habla)
Solo entonces el modelo escribe la respuesta final, basada en el contexto obtenido y no en intuiciones.
Parte 3: Lo que diferencia “funciona” de “funciona bien”
Los tutoriales suelen detenerse en el flujo básico. La calidad de los sistemas en tiempo real generalmente requiere algo más.
Re-clasificación: porque el primer resultado de búsqueda no siempre es el mejor
La recuperación con bi-encoders es rápida pero poco precisa: la consulta y el documento se codifican por separado y luego se comparan. Es excelente para reducir millones de elementos a unos 50 candidatos.
“Rápido y más o menos correcto” no siempre significa “realmente correcto”; por eso un re-clasificador con cross-encoders, aunque más lento, evalúa la consulta y el documento juntos, capturando matices, negaciones y contexto. Funciona únicamente con la lista corta de candidatos y destaca los verdaderos mejores resultados.
Analogía: los bi-encoders revisan rápidamente los currículums para formar una lista corta; los cross-encoders realizan la entrevista.
En un bot de preguntas frecuentes médicas sin reclasificación, una pregunta sobre interacciones con el alcohol puede hacer aparecer otro medicamento que solo comparte vocabulario. Un reclasificador mediante codificador cruzado suele solucionar eso de inmediato. Cuando la precisión es importante (en temas legales, médicos o financieros), la reclasificación es obligatoria y no opcional.
Búsqueda híbrida: porque la búsqueda léxica y la búsqueda vectorial son un poco imperfectas por separado
La búsqueda vectorial captura el significado, pero puede pasar por alto tokens exactos como códigos SKU, identificadores de errores o nombres propios. La búsqueda léxica BM25 logra encontrar cadenas exactas, pero no reconoce sinónimos.
Búsqueda híbrida combina el método BM25 con la recuperación vectorial: precisión en las palabras clave más capacidad de recordar el significado semántico. Cuando no se está seguros, la opción híbrida es una excelente elección por defecto: rara vez empeora las resultados y a menudo los mejora.
Fusión RAG: combinar múltiples opiniones como en un proyecto grupal (pero esta vez realmente funciona)
Varios recuperadores de información (denso, por palabras clave, específico del dominio) generan múltiples listas ordenadas. RAG Fusion las combina con Reciprocal Rank Fusion (RRF).
La idea es sencilla, incluso aunque la fórmula parezca formal: un documento que ocupa una posición cercana a la cima en varios métodos independientes probablemente sea relevante. RRF premia la consistencia entre las listas en lugar de las puntuaciones brutas que no son comparables entre los diferentes recuperadores.
RRF(d) = Σ 1 / (k + rank_i(d))
Aquí, k suele ser 60: una convención del sector más que una constante derivada.
Metadatos: las etiquetas que te salvarán la vida más adelante
Los metadatos son datos sobre otros datos: título, autor, fecha, fuente, nivel de acceso. Parecen aburridos hasta que aparece una regla de acceso —“nunca mostrar documentos internos de recursos humanos a usuarios externos”— y las etiquetas access_level: internal de repente adquieren importancia.
Los metadatos permiten la aplicación de filtros, mejoras en el ranking, control de acceso y depuración (“¿por qué un documento de 2019 respondió a una pregunta de 2026?” → falta filtros por fecha).
Memoria y caché: porque nadie quiere pagar dos veces por el mismo cálculo
Dos conceptos que a menudo se confunden:
- Memoria = recordación a largo plazo de preferencias, interacciones anteriores y hechos permanentes.
- Caché = reutilización a corto plazo de resultados costosos (respuestas del modelo, resultados de búsqueda) para consultas repetidas.
La memoria hace que los asistentes parezcan coherentes. El caché los hace rápidos y económicos. Mezclarlos, por ejemplo “cachear” preferencias con un TTL de diez minutos, puede hacer que el nombre de un usuario desaparezca en medio de la conversación. Mantenga los conceptos separados.
Parte 4: ¿Cuándo NO debe usar RAG?
El aumento mediante recuperación de información no es una solución universal.
Omita RAG cuando:
- La pregunta corresponde a conocimientos generales que el modelo ya maneja (“la capital de Francia” no necesita un índice vectorial).
- Los hechos cambian continuamente (precios, marcadores en tiempo real); es mejor utilizar una API.
- La tarea es puramente creativa (poesía, lluvia de ideas); la recuperación de información rara vez ayuda.
- El corpus es lo suficientemente pequeño como para incluirlo directamente en la instrucción.
- Una latencia ultra baja no puede permitirse un paso adicional de recuperación de datos.
A veces la solución está en redactar instrucciones más claras o realizar un ajuste fino, y no en utilizar un flujo vectorial completo. Elige la herramienta adecuada antes de comenzar a implementarla.
Parte 5: Buenas prácticas aprendidas a la fuerza
- Divide el texto de manera inteligente, no en fragmentos muy pequeños. Los segmentos demasiado pequeños pierden contexto; los segmentos demasiado grandes pierden precisión. Es mejor que haya solapamiento.
- Utiliza un mismo modelo de incrustación para los archivos y las consultas. Mezclar modelos equivale a medir en unidades diferentes.
Los equipos que tratan la recuperación de información como algo secundario suelen volver a encontrar los mismos problemas: desviaciones silenciosas en el esquema de los cargadores, límites entre bloques que afectan negaciones, incoherencias en los modelos de integración entre el indexado offline y las consultas en línea, y paneles de control que solo miden la “latencia de respuesta” mientras ignoran la fidelidad de los resultados. Una práctica sólida de RAG trata cada etapa del proceso como una superficie de producto con responsables, pruebas y planes de reversión, especialmente cuando el asistente interactúa con clientes o en flujos de trabajo regulados.
Al evaluar cambios, prefiera experimentos emparejados: mismo conjunto de preguntas, misma escala de evaluación, y compare los resultados de Recall@k y la solidez de las respuestas antes y después de realizar ajustes en el procesamiento de bloques o en los algoritmos de clasificación. Pequeñas mejoras en la recuperación de información suelen ser más efectivas que ajustes mayores basados únicamente en los prompts, ya que el generador no puede citar elementos que nunca entraron en la ventana de contexto.
El mantra del RAG
Información correcta → Contexto adecuado → Prompt preciso → Respuesta correcta.
RAG es como la plomería, no magia. Una entrada limpia, una recuperación sensata, un aumento honesto de información y un prompt bien definido convierten a un “primo” demasiado confiado en un especialista bien informado que primero lee el archivo, evitando así inventar una asistencia global 24/7 que nunca existió.