Deduplikacja i czyszczenie danych pod AI w 2026 roku

Firma łączy trzy systemy: Confluence, SharePoint i starą bazę FAQ w Excelu. Po pierwszym indeksowaniu RAG odpowiada niekonkretnie albo cytuje sprzeczne procedury. Nie ma błędu w modelu ani w konfiguracji Qdrant. Problem jest wcześniej: te same dokumenty pojawiły się w indeksie kilka razy, w nieznacznie różnych wersjach, i teraz każda wersja rywalizuje o to samo miejsce w wynikach wyszukiwania.

Deduplikacja i czyszczenie danych to praca, która dzieje się przed indeksowaniem, nie po nim. Kiedy jest pominięta, objawy wychodzą stopniowo: asystent odpowiada niespójnie, koszty tokenów rosną, a metryki jakości nie poprawiają się mimo tuningu promptów.

RAG działa na zasadzie rankingu: system pobiera fragmenty, które najbardziej pasują semantycznie do zapytania, i podaje je modelowi jako kontekst. Jeśli w indeksie jest pięć wersji tej samej procedury, trzy z nich trafiają do kontekstu zamiast trzech różnych, uzupełniających się dokumentów. Model dostaje mniej informacji niż mógłby dostać z czystego korpusu.

Duplikaty generują też konkretny koszt. Każdy fragment zajmuje tokeny w oknie kontekstowym. Przy limitach 8 000 lub 128 000 tokenów powtarzające się treści to zmarnowana przestrzeń, za którą płacisz lub która ogranicza, co model może jednocześnie przeanalizować.

Trzeci efekt to sprzeczność. Wersja procedury z 2022 roku i wersja z 2024 roku mogą opisywać ten sam krok inaczej. Model nie wie, która jest aktualna, i cytuje obie albo arbitralnie wybiera. Z zewnątrz wygląda to jak „halucynacja”, ale przyczyną jest baza wiedzy, nie model.

My w Cashcrown obserwujemy, że w projektach, gdzie klienci przychodzą z nieuporządkowanymi korpusami, znaczna część pracy przygotowawczej spada właśnie na deduplikację, a nie na konfigurację modelu. Nie podamy Ci liczbowo, ile to poprawia jakość odpowiedzi, bo to zależy od stanu konkretnych danych. Wiesz, że masz problem, gdy metryki faithfulness i relevance nie rosną mimo zmian w promptach.

Nie ma jednej metody, która wykrywa wszystkie typy duplikatów. W praktyce stosuje się trzy warstwy, uruchamiane kolejno, bo każda następna jest droższa obliczeniowo.

Warstwa 1: dokładne dopasowanie (exact match). Liczy się hash SHA-256 lub MD5 całego dokumentu albo jego fragmentu po normalizacji (lowercase, usunięcie białych znaków). Jeśli dwa pliki mają identyczny hash, jeden trafia do kosza bez dalszej analizy. To najszybsza warstwa, zero kosztu LLM. Sprawdza się przy plikach kopiowanych między folderami lub synchronizowanych przez dwie integracje naraz.

Warstwa 2: rozmyte dopasowanie (fuzzy match). Algorytmy takie jak odległość Levenshteina, podobieństwo Jaccarda na n-gramach lub MinHash wykrywają dokumenty, które różnią się nieznacznie: jeden akapit dodany, literówka poprawiona, formatowanie zmienione. Próg podobieństwa ustala się empirycznie, typowo Jaccard powyżej 0,85-0,90 sugeruje duplikat kandydat. Decyzja o scaleniu lub odrzuceniu pozostaje do potwierdzenia przez człowieka.

Warstwa 3: semantyczna detekcja (embedding-based). Generujesz embeddingi dla każdego fragmentu i mierzysz podobieństwo cosinusowe. Fragmenty z podobieństwem powyżej progu (typowo 0,92-0,95, kalibrowanego na złotym zestawie testowym) są kandydatami do scalenia. Ta warstwa wyłapuje przypadki, gdzie dwa dokumenty mówią to samo inaczej: zmieniona terminologia, inne tłumaczenie, przepisana procedura o tym samym znaczeniu. Szczegóły o podobieństwie wektorowym w artykule wyszukiwanie semantyczne i embeddingi w firmie.

Każda wyższa warstwa wymaga droższej weryfikacji. Dlatego sekwencja ma sens: najpierw filtruj tym, co jest tanie, a semantykę stosuj tylko tam, gdzie dwie poprzednie warstwy nie dały jasnej odpowiedzi.

Deduplikacja bez wcześniejszej normalizacji generuje fałszywe rozróżnienia. Ten sam dokument zapisany raz jako PROCEDURA_v3_final.docx i raz jako procedura v3 final.docx ma inne hashe. Normalizacja tekstu usuwa te pozorne różnice przed porównaniem.

