Телеграм-бот с нейросетью: как сделать и сколько стоит

Телеграм-бот с нейросетью выглядит простой задачей: получил сообщение, спросил модель, отправил ответ. Так и есть — рабочий прототип собирается за вечер. Сложности начинаются позже и всегда в одних и тех же местах: расход растёт непредсказуемо, бот забывает контекст или наоборот тащит всю переписку в каждый запрос, пользователь ждёт двадцать секунд молча, а на длинных диалогах приходит счёт, которого никто не ожидал. Разбираем схему целиком, считаем стоимость на понятном примере и перечисляем места, где она обычно ломается.

Как устроена связка

Три части, и модель — не та, что общается с мессенджером.

Мессенджер присылает вам сообщение пользователя — через опрос обновлений или через веб-хук на ваш адрес.

Ваш код получает его, решает, что отправить модели, формирует запрос и разбирает ответ.

Модель получает текст и возвращает текст. Она не знает ни про пользователя, ни про мессенджер, ни про предыдущие сообщения.

Последнее — ключевое и самое недооценённое. Модель не помнит ничего между запросами. Ощущение памяти создаёт ваш код, подкладывая историю переписки в каждое обращение. Именно отсюда растут и главная возможность, и главная статья расходов.

Сколько это стоит

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

Пусть пользователь задаёт вопрос на 50 токенов, системный промпт занимает 300, ответ выходит на 200 токенов. Служебный контекст маршрута добавит ещё сколько-то — величина различается между моделями на порядок.

Первое сообщение. Вход около 350 плюс служебное, выход 200.

Десятое сообщение, если вы отправляете всю историю. Вход уже около 2600 — накопились предыдущие вопросы и ответы. Выход те же 200.

То есть десятое сообщение стоит в разы дороже первого, хотя пользователь написал столько же. На дешёвой позиции каталога — от 3 ₽ за миллион токенов — весь такой диалог обойдётся в доли копейки, и тысяча диалогов в день останется в пределах десятков рублей.

Те же два обращения по позициям каталога — вход и выход вместе, без служебного контекста маршрута.

Но арифметика меняется, если диалоги длинные, а модель дорогая. История растёт квадратично: удвоение числа сообщений учетверяет суммарный расход на неё. Механику с числами разбирали в материале про стоимость агента в месяц — для бота она работает точно так же.

Где обычно ломается

Пять мест, в которых спотыкаются почти все.

Отправляют всю историю без ограничения. Самая дорогая ошибка. Диалог на сто сообщений превращает каждый следующий запрос в пересылку всей переписки. Решение: держать последние несколько обменов плюс короткое резюме более раннего.

Не ставят предел на длину ответа. Значение по умолчанию щедрее, чем нужно боту, и оплачивается полностью.

Не показывают, что бот думает. Двадцать секунд молчания читаются как поломка. Индикатор набора текста или потоковая передача решают это без всякого ускорения — когда стриминг нужен, а когда мешает.

Обрабатывают все отказы одинаково. Часть ошибок требует повтора с паузой, часть — правки кода, часть — переключения модели. Разбор кодов — отдельно.

Не ограничивают пользователя. Один человек с автоматизированным скриптом способен выбрать месячный бюджет за час. Лимит на пользователя нужен с первого дня.

Как ограничить расход на пользователя

Раз это главный риск, разберём меры по возрастанию сложности.

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

Обрезка истории. Держать последние несколько обменов вместо всей переписки. Ограничивает и расход, и деградацию качества — модель хуже находит нужное в середине длинного ввода.

Счётчик на пользователя. Простой лимит сообщений в сутки. Не для экономии, а чтобы один человек со скриптом не выбрал общий бюджет.

Разные модели под разные запросы. Короткий вопрос — дешёвая позиция, сложный разбор — дороже. Определять это можно тем же дешёвым обращением, которое классифицирует запрос перед основным.

Кэш ответов на повторяющееся. В ботах доля повторяющихся вопросов обычно высокая. Ответ на «как вернуть товар» не надо генерировать заново каждому.

Последний пункт часто даёт больше всех остальных вместе взятых и при этом не требует ничего от модели: обычная таблица «вопрос — готовый ответ» перед обращением к API.

Что логировать с первого дня

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

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

Номер сообщения в диалоге. Показывает, на каком шаге расход становится заметным.

Модель. Фактическая, а не та, что стоит в конфигурации по умолчанию.

Входные и выходные токены раздельно. Пока ставка симметрична, для суммы разницы нет, но она появится мгновенно на модели с раздельными ценами.

Признак повтора. Была ли это первая попытка или повтор после сбоя.

Подробный разбор, что и зачем писать в логи, — в отдельном материале. Для бота особенно ценно первое поле: без него нельзя ответить на вопрос «сколько стоит один активный пользователь», а это и есть та цифра, от которой считается экономика.

Что выбрать под бота

Практические ориентиры.

Модель. Начинайте с самой дешёвой позиции каталога. Для типичного бота — ответы на вопросы, консультации, простые задачи — разницы с флагманом обычно не видно. Как проверить это на своих диалогах — в методике сравнения.

Длина истории. Разумный старт — последние пять-семь обменов. Если бот теряет нить, добавляйте резюме, а не всю переписку.

Отдельный ключ. Не общий с остальным продуктом: так виден расход именно бота, и его лимит не пересекается с рабочим.

Системный промпт покороче. Он уходит в модель при каждом сообщении. Лишние пятьсот токенов при десяти тысячах сообщений в день — это пять миллионов входных токенов в сутки.

Если боту нужны свои знания

Частый следующий шаг: бот должен отвечать по вашим документам, а не общими словами.

Дообучать модель для этого не нужно. Правильная схема — найти нужный фрагмент в своей базе и подложить его в запрос вместе с вопросом. Модель получит и вопрос, и материал, и ответит по нему.

Собирается это из четырёх частей: разбиение документов на фрагменты, поиск кандидатов, их упорядочивание и подстановка лучших. Подробный разбор с местами, где цепочка ломается, — в материале про поиск по своей базе.

Важная оговорка про безопасность: всё, что попало в контекст, модель читает как часть задачи. Если в базу может писать кто-то извне — пользователи, автоматический сбор, — это канал для инструкций, и защита строится не на фильтрации текста, а на ограничении прав.

Чего мы не обещаем

Не приводим кода. Библиотеки для работы с мессенджером меняются, и инструкция устареет быстрее статьи; мы описываем схему и экономику.

Цифры в примере условные. Ваш расход зависит от длины сообщений, системного промпта и выбранной модели; считать нужно по фактическим значениям из ответа API — как считать токены.

Не оцениваем качество моделей для диалога. Это проверяется на ваших сценариях: диалоговые задачи различаются сильнее, чем кажется, и модель, хорошая для консультаций, может плохо держать формальный тон.

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

Не даём рекомендаций по обработке персональных данных. Если бот собирает сведения о пользователях, требования к их хранению определяет закон, а не мы.

Что держать в голове

Бот с нейросетью — это три части, где модель самая простая: она не помнит ничего, и всю память создаёт ваш код.

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

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Ключ для бота заводится за минуту: keydealer.ru/login.