El conocimiento que vive en la cabeza de un técnico muere cuando este se marcha - pero una base de conocimiento mal configurada es peor: parece documentación y devuelve cero resultados. En el mantenimiento de entornos GLPI para clientes, los dos fracasos que más vemos son artículos que nadie encuentra (problema de configuración) y artículos que nadie escribe (problema de participación). Esta guía aborda ambos, con las consultas y los ajustes que ejecutamos en campo.
Diseña la taxonomía antes del primer artículo
La base de conocimiento de GLPI es nativa (tabla glpi_knowbaseitems) y ya incluye categorías, FAQ, búsqueda full-text, control de visibilidad, historial de revisiones y vinculación a tickets. El error común es empezar por los artículos y dejar que el árbol de categorías crezca solo: en seis meses tienes doce niveles y nadie encuentra nada. Fija la estructura primero:
- Dos niveles de categoría como máximo. Si necesitas un tercero, probablemente sea una etiqueta, no una categoría.
- Títulos accionables: "Cómo restablecer la contraseña de AD" funciona mejor que "Active Directory". El usuario busca por la acción, no por el sistema.
- Cuatro familias cubren el 90% de los casos: Cómo hacer (tutoriales), Resolución de problemas (errores conocidos), Políticas (reglas) y FAQ (pública).
- Un artículo puede estar en varias categorías en GLPI 10/11 (tabla glpi_knowbaseitems_knowbaseitemcategories). Úsalo con moderación: demasiadas categorías es lo mismo que ninguna.
El error que hace "desaparecer" artículos: la visibilidad
En el mantenimiento, el fallo número 1 que encontramos no es la falta de artículo - es un artículo publicado que nadie ve. El técnico lo escribe, lo guarda, lo marca como publicado y da por hecho que está en línea. Pero la visibilidad de GLPI funciona por destino explícito: si nadie añadió un perfil, grupo, entidad o usuario en la pestaña de destinatarios, el artículo solo es visible para su autor - y GLPI no emite ningún aviso. Hemos auditado bases con cientos de artículos donde decenas estaban en ese limbo. Por eso, en el onboarding de mantenimiento, lo primero que ejecutamos es la consulta de artículos huérfanos de visibilidad, antes de hablar de taxonomía o participación:
-- Articulos NO-FAQ sin ningun destino de visibilidad:
-- existen, cuentan en el total y son invisibles para todos, menos el autor.
SELECT k.id, k.name
FROM glpi_knowbaseitems k
LEFT JOIN glpi_knowbaseitems_profiles p ON p.knowbaseitems_id = k.id
LEFT JOIN glpi_knowbaseitems_users u ON u.knowbaseitems_id = k.id
LEFT JOIN glpi_groups_knowbaseitems g ON g.knowbaseitems_id = k.id
LEFT JOIN glpi_entities_knowbaseitems e ON e.knowbaseitems_id = k.id
WHERE k.is_faq = 0
AND p.knowbaseitems_id IS NULL
AND u.knowbaseitems_id IS NULL
AND g.knowbaseitems_id IS NULL
AND e.knowbaseitems_id IS NULL;Un detalle que solo muerde a quien escribe esta consulta: los nombres de las cuatro tablas de visibilidad no son simétricos. Usuarios y perfiles usan glpi_knowbaseitems_users y glpi_knowbaseitems_profiles, pero grupos y entidades se invierten a glpi_groups_knowbaseitems y glpi_entities_knowbaseitems. Cambiar el orden es pasar horas depurando un LEFT JOIN que nunca coincide.
Por qué "AD", "VM" y "PC" no devuelven nada en la búsqueda
La búsqueda de la KB no es un LIKE: GLPI construye un MATCH(name, answer) AGAINST(... IN BOOLEAN MODE) sobre el índice FULLTEXT de la tabla. En MariaDB/MySQL con InnoDB (el valor por defecto en GLPI 10 y 11), innodb_ft_min_token_size define la longitud mínima de palabra indexada, y el valor por defecto es 3. La consecuencia: las siglas de dos letras - "AD", "VM", "PC", "TI", "BD" - no entran en el índice, y buscarlas devuelve vacío aunque haya decenas de artículos que las mencionan. Es el motivo número 1 del "la búsqueda de la KB no sirve" que oímos de los clientes. Diagnóstico:
SHOW VARIABLES LIKE 'innodb_ft_min_token_size';Baja el límite a 2 en el archivo de configuración de MariaDB y reinicia el servicio:
# /etc/mysql/mariadb.conf.d/50-server.cnf (MariaDB)
[mysqld]
innodb_ft_min_token_size = 2La parte que casi todos olvidan: cambiar la variable no reindexar los artículos existentes. El token size se graba al crear el índice, así que hay que reconstruirlo. La forma más directa es forzar la reconstrucción de la tabla:
-- Reinicia MariaDB y reconstruye el indice FULLTEXT
-- (el nuevo token size solo aplica tras recrear el indice):
ALTER TABLE glpi_knowbaseitems ENGINE=InnoDB;El error común es bajar el token a 2, reiniciar y cantar victoria - la variable cambia, pero el índice antiguo sigue ignorando las siglas hasta que se reconstruye. En instalaciones heredadas con MyISAM, el parámetro equivalente es ft_min_word_len.
Ventana de validez: el artículo que solo aparece mañana
Otra trampa silenciosa son los campos begin_date y end_date del artículo. GLPI filtra de la búsqueda cualquier artículo cuyo begin_date esté en el futuro o cuyo end_date ya haya pasado. Es útil para publicar un procedimiento solo a partir de una fecha - pero también es la causa clásica de "creé el artículo y no aparece": alguien rellenó una fecha de inicio sin querer. Si un artículo recién creado no surge en la búsqueda y la visibilidad es correcta, revisa la ventana de validez antes que nada.
FAQ pública para autoservicio
Para que un artículo aparezca en el portal del usuario final, márcalo como FAQ (campo is_faq) y define la visibilidad por entidad con la opción recursiva activada, para propagar a las subentidades. Si quieres la FAQ accesible sin inicio de sesión, habilita la FAQ para usuarios anónimos en la configuración de Asistencia de GLPI. La matriz que usamos para decidir dónde vive cada artículo:
| Objetivo | is_faq | Destino de visibilidad | Dónde aparece |
|---|---|---|---|
| FAQ pública (autoservicio) | 1 | Entidad + recursivo | Portal del usuario; sin login si la FAQ anónima está activada |
| Base técnica interna | 0 | Perfil (p. ej. Técnico) | Pestaña Base de conocimiento, solo perfiles con permiso |
| Procedimiento por cliente | 0 | Entidad específica | Solo técnicos de esa entidad |
| Borrador / en revisión | 0 | Ninguno (solo el autor) | Invisible - úsalo a propósito, nunca por olvido |
Fíjate en la última fila: "sin destino" es un estado válido para un borrador, pero debe ser una elección consciente, nunca el resultado de olvidar rellenar la visibilidad.
Participación: el KPI que funciona (y el que no)
El KPI de "X artículos por técnico al mes" que la literatura ITSM adora produce basura: artículos escritos para cumplir una cifra que nadie consulta. Lo que funciona en la práctica es atar la creación al trabajo que ya ocurre - el cierre de tickets de categorías recurrentes. En lugar de exigir volumen, detecta lo repetitivo y conviértelo en artículo. Esta consulta lista los asuntos que más se repitieron en los últimos 90 días, los candidatos de mayor retorno:
-- Asuntos de ticket repetidos en los ultimos 90 dias:
-- los candidatos de mayor retorno para volverse articulos de KB.
SELECT t.name AS asunto, COUNT(*) AS total
FROM glpi_tickets t
WHERE t.date >= DATE_SUB(NOW(), INTERVAL 90 DAY)
AND t.is_deleted = 0
GROUP BY t.name
HAVING total >= 5
ORDER BY total DESC
LIMIT 20;Documentar la cima de esa lista reduce las reaperturas y el tiempo de atención de forma medible. Y mide por el lado correcto: la columna view de cada artículo cuenta las consultas. Un artículo con muchas visualizaciones está devolviendo la inversión; un artículo con view cerca de cero y date_mod antiguo es candidato a revisión o archivo - no a un ítem más en el total.
Mantenla antes de que envejezca
Una base de conocimiento no es un proyecto, es una rutina. GLPI guarda el historial en glpi_knowbaseitems_revisions, así que puedes editar sin miedo a perder la versión anterior. Define un ritmo de revisión (trimestral suele bastar), priorizando los artículos más consultados - un paso a paso erróneo sobre el restablecimiento de contraseña genera más tickets que su ausencia. Un artículo desactualizado no es neutro: cuesta credibilidad y el técnico vuelve a "preguntarle a fulano".
¿Necesitas una base de conocimiento que realmente reduzca tickets, con la búsqueda afinada y la visibilidad bajo control? Conoce el servicio de mantenimiento GLPI de NexTool.
Revisado por el equipo de NexTool Solutions.
