Firmowa baza wiedzy dla asystenta AI: jak ją zbudować

0
52
Rate this post

Ostatnia aktualizacja: 2026-09-21

Definicja: Firmowa baza wiedzy dla asystenta AI to wybrany, uporządkowany i utrzymywany zbiór źródeł, z których system wyszukuje kontekst potrzebny do odpowiedzi.

Zacznij od jednego procesu i rzeczywistych pytań użytkowników. Następnie przygotuj wiarygodne źródła, ustaw granice odpowiedzi i przetestuj osobno wyszukiwanie oraz końcowe odpowiedzi.

  • Nie importuj całego archiwum bez selekcji i wskazania właścicieli dokumentów.
  • Oznacz wersję, okres obowiązywania i zakres dostępu do źródeł.
  • Ustal, co asystent robi, gdy nie znajduje wystarczających informacji.
Dobra baza wiedzy nie powstaje przez samo podłączenie plików do modelu. Trzeba określić, na jakie pytania system ma odpowiadać, wybrać właściwe materiały i wprowadzić zasady ich aktualizacji. Równie istotne są uprawnienia, testy oraz sposób postępowania w sytuacji, gdy wiedza jest niepełna albo sprzeczna.

Najbezpieczniejszym punktem wyjścia jest ograniczony przypadek użycia, który można przetestować na reprezentatywnych pytaniach. Zakres pilota powinien przy tym uwzględniać ryzyko i koszt błędnej odpowiedzi.

Czym jest baza wiedzy dla asystenta AI i gdzie działa RAG

Baza wiedzy nie jest zwykłym folderem z dokumentami. W architekturze RAG, czyli generowaniu wspomaganym wyszukiwaniem, asystent najpierw odnajduje odpowiednie fragmenty zewnętrznych źródeł, a następnie wykorzystuje je jako kontekst odpowiedzi.[5]

Dokumenty są więc materiałem wejściowym, a nie gotowym systemem odpowiedzi. Znaczenie ma cały łańcuch: jakość źródeł, przygotowanie treści, sposób wyszukiwania fragmentów i ich wykorzystanie przez model.[1][7] Nie można jednak przypisać konkretnej poprawy jakości jednemu z tych elementów bez testu przeprowadzonego na własnych danych.

Samo odnalezienie fragmentu nie gwarantuje poprawności odpowiedzi. System może pobrać właściwe źródło, ale błędnie je zinterpretować. Może też znaleźć materiał nieaktualny albo przeznaczony dla innej grupy użytkowników. Dlatego decyzję o narzędziu należy poprzedzić opisaniem problemu, zakresu pytań i źródeł, z których wolno korzystać.

Zacznij od jednego procesu i pytań, które mają otrzymać odpowiedź

Pierwsza wersja bazy powinna obejmować ograniczony proces lub grupę pytań, dla których można wskazać wiarygodne materiały, właściciela treści i sposób przeprowadzenia testu.[2][8] Zamiast importować całe archiwum, należy wybrać źródła potrzebne do obsługi tego właśnie zakresu.[1][3]

Kryteria dobrego przypadku użycia

Zakres pilota można opisać przez pytania, które rzeczywiście mają otrzymać odpowiedź. Każde pytanie powinno dać się połączyć z konkretnym źródłem oraz osobą odpowiedzialną za jego treść. Trzeba także określić, jakie pytania pozostają poza zakresem i kiedy odpowiedź ma zostać przekazana człowiekowi.

  1. Wybierz proces lub grupę pytań. Zakres powinien być wystarczająco ograniczony, aby można było przygotować reprezentatywny test.
  2. Zapisz typowe pytania. Nie zastępuj ich ogólną nazwą działu lub procesu.
  3. Przypisz źródła. Przy każdym pytaniu ustal, który obowiązujący materiał zawiera potrzebną informację.
  4. Wskaż właściciela treści. Musi być jasne, kto odpowiada za zatwierdzenie i późniejszą aktualizację dokumentu.
  5. Określ granice. Zapisz, które tematy i materiały nie należą do pierwszej wersji.
  6. Przygotuj warunki testu. Określ oczekiwane źródło, zakres odpowiedzi oraz sytuacje wymagające odmowy lub eskalacji.

Nie ma jednego zakresu odpowiedniego dla każdej organizacji. Wybór pilota powinien zależeć od dostępnych źródeł, możliwości przeprowadzenia testu oraz ryzyka związanego z błędną odpowiedzią.[9]

Materiały, których nie trzeba dodawać w pierwszej wersji

Poza pierwszą wersją mogą pozostać dokumenty, które nie odpowiadają na pytania objęte pilotem, nie mają ustalonego statusu albo nie powinny być dostępne dla jego użytkowników. Takie ograniczenie nie oznacza, że materiały są zbędne. Oddziela jedynie treści potrzebne teraz od tych, które można włączyć po rozszerzeniu zakresu i przygotowaniu odpowiednich testów.

Jeżeli kolejnym zastosowaniem ma być asystent AI w CRM, należy potraktować ten obszar jako osobny przypadek użycia i ponownie ustalić pytania, źródła, właścicieli oraz granice dostępu.

