Оновлення та версіонування знань у RAG

Відділ продукту змінює прайс-лист у п’ятницю ввечері. Асистент RAG обслуговує запити клієнтів протягом вихідних, відповідаючи на основі векторів, згенерованих у вівторок. Клієнт отримує помилкову ціну, подає скаргу, відділ підтримки витрачає годину на роз’яснення. Це не гіпотетичний сценарій. Це шаблон, який виникає в кожному впровадженні RAG, де немає продуманого шару оновлення знань.

Проблема не в самому мовному моделі чи векторному пошуку. Вона полягає в припущенні, що база знань — це стан, а не потік. Компанії, які це розуміють, будують пайплайн оновлень разом з пайплайном індексації — не як окремий проєкт «на потім».

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

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

Три механізми поглиблюють проблему в міру зростання бази:

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

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

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

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

Потрібні чотири елементи:

Детектор змін. Кожен документ має хеш вмісту (SHA-256 достатньо), який зберігається разом з метаданими вектора. Перед індексацією пайплайн порівнює хеш поточної версії з збереженим хешем. Реіндекс відбувається лише при різниці. При інтеграції з CMS, SharePoint або репозиторієм Git можна слухати вебхуки або події API — зміна документа безпосередньо запускає завдання індексації.

Черга завдань. Події індексації потрапляють до черги (Redis, Celery або спеціалізований message broker). Черга гарантує, що раптовий пакет оновлень (наприклад, оновлення прайс-листа перед сезоном) не блокує систему — завдання обробляються поступово, з пріоритизацією документів з високою кількістю запитів.

Атомна заміна векторів. При оновленні документа старі вектори позначаються як вилучені (soft delete з timestamp), нові індексуються, потім старі видаляються. Ніколи навпаки. Вікно, в якому в базі існують обидві версії, становить кілька секунд і управляється версіонуванням метаданих.

Логи індексації. Кожна операція (новий, оновлений, видалений) логується з timestamp, ідентифікатором документа та версією. Лог незалежний від самої векторної бази і дозволяє проводити аудит: коли даний документ востаннє реіндексувався, скільки разів змінювався, чи вдалася індексація.

Версіонування в системі RAG працює на двох рівнях, які варто розділити концептуально.

Версіонування документів відповідає на питання: яка версія документа зараз активна? Мінімальна реалізація — це поле version або valid_from / valid_to у метаданих кожного фрагмента. При запиті фільтр метаданих виключає фрагменти з valid_to у минулому. Завдяки цьому можливе відкочування оновлень: зміна valid_to повертає попередню версію без реіндексації.

Версіонування векторів відповідає на питання: чи цей вектор походить з моделі ембедінгів, яку ми зараз використовуємо? Моделі ембедінгів змінюються. Міграція з однієї моделі на іншу (наприклад, оновлення до нової версії BGE-M3 або зміна розмірності вектора) означає, що старі та нові вектори не є порівнянними. Метадані кожного вектора повинні містити ідентифікатор моделі та розмірність. При міграції моделі старі вектори поступово замінюються новими — dual-index протягом перехідного періоду, потім видалення старих.

Повна реіндексація повинна бути винятковою операцією, а не рутинною. Якщо доводиться робити її регулярно, це сигнал, що архітектура виявлення змін не працює.

Дрейф знань — це зростаюча розбіжність між тим, про що запитують користувачі, і тим, що є в базі. Два типи найпоширеніші.

Дрейф контенту: документи в базі актуальні, але запитання користувачів стосуються тем, які ще не проіндексовані. Видно в метриках як зростаючий відсоток відповідей з повідомленням «не маю цієї інформації» або зростаюча кількість ескалацій до консультантів.

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

Практичне виявлення дрейфу потребує трьох елементів:

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

Сповіщення про зростаючий відсоток відповідей «не знаю». Раптове зростання — це сигнал, що з’явилися нові теми без покриття в базі — або що документи з цього домену були змінені і не були реіндексовані.

Сліду версії в кожній відповіді. Логування, з якої версії якого документа походить фрагмент, використаний для відповіді, дозволяє постфактум перевірити, чи відповідь базувалася на актуальному чи вилученому контенті. Без цього аудит неможливий. Цей шаблон також є вимогою AI Act у системах, класифікованих як високого ризику — слід рішення має бути відтворюваним.

При обмежених ресурсах індексації варто пріоритизувати. Не кожен документ має однакове значення для якості відповідей.

Високий пріоритет мають документи, на основі яких система надає відповіді найчастіше. Логування ідентифікатора документа при кожному використанні (якщо дотримуєшся RODO та анонім. PII) дозволяє побудувати рейтинг популярності документів. Документи у верхній частині рейтингу слід перевіряти на актуальність при кожній зміні домену.

Високий пріоритет мають також документи з коротким життєвим циклом: прайс-листи, SLA, регламенти, графіки. Їхні метадані повинні містити поле valid_to із визначеним терміном закінчення. Система повинна автоматично позначати їх як застарілі після цього терміну та вимагати підтвердження власника документа перед подальшим використанням.

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

База знань RAG може містити персональні дані: транскрипції розмов з клієнтами, електронні листи, нотатки з проєктів. Право на забуття (ст. 17 RODO) поширюється не лише на базу документів, а й на вектори.

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

Для конфіденційних даних (наприклад, транскрипції з даними клієнтів) стандартний підхід — це маскування PII перед індексацією. Проіндексований фрагмент не містить тоді персональних даних, і видалення на вимогу стосується лише оригінальних документів, а не векторів. Детальний шаблон описано в статті про анонімізацію PII перед AI.

Для конфіденційних даних та регуляторних вимог весь стек (ембедінги + векторна база + модель) має працювати локально. Self-hosting усуває питання про передачу даних у хмару та спрощує DPIA.

Опиши структуру своєї бази знань та частоту змін документів, а модель запропонує архітектуру пайплайну оновлень, адаптовану до масштабу — як відправну точку для обговорення з технічною командою (пісочниця: PII маскуються, нульове зберігання):

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

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

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

Так. Вектор, згенерований з документа, що містить персональні дані, є похідною цих даних і підлягає тим самим обов’язкам, що й оригінал. Видалення документа з вихідного репозиторію недостатньо — потрібне явне видалення векторів з векторної бази, підтверджене в лозі з timestamp. Рекомендованою альтернативою є маскування PII перед індексацією: проіндексований фрагмент не містить тоді персональних даних, а право на видалення стосується лише оригінальних документів.

Старі та нові вектори не є геометрично порівнянними — не можна змішувати вектори з різних моделей в одній колекції. Безпечна процедура міграції — це dual-index: паралельне підтримання старої колекції (з якої відповідає продакшн) та нової (до якої потрапляє інкрементна реіндексація). Після реіндексації всього корпусу трафік перемикається на нову колекцію, стара видаляється. Час міграції залежить від розміру корпусу та доступних обчислювальних ресурсів — при self-hosting з локальною моделлю зазвичай кілька до десятків годин.