Jak zbudować bazę wiedzy: artykuły, wyszukiwanie, uprawnienia i odpowiedzi AI

Baza wiedzy to przeszukiwalny zbiór odpowiedzi: jak coś zrobić, jak coś naprawić, jaka jest zasada. Aby ją zbudować, potrzebujesz artykułów pogrupowanych w kilka jasnych kategorii, edytora, z którego autorzy faktycznie będą korzystać, wyszukiwarki, która znajdzie właściwy artykuł na podstawie słów, jakich ludzie naprawdę używają, oraz decyzji o tym, kto co może czytać: wszyscy, zalogowani klienci czy tylko pracownicy. Kreator aplikacji AI może wygenerować strukturę, edytor i wyszukiwarkę w krótkiej sesji. To, co czyni bazę wiedzy przydatną, to jednak pisanie i utrzymanie, dlatego od pierwszego dnia projektuj ją tak, by łatwo ją było edytować i wykrywać nieaktualne artykuły.

Najpierw zdecyduj, dla kogo jest

Te same funkcje obsługują bardzo różne strony:

Publiczne centrum pomocy — dla klientów i potencjalnych klientów. Musi być szybkie, indeksowalne przez wyszukiwarki i napisane ich językiem.
Dokumentacja tylko dla klientów — za logowaniem, dla płacących klientów lub partnerów.
Wewnętrzna baza wiedzy — zasady, procesy, instrukcje dla pracowników. Musi być prywatna; wyszukiwarka i aktualność ważniejsze są niż wygląd.

Mieszanie publicznych i wewnętrznych artykułów w jednej witrynie to najczęstsze źródło wycieków. Jeśli potrzebujesz obu, przypisz każdemu artykułowi wyraźne ustawienie widoczności albo prowadź dwie osobne witryny.

Czego potrzebuje aplikacja

Dane

Tabela	Kluczowe pola
Artykuły	Tytuł, slug, streszczenie, treść, kategoria, tagi, status (szkic, opublikowany, zarchiwizowany), widoczność, właściciel, data ostatniego przeglądu, data aktualizacji
Kategorie	Nazwa, slug, opis, kolejność, rodzic (opcjonalnie)
Wersje	Artykuł, treść, autor, data zapisu
Opinie	Artykuł, pomocne tak/nie, komentarz, data utworzenia
Dziennik wyszukiwań	Zapytanie, liczba wyników, kliknięty artykuł, data utworzenia

Dwa pola robią dużo pracy: właściciel (kto odpowiada za to, by artykuł był poprawny) oraz data ostatniego przeglądu (kiedy ktoś ostatnio potwierdził, że nadal jest prawdziwy). Razem pozwalają wypisać artykuły, których nikt nie sprawdzał od sześciu miesięcy.

Strony

Czytelnik: strona główna z wyszukiwarką i kategoriami, strony kategorii, strony artykułów ze spisem treści, powiązanymi artykułami i pytaniem „Czy to było pomocne?”.
Edytor: lista artykułów z filtrami (szkice, nieaktualne, nisko oceniane), edytor z podglądem i historia wersji.
Administrator: kategorie, użytkownicy i role oraz raporty o wyszukiwaniach bez wyników.

Uprawnienia

Czytelnicy widzą opublikowane artykuły, do których mają dostęp. Edytorzy tworzą i edytują artykuły, być może tylko w określonych kategoriach. Administratorzy publikują, archiwizują i zarządzają użytkownikami. Wewnętrzna baza wymaga logowania dla wszystkich; publiczne centrum pomocy — tylko dla autorów.

Decyzje i kompromisy

Edytor: Markdown czy tekst sformatowany

Markdown jest szybki, przenośny i dobrze współpracuje z historią wersji, ale część autorów go nie lubi. Edytor tekstu sformatowanego z nagłówkami, listami, obrazkami, wyróżnieniami i blokami kodu wydaje się znajomy. Cokolwiek wybierzesz, przechowuj treść w formacie, który będzie można później wyeksportować.

