AI na danych firmy: jak zbudować bazę wiedzy, której można ufać?

Krótka odpowiedź

Bazie wiedzy z AI można ufać warunkowo: gdy odpowiada wyłącznie na podstawie wskazanych, aktualnych źródeł, pokazuje ich cytaty i respektuje uprawnienia osoby pytającej jeszcze przed pobraniem fragmentów dokumentów. Gdy nie znajduje wystarczającej podstawy albo źródła są sprzeczne, właściwą odpowiedzią systemu powinno być „nie wiem” lub przekazanie sprawy do właściciela wiedzy.

Nie chodzi o przekazanie modelowi wszystkich plików firmy ani o trwałe wprowadzanie ich treści do jego parametrów. Chodzi o zaprojektowanie kontrolowanej ścieżki: dokument jest przygotowany i opisany, system znajduje potrzebny fragment w chwili pytania, a odpowiedź wskazuje, skąd pochodzi informacja.

Czym jest RAG bez technicznego żargonu?

RAG to skrót od sposobu działania, w którym system najpierw odnajduje pasujące fragmenty firmowej wiedzy, a potem używa ich jako materiału do sformułowania odpowiedzi. Można myśleć o nim jak o dobrze zorganizowanej czytelni: zanim asystent odpowie, ma wyszukać właściwy regulamin, instrukcję albo procedurę i położyć ją na biurku obok pytania.

To ważna różnica. Sam model językowy potrafi ułożyć płynną odpowiedź, ale nie jest firmowym rejestrem źródeł ani nie wie sam z siebie, który dokument został wczoraj zastąpiony nową wersją. W podejściu RAG system łączy pytanie z aktualnie dostępną bazą; odpowiedź ma wynikać z odnalezionych fragmentów, nie z domysłu.

Artykuł Lewisa i współautorów opisuje tę klasę rozwiązań jako połączenie modelu z zewnętrzną pamięcią przeszukiwaną podczas generowania odpowiedzi. W praktyce warto zachować jego prostą ideę: wiedza pozostaje w zarządzanych źródłach, a system powinien wskazać fragment, na którym się oparł.

RAG nie gwarantuje prawdziwości. Może pobrać niewłaściwy fragment, pominąć ważny wyjątek, źle zinterpretować tabelę albo otrzymać nieaktualny dokument. Dlatego zaufanie buduje się w całym przepływie informacji, a nie samym wyborem modelu.

Mapa od dokumentu do odpowiedzi z cytatem

Praktyczna architektura bazy wiedzy powinna być zrozumiała dla właściciela procesu, zespołu IT i osoby odpowiedzialnej za dokument. Jej minimalny przebieg można opisać tak:

źródło → pobranie i przygotowanie → podział → indeks → wyszukiwanie fragmentów → odpowiedź z cytatem

1. Źródło. Firma świadomie wskazuje, które repozytoria i dokumenty mogą zasilać bazę: na przykład zatwierdzone procedury, instrukcje produktowe lub polityki. Każdy dokument powinien mieć identyfikator, właściciela, odbiorców, status oraz informację o wersji i dacie obowiązywania.
2. Pobranie i przygotowanie dokumentów (ingest). System pobiera dozwolone treści i zapisuje ich metadane. Na tym etapie warto wykryć duplikaty, dokumenty bez właściciela, brak daty oraz pliki, których tekst odczytał się niepełnie. Błąd podczas tego etapu nie może po cichu tworzyć pozornie kompletnej bazy.
3. Podział. Długi dokument dzieli się na mniejsze fragmenty, które zachowują kontekst: tytuł, sekcję, numer wersji i link do oryginału. Fragment z samą tabelą lub zdaniem wyrwanym z warunku może dać mylącą odpowiedź, dlatego podział powinien uwzględniać strukturę dokumentu.
4. Indeks. Fragmenty trafiają do katalogu, który pozwala znaleźć materiał podobny znaczeniowo do pytania. Indeks ma zawierać także metadane potrzebne do sprawdzenia uprawnień, aktualności i pochodzenia.
5. Wyszukiwanie fragmentów (retrieval). Najpierw system filtruje katalog według tożsamości oraz uprawnień pytającego, a dopiero później szuka pasujących fragmentów w pozostałym zbiorze. To kluczowe: filtrowanie dostępu po pobraniu dokumentu jest za późno, bo treść mogła już wpłynąć na odpowiedź.
6. Odpowiedź z cytatem. Model dostaje pytanie oraz wybrane fragmenty i ma odpowiedzieć w granicach tego materiału. Przy każdej istotnej informacji użytkownik powinien zobaczyć nazwę źródła, sekcję lub link oraz wersję, aby mógł sprawdzić kontekst.

