Construir un chatbot con RAG (Retrieval-Augmented Generation, o generación aumentada por recuperación) significa darle a un modelo de lenguaje acceso a tus propios documentos antes de que genere una respuesta. El resultado es un chatbot con IA que responde sobre información específica que no formó parte de su entrenamiento original, con citas rastreables y con menos riesgo de que fabrique información, aunque no lo elimina del todo.
Qué es un chatbot RAG y en qué se diferencia de un LLM estándar
Un LLM (Large Language Model, modelo de lenguaje de gran tamaño) como GPT-4 o Llama 3 sabe lo que aprendió durante su entrenamiento. Si le preguntas por el reglamento interno de tu empresa o por un manual técnico que publicaste la semana pasada, sencillamente no lo tiene. Un chatbot RAG soluciona esto añadiendo una fase de recuperación: antes de generar texto, el sistema busca los fragmentos más relevantes de tu base de conocimiento y se los entrega al modelo como contexto.
La diferencia es estructural, no de ajuste fino. El fine-tuning modifica los pesos del modelo para que aprenda conocimiento nuevo de forma permanente, pero es costoso, lento y difícil de actualizar. RAG mantiene el modelo intacto y recupera información en tiempo real desde una fuente externa. Eso lo hace mucho más práctico para entornos empresariales donde los documentos cambian con frecuencia.
Los componentes que necesitas antes de escribir la primera línea de código
Un pipeline RAG tiene cinco piezas que trabajan en secuencia: el corpus de documentos, el sistema de chunking (división en fragmentos), el modelo de embeddings, la base vectorial y el LLM que genera la respuesta final. Entender qué hace cada pieza evita el error más habitual en este tipo de proyectos: ajustar la recuperación cuando el problema real está en el chunking, o al revés.
Para orquestar todo el flujo, LangChain es la librería de referencia en Python. Proporciona abstracciones para cargar documentos, dividirlos, convertirlos en vectores, conectarlos a una base vectorial y encadenar la recuperación con la generación. No es la única opción, pero sí la más documentada y la que mejor cubre el ciclo completo de un chatbot RAG.
Paso a paso: ingesta, chunking, embeddings y base vectorial
1. Ingesta de documentos
El primer paso es cargar los documentos en memoria. LangChain incluye loaders para PDF, Markdown, HTML, CSV y otros formatos habituales. Un PyPDFLoader lee un PDF página a página y devuelve una lista de objetos Document, cada uno con su texto y sus metadatos (nombre de archivo, número de página). Esos metadatos importan: sin ellos, cuando el chatbot cite un fragmento, no podrás rastrearlo hasta la fuente original.
2. Chunking: dividir sin romper el significado
Los modelos de embeddings y los LLM tienen un límite de tokens: no pueden procesar documentos enteros de una vez. El chunking divide el texto en fragmentos manejables. La estrategia más común es el RecursiveCharacterTextSplitter de LangChain, que intenta cortar por párrafos, luego por frases y solo como último recurso por caracteres, para no partir una idea por la mitad.
El tamaño del chunk y el solapamiento entre fragmentos consecutivos (el parámetro chunk_overlap) son las dos variables que más afectan a la calidad de la recuperación. Chunks demasiado pequeños pierden contexto; chunks demasiado grandes saturan la ventana del LLM. Un punto de partida razonable para documentación técnica es 500-800 tokens por chunk con un solapamiento de 50-100 tokens, aunque siempre conviene evaluar con tus propios documentos antes de darlo por bueno.
3. Embeddings: convertir texto en vectores
Un embedding es una representación numérica del significado de un texto. Dos fragmentos semánticamente parecidos tendrán vectores cercanos en el espacio matemático, aunque usen palabras distintas. Eso es lo que permite buscar por significado en lugar de por palabra clave exacta. Modelos habituales para este paso son text-embedding-3-small de OpenAI o los modelos de la familia sentence-transformers si prefieres una opción local y sin coste por llamada.
4. Base vectorial: almacenar y recuperar
Los embeddings generados se almacenan en una base vectorial, que permite hacer búsquedas por similitud de forma eficiente. Las opciones más usadas en proyectos reales son pgvector (una extensión de PostgreSQL, útil si ya tienes infraestructura Postgres), Elasticsearch con soporte vectorial y bases dedicadas como Chroma o Weaviate para prototipado rápido. La elección depende de la escala del proyecto y de si necesitas combinar búsqueda vectorial con filtros por metadatos.
Recuperación y generación: el núcleo del chatbot RAG
5. Recuperación: encontrar los fragmentos relevantes
Cuando el usuario hace una pregunta, el sistema la convierte en un embedding y busca los fragmentos más similares en la base vectorial. El retriever estándar de LangChain devuelve los k fragmentos más cercanos por similitud coseno. Para mejorar la precisión, existe una técnica llamada RAG Fusion, que genera varias versiones reformuladas de la pregunta original, lanza una búsqueda por cada una y fusiona los resultados usando Reciprocal Rank Fusion. El efecto práctico es que el sistema captura fragmentos relevantes que una sola consulta habría perdido.
El query routing es otra pieza útil cuando tienes varias bases de conocimiento. Un componente previo a la búsqueda decide a qué fuente dirigir la pregunta según su contenido, en lugar de buscar en todas a la vez. Esto reduce el ruido en la recuperación y mejora la coherencia de las respuestas.
6. Generación: el LLM responde con contexto
Los fragmentos recuperados se insertan en el prompt del LLM junto con la pregunta original. El modelo genera una respuesta basada en ese contexto, no en su conocimiento general. La calidad de esa respuesta depende tanto de la precisión de la recuperación como del prompt que uses: un prompt mal construido puede hacer que el modelo ignore los fragmentos recuperados o que fabrique información cuando el contexto no es suficiente.
Para evaluar si el sistema funciona bien, la técnica LLM-as-Judge utiliza otro modelo de lenguaje como evaluador automático. Comprueba si la respuesta generada está fundamentada en los fragmentos recuperados (groundedness) y si responde realmente a lo que preguntó el usuario (relevancia). Esto permite iterar sobre el pipeline con criterios objetivos en lugar de evaluarlo solo a ojo.
Límites reales que un tutorial no puede ignorar
Un chatbot RAG bien construido no es infalible. Si el documento relevante no está en el corpus, el modelo puede generar una respuesta plausible pero incorrecta. La cobertura del corpus importa tanto como la calidad del pipeline. Mantenerlo actualizado requiere reingesta periódica, lo que implica un proceso de actualización que hay que diseñar desde el principio, no como una ocurrencia posterior.
La latencia es otro factor a gestionar. Cada consulta implica al menos dos llamadas a API (embeddings y LLM) más una búsqueda vectorial, y ese tiempo acumulado en algunos entornos de producción resulta perceptible para el usuario. Si encima usas modelos comerciales, el coste escala con el volumen de consultas y con el tamaño de los chunks que metes en el prompt.
Qué formación necesitas para implementar esto en un proyecto real
Construir un chatbot RAG funcional requiere dominar Python con soltura, entender cómo funcionan los modelos de lenguaje por dentro y saber manejar bases de datos vectoriales, APIs externas y librerías como LangChain. No es un proyecto de fin de semana si partes de cero en alguna de esas áreas.
Si ya tienes base en Python, Data Science y machine learning, el Curso IA Generativa Aplicada de Datahack trabaja exactamente este stack: LangChain, bases vectoriales (pgvector, MongoDB, Elasticsearch), arquitecturas RAG y RAG Fusion, query routing, LangGraph y evaluación con LLM-as-Judge. La metodología es práctica desde el primer módulo, con proyectos sobre casos reales.
Si tu base de Python todavía no es sólida, el punto de partida más directo es el Curso Python desde cero, que te da la base necesaria para seguir avanzando hacia proyectos de IA generativa con criterio técnico real.
Si quieres revisar el temario completo del Curso IA Generativa Aplicada o valorar qué itinerario encaja mejor con tu nivel actual, puedes escribir a Datahack y te orientan sin compromiso.
Preguntas frecuentes
¿Qué diferencia hay entre un chatbot RAG y un chatbot entrenado con fine-tuning?
El fine-tuning modifica los pesos internos del modelo para que asimile conocimiento nuevo de forma permanente. RAG no toca el modelo: recupera información externa en el momento de la consulta y la pasa como contexto. RAG es más fácil de actualizar y más económico para la mayoría de casos de uso empresarial, aunque exige mantener el corpus al día.
¿Qué base vectorial es mejor para empezar a construir un chatbot RAG?
Para prototipado rápido, Chroma es sencilla de instalar y no requiere infraestructura externa. Si el proyecto va a producción y ya usas PostgreSQL, pgvector es una opción madura que evita añadir un servicio nuevo. Elasticsearch tiene sentido cuando necesitas combinar búsqueda vectorial con búsqueda por texto y filtros complejos sobre metadatos.
¿Cuántos documentos puede manejar un chatbot RAG?
El límite práctico lo marcan la base vectorial y la estrategia de indexación, no el modelo de lenguaje. Una base vectorial bien configurada puede indexar millones de fragmentos. El verdadero reto no es el volumen, sino mantener la calidad del corpus: documentos desactualizados o mal estructurados degradan la recuperación independientemente del tamaño total.
¿Es imprescindible usar LangChain para construir un chatbot con RAG?
No es imprescindible, pero sí reduce significativamente el tiempo de desarrollo. LangChain abstrae la carga de documentos, el chunking, la conexión con bases vectoriales y el encadenamiento con el LLM. Alternativas como LlamaIndex cubren un espacio similar. Para producción a gran escala, algunos equipos prefieren implementar el pipeline directamente sobre las APIs del proveedor del modelo para tener más control.
¿Cómo se evalúa si un chatbot RAG responde bien?
Hay dos criterios principales: que la respuesta se base en los fragmentos recuperados (groundedness) y que responda a lo que preguntó el usuario (relevancia). Además del LLM-as-Judge, que delega esa evaluación en otro modelo, conviene rastrear métricas del retriever: cuántos fragmentos recuperados son irrelevantes (precisión) y cuántos relevantes se quedan sin recuperar (exhaustividad).
