AI тренер для бегунов в Telegram: 250 тренировок показали, что код надёжнее нейросети

Российский бегун создал AI тренера в Telegram на базе LLM (большой языковой модели, нейросети, которая понимает и генерирует текст) и за несколько месяцев реальной эксплуатации пришёл к выводу, который полезен любому, кто строит продукт с нейросетью: чем меньше свободы у модели, тем надёжнее результат.

Источник, авторский разбор разработчика AI тренера для бегунов, описывает не просто запуск бота, а эволюцию мышления. Полгода назад автор начал копировать свои тренировки в разные LLM и заметил: при точном промпте (текстовой инструкции для нейросети) модели выдают похожие планы. Но без ручной сборки контекста модель путает дни недели и забывает прошлую неделю. Из этого родился продукт, а из ошибок продукта родилась архитектура.

Ошибка с субботой, которая изменила всю архитектуру

Переломный момент описан конкретно. Пользователь написал боту «поменяй мне лёгкую в субботу», имея в виду перенос тренировки на субботу. Бот изменил план, но не в субботу, а в четверг.

Причина: в четверг уже стояла лёгкая тренировка, модель нашла два признака (easy и Saturday) и с уверенностью 0.92 выбрала ближайший подходящий объект, а не тот, который имел в виду человек. Формально классификация была корректной. Для пользователя результат был неправильным.

Из этого случая и десятков похожих сложился принцип: модель не обязана знать бизнес-правила продукта, если разработчик сам не превратил их в явный код.

Как устроен AI limit тренера: пять ступеней ограничения модели?

Автор описывает эволюцию архитектуры как последовательное сужение свободы LLM:

• «Пусть модель сама всё решает» стало первым и самым провальным подходом
• «Пусть решает, но вернёт JSON» (структурированный формат данных) добавило предсказуемость формы, но не смысла
• «Пусть предлагает, а код проверяет» переложило ответственность на программную валидацию
• «Пусть предлагает только из разрешённого набора» ограничило пространство вариантов
• «Пусть изменение сначала станет черновиком и ждёт подтверждения пользователя» добавило человека в цепочку

Каждый шаг делал продукт надёжнее. Разработчик прямо формулирует: главная ошибка большинства AI-продуктов не в выборе модели и не в промптах, а в том, что разработчики слишком долго пытаются заставить LLM принимать решения, которые давно должен принимать обычный код.

Одна модель, одна роль, одна JSON-схема

Ещё одно архитектурное решение: разделение ролей между моделями. Быстрая модель отвечает за классификацию (определение типа запроса) и маршрутизацию (направление запроса в нужный сценарий). Более мощная модель строит и пересчитывает план. Никогда обе роли одновременно.

Для составления плана модели передаётся не сырой диалог, а заранее собранный кодом контекст: профиль бегуна, якорные даты, календарная сетка, сжатая история нагрузки, факты об атлете. Ответ модель обязана вернуть строго по JSON-схеме с датами, типами тренировок, дистанцией и описанием.

После ответа код валидирует типы, отбрасывает тренировки задним числом, принудительно закрепляет день старта как гоночный слот. Если ответ не проходит валидацию дважды, включается запасной план, собранный по жёстким правилам прямо в коде, вообще без обращения к LLM.

Такой детерминированный fallback (запасной сценарий, который работает без нейросети) гарантирует: даже при сбое, таймауте или галлюцинации (когда модель уверенно выдумывает то, чего не было) пользователь получит рабочий план.

Почему главная метрика не пульс, а ощущение бегуна?

Центральная метрика продукта: субъективная оценка нагрузки от 1 до 10. Пользователь ставит её через кнопки Telegram, без участия модели. Та же шкала используется как контракт с LLM при планировании: модель обязана оценить ожидаемую нагрузку тренировки в тех же единицах.

Когда план оценён на 4, а факт на 9, это прямой сигнал перегруза, не требующий интерпретации. За время работы сервиса накопилось больше 250 тренировок с оценками и отчётами.

Автор отмечает: в большинстве спортивных приложений субъективный отчёт существует, но спрятан в глубине интерфейса, тогда как графики пульса и темпа вынесены на главный экран. AI limit тренера построен наоборот: сначала ощущения человека, потом данные с датчиков.

Что делать с этим прямо сейчас, по ролям

Автору Дзена. Принцип «сужай свободу модели» работает и для контента. Если вы используете нейросеть для генерации текстов, не давайте ей писать «как хочет». Задайте жёсткую структуру, ограничьте набор допустимых форматов, проверяйте результат по чек-листу. Это и есть подход AI limit тренера, применённый к вашей задаче.

Маркетологу. Кейс показывает, как строить AI-продукт для нишевой аудитории (бегуны) без огромного бюджета: Telegram как платформа, LLM как помощник с ограниченной ролью, субъективная метрика как конкурентное отличие.

Предпринимателю в РФ. Бот работает в Telegram, доступен без VPN. Из доступных в РФ LLM для подобных проектов подходят YandexGPT и GigaChat. Принципиальная архитектура (код решает, модель предлагает) не зависит от конкретной модели.

Как попробовать

1. Найдите бота «Клод де Пейс» в Telegram (точная ссылка в источнике не указана, ищите по названию).
2. Задайте боту параметры: ваш беговой опыт, цель и дату старта.
3. После каждой тренировки ставьте оценку нагрузки от 1 до 10, это ключевой вход для адаптации плана.

Частые вопросы

Нужен ли беговой опыт, чтобы пользоваться ботом?

Источник не указывает ограничений по уровню подготовки. Бот строит план на основе данных, которые вы сами вводите: цель, опыт, доступные дни. Ключевой вход, оценка нагрузки от 1 до 10, не требует специальных знаний.

Какую LLM использует бот?

Автор не раскрывает конкретные модели. Известно, что используются минимум две: быстрая для классификации запросов и более мощная для построения планов. Архитектура спроектирована так, чтобы работать с разными моделями.

Можно ли применить этот подход не для бега, а для своего продукта?

Да, и в этом главная ценность кейса. Принцип «сужай свободу модели, отдавай критические решения коду, добавляй запасной сценарий без LLM» работает для любого AI-продукта: от чат-бота поддержки до генератора контента.