Un agente de IA no puede responder mejor de lo que está escrito. Si la respuesta no está en tu documentación, no se la va a inventar bien. Y si está en el cuarto párrafo de un artículo llamado «Configuración avanzada», probablemente no la encuentre.
Por eso la base de conocimiento marca el límite de lo que puede hacer el agente. Casi todas se escribieron para que una persona las leyera navegando, así que hay trabajo que hacer.
¿Cómo se prepara la documentación para un agente de IA?
Un agente no aprende tu documentación. La parte en fragmentos y recupera los que más se parecen a la pregunta. Por eso conviene escribir un artículo por pregunta, titularlo como lo pregunta el cliente y poner la respuesta en el primer párrafo. Cada párrafo tiene que entenderse solo, las tablas tienen que ser tablas (no capturas), lo que no se puede hacer también se documenta y los artículos se revisan cada vez que cambia la pantalla. Empieza por las veinte preguntas más frecuentes y por las búsquedas sin resultado. Y cuenta con que la mitad de tus conversaciones, las que dependen de la cuenta de cada cliente, no las resuelve ningún artículo.
Qué hace un agente con tu documentación
Entender cómo funciona explica todas las recomendaciones que vienen después.
Un agente no se «entrena» con tu documentación. Hace recuperación: parte los artículos en fragmentos y los convierte en vectores que representan su significado. Cuando llega una pregunta, busca los fragmentos más parecidos y se los pasa al modelo, que redacta la respuesta con ellos delante. Por qué se hace así y no con un entrenamiento lo explicamos en RAG o fine-tuning.
De ahí salen tres consecuencias:
- Al modelo le llegan unos pocos fragmentos, no la página entera. Un fragmento que no se entiende solo le llega sin contexto.
- La búsqueda es por significado. Que el cliente use otras palabras ya no es un problema. Que el artículo no diga lo que promete el título, sí.
- Los cambios se aplican al momento. Si corriges un artículo hoy, la respuesta cambia hoy. No hay que volver a entrenar nada, y por eso un artículo desactualizado se nota enseguida en las respuestas.
Los siete cambios que más ayudan
1. Un artículo por pregunta
Un artículo llamado «Facturación» que explica cómo cambiar de plan, cómo descargar facturas, qué pasa si falla un pago y cómo pedir factura con otro CIF son cuatro artículos en uno.
A una persona que navega le servía. Para la recuperación es un problema: los fragmentos mezclan temas, y el que contesta a «me ha fallado el pago» llega con dos párrafos sobre el CIF que no vienen al caso.
Partirlo en cuatro es de los cambios que menos cuestan y más mejoran las respuestas.
2. El título, con las palabras del cliente
Si vosotros lo llamáis «Política de retención de datos» y el cliente escribe «cuánto tiempo guardáis mi información», el artículo tiene que llamarse así.
Ya importaba antes en cualquier centro de ayuda. Con la búsqueda por significado importa más, porque el título es lo que más pesa al comparar un fragmento con una pregunta.
Si el título no es una pregunta, que al menos sea la respuesta. «Los datos se conservan 90 días tras la baja» funciona mejor que «Retención de datos».
3. La respuesta en el primer párrafo
Sin introducción ni «en este artículo vamos a ver». Primero la respuesta y después el detalle.
El primer fragmento es el que más se recupera, y si tiene la respuesta completa, el modelo la cita bien. Si además el artículo es público, eso mismo es lo que necesita un buscador para destacarlo en los resultados.
4. Párrafos que se entienden solos
«Como decíamos antes», «esta opción» o «en el paso anterior» hacen que un párrafo dependa de lo que tiene encima. Cuando el párrafo llega solo al modelo, nadie sabe a qué se refiere.
Para comprobarlo, coge un párrafo cualquiera, léelo aislado y mira si se entiende. Si no, reescríbelo repitiendo de qué hablas. Leído en la página entera parece repetitivo, pero es lo que hace falta.
5. Tablas que sean tablas
Una tabla en HTML se recupera y se cita bien. Una «tabla» hecha con guiones, tabuladores o una captura de pantalla, no: como mucho llega como texto desordenado, y si es una imagen, no llega.
Importa sobre todo en lo que más se pregunta: límites por plan, precios, compatibilidades y códigos de error. Con las capturas pasa lo mismo. El agente no las lee, así que lo que solo esté en una captura no existe para él.
6. Lo que no se puede hacer
Casi nadie lo documenta, y es lo que más alucinaciones evita. Si le preguntan al agente por una función que no existe y no tiene nada escrito sobre ella, tiende a construir una respuesta que suena bien.
Un artículo que diga «no se pueden exportar los datos en XML; los formatos disponibles son CSV y JSON» lo evita. Los límites conocidos, las integraciones que no existen y lo que está en desarrollo merecen su propio artículo.
7. Una fecha a la vista y revisiones ligadas al producto
Un artículo desactualizado es peor que no tener artículo. El cliente hace lo que dice, y el agente lo cita con la misma seguridad que si fuera cierto.
Los recordatorios en el calendario no funcionan. Lo que funciona es ligar la revisión al cambio: si se toca la pantalla de facturación, se revisan los artículos de facturación antes de desplegar. Es una casilla más en la lista de cada despliegue.
Un artículo, antes y después
Antes. Título: «Gestión de miembros». Primer párrafo: «En esta sección veremos las distintas opciones relacionadas con los miembros del espacio de trabajo, sus roles y permisos.» Tres pantallas más abajo, entre los roles y las notificaciones: «Para invitar a un nuevo miembro, accede a Ajustes y en la pestaña correspondiente introduce su correo.»
Después. Título: «Cómo invitar a alguien de mi equipo». Primer párrafo: «Ve a Ajustes → Equipo, pulsa Invitar e introduce su correo. Recibirá un enlace que caduca en 7 días. Cada plan incluye un número de asientos: Básico 3, Equipo 10, Empresa 25; si están todos ocupados, el botón Invitar aparece desactivado y hay que ampliar el plan o quitar a alguien.»
El segundo responde a la pregunta y dice el límite, y el agente puede citarlo entero en un solo fragmento. El primero, por sí solo, no responde nada.
Lo que ninguna documentación va a resolver
Aquí es donde casi todos los proyectos de documentación decepcionan, y no por culpa de la documentación.
Hay dos tipos de pregunta, y solo uno se responde escribiendo:
- «¿Cómo cambio de plan?» se puede responder por escrito. La respuesta es la misma para todos.
- «¿Por qué me habéis cobrado 340 €?» no. Depende de esa cuenta, de ese mes y de ese plan.
En un SaaS, el segundo tipo suele rondar la mitad de las conversaciones. Ningún artículo va a reducir esa mitad, por bien escrito que esté, porque no sabe quién pregunta.
Si se confunden los dos tipos, se escriben doscientos artículos y el volumen solo baja un 15 %. Para el segundo tipo, el sistema tiene que poder consultar la cuenta del cliente al responder. Es la diferencia entre un chatbot y un agente.
Haz el reparto antes de escribir nada. Coge cien conversaciones y sepáralas en dos montones. El porcentaje del primero es lo máximo que puede resolver la documentación. Saberlo te evita objetivos que no vas a cumplir.
Por dónde empezar si ya tienes documentación
No reescribas todos los artículos. Sigue este orden:
- Las veinte preguntas más frecuentes. Sácalas del historial de conversaciones, no de la intuición. Para cada una, comprueba si hay artículo, si el título coincide con cómo lo pregunta el cliente y si la respuesta está en el primer párrafo.
- Las búsquedas sin resultado de tu centro de ayuda. Es la lista de lo que falta, escrita por tus propios clientes y gratis. Pocos informes son tan útiles, y casi nadie lo mira.
- Lo que el agente responde mal. En cuanto esté funcionando, cada respuesta floja suele apuntar a un artículo concreto, y cada «no lo sé» es un artículo que falta. Ya sabes qué hay que escribir.
- Lo que no se puede hacer: un artículo por cada límite conocido.
- Lo interno: notas del equipo, respuestas guardadas, decisiones de soporte que nunca se escribieron. Un agente puede leer documentación interna y usarla sin publicarla. Si la respuesta correcta solo la sabe una persona, ponla en un documento que el agente pueda leer.
Cómo saber si funciona
Tres señales. El número de artículos no es una de ellas:
- Baja la tasa de reformulación: menos clientes vuelven a hacer la misma pregunta con otras palabras.
- Bajan las búsquedas sin resultado, y las que quedan son sobre cosas nuevas.
- La cobertura por tipo de consulta sube en las preguntas que se responden con documentación y no se mueve en las que dependen de la cuenta. Eso confirma que el reparto era correcto.
Veinte artículos bien titulados sirven más que doscientos que nadie encuentra. Con un agente respondiendo, además, se puede medir. Qué medir está en métricas de soporte cuando responde una IA.
Preguntas frecuentes
¿Tengo que reescribir toda la documentación antes de conectar un agente?
No. Conecta lo que tienes, mira qué responde mal y arregla esos artículos. El agente es la forma más rápida de saber qué falta. Antes sí conviene partir los artículos que mezclan temas y cambiar el título de los veinte más leídos.
¿El agente lee capturas de pantalla y vídeos?
No. Lo que solo esté en una imagen no existe para él. Escribe lo que enseña la captura: el nombre del botón, la ruta, el límite.
¿Puedo darle documentación interna sin publicarla?
Sí. Un agente puede leer notas internas y usarlas para responder sin que el cliente vea el documento. Así sacas de la cabeza de una persona lo que solo sabe ella. Más en ¿necesito un centro de ayuda para usar una base de conocimiento?.
¿En qué idioma escribo si tengo clientes en varios?
En uno, y bien. El agente responde en el idioma del cliente aunque el artículo esté en otro. Más en ¿en qué idiomas responde un agente de IA?.
¿Cuánto tarda en notarse?
Los cambios en la documentación se aplican al momento. Lo que lleva tiempo es medirlo: una o dos semanas mirando la tasa de reformulación para saber si los artículos nuevos funcionan.
Para seguir
- Soporte multilingüe sin contratar por idioma
- Cómo crear una base de conocimiento para IA desde cero, si todavía no tienes nada escrito
- Cómo escribir un centro de ayuda que se lee, para las personas que lo leen
- Responder con tu documentación, cómo lo hace Intake
- Base de conocimiento, la landing
- Un chatbot que responde con la documentación de tu software