Podstawowe wyszukiwanie tekstowe w bazie wystarczy dla kilkuset artykułów, jeśli przeszukuje tytuły, streszczenia i treść, a dopasowania w tytule oceniasz wyżej. Przy większej liczbie artykułów albo gdy liczą się literówki i synonimy („faktura” vs „rachunek”), użyj pełnotekstowego wyszukiwania lub hostowanej usługi wyszukiwania. Nasz przewodnik po dodawaniu wyszukiwarki omawia opcje. Zapisuj każde zapytanie, które nic nie zwraca: to darmowa lista artykułów do napisania.

Odpowiedzi AI

Pole „zadaj pytanie”, które odpowiada na podstawie Twoich artykułów, jest już powszechne. Działa tak, że pobiera najtrafniejsze fragmenty i prosi model językowy, by odpowiadał wyłącznie na ich podstawie — zobacz czym jest RAG. Zawsze pokazuj artykuły źródłowe, pozwalaj na odpowiedź „nie wiem” i pamiętaj, że model z pewnością powtórzy wszystko, co jest nieaktualne w Twoich artykułach. Buduj to po tym, jak artykuły będą w dobrym stanie, a nie wcześniej.

Wersjonowanie i przegląd

Zachowuj wersje, abyś mógł sprawdzić, kto co zmienił, i cofnąć zmiany. Przy treściach regulowanych prawnie (polityka kadrowa, procedury bezpieczeństwa) dodaj krok zatwierdzenia przed publikacją zmiany.

Pierwszy prompt, który działa

Zbuduj publiczne centrum pomocy dla Parcelly, aplikacji do etykiet przesyłek dla małych sklepów internetowych. Strona główna z dużym polem wyszukiwania i sześcioma kategoriami (Pierwsze kroki, Drukowanie etykiet, Przewoźnicy, Rozliczenia, Zwroty, Rozwiązywanie problemów). Artykuły mają tytuł, streszczenie, treść w Markdown z obrazkami i wyróżnieniami, kategorię, tagi, status (szkic, opublikowany, zarchiwizowany), właściciela i datę ostatniego przeglądu. Strony artykułów pokazują spis treści, powiązane artykuły oraz pytanie „Czy to było pomocne?” z odpowiedzią tak/nie i opcjonalnym komentarzem. Wyszukiwarka obejmuje tytuły, streszczenia i treść, z dopasowaniami w tytułach na pierwszym miejscu, i zapisuje każde zapytanie wraz z informacją, czy zwróciło wyniki. Obszar edytora (wymagane logowanie, role edytor i administrator) wyświetla szkice, artykuły nieprzeglądane od 180 dni i artykuły o niskich ocenach „pomocne” oraz prowadzi historię wersji. Każdy artykuł ma własny tytuł strony i meta opis dla wyszukiwarek. Czysty, spokojny, czytelny projekt. Najpierw telefon.

Kroki budowy

Zbierz pierwsze 20–30 artykułów na podstawie prawdziwych pytań do pomocy technicznej, zanim cokolwiek zbudujesz. Ta lista ukształtuje kategorie.
Wygeneruj stronę i sprawdź czytanie na telefonie — długość wiersza, nagłówki, obrazki.
Edytor i role. Autorzy muszą dodawać i poprawiać artykuły bez pytania programisty.
Wyszukiwarka, a potem testy na słowach, których faktycznie używają klienci, łącznie z błędami pisowni.
Opinie i zapis wyszukiwań.
Raport nieaktualnych artykułów oparty na właścicielu i dacie ostatniego przeglądu.
Podstawy SEO dla publicznej strony: unikalne tytuły, opisy, czyste adresy URL, mapa strony. Zobacz SEO dla stron tworzonych przez AI.
Podlinkuj ją ze swojego produktu i odpowiedzi do klientów, a potem co tydzień sprawdzaj dziennik zapytań bez wyników.
Odpowiedzi AI, gdy treść będzie solidna.

Częste błędy

Organizowanie według działów zamiast według tego, co czytelnik chce zrobić.
Długie artykuły obejmujące pięć zadań. Jedno zadanie na artykuł, z tytułem mówiącym, jaki problem rozwiązuje.
Brak właściciela każdego artykułu. Nikt nic nie aktualizuje, a zaufanie spada po pierwszej błędnej odpowiedzi.
Wewnętrzne notatki w publicznych artykułach. Używaj osobnej widoczności i sprawdzaj przed publikacją.
Wyszukiwarka, która dopasowuje tylko tytuły. Czytelnicy wpisują objawy, a nie nazwy artykułów.
Zrzuty ekranu bez tekstu alternatywnego lub kontekstu. Szybko się dezaktualizują; opisz krok także słowami.

