Base de conocimiento de un chatbot de IA: qué contenidos incluir y cómo mantenerlos actualizados

Una clienta pregunta el viernes por la tarde si la empresa abre los sábados. En el equipo hay tres versiones: el sitio web dice “de lunes a viernes”, un cartel en la puerta promete “sábados con cita previa” y la compañera de recepción sabe que en verano los sábados está cerrado de todos modos. Las tres consideran correcta su respuesta. Este escenario es inventado; el patrón no lo es.

Justo aquí interviene un chatbot de IA, y justo aquí se decide si ayuda o perjudica. Un modelo de lenguaje no conoce su empresa. Conoce el lenguaje, relaciones generales y formulaciones plausibles. Si no se le da nada más, responde con lo que suele valer en estos casos. Eso suena convincente y aun así puede ser falso.

Por eso la base de conocimiento no es una función adicional, sino el cimiento. Determina lo que el bot puede decir en nombre de su empresa. Quien la descuida obtiene una máquina educada con conocimiento inventado. Quien la construye con cuidado obtiene un asistente que solo transmite lo que usted ha autorizado expresamente y que indica el lugar donde consta.

Este texto se dirige a empresas que se enfrentan justamente a esta decisión: ¿debe un asistente dar información en nombre de la casa y, en ese caso, sobre qué base? Explica cómo construiríamos una base de conocimiento, qué consideraciones surgen y dónde están los límites. Los ejemplos son ficticios, para que nada parezca un proyecto real que nunca existió.

El problema central se llama alucinación: el modelo genera un texto que encaja con la pregunta sin que esté respaldado por una fuente. El mecanismo es trivial. Un modelo de lenguaje calcula qué palabra es probable que siga. Probable no es lo mismo que verdadero. Para “¿Cuánto cuesta una primera consulta?” hay innumerables respuestas plausibles, y el modelo elige una cuando no dispone de un dato concreto.

A ello se suma el problema del envejecimiento. Incluso una base de conocimiento correcta al principio se queda anticuada. Los precios cambian, un empleado se va, una oferta caduca, la consulta cierra entre Navidad y Año Nuevo. Un bot que reproduce la situación de primavera parece tan seguro en otoño como el primer día. El cliente no puede notar la diferencia, y la empresa a menudo se entera solo cuando alguien se encuentra ante la puerta cerrada.

Un tercer tipo de error se refiere a los compromisos. Cuando alguien pregunta “¿Puedo cancelar con ustedes?”, no se trata de información, sino de una afirmación vinculante. Si el bot responde libremente, puede formular una regla que no existe. Por eso una base de conocimiento necesita no solo contenidos, sino también límites: ¿qué temas responde el bot y en cuáles deriva a una persona?

Antes de construir nada técnicamente, conviene hacer un inventario de las preguntas que los clientes hacen en realidad. Las mejores fuentes son la bandeja de entrada, las notas de las llamadas, las búsquedas en el sitio web y la pregunta de qué responde el equipo por quinta vez en una semana. De estas preguntas se deduce qué contenidos debe sostener la base de conocimiento. No toda la información que existe en la empresa debe entrar.

Clasificaríamos los contenidos con dos criterios: ¿con qué frecuencia se pregunta por ello y cuánto cuesta una respuesta errónea? Los horarios se preguntan a menudo, y un error molesta pero suele causar poco daño. Los rangos de precios se preguntan con frecuencia, y un error genera expectativas que luego hay que corregir. Los detalles contractuales se preguntan con menos frecuencia, pero un error puede tener consecuencias graves. De ahí se deduce lo estricta que debe ser la aprobación.

Una contraprueba es igual de reveladora: ¿qué no debe responder el bot expresamente? Cuestiones jurídicas o de salud individuales, precios vinculantes para casos especiales, información sobre otros clientes. Este límite forma parte del diseño y debe dejarse por escrito antes de introducir la primera línea de contenido. Más adelante decide si el bot deriva correctamente en momentos críticos.

