30 запитань до інтерв’ю з теми RAG та векторних баз даних із стислими відповідями.

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

Основи

1. Що таке RAG у одному реченні?

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

2. Коли має сенс використовувати RAG?

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

3. У чому різниця між RAG, налаштуванням моделі та запитами з довгим контекстом?

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

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

Виберіть інструменти чи API для отримання актуальних транзакційних даних.

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

4. Чи є векторна база даних тим самим, що й система RAG?

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

5. У чому різниця між щільним, лексичним та розрідженим пошуком?

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

6. Чому тримати BM25 у стеку семантичного пошуку?

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

7. Бі-енкодер проти крос-енкодера?

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

8. Косинус, скалярний добуток чи евклідова відстань?

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

Пошук та отримання векторів

9. Що таке наближений пошук найближчих сусідів?

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

10. Як порівнюються методи flat, HNSW, IVF та квантування?

• Flat: порівнює все та забезпечує точні результати, але є дорогим при великих обсягах даних.
• HNSW: використовує навігову структуру графа для досягнення високого рівня відтворення результатів та низької затримки, але це потребує додаткової пам’яті.
• IVF: групує вектори у частини за центроїдами та шукає лише кілька з них; збільшення значення nprobe покращує рівень відтворення результатів, але збільшує затримку.
• Продуктове чи скалярне квантування: стискає вектори для економії пам’яті та простору зберігання, але це призводить до певних втрат у точності.

Виберіть за розміром корпусу даних, фільтрами, обсягом пам’яті, шаблоном оновлень, рівнем одночасності та потрібним рівнем точності пошуку.

11. Що таке гібридний пошук та чому його використовувати?

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

12. Що таке фузія взаємних рангів?

RRF об’єднує рангові списки, використовуючи позиції, а не первинні оцінки. Кожен документ отримує для кожного списку значення 1, поділене на (k плюс його ранг), а потім ці значення підсумовуються. Оскільки показники щільності та лексичності належать до різних масштабів, їх пряме додавання є ненадійним. RRF уникає необхідності калібрування та надає перевагу документам, які отримали високі ранги в кількох пошукових алгоритмах.

13. Чому потрібна перерангування?

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

14. Що робить максимальна маржинальна релевантність?

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

15. Чому фільтри метаданих можуть погіршити якість ANN?

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

Підготовка даних

16. Як ви обираєте стратегію часткового оброблення даних?

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

17. Що таке пошук у форматі батьківсько-дочірніх структур?

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

18. Що таке контекстуальне отримання даних та пізнє формування частин?

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

19. Що включає справжня система обробки даних?

1. Збирати документи та фіксувати інформацію про власника, класифікацію, права доступу та термін зберігання.
2. Аналізувати текст, заголовки, таблиці, сторінки та форматування.
3. Усувати шум від OCR та повторюваний стандартний текст.
4. Формувати частини з урахуванням структури.
5. Додавати метадані, інформацію про походження та посилання між елементами.
6. Створювати щільні ембеддинги та розріджені представлення.
7. Виконувати операції вставки/заміни з використанням детерміністичних ідентифікаторів.
8. Перевіряти кількості елементів, хеш-суми, права доступу, операції видалення та механізми перевірки отриманих даних.
9. Впроваджувати версіонування для парсера, інструменту розділення на частини, моделі ембеддингів та процесу створення індексу.

Він також має підтримувати оновлення, повторну обробку даних, скасування змін та перевірене видалення.

20. Як слід обробляти складні PDF-файли та таблиці?

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

Розширені патерни

21. Що таке переписування запитів, отримання інформації з кількох запитів та HyDE?

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

22. У чому різниця між Self-RAG, CRAG, RAPTOR та GraphRAG?

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

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

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

23. Що таке агентний RAG?

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

Оцінка та діагностика

24. Який показник використовується першим?

Candidate Recall@k: частка запитів, для яких необхідні докази є у отриманому наборі, розраховується як кількість релевантних елементів у топ-k поділена на всю кількість релевантних елементів. Якщо докази відсутні, ні ранжер, ні генератор не можуть їх відновити. Після цього оцінюється ранжування за допомогою MRR або nDCG, а потім — точність, коректність, вірність, якість цитувань, затримку та витрати в контексті.

25. MRR проти nDCG?

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

26. Як оцінювати якість відповіді?

Оцінюйте процес пошуку та генерацію окремо. Для пошуку відстежуйте Recall@k, Precision@k, MRR або nDCG, а також правильність та свіжість версій. Для генерації відстежуйте правильність, відповідність даним, повноту, наявність посилань, належне відхилення запиту та дотримання правил. Додайте показники затримки від початку до кінця, витрат, прийнятності користувачем та результатів для сегментів з високим ризиком.

27. Що таке тестування в контексті oracle?

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

28. Як діагностувати високу відповідність даним при низькій правильності відповідей?

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

Безпечна робота в масштабі

29. Як забезпечити безпеку багатокористувацької системи RAG?

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

30. Як би ви спроєктували платформу великого масштабу?

Спочатку уточніть обсяг документів, частоту запитів, кількість орендарів, частоту оновлень, терміни виконання завдань з видалення, затримки, потреби у цитуванні, цілі щодо безпеки та якості. Потім розділіть проектування на окремі етапи:

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

Для забезпечення стійкості необхідно використовувати детерміністичні ID, індекси з версіонуванням під псевдонімами, міграції, які працюють з двома індексами одночасно, механізми захисту від збоїв, обмежені обсяги роботи, кешування, тестові випуски типу canary, можливість скасування змін та чіткі SLO. Використання GraphRAG чи агентних механізмів пошуку слід відкласти, доки виміряний рівень збоїв не стане цьому підставою.