BLURTEK Academy · Guía técnica
RAG: cómo dar tus datos a un LLM
Guía práctica de Retrieval-Augmented Generation: embeddings, chunking, base vectorial, prompt aumentado y cuándo elegir RAG frente a fine-tuning.
Un modelo de lenguaje solo conoce lo que vio durante su entrenamiento. No sabe nada de tus manuales internos, tus tickets de soporte ni la documentación privada de tu empresa. RAG (Retrieval-Augmented Generation, generación aumentada por recuperación) es la técnica estándar para inyectar ese conocimiento sin reentrenar el modelo: recuperas los fragmentos relevantes de tus datos y los pasas al modelo como contexto en el momento de la consulta.
La idea en una frase
En lugar de esperar que el modelo sepa la respuesta, se la enseñas justo antes de que responda. El flujo tiene dos fases: una de indexación (offline, una vez) y otra de consulta (online, en cada pregunta).
Los cinco componentes
1. Chunking (troceado)
Tus documentos son demasiado grandes para pasarlos enteros y demasiado heterogéneos para buscar en ellos como bloques únicos. El primer paso es partirlos en fragmentos (chunks) manejables.
- Tamaño típico: entre 200 y 800 tokens por fragmento. Demasiado pequeño pierde contexto; demasiado grande diluye la relevancia y encarece el prompt.
- Solapamiento (overlap): 10–20 % de solape entre chunks contiguos evita cortar una idea a la mitad.
- Respeta la estructura: trocea por secciones, párrafos o encabezados antes que por número fijo de caracteres. Un chunk que empieza a mitad de frase recupera peor.
2. Embeddings
Un embedding es un vector de números (por ejemplo, 768 o 1536 dimensiones) que representa el significado de un texto. Textos semánticamente parecidos producen vectores cercanos en el espacio. Se genera cada chunk una vez con un modelo de embeddings y se almacena su vector.
La clave: usa el mismo modelo de embeddings para indexar los documentos y para vectorizar la pregunta del usuario. Mezclar modelos rompe la comparación.
3. Base vectorial
Es la base de datos que guarda los vectores y permite buscar los más cercanos a uno dado (búsqueda por similitud, normalmente con distancia coseno). Opciones habituales: FAISS, Qdrant, Weaviate, Chroma, pgvector (extensión de PostgreSQL) o Pinecone.
Para volúmenes grandes usan índices aproximados (ANN, como HNSW) que sacrifican una fracción de precisión a cambio de latencia de milisegundos.
4. Recuperación
Cuando llega una pregunta: se vectoriza con el modelo de embeddings, se buscan en la base vectorial los k chunks más similares (top-k, típicamente 3–8) y se devuelven esos fragmentos. Mejoras habituales:
- Búsqueda híbrida: combinar similitud vectorial con búsqueda por palabras clave (BM25) recupera mejor términos exactos, siglas y nombres propios.
- Reranking: un modelo reordenador (cross-encoder) reevalúa los candidatos y sube los más pertinentes al principio.
5. Prompt aumentado
Se construye el prompt final concatenando los fragmentos recuperados con la pregunta y una instrucción clara. Un esqueleto habitual:
Responde a la pregunta usando ÚNICAMENTE el contexto siguiente.
Si el contexto no contiene la respuesta, dilo explícitamente.
<contexto>
{fragmentos_recuperados}
</contexto>
Pregunta: {pregunta_del_usuario}
La instrucción de "usa solo el contexto" y de admitir cuándo no sabe reduce las alucinaciones y hace las respuestas verificables contra la fuente.
RAG frente a fine-tuning
Se confunden a menudo, pero resuelven problemas distintos. RAG aporta conocimiento; el fine-tuning aporta comportamiento.
| Criterio | RAG | Fine-tuning |
|---|
| Datos que cambian a menudo | Ideal: reindexas y listo | Malo: reentrenar cada vez |
| Trazabilidad / citar fuentes | Sí, sabes qué chunk usó | No, el conocimiento queda opaco |
| Enseñar un formato o tono fijo | Limitado | Ideal |
| Coste de puesta en marcha | Bajo | Alto (datos etiquetados + cómputo) |
| Reducir tamaño del prompt | No | Sí |
Regla práctica: si tu problema es "el modelo no conoce mis datos", usa RAG. Si es "el modelo no responde con el estilo o la estructura que necesito", considera fine-tuning. Muchas veces la mejor respuesta es empezar por RAG y solo añadir fine-tuning si el comportamiento sigue sin encajar.
Arquitectura mínima
Un RAG funcional cabe en pocos componentes:
- Indexación (offline): documentos → chunking → modelo de embeddings → base vectorial.
- Consulta (online): pregunta → embedding → búsqueda top-k → prompt aumentado → LLM → respuesta.
Con eso ya tienes un sistema que responde sobre tus propios datos. A partir de ahí, las mejoras incrementales —búsqueda híbrida, reranking, filtros por metadatos, evaluación de la recuperación— son las que separan una demo de un sistema en producción.
Errores frecuentes
- Chunks mal dimensionados: es la causa número uno de recuperaciones malas. Ajústalos antes que cualquier otra cosa.
- No evaluar la recuperación: si el chunk correcto no está entre los top-k, el mejor LLM del mundo no lo arregla. Mide primero la fase de recuperación, luego la generación.
- Meter demasiado contexto: pasar 30 chunks no mejora la respuesta; añade ruido y coste. Menos fragmentos bien elegidos ganan casi siempre.
- Confiar en el modelo sin instruirlo: sin la instrucción de ceñirse al contexto, el modelo rellenará huecos con su conocimiento previo y alucinará.
RAG no es magia: es un buscador semántico acoplado a un generador de texto. Entiende bien cada eslabón —cómo troceas, cómo recuperas y cómo montas el prompt— y tendrás un sistema que responde sobre tus datos de forma fiable y auditable.
Prueba un sistema RAG con preguntas que puedan fallar
Antes de medir la calidad de la respuesta, comprueba la recuperación. Prepara preguntas cuya respuesta esté en un único documento, otras que necesiten combinar fragmentos y algunas que no estén en la colección. Registra qué fragmentos recupera el sistema, su posición y si contienen realmente la evidencia necesaria. Una respuesta fluida con contexto incorrecto sigue siendo un fallo.
Después evalúa fidelidad, cobertura y capacidad de abstención. Exige que la salida cite el documento usado y que reconozca cuándo no dispone de información suficiente. Controla permisos antes de recuperar datos: el modelo no debe recibir un fragmento que el usuario no pueda consultar directamente. El curso de Agentes de IA y Automatización ayuda a integrar recuperación, herramientas, validaciones y supervisión dentro de un flujo completo.
Volver al blog de BLURTEK Academy