Parte del inventario es también examinar la forma de las fuentes. Una lista de precios como imagen escaneada el bot no puede leerla, una tabla con celdas combinadas se descompone fácilmente al importarla, y una foto del cartel solo sirve como recordatorio. Estas fuentes se convierten antes en texto sencillo, y justo entonces afloran incoherencias que nadie había advertido.

Básicamente hay tres vías para dotar a un modelo del conocimiento de la empresa. La primera es escribirlo todo en la instrucción que se antepone a cada solicitud. Funciona con un puñado de párrafos y fracasa en cuanto el volumen crece: la instrucción se vuelve confusa, cara en cada solicitud, y el modelo no pondera de forma fiable los textos largos. Para una empresa con diez páginas de conocimiento puede bastar; no conviene construir sobre ello más allá de eso.

La segunda vía es reentrenar el modelo. Suena riguroso, pero encaja mal con el conocimiento de una empresa. Lo aprendido es difícil de corregir cuando cambia un precio, y no se puede demostrar de dónde procede una afirmación. El reentrenamiento sirve más para el tono y el formato que para hechos que cambian continuamente. Para los horarios es la palanca equivocada.

La tercera vía se llama recuperación (retrieval), en lenguaje técnico generación aumentada por recuperación (Retrieval-Augmented Generation). Ante cada pregunta, el bot busca primero en sus propios contenidos, pasa al modelo los párrafos encontrados y le deja responder solo a partir de ellos. Si cambia un precio, usted modifica un documento y la siguiente respuesta es correcta. Además, cada afirmación se puede rastrear hasta un punto concreto. Es nuestra elección porque une actualidad, trazabilidad y control.

La recuperación no es una panacea. Si la búsqueda encuentra el pasaje equivocado, el modelo responde con fiabilidad a partir del pasaje equivocado. La calidad reside, por tanto, en dos mitades: en la búsqueda y en la instrucción de responder solo a partir de lo encontrado. Ambas mitades deben probarse, y no es una tarea puntual.

Una base de conocimiento no es un cajón de sastre. Quien carga sin más todos los PDF, folletos y textos del sitio web obtiene fuentes contradictorias y un bot que cita unas veces la lista de precios antigua y otras la nueva. Es mejor un fondo pequeño y construido a conciencia: una página por tema, breve, inequívoca, con fecha y una persona responsable. Mejor cuarenta entradas mantenidas que cuatrocientas poco claras.

El estilo de redacción es más importante de lo que se piensa. La búsqueda trabaja con similitud de significado, por lo que ayudan las entradas formuladas como preguntan los clientes. Una entrada titulada “Cancelación de citas” con la primera frase “Las citas pueden cancelarse sin coste hasta 24 horas antes” se encuentra mejor que un párrafo de las condiciones generales que dice lo mismo en lenguaje jurídico. Los extractos de las condiciones se conservan como prueba; la versión comprensible va a su lado.

Cada entrada lleva metadatos: tema, vigencia, fecha, persona de contacto, visibilidad. La indicación “válido hasta” permite ocultar automáticamente lo estacional. La visibilidad separa lo que el bot puede decir públicamente de las indicaciones internas para el equipo. Y el precio se indica como rango con condiciones, no como una cifra sin contexto, para que “desde” no se convierta por error en “exactamente”.

Por último, en la base de conocimiento debe constar lo que el bot no sabe. Una entrada “Ofertas de precio individuales” con el contenido “El bot no ofrece información al respecto, sino que remite al equipo” vale más que el silencio. Hace que el límite sea localizable y garantiza que ante preguntas afines se elija la reacción correcta.

Las contradicciones las resolvemos antes de introducir los contenidos, no después. Si el sitio web indica horarios distintos de los de la lista de precios, una persona decide qué versión vale y se corrige la otra. Un bot que conoce dos verdades reproduce al azar una u otra. Esta conciliación es incómoda, pero a menudo descubre errores que llevan meses sin ser advertidos también en el sitio web.