Normalizacja powinna być deterministyczna i odwracalna na potrzeby audytu: nie nadpisujesz oryginałów, piszesz do osobnego pipeline'u przygotowującego dane do indeksowania. Oryginały zostają w źródle bez zmian.

Bliski duplikat (near-duplicate) to problem trudniejszy niż identyczny duplikat, bo jest bardziej niewidoczny. Dwa fragmenty proceduralnego dokumentu, które różnią się jednym akapitem o szczególnym przypadku, mogą wyglądać jak duplikaty, a być komplementarne.

Przy wyszukiwaniu semantycznym bliskie duplikaty zaburzają ranking w specyficzny sposób: fragment A i jego prawie identyczna kopia B wzmacniają się nawzajem w wynikach, bo wyszukiwarka uznaje, że temat jest „dobrze reprezentowany”. Inne, mniej powtarzające się treści spadają w rankingu, choć mogłyby być bardziej przydatne.

Praktyczne podejście do bliskich duplikatów w korpusie RAG:

• Grupuj kandydatów według podobieństwa semantycznego (klastry z embeddingow).
• Dla każdej grupy: zatrzymaj wersję z najnowszą datą modyfikacji lub z kompletniejszą treścią.
• Wersje starsze przenieś do archiwum, nie do aktywnego indeksu.
• Wersje, których relacja jest niejasna (np. różnią się kluczowym szczegółem technicznym), oznacz do ręcznego przeglądu.

Próg semantyczny dla bliskich duplikatów ustawia się zwykle niżej niż dla identycznych, bo chcesz być konserwatywny: lepiej oznaczyć kandydata do przeglądu niż automatycznie scalić dwa dokumenty, które okazują się mieć ważne różnice.

Czyszczenie danych pod AI to nie tylko deduplikacja. Równolegle musi przebiec detekcja i obsługa danych osobowych (PII) w każdym dokumencie przed indeksowaniem.

Typowe typy PII w korpusach firmowych: imiona i nazwiska klientów, adresy e-mail, numery telefonów, numery PESEL i NIP, adresy zamieszkania, numery zamówień z powiązaniem do osoby, identyfikatory sesji. Wszystkie są objęte RODO i wymagają podstawy prawnej przetwarzania, minimalizacji oraz obsługi prawa do usunięcia.

W praktyce masz trzy ścieżki:

Maskowanie przed indeksowaniem. PII jest zastępowane tokenem ([EMAIL_1], [PESEL_1]) jeszcze w pipeline przygotowania danych, przed wygenerowaniem embeddingów. Do indeksu trafia tekst z tokenami, nie z prawdziwymi wartościami. Szczegółowa architektura maskowalnia w artykule anonimizacja i maskowanie PII przed AI.

Wykluczenie dokumentu z indeksu. Jeśli dokument zawiera PII niezbędne do jego sensu i nie można go zanonimizować bez utraty wartości (np. transkrypcja rozmowy z klientem), nie trafia do głównego indeksu. Może trafić do dedykowanej kolekcji z kontrolą dostępu i ścisłą podstawą prawną.

Ekstrakcja danych i anonimizacja statystyczna. Dla dokumentów służących do analizy (raporty, ankiety) można wyekstrahować agregaty zamiast danych jednostkowych. Model pracuje wtedy na statystykach, nie na danych personalnych.

Narzędzia do automatycznej detekcji PII w polskich tekstach: Microsoft Presidio (z modelem NER dla polskiego), spaCy z modelem pl_core_news_lg, reguły regex dla wzorców PESEL/NIP/telefonu. Żadne z nich nie daje 100 procent recall na surowych danych firmowych, szczególnie przy nazwach własnych, które wyglądają jak tekst ogólny. Dlatego automatyczna detekcja PII jest pierwszym krokiem, a nie jedynym, zwłaszcza przy danych osobowych szczególnych kategorii (art. 9 RODO).

Więcej o przygotowaniu danych pod kątem RODO i AI Act w artykule jak przygotować dane firmowe pod AI.

Automatyzacja przyspiesza deduplikację i czyszczenie, ale nie eliminuje potrzeby ludzkiej decyzji. Istnieje kilka punktów, gdzie automatyczne działanie jest niedopuszczalne lub zbyt ryzykowne.

Scalanie rekordów klientów w CRM. Algorytm rozmytego dopasowania może znaleźć, że „Jan Kowalski, ul. Lipowa 5” i „Jan Kowalski, ul. Lipowa 5a” to prawdopodobnie ta sama osoba. Prawdopodobnie, nie na pewno. Połączenie historii zamówień, kontaktów i wycen dwóch różnych klientów o podobnych danych to błąd z realną konsekwencją biznesową i prawną (RODO wymaga dokładności danych). Automatyzacja proponuje kandydatów do scalenia, człowiek zatwierdza lub odrzuca każdy przypadek.

