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

Разработчик AI-тренера для бегунов в Telegram столкнулся с типичной проблемой: LLM неправильно интерпретировала запрос пользователя, изменив не ту тренировку. Решение — явные бизнес-правила в коде, а не в модели. Разбираем, как это работает и почему это важно для всех, кто строит AI-продукты.
Инцидент: как LLM перепутала дни тренировок
Автор проекта, который он называет Клод де Пейс, уже несколько месяцев разрабатывает AI-тренера для бегунов в Telegram. Однажды он добавил возможность менять расписание по свободной фразе в чате. Первый же реальный тест показал проблему: пользователь написал «поменяй мне лёгкую в субботу», имея в виду перенести лёгкую тренировку на субботу. План действительно изменился, но не в субботу — в четверг.
Расследование заняло пару минут: в четверг у пользователя стояла лёгкая тренировка, и модель формально нашла в сообщении два признака — easy и Saturday — и уверенно (confidence: 0.92) выбрала тот объект, который был ближе, а не тот, который имел в виду человек. С точки зрения классификации всё было сделано правильно. С точки зрения пользователя — совсем не то, о чём он просил.
Именно в этот момент сложился принцип, вокруг которого сейчас построена вся система: модель не обязана знать, какие ограничения являются бизнес-инвариантами продукта, если я сам не превратил их в явные правила. Код обязан это знать. Модель — нет.
Предыстория и контекст
Проблема, с которой столкнулся разработчик, знакома многим, кто использует большие языковые модели в реальных продуктах. LLM обучены на огромных объёмах текста, но они не понимают бизнес-логику конкретного приложения. Они могут отлично генерировать текст, но когда дело доходит до действий, которые должны соответствовать строгим правилам — например, «не переносить тренировку на день, когда уже есть другая», — модель может ошибиться.
В мире AI-продуктов это называется «проблемой галлюцинаций» или «непредсказуемостью» моделей. Многие разработчики пытаются решить её, добавляя более подробные промпты или увеличивая количество примеров. Но как показывает случай с AI-тренером, это не всегда помогает. Модель может быть уверена в своём ответе, но не учитывать контекст, который для человека очевиден.
Почему модель выбрала не тот день?
Модель проанализировала сообщение «поменяй мне лёгкую в субботу» и выделила два ключевых признака: «лёгкую» (easy) и «субботу» (Saturday). В расписании пользователя была лёгкая тренировка в четверг, и модель решила, что именно её нужно изменить, поскольку она была ближе к текущему дню. Модель не знала, что пользователь имел в виду перенос лёгкой тренировки на субботу, а не изменение той, что уже стоит в четверг.
С точки зрения классификации, модель действовала логично: она нашла объект, соответствующий признакам, и применила действие. Но она не учла, что «в субботу» — это целевой день, а не объект изменения. Это типичная ошибка, когда модель не понимает семантику предложения на уровне бизнес-правил.
Как код должен контролировать LLM
Разработчик пришёл к выводу, что модель должна быть ограничена явными правилами, написанными в коде. Он создал систему, где LLM используется для понимания намерения пользователя, но все действия проверяются и фильтруются через код. Например, если пользователь просит изменить тренировку, код сначала проверяет, есть ли тренировка в указанный день, и только потом разрешает изменение.
Этот подход называется «LLM как генератор намерений, код как исполнитель». Модель может предложить, что нужно сделать, но окончательное решение принимает код, который знает все ограничения. В случае с AI-тренером это означает, что модель может сказать «перенести лёгкую тренировку на субботу», но код проверит, не конфликтует ли это с другими тренировками, и если конфликтует — либо предложит альтернативу, либо откажет.
Технически это реализуется через так называемые «функции-инструменты» (function calling) в современных LLM API. Модель возвращает структурированный ответ с намерением и параметрами, а код обрабатывает этот ответ, проверяет его соответствие бизнес-правилам и выполняет только те действия, которые допустимы.
Кого затронет и как
Этот подход важен для всех, кто разрабатывает AI-продукты, особенно в сферах, где ошибки могут иметь серьёзные последствия: финансы, медицина, образование. Но даже в таких, казалось бы, безобидных приложениях, как фитнес-тренер, ошибка может привести к недовольству пользователя и потере доверия.
Для разработчиков этот кейс — напоминание о том, что нельзя полностью полагаться на LLM в критических функциях. Нужно проектировать систему так, чтобы модель была лишь частью пайплайна, а не единственным решающим элементом. Это также поднимает вопрос о тестировании: необходимо создавать наборы тестовых сценариев, которые проверяют, что модель не нарушает бизнес-правила.
Для пользователей AI-продуктов это означает, что даже самые умные модели могут ошибаться, и важно, чтобы разработчики предусматривали защиту от таких ошибок. В случае с AI-тренером, если бы не было явных правил, пользователь мог бы получить неправильное расписание и, возможно, пропустить важную тренировку.
Что будет дальше
Разработчик планирует расширять функциональность AI-тренера, добавляя новые типы тренировок и более сложные сценарии. Он намерен продолжать развивать принцип явных правил, делая систему более надёжной. В будущем можно ожидать, что подобные подходы станут стандартом в индустрии, так как всё больше компаний интегрируют LLM в свои продукты.
Вероятно, появятся фреймворки и библиотеки, которые упростят создание таких гибридных систем, где код и модель работают вместе. Пока же разработчикам приходится самостоятельно проектировать архитектуру, которая минимизирует риски, связанные с непредсказуемостью LLM.
Итог
Главный вывод из этой истории: LLM — мощный инструмент, но он не заменяет код. Бизнес-правила должны быть явно описаны в коде, а модель должна использоваться для понимания намерений, а не для принятия решений. Это не только предотвращает ошибки, но и делает систему более прозрачной и контролируемой. Если вы строите AI-продукт, помните: код решает, LLM помогает.