Семантичний пошук та ембедінги у компанії

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

Ембедінг — це представлення тексту у вигляді вектора чисел. Модель ембедінгів (нейронна мережа, натренована на великому корпусі текстів) відображає кожне речення у багатовимірному просторі так, що речення зі схожим значенням опиняються близько одне до одного, а з різним — далі. Це не пошук за хешами чи n-грамами — це геометрія значення.

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

Механізм у скороченні:

1. Кожен фрагмент бази знань перетворюється на ембедінг один раз (під час індексації).
2. Запит користувача перетворюється на ембедінг у реальному часі.
3. Движок обчислює косинусну подібність між вектором запиту та векторами документів.
4. Повертає фрагменти з найвищою семантичною збіжністю, незалежно від використаних слів.

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

Використовуємо BGE-M3, запущений локально через Ollama. BGE-M3 генерує 1024-вимірні вектори, підтримує багатомовність (включно з українською) без необхідності перекладу запитів і працює на CPU корпоративного сервера — жодні дані не залишають вашу мережу під час індексації.

Коли дані є конфіденційними або підпадають під RODO, обираємо локальний хостинг. Для публічних даних (наприклад, каталог продуктів без персональних даних) хмарний ендпоінт є прийнятним за умови маскування PII перед відправкою.

Вектори зберігає векторна база. У нашому стеку це Qdrant, запущений на власному сервері (локальне сховище, без вихідних з'єднань). Qdrant підтримує:

• пошук ANN (наближене найближче сусідство) з індексом HNSW — мільйон векторів за кілька мілісекунд,
• payload filtering — шукай семантично лише в документах категорії «процедури HR» або лише в активних продуктах,
• named vectors — той самий документ має ембедінг для пошуку та окремий для реранкінгу.

Альтернативи — pgvector (розширення PostgreSQL — хороший варіант, якщо хочете одну базу даних для всього) та Weaviate (повноцінна платформа з власною схемою). Qdrant обираємо для проектів, що потребують високої пропускної здатності запитів та ізоляції даних на рівні колекцій.

Гібридний пошук поєднує результати повнотекстового (BM25) та семантичного пошуку і об'єднує їх через реранкінг. Це ключово при:

• запитах про код або номери — «закон 2025/0048» знаходить точніше через BM25, а не через семантику,
• запитах про власні назви — моделі ембедінгів гірше справляються з унікальними назвами продуктів, SKU, прізвищами,
• коротких однослівних запитах — замало контексту, щоб семантика дала перевагу.

На практиці гібридний движок: шукає паралельно BM25 та ANN, об'єднує результати Reciprocal Rank Fusion (RRF), а потім реранкер (cross-encoder) оцінює їх знову з урахуванням повного контексту запит+фрагмент. Результат: вища якість при різних типах запитань, ніж міг би дати один механізм.

Детальніше про цей патерн у статті RAG чи fine-tuning — гібрид є однією з причин, чому RAG так добре масштабується на різноманітних базах знань.

RAG (retrieval-augmented generation) — це архітектура, в якій генеративна модель не відповідає «з голови», а спочатку отримує знайдені фрагменти ваших знань, а потім формує відповідь з цитуванням джерел. Ембедінги та векторна база — це саме те «пошук», що в центрі RAG.

Практичний пайплайн:

1. Документ ділиться на фрагменти (chunking — зазвичай 256–512 токенів з накладенням).
2. Кожен фрагмент вбудовується (ембедінг) і зберігається в Qdrant з метаданими (категорія, дата, відділ).
3. Запит користувача вбудовується і шукається в Qdrant.
4. Top-k фрагментів потрапляють як контекст до LLM через router моделей.
5. Модель відповідає виключно на основі цих фрагментів, наводячи цитати.

Якщо пошук не знаходить фрагмент з достатньою відповідністю (поріг подібності), система каже «не знаю» і ескалує до людини — замість того, щоб вигадувати. Це human-handoff, а не недолік архітектури.

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

Не кожна база знань потребує ембедінгів. Варто впровадити, коли:

• Користувачі не знаходять потрібні документи, хоча вони існують — бо запитують інакше, ніж написана документація.
• У компанії понад кількасот документів, і різні відділи називають ті самі поняття по-різному.
• Ви хочете створити асистента, який відповідає на запитання на основі внутрішніх даних (RAG).
• Дані стосуються багатьох мов або клієнти пишуть неформально (обслуговування клієнтів, e-commerce).

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

Перевірте готовність організації у оцінці готовності AI — один з вимірів безпосередньо стосується стану бази знань.

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

• Індексація до кількох тисяч фрагментів на стандартному сервері CPU триває хвилини.
• BGE-M3 локально: нульова ліцензійна вартість, вартість обладнання або VPS-сервера.
• Хмарні ембедінги: кілька центів за мільйон токенів (менше 1 USD за типову базу знань SME).
• Qdrant self-hosted: безкоштовний (open-source), вартість хостингу.

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

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

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

Повнотекстовий пошук (наприклад, Elasticsearch, PostgreSQL FTS) шукає документи, що містять задані слова або їхні форми. Семантичний пошук перетворює запит на ембедінг і шукає документи зі схожим значенням, незалежно від використаних слів. На практиці: клієнт, який запитує про «скаргу», потрапляє на процедуру, описану словом «звернення», чого класична пошукова система не пов'яже.

Лише якщо обрати хмарну модель ембедінгів. При локальному BGE-M3 (Ollama) дані не залишають вашу інфраструктуру під час індексації. До генеративної моделі потрапляє лише контекст знайдених фрагментів, попередньо замаскований нашим роутером зі змінними PII. Чутливі дані можуть залишатися виключно локально протягом усього пайплайну.

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

Пілот на одному сегменті знань (наприклад, FAQ обслуговування клієнтів або процедури HR) зазвичай займає кілька тижнів, залежно від стану та обсягу даних. Час збільшується через неузгоджену базу знань, що потребує впорядкування, або необхідність інтеграції із зовнішньою системою (CRM, ERP). Детальніше про етапи впровадження у статті з чого почати впровадження AI.

Сам по собі семантичний пошук не порушує RODO. Ключові питання стосуються того, що індексується і де зберігаються вектори. Якщо документи містять персональні дані, діє RODO: правова основа, мінімізація даних, право на видалення. При локальному хостингу (Qdrant on-prem, BGE-M3 локально) дані не залишають вашу інфраструктуру. Юридичні деталі описані у статті AI Act та RODO 2026.