Asystent AI lub system RAG w firmie: checklista zakresu

Większość rozczarowujących projektów asystentów AI nie zawodzi przez model. Zawodzą, bo nikt nie uzgodnił, do czego asystent ma służyć, treści źródłowe były niekompletne albo nieaktualne, o uprawnieniach pomyślano na końcu albo nie dało się stwierdzić, czy dana zmiana coś poprawiła, czy pogorszyła. Wybór modelu ma znaczenie, ale zwykle należy do łatwiejszych decyzji.

Ta checklista zbiera pytania, przez które przechodzimy przed budową systemu RAG (retrieval-augmented generation) albo asystenta AI na danych firmowych. Wykorzystaj ją, by przygotować projekt wewnętrzny, napisać brief dla dostawcy albo sprawdzić, czy otrzymana oferta obejmuje to, co najważniejsze. Nie musisz znać wszystkich odpowiedzi pierwszego dnia, ale warto wiedzieć, które pytania są jeszcze otwarte.

1. Przypadek użycia i kryteria sukcesu#

Zapisz to, zanim ktokolwiek otworzy notebook albo zacznie porównywać modele.

• Jedno główne zadanie. Nazwij to jedno zadanie, które asystent ma najpierw robić dobrze, na przykład odpowiadanie na pytania konsultantów wsparcia o produkt albo wyszukiwanie klauzul w umowach z dostawcami. Kolejne przypadki użycia mogą dojść, gdy pierwszy zostanie zmierzony; mieszanie kilku na starcie rozmywa zarówno wymagania, jak i ewaluację.
• Użytkownicy i ich sytuacja. Opisz, kto pyta, jak często, w jakim języku i na jakim urządzeniu oraz co robi z odpowiedzią. Wewnętrzny ekspert, który sprawdza źródła, potrzebuje czegoś innego niż klient, który od razu działa na podstawie odpowiedzi.
• Prawdziwe pytania z idealnymi odpowiedziami. Zbierz 20–50 prawdziwych pytań ze zgłoszeń, e-maili albo logów czatu i poproś eksperta dziedzinowego, by napisał idealną odpowiedź i wskazał źródło, z którego powinna pochodzić. Ten zestaw definiuje, co znaczy „dobrze”, i staje się zalążkiem Twojego zestawu ewaluacyjnego.
• Poza zakresem i odmowy. Wypisz, czego asystent nie może robić: udzielać porad prawnych, medycznych ani finansowych, odpowiadać poza swoimi źródłami, składać zobowiązań w imieniu firmy. Zdecyduj, co ma powiedzieć w zamian i dokąd skierować użytkownika.
• Punkt odniesienia: obecny proces. Zapisz, jak to zadanie jest wykonywane dziś, ile trwa, kto je wykonuje i ile kosztuje. Bez punktu odniesienia „asystent pomaga” jest opinią, a nie wynikiem.

2. Źródła danych#

Jakość odpowiedzi jest ograniczona jakością i dostępnością treści, które za nimi stoją.

• Inwentaryzacja źródeł. Wypisz każde źródło, z którego asystent ma korzystać: wiki, foldery SharePoint lub Google Drive, systemy zgłoszeń, bazy danych, PDF-y, strony internetowe. Przy każdym zanotuj, jak można uzyskać do niego dostęp (API, eksport, crawl) i czy taki dostęp jest dozwolony.
• Formaty i jakość dokumentów. Sprawdź, czy są skany PDF wymagające OCR, złożone tabele, formularze, slajdy i obrazy niosące istotną treść. To na tabelach i skanach naiwne pipeline’y gubią najwięcej informacji, więc zbadaj ich próbkę wcześnie.
• Właściciele i aktualność. Wskaż właściciela każdego źródła i zapisz, jak często się ono zmienia. Jeśli treść nie ma właściciela, nikt nie naprawi błędnych odpowiedzi, które z niej wynikają.
• Duplikaty, wersje i języki. Zidentyfikuj nieaktualne kopie, wersje robocze i równoległe wersje tej samej polityki i zdecyduj, która jest obowiązująca. Zanotuj języki zarówno dokumentów, jak i pytań, bo wyszukiwanie międzyjęzykowe trzeba przetestować osobno.

3. Kontrola dostępu i prywatność#

Ustal to, zanim jakiekolwiek prawdziwe dane opuszczą Twoje systemy.

