1. Постановка задачи: сценарии теста, роли, метрики успеха
Постановка задачи: сценарии теста, роли, метрики успеха
Зачем мы делаем этого бота
Цель курса — разработать Telegram-бота, в котором пользователь проходит упрощённый «тест Тьюринга»: в каждом раунде он видит два текста (один написан человеком, другой — нейросетью) и пытается угадать, где какой. По итогам сессии бот показывает результат, а владельцу продукта доступна аналитика по прохождениям и качеству вопросов в виде метрик и дашборда.
Важное уточнение: это не классический тест Тьюринга из научной постановки (диалог с судьёй), а игровой A/B-формат на распознавание источника текста. Мы используем популярную идею «угадай, где AI», чтобы:
Справка о первоисточнике идеи: Turing test.
Роли и заинтересованные стороны
Чтобы система была продуктоориентированной, сначала фиксируем роли и их потребности.
| Роль | Кто это | Что хочет | Что считается успехом | |---|---|---|---| | Игрок (пользователь бота) | Любой пользователь Telegram | Быстро начать тест, понять правила, получить результат | Прошёл тест без путаницы, увидел итог, захотел повторить | | Администратор (владелец продукта) | Вы (создатель) | Видеть статистику, управлять контентом, улучшать качество | Дашборд отвечает на ключевые вопросы, контент легко обновлять | | Контент-менеджер (опционально) | Вы или помощник | Добавлять пары текстов, помечать метки/темы/сложность | Контент пополняется без ошибок, есть модерация | | Система аналитики | База + ETL/скрипты + дашборд | Получать события и агрегировать их | События полные, консистентные, пригодны для графиков |
В рамках курса мы обычно совмещаем роли администратора и контент-менеджера.
Объекты и термины проекта
Чтобы дальше (в коде, базе и дашборде) не путаться, фиксируем базовые сущности.
Пользовательские сценарии (user flows)
Ниже — сценарии, которые определяют функциональность первой версии (MVP). Чем лучше вы их пропишете сейчас, тем легче будет проектировать архитектуру, хранение данных и дашборд.
!Блок-схема прохождения теста пользователем
Сценарий игрока: первое знакомство
/start.Ключевой принцип: в первые 15 секунд пользователь должен понять, что делать, иначе конверсия в прохождение будет низкой.
Сценарий игрока: прохождение раундов
Каждый раунд должен быть максимально однозначным.
Отдельное решение, которое повлияет на метрики и данные: показывать ли правильный ответ сразу или только в конце. Для аналитики полезны оба варианта, но для «игрового» опыта часто лучше показывать в конце, чтобы не ломать вовлечённость.
Сценарий игрока: результат и повтор
Сценарий администратора: аналитика
Администратор должен отвечать на вопросы:
Админ-доступ можно реализовать разными способами:
В рамках курса удобнее делать web-дашборд, потому что он масштабируется и лучше подходит для визуализаций.
Сценарий контент-менеджера: управление вопросами
Минимальный набор операций:
В MVP допускается, что контент добавляется напрямую в базу или через простую админ-форму.
Ограничения и правила контента
Чтобы тест был честным и измеримым, важно заранее определить правила.
Требования к паре текстов
Что считаем «человечностью» в рамках продукта
Мы измеряем не философскую «разумность», а практическую неотличимость текста. Если пользователи часто принимают AI-текст за человеческий, значит:
И то, и другое важно видеть в метриках.
Метрики успеха: продуктовые, контентные, аналитические
Метрики нужны в двух местах:
Продуктовые метрики (вовлечённость)
| Метрика | Как трактовать | Зачем нужна | |---|---|---| | Количество стартов | сколько раз люди начали | верх воронки | | Конверсия в прохождение | доля пользователей, дошедших до конца | показатель понятности и интереса | | Среднее число раундов за сессию | сколько реально проходят | ранний индикатор скуки/сложности | | Retention (возврат) | возвращаются ли на следующий день/неделю | ценность продукта |
Если вам нужна простая формализация точности в тесте, используйте долю верных ответов:
Где:
Эта метрика пригодится и для итогового экрана, и для дашборда.
Контентные метрики (качество вопросов)
| Метрика | Как трактовать | Типичные выводы | |---|---|---| | Доля выбора A | как часто выбирают «A — человек» | если сильно > 50%, вероятен перекос в оформлении | | Сложность вопроса | доля ошибок на конкретной паре | можно отсортировать вопросы от лёгких к сложным | | Дискриминативность | различаются ли результаты между группами | помогает искать «нечестные» вопросы |
Простой ориентир: если пользователи угадывают «человека» почти всегда, вопрос слишком лёгкий (или AI-текст слишком «палится»). Если угадывают почти никогда, возможно, человеческий текст выглядит «как AI».
Аналитические метрики (качество данных)
Плохая аналитика чаще всего не из-за графиков, а из-за недособранных событий. Поэтому заранее определяем, какие события обязаны логироваться.
| Событие | Когда отправляем | Минимальные поля |
|---|---|---|
| start | пользователь начал | user_id, timestamp, источник (команда/кнопка) |
| session_created | создана сессия | session_id, user_id, mode, planned_rounds |
| round_shown | показан раунд | session_id, round_id, pair_id |
| answer_submitted | пользователь ответил | session_id, round_id, pair_id, choice, is_correct, response_time_ms |
| session_finished | сессия завершена | session_id, answered_rounds, correct_answers |
response_time_ms (время ответа) — очень полезное поле: оно помогает понять, где пользователь реально думает, а где кликает случайно.
Критерии готовности MVP
Чтобы не разрастись в бесконечный проект, фиксируем «готово», когда выполняется следующий минимум.
Риски и как их учесть в постановке
user_id и технических событий. Ознакомьтесь с базовой документацией платформы: Telegram Bot API.Что будет дальше в курсе
После постановки задачи логичный следующий шаг — спроектировать структуру данных (сессии, раунды, пары текстов, события), а затем перейти к реализации:
Эта статья — «контракт» проекта: если сценарии, роли и метрики зафиксированы, все последующие решения (архитектура, таблицы БД, события, дизайн дашборда) будут согласованными.