Дедуплікація та очищення даних під AI у 2026 році

Фірма об'єднує три системи: Confluence, SharePoint і стару базу FAQ в Excel. Після першого індексування RAG відповідає неконкретно або цитує суперечливі процедури. Помилки немає ні в моделі, ні в конфігурації Qdrant. Проблема виникає раніше: ті самі документи з'явилися в індексі кілька разів, у трохи різних версіях, і тепер кожна версія змагається за те саме місце в результатах пошуку.

Дедуплікація та очищення даних – це робота, яка відбувається перед індексуванням, а не після нього. Коли її пропускають, симптоми проявляються поступово: асистент відповідає непослідовно, вартість токенів зростає, а метрики якості не покращуються, попри налаштування промптів.

RAG працює за принципом ранжування: система отримує фрагменти, які найбільше семантично відповідають запиту, і надає їх моделі як контекст. Якщо в індексі є п'ять версій тієї самої процедури, три з них потрапляють до контексту замість трьох різних, взаємодоповнюючих документів. Модель отримує менше інформації, ніж могла б отримати з чистого корпусу.

Дублікати також генерують конкретні витрати. Кожен фрагмент займає токени в контекстному вікні. При лімітах у 8 000 або 128 000 токенів повторюваний контент – це витрачена даремно площа, за яку ви платите або яка обмежує те, що модель може одночасно проаналізувати.

Третій ефект – суперечність. Версія процедури 2022 року та версія 2024 року можуть описувати той самий крок по-різному. Модель не знає, яка з них актуальна, і цитує обидві або довільно обирає одну. Ззовні це виглядає як «галюцинація», але причиною є база знань, а не модель.

Ми в Cashcrown спостерігаємо, що в проєктах, де клієнти приходять з невпорядкованими корпусами, значна частина підготовчої роботи припадає саме на дедуплікацію, а не на налаштування моделі. Ми не наведемо конкретних цифр, наскільки це покращує якість відповідей, бо це залежить від стану конкретних даних. Ви знаєте, що проблема є, коли метрики faithfulness і relevance не зростають, попри зміни в промптах.

Немає одного методу, який виявляє всі типи дублікатів. На практиці застосовують три рівні, які запускаються послідовно, бо кожен наступний є обчислювально дорожчим.

Рівень 1: точне співпадіння (exact match). Обчислюється хеш SHA-256 або MD5 цілого документа або його фрагмента після нормалізації (lowercase, видалення пробілів). Якщо два файли мають ідентичний хеш, один потрапляє до кошика без подальшого аналізу. Це найшвидший рівень, нульова вартість LLM. Працює при файлах, скопійованих між папками або синхронізованих двома інтеграціями одночасно.

Рівень 2: розмите співпадіння (fuzzy match). Алгоритми, такі як відстань Левенштейна, схожість Жаккара на n-грамах або MinHash, виявляють документи, які відрізняються незначно: додано один абзац, виправлено помилку, змінено форматування. Поріг схожості встановлюється емпірично, зазвичай Жаккар вище 0,85-0,90 свідчить про дублікат-кандидат. Рішення про об'єднання або відхилення залишається для підтвердження людиною.

Рівень 3: семантичне виявлення (embedding-based). Генеруєш ембедінги для кожного фрагмента і вимірюєш косинусну схожість. Фрагменти зі схожістю вище порогу (зазвичай 0,92-0,95, каліброваного на золотому тестовому наборі) є кандидатами на об'єднання. Цей рівень виявляє випадки, коли два документи говорять про те саме по-різному: змінена термінологія, інший переклад, переписана процедура з тим самим значенням. Деталі про векторну схожість у статті семантичний пошук та ембедінги у компанії.

Кожен вищий рівень потребує дорожчої перевірки. Тому послідовність має сенс: спочатку фільтруй тим, що дешеве, а семантику застосовуй лише там, де два попередні рівні не дали чіткої відповіді.