Técnicamente, cada solicitud pasa por cuatro pasos. Primero se preparan los contenidos: los textos se dividen en secciones de pocas frases, y cada sección se traduce a una serie de números que representa su significado. Esta traducción, llamada embedding, permite medir la similitud. Dos frases con palabras distintas pero el mismo sentido quedan muy próximas, por ejemplo “¿Cuándo abren?” y “Horario”.

Cuando llega una pregunta, se traduce del mismo modo, y la búsqueda devuelve las secciones más similares. En la práctica combinamos la búsqueda por significado con una búsqueda clásica por palabras clave, porque esta es más fiable con nombres propios, números de artículo y términos técnicos. Los mejores resultados se ordenan, y solo se pasan los que superan una similitud mínima. Este umbral es el regulador más importante del comportamiento ante la incertidumbre.

En el tercer paso, el modelo de lenguaje recibe la pregunta, las secciones encontradas y una instrucción: responde solo a partir de estas secciones, cita la fuente y, si las secciones no responden a la pregunta, dilo. En el cuarto paso, un control comprueba si la respuesta está respaldada por las secciones y bloquea afirmaciones con precios o compromisos que no consten en ellas. Esta etapa de control cuesta algo de tiempo y ahorra muchos disgustos.

La cualidad más difícil de un chatbot no es el conocimiento, sino la contención. Las personas perdonan mucho antes una respuesta honesta de que el bot no sabe algo que una falsa que luego tienen que sufrir. Sin embargo, los modelos de lenguaje tienden a parecer serviciales. Este comportamiento hay que reorientarlo de forma deliberada: mediante la instrucción, mediante el umbral de la búsqueda y mediante ejemplos de buen desconocimiento.

Una respuesta de desconocimiento útil consta de tres partes: dice con claridad que el bot no tiene nada fiable al respecto. Ofrece el siguiente paso, por ejemplo la consulta al equipo, una llamada o la página de contacto. Y se lleva la pregunta, de modo que el equipo sepa de qué se trataba. Esta tercera parte convierte la laguna en una indicación para el mantenimiento: las preguntas sin resultado son la lista más honesta de lo que falta en la base de conocimiento.

Son difíciles los casos límite en los que la búsqueda encuentra algo que solo encaja a medias. La pregunta es “¿Hay descuento para asociaciones?”, el pasaje encontrado habla de descuento por volumen. Aquí el bot no debe extrapolar. Lo resolvemos haciendo que la instrucción distinga entre “respondida”, “parcialmente respondida” y “no respondida” y que, en el nivel intermedio, nombre lo encontrado sin cerrar la laguna.

Dentro del desconocimiento también cabe saber cuál es el propio papel. Si alguien pregunta por un compromiso, un diagnóstico o una cuestión jurídica, el bot no debe adivinar, sino indicar a las personas competentes. No es una debilidad, sino la razón por la que las empresas pueden dar a un asistente así una ventana en su sitio web.

Una buena base de conocimiento hace que el bot sea trazable, no infalible. Lo realista es esperar que la gran mayoría de las preguntas cotidianas se responda correctamente a partir de los contenidos autorizados, que las respuestas citen su fuente y que el bot derive cuando haya lagunas. Una cifra al respecto solo puede darse con seriedad tras una fase de pruebas con preguntas reales, no antes ni de forma general.

El beneficio se puede medir con indicadores próximos a la causa. Entre ellos están el porcentaje de preguntas respondidas con fuente, el porcentaje de derivaciones por falta de resultados, los muestreos en los que una persona contrasta las respuestas con la fuente y las valoraciones de los usuarios mediante el pulgar. Solo después vienen indicadores como menos consultas repetidas en el buzón o tiempos de gestión más cortos, que dependen de muchos otros factores.

