Gotowość danych do RAG — checklista przed wdrożeniem AI

Wiele wdrożeń AI w firmach rozbija się nie o model, lecz o dane. Gotowość danych do RAG to stan, w którym Twoje dokumenty są kompletne, czyste, opisane uprawnieniami i aktualizowane — czyli nadają się na bazę wiedzy, z której AI odpowiada ze źródłem. Sam model rzadko jest przewagą; liczy się to, co mu podajesz. Tę checklistę — 25 pytań w sześciu obszarach — przejdź zanim zaczniesz budować, a nie kiedy prototyp już halucynuje.

Jeśli dopiero zastanawiasz się, czym jest RAG, zacznij od wpisu RAG na dokumentach firmy. Poniżej zakładamy, że wiesz, do czego służy, i pytasz: czy moje dane są na to gotowe.

1. Źródła i zakres

Zanim cokolwiek zindeksujesz, musisz wiedzieć, co indeksujesz i gdzie to leży.

Które dokumenty mają realnie odpowiadać na pytania? Regulaminy, procedury, oferty, dokumentacja techniczna — wypisz konkretne zbiory, nie „cała wiedza firmy”.
Gdzie te dokumenty fizycznie są? SharePoint, dysk sieciowy, e-mail, ERP, głowa jednej osoby — każde źródło to osobna integracja i osobne ryzyko.
Czy istnieje jedno źródło prawdy dla danego tematu? Jeśli ta sama procedura żyje w pięciu wersjach w pięciu miejscach, RAG zacytuje którąś — niekoniecznie obowiązującą.
Kto jest właścicielem każdego zbioru? Bez właściciela nikt nie odpowie, czy dokument jest aktualny ani czy wolno go cytować.
Co świadomie zostawiasz poza zakresem? Notatki robocze, stare wersje, prywatne foldery. Brak granicy oznacza, że model odpowie z czegoś, czego nie chcesz cytować.

Przed ewaluacją porównaj uzgodniony zestaw oczekiwanych dokumentów z przetworzonymi, odrzuconymi i częściowymi; potwierdź obecność przetworzonej treści w indeksie. Raport uzgodnienia jest dla uprawnionego właściciela zbioru lub administratora. Poniżej hipotetyczny przykład manifestu ingestii, bez danych ani wyników klientów.

Pole	Przykład
Dokument / wersja	DOC-C / v2
Wynik ingestii	Częściowy
Zakres pominięcia	Strony 4–5
Przyczyna	Niepełny OCR
Właściciel	Właściciel zbioru B

Świadome wyłączenie z zakresu nie jest błędem przetwarzania takim jak niepełny OCR; zapisz je osobno, poza zestawem oczekiwanym do ingestii. Filtr uprawnień (ACL) to prawidłowa granica dostępu, nie błąd ingestii. Nie ujawniaj użytkownikowi nazw ani identyfikatorów dokumentów poza jego uprawnieniami, także w takim manifeście.

Pokrycie ingestii i indeksu nie jest tym samym co retrieval top-k ani cytowania dla konkretnej odpowiedzi. Model nie widzi całej bazy: dostaje wybrane fragmenty dostępne dla danego użytkownika. Braki istotnych źródeł mogą zafałszować wyniki ewaluacji, nie muszą ich poprawiać. Przed akceptacją wyników ewaluacji właściciel zbioru musi jawnie zdecydować, czy uzupełnić braki i powtórzyć testy, czy zaakceptować ograniczony zakres z opisanym wpływem braków. Werdykt go/no-go pozostaje w Evidence Pack.

2. Uprawnienia i dane wrażliwe

To obszar, który najczęściej wywraca projekt po fakcie — i najtrudniej naprawić po wdrożeniu.

Kto może widzieć który dokument? RAG, który ignoruje uprawnienia, pokaże handlowcowi dane kadrowe. System pokaże to, co pipeline pozwoli mu pobrać.
Czy w dokumentach są dane osobowe lub tajemnice? PESEL, dane pacjentów, warunki kontraktów — to wpływa na ocenę ryzyka, podstawę przetwarzania, retencję, architekturę dostępu i klasyfikację systemu pod AI Act.
Czy masz podstawę przetwarzania i retencji dla danych osobowych? Włączenie dokumentu do bazy RAG to kolejny cel przetwarzania — musi mieć podstawę i określony okres przechowywania.
Czy potrafisz filtrować odpowiedzi per rola użytkownika? Jeśli nie, jedyną bezpieczną granicą jest zawęzić zakres bazy — zanim, nie po incydencie.
Gdzie dane zostają? W produkcyjnym RAG odpowiedź musi mieć źródło, a dane nie powinny trafiać do publicznych modeli ani do ich trenowania.

