Помилки AI-бота — три типи, як ми їх ловимо і що робить власник

Бот не буде ідеальним з першого дня. Це не застереження — це архітектурний факт. Будь-яка система що спирається на LLM, Telegram API і базу знань яку заповнює живий бізнес, буде робити помилки. Питання не «чи помиляється» а «як ти про це дізнаєшся і що відбувається далі».

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

Три типи помилок — і чим вони різні

Я розділяю помилки бота на три категорії. Вони різні за природою, різні за частотою і потребують різних дій.

Технічні збої

Telegram недоступний. OpenAI повертає 429 (rate limit). Таймаут на нашому сервері. Падіння Redis. Це не «бот відповів неправильно» — це бот не відповів взагалі або відповів запізно.

Технічні збої помітні відразу і, як правило, торкаються всіх клієнтів одночасно. Якщо Telegram Business API лягає на 20 хвилин, це не ваша KB — це зовнішній сервіс. Ми не можемо це усунути, але можемо мінімізувати вплив через retry-логіку і graceful fallback.

KB-промахи

Клієнт запитав про ціну вечірнього сеансу в п'ятницю. Бот відповів ціною денного. Або взагалі сказав «уточніть, будь ласка, у адміністратора», хоча ціна є в базі знань.

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

LLM-галюцинації на цінах та умовах

Це рідкіше, але боляче. Бот сказав «знижка 20% для нових клієнтів», якої немає в KB і ніколи не було. Або назвав час роботи як «10:00-22:00» замість «11:00-21:00 у вихідні».

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

RAG-промахи

Окремо варто виділити ситуацію коли RAG технічно спрацював, але дістав не той документ. Клієнт питає про «дитячий лазертаг», KB має розділи «лазертаг для дорослих» і «дитячі свята» окремо, і пошук відповідає фрагментом про дорослий тариф.

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

Як Leadmlyn виявляє помилки

Помилки не стоять із піднятою рукою. Більшість з них треба активно шукати.

Sentry і логи серверних збоїв. Технічні помилки — таймаути, 5xx від OpenAI, збої Telegram delivery — летять у Sentry автоматично. Я бачу трасування, частоту і час. Якщо бот одного конкретного клієнта почав падати на доставці повідомлень, я знаю про це раніше ніж клієнт встигає написати в підтримку.

Метрики якості відповідей. Ми фіксуємо частку розмов де бот сказав «не можу допомогти» або «уточніть у адміністратора» (escalation-фраза). Різкий ріст цього показника для конкретного акаунту — сигнал: або KB поламався, або з'явився новий тип питань що бот не покриває.

Ручний аудит escalation-розмов. Автоматика не замінює ручний перегляд. Щотижня я виборково переглядаю розмови де спрацювала handoff-фраза — бот передав клієнта людині або відмовився відповідати. Частина з них — правомірна ескалація (складна рекламація, нестандартне питання). Але частина — це KB-дірка або погано сформульований промпт.

Фідбек власників. Найчесніше джерело. Власник пише «бот сказав клієнту, що ми працюємо до 20:00, але ми давно до 22:00» — і це пряма KB-помилка. Ми не залежимо від автоматики в цих випадках: людина побачила конкретний приклад.

Що слизьке крізь сітку. Чесно: деякі помилки ми не ловимо до моменту поки клієнт не повідомить. Якщо галюцинація стосується рідкісного сценарію — знижка для корпоративів, умови групового бронювання для 20+ осіб — вона може пройти непоміченою через автоматику. Тут допомагає тільки регулярний ручний аудит і фідбек.

Найчастіші KB-помилки — і як їх виправити

За досвідом аудиту розмов, є п'ять сценаріїв що повторюються.

1. Застарілий прайс. Бот називає стару ціну бо KB не оновлювали після зміни тарифів. Виправлення: оновлення розділу прайсу з датою актуальності. У промпті — інструкція перевіряти дату перед цитуванням ціни.

2. Неповне KB по сезонних умовах. «Ціна в літній період», «знижки в будні» — якщо цього немає в базі, бот або вигадає або не відповість. Виправлення: додати явний розділ «сезонні та тимчасові умови».

3. Конфліктуючі записи. В KB є два записи про те саме — старий і новий, і RAG витягнув старий. Виправлення: видалити або архівувати застарілий запис, а не залишати поруч.

4. Відсутність граничних умов. «Максимальна кількість людей на корт» або «мінімальний вік для квесту» — якщо не вказано, бот або промовчить або вигадає. Виправлення: явно вказати граничні умови у відповідних розділах.

5. Неправильна сегментація KB. Великий нерозбитий текст про всі послуги підряд. RAG бере перший семантично схожий шматок і він може містити не ту послугу. Виправлення: розбити на окремі записи по послузі/типу клієнта.

Детальніше про аналітику розмов і що вона показує — в матеріалі «Аналітика розмов: що бачить власник у dashboard».

Що власник може зробити сам

Для виявлення помилок не потрібні технічні знання. Потрібна система.

Тижневий перегляд escalation-розмов. Раз на тиждень, 20 хвилин: відфільтруй розмови де бот сказав «уточніть» або де клієнт написав «ти не відповів на питання». Подивись на 5-7 таких розмов. Це покаже де KB слабка.

Тестові питання в playground. Раз на два тижні тестуй бота власноруч. Задавай граничні питання — нестандартні часи, нестандартні групи, рідкісні послуги. Якщо бот відповідає правильно — добре. Якщо ні — є що виправити до того як клієнт зіткнеться.

Аналіз звернень у підтримку. Якщо клієнт пише напряму тобі після розмови з ботом — з'ясуй чому. В частині випадків це означає що бот не закрив питання або закрив неправильно.

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

Про те як правильно передавати розмову живому адміністратору — в матеріалі «Handoff до людини: коли і як бот передає розмову». Там є конкретна логіка того, в яких ситуаціях ескалація має відбуватись автоматично.

Помилка — це сигнал, не вирок

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

Leadmlyn будується навколо цього принципу. Ми не обіцяємо нульову кількість помилок — ми обіцяємо що в тебе є інструменти щоб їх побачити, і KB-редактор щоб їх виправити без нашої допомоги.

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

Про те які KPI реально показують якість роботи бота — в матеріалі «KPI які працюють: що вимірювати у AI-менеджера».