Як створити базу знань: статті, пошук, права доступу та відповіді ШІ

База знань — це пошукова бібліотека відповідей: як щось зробити, як щось полагодити, яке правило діє. Щоб створити її, потрібні статті, згруповані в кілька зрозумілих категорій, редактор, яким справді користуватимуться автори, пошук, що знаходить потрібну статтю за словами, які люди справді вводять, і рішення про те, хто що може читати: публіка, клієнти з логіном чи лише персонал. Конструктор застосунків на ШІ може створити структуру, редактор і пошук за коротку сесію. Корисною базу знань робить написання й підтримка, тож проєктуйте її з першого дня для легкого редагування та для помітки застарілих статей.

Спершу вирішіть, для кого вона

Одні й ті самі функції обслуговують дуже різні сайти:

• Публічний центр довідки — для клієнтів і потенційних клієнтів. Має бути швидким, індексованим пошуковими системами і написаним їхніми словами.
• Документація лише для клієнтів — за логіном, для платних клієнтів або партнерів.
• Внутрішня база знань — політики, процеси, інструкції для персоналу. Має бути приватною; пошук і актуальність важливіші за дизайн.

Змішування публічних і внутрішніх статей в одному сайті — головне джерело витоків. Якщо потрібні обидва типи, задайте кожній статті чітке налаштування видимості або ведіть два окремі сайти.

Що потрібно застосунку

Дані

Два поля виконують багато роботи: власник (хто підтримує статтю точною) і дата останнього перегляду (коли хтось востаннє підтвердив, що вона досі правдива). Разом вони дозволяють вивести статті, які ніхто не перевіряв шість місяців.

Сторінки

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

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

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

Рішення та компроміси

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

Markdown швидкий, переносний і добре працює з історією версій, але деяким авторам він не подобається. Редактор форматованого тексту із заголовками, списками, зображеннями, виділеними блоками та блоками коду здається знайомим. Що б ви не обрали, зберігайте вміст у форматі, який можна буде експортувати пізніше.

Пошук

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

Відповіді ШІ

Поле «поставити запитання», яке відповідає зі ваших статей, тепер поширене. Воно працює так: знаходить найрелевантніші фрагменти та просить мовну модель відповідати лише на їх основі — див. що таке RAG. Завжди показуйте статті-джерела, дозволяйте відповідь «не знаю» і пам'ятайте, що модель упевнено повторить усе застаріле зі статей. Будуйте це після того, як статті будуть у доброму стані, а не раніше.

Версії та перевірка

Зберігайте ревізії, щоб бачити, хто що змінив, і повертатися назад. Для регульованого вмісту (політики HR, процедури безпеки) додайте етап схвалення перед публікацією змін.

Перший промпт, що працює

Створи публічний центр довідки для Parcelly, застосунку для друку наклейок доставки для невеликих інтернет-магазинів. Головна сторінка з великим полем пошуку та шістьма категоріями (Початок роботи, Друк наклейок, Перевізники, Оплата, Повернення, Усунення несправностей). Статті мають назву, короткий опис, текст у Markdown із зображеннями та виділеними блоками, категорію, теги, статус (чернетка, опубліковано, архів), власника та дату останнього перегляду. Сторінки статей показують зміст, пов'язані статті та питання «Чи було це корисно?» так/ні з необов'язковим коментарем. Пошук охоплює назви, короткі описи і текст, збіги з назвою ранжуються першими, і логує кожен запит та те, чи він дав результати. Зона редактора (потрібен логін, ролі редактор і адміністратор) показує чернетки, статті, не переглянуті за 180 днів, і статті з низькими оцінками корисності, та веде історію ревізій. Кожна стаття має власну назву сторінки та мета-опис для пошукових систем. Чистий, спокійний, зручний для читання дизайн. Спершу мобільний.

Кроки побудови

1. Складіть перші 20–30 статей на основі реальних запитань до підтримки ще до побудови. Цей список формує категорії.
2. Згенеруйте сайт і перевірте читання на телефоні — довжину рядків, заголовки, зображення.
3. Редактор і ролі. Автори мають додавати та виправляти статті без звернення до розробника.
4. Пошук, а потім перевірте його словами, які справді використовують клієнти, включно з помилками друку.
5. Відгуки та журнал пошуку.
6. Звіт про застарілі статті на основі власника і дати останнього перегляду.
7. Основи SEO для публічного сайту: унікальні назви, описи, чисті URL, карта сайту. Див. SEO для сайтів, створених ШІ.
8. Посилайтеся на базу з вашого продукту та відповідей підтримки, потім щотижня переглядайте журнал запитів без результатів.
9. Відповіді ШІ, коли вміст буде надійним.

Типові помилки

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

Коли краще готовий продукт

Якщо ваша команда вже працює в інструменті документації чи вікі, внутрішня база знань там зазвичай найпростіший шлях — наше порівняння Notion і Confluence розглядає два поширені варіанти. Якщо ви користуєтеся продуктом helpdesk, його вбудований центр довідки прив'язує статті до заявок і пропонує статті клієнтам, що важко відтворити. Генератори сайтів документації ідеальні для документації для розробників, яка зберігається разом із кодом.

Власну базу будуйте, коли потрібна ваша структура чи права доступу (статті для кожного клієнта, локації, ролі), коли хочете мати базу всередині продукту, а не на окремому сайті, коли потрібні кроки перевірки та схвалення, яких вікі не забезпечує, або коли хочете відповіді ШІ за вашим вмістом без ще однієї підписки. Вона природно поєднується з власним helpdesk.

Створення з Mythex

У Mythex ви описуєте базу знань у чаті, і вона будується в живому попередньому перегляді; статті, ревізії та відгуки зберігаються в базі Postgres, яку агент додає за потреби, а зображення йдуть у файлове сховище проєкту. Логін для редакторів використовує підхід до автентифікації, який ви обираєте, оскільки в Mythex немає вбудованого логіну для кінцевих користувачів. Для відповідей ШІ ви використовуєте API-ключ свого провайдера ШІ, збережений як секрет проєкту, і використання оплачується через ваш обліковий запис провайдера, а не кредитами Mythex (рецепт ШІ). Нові застосунки Mythex за замовчуванням є односторінковим React-застосунком із рендерингом на клієнті, що гірше для пошукових систем, тож для публічного центру довідки попросіть статичну або серверну конфігурацію, наприклад Next.js (рецепт SEO).

Як стартовий промпт спробуйте шаблони бази знань продукту або застосунку командної документації.

Запитання