RAG Cómo Crear una IA que Consulte tu Base de Conocimiento

1. Qué es RAG y por qué es útil

RAG significa Retrieval-Augmented Generation, o Generación Aumentada por Recuperación. Es una arquitectura que combina dos capacidades: buscar información relevante dentro de una base de conocimiento y utilizar esa información como contexto para que un modelo de lenguaje genere una respuesta.

La idea clave es sencilla: en lugar de pedirle al modelo que “sepa” todo sobre tu empresa, tus manuales o tus procedimientos, el sistema busca primero los fragmentos que podrían responder la pregunta. Después se los entrega al modelo junto con la consulta del usuario.

Figura 1. Flujo simplificado de una consulta RAG.

Cuándo conviene usar RAG

• Manuales internos, procedimientos y políticas de empresa.

• Documentación técnica, fichas de productos y preguntas frecuentes.

• Contratos, normativas o bibliotecas documentales que cambian con frecuencia.

• Bases de conocimiento de soporte y atención al cliente.

• Documentación de proyectos, actas, informes y documentación comercial.

• Catálogos grandes donde una búsqueda por palabras exactas resulta insuficiente.

RAG es especialmente útil cuando la información cambia con frecuencia. Actualizar documentos e indexarlos nuevamente suele ser más simple que reentrenar un modelo.

2. El problema que RAG resuelve

Un modelo de lenguaje general responde a partir de patrones aprendidos durante su entrenamiento y del contexto que recibe en la conversación. No tiene acceso automático a las carpetas de tu empresa, a un PDF privado ni a la última versión de un procedimiento interno.

Además, incluso un modelo muy capaz puede completar huecos con información plausible pero incorrecta. RAG reduce este problema porque obliga al sistema a buscar evidencia antes de responder.

3. Anatomía de un sistema RAG

Un RAG completo tiene dos grandes momentos. El primero ocurre antes de que el usuario pregunte: la ingesta. El segundo ocurre en tiempo real: la consulta.

Fase A: ingesta

Los documentos se cargan, se convierten a texto, se limpian, se dividen en fragmentos y cada fragmento se transforma en una representación matemática llamada embedding. Finalmente, esos embeddings y sus metadatos se almacenan en un índice preparado para búsquedas.

Figura 2. Pipeline de ingesta de documentos.

Fase B: consulta

Cuando llega una pregunta, también se genera un embedding de esa consulta. El sistema compara la consulta con los fragmentos indexados, recupera los más similares y construye un prompt que contiene la pregunta más la evidencia encontrada.

4. Documentos, limpieza y preparación de datos

La calidad del RAG depende directamente de la calidad de la base de conocimiento. Un sistema sofisticado no compensa documentos duplicados, versiones contradictorias, tablas mal extraídas o textos sin estructura.

Fuentes habituales

• PDF y PDF con texto digital.

• DOCX, TXT y Markdown.

• Páginas web y centros de ayuda.

• CSV, hojas de cálculo y exportaciones de sistemas.

• Wikis, bases documentales y repositorios internos.

Qué limpiar

• Encabezados y pies repetidos que no aportan contenido.

• Menús, avisos legales repetidos y bloques de navegación web.

• Duplicados y versiones obsoletas.

• Caracteres extraños o saltos de línea incorrectos.

• Datos sensibles que no deberían entrar al índice.

Consejo: conserva siempre el documento original. La versión procesada sirve para buscar; el original sirve para auditar y verificar.

5. Chunking: cómo dividir la información

Un chunk es un fragmento de texto que se indexará como una unidad. Si los chunks son demasiado grandes, mezclan temas y empeoran la precisión. Si son demasiado pequeños, pierden contexto.

Para un primer proyecto, comienza con fragmentos equivalentes a unas pocas centenas de tokens y un pequeño solapamiento entre fragmentos. Luego ajusta con pruebas reales; no existe un tamaño universal.

Metadatos que conviene guardar

• Nombre del archivo.

• Título o sección.

• Número de página si existe.

• Fecha o versión.

• Área, cliente, producto o categoría.

• Nivel de acceso o grupo autorizado.

6. Embeddings explicados de forma simple

Un embedding es una lista de números que representa el significado aproximado de un texto. Textos con significado parecido tienden a quedar cerca en ese espacio matemático, aunque no utilicen exactamente las mismas palabras.

Por ejemplo, una consulta como “¿cómo recupero mi contraseña?” puede encontrar un fragmento titulado “Restablecimiento de credenciales”, aun cuando no comparta todas las palabras.

Lo importante es utilizar el mismo modelo de embeddings para indexar los documentos y para convertir las preguntas de los usuarios. Si cambias de modelo, normalmente deberás volver a generar el índice.

7. Base vectorial y búsqueda semántica

Una base vectorial almacena embeddings y permite encontrar rápidamente los vectores más cercanos a una consulta. En muchos proyectos no necesitas una infraestructura separada: varias bases de datos modernas incorporan búsqueda vectorial mediante extensiones o funciones específicas.