Tak zbudowana ścieżka ułatwia znalezienie miejsca błędu. Gdy odpowiedź jest niepoprawna, zespół może sprawdzić: czy dokument był właściwy, czy system właściwie go pobrał i przygotował, czy fragment zachował warunek, czy filtr dostępu zadziałał, czy wyszukiwanie wybrało dobrą podstawę i czy model nie dodał twierdzenia bez cytatu.

Warstwy bazy wiedzy: ryzyko i kontrola

Poniższa tabela nie jest listą certyfikacyjną. Ma pomóc ustalić, co trzeba sprawdzić przed udostępnieniem systemu szerokiej grupie użytkowników.

NIST AI RMF traktuje zarządzanie ryzykiem jako ciągłe działanie: ustanowienie odpowiedzialności, opis kontekstu, pomiar oraz zarządzanie ryzykiem. W bazie wiedzy przekłada się to na jasnego właściciela dokumentów, rozpoznanie odbiorców i konsekwencji błędu, testowanie odpowiedzi oraz reagowanie na problemy po wdrożeniu.

Uprawnienia i aktualność nie są dodatkiem do jakości

Cytat buduje zaufanie tylko wtedy, gdy użytkownik ma prawo zobaczyć cytowane źródło. Dlatego uprawnienia trzeba przenieść do mechanizmu wyszukiwania, nie ograniczać się do ukrycia linku w interfejsie. Kto widzi wyłącznie materiały działu serwisu, temu system powinien przeszukiwać wyłącznie tę część wiedzy. Uprawnienie do pytania nie oznacza automatycznie dostępu do wszystkich dokumentów firmowych.

To także kwestia bezpieczeństwa. OWASP opisuje ryzyko wycieku między kontekstami oraz manipulacji treścią w mechanizmach wektorowych. Dla bazy wiedzy oznacza to zasadę najmniejszego dostępu: komponent wyszukiwania ma odczytywać tylko potrzebne źródła, a interfejs odpowiadania nie potrzebuje prawa do edycji, eksportu całego repozytorium ani wywoływania otwartych poleceń.

Aktualność wymaga decyzji organizacyjnej, nie tylko daty w nazwie pliku. Właściciel dokumentu powinien określić, czy dana wersja jest obowiązująca, do kiedy może być używana i co ma się stać po zmianie. Czasem właściwe jest natychmiastowe wykluczenie starej wersji z odpowiedzi, czasem zachowanie jej wyłącznie dla uprawnionych osób, które analizują historię. System powinien pokazać tę różnicę, a nie mieszać wersje w jednej odpowiedzi.

Jak projektować odpowiedź „nie wiem”?

„Nie wiem” nie jest porażką interfejsu. To kontrolowany wynik, który chroni użytkownika przed płynną, lecz nieudokumentowaną odpowiedzią. System powinien wybrać go co najmniej w czterech sytuacjach:

• nie znalazł źródła, które bezpośrednio odpowiada na pytanie;
• znalazł źródła sprzeczne lub różne wersje bez rozstrzygnięcia;
• pytanie wykracza poza zakres dostępnych użytkownikowi dokumentów;
• źródło jest oznaczone jako nieaktualne, w trakcie przeglądu albo bez właściciela.

Dobra odpowiedź nie kończy się samym komunikatem. Może wskazać, czego brakuje: „Nie znajduję zatwierdzonej procedury dla tej sytuacji. Właścicielem obszaru jest wskazany zespół; przekaż pytanie do jego kolejki.” Nie powinna natomiast ujawniać tytułu ani treści dokumentu, do którego pytający nie ma dostępu.

Testy, które pokazują jakość przed i po uruchomieniu

Zanim baza będzie dostępna, przygotuj zestaw pytań od osób, które znają proces. Nie chodzi o losową listę ciekawostek, lecz o przypadki odzwierciedlające rzeczywiste decyzje i granice dostępu.

Zestaw powinien zawierać pytania z jednoznaczną odpowiedzią i wskazanym źródłem, pytania wymagające przeczytania wyjątku, pytania dotyczące najnowszej wersji, pytania bez odpowiedzi oraz pytania osoby bez dostępu do danego obszaru. Dodaj też pytania sformułowane nieprecyzyjnie, by sprawdzić, czy system poprosi o doprecyzowanie zamiast dopowiadać.

Dla każdego pytania zapisz oczekiwany rezultat i oceniaj co najmniej:

• poprawność merytoryczną odpowiedzi względem zatwierdzonego źródła;
• trafność cytatu, czyli czy cytowana sekcja rzeczywiście wspiera twierdzenie;
• kompletność, czyli czy odpowiedź nie pominęła warunku istotnego dla decyzji;
• właściwą odmowę, gdy pytanie nie ma podstawy, wykracza poza zakres lub dotyczy niedostępnej treści;
• przestrzeganie uprawnień, w tym brak śladów źródeł spoza zakresu użytkownika;
• aktualność, czyli użycie obowiązującej wersji dokumentu.

