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ć.

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.