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

Телеграм-бот на Python я собирал не один раз. Сначала генератор картинок, потом парсер вакансий, потом чарник для DnD с ИИ-мастером. Каждый раз казалось, что вот теперь-то я всё знаю и соберу за вечер. И каждый раз находилась новая грабля, на которую я радостно наступал. Так что это не туториал "сделай как я", а скорее "сделай не как я".

Телеграм-бот с нейросетью на Python - это связка из трёх частей: библиотека, которая общается с Telegram Bot API (обычно aiogram), LLM-провайдер для генерации ответов (Claude, GPT) и хостинг, где всё это крутится. На старте хватает long polling и модели уровня Haiku или GPT-4o mini - так первый рабочий бот собирается за вечер, а токены не разоряют. Дальше начинается интересное.

С чего начать телеграм-бота на Python в 2026

Начать проще, чем кажется: заводите бота через @BotFather, получаете токен, ставите aiogram (pip install aiogram) и пишете один хендлер на команду /start. Через полчаса у вас в кармане отвечающий бот. Первый MVP реально собирается за вечер, и это та самая точка, где хочется закричать "хэй, так этож продукт!".

Не кричите пока. MVP на long polling - это когда ваш скрипт сам раз в секунду спрашивает у Telegram "есть чё новенькое?". Работает, запускается одной командой, не нужен ни домен, ни HTTPS. Для проверки идеи и первых десятков пользователей этого хватает с головой. Я почти все свои боты так и начинал - и почти все потом переписывал.

Главная ошибка на старте - сразу пытаться сделать "по-взрослому": webhook, база данных, докер, очереди. Не надо. Сначала докажите себе, что ботом вообще кто-то будет пользоваться. У меня половина ботов умерла на стадии "прикольно, но зачем", и вся инфраструктура вокруг них оказалась выкинутой работой.

aiogram или python-telegram-bot: что выбрать

aiogram - это современный полностью асинхронный фреймворк для Telegram Bot API на Python 3.10+, и в 2026 он уже дорос до версии 3.30 (данные репозитория aiogram, июль 2026). Альтернатива - python-telegram-bot, он попроще для новичка, но aiogram выигрывает, когда бот асинхронный по своей природе: общается с LLM, ходит в базу, дёргает внешние API.

Практическое правило простое. Пока у вас меньше полусотни одновременных апдейтов - берите что угодно, разницы не почувствуете. Как только бот начинает параллельно ждать ответа от нейросети на десятки запросов сразу, асинхронность aiogram перестаёт быть модным словом и становится тем, что держит бота живым под нагрузкой.

Минус у aiogram один, но честный: он async-only с третьей версии. Если вы никогда не писали на asyncio, первые ошибки будут выглядеть как китайская грамота - "coroutine was never awaited" и прочая радость. Я советую перед первым ботом навернуть пару туториалов по async/await, иначе будете дебажить не бота, а собственное непонимание.

Как прикрутить к боту нейросеть и не разориться на токенах

Прикрутить нейросеть технически - это один HTTP-запрос: берёте сообщение пользователя, шлёте в API провайдера, ответ возвращаете в чат. Весь фокус не в коде, а в выборе модели, потому что именно она определяет, разоритесь вы на токенах или нет. И вот тут новички обжигаются чаще всего.

Не берите на чат-бота топовую модель. Для большинства ботов "ответь по-человечески" хватает лёгкой модели. Claude Haiku 4.5 стоит $1 за миллион входных токенов и $5 за миллион выходных (данные Anthropic, июль 2026), GPT-4o mini ещё дешевле - $0.15 и $0.60 за миллион. Разница с флагманами - десятки раз. Для чат-бота на Python это значит, что можно спокойно отдавать ответы живым людям и не смотреть на счётчик с ужасом.

Чтобы цифры стали осязаемыми: 10 000 коротких диалогов на Haiku 4.5 обходятся примерно в $37 (расчёт из документации Anthropic по токенам, июль 2026). Это не месячная зарплата, это чашка кофе раз в пару дней. А если ваш бот гоняет один и тот же системный промпт в каждом запросе - включайте prompt caching: повторный контекст из кэша стоит 10% от обычной цены входных токенов, то есть экономия до 90% на той части, что не меняется.

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

Что ломается у бота на первых живых пользователях

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

Telegram Bot API разрешает боту слать не больше 30 сообщений в секунду суммарно, не больше 1 сообщения в секунду в один чат и до 20 сообщений в минуту в группу (данные Telegram Bots FAQ). Превысили - получаете 429 Too Many Requests, и Telegram ставит бота на паузу. На рассылке "всем сразу" это выстреливает моментально: думаешь, что разослал анонс тысяче человек, а половина упала в лимит.

Вторая классика - долгий запрос к LLM. Нейросеть думает пару секунд, пользователь за это время жмёт кнопку ещё три раза, и если у вас нет ни "печатает...", ни защиты от повторов, бот отвечает четырьмя одинаковыми простынями. Лечится троттлингом и статусом "бот печатает", но об этом вспоминаешь обычно уже после того, как кто-то написал "у тебя бот сломался".

Третье - состояние. Пока пользователь один, можно хранить контекст диалога хоть в глобальной переменной. Пришли двое - и они начинают видеть чужие ответы. FSM в aiogram и нормальное хранилище состояний (хотя бы Redis) - это не оверинжиниринг, это то, без чего бот с памятью на нескольких людях просто врёт.

Парсинг в телеграме: где Bot API не поможет

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

Для настоящего парсинга телеграма нужен userbot на MTProto - библиотеки вроде Telethon или Pyrogram, которые заходят не как бот, а как обычный аккаунт. Умеют они много, но и рисков там больше: можно словить бан аккаунта, можно нарушить правила, если начать мести всё подряд. Мой парсер вакансий из телеграма живёт именно на этой границе, и главный вывод оттуда я уже вынес в отдельную статью - больше половины собранного оказалось шумом, и настоящая работа была не в парсинге, а в фильтрации.

Что бы я сделал иначе

Если коротко - меньше геройства на старте, больше скуки. Вот мой личный список граблей, собранный лбом:

Начинал бы с long polling и не трогал webhook, пока бот не докажет, что нужен. Сразу закладывал бы обработку ошибок вокруг вызова нейросети - не "а вдруг упадёт", а "упадёт точно, что показать пользователю". Ставил бы троттлинг и защиту от дублей с первого дня, а не после первого "бот завис". И считал бы токены заранее, а не после того, как пришёл счёт.

И ещё одно, не техническое. Самая дорогая ошибка - строить инфраструктуру для бота, которым никто не пользуется. Сначала докажите, что идея живая, на самом кривом MVP. Красиво переписать успеете всегда, а вот вернуть потраченные на переписывание вечера - уже нет.

А я пойду чинить очередной бот, который вчера отлично работал, а сегодня почему-то нет. Такие дела.