Un ejemplo de interpretación: si el número de derivaciones por falta de resultados aumenta en las primeras semanas, no es un retroceso; el bot muestra dónde faltan contenidos. Si después baja sin que los muestreos empeoren, la cobertura crece. Si baja mientras los muestreos empeoran, el bot probablemente responde con demasiada liberalidad y el umbral debe endurecerse.

Igual de claro es lo que no se puede prometer: ninguna base de conocimiento garantiza respuestas sin errores, sobre todo ante preguntas ambiguas o fuentes contradictorias. Tampoco se puede cuantificar de antemano un alivio determinado para el equipo. Depende de cuántas consultas recibe realmente su empresa, de lo estandarizadas que sean y de lo constante que sea el mantenimiento.

El motivo más frecuente por el que los chatbots decepcionan al cabo de unos meses no es la técnica, sino la falta de responsabilidad. La puesta en marcha fue un proyecto; el mantenimiento no es de nadie. Por eso definimos desde el principio quién es responsable de cada área: los precios, la dirección; los horarios, la recepción; las descripciones de los servicios, el profesional. Cada entrada tiene un nombre y una fecha de revisión.

El ritmo consta de tres niveles. Por eventos, se cambia de inmediato cuando algo cambia: nueva lista de precios, cierre por vacaciones, un festivo. De forma periódica, por ejemplo mensual, alguien revisa la lista de preguntas sin respuesta y de valoraciones negativas y completa las entradas. Dos veces al año el equipo repasa toda la base de conocimiento y elimina lo que ya no es válido. Las fechas de caducidad ayudan, porque las entradas con vigencia vencida dejan de intervenir automáticamente en las respuestas.

Es importante que haya una vía sencilla para los cambios. Si adaptar una entrada requiere consultarlo con la agencia, se aplaza. Por eso construimos una interfaz en la que las personas autorizadas editan y aprueban entradas, y conservamos el historial. En cada cambio se ejecuta un pequeño conjunto de preguntas de prueba, para que una nueva formulación no desplace sin darse cuenta las respuestas sobre otros temas.

La base de conocimiento se convierte así en un documento vivo que sirve para más que el bot. Muchas empresas descubren que por primera vez dejan por escrito qué se aplica en caso de cancelación, acceso o pago. Esto ayuda también a los nuevos empleados y al sitio web. Este efecto secundario es real, pero no sustituye el esfuerzo de mantenimiento, que permanece.

Un chatbot de IA compensa a las empresas que responden a menudo preguntas parecidas y cuyas respuestas pueden recogerse en afirmaciones claras. Su calidad depende de la base de conocimiento: de pocas entradas bien cuidadas, de una búsqueda que encuentre de forma fiable, de la fuente bajo cada respuesta y de un bot que reconozca sus lagunas. El modelo que hay detrás es intercambiable; el cuidado previo, no.

El siguiente paso es pequeño y todavía no necesita un bot. Anote las veinte preguntas que su equipo ha respondido con más frecuencia en las últimas semanas y compruebe si las respuestas están en un único lugar actualizado. Si ese lugar no existe, esa es la verdadera tarea, y merece la pena con independencia del chatbot. Con gusto revisamos juntos cuánto de ello ya existe.

También forma parte de la honestidad decir esto: en empresas muy pequeñas con pocas preguntas estables, basta una página de preguntas frecuentes bien hecha. El chatbot saca partido cuando las preguntas se formulan de formas muy distintas, cuando se esperan respuestas las 24 horas y cuando alguien asume el mantenimiento. Si falta lo último, conviene aplazar el lanzamiento.

Quien empiece debería hacerlo en pequeño: con los cinco a diez temas más importantes, una fase de pruebas acompañada y la disposición a mejorar a partir de preguntas reales. La base de conocimiento crece entonces con la necesidad, en lugar de aparentar de antemano que está completa. Es más lento que una gran importación, pero las respuestas siguen siendo verificables y el equipo mantiene el control de lo que el bot dice en nombre de la empresa.