Inicio / Artículos / Explicación de RAG: Permitir que los LLM tengan acceso al conocimiento externo

Explicación de RAG: Permitir que los LLM tengan acceso al conocimiento externo

Una guía sencilla para principiantes sobre RAG: fragmentación de texto, embeddings, búsqueda vectorial, recuperación híbrida y cuándo RAG sigue generando información falsa, con diagramas claros de la arquitectura.

2065 palabras

Los modelos de lenguaje grandes responden a partir de su memoria de entrenamiento. Esa memoria es poderosa pero incompleta: puede omitir manuales internos, políticas obsoletas y hechos que nunca aparecieron en textos públicos. La generación reforzada por recuperación de información (RAG) cierra esa brecha al buscar primero material externo relevante y luego pedirle al modelo que responda a partir de ese material.

¿Qué es RAG?

Sin recuperación de información, una pregunta va directamente al modelo:

User Question
      ↓
     LLM
      ↓
   Answer

Con RAG, el sistema encuentra información relevante antes de generar la respuesta:

User Question
      ↓
Find Relevant Information
      ↓
Give Information to the LLM
      ↓
     LLM
      ↓
   Answer

El modelo sigue redactando el texto final; el nuevo elemento es un contexto basado en un almacén de conocimientos.

¿Por qué necesitamos RAG?

Los plazos de entrenamiento, los corpus privados y las políticas en constante cambio rompen con las respuestas basadas únicamente en la memoria. Un manual para empleados actualizado la semana pasada no estará incluido en los pesos de un modelo frontier. RAG permite que el asistente consulte ese manual al momento de hacer una pregunta sin necesidad de volver a entrenarlo.

Un ejemplo sencillo de RAG

Un empleado pregunta sobre la posibilidad de trasladar días de vacaciones. El flujo es el siguiente:

Employee asks a question
          ↓
Search the employee handbook
          ↓
Find the relevant section
          ↓
Give that section to the LLM
          ↓
LLM generates the answer

El asistente debe citar el manual, no inventar una política que “suene correcta”.

¿Cómo funciona RAG?

Hay dos fases importantes: preparar el conocimiento de forma offline y luego responder online.

1. Preparar el conocimiento

Se ingieren archivos, se dividen, se incrustan los fragmentos y se almacenan vectores para búsquedas.

2. Responder a la pregunta

Se incrusta la pregunta, se obtienen los fragmentos más relevantes, se agrupan en un prompt y se genera la respuesta.

Parte 1: Preparar el conocimiento

Fuentes típicas para un asistente de recursos humanos:

Employee Handbook
Vacation Policy
Benefits Guide
Leave Policy

El proceso de preparación:

Documents
    ↓
Extract Text
    ↓
Break into Smaller Pieces
    ↓
Create Embeddings
    ↓
Store for Search

Paso 1: Obtener la información

Extraer texto limpio de cada fuente:

Employee Handbook
        ↓
    Extract text
        ↓
"Employees receive..."
"Vacation requests..."
"Leave policy..."

Los encabezados, pies de página y elementos de navegación deben eliminarse temprano para que nunca se conviertan en “hechos”.

Paso 2: Dividir el documento en fragmentos

Los manuales extensos superan los límites de contexto y ocultan los párrafos relevantes. Al dividirlos en fragmentos se obtienen unidades que pueden buscarse:

Employee Handbook
       ↓
 ┌───────────────┐
 │    Chunk 1    │
 ├───────────────┤
 │    Chunk 2    │
 ├───────────────┤
 │    Chunk 3    │
 ├───────────────┤
 │      ...      │
 └───────────────┘

¿Por qué es importante dividir en fragmentos?

Los fragmentos demasiado grandes diluyen la relevancia; los fragmentos demasiado pequeños pierden las reglas circundantes (especialmente las negaciones y excepciones). La superposición entre fragmentos vecinos mantiene el contexto de los límites. Comience con algo simple: tamaño fijo con superposición, y luego ajuste según las evaluaciones que muestren errores.

Paso 3: Crear embeddings

Los embeddings asignan texto a vectores de modo que las frases con significado similar queden cerca, incluso sin palabras clave en común.

Texto de la pregunta:

"What is my vacation allowance?"

Una parafrasis con el mismo propósito:

"How many annual leave days do I get?"

Ambos pueden ubicarse cerca del mismo fragmento relacionado con la política de vacaciones después del proceso de incrustación:

"What is my vacation allowance?"
              ↓
          Embedding
              ↓
       Numerical representation

