Jak przygotować firmową bazę wiedzy dla asystenta AI?

Firmową bazę wiedzy dla asystenta AI przygotuj w tej kolejności: wybierz jeden proces, wskaż obowiązujące dokumenty, rozstrzygnij sprzeczności i ustal dostęp. Dopiero później konfiguruj wyszukiwanie oraz sprawdzaj odpowiedzi. Większa liczba plików nie zastąpi aktualnych, jednoznacznych informacji.

Przed pilotażem potrzebujesz sześciu elementów: zakresu pytań, zatwierdzonych źródeł, rejestru dokumentów, matrycy dostępu, procedury aktualizacji i zestawu testów. Celem jest sprawdzenie, czy asystent nadaje się do konkretnego zadania, a nie uzyskanie obietnicy bezbłędności.

Zacznij od jednego zadania asystenta

„Asystent ma znać całą firmę” to zbyt szeroki punkt startowy. Trudno wtedy ustalić, które dokumenty są potrzebne i po czym poznać poprawną odpowiedź. Lepszy zakres pilotażu to na przykład odpowiadanie pracownikom na pytania o aktualne pakiety obsługi stron internetowych.

Zapisz krótki opis zadania. Powinien wskazywać użytkowników, temat pytań, granice odpowiedzialności i zachowanie przy braku informacji. W hipotetycznym przykładzie może wyglądać tak:

• Użytkownicy: pracownicy działu obsługi klienta.
• Zakres: zawartość pakietów, limity prac i sposób przekazania zgłoszenia.
• Poza zakresem: ustalanie indywidualnych rabatów i składanie zamówień.
• Brak danych: wskazanie brakującej informacji i osoby odpowiedzialnej za ofertę.

Zbierz też rzeczywiste pytania od przyszłych użytkowników. Firmowe dokumenty mogą opisywać „modyfikacje zawartości serwisu”, podczas gdy pracownik pyta „ile zmian tekstu ma klient?”. Te sformułowania warto później uwzględnić w testach.

Zrób spis źródeł i rozstrzygnij sprzeczności

Przejrzyj katalogi ofert, instrukcje, FAQ, procedury i prezentacje. Nie przesyłaj całego archiwum tylko dlatego, że jest dostępne. Każde źródło przypisz do jednej z trzech grup: obowiązujące, archiwalne albo wymagające rozstrzygnięcia. W aktywnej bazie powinny znaleźć się materiały dopuszczone do tego zastosowania.

Dla każdej grupy informacji wyznacz właściciela. To rola odpowiedzialna za treść, niekoniecznie osoba, która utworzyła plik. Właściciel oferty rozstrzyga zawartość pakietów, a właściciel procesu obsługi określa sposób przyjmowania zgłoszeń. Nie przekazuj modelowi odpowiedzialności za wybór obowiązujących zasad.

Przykład: dwa opisy tego samego pakietu

Załóżmy hipotetycznie, że aktualny katalog przewiduje dwie aktualizacje treści miesięcznie w pakiecie Standard, a stara prezentacja mówi o czterech. Przed wdrożeniem trzeba wskazać obowiązującą wersję i wyłączyć prezentację z aktywnego wyszukiwania. Sam dopisek „korzystaj z najnowszych danych” nie rozwiązuje problemu, jeśli dokumenty nie mają wiarygodnych dat.

Z tego konfliktu od razu powstaje test: „Czy w Standardzie mogę zlecić cztery aktualizacje?”. Oczekiwana odpowiedź ma podać aktualny limit i źródło, bez wymyślania wyjątków. Archiwum możesz zachować oddzielnie, ale nie powinno przypadkowo zasilać odpowiedzi o bieżącej ofercie.

Przygotuj dokumenty do wyszukiwania, nie do trenowania

Korzystanie z firmowych plików nie musi oznaczać trenowania modelu na ich zawartości. W mechanizmie RAG system najpierw wyszukuje fragmenty związane z pytaniem, a następnie przekazuje je modelowi do przygotowania odpowiedzi. Prosty schemat wygląda tak: pytanie → wyszukanie fragmentów → odpowiedź ze wskazaniem źródeł.

Przykładowo File Search w OpenAI Responses API łączy wyszukiwanie semantyczne i wyszukiwanie po słowach kluczowych. To przykład konkretnego narzędzia, nie wymóg wyboru tego dostawcy. Przygotowanie treści pozostaje ważne niezależnie od użytej technologii.

Dokumentacja OpenAI Retrieval opisuje automatyczne dzielenie plików na fragmenty, tworzenie ich reprezentacji i indeksowanie. Dlatego odpowiedź może powstawać na podstawie wybranych części dokumentu, a nie jego pełnej treści. Warunek zapisany kilkanaście stron dalej może nie trafić do tego samego zestawu wyników.

