El problema más común con los chatbots no es que “no tengan información”, sino que su base de conocimiento está mal construida. El bot suena seguro, pero responde mal cuando la pregunta se sale un poco del guion.
Este artículo explica cómo estructurar una base de conocimiento para un agente con RAG (retrieval-augmented generation) para que recupere bien la información, responda con precisión y sepa cuándo escalar a un humano.
---
Cómo tu agente de IA realmente usa tu base de conocimiento
Los agentes modernos no “leen” documentos como una persona. Usan RAG:
- Recuperan fragmentos de texto estadísticamente relevantes a la consulta.
- Generan una respuesta basándose casi exclusivamente en esos fragmentos.
Esto tiene dos implicaciones clave:
- Cómo fragmentas el contenido importa. Un PDF de 3.000 palabras sobre devoluciones puede devolver solo la introducción cuando el cliente pregunta por devoluciones internacionales.
- La calidad de la respuesta depende de lo recuperado. Si el fragmento es vago, contradictorio u obsoleto, la respuesta también lo será.
Tu trabajo no es solo “subir la información correcta”, sino estructurarla para que se recupere bien.
---
Qué debe incluir una buena base de conocimiento para chatbot
1. FAQs escritas como respuestas directas
- Escribe cada entrada como si fuera una respuesta completa y directa a una sola pregunta.
- Evita intros largas tipo “Creemos en la satisfacción del cliente…”.
- Ejemplo malo: “Creemos en la satisfacción del cliente, por eso nuestra política de devoluciones…”.
- Ejemplo bueno: “Nuestra política de devoluciones es: puedes devolver cualquier producto dentro de 30 días…”.
Mantén una pregunta por entrada y empieza siempre con el dato clave.
2. Detalles específicos de producto y servicio
Incluye información granular y verificable:
- Niveles de precios y qué incluye cada plan.
- Nombres de funciones y limitaciones.
- Restricciones por tipo de cuenta.
Ejemplo: en lugar de “soportamos múltiples canales”, especifica:
- “El plan Business incluye: Email, Chat web, WhatsApp”.
- “El plan Starter incluye: Email, Chat web (no incluye WhatsApp)”.
3. Detalles operacionales
Documenta como hechos concretos:
- Horarios de atención.
- Tiempos de respuesta esperados.
- Regiones donde el servicio está disponible.
- Rutas de escalación (a qué equipo va cada tipo de caso).
Evita enterrarlos en manuales de onboarding largos. Cada hecho operativo clave debe ser una entrada clara y recuperable.
4. Casos especiales y excepciones
Incluye las excepciones que tu equipo maneja a menudo:
- Tipos de cuenta con reglas distintas.
- Precios promocionales vigentes.
- Funciones antiguas que algunos clientes aún usan.
Sé explícito sobre qué puede y qué no puede hacer el bot con esas excepciones. Por ejemplo:
“Los descuentos por volumen para clientes Enterprise se evalúan caso por caso. El bot no puede ofrecer ni confirmar descuentos; debe escalar al equipo de ventas.”
5. Condiciones de escalación
Define claramente:
- Temas que el bot no debe resolver (p. ej., disputas de facturación sensibles, cancelaciones definitivas de cuenta, temas legales).
- Palabras clave o patrones que deben disparar escalación obligatoria.
En plataformas como Reach, esto se conecta directamente con la configuración de transferencia a agente humano.
---
Cómo estructurar el contenido para que la recuperación funcione
Un tema por entrada
No mezcles políticas o procesos distintos en un mismo artículo:
- No combines reembolsos y cambios.
- No mezcles precios actuales con históricos.
Si lo haces, el motor de recuperación traerá ambos temas a la vez y el modelo puede mezclarlos en una sola respuesta confusa.
Empieza con la respuesta, luego el contexto
Estructura cada entrada así:
- Primera o primeras dos frases: el hecho concreto.
- Después: matices, contexto, ejemplos.
Ejemplo:
“Los pedidos internacionales no son elegibles para devoluciones gratuitas. Se aplican tarifas estándar de devolución que se muestran al pagar. A continuación explicamos cómo se calculan estas tarifas…”
Usa el lenguaje real de tus clientes
- Revisa tickets de soporte, chats y correos.
- Identifica cómo formulan las preguntas: “cancelar mi suscripción” vs “terminar mi cuenta”.
- Usa esas mismas frases en títulos y primeros párrafos de tus entradas.
Esto mejora drásticamente la recuperación, porque el modelo encuentra coincidencias más directas entre la consulta y el contenido.
Nota específica para WhatsApp (Reach)
En WhatsApp, las respuestas largas son un problema:
- Los usuarios leen en móvil, en ráfagas cortas.
- Respuestas de 400+ palabras se cortan o se ignoran.
Por eso:
- Mantén las entradas de la base de conocimiento más cortas y enfocadas.
- Divide procesos largos en pasos breves (una entrada por paso clave si es necesario).
- Prioriza bullets y frases cortas sobre párrafos densos.
La longitud de la entrada tiende a determinar la longitud de la respuesta generada.
---
Qué dejar fuera de la base de conocimiento
1. Contenido de marketing
Evita subir:
- Páginas de producto orientadas a venta.
- Copys tipo “plataforma líder en la industria”.
El modelo repetirá ese lenguaje cuando el cliente haga preguntas prácticas, generando respuestas promocionales e imprecisas.
2. Versiones contradictorias de la misma información
No subas:
- Una tabla de precios antigua y otra nueva.
- Dos políticas de devoluciones distintas.
El modelo no sabe cuál es la correcta. Mezclará ambas en una respuesta que suena segura pero es falsa. Define una única fuente de verdad y elimina el resto.
3. Contenido que requiere juicio humano
No conviertas en “política” lo que en realidad son excepciones discrecionales:
- Reembolsos especiales para clientes de largo plazo.
- Descuentos ad hoc por mala experiencia.
Si documentas “a veces hacemos excepciones para clientes leales”, el bot tenderá a prometer esa excepción a cualquiera que se autodefina leal. Mantén esos casos como procesos humanos, no como reglas del bot.
4. Contenido obsoleto
El modelo no tiene noción de tiempo. Si subes:
- Precios antiguos.
- Nombres de funciones en desuso.
- Procesos de soporte que ya cambiaron.
Los usará con la misma confianza que la información actual. Revisa y elimina contenido obsoleto de forma sistemática.
---
El espacio negativo: lo que tu bot explícitamente no puede responder
No basta con decir qué sí puede hacer el bot; también debes definir qué está fuera de alcance.
Temas de escalación obligatoria
Configura como “siempre escalar” temas como:
- Disputas de facturación sensibles.
- Eliminaciones definitivas de cuenta.
- Preguntas legales o de cumplimiento.
- Cualquier cosa que requiera contexto de cuenta al que el bot no tenga acceso.
En lugar de dejar que el modelo “decida” si responde o no, marca estos temas como disparadores de escalación.
Define el tono del “no sé”
Diseña una respuesta de fallback clara, por ejemplo:
“No tengo información suficiente para responder esto con precisión. Te voy a pasar con una persona de nuestro equipo para que te ayude mejor.”
Esto es mucho mejor que una respuesta inventada pero convincente.
Entradas explícitas de “fuera de alcance”
Un hallazgo contraintuitivo: agregar entradas cortas que digan explícitamente con qué no puede ayudar el bot reduce más las respuestas incorrectas que agregar más contenido en el alcance.
Ejemplos de entradas útiles:
- “El bot no puede ofrecer ni confirmar descuentos personalizados. Para eso, siempre escalará al equipo comercial.”
- “El bot no puede procesar solicitudes de eliminación definitiva de cuenta. Estas solicitudes se manejan solo por el equipo de soporte.”
---
El ciclo de mantenimiento continuo
Una base de conocimiento se deteriora con el tiempo:
- Cambian precios y planes.
- Se actualizan políticas.
- Se lanzan nuevos productos.
El bot no se entera solo. Necesita un ciclo de mantenimiento.
Qué señales vigilar
Revisa regularmente:
- Conversaciones escaladas que no deberían haberse escalado.
- Si los agentes responden muchas veces “¿cuáles son sus horarios de atención?”, falta una entrada o no se está recuperando bien.
- Casos donde el humano corrige al bot.
- Si corrigen precios o políticas, probablemente cambió algo que no se actualizó en la base de conocimiento.
En Reach, los logs de conversación y los datos de escalación te permiten ver esto directamente.
Ritmo recomendado
- Primer mes tras el despliegue: revisa escalaciones semanalmente.
- Después: establece una cadencia mensual o alineada con tus ciclos de cambio de producto/políticas.
La mayoría de los problemas serán:
- Entradas incorrectas.
- Entradas que faltan.
- Entradas que se contradicen.
Son correcciones concretas, no problemas filosóficos del modelo.
---
Resumen accionable
- Diseña entradas atómicas: una pregunta/tema por artículo, empezando siempre con la respuesta.
- Documenta lo operativo y lo específico: planes, límites, horarios, excepciones frecuentes.
- Usa el lenguaje del cliente: copia sus frases reales en títulos y primeros párrafos.
- Define el espacio negativo: temas fuera de alcance y reglas claras de escalación.
- Elimina ruido: marketing, duplicados, contradicciones y contenido obsoleto.
- Mantén un ciclo de revisión: usa las escalaciones y correcciones humanas como señal para mejorar la base.
El objetivo no es lanzar un bot perfecto, sino un sistema donde cada semana, con datos reales de conversaciones, tu base de conocimiento y tu agente mejoran de forma medible.