Baza wiedzy firmowej dla AI — jak przygotować dokumenty

System oparty na sztucznej inteligencji odpowiada tak dobrze, jak dobra jest wiedza, którą mu dasz. To zdanie brzmi banalnie, dopóki nie zobaczy się, jak wygląda dokumentacja w typowej firmie: aktualne procedury obok nieaktualnych, ta sama usługa nazwana na trzy sposoby, kluczowe ustalenia w czyjejś skrzynce pocztowej. Uporządkowanie tego jest najbardziej pracochłonnym etapem wdrożenia i jednocześnie tym, który zwraca się niezależnie od losów projektu.

Autor: zespół Convert Studio — software house z Kielc i Krakowa, projektujemy aplikacje webowe, sklepy i wdrożenia AI dla firm.

Po co osobna baza wiedzy

Model językowy nie zna Twojej oferty, cennika ani procedur. Zapytany o nie bez dostępu do dokumentów wygeneruje odpowiedź prawdopodobną — czyli brzmiącą sensownie i najczęściej nieprawdziwą.

Rozwiązaniem jest układ, w którym system najpierw wyszukuje właściwe fragmenty w Twoich dokumentach, a dopiero potem formułuje odpowiedź wyłącznie na ich podstawie, ze wskazaniem źródła. Pracownik widzi wtedy, z którego fragmentu procedury pochodzi odpowiedź, i weryfikuje ją w kilka sekund.

Praktyczna konsekwencja: jakość systemu zależy przede wszystkim od jakości dokumentów, a dopiero potem od modelu. Zmiana dostawcy modelu nie naprawi bałaganu w bazie wiedzy.

Co włączyć, a co zostawić

Jak przygotować dokument

System dzieli dokumenty na fragmenty i wyszukuje te pasujące do pytania. Fragment wyrwany z kontekstu musi pozostać zrozumiały — i to jest główna zasada, z której wynika reszta.

• Nagłówki opisowe. „Zwroty i reklamacje" zamiast „Rozdział 4" — fragment znaleziony przez wyszukiwanie sam mówi, czego dotyczy.
• Jedna sekcja, jeden temat. Sekcja mieszająca zwroty z gwarancją i dostawą trafia do wyników przy każdym z tych pytań, za każdym razem tylko częściowo trafnie.
• Unikaj odwołań wewnętrznych. „Jak opisano powyżej" jest bezużyteczne, gdy fragment czyta się osobno.
• Rozwijaj skróty przy pierwszym użyciu w każdej sekcji, nie tylko na początku dokumentu.
• Konkret zamiast ogólnika. „Termin wynosi czternaście dni" działa, „termin ustalany indywidualnie" nie odpowiada na nic.
• Data aktualizacji w treści, nie tylko w metadanych pliku.
• Tabele zamiast opisu tam, gdzie porównujesz warianty — łatwiej je odnaleźć i zacytować.

Rozstrzyganie sprzeczności

To etap, który ujawnia najwięcej i bywa najbardziej niewygodny. Gdy dwa dokumenty mówią co innego, system wybierze jeden — nie wiadomo który, i za każdym razem może wybrać inaczej.

Typowe źródła rozbieżności w firmach: regulamin mówi jedno, a obsługa klienta od lat robi inaczej; strona internetowa obiecuje krótszy termin niż procedura wewnętrzna; oferta handlowa zawiera warunki nieujęte w umowie wzorcowej.

Każdą taką rozbieżność trzeba rozstrzygnąć decyzją człowieka — co obowiązuje — i poprawić w źródle. Nie da się tego obejść konfiguracją systemu.

Ujednolicenie nazewnictwa

Jeśli ta sama usługa występuje w dokumentach jako „wdrożenie", „instalacja" i „uruchomienie systemu", pytanie klienta o jedną z tych nazw znajdzie tylko część materiału.

Rozwiązania są dwa i warto zastosować oba. Pierwsze: ujednolicić nazwy w dokumentach źródłowych. Drugie: przygotować krótki słownik synonimów, który system uwzględni przy wyszukiwaniu — bo klienci i tak będą używać własnych określeń, niezależnie od tego, jak nazwiecie coś wewnętrznie.

Format plików

Nie każdy format nadaje się równie dobrze do przetwarzania.

• Tekst i dokumenty tekstowe — najlepsze. Struktura nagłówków jest czytelna, treść wyodrębnia się bez strat.
• PDF z warstwą tekstową — dobre, o ile układ nie jest wielokolumnowy. Kolumny bywają odczytywane w złej kolejności.
• PDF ze skanu — wymaga rozpoznania tekstu, z ryzykiem błędów. Lepiej odnaleźć oryginał.
• Arkusze kalkulacyjne — dobre dla danych tabelarycznych, słabe dla treści opisowej rozrzuconej po komórkach.
• Prezentacje — trudne. Treść jest fragmentaryczna i zależna od kontekstu wypowiedzi.
• Grafiki i zrzuty ekranu — bezużyteczne bez opisu tekstowego.

