RAG у Leadmlyn: як влаштований пошук по базі знань і чому це важливо для якості

Якість відповіді AI-бота залежить не від того, «наскільки він розумний». Вона залежить від того, що саме бот отримав на вхід перед тим, як відповісти. І тут ключову роль відіграє RAG.

Якщо твій бот дає неточні відповіді — найчастіше проблема не в моделі. Проблема у тому, що бот або не знайшов потрібний фрагмент із бази знань, або знайшов не той. Саме це і вирішує RAG-підсистема.

Що таке RAG і навіщо він у Leadmlyn

RAG розшифровується як Retrieval-Augmented Generation — «генерація з пошуком». Ідея проста: перш ніж мовна модель формує відповідь, система знаходить у твоїй базі знань найбільш релевантні фрагменти і передає їх у контекст разом з питанням клієнта.

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

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

Як RAG працює в Leadmlyn крок за кроком

Коли клієнт пише повідомлення боту, відбувається ось що.

Крок 1 — Векторизація запиту. Текст повідомлення клієнта перетворюється на вектор — числовий «відбиток» змісту. Для цього ми використовуємо модель text-embedding-3-small від OpenAI. Вектор має 1536 вимірів і фіксується у пам'яті на час запиту.

Крок 2 — Пошук у векторній БД. Цей вектор порівнюється з векторами всіх фрагментів твоєї бази знань, які зберігаються у PostgreSQL з розширенням pgvector. Пошук відбувається за косинусною схожістю — знаходяться фрагменти, зміст яких найближчий до запиту.

Крок 3 — Відбір топ-N чанків. Система бере кілька найрелевантніших фрагментів (chunks). Ці фрагменти — це й є те, що бот «знає» для цієї конкретної відповіді.

Крок 4 — Формування контексту. Відібрані фрагменти додаються до запиту, який іде у мовну модель. Разом з системним промптом і історією розмови вони утворюють повний контекст для генерації.

Крок 5 — Відповідь. Мовна модель (gpt-4o-mini або інша за вибором) генерує відповідь, спираючись на те, що знайшлось у KB. ID використаних фрагментів фіксуються у полі retrieved_chunk_ids таблиці повідомлень — це дозволяє пізніше аудитувати, на основі чого була дана відповідь.

Весь цикл — від повідомлення клієнта до відповіді бота — займає в середньому 1.5–2.5 секунди при стандартному KB.

Що власник контролює в RAG

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

Чому якість KB критична для RAG

Є правило в машинному навчанні: garbage in, garbage out. У RAG воно діє особливо наочно.

Якщо в KB є запис «Наш клуб найкращий і ми надаємо безліч чудових послуг за доступними цінами» — жоден RAG не витягне з нього конкретну відповідь на «скільки коштує лазертаг на 6 людей». Бот або вигадає щось, або скаже «уточніть у менеджера», або видасть загальну фразу без конкретики.

Порівняй із записом: «Лазертаг — ціни: будній день — 180 грн/особа, вихідний — 220 грн/особа. Мінімальна група 4 особи. Тривалість сесії 45 хвилин.» — це вже конкретний факт, який RAG знайде і передасть боту без втрат.

Метрика впевненості (confidence_score) на кожній відповіді бота відображає, наскільки близькі знайдені фрагменти до запиту. Значення нижче 0.5 означає: бот відповідав без надійної опори на KB, або потрібного запису в базі просто немає. Це сигнал додати або уточнити відповідний запис.

Детальніше про те, як читати ці метрики в дашборді — у статті про KB-редактор.

RAG vs fine-tuning: чому ми обрали RAG для SMB

Fine-tuning — це процес додаткового навчання базової моделі на твоїх конкретних даних. Після fine-tuning модель «пам'ятає» твій прайс прямо в параметрах. Звучить привабливо. Але є кілька проблем.

По-перше, ціна. Fine-tuning GPT-4o-mini від OpenAI коштує $25 за мільйон тренувальних токенів. Для типового KB салону краси (200–400 записів) — разова вартість прийнятна. Але:

По-друге, актуальність. Після fine-tuning «знання» зафіксовані у ваганнях моделі. Змінив прайс — треба перенавчати. Додав нову послугу — перенавчай. Для leisure-бізнесу, де акції та ціни змінюються щомісяця, це операційний кошмар.

По-третє, якість на вузьких доменах. Fine-tuned моделі добре запам'ятовують формат, але погано узагальнюють на нові питання поза тренувальним набором.

RAG вирішує всі три проблеми: оновлення KB відбувається миттєво без перенавчання, вартість ембедингів при індексуванні мізерна (text-embedding-3-small — $0.02 за мільйон токенів), а пошук по актуальних даних надійніший за «пам'ять» fine-tuned моделі.

Чесний трейдоф: RAG може «не знайти» відповідь, якщо запис відсутній або погано сформульований. Fine-tuned модель у такому випадку вигадає щось схоже — що гірше, бо це не позначається як відсутність даних. З RAG власник бачить confidence_score і знає де діра в KB.

# Спрощена схема RAG-виклику у Leadmlyn

query_embedding = embed(user_message)         # text-embedding-3-small
chunks = vector_search(query_embedding, top_k=5)  # pgvector cosine search
context = build_context(system_prompt, chunks, history)
reply = llm.generate(context)                 # gpt-4o-mini або інша модель
log_usage(retrieved_chunk_ids=chunks, confidence=best_chunk_score)