Un chatbot con los documentos de tu empresa no “aprende” esos documentos. En cada pregunta, busca los fragmentos más relevantes y se los pasa a un modelo de lenguaje (LLM) para que redacte la respuesta a partir de ellos. Esta técnica se llama RAG (generación aumentada por recuperación). Su calidad depende sobre todo de los documentos y de la búsqueda, no del modelo.

Si buscas cómo funciona, encontrarás sobre todo páginas de herramientas que venden “sube tus PDF y listo”. Para una demo funciona. Para que tu equipo o tus clientes confíen en las respuestas, hace falta más. Este artículo explica las piezas, qué documentos sirven, cómo se respetan los permisos y cómo se mide si el chatbot responde bien.

Por qué no basta con preguntarle a un LLM

Un LLM generalista no conoce tus procedimientos, tus tarifas ni tus contratos. Si le preguntas, puede inventar una respuesta plausible. Hay tres formas de darle tu información:

Método Cómo funciona Cuándo encaja
Pegar el documento en la conversación Se envía el texto completo en cada pregunta Un documento corto y una consulta puntual
RAG Se buscan los fragmentos relevantes y solo esos se envían al modelo Muchos documentos que cambian y preguntas variadas
Ajuste fino (fine-tuning) Se reentrena el modelo con ejemplos Enseñar un estilo o un formato, no hechos que cambian

El ajuste fino no es la forma adecuada de enseñar hechos a un modelo: cada cambio en un documento exigiría reentrenar, y no puedes saber de qué fuente sale una respuesta. RAG permite actualizar un documento y que el chatbot lo use en la siguiente pregunta, y permite citar la fuente.

Cómo funciona un sistema RAG, paso a paso

Un sistema RAG tiene dos fases: preparar los documentos y responder a las preguntas.

Fase 1: preparar los documentos (ingesta)

  1. Extraer el texto de cada formato: PDF, Word, páginas de la intranet, tickets, hojas de cálculo. Los PDF escaneados necesitan OCR.
  2. Limpiar: quitar cabeceras, pies de página, índices y texto repetido que confunden la búsqueda.
  3. Dividir en fragmentos (chunks). Un fragmento debe tener sentido por sí solo: una sección, un apartado, una pregunta con su respuesta. Cortar a mitad de una tabla o de una lista es una causa frecuente de malas respuestas.
  4. Añadir metadatos a cada fragmento: documento de origen, fecha, versión, departamento y quién puede verlo.
  5. Calcular el embedding de cada fragmento: un vector numérico que representa su significado.
  6. Guardar fragmentos, metadatos y vectores en una base de datos con búsqueda vectorial.

Fase 2: responder (consulta)

  1. El usuario pregunta.
  2. El sistema busca los fragmentos más relevantes, filtrando por los permisos del usuario.
  3. Opcionalmente, reordena los resultados con un modelo que mide mejor la relevancia.
  4. Envía al LLM la pregunta, los fragmentos y unas instrucciones: responde solo con esta información, cita la fuente y di “no lo sé” si no está.
  5. Muestra la respuesta con enlaces a los documentos de origen.

Las piezas técnicas y qué decidir en cada una

Pieza Opciones habituales Qué tener en cuenta
Extracción de texto Librerías de PDF y Office, OCR para escaneados Las tablas y los documentos escaneados son los que más fallan
Fragmentación Por tamaño fijo, por secciones del documento, por pregunta y respuesta Respetar la estructura del documento da mejores resultados que cortar por número de palabras
Modelo de embeddings Por API o alojado por ti Debe funcionar bien en español; si lo cambias, hay que recalcular todos los vectores
Base de datos vectorial Una extensión de tu base de datos actual (por ejemplo, pgvector en PostgreSQL) o un servicio dedicado Para volúmenes moderados, usar tu base de datos actual simplifica la operación
Búsqueda Semántica, por palabras clave o híbrida La búsqueda semántica falla con códigos, referencias y nombres propios; la híbrida combina las dos
Modelo de lenguaje Por API o alojado por ti El coste, la privacidad y la calidad en español deciden; lo explicamos en cómo integrar IA en tu software

Un detalle que suele olvidarse: la búsqueda por palabras clave sigue siendo necesaria. Si un usuario pregunta por la referencia “PR-0042” o por el nombre de un producto, la búsqueda semántica puede devolver fragmentos parecidos pero equivocados. La búsqueda híbrida resuelve buena parte de esos casos.

Qué documentos sirven y cuáles no

El chatbot responde tan bien como los documentos que tiene. Antes de construir nada, revisa tu documentación:

Problema en los documentos Efecto en el chatbot Qué hacer
Versiones antiguas junto a las vigentes Responde con información caducada Incluir solo la versión vigente o marcar la fecha en los metadatos
Documentos contradictorios Respuestas distintas a la misma pregunta Decidir cuál manda y retirar el otro
Información solo en la cabeza de alguien “No lo sé” o, peor, una respuesta inventada Escribirla: el chatbot no puede citar lo que no existe
Tablas complejas y documentos escaneados Datos mal extraídos Revisar la extracción o convertirlos a un formato limpio
Documentos enormes sin estructura Fragmentos sin sentido Añadir títulos y secciones antes de indexarlos

Muchas empresas descubren en este paso que el proyecto de chatbot es, en realidad, un proyecto de ordenar la documentación. Ese trabajo tiene valor aunque el chatbot no existiera.

Permisos: el chatbot no debe saber más que el usuario