Przygotuj dokumenty tak, aby dało się ustalić ich treść, wersję i status

Przed importem trzeba sprawdzić, czy dokument jest czytelny, kompletny tekstowo i obowiązujący. Należy usunąć oczywiste duplikaty, skontrolować wynik OCR oraz dodać metadane pozwalające rozpoznać właściciela, wersję i datę obowiązywania.[1][4][8]

Dokładny zestaw metadanych zależy od używanego narzędzia, rodzaju materiałów i procesu firmy. OCR może przekształcić skan w tekst, ale nie potwierdza poprawności merytorycznej dokumentu. Podobnie indeksowanie nie rozstrzyga, która z kilku sprzecznych wersji powinna być używana.

Co sprawdzić przed indeksowaniem

  • Przydatność: dokument odpowiada na pytania należące do ustalonego zakresu.
  • Czytelność: treść jest dostępna jako tekst, a rezultat OCR został sprawdzony.
  • Kompletność: materiał nie jest przypadkowym fragmentem pozbawionym potrzebnego kontekstu.
  • Duplikaty: oczywiste kopie zostały usunięte lub właściwie rozróżnione.
  • Status: wiadomo, czy dokument obowiązuje, został zastąpiony czy oczekuje na zatwierdzenie.
  • Wersja: można odróżnić aktualny materiał od wcześniejszych wydań.
  • Właściciel: wskazano osobę lub rolę odpowiedzialną za treść.
  • Dostęp: określono, kto może korzystać z dokumentu.

Minimalne metadane dokumentu

Praktyczny zestaw opisowy obejmuje właściciela, wersję, datę obowiązywania, status publikacji i zakres dostępu. Informacje te pomagają ustalić, dlaczego asystent wykorzystał dany materiał, oraz umożliwiają wycofanie źródła, gdy przestaje obowiązywać.

Metadane nie naprawią jednak niejasnej albo błędnej treści. Jeśli dokument nie pozwala udzielić jednoznacznej odpowiedzi, powinien najpierw zostać zweryfikowany przez właściciela procesu. Dopiero później można oceniać sposób jego wyszukiwania.

Ustal granice odpowiedzi, eskalację i dostęp do wiedzy

Asystent powinien mieć określone tematy, na które odpowiada, oraz sposób działania przy braku wystarczającego źródła. Trzeba ustalić, kiedy prosi o doprecyzowanie, kiedy odmawia, a kiedy przekazuje sprawę człowiekowi.[2][6] Reguły te powinny wynikać z ryzyka i charakteru procesu, a nie z jednego uniwersalnego szablonu.

Trzy sytuacje, których nie należy mieszać

Brak wystarczającego źródła
Asystent nie ma podstaw do udzielenia odpowiedzi. Powinien poprosić o doprecyzowanie, odmówić albo skierować sprawę do odpowiedniej osoby, zgodnie z wcześniej ustaloną regułą.
Źródła są sprzeczne lub mają niejasny status
Problem dotyczy zarządzania treścią. Należy wskazać właściciela, ustalić obowiązującą wersję i wycofać materiał, który nie powinien być wykorzystywany.
Źródło istnieje, ale użytkownik nie ma dostępu
To problem uprawnień, a nie brak wiedzy. System nie powinien ujawniać treści spoza zakresu przypisanego do użytkownika.

Odmowa nie zastępuje poprawnego przygotowania dokumentów ani testowania. Jest jednym z zachowań potrzebnych wtedy, gdy odpowiedź nie może zostać bezpiecznie oparta na dostępnej wiedzy.

Dostęp użytkownika do źródeł i odpowiedzi

Przed wdrożeniem należy ustalić, kto może korzystać z poszczególnych zbiorów, a następnie sprawdzić, czy asystent nie ujawnia treści spoza uprawnień.[3][4][6] Konkretny model kontroli dostępu zależy od architektury, dostawcy i przyjętej klasyfikacji danych.

Test powinien zatem obejmować nie tylko poprawne odpowiedzi dla uprawnionego użytkownika. Musi również uwzględniać pytania o treści, których dana rola nie powinna otrzymać. Brak źródła i brak uprawnienia wymagają odrębnej diagnozy, nawet jeśli dla użytkownika kończą się brakiem odpowiedzi.

Testuj osobno wyszukiwanie źródeł i jakość odpowiedzi

Zestaw testowy powinien składać się z reprezentatywnych pytań pochodzących z rzeczywistej pracy. Dla każdego pytania należy osobno ocenić, czy system znalazł właściwe źródło, oraz czy końcowa odpowiedź wiernie wykorzystała jego treść.[6][7][8]

Rozdzielenie tych ocen pozwala odróżnić błąd źródła od błędu wyszukiwania lub generowania. Właściwy fragment może zostać źle zinterpretowany, a pozornie dobra odpowiedź nie musi oznaczać, że mechanizm wyszukiwania działa prawidłowo.

Jak zbudować zestaw pytań testowych