Uprawnienia i poufność

Baza wiedzy dziedziczy problem, który dokumenty miały wcześniej: nie wszystko jest dla wszystkich. Jeśli system odpowiada zarówno klientom, jak i pracownikom, musi rozróżniać, z których dokumentów może korzystać w danym kontekście.

• Oznacz poziom dostępu przy każdym dokumencie — publiczny, dla klientów, wewnętrzny.
• Sprawdź, czy w dokumentach nie ma danych osobowych — imion klientów w przykładach, adresów w wzorach pism.
• Wydziel warunki indywidualne. Cenniki i ustalenia dla konkretnych kontrahentów powinny pochodzić z systemu w kontekście zalogowanego użytkownika, nie z ogólnej bazy wiedzy.
• Ustal, co opuszcza firmę. Przy modelu działającym w chmurze treść trafia do zewnętrznego dostawcy.

Utrzymanie — bez tego baza starzeje się w miesiące

Dokumentacja przygotowana raz i pozostawiona bez opieki po pół roku zaczyna wprowadzać w błąd. Zmienia się oferta, terminy, procedury i przepisy.

• Właściciel bazy — osoba odpowiedzialna za aktualność. Bez tego nikt nie czuje się zobowiązany.
• Aktualizacja w procesie zmiany. Zmiana oferty powinna obejmować aktualizację dokumentu, a nie być osobnym zadaniem na później.
• Przegląd okresowy — kwartalny przy szybko zmieniającej się ofercie, roczny przy stabilnej.
• Rejestr pytań bez odpowiedzi. Gdy system nie znajduje odpowiedzi, zapisz pytanie — to gotowa lista braków w bazie.
• Usuwanie, nie tylko dodawanie. Wycofany dokument trzeba usunąć z bazy, nie zostawiać obok nowego.

Jak sprawdzić, czy baza jest dobra

Przygotuj zestaw kilkudziesięciu realnych pytań z prawidłowymi odpowiedziami — najlepiej takich, które faktycznie padają. Uruchom je przed wdrożeniem i po każdej większej aktualizacji bazy.

Patrz na trzy rzeczy: czy odpowiedź jest poprawna merytorycznie, czy wskazane źródło faktycznie ją zawiera oraz czy system przyznaje się do niewiedzy zamiast zmyślać. Ta trzecia właściwość jest najważniejsza i najczęściej niedostrzegana — system, który zawsze odpowiada, jest gorszy od takiego, który czasem mówi „nie znalazłem".

O tym, gdzie w ogóle warto zaczynać z takim projektem, pisaliśmy w materiale o wyborze pierwszego procesu, a o granicach zastosowania w obsłudze klienta.

Skąd brać treść, której nigdzie nie ma

Najcenniejsza wiedza w firmie zwykle nie istnieje w formie dokumentu. Siedzi w głowach osób, które od lat odpowiadają na te same pytania, i w korespondencji rozrzuconej po skrzynkach. To materiał, którego nie da się po prostu wyeksportować.

Wywiad z osobą obsługującą klientów

Godzina rozmowy z kimś, kto od lat odpowiada na zapytania, daje zwykle więcej niż przegląd całej dokumentacji. Warto zapytać wprost: o co pytają najczęściej, co jest źródłem nieporozumień, jakie odpowiedzi powtarzasz co tydzień, czego nie ma nigdzie zapisane, a wszyscy wiedzą.

Przegląd historii korespondencji

Nie po to, żeby wrzucić ją do bazy — zawiera dane osobowe i treści nieuporządkowane — lecz żeby wyłowić powtarzające się pytania i sposób, w jaki zespół na nie odpowiada. Efektem jest lista tematów wymagających spisania.

Rejestr pytań bez odpowiedzi

Po uruchomieniu systemu każde pytanie, na które nie znalazł odpowiedzi, warto zapisywać. Po miesiącu ta lista jest najlepszym możliwym planem rozbudowy bazy — opartym na realnych potrzebach, a nie na przypuszczeniach.

Podsumowanie

Baza wiedzy jest fundamentem, na którym stoi jakość całego wdrożenia — i jednocześnie etapem, który firmy najchętniej pomijają, bo nie wygląda na pracę nad sztuczną inteligencją. Tymczasem to właśnie tu rozstrzyga się, czy system będzie odpowiadał trafnie, czy przekonująco myliły.

Zacznij od czynności, która nie wymaga żadnej technologii: wypisz pięć pytań, które klienci zadają najczęściej, i sprawdź, czy odpowiedzi na nie są gdziekolwiek spisane w jednej, aktualnej wersji. Jeśli nie są — masz przed sobą pierwszy etap projektu, a przy okazji materiał przydatny zespołowi niezależnie od tego, czy wdrożenie w ogóle dojdzie do skutku.