Коли схожість не є релевантною: створення корпоративних систем RAG за межами векторного пошуку.

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

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

У компанії значущість залежить від набагато більшої кількості факторів, ніж просто формулювання. Нещодавність, авторитет, географія, тип документа, дозволи користувача, стан робочого процесу, контрактні зв’язки та взаємозв’язки між бізнес-ентитетами — усе це має значення. Надійна система повинна об’єднати всі ці сигнали та не вважати близькість у векторному просторі остаточним критерієм.

Як векторний пошук став стандартом

Пошук за ключовими словами сильно залежить від точних термінів. Людина, яка шукає „політику відходу співробітників“, може пропустити файл під назвою „Процедура виходу співробітників з компанії“, оскільки в цих назвах немає спільних слів.

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

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

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

Демонстрації та невеликі бази знань працюють добре за цією схемою. Однак у корпоративних середовищах починають виникати проблеми.

Схожість — це лише один із кількох показників

Уявіть менеджера з закупівель, який пише: «Які умови оплати діють за нашою поточною угодою з Northstar Components?»

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

Кожен із цих елементів семантично пов’язаний із поставленим запитанням, проте, можливо, лише один чи два мають оперативне значення. Правильний вибір означає необхідність відповідей на додаткові запитання: до якої юридичної особи посилається термін „наш“? Яка саме компанія Northstar бере участь? Чи залишається угода чинною, і чи змінили доповнення початкові умови? Яка юрисдикція її регулює? Чи має цей користувач дозвіл на її перегляд? Чи існує підписана версія, і яке джерело має найвищу автентичність?

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

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

Сім способів, якими чиста схожість призводить до проблем

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

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

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

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

Проблеми з точними ідентифікаторами. Ембеддинги оптимізовані під зміст та часто погано обробляють буквальні рядки. Типовими жертвами є номери деталей, номери рахунків, посилання на пункти угоди, коди ліків, ідентифікатори обладнання та номери версій. Пошук за „Model AX-1047“ не повинен повертати „AX-1041“, оскільки описи цих елементів схожі між собою. У бізнес-запитах часто потрібна як семантична, так і буквальна точність.

Негативні обмеження. Люди часто запитують про те, чого бракує: які клієнти не завершили процедуру верифікації, які пристрої не підпадають під дію поточної угоди про технічне обслуговування, які рахунки-фактури залишаються непогашеними протягом 60 днів, які тестові сайти не надіслали необхідну документацію. Такі запитання ґрунтуються на відсутності, виключенні чи порівнянні даних у різних записах. Пошук за схожістю знаходить текст, пов’язаний із певною концепцією, але не може надійно визначити, що саме відсутнє.

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

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

Релевантність має багато вимірів

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

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

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

Як виглядає більш міцна архітектура пошуку

Надійна система RAG зазвичай проходить кілька етапів пошуку та перевірки.

1. Розуміння запиту

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

Візьмемо запит «Що змінилося у нашій політиці зберігання даних у Європі цього року?» Його не слід обробляти як звичайний семантичний пошук. Він передбачає певний регіон, категорію документа, часовий проміжок та порівняння версій. Розуміння запиту перетворює неструктурований речення на структурований план пошуку.

2. Фільтрація метаданих

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

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

3. Гібридний пошук

Гібридний метод пошуку поєднує семантичний та лексичний пошук. Вектори враховують значення та парафрази, тоді як лексичні методи, такі як BM25, працюють із точною термінологією, ідентифікаторами та рідкісними термінами. Гібридна система може зрозуміти, що „процедура завершення“ пов’язана з „політикою виходу співробітників“, але все одно вимагати точного збігу для „HR-OPS-204“.

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

4. Пошук структурованих даних

Фрагменти документів є неправильним джерелом інформації для деяких запитів. Інформація про кількості, суми, порогові значення, статуси чи порівняння часто краще отримується за допомогою SQL-запитів, індексів пошуку, API, сховищ даних, баз знань, систем керування основними даними чи двигунів правил.

Якщо хтось запитує: «Скільки відкритих заявок цього кварталу перевищили суму в 5 лакхів?», правильним кроком є звернення до структурованого джерела, яке містить записи про заявки. Простий текст, що лише обговорює заявки, не може надати точної кількості. Зріла система направляє кожне запитання до відповідного механізму, який підходить для його обробки.

5. Графи знань та пошук з урахуванням взаємозв’язків

Деякі запитання по суті стосуються взаємозв’язків. Граф знань може моделювати клієнтів, постачальників, продукти, контракти, місця розташування, інциденти та правила, а також зв’язки між ними.

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

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

6. Переранжування

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

Серед сигналів, які можна використовувати, — ступінь прямої відповідності уривка запитанню, узгодженість з ентитетами, авторитетність, свіжість, повнота, конкретність, суперечності та бізнес-правила. Мета полягає у тому, щоб відрізнити уривки, які є „про тему“, від тих, які є „корисними для цього запитання“.

7. Складання контексту

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

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

8. Перевірка достовірності доказів

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

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

Бізнес-правила мають велике значення

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

Ці правила мають бути включені до коду для пошуку, ранжування чи координації дій. Сподіватися, що ШІ зможе вивести їх з контексту, — ненадійно, і це не залишає нічого для аудиту. Тут RAG у корпоративних умовах перетворюється на завдання системної інженерії, а не на просте вибір моделі.

Оцінка поза межами точності відповідей

Система може дати правильну відповідь з неправильної причини, використовуючи слабкі докази та покладаючись на попередні знання моделі. Вона також може здаватися точною під час тестування, але зазнати невдачі, як тільки зміняться документи. Тому оцінка має враховувати кожен етап процесу обробки даних.

Отримання даних. Перевірте, чи знайдені необхідні докази: recall@k, precision@k, середній обернений ранг та нормалізований дисконтований кумулятивний приріст, а також те, наскільки часто знаходяться точні ідентифікатори та наскільки часто результати є актуальними та авторитетними.

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

Генерація. Перевірте кінцеву відповідь: вірність даним, правильність посилань, повнота інформації, кількість непідтверджених тверджень, належне утримання від висловлювань та дотримання дозволів та правил.

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

Помилки, яких роблять команди, переходячи від векторного пошуку

Організації часто бачать обмеження моделей RAG, заснованих лише на векторах, і тоді додають складність без чіткого моделювання релевантності.

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

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

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

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

Практичний шлях вперед

Для покращення релевантності не обов’язково замінювати існуючу платформу RAG — її можна розвивати поступово.

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

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

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

Наостанок створіть набір для оцінки з реальних запитів користувачів та реальних проблем, та окремо тестуйте процес отримання та генерації інформації, щоб покращення в одному етапі не приховували проблем у іншому.

Правильні докази замість схожого тексту

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

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

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