Usuwanie wersji dokumentów. Starsza wersja procedury może być potrzebna jako dowód w razie audytu lub reklamacji. Automatyczne usunięcie „starszej wersji duplikatu” może skasować materiał, który firma jest zobowiązana zachować. Archiwizuj, nie usuwaj, a decyzję o fizycznym usunięciu powierzaj osobie, która zna kontekst prawny dokumentu.

Dane wrażliwe z AI Act. Przy dokumentach w obszarach wysokiego ryzyka (HR, ocena kredytowa, systemy rekrutacyjne) każda zmiana w zbiorze danych treningowych lub indeksowanym wymaga udokumentowania i zatwierdzenia przez człowieka, zgodnie z wymaganiami art. 10 AI Act (jakość danych i zarządzanie). Automatyczna deduplikacja bez śladu audytowego jest tu niezgodna z wymogami.

Granica pewności semantycznej. Jeśli dwa fragmenty mają podobieństwo wektorowe między 0,85 a 0,92 (strefa szara), model semantyczny nie jest wystarczająco pewny, żeby zdecydować samodzielnie. Takie pary trafiają do kolejki manualnej weryfikacji. Próg ten kalibruje się raz na złotym zestawie przykładów przed uruchomieniem pipeline'u.

Wzorzec, który stosujemy: automatyzacja proponuje, lista decyzyjna trafia do osoby odpowiedzialnej za daną bazę danych, decyzja jest logowana z datą i uzasadnieniem. Więcej o zarządzaniu decyzjami na zbiorach danych w artykule governance danych do AI.

Normalizacja usuwa pozorne różnice w reprezentacji tego samego tekstu: zmiana wielkości liter, spacje, kodowanie Unicode znaków diakrytycznych. Deduplikacja wykrywa i obsługuje rzeczywiste powtórzenia treści na trzech poziomach: identyczne, rozmyte i semantyczne. Bez normalizacji ten sam dokument w dwóch kodowaniach może nie zostać rozpoznany jako duplikat przez hash, więc normalizacja jest zawsze krokiem pierwszym.

Próg kalibruje się empirycznie: przygotuj 100-200 par dokumentów z ręcznym oznaczeniem „duplikat / nie-duplikat”, uruchom model embeddingów i zmierz precision i recall przy różnych wartościach. Typowy punkt startowy to cosine similarity 0,92-0,95 dla krótkich fragmentów, niższy dla dłuższych dokumentów. Wybierz próg minimalizujący fałszywe scalenia, bo scalenie dwóch różnych rekordów jest trudniejsze do odwrócenia niż pozostawienie kandydata do ręcznego przeglądu.

Przy małych, jednorodnych bazach (kilkaset dokumentów z jednego źródła) duplikaty są rzadkie i wpływ na jakość jest mały. Przy bazach powyżej kilku tysięcy dokumentów z wielu systemów (CRM, SharePoint, Confluence, e-maile) duplikaty pojawiają się niemal zawsze, bo te same informacje krążą w wielu miejscach. Oznaka, że deduplikacja jest potrzebna: identyczne pytania testowe dostają różne odpowiedzi przy kolejnych uruchomieniach, albo asystent cytuje sprzeczne procedury w tej samej odpowiedzi.

Żądanie usunięcia dotyczy wszystkich miejsc z danymi osoby, w tym indeksu wektorowego. Fragmenty zbudowane na dokumentach z PII tej osoby muszą być usunięte. Pipeline deduplikacji powinien przechowywać mapę proweniencji: który fragment pochodzi z którego dokumentu źródłowego. Bez niej nie da się wykonać kompletnego usunięcia. Jeśli fragmenty były scalone z innymi dokumentami, scalona wersja wymaga ręcznej rewizji przed usunięciem.

Czas zależy przede wszystkim od stanu danych wejściowych i liczby źródeł. Przy jednym, ustrukturyzowanym systemie (np. Confluence z kilkuset stronami) dokładna i rozmyta deduplikacja plus normalizacja to praca jednego do trzech dni, z godzinami na ręczny przegląd kandydatów. Przy trzech lub więcej systemach z historią kilku lat, nieujednoliconą terminologią i duplikatami między systemami praca zajmuje od jednego do trzech tygodni, z realną częścią spędzaną na decyzjach wymagających kontekstu biznesowego, nie tylko technicznego. Szczegółowy plan etapów przygotowania danych firmowych pod AI opisujemy w osobnym artykule na tym blogu.