Как создать базу знаний: статьи, поиск, права доступа и ответы ИИ

База знаний — это поисковая библиотека ответов: как что-то сделать, как что-то исправить, какое правило действует. Чтобы создать её, нужны статьи, сгруппированные в несколько понятных категорий, редактор, которым действительно будут пользоваться авторы, поиск, который находит нужную статью по словам, которые люди реально вводят, и решение о том, кто что может читать: публика, вошедшие клиенты или только сотрудники. ИИ-конструктор может создать структуру, редактор и поиск за короткую сессию. Но полезной базу знаний делают текст и поддержка в актуальном состоянии, поэтому сразу проектируйте удобное редактирование и способ замечать устаревшие статьи.

Сначала решите, для кого она

Одни и те же функции подходят очень разным сайтам:

• Публичный центр справки — для клиентов и потенциальных покупателей. Должен быть быстрым, индексируемым поисковыми системами и написанным их языком.
• Документация только для клиентов — за логином, для платящих клиентов или партнёров.
• Внутренняя база знаний — политики, процессы, инструкции для сотрудников. Должна быть закрытой; поиск и актуальность важнее дизайна.

Смешивание публичных и внутренних статей на одном сайте — самая частая причина утечек. Если нужны оба варианта, задайте каждой статье понятную настройку видимости или ведите два отдельных сайта.

Что нужно приложению

Данные

Два поля делают очень много работы: владелец (кто отвечает за точность статьи) и дата последней проверки (когда кто-то в последний раз подтвердил, что статья актуальна). Вместе они позволяют составить список статей, которые никто не проверял полгода.

Страницы

• Читатель: главная со строкой поиска и категориями, страницы категорий, страницы статей с оглавлением, связанными статьями и вопросом «Был ли этот материал полезен?».
• Редактор: список статей с фильтрами (черновики, устаревшие, с низкими оценками), редактор с предпросмотром и история ревизий.
• Админ: категории, пользователи и роли, а также отчёты по поисковым запросам без результатов.

Права доступа

Читатели видят опубликованные статьи, которые им разрешено видеть. Редакторы создают и редактируют статьи, возможно только в определённых категориях. Админы публикуют, архивируют и управляют пользователями. Для внутренней базы знаний всем нужен логин; для публичного центра справки — только авторам.

Решения и компромиссы

Редактор: Markdown или форматированный текст

Markdown быстрый, переносимый и хорошо сочетается с историей версий, но некоторым авторам он неудобен. Редактор с форматированием — с заголовками, списками, изображениями, выносками и блоками кода — кажется привычным. Что бы вы ни выбрали, храните содержимое в формате, который можно будет экспортировать позже.

Поиск

Простого текстового поиска по базе достаточно для нескольких сотен статей, если искать по заголовкам, кратким описаниям и текстам и выше ранжировать совпадения в заголовках. Дальше, или если важны опечатки и синонимы («счёт» и «квитанция»), используйте полнотекстовый поиск или хостинговый поисковый сервис. Наше руководство по добавлению поиска разбирает варианты. Записывайте каждый запрос, который ничего не нашёл: это бесплатный список статей, которые нужно написать.

Ответы ИИ

Поле «задайте вопрос», которое отвечает по вашим статьям, сейчас распространено. Оно работает так: находит самые релевантные фрагменты и просит языковую модель отвечать только по ним — см. что такое RAG. Всегда показывайте статьи-источники, разрешайте ответ «не знаю» и помните, что модель уверенно повторит всё устаревшее в ваших статьях. Создавайте её, когда статьи уже в хорошем состоянии, а не раньше.

Версии и проверка

Сохраняйте ревизии, чтобы видеть, кто что изменил, и откатывать изменения. Для регулируемого контента (кадровые политики, инструкции по безопасности) добавьте шаг согласования перед публикацией изменений.

Первый промпт, который работает

