Cómo crear una base de conocimiento: artículos, búsqueda, permisos y respuestas con IA
Una base de conocimiento es una biblioteca con búsqueda de respuestas: cómo hacer algo, cómo arreglar algo, cuál es la norma. Para crear una necesitas artículos agrupados en unas pocas categorías claras, un editor que tus redactores usen de verdad, una búsqueda que encuentre el artículo correcto con las palabras que la gente escribe realmente, y una decisión sobre quién puede leer qué: el público, los clientes con sesión iniciada o solo el personal. Un constructor de apps con IA puede generar la estructura, el editor y la búsqueda en una sesión corta. Lo que hace útil a una base de conocimiento es la redacción y el mantenimiento, así que diseña desde el primer día para facilitar la edición y para detectar artículos desactualizados.
Decide primero para quién es
Las mismas funciones sirven a webs muy distintas:
- Centro de ayuda público: para clientes y potenciales clientes. Debe ser rápido, indexable por los buscadores y escrito con sus propias palabras.
- Documentación solo para clientes: detrás de un inicio de sesión, para clientes de pago o socios.
- Base de conocimiento interna: políticas, procesos y guías para el personal. Debe ser privada; la búsqueda y la actualidad importan más que el diseño.
Mezclar artículos públicos e internos en un mismo sitio es donde se producen la mayoría de las filtraciones. Si necesitas ambos, asigna a cada artículo una opción de visibilidad clara, o usa dos sitios separados.
Qué necesita la app
Datos
| Tabla | Campos clave |
|---|---|
| Artículos | Título, slug, resumen, contenido, categoría, etiquetas, estado (borrador, publicado, archivado), visibilidad, responsable, última revisión, fecha de actualización |
| Categorías | Nombre, slug, descripción, orden, categoría padre (opcional) |
| Revisiones | Artículo, contenido, autor, fecha de guardado |
| Valoraciones | Artículo, útil sí/no, comentario, fecha de creación |
| Registro de búsquedas | Consulta, número de resultados, artículo en el que se hizo clic, fecha de creación |
Dos campos hacen mucho trabajo: responsable (quién mantiene el artículo exacto) y última revisión (cuándo alguien confirmó por última vez que sigue siendo cierto). Juntos te permiten listar los artículos que nadie ha comprobado en seis meses.
Páginas
- Lector: inicio con búsqueda y categorías, páginas de categoría, páginas de artículo con índice, artículos relacionados y una pregunta «¿Te ha sido útil?».
- Editor: lista de artículos con filtros (borradores, obsoletos, mal valorados), un editor con vista previa e historial de revisiones.
- Administración: categorías, usuarios y roles, e informes de búsquedas sin resultados.
Permisos
Los lectores ven los artículos publicados a los que tienen acceso. Los editores crean y editan artículos, quizá limitados a ciertas categorías. Los administradores publican, archivan y gestionan usuarios. En una base interna, todo el mundo necesita un inicio de sesión; en un centro de ayuda público, solo lo necesitan los redactores.
Decisiones y compromisos
Editor: Markdown o texto enriquecido
Markdown es rápido, portable y encaja bien con el historial de versiones, pero a algunos redactores no les resulta cómodo. Un editor de texto enriquecido con títulos, listas, imágenes, avisos y bloques de código resulta familiar. Elijas lo que elijas, guarda el contenido en un formato que puedas exportar después.
Búsqueda
La búsqueda de texto básica de la base de datos basta para unos cientos de artículos si buscas en títulos, resúmenes y contenidos, y das más peso a las coincidencias en el título. A partir de ahí, o si importan las erratas y los sinónimos («factura» frente a «recibo»), usa una búsqueda de texto completo de verdad o un servicio de búsqueda alojado. Nuestra guía para añadir búsqueda repasa las opciones. Registra cada consulta que no devuelva nada: es una lista gratuita de artículos que escribir.
Respuestas con IA
Hoy es habitual un cuadro de «haz una pregunta» que responde a partir de tus artículos. Funciona recuperando los fragmentos más relevantes y pidiendo a un modelo de lenguaje que responda solo a partir de ellos; consulta qué es RAG. Muestra siempre los artículos de origen, permite la respuesta «no lo sé» y ten en cuenta que repetirá con seguridad cualquier cosa desactualizada que aparezca en tus artículos. Construyela cuando los artículos ya estén en buen estado, no antes.
Versiones y revisión
Guarda revisiones para ver quién cambió qué y poder volver atrás. En contenidos regulados (políticas de RRHH, procedimientos de seguridad), añade un paso de aprobación antes de publicar un cambio.
Un primer prompt que funciona
Construye un centro de ayuda público para Parcelly, una app de etiquetas de envío para pequeñas tiendas online. Página de inicio con un buscador grande y seis categorías (Primeros pasos, Imprimir etiquetas, Transportistas, Facturación, Devoluciones, Solución de problemas). Los artículos tienen título, resumen, contenido en Markdown con imágenes y avisos, categoría, etiquetas, estado (borrador, publicado, archivado), responsable y fecha de última revisión. Las páginas de artículo muestran un índice, artículos relacionados y una pregunta «¿Te ha sido útil?» con sí/no y un comentario opcional. La búsqueda cubre títulos, resúmenes y contenidos, con las coincidencias en el título primero, y registra cada consulta y si devolvió resultados. Un área de editor (requiere inicio de sesión, roles editor y administrador) lista los borradores, los artículos no revisados en 180 días y los artículos con valoraciones de utilidad bajas, y conserva el historial de revisiones. Cada artículo tiene su propio título de página y su propia meta descripción para los buscadores. Diseño limpio, tranquilo y legible. Pensado primero para móvil.
Pasos de construcción
- Enumera tus primeros 20 o 30 artículos a partir de preguntas reales de soporte antes de construir nada. Esa lista da forma a las categorías.
- Genera el sitio y comprueba la lectura en un teléfono: longitud de línea, títulos, imágenes.
- Editor y roles. Los redactores deben poder añadir y corregir artículos sin pedírselo a un desarrollador.
- Búsqueda, y pruébala con las palabras que usan realmente los clientes, incluidas las erratas.
- Valoraciones y registro de búsquedas.
- Informe de artículos obsoletos basado en el responsable y la fecha de última revisión.
- Lo básico de SEO para un sitio público: títulos y descripciones únicos, URLs limpias, un mapa del sitio. Consulta SEO para webs creadas con IA.
- Enlázala desde tu producto y tus respuestas de soporte, y revisa cada semana el registro de búsquedas sin resultados.
- Respuestas con IA, cuando el contenido ya sea sólido.
Errores habituales
- Organizar por departamento en lugar de por lo que intenta hacer el lector.
- Artículos largos que cubren cinco tareas. Una tarea por artículo, con un título que diga qué resuelve.
- No tener un responsable por artículo. Nadie actualiza nada, y la confianza cae tras la primera respuesta incorrecta.
- Notas internas en artículos públicos. Usa visibilidades separadas y revisa antes de publicar.
- Una búsqueda que solo coincide con los títulos. Los lectores escriben síntomas, no nombres de artículos.
- Capturas de pantalla sin texto alternativo ni contexto. Envejecen rápido; describe también el paso con palabras.
Cuándo es mejor un producto ya hecho
Si tu equipo ya trabaja en una herramienta de documentación o de wiki, una base de conocimiento interna allí suele ser el camino de menor resistencia; nuestra comparativa de Notion frente a Confluence cubre dos opciones habituales. Si usas un software de mesa de ayuda, su centro de ayuda integrado enlaza artículos con tickets y sugiere artículos a los clientes, algo difícil de reproducir. Los generadores de sitios de documentación son ideales para documentación de desarrollo que vive junto al código.
Construye la tuya cuando necesites tu propia estructura o tus propios permisos (artículos por cliente, por sede o por rol), quieras la base de conocimiento dentro de tu producto y no en un sitio aparte, necesites pasos de revisión y aprobación que una wiki no impone, o quieras respuestas con IA sobre tu contenido sin otra suscripción. Encaja de forma natural con un sistema de atención al cliente propio.
Cómo construirlo con Mythex
En Mythex describes la base de conocimiento en el chat y se construye en una vista previa en vivo; los artículos, las revisiones y las valoraciones se guardan en una base de datos Postgres que el agente añade cuando hace falta, y las imágenes van al almacenamiento de archivos del proyecto. Los inicios de sesión de editores usan un enfoque de autenticación que tú eliges, ya que Mythex no incluye un inicio de sesión de usuario final. Para las respuestas con IA, usas tu propia clave de API de tu proveedor de IA, guardada como secreto del proyecto, y el consumo se factura en tu cuenta del proveedor y no en los créditos de Mythex (receta de IA). Las nuevas apps de Mythex usan por defecto una single-page app de React renderizada en el cliente, que funciona peor con los buscadores; por eso, para un centro de ayuda público, pide una configuración estática o renderizada en el servidor, como Next.js (receta de SEO).
Para un prompt inicial, prueba las plantillas hub de conocimiento de producto o app de documentación de equipo.
Preguntas
¿Qué diferencia hay entre una base de conocimiento y una wiki?
Una base de conocimiento suele estar curada: un equipo pequeño redacta y mantiene las respuestas para un público definido, a menudo los clientes. Una wiki permite editar a todo el mundo y tiende a crecer más amplia y desordenada. El mismo software puede servir para cualquiera de las dos; la diferencia está en quién escribe y quién revisa.
¿Cómo debe organizarse una base de conocimiento?
Según lo que intentan hacer los lectores, no según tu organigrama. Unas pocas categorías principales, artículos cortos centrados en tareas, con títulos claros, y enlaces entre artículos relacionados funcionan mejor que árboles de carpetas profundos.
¿Puedo añadir respuestas con IA a una base de conocimiento?
Sí. El enfoque habitual, llamado generación aumentada por recuperación, busca en tus artículos los fragmentos relevantes y pide a un modelo de lenguaje que responda usando solo esos fragmentos, con enlaces a las fuentes. Funciona mejor cuando los propios artículos son exactos y están al día.
¿Debe indexarse en buscadores un centro de ayuda público?
Normalmente sí. Las personas buscan cómo resolver un problema antes de contactar con soporte, así que cada artículo debe tener su propia página, título y descripción. Mantén los artículos internos en un sitio separado y protegido con inicio de sesión.