Przy redakcji materiałów stosuj kilka prostych zasad:

• Nadawaj sekcjom jednoznaczne nagłówki, na przykład „Pakiet Standard: zakres i limity”.
• Opisuj warunki i wyjątki blisko reguły, której dotyczą.
• Rozwijaj firmowe skróty i wyjaśniaj nazwy używane tylko wewnętrznie.
• Zastępuj niejasne odwołania typu „jak wyżej” konkretną informacją.
• Przy tabelach zachowuj nagłówki kolumn, jednostki i znaczenie pustych pól.

Sprawdź tekst faktycznie odczytany z pliku. Skan PDF może wymagać rozpoznania znaków, a tabela może po ekstrakcji połączyć limit jednego pakietu z nazwą innego. Wybierz kilka reprezentatywnych fragmentów i porównaj wynik z oryginałem. Samo poprawne przesłanie pliku nie potwierdza poprawnego odczytu.

Nie szukaj jednej idealnej długości fragmentu dla wszystkich materiałów. Krótkie FAQ i rozbudowana instrukcja mają inną strukturę. Ustawienia podziału należy oceniać na pytaniach testowych, zamiast dopasowywać całą dokumentację do arbitralnej liczby znaków.

Dodaj metadane i ustal dostęp

Metadane opisują dokument w sposób, który aplikacja może wykorzystać przy wyszukiwaniu i utrzymaniu bazy. Nazwa „oferta_final_poprawiona” nie wystarczy. Potrzebujesz stabilnego identyfikatora, informacji o wersji oraz zasadach udostępniania.

Poniższy rejestr jest propozycją organizacyjną. Nie stanowi obowiązkowego schematu żadnego dostawcy.

Pole	Co zapisać	Przykład hipotetyczny
Identyfikator	Stałe oznaczenie dokumentu	OFERTA-STANDARD
Właściciel	Rolę odpowiedzialną za treść	Opiekun oferty
Wersja i status	Numer oraz etap publikacji	3.0, obowiązujący
Data obowiązywania	Początek stosowania zasad	2026-11-01
Odbiorcy	Grupy z dostępem	Obsługa klienta
Źródło	Lokalizację oryginału	Rekord w firmowym repozytorium
Przegląd	Termin następnej kontroli	Przy zmianie oferty

File Search obsługuje filtrowanie według metadanych plików. Można je wykorzystać do zawężania wyników, ale bezpieczeństwo wymaga reguł po stronie aplikacji. To aplikacja powinna rozpoznać użytkownika i ograniczyć zakres wyszukiwania przed przekazaniem treści modelowi.

Nie polegaj wyłącznie na instrukcji „nie ujawniaj danych wewnętrznych”. Jeśli użytkownik nie ma dostępu do dokumentu, jego treść nie powinna trafiać do kontekstu odpowiedzi. Dotyczy to również podglądów źródeł, załączników i historii rozmowy. Sposób realizacji musi uwzględniać możliwości wybranej platformy.

Oddziel wiedzę od instrukcji asystenta

Dokument źródłowy opisuje ofertę lub procedurę. Instrukcja systemu określa, jak asystent ma odpowiadać. Te dwie warstwy przechowuj oddzielnie. W przeciwnym razie przypadkowa notatka, skopiowany e-mail albo treść obcego pliku może zostać potraktowana jak polecenie.

W regułach działania określ, że asystent ma wskazywać źródła, nie uzupełniać brakujących warunków domysłami i zgłaszać nierozstrzygnięte sprzeczności. Zapisz również, co robić, gdy pytanie jest niejednoznaczne: na przykład poprosić o nazwę pakietu, zamiast wybierać go samodzielnie.

Dokumentacja bezpieczeństwa OpenAI opisuje prompt injection, czyli próbę zmiany zachowania systemu przez instrukcje umieszczone w niezaufanej treści. Firmowy dokument również może zawierać taki tekst, choćby po skopiowaniu materiału z zewnątrz. Zabezpieczenia ograniczają ryzyko, ale go nie eliminują.

W kontrolowanym teście umieść w osobnym materiale próbę wymuszenia zignorowania zasad i ujawnienia informacji. Sprawdź nie tylko odpowiedź, lecz także to, do jakich danych system uzyskał dostęp. Sam spokojny ton odmowy nie dowodzi poprawnego działania uprawnień.

Zaplanuj aktualizacje i wycofywanie informacji

Baza wiedzy potrzebuje procedury publikacji podobnie jak firmowa oferta. Samo zapisanie nowej wersji na dysku nie oznacza, że asystent już ją wykorzystuje. Ustal, kto inicjuje zmianę, kto odpowiada za jej treść i kto sprawdza efekt techniczny.

Proponowany przebieg aktualizacji obejmuje:

