Как да създадете база знания: статии, търсене, права и отговори с ИИ

Базата знания е търсима библиотека от отговори: как да направите нещо, как да поправите нещо, какво е правилото. За да я създадете, са ви нужни статии, групирани в няколко ясни категории, редактор, който вашите автори наистина ще ползват, търсене, което намира правилната статия по думите, с които хората действително пишат, и решение кой какво може да чете — публичността, клиентите с вход или само служителите. ИИ билдър може да създаде структурата, редактора и търсенето за кратка сесия. Полезна я прави писането и поддръжката, затова проектирайте лесно редактиране и откриване на остарели статии от първия ден.

Първо решете за кого е

Едни и същи функции служат на много различни сайтове:

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

Смесването на публични и вътрешни статии в един сайт е мястото, където настъпват повечето течове. Ако ви трябват и двете, дайте на всяка статия ясна настройка за видимост или направете два отделни сайта.

Какво трябва да може приложението

Данни

Два полета вършат много работа: собственик (кой поддържа статията точна) и последна проверка (кога някой за последно е потвърдил, че е още вярна). Заедно ви позволяват да изброите статиите, които никой не е проверявал от шест месеца.

Страници

• Читател: начало с търсене и категории, страници на категории, страници на статии със съдържание, свързани статии и въпрос „Беше ли полезно?“.
• Редактор: списък със статии с филтри (чернови, остарели, с ниски оценки), редактор с преглед и история на ревизиите.
• Администратор: категории, потребители и роли, и справки за търсения без резултати.

Права за достъп

Читателите виждат публикуваните статии, до които имат достъп. Редакторите създават и редактират статии, може би ограничени до определени категории. Администраторите публикуват, архивират и управляват потребителите. За вътрешна база знания всеки трябва да има вход; за публичен център за помощ входът е само за авторите.

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

Редактор: Markdown или богат текст

Markdown е бърз, преносим и добре работи с история на версиите, но някои автори го намират за отблъскващ. Редакторът с богат текст — със заглавия, списъци, изображения, важни блокове и блокове с код — изглежда познато. Какъвто и да изберете, съхранявайте съдържанието във формат, който по-късно можете да експортирате.

Търсене

Основно текстово търсене в базата е достатъчно за няколко стотин статии, ако търсите в заглавията, резюметата и текстовете и класирате по-горе съвпаденията в заглавието. Отвъд това или ако са важни грешките при писане и синонимите („фактура“ срещу „сметка“), използвайте истинско full-text търсене или хоствана услуга за търсене. Нашето ръководство за добавяне на търсене разглежда вариантите. Записвайте всяка заявка, която не връща нищо: това е безплатен списък със статии, които трябва да напишете.

Отговори с ИИ

Кутията „Задайте въпрос“, която отговаря от вашите статии, вече е често срещана. Работи така: извлича най-подходящите пасажи и моли езиков модел да отговори само от тях — вижте какво е RAG. Винаги показвайте изходните статии, позволете „Не знам“ и помнете, че системата уверено ще повтори всичко остарало в статиите ви. Изграждайте я, след като статиите са в добро състояние, а не преди.

Версии и преглед

Пазете ревизиите, за да виждате кой какво е променил и да можете да се върнете назад. За регулирано съдържание (HR политики, процедури по безопасност) добавете стъпка за одобрение преди публикуване на промяна.

Първо запитване, което работи

Създай публичен център за помощ за Parcelly, приложение за етикети за пратки за малки онлайн магазини. Начална страница с голямо поле за търсене и шест категории (Начало, Печат на етикети, Куриери, Фактуриране, Връщания, Отстраняване на неизправности). Статиите имат заглавие, резюме, текст в Markdown с изображения и важни блокове, категория, тагове, статус (чернова, публикувана, архивирана), собственик и дата на последна проверка. Страниците на статиите показват съдържание, свързани статии и въпрос „Беше ли полезно?“ с да/не и незадължителен коментар. Търсенето обхваща заглавия, резюмета и текстове, като съвпаденията в заглавията са първи, и записва всяка заявка и дали е върнала резултати. Зона за редактори (изисква вход, роли редактор и администратор) показва чернови, статии, непроверявани от 180 дни, и статии с ниски оценки за полезност, и пази история на ревизиите. Всяка статия има собствено заглавие на страницата и мета описание за търсачките. Чист, спокоен, четлив дизайн. Първо за мобилни телефони.

Стъпки за изграждане

1. Съставете първите 20–30 статии от реални въпроси към поддръжката, преди да строите каквото и да е. Този списък определя категориите.
2. Генерирайте сайта и проверете четенето на телефон — дължина на редовете, заглавия, изображения.
3. Редактор и роли. Авторите трябва да добавят и поправят статии, без да молят разработчик.
4. Търсене, после го тествайте с думите, които клиентите реално използват, включително с правописни грешки.
5. Обратна връзка и журнал на търсенията.
6. Справка за остарели статии въз основа на собственик и дата на последна проверка.
7. Основи на SEO за публичен сайт: уникални заглавия, описания, чисти URL адреси, sitemap. Вижте SEO за сайтове, създадени с ИИ.
8. Свържете я от продукта си и от отговорите на поддръжката, после следете седмично журнала за търсения без резултати.
9. Отговори с ИИ, когато съдържанието е стабилно.

Чести грешки

• Организиране по отдели вместо по това, което читателят се опитва да направи.
• Дълги статии, които покриват пет задачи. Една задача на статия, със заглавие, което казва какво решава.
• Няма собственик на всяка статия. Никой не обновява нищо и доверието спада след първия грешен отговор.
• Вътрешни бележки в публични статии. Използвайте отделна видимост и преглеждайте преди публикуване.
• Търсене, което съвпада само със заглавията. Читателите пишат симптоми, не имена на статии.
• Екранни снимки без alt текст или контекст. Бързо остаряват; опишете стъпката и с думи.

Кога е по-добър готов продукт

Ако екипът ви вече работи в инструмент за документация или уики, вътрешната база знания там обикновено е най-лесният път — нашето сравнение Notion срещу Confluence разглежда два често срещани избора. Ако използвате helpdesk продукт, вграденият в него център за помощ свързва статиите с тикетите и предлага статии на клиентите, което е трудно за възпроизвеждане. Генераторите на документационни сайтове са идеални за документация за разработчици, пазена заедно с кода.

Създайте своя, когато ви трябва собствена структура или права (статии по клиент, по локация, по роля), искате базата знания вътре в продукта, а не на отделен сайт, имате нужда от стъпки за преглед и одобрение, които уики не налага, или искате отговори с ИИ върху собственото си съдържание без още един абонамент. Тя се съчетава естествено с собствена helpdesk система.

Изграждане с Mythex

В Mythex описвате базата знания в чата и тя се изгражда в жив преглед; статиите, ревизиите и обратната връзка се съхраняват в Postgres база данни, която агентът добавя при нужда, а изображенията отиват във файловото хранилище на проекта. Входът за редакторите използва подход за автентикация по ваш избор, тъй като Mythex няма вграден вход за крайни потребители. За отговори с ИИ използвате API ключ на собствения си доставчик на ИИ, пазен като тайна на проекта, а използването се таксува при вашия доставчик, не в кредитите на Mythex (рецепта за ИИ). Новите Mythex приложения по подразбиране са клиентски React single-page приложения, които са по-слаби за търсачките, затова за публичен център за помощ поискайте настройка, оптимизирана за статично съдържание или рендериране на сървъра, като Next.js (рецепта за SEO).

За начално запитване пробвайте шаблоните продуктов хъб за знания или приложение за екипна документация.

Въпроси