Чому вибір embedding-моделі для RAG визначає якість відповідей
RAG працює у два такти: спочатку пошук у внутрішній базі знань, потім генерація відповіді за знайденими фрагментами.
Якість відповіді обмежена якістю вилучення — якщо на першому кроці повернулися не ті уривки, модель добудовує текст загальними уявленнями про світ, а не вашими документами.
Різницю задає embedding-модель: вона вирішує, що вважати близьким за змістом. Слабка модель уловлює збіг рідкісних слів і абревіатур замість сенсу — у топ потрапляють нерелевантні фрагменти, сусідні розділи або застарілі редакції. Далі це видно у відповіді: вона звучить упевнено, але спирається не на джерело, а на здогад.
Ціна такої помилки накопичується непомітно. Користувачі перестають довіряти пошуку по базі знань і повертаються до ручного перебирання файлів, а команда виправляє формулювання після кожної видачі.
Окрема стаття — частота переіндексації корпусу: від того, як модель нарізає текст на фрагменти і як рахує близькість, залежить, скільки даних доведеться перераховувати під час оновлення документів і під час зміни самої моделі.
Тому вибір embedding-моделі для RAG — не деталь реалізації, а інженерне рішення з вимірюваними наслідками: частка релевантних фрагментів у топі, частка відповідей із посиланням на документ, час повної переіндексації після правок корпусу.
Як ми підбираємо модель під конкретний корпус і як перевіряємо результат до переходу на неї — розбираємо далі.
Що дає правильно підібрана модель: вимірювані ефекти
Першу метрику — частку релевантних фрагментів — знімаємо на своєму наборі з 100–200 реальних звернень: чи потрапляє правильний фрагмент у перші п’ять результатів пошуку.
Модель, підібрана під мову й термінологію конкретної документації, піднімає цю частку приблизно з половини запитів до 85–95%.
Загальні відкриті рейтинги на кшталт MTEB беремо як орієнтир, але вирішальним залишаємо замір на даних замовника — вони не знають ваших скорочень і внутрішньої лексики.
Стійкість до перефразувань перевіряємо окремо: те саме питання ставимо в 6–8 формулюваннях, зокрема розмовних і з друкарськими помилками, і дивимося розкид видачі.
Якщо модель підібрана правильно, набір фрагментів майже не змінюється — відповідь не розсипається від перестановки слів або синоніма, і користувачеві не потрібно вгадувати «правильне» формулювання.
Час підготовки відповіді визначається пошуком, а не генерацією.
Розмірність вектора й спосіб побудови індексу вирішують, чи вкладається відбір фрагментів у частки секунди при зростанні бази в рази; ми залишаємо два маршрути — швидкий за короткими векторами і точний перерахунок для складних запитів — і перевикористовуємо вже пораховані вектори для повторюваних питань.
Зворотний ефект видно за обсягом ручних правок: коли в контекст потрапляють потрібні фрагменти, модель рідше добудовує факти, і оператор виправляє одну відповідь із десяти замість кожної другої.
Заміри «до» і «після» фіксуємо у звіті разом із методикою — їх можна повторити на нових даних і переконатися, що виграш не одноразовий.
Порівняння підходів: готова embedding-модель, донавчання, гібрид
Три шляхи різняться не «якістю моделі», а тим, скільки доменного сигналу потрібно закласти у вектори.
Готова модель загального призначення вже бачила різнорідні тексти і працює з коробки; донавчання на доменному корпусі зсуває векторний простір під вашу термінологію; гібридна схема додає до пошуку за змістом лексичний і закриває точні збіги.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готова модель загального призначення | Корпус до десятків тисяч фрагментів, термінологія близька до загальномовної, потрібен багатомовний корпус | Не розрізняє внутрішні синоніми й коди; якість упирається в стелю домену |
| Донавчання на доменному корпусі | Стійка термінологія, багато однотипних документів, є чим розмічати пари «запит — фрагмент» | Потрібен очищений корпус і розмітка; відкат до попередньої версії — окрема процедура; багатомовний корпус легко втрачає другу мову |
| Гібридний пошук по документах | Запити з артикулами, абревіатурами, точними формулюваннями | Два індекси й підбір ваги злиття видачі — зростає обсяг перевірок і час підтримки |
Вибір диктує корпус, а не розмір моделі. Якщо в документах живуть артикули й внутрішні коди, пошук за змістом їх не втримає — потрібен гібрид.
Якщо термінологія стійка й однотипна, окупається донавчання; на багатомовному корпусі воно потребує окремої перевірки, інакше друга мова просідає.
Тому йдемо від заміру: збираємо пари «запит — релевантний фрагмент», рахуємо частку знайдених на перших позиціях. Якщо готова модель тримає планку — донавчання не запускаємо і не витрачаємо корпус на завдання, яке вирішують нарізка на фрагменти й переранжування видачі.
Етапи впровадження: від аудиту корпусу до передачі в експлуатацію
Порядок робіт однаковий і для нового корпусу, і для заміни embedding-моделі в працюючому RAG-пошуку: спочатку вимірюємо, потім змінюємо.
Головний ризик — вибрати модель за чужими порівняльними таблицями: на демонстраційному наборі різниця між кандидатами непомітна, а на сканах, таблицях і застарілих редакціях саме вона вирішує, знайде співробітник відповідь чи ні.
- Аудит корпусу документів. Рахуємо обсяг, формати, частку сканів і таблиць, дублі, застарілі редакції. На виході — карта джерел і правила розбиття тексту на фрагменти.
- Розмітка перевірних питань для оцінки пошуку. 50–100 реальних питань співробітників з еталонною відповіддю та посиланням на документ-джерело. Набір далі не змінюється — інакше заміри непорівнянні.
- Порівняння моделей на своєму корпусі. Проганяємо кандидатів на одному наборі й дивимося частку потраплянь потрібного джерела в першу п’ятірку, окремо — якість на коротких і неточних запитах.
- Налаштування індексації. Розмір фрагмента й перекриття, метадані (версія, підрозділ, термін дії), поєднання векторного й точного пошуку, розклад переіндексації під час оновлення документів.
- Калібрування порогу «немає відповіді». Підбираємо, за якої близькості система відповідає, а за якої чесно повідомляє, що даних немає. Це прибирає впевнені вигадки на прогалинах у корпусі.
- Приймання якості пошуку. Фіксуємо цільові метрики й проганяємо контрольний набір. Розбіжність — привід повернутися до розбиття або моделі, а не переписувати питання.
- Передача в експлуатацію. Конфігурація, регламент переіндексації, контроль частки відмов, розмежування доступів і навчання команди замовника.
Артефакти передачі: схеми індексації, регламенти, документація
Рішення з пошуком по корпусу й генерацією відповідей живе довше за сам проєкт впровадження: корпус зростає, embedding-модель оновлюється, вимоги до доступу змінюються.
Усе, що не зафіксовано в схемах і регламентах, залишається у підрядника й перетворюється на єдиний спосіб щось виправити. Тому пакет передачі збираємо як робочий інструмент команди замовника.
- Схема індексації корпусу: джерела, правила розбиття на фрагменти, розмір вікна й перекриття, склад метаданих (джерело, дата, рівень доступу) поруч із вектором.
- Обґрунтування вибору embedding-моделі: які варіанти порівнювали на контрольному наборі питань і за якими метриками — частка потраплянь потрібного джерела у верх видачі.
- Регламент оновлення індексу: тригери переіндексації, інкрементальний добір проти повного перезбирання, час збирання, дії при збої.
- Політики доступу до даних: перенесення прав з документа на фрагмент, фільтри при пошуку, що відбувається з векторами при відкликанні доступу.
- План відкату: сумісність версій індексу й моделі, повернення попереднього збирання без втрати свіжих документів.
- Інструкція для внутрішньої команди: де лежать конфігурації, як додати джерело, як запустити переіндексацію, які перевірки обов’язкові перед викатом.
- Схема шляху запиту: нормалізація питання, пошук, фільтрація, переранжування, звернення до мовної моделі — із зазначенням місця кожного кроку.
Приймання йде за цим самим переліком: інженер замовника проходить регламент на своєму стенді, розбіжності закриваємо до передачі. Далі контур розвивається всередині компанії, без обов’язкової залежності від нас.
Кейс: перевели пошук по базі знань на нову модель
Замовник — сервісна компанія з базою знань на кілька тисяч документів: регламенти, договори, інструкції з обладнання.
Пошук працював на векторних представленнях, навчених на загальних текстах: на побутових питаннях видача була пристойною, але на внутрішній термінології в топ потрапляли близькі за змістом, однак неправильні фрагменти.
Співробітники підтримки звіряли відповідь із першоджерелом вручну — кожна відповідь розтягувалася на хвилини.
Ми порівняли кандидатів на публічному рейтингу якості пошуку по документах MTEB, відібрали три моделі й прогнали їх на власному наборі з кількох сотень реальних питань з еталонними фрагментами.
Вибирали не за середнім балом, а за часткою потраплянь потрібного фрагмента в першу трійку — на нашій термінології порядок лідерів виявився іншим.
Що змінили в контурі пошуку
Нарізку документів прив’язали до структури — заголовок, пункт, таблиця, — додали перекриття на межах і гібридну видачу: вектор плюс пошук за ключовими словами, з переранжуванням верхніх результатів. Незмінені файли більше не перераховуються: оновлення документа зачіпає лише його частини.
| Метрика | До | Після |
|---|---|---|
| Правильних відповідей без ручної звірки | 61% | 92% |
| Час пошуку по базі знань | 4–6 с | менше 1 с |
| Оновлення документа в індексі | ~40 хв | ~3 хв |
Через місяць після запуску частка звернень, де співробітник ішов перевіряти першоджерело, впала з 40% до 8%. Заміри й конфігурацію віддаємо разом із рішенням — результат можна повторити на своїй базі.
Що робити, якщо векторний індекс уже зібрано на іншому рішенні
Перевикористати індекс, зібраний на іншій моделі, напряму не можна: розмірність вектора, метрика близькості й поріг відсікання прив’язані до конкретної моделі, і старі вектори в новому просторі втрачають сенс.
Питання не в тому, чи можна обійтися без перерахунку, а в тому, як провести переіндексацію корпусу так, щоб видача не просіла, а сервіс не став.
Найпередбачуваніший шлях — паралельний індекс: новий збирається поруч зі старим, запис при додаванні й видаленні документів іде в обидва, а пошук до моменту перемикання обслуговує попередня модель. Пересбирання йде фоном, порціями, з обмеженням навантаження на кластер. Коли видача двох індексів на еталонному наборі запитів сходиться, трафік переводять поступово.
Зміна моделі без зупинки сервісу тримається на одному прийомі: ім’я моделі й версія індексу зберігаються в метаданих колекції, а видача читає їх із конфігурації, а не з коду.
Тоді перемикання — це зміна значення, відкат — повернення попереднього, а пересбирання не потребує правок у пошуку.
Технічні сумніви: обсяг корпусу, мови, оновлення даних
П’ять сумнівів повторюються на кожній оцінці — знімаємо їх до запуску, а не після перших скарг користувачів. Коротко: що перевіряємо на пілотній вибірці документів і який запас закладаємо в архітектуру індексу.
Чи вистачить індексу на весь корпус і як різати документи?
Обмежувач — не обсяг, а розмір фрагмента: великий розмиває сенс, дрібний втрачає контекст. Тримаємо 1-2 абзаци з перекриттям і перевіряємо запас на пілотній вибірці.
Документи кількома мовами — один індекс чи кілька?
Окремий індекс для рідкісної мови точніший за змішаний. Багатомовну модель беремо, коли мови представлені порівняно, і перевіряємо на питаннях, де мова запиту не збігається з мовою документа.
Що робити з таблицями й сканами?
Таблиці вивантажуємо у структурованому вигляді — інакше рядки втрачають зв’язок із заголовками. Скани розпізнаємо, критичні поля звіряє людина: помилка в цифрі гірша за її відсутність.
Як часто переіндексувати корпус?
Оновлюємо приростами за датою зміни, повний перерахунок — лише при зміні моделі або схеми розбиття. Сховище на pgvector оновлює частину колекції, не перебудовуючи решту.
Як переконатися, що пошук знаходить потрібне?
Збираємо еталонний набір питань з відомими відповідями й дивимося, як часто потрібний фрагмент потрапляє в перші позиції. Кожен розібраний провал стає новим тестом.
Обговоримо задачу: повернемося з планом та оцінкою за вашим корпусом
Предметна оцінка обсягу робіт виходить лише з ваших даних: універсальних цифр для вибору embedding-моделі не існує, усе вирішує корпус і те, як формулюють запити співробітники.
Надішліть вхідні зі списку нижче — цього достатньо, щоб повернутися з планом впровадження, етапами та складом пробного запуску.
- 20–50 реальних документів корпусу в тих форматах, у яких вони лежать зараз: скани, текстові файли, таблиці, сторінки внутрішніх баз знань.
- Мови та їхні частки — від цього залежить, впорається модель сама чи потрібне донавчання на вашій лексиці й абревіатурах.
- 20–30 реальних питань співробітників із фрагментами-еталонами: вони стають перевірним набором, на якому порівнюємо кандидатів.
- Поточний пошуковий контур: де зберігаються документи, як часто оновлюються, чи є розмежування прав доступу за розділами.
- Обмеження щодо розгортання: ваш контур або хмара, запас ресурсів, вимоги до зберігання даних.
- Вимоги до режиму роботи: допустима затримка відповіді, частка ручних перевірок, хто і як переіндексує корпус після оновлень.
За цими даними ми відбираємо двох-трьох кандидатів і проганяємо їх на вашому корпусі: рахуємо частку питань, де потрібний фрагмент потрапив у перші видачі, і перевіряємо стійкість на перефразуваннях.
На виході — план впровадження з порядком етапів, складом робіт і тим, що ви побачите після кожного кроку. Опишіть задачу — повернемося з оцінкою та планом.