1. Przygotowanie nowej wersji i wskazanie zmienionych zasad.
2. Potwierdzenie statusu dokumentu przez jego właściciela.
3. Dodanie pliku oraz metadanych do systemu.
4. Sprawdzenie zakończenia indeksowania.
5. Przełączenie aktywnej wersji i wyłączenie poprzedniej z wyszukiwania.
6. Uruchomienie testów dotyczących zmiany i wcześniejszych ważnych odpowiedzi.

Kolejność techniczna zależy od platformy. W OpenAI część operacji jest asynchroniczna, a po usunięciu pliku jego treść może jeszcze przez krótki czas pojawiać się w wynikach. Takie zachowanie opisuje dokumentacja Retrieval. Nie zakładaj więc natychmiastowego przełączenia wyłącznie na podstawie komunikatu o przyjęciu żądania.

Przy istotnej zmianie ustal sposób czasowego ograniczenia odpowiedzi: wyłączenie danego tematu, odseparowanie nowej wersji bazy albo skierowanie pytań do właściciela procesu. Zachowaj historię publikacji. Pozwoli ona ustalić, z jakiej wersji korzystał asystent w momencie zgłoszenia błędu.

Sprawdź osobno wyszukiwanie i odpowiedź

Test powinien odpowiadać na dwa różne pytania: czy system znalazł właściwy fragment oraz czy model wiernie go wykorzystał. Jeśli wyszukiwanie zwraca starą ofertę, poprawianie samej instrukcji odpowiedzi może nie usunąć przyczyny problemu.

File Search może zwracać odwołania do plików, a wyniki wyszukiwania można dołączyć do odpowiedzi API parametrem include, zgodnie z dokumentacją narzędzia. Sama nazwa dokumentu przy odpowiedzi nie jest jednak dowodem, że wszystkie zawarte w niej twierdzenia mają pokrycie w źródle.

Dla każdego przypadku testowego zapisz pytanie, rolę użytkownika, oczekiwane źródło, oczekiwaną odpowiedź lub odmowę oraz kryterium zaliczenia. Nie wymagaj identycznego brzmienia zdania. Wymagaj zgodności faktów, warunków i ograniczeń.

Rodzaj testu	Co sprawdzasz
Typowe pytanie	Poprawny fakt i właściwe źródło
Parafraza lub skrót	Rozpoznanie języka pracowników
Brak odpowiedzi w bazie	Przyznanie braku danych bez dopowiadania
Sprzeczne wersje	Użycie obowiązującej wersji albo zgłoszenie konfliktu
Brak uprawnień	Brak dostępu do chronionej treści i jej fragmentów
Polecenie w dokumencie	Traktowanie treści jako danych, nie instrukcji

W pilotażu raportuj błędy według przyczyny: dokument, wyszukiwanie, generowanie odpowiedzi lub dostęp. Taki podział pokazuje, co poprawić. Jeden ogólny wynik „poprawności” może ukryć poważny problem z uprawnieniami pod dużą liczbą łatwych, zaliczonych pytań.

Ustal warunki wstrzymania udostępnienia przed testami. Przykładowo wykryte ujawnienie informacji poza uprawnieniami powinno blokować dalsze udostępnianie do czasu poprawki i ponownego sprawdzenia. To propozycja zasady pilotażu, nie gwarancja wykrycia wszystkich zagrożeń.

Co przekazać wykonawcy przed pilotażem?

Przygotuj jeden pakiet startowy, zamiast przesyłać dokumenty w kilku wiadomościach bez kontekstu. Powinien zawierać:

• Opis jednego procesu, użytkowników i wyłączeń z zakresu.
• Zatwierdzony zestaw dokumentów bez przypadkowo dołączonego archiwum.
• Rejestr źródeł z właścicielami, wersjami i statusem.
• Matrycę dostępu dla grup użytkowników.
• Reguły odpowiedzi przy brakach i sprzecznościach.
• Procedurę aktualizacji oraz wycofywania informacji.
• Przypadki testowe i kryteria rozpoczęcia pilotażu.

W budżecie oddziel przygotowanie treści, integrację, testy i utrzymanie od opłat za model, wyszukiwanie czy przechowywanie danych. Bez znajomości liczby pytań, wielkości bazy i sposobu działania aplikacji nie da się rzetelnie wycenić całego rozwiązania.

Jeśli nie masz jeszcze rozstrzygniętego zakresu, konsultacja technologiczna może służyć uporządkowaniu wariantów i następnego kroku. W ramach rozwiązań AI i baz wiedzy punktem wyjścia może być ocena materiałów oraz przygotowanie ograniczonego pilotażu. Gotowość oznacza tu możliwość sprawdzenia konkretnego zadania na kontrolowanych danych, nie deklarację, że asystent poradzi sobie z każdym pytaniem.