Kiedy lepszy jest gotowy produkt

Jeśli Twój zespół już pracuje w narzędziu do dokumentacji lub wiki, wewnętrzna baza wiedzy w tym narzędziu jest zwykle najmniejszym oporem — nasze porównanie Notion i Confluence omawia dwa popularne wybory. Jeśli korzystasz z systemu helpdesk, jego wbudowane centrum pomocy łączy artykuły ze zgłoszeniami i podpowiada klientom artykuły, co trudno odtworzyć samodzielnie. Generatory stron dokumentacji są idealne do dokumentacji programistycznej przechowywanej obok kodu.

Buduj własną, gdy potrzebujesz własnej struktury lub uprawnień (artykuły per klient, per lokalizacja, per rola), chcesz mieć bazę wewnątrz swojego produktu zamiast na osobnej stronie, potrzebujesz kroków przeglądu i zatwierdzania, których wiki nie wymusza, lub chcesz odpowiedzi AI na swojej treści bez kolejnej subskrypcji. Dobrze łączy się z własnym helpdeskiem.

Budowa w Mythex

W Mythex opisujesz bazę wiedzy w czacie, a następnie powstaje ona w podglądzie na żywo; artykuły, wersje i opinie są przechowywane w bazie Postgres, którą agent dodaje w razie potrzeby, a obrazki trafiają do magazynu plików projektu. Logowanie edytorów korzysta z podejścia do uwierzytelniania, które wybierasz, ponieważ Mythex nie ma wbudowanego logowania użytkowników końcowych. Do odpowiedzi AI używasz klucza API własnego dostawcy AI, przechowywanego jako sekret projektu, a koszty naliczane są na koncie dostawcy, a nie w kredytach Mythex (przepis AI). Nowe aplikacje Mythex domyślnie są aplikacjami React renderowanymi po stronie klienta, które słabiej wypadają w wyszukiwarkach, dlatego w przypadku publicznego centrum pomocy poproś o konfigurację statyczną lub renderowaną po stronie serwera, np. Next.js (przepis SEO).

Aby uzyskać punkt wyjścia do promptu, wypróbuj szablony hub wiedzy o produkcie lub aplikacja z dokumentacją zespołu.

Pytania

Czym różni się baza wiedzy od wiki?

Baza wiedzy jest zwykle redagowana: mały zespół pisze i utrzymuje odpowiedzi dla określonej grupy odbiorców, często klientów. Wiki pozwala edytować każdemu i zwykle rozrasta się szerzej i chaotyczniej. To samo oprogramowanie może obsługiwać oba przypadki; różnica polega na tym, kto pisze i kto weryfikuje.

Jak należy uporządkować bazę wiedzy?

Według tego, co czytelnicy chcą zrobić, a nie według struktury firmy. Kilka kategorii najwyższego poziomu, krótkie artykuły zorientowane na zadanie z jasnymi tytułami i linki między powiązanymi tekstami sprawdzają się lepiej niż głębokie drzewa folderów.

Czy mogę dodać do bazy wiedzy odpowiedzi AI?

Tak. Typowe podejście, nazywane generowaniem wspomaganym wyszukiwaniem (RAG), przeszukuje Twoje artykuły w poszukiwaniu istotnych fragmentów i prosi model językowy o odpowiedź wyłącznie na podstawie tych fragmentów, z linkami do źródeł. Działa najlepiej, gdy same artykuły są poprawne i aktualne.

Czy publiczne centrum pomocy powinno być indeksowane przez wyszukiwarki?

Zwykle tak. Ludzie szukają, jak rozwiązać problem, zanim skontaktują się z pomocą techniczną, dlatego każdy artykuł powinien mieć własną stronę, tytuł i opis. Wewnętrzne artykuły trzymaj na osobnej stronie, zabezpieczonej logowaniem.