Дедуплікація без попередньої нормалізації генерує хибні розрізнення. Той самий документ, записаний як PROCEDURA_v3_final.docx і як procedura v3 final.docx, має різні хеші. Нормалізація тексту усуває ці уявні відмінності перед порівнянням.

Нормалізація має бути детермінованою та оборотною для потреб аудиту: не перезаписуєш оригінали, пишеш до окремого пайплайну, що готує дані до індексування. Оригінали залишаються в джерелі без змін.

Близький дублікат (near-duplicate) – це проблема складніша за ідентичний дублікат, бо є менш помітною. Два фрагменти процедурного документа, які відрізняються одним абзацом про особливий випадок, можуть виглядати як дублікати, але бути взаємодоповнюючими.

При семантичному пошуку близькі дублікати порушують ранжування специфічним чином: фрагмент A та його майже ідентична копія B підсилюють один одного в результатах, бо пошукова система вважає, що тема «добре представлена». Інші, менш повторювані матеріали опускаються в ранжуванні, хоча могли б бути кориснішими.

Практичний підхід до близьких дублікатів у корпусі RAG:

• Групуй кандидатів за семантичною схожістю (кластери з ембедінгів).
• Для кожної групи: залишай версію з найновішою датою модифікації або з повнішим змістом.
• Старіші версії перенось до архіву, не до активного індексу.
• Версії, відношення між якими незрозуміле (наприклад, відрізняються ключовою технічною деталлю), позначай для ручного перегляду.

Поріг семантичної схожості для близьких дублікатів зазвичай встановлюють нижче, ніж для ідентичних, бо хочеш бути консервативним: краще позначити кандидата для перегляду, ніж автоматично об'єднати два документи, які виявляться такими, що мають важливі відмінності.

Очищення даних під AI – це не лише дедуплікація. Паралельно має проходити виявлення та обробка персональних даних (PII) у кожному документі перед індексуванням.

Типові типи PII у корпоративних корпусах: імена та прізвища клієнтів, адреси електронної пошти, номери телефонів, номери PESEL та NIP, адреси проживання, номери замовлень з прив'язкою до особи, ідентифікатори сесій. Усі вони підпадають під дію RODO і потребують правової основи обробки, мінімізації та обробки права на видалення.

На практиці є три шляхи:

Маскування перед індексуванням. PII замінюється токеном ([EMAIL_1], [PESEL_1]) ще в пайплайні підготовки даних, перед генерацією ембедінгів. До індексу потрапляє текст з токенами, а не з реальними значеннями. Детальна архітектура маскування в статті анонімізація та маскування PII перед AI.

Виключення документа з індексу. Якщо документ містить PII, необхідні для його змісту, і їх не можна анонімізувати без втрати цінності (наприклад, транскрипція розмови з клієнтом), він не потрапляє до основного індексу. Може потрапити до спеціалізованої колекції з контролем доступу та чіткою правовою основою.

Екстракція даних та статистична анонімізація. Для документів, що служать для аналізу (звіти, анкети), можна виокремити агрегати замість одиничних даних. Модель працює тоді зі статистикою, а не з персональними даними.

Інструменти для автоматичного виявлення PII в польських текстах: Microsoft Presidio (з моделлю NER для польської), spaCy з моделлю pl_core_news_lg, правила regex для шаблонів PESEL/NIP/телефону. Жоден з них не дає 100% recall на сирих корпоративних даних, особливо при власних назвах, які виглядають як загальний текст. Тому автоматичне виявлення PII – це перший крок, а не єдиний, особливо при даних особливих категорій (ст. 9 RODO).

Більше про підготовку даних з урахуванням RODO та AI Act у статті як підготувати корпоративні дані під AI.

Автоматизація прискорює дедуплікацію та очищення, але не усуває потреби в людському рішенні. Існує кілька точок, де автоматична дія є неприпустимою або надто ризикованою.