Use el mismo herramienta de incrustación para indexar y realizar búsquedas; mezclar modelos interfiere silenciosamente con la búsqueda de vecinos más cercanos.

Paso 4: Almacenar la información para búsquedas

Cada fragmento junto con su vector se guarda en un índice vectorial (o almacenamiento híbrido):

Document Chunk
      ↓
   Embedding
      ↓
Vector Database

Los metadatos —título de la fuente, página, nivel de acceso, fecha de vigencia— deben ir junto al fragmento para poder utilizarlos posteriormente en filtros y citaciones.

Parte 2:Responder a la pregunta del usuario

Ruta en línea:

User Question
      ↓
Understand the question
      ↓
Search the stored information
      ↓
Find relevant chunks
      ↓
Give those chunks to the LLM
      ↓
Generate an answer

Paso 5:Obtener la información relevante

La incrustación de la pregunta permite recuperar los fragmentos más relevantes, por ejemplo:

Chunk 147 → Vacation carryover policy
Chunk 148 → Vacation request process
Chunk 62  → Employee benefits
Chunk 300 → Security policy

Aquí, la calidad de la selección determina la calidad de la respuesta final. Una mala recuperación no puede corregirse con una pregunta mejor redactada.

Paso 6: Proporcionar la información al LLM

El texto obtenido se convierte en el contexto de la instrucción:

Context:Employees may carry over up to 5 unused
vacation days into the following year.
Question:How many vacation days can I carry over?

Las instrucciones deben requerir respuestas basadas en el contexto y reconocer las lagunas cuando este falte.

Paso 7: Generar la respuesta

Retrieved Information
        +
User Question
        ↓
       LLM
        ↓
      Answer

El modelo elabora una respuesta fundamentada en las líneas recuperadas y no en conocimientos genéricos sobre recursos humanos.

La arquitectura completa de RAG

Etiqueta de preparación sin conexión:

KNOWLEDGE PREPARATION

Diagrama de extremo a extremo:

        Documents
            ↓
      Extract Text
            ↓
         Chunking
            ↓
        Embeddings
            ↓
      Vector Database
            │
            │
            │
            ▼
        USER QUESTION
            ↓
        Query Embedding
            ↓
         Retrieval
            ↓
    Relevant Information
            ↓
     Question + Context
            ↓
            LLM
            ↓
          Answer

Antes de la pregunta

Documents
   ↓
Chunks
   ↓
Embeddings
   ↓
Vector Database

Cuando llega la pregunta

Question
   ↓
Retrieval
   ↓
Relevant Context
   ↓
LLM
   ↓
Answer

¿Solo utiliza RAG la búsqueda vectorial?

No. Los sistemas en producción suelen combinar varios métodos.

Búsqueda por palabras clave

Los comparadores léxicos (BM25 y similares) son excelentes para tokens exactos: códigos de políticas, SKU, IDs de errores, nombres propios.

Búsqueda semántica

La búsqueda vectorial detecta paráfrasis y sinónimos que las palabras clave pasan por alto.

Búsqueda híbrida

Combina ambos métodos y luego fusiona las clasificaciones:

Keyword Search
       +
Semantic Search
       ↓
  Hybrid Search

La búsqueda híbrida es una opción sólida por defecto cuando el tráfico mezcla identificadores exactos con consultas en lenguaje natural.

RAG no elimina las alucinaciones

La recuperación de información reduce la invención no respaldada, pero no la elimina por completo. Los modos de fallo incluyen:

Se obtiene el fragmento incorrecto:

User Question
      ↓
Wrong information retrieved
      ↓
LLM
      ↓
Wrong answer

No se encuentra nada relevante, pero el modelo sigue respondiendo:

User Question
      ↓
No relevant information found
      ↓
LLM
      ↓
Unsupported answer

Mitigaciones: recuperación más estricta, reclasificación, instrucciones de rechazo, citas y evaluación basada en la fidelidad, no solo en la fluidez.

RAG vs. ajuste fino

RAG

Es la mejor opción cuando el conocimiento cambia con frecuencia, debe citarse o permanece privado fuera de los datos de entrenamiento. Las actualizaciones implican un nuevo indexación, no un nuevo entrenamiento.

Ajuste fino

Es óptimo cuando es necesario cambiar el comportamiento, el estilo o el formato de las tareas, o cuando los conocimientos son lo suficientemente estables y compactos como para integrarse directamente. Resulta costoso actualizarlo cuando las políticas cambian con frecuencia.