3. Jakość i struktura dokumentów

Model jest tak dobry, jak fragment, który dostanie. Śmieci na wejściu to śmieci w cytacie.

Czy dokumenty są tekstem, czy skanami? Skan bez warstwy tekstowej trzeba najpierw przepuścić przez OCR — inaczej dla RAG to obrazek bez treści.
Czy treść da się sensownie podzielić na fragmenty (chunking)? Tabele, formularze i 200-stronicowe PDF-y bez nagłówków tną się źle i gubią kontekst.
Czy w bazie są duplikaty i sprzeczności? Dwie wersje tej samej polityki, które mówią co innego, to gwarancja niespójnych odpowiedzi.
Czy dokumenty mają kontekst, czy zakładają wiedzę domyślną? Akronimy, wewnętrzne nazwy i „jak zwykle” są oczywiste dla zespołu, nie dla modelu.
Czy dokumenty są w językach, w których system ma odpowiadać? Baza po polsku i pytania po angielsku to częsta przyczyna pustych lub słabych trafień.

4. Aktualność i wersjonowanie

Baza wiedzy to nie zrzut z jednego dnia. Dane, które się nie odświeżają, starzeją się szybciej, niż myślisz.

Jak często zmienia się treść? Cennik co tydzień i regulamin raz na rok wymagają innego rytmu aktualizacji indeksu.
Kto i jak aktualizuje bazę po wdrożeniu? Bez właściciela procesu RAG zacytuje stan z dnia uruchomienia — w nieskończoność.
Czy widać datę i wersję dokumentu? Bez tego ani człowiek, ani model nie odróżni obowiązującej procedury od archiwalnej.
Jak wycofujesz dokument z indeksu, gdy traci ważność? Usunięcie pliku ze źródła to nie to samo co usunięcie go z bazy wektorowej — bez tego RAG dalej cytuje nieaktualne.

5. Testy i miary jakości

Bez testów „działa” jest przeczuciem, nie faktem. Tu nie wystarczy zbudować — trzeba zmierzyć.

Masz listę realnych pytań, na które system musi odpowiedzieć? To zalążek zestawu referencyjnego (golden set): pytanie, oczekiwana odpowiedź, źródło.
Co system ma robić, gdy nie zna odpowiedzi? Poprawna odmowa („nie wiem, sprawdź u…“) jest cechą jakości, nie awarią.
Kto oceni, czy odpowiedź jest trafna i ze źródła? Jak mierzyć jakość RAG opisujemy osobno: ewaluacja RAG. Tu chodzi o to, byś miał z czego ten test ułożyć.

6. Koszty i utrzymanie

Najdroższa część GenAI to zwykle nie inferencja, lecz inżynieria danych — a ona nie kończy się na wdrożeniu.

Kto utrzyma pipeline danych po starcie? Porządkowanie źródeł to praca ciągła, nie jednorazowy import.
Czy mierzysz koszt i jakość w czasie? Jak wygląda realny rachunek za GenAI na produkcji, pokazujemy na danych: ile kosztuje GenAI.
Czy zaczynasz od wycinka, czy od całości? PoC na jednym, dobrze uporządkowanym zbiorze powie Ci więcej niż indeks wszystkiego naraz.

W skrócie

Gotowość danych do RAG sprawdza się w sześciu obszarach: źródła i zakres, uprawnienia i dane wrażliwe, jakość i struktura dokumentów, aktualność i wersjonowanie, testy jakości oraz koszt i utrzymanie. Jeśli na większość pytań odpowiadasz „nie wiem”, to nie jest powód, by rezygnować z AI — to jest pierwszy etap projektu. Najtańszy moment, by to wykryć, jest przed budową, nie po.

Co dalej

Jak budujemy RAG na firmowych dokumentach — ze źródłami, na AWS — opisujemy na stronie RAG / bazy wiedzy. Porządkowanie danych (ETL) i baza wiedzy to u nas osobny etap wdrożenia, opisany w jak pracujemy. Jeśli nie wiesz, od czego zacząć — zacznij od audytu: przejdziemy tę checklistę na Twoich danych.