RAG з FAISS: локальний векторний пошук без хмари

RAG-розробка впирається в ліміти хмарного пошуку

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

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

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

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

Друга лінія ризику — дані за периметром. Щоб пошук працював, назовні вирушають тексти внутрішніх документів, витяги з облікових систем і листування співробітників.

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

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

Бібліотека FAISS підходить для цього без застережень — індекс живе на диску та в пам'яті, мережевих викликів на кожен запит немає. Розбираємо, як це закривається на практиці.

Що дає локальний векторний індекс: швидкість і контроль

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

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

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

Звідси передбачуваний час відгуку — частки секунди на запит навіть за помітного обсягу корпусу, і він не «пливе» при зростанні кількості одночасних користувачів.

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

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

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

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

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

Варіанти RAG-розробки: хмара, локальний контур, гібрид

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

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

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

Як відбувається впровадження: від аудиту даних до запуску

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

1. Аудит даних. Дивимося, що реально лежить у корпусі: формати, дублікати, застарілі редакції, документи з обмеженням доступу. На виході — перелік джерел з оцінкою придатності та прогалини, які доведеться закрити.

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

3. Налаштування пошуку. Збираємо локальний векторний індекс (FAISS) і додаємо фільтри за метаданими, щоб співробітник отримував лише дозволені йому документи. Переіндексація відбувається за регламентом, а не вручну.

4. Складання відповіді. Модель отримує лише знайдені фрагменти й зобов'язана посилатися на джерело. Якщо відповідного фрагмента немає — відповідає «у базі немає», а не добудовує факти.

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

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

Кожен етап завершується артефактом, який можна перевірити, а не усним статусом. Опишіть завдання — повернемося з оцінкою та планом за етапами.

Що залишається в контурі замовника: конфігурації та регламенти

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

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

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

Кейс: пошук за внутрішньою базою знань у закритому контурі

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

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

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

Що змінили

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

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

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

Метрики до і після

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

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

Чим векторний пошук відрізняється від повнотекстового

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

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

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

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

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

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

Технічні питання, які ставлять до старту

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

Як часто перезбирати індекс?

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

Який запас за навантаженням залишиться?

Час відповіді зростає нелінійно після певної кількості одночасних запитів, тому запас рахуємо не на око. Знімаємо профіль на піковому сценарії, розділяємо індекс за колекціями й додаємо репліки для читання — тримаємо запас у рази, а не в одиниці відсотків.

Що відбувається після передачі?

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

Обговоримо завдання й повернемося з планом робіт

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

• Дані. Обсяг корпусу, формати (тексти, таблиці, скани, листування), частота оновлень і права доступу. Від цього залежить логіка нарізки документів на фрагменти й розклад переіндексації.
• Навантаження. Скільки запитів за годину, яка затримка відповіді вважається прийнятною, скільки одночасних сесій. Це визначає, тримаємо ми індекс в оперативній пам'яті чи розбиваємо на шарди.
• Контур. Де фізично лежать дані, чи допустимий вихід у зовнішню хмару, хто володіє ключами. Якщо вихід заборонений, проєктуємо повністю локальний векторний пошук на серверах замовника.
• Критерії приймання. Набір еталонних питань з очікуваними відповідями та джерелами. Фіксуємо частку коректних влучань і частку відповідей «не знаю» замість вигадки — на цьому будується приймання.
• Ролі. Хто з боку замовника дає доступи до сховищ, хто підтверджує якість розмітки й хто приймає етапи. Без виділеного власника даних строки зсуваються на етапі інтеграції.
• Що надсилаємо у відповідь. План робіт за етапами із залежностями, оцінку строків діапазоном, склад команди із зонами відповідальності, схему контуру та перелік ризиків із планом на кожен.

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