Muchos productos utilizan ambos enfoques: el ajuste fino para las habilidades y RAG para los hechos.

¿Dónde es útil RAG?

Atención al cliente

Asistentes basados en documentos del producto y macros de tickets.

Salud

Búsqueda de protocolos y pautas con estrictos controles de citación y acceso (siguen aplicándose las reglas del dominio).

Finanzas

Respuestas sobre políticas, declaraciones y reglas del producto que deben reflejar siempre el texto aprobado más reciente.

Recursos humanos

Manuales, beneficios, reglas de permisos: exactamente el mismo patrón de preguntas de los empleados mencionado anteriormente.

Desarrollo de software

Documentación interna de resolución de problemas, guías de operaciones y referencias de API junto con los documentos públicos.

¿Cuándo debería usar RAG?

Utilice RAG cuando las respuestas deben reflejar un corpus específico que es más grande que una solicitud, cambia con mayor rapidez que los ciclos de ajuste fino o requiere información sobre su origen. Omita RAG para trivia pura que el modelo base ya conoce, creatividad pura o rutas de latencia ultra baja que no pueden permitirse un paso de recuperación.

¿Qué puede dificultar el uso de RAG?

Límites entre segmentos, desviación en las representaciones vectoriales, índices obsoletos, fugas en el control de acceso y brechas en la evaluación. Un ejemplo concreto:

El usuario pregunta:

User asks:
"What is the vacation carryover policy?"

El sistema recupera la familia de políticas incorrecta:

             ↓System retrieves:
"Health insurance policy"             ↓LLM receives wrong context             ↓Poor answer

Luego el modelo suena seguro al explicar los seguros de salud como si se tratara de un saldo acumulado de vacaciones. Corrija la recuperación y los filtros de metadatos antes de culpar al generador.

¿Qué necesita aprender para crear RAG?

Una escala práctica de habilidades:

RAG Fundamentals
       ↓
Document Processing
       ↓
Chunking
       ↓
Embeddings
       ↓
Vector Databases
       ↓
Retrieval
       ↓
Prompt + Context
       ↓
LLM
       ↓
Evaluation

El procesamiento de documentos, la estrategia de fragmentación, los embeddings, los almacenes vectoriales, el ensamblaje de prompts, la evaluación y las operaciones (reconstrucción, acceso, monitoreo) son todos elementos importantes.

La visión general

Knowledge
                 ↓
            Find relevant
            information
                 ↓
           Give it to LLM
                 ↓
             Generate
              answer

El conocimiento existe fuera del modelo; la obtención de datos cierra esa brecha; la generación representa el paso final.

Las opciones de particionamiento interactúan con la dimensionalidad del embedding y el tipo de índice: las configuraciones HNSW exclusivamente densas se comportan de manera diferente a los almacenes híbridos BM25+vector cuando las consultas contienen tanto texto prosaico como identificadores. Es necesario mantener una política por escrito para los desencadenantes de reconstrucción —nuevas versiones del manual, páginas eliminadas, cambios en permisos— y verificar que los materiales eliminados desaparezcan realmente del índice en lugar de quedar como vectores huérfanos. El formato de las citaciones también debe incluirse en el contrato de generación: si la interfaz promete información sobre el origen a nivel de página, el prompt y el procesador posterior deben generar identificadores de fuente estables, y no notas al pie decorativas que no apunten a ningún lugar.

El re-clasificación merece una breve mención incluso en un camino para principiantes. Una lista reducida generada con un bi-encoder es económica; aplicar un cross-encoder a los cincuenta candidatos principales suele solucionar los errores de “documento casi correcto, sección incorrecta” que hacen que las demostraciones parezcan defectuosas. Combínalo con reglas simples de rechazo cuando las puntuaciones de similitud bajen por debajo de un umbral calibrado. Los equipos que omiten la evaluación suelen descubrir estos problemas frente a las partes interesadas en lugar de en un cuaderno de notas.

Finalmente, recuerde la estructura económica del RAG: el costo de indexación se paga continuamente a medida que crecen los corpus, mientras que el costo del ajuste fino se paga de forma puntual. En dominios con muchas regulaciones, la factura continua por el índice suele ser más económica que los ajustes finos semanales, y además mantiene la posibilidad de citar el párrafo exacto que solicitó un auditor. Esa capacidad de auditoría es a menudo el verdadero requisito del producto que se oculta detrás de la solicitud de “crear un chatbot”.

