Playground у Leadmlyn: як тестувати бота перед тим як клієнти побачать помилки
Playground-режим Leadmlyn дозволяє протестувати бота в реальних умовах перш ніж він відповідатиме клієнтам. Методика тестування і що перевіряти.
Продукт
Playground у Leadmlyn: як тестувати бота перед тим як клієнти побачать помилки
Перше враження від бота у клієнта — незворотне. Якщо перший раз він отримав дивну відповідь або неправильну ціну — цей досвід залишається. Не обов'язково він напише скаргу, але довіри до бота вже не буде.
Саме тому в Leadmlyn є playground — режим, де ти як власник можеш симулювати розмову з ботом так само, як її бачить клієнт. До того, як клієнти побачать будь-що.
Навіщо тестувати бота перед запуском
Відкидаю очевидне: «щоб не соромитись перед клієнтами». Це правда, але є і операційна причина.
Бот дає відповіді на основі двох джерел: системного промпту і KB. Якщо в KB пусто або запис сформульований погано — бот не скаже «не знаю», він скаже щось схоже на правду. Це гірше, ніж «не знаю», бо клієнт може повірити і прийти з неправильними очікуваннями.
Ти не можеш знати, як бот реагуватиме на конкретне питання клієнта, не поставивши це питання самостійно. Playground — єдиний спосіб це зробити без ризику для репутації.
Що є в playground-режимі Leadmlyn
Playground доступний у дашборді в розділі «Playground». Він складається з двох частин: ліва панель — налаштування, права панель (або fullscreen на мобільному) — live-чат.
Реальна модель, реальний KB. Це не «симуляція з кешованими відповідями». Кожне повідомлення у playground робить справжній LLM-виклик з реальною базою знань твого бота. Ти бачиш саме те, що побачить клієнт — або дуже близьке до цього.
Статистика після кожного повідомлення. Під полем введення відображається: час відповіді в секундах, загальна кількість токенів за цей обмін, кількість чанків з KB що бот використав, і показник впевненості (confidence_score) у відсотках. Наприклад: «1.8с · 847 токенів · 3 chunks з KB · впевненість 78%».
Саме ця статистика — головна перевага playground над «просто написати боту в Telegram». У TG ти бачиш текст відповіді. В playground ти бачиш, на якій основі ця відповідь побудована.
Налаштування моделі і параметрів прямо тут. Не треба виходити в інший розділ — у лівій панелі можна змінити модель, temperature, глибину історії, тон, дозвіл на emoji. Зміни застосовуються до наступного повідомлення одразу, але не зберігаються в бот автоматично. Треба натиснути «Зберегти» — і лише тоді вони перейдуть у живий бот.
Підказки для тестування. У нижній частині чату є кілька заготовлених питань: «Скільки коштує?», «Чи можна з дітьми?», «Корпоратив на 25 людей», «Працюєте у неділю?». Це не весь checklist, але хороша точка старту для першого запуску.
Баланс витрачається. Важливий нюанс: тестові повідомлення в playground списуються з гаманця так само як повідомлення реальних клієнтів. Це не безкоштовний sandbox. Але при типовій вартості 0.001–0.003 USD за повідомлення — тест із 20–30 питань коштуватиме менше 5 центів.
Різниця між playground і реальною розмовою
Кілька важливих відмінностей, які треба мати на увазі.
Немає Telegram-форматування. У живому боті відповіді форматуються під Telegram: жирний текст, переноси рядків, emoji якщо дозволено. У playground — просто текст. Якщо хочеш перевірити форматування — зайди в Telegram до бота безпосередньо після збереження.
Немає постійної сесії між тестами. Кожен раз коли ти натискаєш іконку «очистити чат» — history обнуляється. Для наступного повідомлення бот не пам'ятає нічого з попереднього сеансу тестування. Це відповідає тому, що відбудеться після /reset у реального клієнта.
Контекст з попередніх розмов відсутній. У реальному Telegram-боті є cleared_at — мітка скидання розмови. Між тестами в playground цього поняття немає: кожна сесія чиста. Це добре для ізольованого тестування, але не відображає накопичений контекст після кількох сесій клієнта.
Unsaved changes тут застосовуються, але не зберігаються в бот. Якщо ти змінив temperature з 0.4 до 0.7 і надіслав повідомлення — воно відправилось із temperature 0.7. Але живий бот у Telegram досі використовує 0.4, поки ти не натиснеш «Зберегти».
Типовий сценарій:
1. Змінив KB-запис щодо цін
2. Зайшов у playground
3. Написав «скільки коштує на вихідний?»
4. Перевірив: відповідь правильна, confidence 82%, 2 chunks з KB
5. Натиснув «Зберегти» — налаштування пішли в живий бот
6. Готово
Коли повертатись у playground
Не тільки перед першим запуском. Playground — це інструмент, до якого варто повертатись у кількох ситуаціях.
Після кожного оновлення KB. Додав новий запис або змінив існуючий — протестуй одразу. Це займе 2 хвилини і підтвердить, що RAG «бачить» зміну і відповідає правильно.
Після зміни системного промпту. Промпт контролює тон, роль, обмеження. Будь-яка зміна в промпті може мати неочікувані сайд-ефекти на крайніх кейсах. Після редагування — 5 тестових питань.
Якщо клієнт повідомив про дивну відповідь. Це найважливіший сценарій. Якщо клієнт написав, що бот сказав щось неправильне — відтвори розмову в playground із тим самим питанням. Перевір confidence_score і кількість chunks. Визнач: проблема в KB (немає запису або він неточний) чи у промпті (бот вийшов за рамки ролі).
Перед акційними або сезонними змінами. Змінив прайс на свято — протестуй цінові питання. Запустив нову послугу — переконайся, що бот розповідає про неї правильно.
Якщо підсумувати: playground — це «приміряти перед виходом». Не можна знати, як бот поводитиметься з клієнтами, без того щоб самому пройти ті самі розмови.
Засновник Leadmlyn. Будую AI-менеджерів для leisure-бізнесу в Україні.