Меня зовут Ян, я разработчик, и я хронически подписываюсь на слишком много чатов. Рабочие обсуждения по разработке и DevOps, бесконечные разговоры про IT‑стартапы, чаты друзей, домовые собрания жильцов - всё это живёт в Telegram. И однажды утром я понял, что больше так жить нельзя.
Я просыпаюсь, открываю чат с друзьями - 127 непрочитанных сообщений. Чтобы понять, о чём вообще шёл разговор, мне каждый раз приходилось:
- листать весь тред вверх;
- читать десятки реплик, половина из которых - мемы и оффтоп;
- в голове восстанавливать цепочку: кто кому ответил, о чём спорили, к чему пришли.
В итоге ты тратишь 10-15 минут только на то, чтобы "догнать" обсуждение, и это при том, что тема может оказаться неважной. В какой‑то момент у меня всплыла предельно простая мысль: почему нельзя сделать так, чтобы бот сам прочитал все эти сообщения и выдал мне в личку человеческое, сжатое саммари? Без воды, без цитат на пол-экрана, просто: "вот, о чём спорили, вот к чему пришли, вот кто что предложил".
Так родилась идея бота, который делает сводки обсуждений в Telegram и параллельно работает как AI‑ассистент прямо внутри чата.
---
Чем бесят активные Telegram-чаты
Если вы сидите хотя бы в трёх-четырёх живых чатах, картина наверняка знакома. За пару часов там набегает от сотни до трёхсот сообщений. Пропустили час - вы уже "выпали из контекста".
Отсюда две ключевые проблемы:
1. Теряется контекст.
Заходишь в чат, а там уже 150 новых сообщений. Неясно, с чего началось, о чём спор и почему вдруг кто-то на кого-то наехал. Чтобы въехать, нужно читать всё подряд, пытаясь восстановить логику обсуждения.
2. Тратится время.
Даже если разговор не особенно важен, появляется FOMO: "А вдруг там что-то полезное?". И ты всё равно лезешь читать, сжигая по 5-20 минут на пересказ чужих эмоций и шуток.
То, что я хотел получать, выглядело примерно так:
> За последние 2 часа обсуждали разницу ARM и x86, кто на чём собирает проекты, какие бенчмарки актуальны. В итоге сошлись, что ARM подходит для большинства задач, особенно на macOS, но для части серверных нагрузок по-прежнему удобнее x86. Пара человек поделились личными замерами по сборке в Xcode на M3.
Несколько строк текста - и уже понятно, что происходило. По сути, это аналог RSS‑ленты, только не для новостей, а для групповых диалогов.
---
Зачем вообще городить AI-ассистента прямо в чате
Когда я додумывал концепцию саммаризации, стало ясно: ограничиваться только сжатием истории - расточительно. В любой технической беседе постоянно всплывают вопросы:
- чем принципиально отличается ARM от x86;
- какая архитектура быстрее в однопоточных задачах;
- существуют ли свежие бенчмарки под конкретную нагрузку;
- что изменилось в новой версии языка или фреймворка.
В обычном сценарии кто-то сворачивает Telegram, открывает браузер, гуглит, либо идёт в отдельный интерфейс чат‑модели. Контекст при этом теряется, половина людей перестают следить за беседой.
Я захотел сделать по-другому:
чтобы любой участник мог прямо в чате задать вопрос ИИ, не выходя из диалога, и получить в ответ компактное, но внятное объяснение.
Так в боте появилась вторая функция:
- в общем чате можно вызвать команду `/ask_ai` и сформулировать вопрос;
- либо написать этот вопрос боту в личку;
- ответ от модели DeepSeek‑V3.2 возвращается обратно в чат в удобном виде.
Чат продолжает жить, не распадаясь на "ушёл гуглить" и "мне лень искать".
---
Технологический стек
Для реализации бота я взял привычный для себя стек:
- Backend: PHP
- Фреймворк: Symfony
- Очереди: RabbitMQ
- База данных: PostgreSQL
- AI-клиент: Ollama (для локального тестирования моделей)
Я сознательно решил начать с бесплатных моделей и локального окружения - на этапе MVP тратить деньги на API бессмысленно, если ещё не понятно, как часто и в каких сценариях люди будут пользоваться ботом.
---
Какие модели я пробовал и как тестировал
Для локальных экспериментов я использовал клиент Ollama и протестировал несколько русскоязычных и мультиязычных моделей:
- T‑Lite (~5 GB)
- Saiga YandexGPT (~5 GB)
- Qwen 2.5 (~5 GB)
- Llama 3 (~4,7 GB)
- YandexGPT‑5‑Lite (квантованный GGUF-вариант)
Чтобы не полагаться на субъективное ощущение "нравится/не нравится", я сгенерировал через большую модель около 300 случайных сообщений для трёх разных по тематике чатов: техничка, дружеский чат и обсуждение рабочих задач. Дальше проверял саммаризацию по наборам в 50, 100, 200 и 300 сообщений.
Критерии были всего два, но очень жёстких:
1. Качество русского языка.
Минимум ошибок, естественные формулировки, отсутствие странных конструкций.
2. Строгое следование промпту.
Если прошу выдать краткое саммари с перечислением основных тем и выводов - значит, именно это и должно приехать. Без лирики, самовыражения и лишних советов.
Реальные результаты получились такими:
- Qwen 2.5 7B: временами внезапно переходила на китайский, что делает её непредсказуемой в проде.
- Saiga YandexGPT 8B: любила уходить в длинные рассуждения, хотя я просил о кратких выжимках.
- T‑Lite‑it‑2.1: иногда просто не возвращала результат - для продакшена неприемлемо.
- Llama 3 8B: периодически "сползала" на английский и игнорировала стилизацию под русскую речь.
- YandexGPT‑5‑Lite: показала лучший баланс - аккуратно следовала промпту, писала на нормальном русском. Из минусов - иногда всё же были галлюцинации, но не критичные для саммаризации.
В итоге для MVP я остановился именно на YandexGPT‑5‑Lite в квантованном варианте.
---
"Кирпичи" контекста: как я обошёл проблему Lost in the Middle
Одна из типичных проблем работы с LLM - эффект Lost in the Middle: модель хуже всего помнит и обрабатывает середину длинного контекста. Если просто скормить ей 200-300 сообщений чата, возрастает риск, что важная часть обсуждения окажется как раз в "проваленной" зоне.
Решением стала простая архитектурная идея, которую я для себя назвал "Кирпич" (Brick Context).
- 1 кирпич = 50 сообщений чата.
Как это работает:
1. Как только в чате набирается очередные 50 сообщений, по крону срабатывает задача.
2. Эти 50 сообщений отправляются в модель.
3. Модель возвращает компактное саммари - и это отдельная сущность "кирпич".
Пример условного "Кирпича #1":
> Обсуждали разницу ARM и x86: Sergey_it спрашивал про реальную разницу в повседневных задачах, участники делились опытом сборки проектов на M3 и классических x86‑серверах. В целом сошлись, что ARM подходит большинству пользователей, особенно на macOS, но для части тяжелых серверных нагрузок проще оставаться на x86.
Если за день в чате накопилось, скажем, 200 сообщений, то у нас будет четыре кирпича. Для суточного саммари я не подаю в модель 200 сырых сообщений - я подаю промпт плюс эти 4 "кирпича" как уже сжатые блоки контекста. Так я:
- уменьшаю длину реального контекста для модели;
- сохраняю ключевые смысловые узлы обсуждения;
- снижаю риск, что "середина дня" выпадет из внимания модели.
---
AI-ассистент на DeepSeek‑V3.2
Для части, отвечающей на вопросы пользователей, я реализовал API к модели DeepSeek‑V3.2.
Её ключевое преимущество на старте - очень низкая стоимость одного запроса: примерно $0.0000084. Это позволяет не бояться, что при первых же активных пользователях счёт за инференс уйдёт в космос.
Логика простая:
- запросы саммаризации и запросы к ассистенту - разные очереди в RabbitMQ;
- для ассистента применяется отдельный промпт, заточенный под объяснения и факты;
- ответы форматируются так, чтобы их было удобно читать прямо в чате, без "простынь".
---
Хостинг моделей и производительность: почему RunPod
Когда стало ясно, что локальной машины мне уже не хватает для постоянных тестов, я вынес инференс на внешнюю инфраструктуру и остановился на модели хостинга с оплатой по факту использования.
В итоге использую конфигурацию, при которой:
- Один запрос на саммаризацию 50 сообщений обходится примерно в $0.00019.
- При этом задержка адекватная:
- 50 сообщений - около 4,8 секунд;
- 2 кирпича (100 сообщений) - примерно 30 секунд;
- 4 кирпича (200 сообщений) - около 40 секунд.
Это не мгновенно, но для фонового саммари это вполне комфортно: бот не претендует на real‑time, его задача - давать понятную картину обсуждений за период.
---
Экономика: RunPod + YandexGPT‑5‑Lite против GPT‑4o mini
Чтобы понять, насколько жизнеспособен проект, я посчитал стоимость генерации саммари при разных объёмах сообщений.
Базовая цена за генерацию саммари (RunPod + YandexGPT‑5‑Lite):
- 50 сообщений - $0.00019
- 100 сообщений - $0.00038
- 200 сообщений - $0.00076
- 500 сообщений - $0.0019
- 1 000 сообщений - $0.0038
Дальше - сценарии по числу чатов в месяц (условно считаем, что каждый чат даёт около 500 сообщений, которые нужно саммаризировать):
- 1 чат (500 сообщений) - $0.002
- 10 чатов (5 000 сообщений) - $0.02
- 100 чатов (50 000 сообщений) - $0.19
- 1 000 чатов (500 000 сообщений) - $1.90
- 10 000 чатов (5 000 000 сообщений) - $19.00
Для сравнения, аналогичная нагрузка на GPT‑4o mini обойдётся примерно в:
- 1 чат - $0.04
- 10 чатов - $0.40
- 100 чатов - $4.00
- 1 000 чатов - $40.00
- 10 000 чатов - $400.00
Вывод получился довольно простой:
MVP можно запускать на дешёвой связке RunPod + YandexGPT‑5‑Lite, а при росте объёмов или повышении требований к качеству текста - безболезненно мигрировать часть трафика на более дорогую модель вроде GPT‑4o mini для премиальных чатов или платных подписок.
---
Что оказалось самым сложным в разработке
Не кодирование и не интеграция с Telegram API, а три более "человеческие" задачи:
1. Найти правильный формат саммари.
Первые версии были либо слишком сухими ("обсуждали X, выводов нет"), либо, наоборот, превращались в пересказ на пол-экрана. Пришлось поэкспериментировать с промптом: чётко разделить "темы обсуждения", "ключевые решения" и "что стоит посмотреть/почитать дополнительно".
2. Сделать так, чтобы бот не раздражал.
Если слать саммари слишком часто - это превращается в спам. Если слишком редко - теряется смысл. В итоге я добавил настройки периодичности и формата прямо на уровне чата: админ может сам выбрать, нужны ли ему, например, только утренние и вечерние сводки или ещё и "по триггеру" (когда произошёл всплеск активности).
3. Минимизировать галлюцинации.
Для саммаризации это особенно критично: если бот начнёт "придумывать" несуществующие выводы или фразы, люди перестанут доверять сводкам. Пришлось ужесточать промпты в стиле: "не додумывай факты, если в сообщениях нет явного вывода - так и напиши, что участники не пришли к единому мнению".
---
Как это выглядит в реальном использовании
Типичный сценарий для активного чата:
- Днём там идёт бурное обсуждение, накапливаются сотни сообщений.
- Бот собирает "кирпичи" по 50 сообщений, формирует из них суточное саммари.
- Вечером все участники, которые подписались на сводки, получают в личку краткий обзор: что обсуждали, к каким решениям пришли, какие идеи стоит дообсудить.
Параллельно, если в процессе кто-то задаёт технический вопрос, его можно сразу же отправить на `/ask_ai`. Бот возвращает развёрнутый ответ модели, который можно тут же обсудить и либо принять как основу, либо раскритиковать.
В рабочих чатах такой формат помогает не терять важные решения в потоке: саммари превращается в своего рода "рабочий лог" без необходимости вручную писать отчёты.
---
Где такой бот особенно полезен
По опыту тестирования, наибольшую пользу бот даёт в следующих сценариях:
- Чаты разработчиков и DevOps.
Там постоянно обсуждаются архитектурные решения, версии библиотек, баги. Саммари помогает не терять решения и гипотезы, а AI‑ассистент - быстро проверять факты и сравнивать подходы.
- Чаты небольших стартапов.
Когда вся команда сидит в одном канале и обсуждает и продукт, и маркетинг, и продажи, легко утонуть в хаосе. Сводки позволяют держать в голове общую картину, не перечитывая всё подряд.
- Чаты собственников жилья или рабочих групп.
Люди периодически подключаются и отключаются, но им важно понимать, к чему в итоге пришли - выбрали ли подрядчика, какую схему оплаты решили и т.д.
- Дружеские и семейные переписки.
Тут ценность скорее в том, чтобы "быть в теме", когда нет времени читать 200 сообщений с мемами. Пара абзацев от бота - и вы понимаете, кому сейчас нужна помощь, о чём шутили, что планируют.
---
Какие улучшения напрашиваются дальше
После того как базовый функционал заработал стабильно, стало понятно, куда двигаться дальше:
- Персональные фильтры.
Возможность указать, какие темы интересны конкретному пользователю. Например, "показывай в саммари только технические обсуждения и решения, без оффтопа".
- "Умные" триггеры для саммари.
Не только по количеству сообщений или по времени суток, а по всплескам активности или ключевым словам ("релиз", "ошибка", "срочно").
- Хранение и поиск по саммари.
Когда у чата появляется длинная история сводок, это почти готовая база знаний: можно сделать по ней быстрый поиск вроде "когда мы обсуждали миграцию на ARM и что тогда решили?".
- Разделение моделей по уровням качества.
Бесплатный план - на дешёвой модели, платная подписка - с более точными и аккуратными саммари на более дорогой модели.
---
Итог
Вся эта история началась с банальной усталости от 100+ непрочитанных сообщений. Но попытка "просто сэкономить себе время" вылилась в довольно универсальный инструмент: бот, который:
- разбирает длинные обсуждения на "кирпичи";
- собирает из них понятные саммари;
- помогает участникам быстро восстановить контекст;
- отвечает на технические и фактологические вопросы прямо внутри чата.
При этом MVP оказался дешёвым в эксплуатации и достаточно быстрым, чтобы не раздражать задержками. А главное - он снимает ту самую скрытую боль, о которой мало кто говорит вслух: постоянное чувство, что ты либо утонул в бесконечных чатах, либо что-то важное пропустил. Теперь за восстановление контекста отвечает бот, а не твой вечер.