Cada registro debería unir tres elementos: el texto del fragmento, su embedding y sus metadatos. Así, cuando recuperas un resultado, también sabes de qué archivo, página o sección proviene.

8. Recuperación: Top-K, filtros y relevancia

Figura 3. Recuperación semántica con filtros de metadatos.

Top-K indica cuántos fragmentos recuperas inicialmente. Recuperar muy pocos puede omitir evidencia; recuperar demasiados puede llenar el prompt con ruido. El valor adecuado depende del tipo de documentos y de la longitud de los fragmentos.

Filtros antes o durante la búsqueda

Los filtros son fundamentales en entornos empresariales. Puedes limitar la búsqueda por cliente, departamento, idioma, producto, fecha o nivel de acceso. Esto mejora la precisión y evita mezclar información que no corresponde.

Ejemplo: si un empleado pregunta por vacaciones, el sistema podría filtrar por país y versión vigente de la política antes de calcular similitud.

9. Prompt aumentado y generación de la respuesta

Una vez recuperados los fragmentos, el sistema construye un prompt. Este prompt debe indicar al modelo qué hacer con la evidencia y qué hacer cuando la evidencia no alcanza.

Una instrucción robusta suele incluir: rol, objetivo, fragmentos recuperados, reglas para no inventar, formato de salida y obligación de citar las fuentes.

Regla recomendada: “Responde únicamente con la información proporcionada. Si la evidencia no permite responder con seguridad, indícalo y solicita más contexto o deriva a una persona.”

También conviene separar claramente las instrucciones del sistema, la evidencia recuperada y la pregunta del usuario. Esa separación hace el comportamiento más predecible.

10. Fuentes, citas y control de alucinaciones

RAG reduce las alucinaciones, pero no las elimina por sí solo. Un fragmento irrelevante puede ser recuperado; un documento puede estar desactualizado; o el modelo puede interpretar mal una instrucción.

Controles recomendados

• Mostrar nombre de archivo y sección utilizados.

• Permitir abrir la fuente original.

• Indicar cuando la evidencia es insuficiente.

• Aplicar un umbral mínimo de relevancia cuando sea apropiado.

• Evitar responder sobre temas fuera del alcance de la base.

• Registrar preguntas, fragmentos recuperados y respuesta para evaluación.

11. Arquitectura recomendada para un primer proyecto

Figura 4. Componentes de un asistente RAG sencillo.

Para un MVP no necesitas decenas de servicios. Puedes trabajar con una interfaz de chat, un backend que ejecute el flujo RAG, almacenamiento de documentos, una base con soporte vectorial y un modelo de lenguaje.

12. Proyecto práctico: asistente RAG para una empresa

Proyecto objetivo: construir un “Asistente de Procedimientos” que responda preguntas sobre manuales internos. El usuario podrá preguntar, por ejemplo, cómo solicitar una compra, cómo escalar un incidente o qué documentación requiere un proceso.

Alcance del MVP

• Cargar entre 10 y 30 documentos representativos.

• Indexar automáticamente el contenido.

• Permitir preguntas desde una interfaz simple.

• Recuperar los fragmentos más relevantes.

• Responder usando solo la evidencia encontrada.

• Mostrar las fuentes utilizadas.

• Registrar preguntas que no pudieron responderse.

Criterio de éxito

El MVP será útil cuando responda correctamente la mayoría de un conjunto de preguntas reales y, especialmente, cuando sepa decir “no encuentro información suficiente” en lugar de inventar.

Paso 1. Selecciona un caso de uso estrecho

No empieces con “toda la empresa”. Elige una colección documental coherente: soporte de un producto, procedimientos de RR. HH., documentación técnica o políticas comerciales.

Paso 2. Reúne y depura documentos

• Identifica la versión vigente de cada documento.

• Elimina duplicados evidentes.

• Clasifica por área, tema, fecha y nivel de acceso.

• Define qué archivos quedan fuera por contener datos innecesarios o sensibles.

Paso 3. Extrae texto y conserva estructura

Intenta conservar títulos, subtítulos, páginas y tablas relevantes. La estructura servirá para crear mejores chunks y mejores referencias.

Paso 4. Divide en chunks

Empieza con una estrategia simple basada en títulos y párrafos. Añade solapamiento cuando una explicación pueda quedar partida entre dos fragmentos.

Paso 5. Genera embeddings e indexa

Por cada chunk, genera un embedding y guarda texto, vector y metadatos. Haz el proceso reproducible: si un documento cambia, debes poder eliminar o reemplazar sus chunks.

Paso 6. Implementa la consulta

• Recibe la pregunta.

• Aplica permisos y filtros.

• Genera el embedding de consulta.

• Busca los fragmentos más cercanos.

• Construye el prompt con esos fragmentos.

• Solicita la respuesta al modelo.

• Devuelve respuesta más fuentes.

Paso 7. Añade una política de abstención

Si los resultados son débiles o contradictorios, el asistente debe reconocerlo. En un sistema empresarial, una respuesta prudente suele ser mejor que una respuesta fluida pero falsa.