Przy każdym pytaniu trzeba zapisać oczekiwane źródło, dopuszczalny zakres odpowiedzi oraz warunek, przy którym asystent powinien poprosić o doprecyzowanie, odmówić lub przeprowadzić eskalację. Test powinien uwzględniać również materiały o różnych wersjach oraz treści dostępne wyłącznie dla określonych ról.

Wyniki pozostają miarodajne tylko w zakresie pytań i materiałów reprezentowanych w zestawie. Nie ma podstaw do przyjęcia jednego uniwersalnego progu gotowości dla wszystkich firm i procesów.

Jak interpretować nieudaną odpowiedź

Nietrafiona odpowiedź wymaga wskazania miejsca awarii. Jeśli właściwa informacja nie istnieje w źródłach, należy uzupełnić lub poprawić dokument. Jeśli istnieje, ale nie została odnaleziona, problem dotyczy wyszukiwania. Gdy system znalazł właściwy fragment, lecz użył go niezgodnie z treścią, trzeba analizować etap formułowania odpowiedzi. Osobnymi kategoriami pozostają przekroczenie zakresu i naruszenie reguł dostępu.

Taka diagnoza prowadzi do konkretnej decyzji naprawczej zamiast ogólnej oceny, że asystent działa dobrze albo źle.

Utrzymuj bazę tak samo jak proces, którego dotyczy

Baza wiedzy wymaga utrzymania po uruchomieniu. Dla dokumentów zmiennych trzeba wskazać właściciela, sposób publikacji nowej wersji i procedurę wycofania starej.[1][3] Częstotliwość przeglądów powinna zależeć od tempa zmian oraz ryzyka danego procesu.

Cykl życia dokumentu

Zmiana treści nie powinna kończyć się na dodaniu kolejnego pliku. Nowa wersja musi otrzymać właściwy status, a poprzednia powinna zostać wycofana z użycia zgodnie z przyjętą procedurą. Właściciel treści odpowiada za rozstrzygnięcie, który dokument obowiązuje; system techniczny nie powinien podejmować tej decyzji za organizację.

Jeśli zmienia się procedura, zakres usługi albo polityka dostępu, trzeba ponowić odpowiednie testy. Wcześniej poprawna odpowiedź może przestać być właściwa po zmianie źródła lub roli użytkownika.

Co monitorować po uruchomieniu

Bazę, wyszukiwanie i odpowiedzi należy traktować jako jeden system wymagający regularnej kontroli.[6][9] Monitoring powinien obejmować błędne odpowiedzi, nietrafione wyszukiwanie, odmowy, zmiany dokumentów oraz próby uzyskania treści spoza uprawnień. Nie ogranicza się więc do liczby przeprowadzonych rozmów.

Gotowość operacyjna nie oznacza braku wszystkich możliwych błędów. Oznacza istnienie sposobu ich wykrywania, przypisywania do właściwego etapu i naprawiania po wdrożeniu.

Najczęstsze pytania

Czy do bazy wiedzy trzeba dodać wszystkie dokumenty firmy?

Nie. Pierwsza wersja powinna zawierać materiały potrzebne do określonego procesu lub zestawu pytań. Pozostałe źródła można włączać po rozszerzeniu zakresu oraz przygotowaniu odpowiednich testów.

Czy RAG eliminuje błędne odpowiedzi asystenta?

Nie. RAG dostarcza modelowi zewnętrzny kontekst, ale samo wyszukanie fragmentów nie gwarantuje poprawności. Znaczenie mają również jakość źródeł, sposób wyszukiwania i wykorzystanie treści podczas formułowania odpowiedzi.

Jak często aktualizować bazę wiedzy?

Nie ma jednej częstotliwości odpowiedniej dla każdego wdrożenia. Przeglądy powinny zależeć od tempa zmian dokumentów i ryzyka procesu, a każda zmiana powinna mieć właściciela oraz procedurę wycofania poprzedniej wersji.

Źródła

  1. Jak przygotować firmową bazę wiedzy dla asystenta AI?, Kamil Pionkowski.
  2. Asystenci AI i firmowa baza wiedzy (RAG) – wdrożenie no-code dla MŚP, Klaster.
  3. Jak zbudować firmową bazę wiedzy AI, żeby pracownicy faktycznie z niej korzystali?, RedAI.
  4. Firmowa baza wiedzy jako aktywo: od folderów i maili do asystenta decyzyjnego?, Transformacje z AI.
  5. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, arXiv / NeurIPS.
  6. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, National Institute of Standards and Technology.
  7. EKRAG: Benchmark RAG for Enterprise Knowledge Question Answering, ACL Anthology.
  8. EnterpriseRAG-Bench: A RAG Benchmark for Company Internal Knowledge, arXiv.
  9. AI Risk Management Framework, National Institute of Standards and Technology.

Tematy związane z budową i wykorzystaniem asystentów AI w HubSpot rozwija Przemek Gliński — autor ebooka „Asystent AI w HubSpot” oraz HubSpot AI Platform Architect w BusinessWeb.

+Artykuł Sponsorowany+