Cuando se integre RAG en una pila de soporte existente, comience con un único corpus y un grupo específico de preguntas en lugar de intentar abarcar todo al mismo tiempo. Mida la desviación, la escalada y las quejas por respuestas incorrectas en esa parte antes de añadir espacios de Confluence de forma masiva. Los resultados parciales le indicarán qué tamaños de fragmentos y qué pesos híbridos funcionan; los lanzamientos a gran escala suelen demostrar que los paneles sin métricas de fidelidad ocultan regresiones. Mantenga una cola de revisión humana para las respuestas controvertidas durante las primeras semanas, de modo que los editores puedan marcar como “buena recuperación / mala generación” o simplemente “mala recuperación”, ya que corresponden a rutas de reparación diferentes. Con el tiempo, esas etiquetas se convertirán en señales de entrenamiento para los sistemas de reclasificación y para decidir si un tema debe abandonar RAG y convertirse en un flujo de trabajo determinista.

Conclusión final

Store external knowledge
        ↓
Find relevant information
        ↓
Give that information to an LLM
        ↓
Generate a grounded response

Almacena conocimiento externo, busca las piezas relevantes para cada pregunta y solo entonces genera la respuesta. Ese ciclo de tres pasos es RAG: sencillo de concebir, pero difícil de implementar correctamente, y sigue siendo la forma más práctica de mantener a los asistentes fieles a hechos privados y en constante cambio.

La disciplina operativa distingue a las herramientas temporales de los asistentes duraderos: congele un conjunto de preguntas, mida las tasas de éxito en la recuperación junto con el grado de fidelidad de las respuestas, y reconstruya los índices según un calendario acorde a la frecuencia con que cambian los materiales de origen. Cuando se utilicen búsquedas híbridas, reclasificaciones o filtros de metadatos, mantenga la misma hoja de puntuación para que las mejoras sean visibles y no solo anecdóticas. Trate las etiquetas de acceso como parte del contenido a procesar desde el primer día; agregar permisos posteriormente es la forma en que las notas privadas de recursos humanos terminan en chats públicos. Finalmente, prefiera el rechazo acompañado de una solicitud de cita a una suposición improvisada cada vez que los fragmentos principales parezcan débiles: los usuarios confían más en el silencio calibrado que en invenciones pulidas.

Mantenga manuales de procedimiento para la reconstrucción de índices, las revisiones de acceso y los modos de fallo conocidos junto con los diagramas del flujo óptimo, para que los operadores hereden algo más que solo un conjunto de diapositivas.

Mantenga los manuales de operaciones para la reconstrucción de índices, las revisiones de acceso y los modos de fallo conocidos junto a los diagramas del camino óptimo, para que los operadores hereden algo más que solo un conjunto de diapositivas.

Mantenga los manuales de operaciones para la reconstrucción de índices, las revisiones de acceso y los modos de fallo conocidos junto a los diagramas del camino óptimo, para que los operadores hereden algo más que solo un conjunto de diapositivas.

Mantenga los manuales de operaciones para la reconstrucción de índices, las revisiones de acceso y los modos de fallo conocidos junto a los diagramas del camino óptimo, para que los operadores hereden algo más que solo un conjunto de diapositivas.

Mantenga los manuales de operaciones para la reconstrucción de índices, las revisiones de acceso y los modos de fallo conocidos junto a los diagramas del camino óptimo, para que los operadores hereden algo más que solo un conjunto de diapositivas.

Mantenga los manuales de operaciones para la reconstrucción de índices, las revisiones de acceso y los modos de fallo conocidos junto a los diagramas del camino óptimo, para que los operadores hereden algo más que solo un conjunto de diapositivas.

Mantenga los manuales de procedimientos para la reconstrucción del índice, las revisiones de acceso y los modos de fallo conocidos junto a los diagramas del camino óptimo, para que los operadores hereden algo más que solo un conjunto de diapositivas.

Lecturas relacionadas

  • Por qué el RAG empresarial necesita búsqueda híbrida y no solo vectores — Las representaciones incrustadas omiten los IDs de facturas y códigos de error; BM25 combinado con recuperación densa mediante fusión soluciona el problema de los identificadores empresariales.
  • Búsqueda híbrida para el RAG empresarial: la densa sola no es suficiente — Los IDs exactos y códigos poco comunes invalidan las representaciones incrustadas; BM25 junto con fusión densa en paralelo abarca la verdadera variedad de consultas.