Семантичний пошук: чому підбір за словами не знаходить відповіді
Повнотекстовий підбір порівнює не сенс, а символи: він розбиває запит і документи на слова, зводить їх до основи та шукає перетини. Поки співробітник вводить ті самі терміни, що й автор документа, усе працює. Але варто сформулювати думку своїми словами — і видача порожня, хоча потрібний файл лежить у базі.
Перший розрив — синоніми та словоформи. Зведення до основи знімає частину розбіжностей, але не допомагає, коли в запиті «повернути товар», а в регламенті «відмова від покупки».
Перетину за словами немає — отже, для пошуку документ нерелевантний, хоча для людини це той самий процес.
Другий розрив — формулювання запиту. Питання співробітники задають живою мовою, а документи написані канцеляритом: «хто відповідає за приймання» проти «відповідальність за здійснення приймання».
Різні конструкції, різні частини мови, нульовий збіг за словами — і порожня видача на п’ятому-шостому запиті змушує людей шукати вручну по папках.
Семантичний пошук працює інакше: він переводить запит і фрагменти документів у векторні представлення та порівнює їх за близькістю сенсу, а не за літерами. Синоніми, словоформи й різні формулювання однієї думки перестають бути бар’єром. Нижче розбираємо, як це влаштовано і що дає на документах різного обсягу.
Що дає семантичний пошук: ефект у вимірюваних метриках
Перший замір, який робимо до і після впровадження, — частка запитів, де потрібний документ потрапив у перші результати видачі.
На корпусі в кілька тисяч сторінок пошук за ключовими словами дає її в межах 35–45%: формулювання запиту не збігається з формулюванням у тексті, синоніми й скорочення не знаходяться.
Після переходу на смисловий пошук із гібридною схемою — лексичний відбір плюс пошук за векторним представленням — показник піднімається до 75–90%. Працюємо на OpenSearch: обидва режими живуть в одному індексі, друга система не потрібна.
Другий показник — час до першого корисного документа. Раніше співробітник витрачав 10–20 хвилин на перебір нерелевантних посилань або йшов запитувати колегу; тепер видача за смислом закриває питання за хвилину-дві.
Наслідок видно за повторними зверненнями: питання на кшталт «де лежить регламент» доходять до носіїв знання в рази рідше, і це вже зміна навантаження, а не самооцінка зручності.
Окремо рахуємо клас відмов «документ є, але не знайдено» — коли текст лежить у системі, але пошук за словами його не піднімає через інше формулювання або назву розділу.
У еталонній вибірці такі запити провалювалися приблизно в половині випадків і закривалися людиною; після впровадження вони знаходяться в пошуку.
Якість видачі тримаємо під контролем: є еталонний набір запитів із розміченими правильними документами, за ним рахуємо метрики до впровадження та після і окремо дивимося рідкісні формулювання.
Порівняння підходів: векторний індекс, гібрид і правила
Вибір режиму визначає не «якість пошуку взагалі», а те, які промахи ви отримаєте на своєму корпусі. Векторний індекс знаходить смислові збіги під час перефразування, але втрачає точні ідентифікатори — номери договорів, артикули, рідкісні абревіатури. Пошук за правилами передбачуваний і пояснюваний, але потребує збігу запиту зі схемою.
Гібридний режим знімає цю суперечність: він об’єднує лексичний сигнал і близькість ембедингів, а фільтри за метаданими відсікають зайве до ранжування. Що підходить якому корпусу — в таблиці.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Векторний індекс | Різнорідний корпус, вільні формулювання запитів, важлива стійкість до синонімів | Потребує перезбирання при зміні моделі ембедингів, слабко ловить точні коди й рідкісні терміни |
| Гібридний режим | Змішані запити: сенс плюс точний ідентифікатор, кілька типів документів в одному індексі | Потрібно узгодити внесок сигналів і поріг відсікання, вищий час відгуку |
| Пошук за правилами | Вузький домен, вимога пояснюваності та повторюваності, регламентовані запити | Крихкий до перефразування, кожне нове поле документа — ручна правка правил |
На практиці режим обирають за складом запитів. Якщо в корпусі і проза, і точні ідентифікатори — починають із гібрида, а правила залишають для обов’язкових умов: доступ, термін, тип документа.
Обмеження кожного підходу при цьому відомі заздалегідь, і вибір режиму стає рішенням за даними, а не за смаком.
Як ми впроваджуємо: етапи робіт від аудиту до передачі
Етапи вибудовуємо так, щоб якість пошуку вимірювалася на кожному кроці, а не в кінці проєкту. Кожен етап закінчується перевірюваним артефактом: звітом за корпусом, схемою розбиття, набором тестових запитів.
- Аудит корпусу документів. Рахуємо обсяг, формати, частку сканів і таблиць, знаходимо дублікати та застарілі редакції. На виході — список джерел і правило, що потрапляє в індекс, а що відсікається як шум.
- Схема розбиття та індексування. Визначаємо межі фрагментів — розділ, абзац, таблиця, — щоб шматок тексту зберігав сенс без сусідів. Поруч із фрагментом зберігаємо номер пункту, дату, тип документа й права доступу.
- Розмітка запитів. Збираємо реальні формулювання співробітників і розмічаємо їх за темами та очікуваними документами. Це дає набір перевірок, на якому далі порівнюються варіанти пошуку.
- Налаштування режиму видачі. Шукаємо баланс між точним збігом слів і смисловим пошуком, задаємо фільтри за правами та свіжістю. Окремо перевіряємо короткі запити та запити з номером пункту.
- Замір якості. Рахуємо частку запитів, де потрібний документ потрапив у першу п’ятірку результатів, і розбираємо провали вручну. Поріг приймання узгоджуємо до початку робіт.
- Дослідна експлуатація та передача. Запускаємо на обмеженій групі, дивимося, що шукають і де кидають, правимо розбиття та видачу за фактом. Віддаємо конфігурації, схему індексування й регламент переіндексації, навчаємо адміністраторів.
Артефакти на виході: схеми, словники та регламенти оновлення
Семантичний пошук залишається робочим інструментом лише тоді, коли його можна змінювати без авторів системи. Тому передаємо не сервіс-«чорну скриньку», а комплект артефактів, за яким ваша команда супроводу сама оновлює корпус, розширює словники та розбирає інциденти видачі.
- Схема індексування — які поля документа потрапляють в індекс, на які фрагменти він ріжеться, з яким перекриттям і які метадані (розділ, версія, дата, права) зберігаються поруч із текстом.
- Словник термінів і синонімів предметної області — внутрішні абревіатури, назви продуктів, професійний жаргон; поповнюється без перезбирання індексу та правок коду.
- Правила попередньої обробки — нормалізація розмітки, розбір таблиць і вкладень, окремий шар розпізнавання для сканів: без нього частина корпусу просто не знаходиться.
- Політики доступу до розділів — які колекції документів кому видно; фільтрація відбувається на етапі пошуку, а не після нього, інакше закритий документ витікає через видачу.
- Регламент переіндексації — що оновлюється інкрементально при зміні документа, що потребує повного проходу, у якому вікні це запускається й як перевіряється, що нова версія індексу не гірша за попередню.
- Набір еталонних запитів і метрики якості — контрольні питання з очікуваними документами; за ними відрізните деградацію від разової скарги користувача.
- Експлуатаційна документація — карта сервісів, точки відмови, порядок відкату на попередню версію індексу, типові збої та дії при них.
Пакет передаємо разом із розбором на працюючій системі: показуємо, як додати новий розділ документів і як відкотитися, якщо якість видачі просіла після оновлення. Далі супровід іде силами вашої команди або нашої — за вашим вибором.
Кейс: час знаходження відповіді в базі документів скоротився
Кейс впровадження: виробнича компанія з корпусом технічної та нормативної документації — десятки тисяч сторінок регламентів, паспортів обладнання, інструкцій з експлуатації та внутрішніх стандартів.
Пошук працював за назвами файлів і збігом слів, тому результат залежав від того, чи вгадав фахівець формулювання.
До впровадження відповідь шукали ручним перебором: відкривали 8-12 документів, звіряли редакції, уточнювали в колег.
Середній час знаходження відповіді — 30-40 хвилин, а приблизно кожен п’ятий запит закінчувався висновком «у документах немає», хоча потрібний пункт існував в іншому формулюванні.
Навантаження на профільних фахівців зростало: до третини робочого часу йшло на пошук замість основної роботи.
Що змінили
Документи розібрали за структурою — розділи, пункти, таблиці, додатки — і нарізали на смислові фрагменти зі збереженням посилання на першоджерело.
Семантичний пошук зібрали як гібридну схему на Elasticsearch: векторні представлення відповідають за сенс, точний індекс — за номери, артикули та абревіатури. У видачі — фрагмент тексту й посилання на сторінку оригіналу.
Метрики до і після
Частка запитів зі знайденою відповіддю зросла з 78% до 96%, середній час знаходження скоротився з півгодини до двох-трьох хвилин. Навантаження на профільних фахівців упало приблизно вдвічі: питання, які закривалися перебором вручну, тепер знімаються самостійно.
Паралельно розширили оновлення індексу — нова редакція документа потрапляє в пошук того самого дня, і застарілі версії не спливають.
Чим відрізняється векторний індекс від збігу за словами
Інвертований індекс відповідає на точний збіг: запит розбивається на токени, і документ потрапляє у видачу, лише якщо ті самі токени в ньому є.
Це швидко й передбачувано, але працює лише коли формулювання відоме заздалегідь: «регламент розірвання» не знайде текст про «порядок припинення договору». Стеминг і словники синонімів закривають частину випадків, але не перефразування, не переклад і не одруки.
Векторне представлення переводить документ і запит в один числовий простір, де смислове зіставлення рахується як близькість векторів, а не як збіг рядків. Запит «як оформити повернення» знаходить абзаци про «процедуру скасування замовлення», хоча спільних слів у них немає.
Релевантність тут визначається відстанню між векторами — видача ранжується за сенсом, а не за частотою терміна.
Точний збіг при цьому не скасовується. Артикули, номери договорів, ПІБ, коди підрозділів і абревіатури векторна модель може розмити до схожих за сенсом, але чужих значень, а помилка тут дорожча за все.
Такі поля залишаються на рядковому пошуку з обов’язковим точним входженням — те саме стосується юридичних формулювань і заперечень.
У робочій системі обидва механізми збираються в комбіновану видачу: рядковий пошук дає точні влучання та фільтри, векторний — смислових сусідів, а об’єднання рангів і ваги налаштовуються під конкретний корпус.
Частина запитів маршрутизується явно: номерний іде в точний індекс, питання природною мовою — у векторний. Схему ставимо на штатних компонентах, наприклад Qdrant для векторів у зв’язці з інвертованим індексом для рядків.
Налаштування ваг — окрема робота з розміткою реальних запитів: дивимося, де гібрид програє чистому збігу за словами, і правимо нормалізацію рангів, щоб релевантність зростала не на тестах, а на живому потоці звернень.
Часті технічні сумніви перед початком робіт
Сумніви перед стартом зазвичай стосуються не самої ідеї семантичного пошуку, а того, як він поведеться на реальному корпусі: різнорідних файлах, сканах, правах доступу та постійних правках. Нижче — відповіді на те, що найчастіше уточнюють інженери й керівники напрямів до початку робіт.
Що буде з «брудними» документами — таблицями, колонтитулами, розірваними рядками?
Перед індексацією текст нормалізується: знімаються повторювані колонтитули, склеюються розірвані рядки, відновлюється структура таблиць, документ ріжеться на фрагменти з перекриттям і прив’язкою до розділу. Тоді шум не потрапляє у векторне представлення й не підмішується у видачу під час ранжування.
А якщо документи — скани без текстового шару?
Підключається розпізнавання: сторінка приводиться до тексту, а кожен фрагмент отримує оцінку впевненості. Фрагменти з низькою впевненістю позначаються й ідуть на ручну перевірку — так пошук не починає впевнено відповідати за сміттєвим розпізнаванням. Частку коректно розпізнаних сторінок ми вимірюємо на пілотній вибірці документів замовника.
Як розмежувати доступ, щоб співробітник не побачив зайвого?
Права успадковуються з джерела: файлового сховища або системи документообігу. Фільтр за доступними користувачеві документами застосовується до ранжування, а не після — інакше верх видачі може виявитися порожнім, хоча релевантні матеріали є. У журналі залишається запит і область видимості, у якій він виконувався.
Чи можна розгорнути пошук у внутрішньому контурі?
Так. Рішення розгортається в закритому контурі замовника: модель, індекс і сховище працюють локально, без звернення до зовнішніх сервісів. Оновлення — теж внутрішня процедура.
Що відбувається при оновленні бази знань?
Переіндексація інкрементальна: змінився документ — перераховується лише він, застарілі версії позначаються й випадають з видачі. Зміна моделі представлень потребує повного перерахунку — це планова процедура з вікном робіт, про неї ми попереджаємо заздалегідь.
Як довести, що якість пошуку справді зросла?
Фіксуємо набір реальних питань з еталонними фрагментами й рахуємо частку влучань у топ-5 і повноту відповіді. Той самий набір проганяється через пошук за ключовими словами — порівняння на одних даних показує, де саме семантика виграє, а де достатньо точного збігу.
Обговоримо задачу: як ми повернемося з оцінкою та планом
Щоб оцінка семантичного пошуку спиралася на факти, а не на здогадки, до першої розмови корисно зібрати кілька ввідних. Чим точніші вихідні дані, тим менше припущень у плані етапів і тим раніше видно, де саме якість підбору просідає на вашому корпусі.
- Приклади запитів — 15–20 формулювань ваших користувачів, включно з одруками, синонімами та вузькими термінами предметної області.
- Склад і обсяг корпусу — типи документів, формати (PDF, DOCX, скани, таблиці), приблизний обсяг, мови, чи є історія пошуку або ручна розмітка.
- Вимоги до доступу — де розгортаємо контур, чи потрібна ізоляція без зовнішніх звернень, хто видає облікові записи й узгоджує мережеві правила.
- Поточні механізми підбору — як пошук працює зараз: повнотекстовий індекс, фільтри за полями, ручні добірки, що дратує користувачів.
- Очікувані метрики — частка запитів із релевантним першим результатом, час до відповіді, кількість уточнювальних перезапитів.
За підсумками обговорення надсилаємо оцінку робіт і план етапів: підготовка корпусу, вибір моделі, налаштування пошуку, перевірка на ваших запитах, постачання в контур і передача документації. Опишіть задачу — повернемося з оцінкою та планом.
