Чому конверсаційний пошук ламається на живих запитах
У конверсаційному пошуку сенс запиту майже ніколи не лежить в одній репліці. Користувач запитує «а якщо на дві філії?» — і весь зміст питання залишився в попередніх двох повідомленнях: який продукт, який тариф, що вже уточнили щодо термінів.
Система, яка обробляє кожну репліку як окремий запит, бачить лише набір слів без опори й повертає найближче за словами, а не за сенсом.
Основний розрив контексту діалогу виникає на уточнювальних запитах і займенниках. «Скільки це коштує», «а є дешевше», «він підійде для звітності» — тут немає жодного терміна, за який можна зачепитися напряму.
Додайте зміну теми в середині розмови й повернення до попереднього питання — і пошук за близькістю формулювань починає змішувати теми, підтягуючи фрагменти з чужих реплік.
Ціна помилки видна в метриках: частка нерелевантних відповідей зростає на довгих діалогах помітно сильніше, ніж на коротких, бо кожен наступний крок накопичує викривлення.
Користувач переформулює три-чотири рази, іде в підтримку або кидає сценарій — якість видачі падає саме там, де діалог мав економити його час.
Окрема причина — немає явної моделі стану розмови: система не зберігає, що вже встановлено, і не розрізняє, коли уточнення змінює запит, а коли доповнює його.
Тому розбираємо, як це закривається: який шар відповідає за переформулювання запиту з урахуванням історії, де підключається перевірка релевантності відповіді та як вимірювати, що діалог справді став коротшим.
Ефект від контекстного розуміння: метрики й класи відмов
Метрики рахуємо не за відчуттями, а на еталонному наборі діалогів: кілька сотень реальних звернень, розмічених за кроками — що запитали, що мали на увазі та яка відповідь вважається правильною.
Прогін іде на тіньовому трафіку, тому частка невдалих відповідей вимірюється на тих самих запитах, що надходять у продукт. Розмітку й підрахунок тримаємо на відкритому наборі метрик оцінювання RAGAS — шкала до і після однакова, порівняння коректне.
Головний зсув видно в структурі відмов, а не в середньому.
Клас, де система відповідає на останню репліку у відриві від попередніх (втрачений референт займенника, підміна сутності, відповідь із уже закритої гілки розмови), за контекстного розуміння скорочується в рази — саме він давав найбільше невдалих відповідей у багатокрокових діалогах.
Відмови «не зрозумів формулювання» залишаються, але перестають маскувати втрату контексту й видно окремо.
Час відповіді зростає не лінійно: збирання контексту — це окремий крок перед пошуком. Щоб утримати бюджет, обмежуємо глибину переранжування, кешуємо зв'язки «репліка + контекст» і не даємо переформулюванню розгортатися в багаторазовий прохід.
На виході важливіше не середнє, а хвіст: розрив між медіаною й найгіршими відповідями скорочується, бо важкі багатокрокові діалоги більше не йдуть найдовшим шляхом.
Навантаження на операторів — похідна метрика. Коли система утримує контекст, користувачеві не потрібно знову вводити вступні, і падає частка ескалацій і повторних звернень на ту саму тему.
Фіксуємо й зворотне: скільки уточнювальних питань система ставить до відповіді — зайве уточнення виводить із діалогу так само, як неправильна відповідь.
Перевіряємо порівнянням на одній вибірці: версія без контексту й версія з ним ідуть паралельно, метрики знімаємо подобово. Так видно, де зсув стійкий, а де випадковість вибірки.
Решту класів відмов розбираємо за причинами, а не за фактом «відповідь погана» — і це вже робота над наступним зрізом якості.
Режими конверсаційного пошуку та коли вони доречні
Режим відбору визначає, як система зіставляє переформульований запит із базою знань. Розмова додає контекст: на репліку «а якщо без передоплати?» лексичний пошук без підстановки попередньої теми поверне випадкові документи.
Тому спочатку запит переписується з урахуванням історії діалогу та займенникових відсилань, і лише потім потрапляє в конкретний режим відбору.
| Режим | Коли доречний | Обмеження режиму |
|---|---|---|
| Повнотекстовий відбір | Термінологія, артикули, коди, внутрішні регламенти, точні формулювання | Не розуміє синоніми й перефрази, на розмовних запитах дає пропуски |
| Векторний відбір | Розмовні запити, близькі за сенсом формулювання, різномовні каталоги | Втрачає рідкісні терміни й точні ідентифікатори, нестійкий до заперечень |
| Гібридна схема | Змішаний трафік: частина запитів точні, частина описові | Потребує налаштування ваги об'єднання рангів, складніше пояснювати видачу |
| Гібрид і переранжування | Висока ціна помилки: підбір, підтримка, юридичні документи | Зростає час відповіді, потрібен запас обчислювальних ресурсів під навантаження |
Вибір режиму — не смаківщина, а наслідок розподілу запитів і ціни помилки. Обмеження проявляються на краях: якщо в логах помітна частка реплік містить заперечення або точні коди, чиста семантика їх зріже, а якщо діалоги описові — лексика не знайде нічого.
Ми дивимося на розмічену вибірку реальних діалогів, рахуємо частку влучань у топ-3 і лише потім фіксуємо схему; у більшості проєктів старт — гібридний режим, переранжування вмикаємо точково там, де помилка дорожча за затримку.
Етапи впровадження: аудит діалогів, схема, налаштування, передача
Налаштувати конверсаційний пошук за демо-запитами не можна: реальні репліки коротші, ідуть з помилками та займенниками — «а він дешевший?», «той самий, але з доставкою». Поки не видно розподілу таких запитів, будь-яка схема залишається гіпотезою. Тому починаємо з аудиту діалогів і закінчуємо передачею регламентів вашій команді.
- Аудит діалогів. Вивантажуємо журнали звернень і розмічаємо, де пошук втрачає контекст: анафора, пропущений підмет, зміна теми всередині сесії. На виході — частка реплік, яким бракує попередньої.
- Схема контексту. Визначаємо, що живе в сесії: останні репліки, виділені сутності, вибрані фільтри. Окремо — умова скидання, інакше уточнення «ні, не цей» тягне за собою неправильний результат.
- Налаштування відбору. Ранжування, пороги релевантності, пріоритет свіжої репліки над історією, правила злиття фільтрів і розв'язання конфліктів між ними.
- Перевірка на живих запитах. Прогін на відкладеній вибірці реальних діалогів, а не на тестовому наборі: частка влучань у топ-3 і як часто користувачеві вистачає другої спроби.
- Пілот на частині трафіку. Порівнюємо з поточним пошуком на тій самій аудиторії та розбираємо діалоги, де стало гірше — зазвичай це зміна наміру в середині сесії.
- Передача регламентів. Схема контексту, інструкція з розмітки нових діалогів, дашборд якості та порядок розширення правил силами вашої команди.
Після передачі ваші фахівці змінюють пороги й правила відбору, не переписуючи ядро. Це і є критерій готовності: система розвивається всередині команди, а не через нас.
Що передаємо на руки: конфігурації, схеми, регламенти
Система не повинна залишатися «чорною скринькою», яку здатен супроводжувати лише її автор. Ми передаємо комплект артефактів, за яким ваша команда може змінювати сценарії відповідей, підключати нові джерела та розгортати контур з нуля. Нижче — що саме залишається у вас після здачі.
- Конфігурації системи — файли налаштувань пошуку й ранжування: ваги полів, пороги релевантності, глибина врахованого контексту діалогу, правила розбиття документів на фрагменти. Правляться без зміни коду, зі зрозумілим описом кожного параметра та його впливу на видачу.
- Схеми потоків даних — шлях контенту від джерела до індексу: завантаження, нормалізація, очищення, розмітка; окрема схема проходження запиту — від формулювання користувача через уточнення контексту до готової відповіді з посиланням на першоджерело.
- Політики доступу — розмежування ролей і колекцій: які джерела бачить кожна група користувачів, як перевіряються права в момент видачі відповіді, як обмежується цитування закритих документів.
- Документація — опис архітектури та призначення вузлів, формати обміну між ними, інструкція з локального запуску та типові несправності з ознаками.
- Регламенти оновлення — порядок викочування нової гілки моделі, перебудови індексу й правки сценаріїв: які перевірки запускаються до релізу, за яких відхилень якості реліз відкочується.
- Набір перевірочних питань з еталонними відповідями — за ним після будь-якої правки видно, чи не просів якість на ключових темах, і в яких саме сценаріях.
- Регламент спостереження — які метрики дивитися, що вважати деградацією якості, кому повідомляти про збій і в якому порядку діяти.
Передача йде не архівом, а розбором: показуємо, де що лежить, вносимо перші зміни разом з вашими інженерами та відповідаємо на питання по ходу. Після цього розвиток конверсаційного пошуку — додавання джерел, перенавчання ранжування, нові канали — не потребує повертатися до нас.
Кейс: як скоротили частку невдалих відповідей утричі
Замовник — служба підтримки з розподіленою першою лінією та базою знань у кілька тисяч статей на базі Zendesk.
Оператори шукали відповідь за ключовими словами: формулювання клієнта майже не збігалося з формулюванням статті, а контекст попередніх реплік у діалозі не враховувався взагалі.
Ламалося на трьох ділянках. Пошук видавав статтю-«сусіда» за темою, оператор ішов у ручний розбір або відповідав навмання — і клієнт повертався з тим самим питанням. У довгих діалогах втрачався зв'язок із попередніми повідомленнями, тому уточнення доводилося збирати заново.
Що змінили
Над базою знань зібрали конверсаційний пошук: запит розбирається з урахуванням історії діалогу, відповідь формується лише зі знайдених фрагментів і з посиланням на джерело.
За низької впевненості система не вгадує, а передає діалог оператору разом із зібраним контекстом — ескалація стала усвідомленою, а не аварійною.
Метрики до і після
| Показник | До | Після | Спосіб вимірювання |
|---|---|---|---|
| Частка невдалих відповідей | 34% | 11% | ручна розмітка вибірки діалогів |
| Повторні звернення з тим самим питанням | кожен четвертий | кожен десятий | зв'язка звернень у системі |
| Підбір відповіді оператором першої лінії | близько 4 хвилин | близько 40 секунд | журнал дій |
| Діалоги, закриті без ескалації | 61% | 83% | звіти черги підтримки |
Порівняння йде на одному наборі питань, розміченому вручну до і після впровадження, — зростання частки правильних відповідей не списується на сезонність. Додатково місяць спостерігали за зміною: відтік скоротився, повторні звернення стали поодинокими. Результат проєкту — пошук, якому оператор довіряє й на який спирається прямо в розмові.
Чим контекстне розуміння відрізняється від підстановки історії
Підстановка історії діалогу — це механічне склеювання останніх реплік в один запит. На двох-трьох кроках прийом працює, але в багатокроковому діалозі дає втрату контексту: ключова рання репліка витісняється свіжою, і модель відповідає на останню фразу, а не на намір користувача. Вікно зростає, а точність падає — бо обсяг історії не дорівнює структурі сенсу.
Причина в природі живого мовлення. Репліки повні еліпсисів і вказівників без антецедента: «а якщо навпаки», «порівняй із попереднім», «той самий фільтр, але ширше».
Якщо стан розмови ніде явно не зафіксовано, ці вказівники нема до чого прив'язати, і пошуковий запит залишається неповним. Контекстне розуміння відрізняється тим, що кожен новий крок переформульовується в самостійний запит із відновленими сутностями й обмеженнями.
Інженерно це виноситься в окремий шар стану: активна тема й підтема, уточнені умови, зняті та відкинуті варіанти, точка повернення при зміні гілки. Шар оновлюється на кожній репліці й передає пошуку готове формулювання, а не переказ листування.
Видача при цьому гібридна — вектор за смисловими поданнями тексту плюс лексичний відбір за ключовими словами в Qdrant, щоб рідкісні терміни й артикули не губилися за узагальненням.
Перевіряється утримання теми діалогами з провокаціями: зміна підтеми й повернення до вихідної, додавання уточнення, заперечення сказаного раніше. Такий набір проганяється після кожної зміни логіки, і видно частку кроків, де сенс збережено. Саме вона, а не довжина промпту, визначає, чи витримає система розмову на десять кроків.
Технічні сумніви: термінологія, дані, інтеграції
Технічні фахівці замовника ставлять на прийманні ті самі питання — і вони справедливі: система працює з їхніми документами й має вписуватися в їхній контур. Розбираємо сумніви, які звучать найчастіше.
Як система зрозуміє нашу предметну термінологію та внутрішні скорочення?
Перенавчати модель з нуля під вашу мову не потрібно. Словник предметних термінів, абревіатур і синонімів збирається з ваших же регламентів та історії звернень, а правила нормалізації запитів виносяться в окремий конфігураційний шар.
Якщо один об'єкт називають трьома різними словами, усі три потрапляють у словник — пошук знаходить документ за будь-яким із них.
Як обмежуються домисли та контролюються джерела?
Відповідь будується лише на проіндексованих документах, і кожне твердження супроводжується посиланням на першоджерело з номером розділу. Якщо підтвердження немає, система прямо про це каже, а не добудовує відповідь здогадками.
Поріг упевненості налаштовується: можна дозволити відповідь лише за збігу з двома незалежними джерелами.
Чи не побачить співробітник документи, до яких у нього немає доступу?
Обмін іде через сервісний обліковий запис, а права успадковуються з вашої системи: у видачу потрапляє лише те, що дозволено конкретному співробітнику. Те саме правило діє під час вивантаження історії питань для розбору.
Чи зможемо ми донавчати систему своїми силами?
Так. Словники, правила цитування й підказки щодо формату відповіді винесені в окремий шар, який правлять без нас. Ваш інженер додає термін або закриває цілу тему — зміна набуває чинності того самого дня, без перезбирання моделі та повторного приймання.
Обговоримо вашу задачу й повернемося з планом робіт
Щоб обговорення задачі було предметним, починаємо з вашого сценарію, а не із загальних питань: як користувач формулює запит, які уточнення робить другим-третім повідомленням, що вважає вдалою відповіддю.
На реальних прикладах одразу видно, де конверсаційний пошук втрачає контекст — на підстановці займенників, на сутності з минулої репліки або на зміні теми.
Що потрібно від вас для оцінки:
- 20-30 справжніх діалогів з очікуваною відповіддю — на них перевіряємо, як система тримає історію й уточнення.
- Де лежать дані та як часто змінюються: вивантаження, доступ до пошукового індексу або запити до вашої системи.
- Що не можна показувати й зберігати: правила знеособлення, строк зберігання історії діалогу.
- Вимоги до розгортання: ваш контур, ізольований сегмент мережі або зовнішній майданчик.
Що повернемо у відповідь:
- План робіт за етапами з точками приймання та метриками якості на кожному.
- Оцінку строків: коли запускаємо перший робочий контур і коли виходимо на цільову точність.
- Склад команди: хто відповідає за діалогову логіку, хто за пошуковий індекс, хто за розгортання.
- Наступний крок — коротка зустріч за вашими прикладами, після неї фіксуємо етапи та стартуємо.
Опишіть задачу в двох-трьох абзацах і додайте приклади запитів — повернемося з оцінкою та планом робіт.