Об'єднання записів клієнтів у CRM. Алгоритм розмитого співпадіння може знайти, що «Jan Kowalski, ul. Lipowa 5» і «Jan Kowalski, ul. Lipowa 5a» – ймовірно, та сама особа. Ймовірно, але не точно. Об'єднання історії замовлень, контактів і оцінок двох різних клієнтів з подібними даними – це помилка з реальними бізнесовими та правовими наслідками (RODO вимагає точності даних). Автоматизація пропонує кандидатів на об'єднання, людина затверджує або відхиляє кожен випадок.

Видалення версій документів. Стара версія процедури може бути потрібна як доказ у разі аудиту або рекламації. Автоматичне видалення «старої версії дублікату» може видалити матеріал, який компанія зобов'язана зберігати. Архівуй, а не видаляй, а рішення про фізичне видалення доручай людині, яка знає правовий контекст документа.

Чутливі дані з AI Act. При документах у сферах високого ризику (HR, оцінка кредитоспроможності, системи рекрутингу) кожна зміна в навчальному наборі даних або індексованому вимагає документування та затвердження людиною, відповідно до вимог ст. 10 AI Act (якість даних та управління). Автоматична дедуплікація без аудиторського сліду тут несумісна з вимогами.

Межа семантичної впевненості. Якщо два фрагменти мають векторну схожість між 0,85 та 0,92 (сіра зона), семантична модель недостатньо впевнена, щоб вирішити самостійно. Такі пари потрапляють до черги ручної перевірки. Цей поріг калібрується один раз на золотому наборі прикладів перед запуском пайплайну.

Шаблон, який ми застосовуємо: автоматизація пропонує, список рішень потрапляє до відповідальної за базу даних особи, рішення фіксується з датою та обґрунтуванням. Більше про управління рішеннями на наборах даних у статті governance даних для AI.

Нормалізація усуває уявні відмінності в представленні того самого тексту: зміна регістру літер, пробіли, кодування Unicode діакритичних знаків. Дедуплікація виявляє та обробляє реальні повторення контенту на трьох рівнях: ідентичні, розмиті та семантичні. Без нормалізації той самий документ у двох кодуваннях може не бути розпізнаний як дублікат за хешем, тому нормалізація завжди є першим кроком.

Поріг калібрується емпірично: підготуй 100-200 пар документів з ручним позначенням «дублікат / не дублікат», запусти модель ембедінгів і виміряй precision та recall при різних значеннях. Типова стартова точка – cosine similarity 0,92-0,95 для коротких фрагментів, нижча для довших документів. Обери поріг, що мінімізує хибні об'єднання, бо об'єднання двох різних записів важче скасувати, ніж залишити кандидата для ручного перегляду.

При малих, однорідних базах (кількасот документів з одного джерела) дублікати рідкісні, і вплив на якість незначний. При базах понад кілька тисяч документів з багатьох систем (CRM, SharePoint, Confluence, електронні листи) дублікати з'являються майже завжди, бо та сама інформація циркулює в багатьох місцях. Ознака того, що дедуплікація потрібна: однакові тестові запитання отримують різні відповіді при наступних запусках, або асистент цитує суперечливі процедури в одній відповіді.

Запит на видалення стосується всіх місць з даними особи, включаючи векторний індекс. Фрагменти, створені на основі документів з PII цієї особи, мають бути видалені. Пайплайн дедуплікації повинен зберігати мапу походження: який фрагмент походить з якого вихідного документа. Без неї неможливо виконати повне видалення. Якщо фрагменти були об'єднані з іншими документами, об'єднана версія потребує ручної ревізії перед видаленням.

Час залежить насамперед від стану вхідних даних та кількості джерел. При одній структурованій системі (наприклад, Confluence з кількома сотнями сторінок) точна та розмита дедуплікація плюс нормалізація – це робота від одного до трьох днів, з годинами на ручний перегляд кандидатів. При трьох або більше системах з історією кількох років, неуніфікованою термінологією та дублікатами між системами робота займає від одного до трьох тижнів, з реальною частиною, витраченою на рішення, що потребують бізнес-контексту, а не лише технічного. Детальний план етапів підготовки корпоративних даних під AI описано в окремій статті на цьому блозі.