Семантичний пошук за документацією: де ламається
Пошук по базі знань ламається не в момент впровадження, а пізніше: корпус виріс із сотень документів до десятків тисяч, а логіка видачі залишилася такою самою.
Співробітник запитує «як оформити повернення за передзамовленням» — і отримує регламент щодо гарантії: слова збіглися, сенс — ні. Після кількох таких промахів людина перестає шукати взагалі.
Корінь у тому, що пошук за точними словами вимагає, щоб автор запиту вгадав формулювання автора документа. А термінологія розходиться: абревіатури, синоніми, відмінки й часи, різні назви однієї сутності в різних відділах.
Лематизація та словник синонімів витягують частину випадків, але перефраз не покривають — а запитують люди саме перефразом.
Окрема поломка — розрізнені джерела документів. Внутрішня вікі, мережеві папки, скани договорів, вкладення з пошти та вивантаження з облікових систем живуть самі по собі: версії розходяться, частина файлів лежить у двох редакціях без позначки, яка актуальна. Індекс, зібраний за одним джерелом, відповідає впевнено й неправильно — він просто не бачить решти.
Ціна нерелевантної видачі вимірюється не секундами відгуку. Співробітник, який двічі отримав не те, іде запитувати в чат до знаючого колеги — і те саме питання спливає заново в наступного новачка. База знань формально жива, фактично її оминають, а готові рішення дублюються.
Семантичний пошук за документацією закриває саме цей клас відмов: запит зіставляється зі змістом фрагмента, а не з набором слів, що збіглися. Розбираємо, як це влаштовано і що потрібно, щоб видача знову викликала довіру.
Що змінюється після впровадження: час відповіді та точність
Ефект вимірюється за чотирма метриками: час до відповіді, точність влучання в потрібний фрагмент, частка відповідей із посиланням на джерело та обсяг типових звернень до підтримки.
До впровадження їх доводиться збирати вручну — за логами пошукового рядка та розборами закритих звернень, після — вони рахуються автоматично на кожному запиті.
Час до відповіді скорочується не за рахунок «швидшого пошуку», а за рахунок зміни режиму. Ключовий пошук вимагає, щоб користувач угадав формулювання: неправильний термін — порожня видача, друга-третя ітерація запиту, потім дзвінок колезі.
Семантичний пошук і підхід RAG шукають за змістом, тому відповідь приходить із першої спроби — із десятків хвилин очікування задача перетворюється на хвилину-дві, включно з читанням джерела.
Точність зростає за рахунок того, що модель відповідає не «з пам'яті», а за вилученими фрагментами, і кожна відповідь несе посилання на документ, розділ і версію.
Частка відповідей із посиланням на джерело тримається близько до повної — це і є захист від класу відмов «відповідь повз»: якщо фрагментів не знайшлося, система чесно повідомляє про це замість правдоподібної вигадки. Окремо ведемо поріг релевантності та список тем, які за правилом переходять до живого спеціаліста.
Навантаження на підтримку падає нерівномірно, і це важливіше за загальне число. Перша лінія перестає бути довідковою службою: типові питання щодо регламентів, договорів і внутрішніх інструкцій закриваються самообслуговуванням, а на інженерів потрапляють лише спірні випадки.
Ми фіксуємо метрики до запуску, повторюємо замір через місяць роботи та розбираємо запити без влучання — саме вони показують, яких документів в індексі бракує або які розділи варто переписати.
Режими індексації та видачі: порівняння підходів
Схема видачі визначає, що взагалі потрапить у відповідь: точні збіги термінів, близькі за змістом фрагменти або об'єднаний список. Це не вибір «краще чи гірше», а різні профілі помилок — і добирати режим потрібно під потік запитів, а не під модний термін.
| Схема | Коли підходить | Обмеження |
|---|---|---|
| Добір за словами | Точні терміни, абревіатури, номери регламентів, артикули, назви розділів | Пропускає перефраз: запит «звільнення за власним бажанням» не знайде «розірвання за ініціативою працівника» |
| Векторний добір | Питання своїми словами, близькі формулювання, довгі описи ситуацій | Тягне змістовно близьке, але нерелевантне; слабкий на рідкісних кодах, цифрах і точних назвах |
| Гібридна схема з переранжуванням | Змішаний потік запитів, робочий контур RAG | Дорожча в налаштуванні та оцінці: потрібен набір еталонних пар «питання — фрагмент» для контролю якості |
Ключове для впровадження: режими сумісні між собою, а не взаємовиключні. Обидва індекси будуються з одного корпусу документів і живуть паралельно, а спосіб видачі перемикається параметром сервісу — переіндексація при цьому не потрібна.
Це дозволяє вводити гібридну видачу поступово: спочатку переранжування вмикається на частині запитів, видача порівнюється з базовою на еталонному наборі, і будь-яка зміна відкочується одним перемиканням.
Далі по ланцюжку RAG бере ті самі відібрані фрагменти — змінюється лише число кандидатів, що йдуть у генерацію. Тому якість відповіді впирається у відбір, а не в модель: слабкий відбір не врятує жодне переранжування.
Етапи впровадження: від аудиту корпусу до передачі
Порядок робіт вибудуваний від даних до перевірки: спочатку розбираємося, що лежить у корпусі та в якому вигляді, потім проєктуємо схему пошуку, і лише потім налаштовуємо обробку.
Такий порядок знімає головний ризик — пошук, який упевнено працює на показових прикладах і розвалюється на реальних регламентах і договорах.
- Аудит корпусу документів. Збираємо всі джерела, формати та редакції, позначаємо дублі, застарілі версії, скани без текстового шару, документи з таблицями та вбудованою графікою. На виході — карта корпусу з обсягом, часткою проблемних файлів і правами доступу за групами.
- Розмітка розділів. Визначаємо, що вважати цілісною одиницею пошуку — пункт, підрозділ або блок абзаців, і зберігаємо ієрархію заголовків. Тоді відповідь посилається на конкретний пункт документа, а не на файл загалом.
- Проєктування схеми. Фіксуємо, як формуються векторні представлення фрагментів, як зберігається зв'язок із першоджерелом і як застосовуються фільтри за правами доступу.
- Налаштування конвеєра обробки. Розпізнавання сканів, розбиття, оновлення індексу під час правки документа — без повної переіндексації корпусу.
- Контрольні питання. Готуємо набір із кількох десятків питань з еталонними відповідями та правильним джерелом, заміряємо, чи потрапляє потрібний фрагмент у перші рядки видачі.
- Приймання результату та передача. Розбираємо заміри, журнал змін та інструкцію з додавання нових документів, навчаємо співробітників.
Кожен етап закінчується артефактом, який можна перевірити: карта корпусу, схема розбиття, набір контрольних питань із результатами. На прийманні ви бачите працюючий семантичний пошук на своїх документах, а не презентацію.
Що передаємо на руки: схеми, регламенти, доступи
Рішення залишається у вашому контурі, а не в нашій інфраструктурі. Тому передаємо не лише працюючий сервіс, а й набір артефактів, за якими команда супроводу зможе розвивати його самостійно.
- Схема конвеєра — шлях документа від приймання до відповіді: розбір форматів, нарізка на фрагменти, векторизація, пошук і переранжування. Зазначено, на якому кроці що ламається і як це помітити.
- Регламент оновлення індексу — розклад і тригери перезбирання, правила обробки змінених і видалених документів, момент, коли перезбирання обов'язкове.
- Політики доступу — розмежування за ролями та групами: у відповіді показується лише те, на що користувач має права у вихідній системі.
- Карта інтеграцій — джерела, способи підключення, сервісні облікові записи, частота синхронізації та точки відмови.
- Документація з експлуатації — запуск, моніторинг, типові збої, порядок дій при падінні якості відповідей.
- Набір контрольних питань з еталонними відповідями — щоб вимірювати якість до й після правок у моделі чи даних.
- Журнал рішень — чому вибрано таку нарізку, розмір фрагмента й модель: щоб через пів року не розбиратися заново.
Передачу супроводжуємо розбором із вашою командою: показуємо, де що лежить і як перевірити зміну. Після цього джерела, документи й модель можна змінювати своїми силами.
Кейс: як зросли точність відповідей і швидкість видачі
Кейс впровадження семантичного пошуку: логістичний оператор Северный Путь зберігає 40 000 сторінок регламентів, інструкцій з обладнання та типових договорів.
Відповіді шукали вручну: співробітник проганяв пошук за ключовими словами, відкривав п'ять-десять файлів і все одно йшов уточнювати до автора документа. Клієнт чекав відповідь 20–40 хвилин, а частину формулювань співробітники давали з пам'яті — без підтвердження першоджерелом.
Метрики до і після
Розбили документи на смислові фрагменти й пов'язали кожен із вихідним розділом і датою редакції. Пошук тепер іде за змістом запиту, а не за збігом слів: відповідь збирається зі знайдених фрагментів і зобов'язана на них посилатися. Якщо підтвердження в базі немає, система повідомляє про це прямо замість правдоподібної здогадки.
| Показник | До | Після |
|---|---|---|
| Час підбору відповіді | 20–40 хвилин | 40–90 секунд |
| Відповіді з посиланням на документ | 46% | 94% |
| Запити, що пішли на уточнення авторові | 3 з 10 | 1 з 12 |
Контрольний набір і достовірність відповідей
Оцінок «на око» не було: зібрали контрольний набір із 120 реальних питань співробітників, для кожного заздалегідь відомий правильний документ. Достовірність відповідей рахували як частку запитів, де система знайшла потрібний фрагмент і послалася на нього.
Набір проганяємо після кожної правки пошукового індексу — регресії ловимо до випуску, а не в роботі з клієнтом.
Чим векторний добір відрізняється від добору за словами?
Добір за словами спирається на інвертований індекс: документ розбивається на терміни, для кожного зберігається список фрагментів, а вага рахується за частотою терміна в тексті та його рідкістю в усьому масиві.
Запит знаходить рівно ті абзаци, де слова є буквально, — включно з артикулами, номерами пунктів і абревіатурами. Зворотний бік — синоніми й одруки: «угода про закупівлю верстатів» і «договір постаки» для лексичного пошуку вже інша історія, збігів він не побачить.
Векторний добір працює зі змістом: і запит, і фрагмент перетворюються на числові представлення, близькість яких порівнюється напряму. Потрібний розділ знаходиться, навіть якщо спільних слів немає зовсім, — переформулювання, одруки та розмовні варіанти він тримає впевнено.
Але там, де важлива буква — код виробу, номер редакції, пункт регламенту — вектор веде в тематично схожий, але неправильний фрагмент.
Тому на практиці частіше виграють гібридні схеми: обидва ранжування йдуть паралельно, результати об'єднуються, а спірні позиції довизначає переранжування.
Такий режим штатно підтримує, наприклад, Elasticsearch — лексичний індекс, вектори та фільтри за метаданими живуть в одному сховищі, а не у двох незв'язаних системах.
Налаштування гібрида — це калібрування, а не перемикач. Вага кожного ранжування добирається на наборі реальних запитів співробітників, окремими правилами закріплюється пріоритет точних збігів і свіжих редакцій документа.
Міряємо результат часткою запитів, де потрібний фрагмент потрапив у першу п'ятірку, і повнотою відповіді — саме ці два числа показують, де ще губляться синоніми й одруки.
Сумніви щодо якості відповідей і приватності даних
Вигадані відповіді — майже завжди наслідок не пошуку, а генерації: якщо видача принесла нерелевантні фрагменти, мовна модель добудовує правдоподібний текст.
Тому відповідь збирається лише за знайденими фрагментами, з обов'язковим посиланням на вихідний документ, а за низької релевантності система чесно повідомляє, що відповіді в базі немає.
Друге джерело сумнівів — права доступу та якість розмітки. Мітка доступу успадковується від документа до кожного фрагмента й застосовується на етапі пошуку, а не після генерації: співробітник фізично не отримає абзац, на який не має прав.
Наскільки рівно документи розбиті на фрагменти, визначає влучання у видачу — цю частину перевіряємо на еталонних питаннях до запуску.
Як переконатися, що система не вигадує відповіді?
Генерація обмежена знайденим контекстом і порогом релевантності: немає відповідних фрагментів — замість домислу приходить «у документах відповіді немає». Якість перевіряємо на наборі еталонних питань, окремо рахуємо частку відповідей із коректним посиланням на джерело.
Як права доступу застосовуються до фрагментів?
Права виставляються на рівні фрагмента, а не всього документа, — інакше закриті розділи течуть у загальну видачу. Фільтр за доступами спрацьовує до генерації, тому заборонений фрагмент не потрапляє ні у відповідь, ні в контекст моделі. При зміні прав документ переіндексовується.
Чи можна розгорнути пошук у закритому контурі?
Так: індексація, зберігання та генерація працюють на ваших потужностях, без звернень до зовнішніх сервісів. Документи не покидають контур, вхід у систему — через вашу корпоративну авторизацію, а логи запитів залишаються під вашим контролем.
Обговоримо задачу: підготуємо оцінку та план робіт
Щоб оцінка була інженерною, а не «плюс-мінус порядок», нам потрібен не переказ задачі, а картина даних: скільки документів, у яких форматах і якими мовами, як часто вони оновлюються, хто і за якими ролями шукає.
Із цим набором ввідних уже зрозуміло, яке розбиття на фрагменти та яка стратегія індексації підійдуть, і де потрібне узгодження доступів.
У відповідь на опис задачі надсилаємо оцінку та план: схему пошуку, склад етапів, точки перевірки. У план одразу закладаємо метрики якості та спосіб їх заміру на вашому корпусі.
- склад робіт за етапами: підготовка корпусу, розмітка, індексація, пошуковий шар, інтеграція з вашими інтерфейсами;
- вимоги до даних: формати, мови, версійність, права доступу, регулярність оновлень;
- схему архітектури: де зберігаються вектори, як переіндексовуються лише змінені документи;
- метрики якості та методику їх заміру на вашому корпусі до початку робіт;
- порядок старту: пілот на одній предметній області, потім розширення на решту;
- ризики та план відкату: повернення до попереднього пошуку без втрати документів і налаштувань.
Опишіть задачу — що за документи, хто шукає і який результат вважаєте невдачею — і ми повернемося з оцінкою, схемою та планом впровадження.