• Uprawnienia przeniesione do retrievalu. Jeśli użytkownicy mogą widzieć tylko niektóre dokumenty, retrieval musi filtrować według uprawnień pytającego, synchronizowanych z systemów źródłowych. Instrukcje w prompcie albo wiara, że model sam zatai treść, to nie jest kontrola dostępu.
• Dane osobowe i podstawa prawna. Zidentyfikuj dane osobowe w dokumentach, pytaniach i logach oraz udokumentuj podstawę prawną i cel ich przetwarzania według RODO. Włącz inspektora ochrony danych na początku, a nie przy starcie produkcyjnym.
• Umowa z dostawcą i lokalizacja danych. Zawrzyj umowę powierzenia przetwarzania danych z każdym dostawcą modeli i infrastruktury, przejrzyj listę ich dalszych podmiotów przetwarzających (podprocesorów) i potwierdź, że przetwarzanie może pozostać w regionie UE, jeśli tego wymagasz. Uzyskaj pisemne potwierdzenie, że Twoje dane nie służą do trenowania modeli dostawcy.
• Retencja, logowanie i maskowanie danych. Zdecyduj, jak długo przechowywane są prompty, pobrane fragmenty i odpowiedzi, kto może je czytać i czy dane osobowe są maskowane przed zapisaniem do logów. Logi są potrzebne do debugowania i ewaluacji, więc celem jest kontrolowana retencja, a nie brak logów.

4. Projekt retrievalu#

Większość błędnych odpowiedzi w systemach RAG ma źródło w retrievalu, a nie w modelu; przy małym, stabilnym korpusie długi kontekst z prompt cachingiem może retrieval całkowicie zastąpić (zobacz RAG vs fine-tuning).

• Chunking zgodny ze strukturą dokumentu. Dziel treść według nagłówków, sekcji, punktów list i granic tabel, a nie według stałej liczby znaków. Do każdego chunka dołączaj ścieżkę nagłówków, żeby fragment miał sens także w oderwaniu od reszty.
• Metadane i filtry. Z każdym chunkiem przechowuj tytuł, źródło, sekcję, datę, język, wersję i grupy dostępu. To metadane umożliwiają filtrowanie po uprawnieniach, reguły „tylko najnowsza wersja” i użyteczne cytaty.
• Wyszukiwanie hybrydowe i reranking. Połącz wyszukiwanie po słowach kluczowych dla dokładnych terminów, takich jak kody produktów, numery artykułów i nazwy, z wyszukiwaniem wektorowym po embeddingach dla znaczenia, a potem zrób reranking połączonych kandydatów. Testuj każdy krok na swoich przykładowych pytaniach, zamiast zakładać, że ustawienia domyślne wystarczą.
• Cytaty obowiązkowe. Wymagaj, by asystent cytował fragmenty, z których skorzystał, z linkiem do dokumentu źródłowego i sekcji. Cytaty pozwalają użytkownikom weryfikować odpowiedzi, a recenzentom zobaczyć, czy błędna odpowiedź wynikła ze złego retrievalu, czy ze złej generacji.

5. Wybór modelu i dostawcy#

Model wybieraj wtedy, gdy masz już zestaw ewaluacyjny, tak by decyzja opierała się na Twoich danych, a nie na ogólnych benchmarkach.

• Opcja hostingu. Porównaj hostowane API, te same lub podobne modele w regionie chmurowym UE oraz samodzielnie hostowany model open-weight na własnej infrastrukturze. Każda opcja inaczej rozkłada akcenty między jakością odpowiedzi, kontrolą nad danymi, nakładem operacyjnym i kosztem.
• Opóźnienie i koszt zapytania. Zmierz na własnych przykładowych pytaniach całkowity czas odpowiedzi i koszt jednego obsłużonego pytania, wliczając retrieval, reranking oraz tokeny wejściowe i wyjściowe. Prompt caching i mniejsze modele do prostych kroków mogą te liczby znacząco zmienić.
• Fallback i lock-in. Zaplanuj, co się dzieje, gdy dostawca ma awarię albo wycofuje model: drugi dostawca, tryb ograniczony albo jasny komunikat o błędzie. Prompty, zestaw ewaluacyjny i warstwę retrievalu utrzymuj neutralne względem dostawcy, żeby zmiana była zmianą konfiguracji i jednym przebiegiem ewaluacji, a nie pisaniem od nowa.

6. Ewaluacja#

Jeśli nie potrafisz zmierzyć jakości, nie potrafisz jej poprawić ani obronić decyzji o uruchomieniu.

