Донавчання Embedding-моделі під домен замовника

Дообучення embedding-моделі: коли пошук не розуміє домен

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

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

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

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

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

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

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

Це саме той випадок, коли дообучення embedding-моделі на парах «запит — релевантний фрагмент» із вашої предметної області повертає потрапляння в топ. Розбираємо, як це закривається.

Що змінюється в якості пошуку після доменної адаптації

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

Адаптація зсуває векторний простір до мови бази знань: частка релевантних видач у першій трійці на еталонному наборі зростає з 40–55% до 85–90%, а середня позиція першого потрібного документа скорочується приблизно вдвічі.

Найсильніше ефект видно на синонімах, трансліті та внутрішніх скороченнях. «ГО», «КП», «СФ», абревіатури відділів і назви внутрішніх систем для загальної моделі майже не відрізняються від одруків, для адаптованої — стійкі смислові якорі.

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

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

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

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

Способи адаптації пошуку: порівняння підходів

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

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

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

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

Як відбувається дообучення моделі на доменних даних

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

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

2. Розмітка доменних пар. Збираємо пари «запит — релевантний документ» і додаємо складні негативи: близькі за темою, але не відповідні. Розмітку ведуть носії предметної області, спірні випадки розбирає окреме правило.

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

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

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

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

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

Що передаємо на виході: конфігурації, схеми, регламенти

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

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

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

Кейс: точність пошуку за внутрішньою базою знань до і після

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

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

Що знімали до робіт

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

Окремо відклали незалежну вибірку — 400 запитів, які не брали участі ні в дообученні, ні в підборі параметрів.

Що змінили і що стало

Дообучення embedding-моделі відбувалося на парах «запит — релевантний фрагмент», розмічених носіями домену. До векторного індексу на OpenSearch додали пошук за ключовими словами, переранжування й фільтр за правами доступу.

Потрапляння в топ-3 зросли з 47% до 86%, повнота на топ-10 — з 71% до 94%, середня позиція правильного документа змістилася з шостої на другу.

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

Що робити, якщо пошук уже працює на готовому рішенні

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

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

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

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

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

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

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

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

Чи не погіршиться модель на загальних запитах?

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

Як перевірити якість без еталонного набору?

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

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

Як часто дообучати модель?

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

Обговоримо задачу: з чого почати і що знадобиться від вас

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

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

Що варто підготувати до першої розмови:

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

Далі роботу беремо на себе: розбираємо корпус, збираємо розмітку пар «запит — релевантна відповідь», дообучаємо модель на домені й порівнюємо її з поточною на відкладеній вибірці.

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