Создай публичный центр справки для Parcelly, приложения для печати этикеток доставки для небольших интернет-магазинов. Главная страница с большой строкой поиска и шестью категориями (Начало работы, Печать этикеток, Перевозчики, Оплата, Возвраты, Решение проблем). Статьи имеют заголовок, краткое описание, текст в Markdown с изображениями и выносками, категорию, теги, статус (черновик, опубликована, в архиве), владельца и дату последней проверки. На страницах статей — оглавление, связанные статьи и вопрос «Был ли этот материал полезен?» с ответом да/нет и необязательным комментарием. Поиск охватывает заголовки, краткие описания и тексты, совпадения в заголовках идут первыми, и каждый запрос записывается вместе с тем, были ли результаты. Область редактора (нужен логин, роли редактор и админ) показывает черновики, статьи, которые не проверялись 180 дней, и статьи с низкими оценками полезности, и хранит историю ревизий. У каждой статьи свой заголовок страницы и мета-описание для поисковых систем. Чистый, спокойный, удобный для чтения дизайн. Сначала мобильная версия.

Этапы создания

1. Составьте список первых 20–30 статей на основе реальных вопросов в поддержку до начала разработки. Этот список определит категории.
2. Создайте сайт и проверьте чтение на телефоне: длина строк, заголовки, изображения.
3. Редактор и роли. Авторы должны добавлять и исправлять статьи без обращения к разработчику.
4. Поиск, затем проверка на словах, которые реально используют клиенты, включая опечатки.
5. Отзывы и журнал поиска.
6. Отчёт по устаревшим статьям на основе владельца и даты последней проверки.
7. Базовое SEO для публичного сайта: уникальные заголовки, описания, понятные URL, карта сайта. См. SEO для сайтов, созданных ИИ.
8. Добавьте ссылку из продукта и ответов поддержки, затем каждую неделю смотрите журнал запросов без результатов.
9. Ответы ИИ, когда контент уже надёжен.

Частые ошибки

• Организация по отделам, а не по тому, что читатель пытается сделать.
• Длинные статьи, покрывающие пять задач. Одна задача на статью, а заголовок говорит, какую проблему она решает.
• Нет владельца у статьи. Никто ничего не обновляет, и доверие падает после первого неверного ответа.
• Внутренние заметки в публичных статьях. Используйте отдельную видимость и проверяйте перед публикацией.
• Поиск, который совпадает только с заголовками. Читатели вводят симптомы, а не названия статей.
• Скриншоты без альтернативного текста и контекста. Они быстро устаревают; описывайте шаг и словами тоже.

Когда лучше готовый продукт

Если ваша команда уже работает в инструменте для документации или вики, внутренняя база знаний там обычно самый простой путь — наше сравнение Notion и Confluence рассматривает два частых выбора. Если вы пользуетесь службой поддержки, её встроенный центр справки связывает статьи с обращениями и предлагает статьи клиентам, и это трудно повторить. Генераторы сайтов документации идеальны для документации для разработчиков, которая хранится рядом с кодом.

Создавайте свою базу, когда нужна собственная структура или права доступа (статьи для каждого клиента, локации или роли), когда база должна быть внутри вашего продукта, а не на отдельном сайте, когда нужны шаги проверки и согласования, которых не требует вики, или когда вы хотите ответы ИИ по своему контенту без ещё одной подписки. Она хорошо сочетается с собственной службой поддержки.

Создание с Mythex

В Mythex вы описываете базу знаний в чате, и она строится в живом предпросмотре; статьи, ревизии и отзывы хранятся в базе данных Postgres, которую агент добавляет по необходимости, а изображения попадают в файловое хранилище проекта. Вход для редакторов использует способ аутентификации, который вы выбираете, поскольку у Mythex нет встроенного входа для конечных пользователей. Для ответов ИИ вы используете API-ключ собственного провайдера ИИ, который хранится как секрет проекта, и расход оплачивается в аккаунте провайдера, а не кредитами Mythex (рецепт ИИ). Новые приложения Mythex по умолчанию — клиентское React-приложение (SPA), которое хуже индексируется поисковиками, поэтому для публичного центра справки попросите статичную или серверно рендерящуюся конфигурацию, например Next.js (рецепт SEO).

Для стартового промпта попробуйте шаблоны хаба знаний о продукте или приложения командной документации.

Вопросы