Si indexas toda la documentación de la empresa en un solo sitio, el chatbot puede acabar respondiendo a un empleado con datos de nóminas o de un contrato confidencial. Es un riesgo real y fácil de pasar por alto.

Cómo evitarlo:

  • Guarda en cada fragmento quién puede verlo, copiado de los permisos del sistema de origen.
  • Filtra en la búsqueda, antes de enviar nada al modelo. Pedir al modelo que “no revele” información no es una medida de seguridad.
  • Sincroniza los permisos: si alguien pierde acceso a una carpeta, también lo pierde en el chatbot.
  • Para un chatbot público en tu web, indexa solo documentación pública.

Ten en cuenta también la inyección de instrucciones: un documento puede contener texto que intente cambiar el comportamiento del modelo. Si el chatbot solo responde y no ejecuta acciones, el riesgo es menor, pero conviene saber de dónde viene cada documento indexado.

Cómo medir si el chatbot responde bien

“Parece que funciona” no es una medida. Antes de abrirlo a los usuarios, prepara una evaluación:

  1. Reúne preguntas reales, entre cincuenta y unas pocas centenas. Sácalas de correos, tickets o de las dudas que el equipo repite.
  2. Anota la respuesta correcta y el documento donde está.
  3. Mide la búsqueda por separado: ¿el fragmento correcto aparece entre los primeros resultados? Si la búsqueda falla, ningún modelo arregla la respuesta.
  4. Mide la respuesta: ¿es correcta, cita la fuente adecuada y dice “no lo sé” cuando no hay información?
  5. Repite la evaluación cada vez que cambies la fragmentación, el modelo de embeddings, el LLM o las instrucciones.

En producción, añade un botón de “útil / no útil” y revisa las respuestas marcadas como no útiles. Son la mejor fuente de mejoras.

Errores comunes

Error Consecuencia Cómo evitarlo
Indexar todo sin revisar Respuestas con información caducada o contradictoria Revisar y limpiar la documentación antes
No mostrar las fuentes El usuario no puede comprobar y deja de confiar Citar siempre el documento y la sección
Ignorar los permisos Fuga de información interna Filtrar por permisos en la búsqueda
Solo búsqueda semántica Falla con referencias, códigos y nombres Búsqueda híbrida
No permitir “no lo sé” El modelo inventa respuestas plausibles Instrucción explícita y evaluación de ese caso
No actualizar el índice El chatbot responde con documentos antiguos Reindexado automático cuando cambia un documento
Lanzar sin evaluación No sabes si una mejora ayuda o empeora Conjunto de preguntas de prueba desde el principio

Chatbot interno o chatbot para clientes

La técnica es la misma, pero las decisiones cambian:

Aspecto Chatbot interno Chatbot para clientes
Documentos Procedimientos, manuales, contratos, tickets Solo documentación pública: ayuda, condiciones, catálogo
Permisos Por usuario y por departamento Iguales para todos los visitantes
Tolerancia al error Media: el empleado puede comprobar la fuente Baja: una respuesta errónea llega al cliente
Cuando no sabe Remite al documento o a un compañero Ofrece contacto con una persona

Empezar por el interno suele ser más seguro: los usuarios conocen el tema, detectan los errores y te ayudan a construir la evaluación.

Cuánto cuesta y de qué depende

No damos una cifra sin ver tus documentos, porque el trabajo cambia mucho de un caso a otro. El coste depende de:

  • Volumen y estado de los documentos: cuánto hay que limpiar, convertir u ordenar.
  • Fuentes: una carpeta de PDF es más sencilla que sincronizar con la intranet, el gestor documental y la herramienta de tickets.
  • Permisos: replicar permisos de varios sistemas es trabajo de integración.
  • Uso: el coste del LLM y de los embeddings es por uso y crece con el número de preguntas.
  • Dónde se aloja: API de terceros o modelos en tu infraestructura.

Lo recomendable es empezar con un ámbito pequeño (un departamento, un tipo de documento) y una evaluación. Con datos reales de uso, decides si ampliar.

Preguntas frecuentes

¿El chatbot puede contestar preguntas sobre datos de mi base de datos, no solo documentos?

Sí, pero no con RAG sobre documentos. Para datos estructurados (pedidos, stock, clientes) es mejor que el modelo pida a tu sistema una consulta concreta mediante funciones que tú defines. Muchos sistemas combinan las dos cosas.

¿Mis documentos se usan para entrenar el modelo?

En RAG, tus documentos se envían como contexto en cada pregunta, no se usan para reentrenar. Si usas un modelo por API, revisa en las condiciones del proveedor si usa esos datos para entrenar y cuánto tiempo los guarda.

¿Sirve una herramienta comercial en vez de un desarrollo a medida?

Para documentos públicos o un piloto rápido, a menudo sí. El desarrollo a medida compensa cuando necesitas respetar permisos de varios sistemas, integrar el chatbot en tu aplicación o controlar dónde se procesan los datos.

Conclusión

Un chatbot con los documentos de tu empresa funciona bien cuando la documentación está ordenada, la búsqueda encuentra el fragmento correcto, los permisos se respetan y una evaluación lo confirma. El modelo de lenguaje es la parte más visible y la menos decisiva.

¿Quieres que tu equipo o tus clientes encuentren respuestas en tu documentación? Cuéntanos qué documentos tienes y qué preguntas quieres resolver. Más sobre nuestro servicio de inteligencia artificial.