• Zestaw ewaluacyjny przed budową. Zamień prawdziwe pytania z sekcji 1 w wersjonowany zestaw ewaluacyjny z oczekiwanymi odpowiedziami i oczekiwanymi źródłami i rozszerz go o przypadki trudne i brzegowe. Zbuduj go przed pierwszym prototypem, a nie po pierwszym demo.
• Jakość retrievalu i odpowiedzi. Mierz osobno, czy pobrano właściwe fragmenty i czy odpowiedź jest poprawna, kompletna i wierna tym fragmentom. Sprawdź trafność cytatów: cytowany fragment musi faktycznie potwierdzać dane stwierdzenie.
• Testy odmów i prompt injection. Uwzględnij pytania, na które asystent musi odmówić odpowiedzi, oraz pytania, na które jego źródła nie odpowiadają, i sprawdź, czy mówi o tym wprost, zamiast zgadywać. Dodaj dokumenty i dane wejściowe, które próbują nadpisać jego instrukcje albo wyciągnąć dane innych użytkowników, i potwierdź, że te próby się nie udają.
• Przebiegi regresyjne i weryfikacja przez człowieka. Uruchamiaj pełny zestaw ewaluacyjny przy każdej zmianie promptów, modeli, chunkingu lub danych i porównuj wyniki z poprzednim przebiegiem. Automatyczne ocenianie modelem przyspiesza pracę, ale ekspert dziedzinowy powinien regularnie sprawdzać wyniki wyrywkowo.

7. Integracja i utrzymanie#

Asystent musi gdzieś mieszkać, a po starcie ktoś musi go utrzymywać.

• Kanał i logowanie. Zdecyduj, gdzie asystent będzie dostępny: widget na stronie, Slack albo Microsoft Teams, narzędzie wewnętrzne czy istniejący system zgłoszeń. Użyj swojego SSO, żeby tożsamość i uprawnienia pochodziły z tego samego miejsca co wszędzie indziej.
• Przekazanie człowiekowi i feedback. Określ, jak użytkownik dociera do człowieka, gdy asystent nie potrafi pomóc, razem z przekazaniem przebiegu rozmowy. Dodaj proste przyciski oceny i kieruj negatywny feedback do zestawu ewaluacyjnego.
• Model kosztów i monitoring. Oszacuj koszt zapytania i koszt miesięczny przy oczekiwanym i szczytowym użyciu oraz ustaw alerty budżetowe. Monitoruj opóźnienia, odsetek błędów, odsetek odmów i opinie użytkowników na logach z danymi zamaskowanymi zgodnie z ustaleniami z sekcji 3.
• Reindeksacja, odpowiedzialność za treści i incydenty. Zautomatyzuj reindeksację przy zmianach dokumentów źródłowych, łącznie z usunięciami, żeby asystent nigdy nie cytował wycofanych treści. Wskaż, kto naprawia problemy z treścią, i zdefiniuj proces obsługi incydentów na wypadek odpowiedzi błędnych, szkodliwych lub ujawniających dane, w tym sposób szybkiego wyłączenia asystenta.

8. Kryteria go/no-go#

Uzgodnij reguły decyzyjne, zanim spłyną wyniki, żeby decyzja nie zapadła pod wpływem udanego demo.

• Progi ustalone z góry. Zapisz minimalne poziomy poprawności odpowiedzi i trafności cytatów na zestawie ewaluacyjnym, akceptowalne opóźnienie i koszt zapytania oraz zero tolerancji dla odpowiedzi, które przekraczają granice uprawnień. Porównaj wyniki z punktem odniesienia z sekcji 1.
• Pilotaż ograniczony w czasie, z jasnym wyjściem. Przeprowadź pilotaż z małą grupą prawdziwych użytkowników przez ustalony okres, ze wskazaną osobą, która podejmuje decyzję. Zawężenie zakresu albo zatrzymanie projektu to pełnoprawny wynik, znacznie tańszy niż przekonanie się o tym po pełnym wdrożeniu.

Jak możemy pomóc#

Jeśli chcesz przejść tę checklistę razem z nami, najprostszą drogą jest nasz AI Proof-of-Value Sprint o stałym zakresie. W dwa tygodnie określamy z Tobą przypadek użycia, budujemy prototyp RAG albo agenta na Twoich własnych danych, tworzymy zestaw ewaluacyjny, przygotowujemy model kosztów i dostarczamy raport go/no-go, z którym możesz pójść do swoich decydentów. Szczegóły znajdziesz na stronie cennika i w opisie naszych usług AI i automatyzacji.

Zanim którykolwiek z Twoich dokumentów trafi do modelu, uzgadniamy z Tobą sposób postępowania z danymi; z góry możesz przeczytać, jak obchodzimy się z danymi klientów w projektach AI. Jeśli wolisz zacząć od rozmowy, poproś o bezpłatną wycenę i opisz przypadek użycia, który masz na myśli.