Paso 8. Registra telemetría

Guarda al menos: pregunta, fecha, usuario o grupo, documentos recuperados, puntuaciones de búsqueda, respuesta y feedback. Evita registrar datos sensibles que no necesites.

14. Evaluación y mejora

Figura 5. La calidad se mejora con un ciclo de pruebas, no con intuición.

Crea un conjunto de preguntas de evaluación antes de ajustar parámetros. Incluye preguntas fáciles, ambiguas, fuera de alcance y preguntas cuya respuesta esté repartida entre varias secciones.

No optimices únicamente la redacción. Primero comprueba que el recuperador encuentre la evidencia correcta; después ajusta el prompt y el modelo.

15. Seguridad, permisos y privacidad

Un RAG empresarial puede convertirse en una puerta de acceso a información sensible si no se diseñan permisos desde el inicio. La búsqueda debe respetar exactamente las autorizaciones del usuario.

• Autentica al usuario antes de consultar.

• Guarda metadatos de acceso por documento o fragmento.

• Filtra resultados según rol, equipo, cliente o proyecto.

• Cifra datos en tránsito y en reposo cuando corresponda.

• No envíes al modelo más información de la necesaria.

• Define retención de logs y tratamiento de datos personales.

• Protege el sistema contra instrucciones maliciosas presentes dentro de documentos.

Un documento recuperado debe tratarse como datos, no como una nueva autoridad capaz de reemplazar las instrucciones del sistema.

16. Costos, escalabilidad y mantenimiento

Los costos aparecen en dos momentos: indexación y consultas. La indexación consume extracción y embeddings; la consulta consume embeddings de la pregunta, búsqueda y generación del modelo.

Para controlar costos, indexa solo contenido útil, evita duplicados, usa caché cuando tenga sentido y mide la cantidad de contexto que realmente mejora las respuestas.

Mantenimiento

• Reindexar documentos modificados.

• Eliminar versiones antiguas.

• Detectar enlaces o fuentes rotas.

• Revisar preguntas sin respuesta.

• Actualizar el conjunto de evaluación.

• Auditar permisos periódicamente.

Reranking

En lugar de enviar directamente al modelo los primeros resultados de la búsqueda vectorial, un reranker vuelve a ordenar candidatos usando un método más preciso. Es útil cuando tienes muchos documentos parecidos.

Hybrid Search

Combina búsqueda semántica con búsqueda léxica. Es especialmente útil para códigos de producto, números de expediente, nombres exactos, siglas y términos técnicos.

Query rewriting

El sistema puede reformular una pregunta ambigua en una consulta más adecuada para buscar. También puede generar varias consultas y combinar resultados.

RAG agéntico

Un agente puede decidir qué fuente consultar, repetir una búsqueda, utilizar filtros adicionales o solicitar una herramienta específica. Esta flexibilidad es potente, pero agrega costo, latencia y complejidad de evaluación. Conviene incorporarla después de tener un RAG básico estable.

RAG multimodal

Cuando la información relevante vive en diagramas, imágenes, capturas o tablas complejas, puede ser necesario combinar extracción visual y textual. El principio sigue siendo el mismo: recuperar evidencia pertinente antes de generar.

19. Checklist de lanzamiento

☐ El caso de uso está claramente delimitado.

☐ Los documentos vigentes están identificados.

☐ Los duplicados y versiones antiguas fueron tratados.

☐ Los chunks conservan suficiente contexto.

☐ Cada chunk tiene fuente y metadatos.

☐ Los permisos se aplican antes de entregar contexto al modelo.

☐ Existe una política clara para no inventar.

☐ Las respuestas muestran fuentes.

☐ Hay un conjunto de preguntas de evaluación.

☐ Se registran fallos y preguntas sin respuesta.

☐ Existe un proceso para reindexar cambios.

☐ Se probaron preguntas fuera de alcance.

☐ Se revisó privacidad y retención de logs.

☐ Se midieron latencia y costo por consulta.

20. Próximos pasos

Una buena estrategia es construir primero un RAG pequeño y medible. Elige un único departamento, reúne documentos confiables y crea entre 20 y 50 preguntas reales. Haz que la recuperación funcione bien antes de agregar agentes, múltiples fuentes o automatizaciones.

Cuando el MVP sea consistente, amplía gradualmente: más documentos, permisos por usuario, búsqueda híbrida, reranking, integración con sistemas internos y automatizaciones. Cada expansión debe acompañarse con nuevas pruebas.

Plan de proyecto en 7 hitos

• Definir el caso de uso y las preguntas objetivo.

• Preparar y clasificar la documentación.

• Construir el pipeline de ingesta.

• Implementar búsqueda semántica con metadatos.

• Construir el prompt y la interfaz de consulta.

• Evaluar con preguntas reales y corregir fallos.

• Publicar el MVP con permisos, fuentes y monitoreo.

Resultado esperado: un asistente que no pretende saberlo todo, sino que sabe dónde buscar, qué evidencia utilizar y cuándo admitir que la base de conocimiento no contiene una respuesta suficiente.