Як навчити ШІ відповідати «не знаю», коли в базі немає відповіді

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

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

Коли відповіді справді немає

«У базі немає відповіді» описує щонайменше чотири різні ситуації. Від того, яка саме сталася, залежить правильна реакція.

Немає документа. Питання стосується теми, яку база знань не покриває. Наприклад, клієнт питає про доставку в країну, з якою компанія не працює, а в документах про це нічого не сказано.

Недостатньо даних. Документ на тему є, але не містить потрібної деталі. Регламент повернень описує загальні правила, а питання про конкретний тип товару чи договору, якого там немає. Модель у такій ситуації схильна «добудувати» відповідь з загальних правил, і це найнебезпечніший випадок.

Конфлікт версій. Знайдено два документи з різними відповідями: старий і новий регламент, загальна політика і виняток для окремого регіону. Без правила, який документ має пріоритет, модель може обрати будь-який або змішати обидва.

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

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

Перевірка доказів

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

Пошук у більшості систем RAG працює за подібністю: він знаходить фрагменти, близькі за змістом до запиту. Але близькість не дорівнює відповіді. На питання «Чи можна повернути товар після 30 днів, якщо він був у використанні?» пошук легко знайде фрагмент про повернення протягом 14 днів. Тема та сама, а відповіді на конкретне питання там немає.

Тому корисно розділяти два кроки перевірки:

1. Чи знайдено релевантний контекст. Чи є серед фрагментів ті, що стосуються питання. Тут оцінюється якість пошуку.
2. Чи відповідь спирається на контекст. Чи кожне твердження у відповіді підтверджується знайденими фрагментами, а не загальними знаннями моделі. Тут оцінюється вірність відповіді джерелу.

Практичні прийоми, які допомагають:

• Просити модель спершу знайти цитату. Інструкція виду «наведи фрагмент, який прямо відповідає на питання; якщо такого немає, позначи це» робить відсутність доказу явною.
• Структурований результат. Відповідь повертається з полями: статус (відповідь, уточнення, обмеження, передача людині), текст, ідентифікатори використаних фрагментів. Це дозволяє коду перевірити, що статус «відповідь» має хоча б одне посилання на фрагмент. Але пам'ятайте: структура не доводить, що модель вибрала статус правильно.
• Окрема перевірка відповідності. Для критичних тем можна додати другий крок, який перевіряє, чи твердження відповіді містяться в наведених фрагментах.

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

Окремо про пороги подібності. Число, яке повертає векторний пошук, показує близькість текстів у певному представленні, а не ймовірність, що фрагмент містить правильну відповідь. Універсального порогу немає: він залежить від моделі ембеддингів, мови, стилю документів і того, як розбито текст. Поріг можна використовувати як один із сигналів, але налаштовувати його треба на ваших даних.

Чотири реакції

Коли повної відповіді немає, у асистента є не одна, а щонайменше чотири корисні реакції.

Відповісти. Знайдено фрагмент, який прямо відповідає на питання, і права дозволяють його показати. Асистент відповідає і, бажано, вказує документ, на який спирається.

Уточнити. Питання неоднозначне, а відповідь залежить від деталі, яку можна запитати. Наприклад, правила різні для фізичних і юридичних осіб, а з питання незрозуміло, хто питає. Уточнення часто корисніше за відмову: воно перетворює «не знаю» на «знаю, якщо скажете ось це».

Назвати обмеження. Документ є, але не покриває випадок. Асистент чесно каже, що саме відомо, а що ні: «У регламенті описано повернення протягом 14 днів для неношених товарів. Для товарів після використання умов не знайдено».

Передати людині. Відповіді немає, уточнення не допомагає, а питання важливе. Асистент передає його відповідальному співробітнику з контекстом, щоб клієнтові не довелося повторювати все спочатку.

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

Як сформулювати корисну відмову

Погане «не знаю» закінчує розмову. Корисне «не знаю» дає людині наступний крок.

Корисна відмова містить три елементи:

1. Що саме не знайдено. Не загальне «я не можу допомогти», а конкретно: «у доступних документах немає умови для цього випадку».
2. Що відомо поруч, якщо це доречно. Загальне правило, яке є, з чітким позначенням, що воно може не стосуватися конкретного випадку.
3. Наступний крок. Яку деталь уточнити або кому буде передано питання і що буде далі.

Навчальний приклад відповіді:

«У доступному регламенті немає умови для цього випадку. Уточніть, будь ласка, тип договору: стандартний чи корпоративний. Якщо правила не знайдуться, ми передамо питання спеціалісту».

Чого варто уникати у формулюваннях:

• Вигадувати впевненість. Фрази «найімовірніше», «зазвичай» перед припущенням, що не підтверджене документом, клієнт сприймає як відповідь.
• Розкривати закрите. Відмова через права не повинна натякати на зміст документа: «я не можу сказати, що відповідно до наказу про звільнення...» уже розкриває інформацію.
• Обіцяти те, чого система не робить. Якщо передача людині не налаштована або не має часу відповіді, не варто писати «з вами зв'яжуться протягом години».

Дві групи помилок

Будь-яке налаштування поведінки «не знаю» зсуває баланс між двома помилками.

Хибна відповідь. Асистент відповідає, хоча доказів немає або вони неправильні. Ціна залежить від теми: неточність у загальному описі продукту менш шкідлива, ніж хибна умова договору чи неправильна сума повернення.

Зайва відмова. Асистент каже «не знаю», хоча відповідь є в документах. Ціна теж реальна: клієнт іде до оператора, навантаження не зменшується, довіра до асистента падає.

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

Практичне правило: вимірюйте обидві помилки окремо і завжди разом. Якщо після зміни правил хибних відповідей стало менше, перевірте, скільки з'явилося зайвих відмов. Якщо ціна хибної відповіді для певної теми висока (фінанси, юридичні умови, безпека), для неї можна свідомо допустити більше відмов і передач людині. Для довідкових тем баланс може бути іншим.

Налаштування за реальними зверненнями

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

Навчальна контрольна вибірка на 100 питань

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

Як працювати з вибіркою:

1. Збирайте питання з реальних звернень, а не вигадуйте зручні. Найцінніші: ті, на яких асистент уже помилявся.
2. Розмітку робить людина, яка знає процес, і окремо фіксує, чому реакція саме така.
3. Змінюйте одне правило за раз і порівнюйте результати на тій самій вибірці.
4. Не додавайте приклади з контрольної вибірки в промпт, інакше ви перевіряєте запам'ятовування.
5. Переглядайте вибірку, коли змінюються документи, продукти або типові питання клієнтів.

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

• Відмови, після яких оператор швидко знайшов відповідь у документах. Це зайві відмови, і вони часто вказують на проблему пошуку або розбиття тексту.
• Відповіді, які оператор виправив. Це хибні відповіді; кожна з них є кандидатом у контрольну вибірку.
• Часті питання без відповіді. Це не помилка асистента, а сигнал для власника бази знань: бракує документа або розділу.

Останній пункт часто дає найбільшу практичну користь. Чесне «не знаю», зібране в статистику, показує, які знання компанії не записані, і допомагає вирішити, що задокументувати першим.

Висновок

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

Що можна зробити на своєму процесі:

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

Якщо вам важливо, щоб асистент чесно відповідав за документами компанії, команда BotLabs може розібрати це з вами на 15-хвилинній консультації. Обговоримо, які питання надходять найчастіше, де зараз виникають хибні відповіді і зайві відмови та з якої контрольної вибірки почати. Наступним кроком визначимо, що перевірити на ваших реальних зверненнях.

Часті запитання