Забезпечення чесності сховища векторів: життєвий цикл, моделювання користувацьких прав, метадані, гібридний пошук.
Керування сховищем векторів для RAG у промисловому середовищі: життєвий цикл документів, оновлення ембеддингів, фільтри орендарів, гібридний пошук за точними ідентифікаторами, метадані та відстеження.
Джерела: Vector Store Operations: What Keeps RAG Retrieval Correct in Production
Технік на місці звертається до внутрішнього асистента підтримки з питанням про те, як замінити гідравлічний насос. Відповідь здається правильною: правильна група обладнання, правильний тип насоса, логічна послідовність кроків. Проте вона є вже півроку старою. У поточному бюлетені вимагається оновлення прошивки перед встановленням насоса, а у старому бюлетені про це нічого не сказано. Обидва бюлетені зберігаються у сховищі даних. Новий був належним чином індексований, але старий так і не було видалено. Модель не створила жодних хибних даних — їй просто надали застарілу інформацію.
Саме такі запитання визначають, чи можна довіряти системі пошуку.
- Яку версію документа можна наразі знайти?
- Через який час після схвалення оновлення стає доступним для пошуку?
- Чи може один клієнт побачити контент іншого клієнта?
- Що відбувається, коли користувач шукає точний номер деталі, а не загальну інформацію?
Усе це не стосується якості моделі. Це пов’язано з щоденною роботою сховища векторів.
Конкретна налаштування: технічна підтримка кількох клієнтів
Уявіть собі платформу підтримки, якою користуються дилери обладнання в кількох країнах. Вона містить інструкції до продуктів, інформацію про ремонт, каталоги запчастин, умови гарантії, процедури технічного обслуговування та примітки, написані окремими дилерами. Технік може запитати, яка процедура заміни схвалена для гідравлічного насоса MX-204, версія 5.2, у його регіоні.
Це не звичайний семантичний пошук. Система має розуміти мету обслуговування, зберігати точні ідентифікатори, такі як версія MX-204 5.2, у недоторканному вигляді, повертати поточну процедуру ремонту, застосовувати відповідну регіональну політику та виключати все, що належить іншим дилерам чи обліковим записам. Простий запит на пошук схожості не може забезпечити такі гарантії. Шар пошуку має функціонувати як керована інформаційна служба.
Розглядайте індексування як управління публікацією документів
У ранніх версіях технології RAG індексування зазвичай розглядається як єдиний етап: завантаження, розділення на частини, вбудовування, записування, готово. Після цього документ залишається доступним для пошуку, поки хтось не помітить проблему. Наслідки таких недоліків легко передбачити.
- Оновлений посібник зберігається разом із попередньою версією.
- Чорнова версія політики стає доступною для пошуку ще до її схвалення.
- Процедура видалення не виконується, тому документ залишається доступним, оскільки процес видалення відсутній.
- Помилка у потоці обробки призводить до того, що документ індексується частково, тож можна отримати лише фрагменти.
Для корпусу підтримки найменший корисний набір станів життєвого циклу виглядає так:
- Чорновик: отримано, ще не схвалено до пошуку.
- Кандидат: індексовано та перевіряється.
- Активний: схвалено та готове до пошуку.
- Замінений: замінено на новішу версію, зберігається для аудиту, приховано від звичайних запитів.
- У карантині: утримується через проблеми з перевіркою, перевіркою метаданих або рецензуванням контенту.
- Видалено: видалено з корпусу, а також із базового сховища, якщо це вимагають правила.
Є одне важливе правило: пошук має стосуватися лише документів у активному стані. Його необхідно забезпечувати за допомогою фільтрів метаданих, а не через звички найменування файлів чи інструкції в запиті.
Кожен документ також потребує стабільного ідентифікатора документа та окремого ідентифікатора версії. Перший позначає логічний об’єкт, наприклад певний інструкційний бюлетень, а другий — певну його ревізію. Схвалення нової ревізії активує нову версію та позначає попередню як застарілу, причому ця заміна має відбуватися атомарно. Завдяки цьому система перестає повертати контент, який є релевантним, але більше не є дійсним.
Оновлення ембеддингів: інкрементальне, версійоване, зворотне
Оновлення ембеддингів часто описують як завдання, які потрібно виконувати щоразу, коли змінюється модель. Насправді ж існує більше різноманітних спускових механізмів:
- Документ-джерело було відредаговано.
- Політика досягла своєї дати набрання чинності або закінчення терміну дії.
- Схема метаданих розширюється.
- Стратегія часткового оброблення даних покращується.
- Модель вбудовування оновлюється.
- Документ відкликається або перекласифікується.
- Права користувача змінюються.
Кожен випадок вимагає окремої реакції. Для оновленого бюлетеня може знадобитися лише оновлення на рівні розділу. Нова модель вбудовування може означати необхідність повної перебудови всього. Нове поле метаданих вимагає контрольованого заповнення, а відкликаний документ мусить негайно бути видалений з активного індексу.
Тому процес оновлення має відстежувати чотири версії: версію вихідного документа, логіку часткового оброблення, модель вбудовування та схему метаданих, яка використовується для фільтрації. Без цього запису ніхто не зможе пояснити, чому два фрагменти даних поводяться по-різному під час пошуку.
На практиці надісланий файл порівнюється з активною версією за допомогою хеш-вартості контенту або структурованого дифу. Розділи, які змінилися, розбиваються на нові частини та заново вбудовуються, тоді як незмінні розділи залишаються без змін, якщо тільки спосіб розбиття на частини чи вбудовування не змінився.
Для оновлень великих моделей потрібна більш безпечна процедура: створюється паралельний кандидатський індекс, виконуються запити на оцінку для обох індексів, перевіряються механізми контролю доступу, і трафік перенаправляється лише тоді, коли новий індекс працює на прийнятному рівні. Важливим є не те, чи отримала нова модель вищий бал за певними критеріями, а те, чи повертає новий індекс правильні, схвалені дані для запитів, які насправді надсилають користувачі.
Забезпечувати дотримання правил ще до отримання даних, а не після
Небезпечна, але поширена проблема проектування в системах RAG з кількома орендарями — це фільтрація результатів за орендарем після пошуку. Система спочатку знаходить широкий спектр результатів, а потім видаляє ті, що належать іншим організаціям. Це вже занадто пізно. Фільтри орендаря та доступу мають визначати діапазон можливих результатів ще до початку пошуку за векторами чи ключовими словами.
У платформі підтримки контент поділяється на три групи.
- Глобальний контент: інструкції виробника та спільні процедури безпеки.
- Контент дилерів: внутрішні інструкції з обслуговування, комерційні угоди та місцеві інструкції щодо експлуатації.
- Контент клієнтів: історія активів, умови контрактів та конфіденційні записи щодо експлуатації.
Їм не потрібна однакова структура зберігання. Глобальний контент може користуватися спільним корпусом даних. Контент дилера може використовувати індекс, захищений обов’язковими фільтрами для користувачів. Дуже конфіденційні клієнти можуть потребувати власних колекцій чи ізольованих індексів залежно від вимог регуляторних органів, контрактів та критеріїв ризику.
Інформація про користувача, його роль, регіон, права на доступ до продуктів та рівень конфіденційності має походити з автентифікованої сесії, а не з формулювань запиту. Технік, який вводить ім’я іншого дилера у запит, не повинен мати можливості змінити фільтри. Фактично запит на пошук передбачає пошук лише тих даних, до яких має доступ цей автентифікований користувач, і лише після цього починається семантичне чи ключове сортування. Це забезпечує конфіденційність та видаляє нерелевантні результати.
Гібридний пошук для точних ідентифікаторів
Щільний пошук векторів є ефективним, коли люди описують проблему звичайною мовою, наприклад, запитуючи, яка версія прошивки потрібна перед встановленням замінної помпи на MX-204. Номери деталей, коди контролерів та рядки версій поводяться по-різному, і лексичний індекс значно краще дозволяє знаходити їх із точністю.
У випадку MX-204 лексичний пошук може знайти саме потрібний документ, оскільки він містить ідентифікатори контролера та помпи, тоді як щільний пошук пропонує відповідні інструкції з технічного обслуговування. Потім алгоритм переоцінки може надати перевагу документу, який містить вимоги до прошивки та схвалену послідовність дій.
Коли ефективність пошуку низька, додавання більшої кількості даних у контекст рідко допомагає. Більше елементів у списку топ-k переважно створює шум, затримки та підвищує ймовірність отримання правдоподібної, але не підтвердженої даними відповіді. Краще з’ясувати, на якому етапі виникла проблема.
- Чи був потрібний документ недієздатним?
- Чи виключив його несправний фільтр метаданих?
- Чи пропустила лексична пошукова система інший формат номера деталі?
- Чи віддав перевагу алгоритм ранжування більш загальному документу перед більш конкретним?
Кожен з цих випадків є вимірюваним системним проблемою.
Метадані як план керування
Метадані часто обробляються як необов’язкові теги, які додаються під час отримання даних. У реальних умовах вони визначають, що може бути отримано системою. Корисна схема охоплює п’ять сфер.
- Ідентичність: джерельний документ, система, з якої надійшли дані, та хеш контенту.
- Життєвий цикл: версія, статус схвалення, дати набрання чинності та закінчення терміну дії, а також те, що має пріоритет над чим.
- Доступ: ідентифікатор користувача, регіон, права ролі, доступ до продукту, клас конфіденційності та юридичні обмеження.
- Отримання: тип документа, мова, модель обладнання, родина компонентів, лінійка продуктів та категорія контенту.
Завдяки такій структурі запитання, які інакше були б складними, перетворюються на прості запити. Які активні документи все ще використовують стару модель вбудовування? Які процедури ремонту закінчуються терміном дії наступного місяця? Які частини даних не мають метаданих регіону? У якого користувача найвищий відсоток порожніх результатів? Які системи вихідних даних спричиняють найбільше помилок під час імпорту?
Метадані слід перевіряти перед тим, як документ потрапить до активного корпусу. Частина даних без інформації про користувача, стан життєвого циклу, лінійку продуктів чи статус схвалення не повинна ставати доступною для пошуку лише через те, що було створено її вбудовування. Багато систем RAG стають ненадійними саме на цьому етапі: база даних працює за задумом, але модель метаданих занадто примітивна, щоб відображати справжні правила організації щодо доступу, життєвого циклу та політик.
Здатність до спостереження, яка виявляє несправну стадію
Коли користувач повідомляє про неправильну відповідь, можливо, сталася одна з кількох проблем. Правильне джерело могло так і не бути індексоване, або бути індексованим, але позначеним як неактивне, або бути відкинутим фільтром. Воно могло потрапити до списку кандидатів, але отримати занадто низький рейтинг. Воно могло потрапити до контексту моделі, але бути проігнорованим. Або ж модель могла написати щось, що не підтверджується даними. Кожен випадок вимагає окремого рішення.
Тому зріла служба пошуку фіксує весь шлях обробки:
- Запит та контекст користувача.
- Фільтри доступу та життєвого циклу, які були застосовані.
- Інтенсивні кандидати та лексичні кандидати.
- Об’єднаний рейтинг та результати повторної оцінки.
- Остаточні дані, які надаються моделі.
- Цитати, використані у відповіді.
Корисними заходами є затримка між схваленням джерела та активацією індексу, частка активного контенту у поточній версії інтеграції, документи з більш ніж однією активною версією, показники кількості запитів без результатів за типом, рівень покриття у тестах з відомими відповідями, кількість відхилених записів через фільтрацію та будь-які спроби доступу між користувачами.
Корисним показником є покриття кандидатів: для запиту з відомою відповіддю чи з’являлося правильне джерело серед кандидатів перед переранжуванням? Якщо ні, слід перевірити процес індексування, фільтрацію чи проектування пошуку. Якщо воно з’являлося, але мало низький ранг, потрібно переглянути процес об’єднання даних чи переранжування. Якщо воно мало високий ранг, а відповідь його проігнорувала, проблема полягає у генерації тексту чи формуванні запиту. Розділення етапів заважає командам намагатися виправити все шляхом редагування запиту.
Рутинні процедури роботи
Сховище векторів потребує такої ж дисципліни, як і будь-який сервіс обробки даних у продакшені. Щоденні перевірки мають враховувати помилки під час отримання даних, затримки оновлень, документи, що застрягли у статусі «кандидат» або у карантині, відсутність обов’язкових метаданих та затримки у процесі схвалення для індексації. Щотижневі огляди мають аналізувати якість отримання даних для різних типів запитів — від розмовних запитань до простих кодів, назв продуктів, пошуку правил, пошуку іншими мовами та нечітких запитів.
Будь-які зміни щодо розділення даних на частини, моделей ембеддингу, схеми метаданих чи політики доступу мають спочатку тестуватися в тестовому середовищі. Для оцінки потрібні реальні запити користувачів, випадки з відомими відповідями, тести контролю доступу та запити, призначені для виявлення витоків даних або застарілого контенту.
Метою не є отримання більшої кількості документів. Це — надання правильних, схвалених доказів правильній користувачці у правильний момент. Сховище векторів — це не пасивна база даних позаду чат-бота, адже саме воно вирішує, які докази можуть вплинути на формування відповіді. Якщо застарілі документи залишаються активними, фільтри користувачів є необов’язковими, ідентифікатори зникають під час семантичного пошуку, а метадані не можуть відображати бізнес-правила, система є ненадійною, незалежно від потужності моделі.