ИИ-бот в Telegram: пять нерабочих требований ТЗ
Задания на ботов с искусственным интеллектом всё чаще пишут с помощью самого искусственного интеллекта. Снаружи такой документ выглядит солидно: разделы, схема базы данных, системный промпт. Внутри же оказываются требования, которые невозможно выполнить или которые противоречат друг другу через две страницы. Ниже разберём пять пунктов, встречающихся в таких заданиях чаще всего, и расскажем, что предлагаем вместо них.
Требование 1: посимвольная печать сообщений
Первый пункт звучит так: "сообщения печатаются посимвольно, задержка от 20 до 40 мс на символ". В Telegram нет механизма, который печатает текст по буквам. Есть индикатор "печатает" и есть правка уже отправленного сообщения, однако частые правки упираются в ограничения платформы. Вдобавок это требование обычно соседствует с другим: "ответ должен приходить не позже пяти секунд". Посимвольная печать ответа в 400 знаков заняла бы двенадцать секунд только на вывод, то есть пункт нарушает сам себя.
Рабочая замена выглядит живее оригинала. Сначала показывается индикатор "печатает", затем ответ появляется частями по мере того, как его генерирует модель. Человек видит движение через секунду после своего сообщения и не ждёт молча, пока сервер думает.
Требование 2: RAG для памяти диалога
Второй пункт требует "для памяти диалога реализовать RAG". Почти всегда в том же абзаце описано совсем другое: хранить последние сообщения в быстром кеше и сжимать историю, когда она разрастается. Это не RAG, а буфер контекста, и делается он в разы проще. Настоящий RAG нужен, когда бот отвечает по вашей базе знаний, то есть по регламентам, каталогу или документации. Для задачи "помнит, о чём говорили вчера" векторная база означает лишние недели работы и лишний сервис в инфраструктуре.
Требование 3: бесплатные сообщения каждый день
Третий пункт гласит, что "пользователю даётся десять бесплатных сообщений в день". Звучит он как маркетинг, но представляет собой статью расходов, ведь за каждое сообщение платите вы, а не пользователь. Тысяча человек, которые ничего не купили, каждый день превращаются в счёт за обращения к модели. Здесь важно считать заранее и закладывать этот счёт в цену подписки, иначе самые активные пользователи окажутся самыми убыточными.
Расходы сильно сокращает кеширование всего, что повторяется. Ежедневные прогнозы, гороскопы и типовые подборки достаточно сгенерировать один раз на группу пользователей, а личное подставить из профиля уже на стороне бота. Вместо тысячи обращений к модели каждое утро получается десяток, причём пользователь разницы не замечает.
Требование 4: приём оплаты через YooKassa и Stars
Четвёртый пункт требует "приём оплаты через YooKassa и Telegram Stars". Это два разных пути с разными последствиями. Stars представляют собой штатный способ продавать подписки внутри Telegram, они не требуют от владельца ничего, кроме решения о ценах, и открывают доступ сразу после оплаты. Однако когда пользователь покупает звёзды внутри мобильного приложения, Apple и Google удерживают около 30 процентов, а вывод идёт с задержкой. YooKassa принимает карты напрямую и без этой потери, зато подключается только на ИП, юридическое лицо или самозанятость.
На практике мы закладываем в код обе точки, а запускаемся на Stars. Благодаря этому продажи стартуют в день сдачи, а не после того, как владелец разберётся с платёжным сервисом.
Требование 5: набор анимаций персонажа
Пятый пункт требует "набор анимаций персонажа". Отрисовка и анимация относятся к работе иллюстратора, и в смету разработчика они попадать не должны. Часто их вообще не нужно оплачивать: если персонаж уже живёт в Telegram в виде стикеров, готовые файлы подключаются к событиям бота напрямую. Отдельно рисовать имеет смысл одну или две сцены, которых не нашлось, а не весь набор с нуля.
Где на самом деле лежит объём работы
Когда все невыполнимые пункты вычеркнуты, остаётся настоящий объём работы, и находится он совсем не там, где его ожидают. Разговор с моделью подключается быстро. Время съедает всё вокруг: состояние подписки с продлением и снятием по истечении срока, лимиты и их обнуление, поведение бота в момент, когда внешний сервис отвечает ошибкой или молчит, приём платежа и надёжное открытие доступа. Отдельно стоит перенос всего этого на сервер так, чтобы оно пережило перезапуск.
Поэтому разработка бота с ИИ, подпиской и оплатой занимает от 2 до 3 недель, а стоимость считается по объёму работ. Если вам предлагают то же самое в несколько раз дешевле, стоит спросить, что именно входит в цену. Уточните, что произойдёт при ошибке модели, кто снимает подписку по истечении срока, как обнуляются лимиты и кто оплачивает обращения к ИИ. Разница между предложениями почти всегда прячется в этих ответах, а не в умении писать код.