Hay una frase que conviene tener presente antes de montar nada: un agente de IA no puede responder mejor de lo que está escrito. Si la respuesta no existe en tu documentación, no la va a inventar bien; y si existe pero está enterrada en el párrafo cuarto de un artículo que se llama «Configuración avanzada», es bastante probable que no la encuentre.
Eso convierte a la base de conocimiento en el techo del sistema. Y como la mayoría de las bases de conocimiento se escribieron para que las leyera una persona navegando, hay trabajo que hacer.
Qué hace realmente un agente con tu documentación
Conviene entender el mecanismo, porque explica todas las recomendaciones que vienen después.
Un agente no se «entrena» con tu documentación. Lo que hace es recuperación: parte los artículos en fragmentos, los convierte en vectores que representan su significado, y cuando llega una pregunta busca los fragmentos más cercanos a esa pregunta y se los pasa al modelo para que redacte la respuesta con ellos delante.
De ahí salen tres consecuencias prácticas:
- El fragmento es la unidad, no el artículo. Lo que llega al modelo son unos pocos trozos, no la página entera. Un trozo que no se entiende por sí solo llega descontextualizado.
- La búsqueda es por significado, no por palabras. Que el cliente use otras palabras deja de ser un problema. Que el artículo no diga lo que promete, sí.
- Se actualiza al instante. Corriges un artículo hoy y la respuesta cambia hoy. No hay reentrenamiento, y por eso un artículo desactualizado es un error que se propaga inmediatamente.
Los siete cambios que más rinden
1. Un artículo, una pregunta
El artículo que cubre «Facturación» y dentro explica cómo cambiar de plan, cómo descargar facturas, qué pasa si falla un pago y cómo pedir factura con otro CIF es cuatro artículos escritos como uno.
Para una persona navegando, funcionaba. Para la recuperación, es un desastre: los fragmentos de un artículo así mezclan temas, y el que contesta a «me ha fallado el pago» viene acompañado de dos párrafos sobre CIF que no vienen a cuento.
Partirlo en cuatro es la intervención con mejor relación entre esfuerzo y resultado que existe.
2. Titular con la pregunta 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 lo segundo.
Esto ya importaba antes —era el error más caro de cualquier centro de ayuda— y con recuperación semántica importa más todavía, porque el título es lo que más pesa cuando se compara un fragmento con una pregunta.
Regla práctica: 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
Nada de contexto introductorio, nada de «en este artículo vamos a ver». La respuesta primero y el detalle después.
El motivo es doble: el primer fragmento es el que más se recupera, y si contiene la respuesta completa, el modelo la cita bien. Y si además el artículo es público, es lo mismo que hace falta para que un buscador lo ponga en un fragmento destacado.
4. Fragmentos que se entienden solos
Escribir «como decíamos antes», «esta opción» o «en el paso anterior» construye párrafos que dependen de lo que hay encima. Cuando ese párrafo viaja solo, el pronombre se queda sin referente.
La prueba es sencilla: coge un párrafo cualquiera de tu documentación, léelo aislado y mira si se entiende. Si no, reescríbelo repitiendo el sujeto. Suena redundante leyendo la página entera y es exactamente lo que hace falta.
5. Tablas de verdad
Una tabla en HTML se recupera bien y se cita bien. Una «tabla» hecha con guiones, tabulaciones o una captura de pantalla, no: en el mejor de los casos llega como texto plano desordenado, y en el peor no llega.
Es especialmente relevante en lo que más se pregunta: límites por plan, precios, compatibilidades, códigos de error.
6. Decir lo que no se puede hacer
Es la parte que nadie documenta y la que más alucinaciones evita. Un agente al que se le pregunta por una función que no existe, y que no tiene nada escrito al respecto, tiende a construir una respuesta plausible.
Un artículo que diga «no se pueden exportar los datos en formato XML; los formatos disponibles son CSV y JSON» cierra esa puerta. Los límites conocidos, las integraciones que no existen y lo que está en desarrollo merecen su propio artículo.
7. Una fecha visible y una revisión atada al producto
Un artículo desactualizado es peor que ninguno, porque el cliente actúa según lo que dice y el agente lo cita con la misma seguridad que si fuera cierto.
Los recordatorios de calendario no funcionan. Lo que funciona es atar 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 despliegue.
Lo que ninguna documentación va a resolver
Aquí es donde la mayoría de los proyectos de documentación decepcionan, y no es culpa de la documentación.
Hay dos tipos de pregunta y solo uno se responde escribiendo:
- «¿Cómo cambio de plan?» → tiene respuesta escribible. Es la misma para todo el mundo.
- «¿Por qué me habéis cobrado 340 €?» → no la tiene. Depende de esa cuenta, ese mes y ese plan.
En un SaaS, el segundo grupo suele ser cerca de la mitad del volumen. Ningún artículo, por bien escrito que esté, va a bajar esa mitad, porque el artículo no sabe quién pregunta.
Confundir los dos grupos es lo que lleva a escribir doscientos artículos y ver que el volumen baja un 15 %. Para el segundo grupo hace falta otra cosa: que el sistema pueda consultar el estado de la cuenta en el momento de responder.
Merece la pena hacer el reparto antes de escribir nada. Cien conversaciones reales, dos montones. Ese porcentaje es el techo de lo que la documentación puede resolver, y saberlo evita fijarse objetivos que no se van a cumplir.
Por dónde empezar si ya tienes documentación
No reescribiendo el catálogo entero. En este orden:
Primero, las veinte preguntas más frecuentes. Sácalas del histórico de conversaciones, no de la intuición. Para cada una, comprueba si existe artículo, si el título coincide con cómo la formula el cliente, y si la respuesta está en el primer párrafo.
Segundo, las búsquedas sin resultado de tu centro de ayuda. Es la lista de lo que falta, escrita por los propios clientes y gratis. Es el informe más accionable que existe y el que menos se mira.
Tercero, lo que el agente responde mal. En cuanto esté funcionando, las respuestas flojas apuntan a un artículo concreto casi siempre. Cada una es una tarea de documentación con el diagnóstico ya hecho.
Cuarto, lo que no se puede hacer. Un artículo por límite conocido.
Cómo saber si va bien
Tres señales, y ninguna es el número de artículos:
- La tasa de reformulación baja. Menos gente vuelve a escribir la misma pregunta con otras palabras.
- Las búsquedas sin resultado bajan y las que quedan son sobre cosas nuevas, no sobre lo de siempre.
- La [cobertura por tipo de consulta](/es/glosario/tasa-de-desvio) sube en el grupo documental y se queda quieta en el grupo que depende de la cuenta. Eso último no es un fallo: es la confirmación de que el reparto era correcto.
Un catálogo de doscientos artículos que nadie encuentra vale menos que veinte bien titulados. Con un agente delante, esa diferencia deja de ser una opinión y se puede medir.