Nie ma uniwersalnego progu, który sam uczyni rozwiązanie bezpiecznym. Właściciel procesu powinien z góry ustalić, które błędy są niedopuszczalne, kto ocenia próbę i co dzieje się po wykryciu regresji. Należy ponownie uruchamiać ten sam zestaw po zmianie źródła, logiki pobierania, modelu lub polityki dostępu. Sam zestaw testowy to jednak dopiero jeden z warunków, które oddzielają udany test od systemu gotowego na produkcję.

Hipotetyczny przykład: pytania o procedurę serwisową

Wyobraźmy sobie firmę, która udostępnia pracownikom bazę zatwierdzonych procedur serwisowych. Dokument „Przyjęcie zgłoszenia” ma właściciela, wersję i datę obowiązywania; system dzieli go według sekcji, a pracownik działu serwisu ma dostęp tylko do procedur swojej roli.

Na pytanie „Jak oznaczyć zgłoszenie bez numeru urządzenia?” system znajduje sekcję o brakujących danych, przytacza ją i linkuje do wersji dokumentu. Jeśli pytanie dotyczy wyjątku, którego procedura nie opisuje, odpowiedź brzmi „nie wiem” i wskazuje właściwą kolejkę. Gdy to samo pytanie zada osoba bez dostępu do procedur serwisowych, system nie wyszukuje tej treści i nie zdradza jej istnienia.

To hipotetyczny scenariusz projektowy, nie opis klienta, wdrożenia ani wyniku Aether Solutions. Jego celem jest pokazanie, że jakość odpowiedzi zależy równie mocno od właścicieli, wersji i uprawnień jak od samego wyszukiwania.

Kiedy baza wiedzy z AI nie ma sensu?

Nie zaczynaj od RAG, gdy nie ma wiarygodnych źródeł, a kluczowa wiedza istnieje wyłącznie w pamięci kilku osób. Najpierw trzeba ustalić procedury, właścicieli i cykl aktualizacji; system nie rozwiąże braku uzgodnionej odpowiedzi. Podobnie, gdy pytania są rzadkie i zawsze wymagają indywidualnej oceny eksperta, prostszy katalog dokumentów albo bezpośrednia konsultacja mogą być lepsze.

Rozwiązanie nie jest też właściwą drogą do podejmowania decyzji transakcyjnych, automatycznego zapisu w CRM lub ERP ani zastępowania procesu akceptacji. Ten artykuł dotyczy odczytu i wyjaśniania firmowej wiedzy. Gdy potrzebne są działania w systemach, trzeba osobno zaprojektować odczyt, walidację i zapis w CRM lub ERP, a razem z nimi uprawnienia, punkty akceptacji i odpowiedzialność.

Jeśli firma nie może utrzymać dostępu według ról, wersji dokumentów oraz minimalnego testowego zestawu pytań, lepiej zmniejszyć zakres do jednej, dobrze zarządzanej kolekcji niż otwierać całą przestrzeń plików.

Co zrobić dalej

Wybierz jeden obszar wiedzy, na przykład procedury obsługi zgłoszeń, i przygotuj jego inwentarz: dokument, właściciel, odbiorcy, wersja, status, data przeglądu oraz zasady dostępu. Następnie zbierz pytania testowe wraz z oczekiwanymi cytatami i przykładami, w których odpowiedź ma brzmieć „nie wiem”. Taka karta pozwoli ocenić, czy warto budować ograniczoną bazę wiedzy z AI. Jeśli potrzebujesz pomocy w zmapowaniu źródeł i ryzyk, zobacz usługi Aether lub skontaktuj się z zespołem.

Źródła i metodologia

• Patrick Lewis i współautorzy, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, arXiv, pierwsza wersja 22 maja 2020, https://arxiv.org/abs/2005.11401. Źródło pojęcia retrieval-augmented generation i pracy z zewnętrzną, przeszukiwaną pamięcią.
• National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 26 stycznia 2023, https://www.nist.gov/itl/ai-risk-management-framework. Wykorzystano jako podstawę opisu ciągłego zarządzania ryzykiem i odpowiedzialności.
• OWASP Foundation, LLM08:2025 Vector and Embedding Weaknesses, 2025, https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/. Wykorzystano dla opisu ryzyka wycieku między kontekstami oraz manipulacji treścią w mechanizmach wektorowych.

Mapa, tabela, zestaw pytań oraz przykład są autorską metodą projektową. Nie opisują danych, wdrożeń ani wyników Aether Solutions.