Архитектурные ловушки при создании AI-агрегатора для Telegram: опыт соло-разработчика
Разработка собственного AI-агрегатора, который собирает новости из Telegram-каналов, фильтрует их и превращает в аудио-дайджест, выявила пять фундаментальных технических проблем. Статья анализирует ограничения сторонних сервисов, особенности тарификации облачных инструментов, сложности дедупликации контента и ошибки в проектировании оркестрации процессов, которые могут поглотить бюджет и время проекта.
# Пять архитектурных ловушек при создании AI-агрегатора Telegram
Разработка собственного агрегатора новостей, который собирает публикации из отобранных Telegram-каналов, удаляет дубликаты и «шум» с помощью классификации, а затем превращает результат в аудио-дайджест, часто сталкивается с непредвиденными препятствиями. Ниже представлен разбор пяти конкретных технических проблем, с которыми столкнулся автор при реализации такого проекта.
1. Ограничения «невидимых» мостов: проблема RSS от Telegram
Прямой доступ к Telegram API для чтения произвольных публичных каналов отсутствует. Стандартное API предназначено для работы ботов, а не для мониторинга чужих каналов. Решение проблемы — использование бесплатных сторонних сервисов, конвертирующих URL канала в RSS-ленту.
Однако такие сервисы имеют неофициальные лимиты. По практике, допустимо около 13–15 запросов подряд в течение нескольких минут. После превышения этого порога сервис возвращает ошибку 429 (Too Many Requests) и выходит на восстановительный режим, длительность которого часто превышает заявленные в документации 15 запросов в минуту. Это становится жестким ограничением скорости всего продукта.
Термин: *Ограничение по частоте запросов (Rate Limit).* Механизм защиты сервера, который ограничивает количество запросов клиента в единицу времени. При превышении лимита сервер отклоняет лишние запросы.
Из-за этой зависимости архитектура системы была вынуждена учитывать паузы. Например, между темами внутри пайплайна пришлось устанавливать таймаут в 75 секунд, что диктовало нижнюю границу частоты полного цикла сбора. На 12 тем этот цикл занимает около 40–45 минут. Внешняя зависимость без гарантий уровня обслуживания (SLA) стала главным узким местом.
2. Экономика запуска скриптов: не только стоимость, но и количество
Использование сервисов автоматизации (например, n8n или аналоги) имеет специфическую тарифную модель. На базовых тарифах часто устанавливаются лимиты не только на время выполнения, но и на количество запусков в месяц (например, 2500) и количество одновременных запусков (например, 5).
Изначально проект был спроектирован так, что у каждой из 12 тем было свое независимое расписание. Это создало 12 точек входа. При попытке увеличить частоту сбора (например, до ежечасного) количество засчитываемых запусков возросло в 12 раз, что мгновенно привело к исчерпанию тарифа.
Решение: Ввод «Оркестратора» — единой точки входа, которая по расписанию последовательно вызывает все темы. Внутренние вызовы между темами внутри одного запуска Оркестратора не засчитываются как отдельные запуски в тарифной сетке. Это решение продиктовано экономикой, а не архитектурной эстетикой.
3. Иллюзия дедупликации: почему хэши текста не работают
В пайплайне обработки использовались два типа идентификаторов для борьбы с дубликатами:
1. `external_id`: Детерминированный хэш, зависящий от ссылки на пост и даты. Этот метод работает корректно: одна и та же статья из разных источников получает одинаковый ID, и бэкенд успешно схлопывает дубли. 2. `cluster_id`: Хэш от точного текста описания (первые 200 символов). Цель — кросс-канальная кластеризация, когда разные каналы пишут об одном событии своими словами.
Тестирование на выборке из 1003 записей за 14 дней показало, что cluster_id сработал на 99% случаев (то есть практически никогда). Разные каналы действительно описывают события уникально для себя, и простой хэш текста не способен уловить смысловое сходство.
Эксперименты показали, что только добавление стемминга (редуцирование слов до их основы, например, «Россия»/«России») и сравнение заголовков вместо полного текста дали точность около 89%, но этот механизм требует дополнительных ресурсов и пока не подключен к основной ленте.
4. Двойная оплата за озвучку: эффект параллельного выполнения
В архитектуре, где одна тема может относиться к нескольким категориям (например, канал о финансах попадает в разделы «Банки» и «Финансы»), каждый раздел запускал отдельный цикл обработки. Дедупликация по external_id происходила только на бэкенде *после* генерации аудио.
Это приводило к ситуации, когда текст дублируется для пользователя, но плата за синтез речи (TTS) списывается дважды. Статистика за 14 дней показала множитель 2.27: на 1003 уникальных новости было сделано 2275 вызовов синтеза. Это означает, что около 56% расходов на озвучку было избыточным.
Экономический штрих: Устранение дублей позволяет сэкономить порядка 1300 рублей в месяц. Кэш-механизм, который должен запоминать, что атом уже озвучен, не работал из-за асинхронности: если темы запускались с разбросом в минуту, вторая тема могла прочитать кэш до того, как первая успела записать результат.
Решение: Переход к строгой последовательности запуска всех тем через единого Оркестратора позволил кэш-механизму работать корректно, так как вторая тема начала работу только после завершения предыдущей.
5. Ложно-зеленый статус и исчерпание квот
Увеличение частоты сбора с 4 раз в сутки до раза в час привело не к плавному росту нагрузки, а к полному отказу системы с первого часа. Причина — бесплатная дневная квота классификатора модели (500 запросов в сутки) была исчерпана мгновенно.
При старой схеме (4 запуска в день) квоты хватало на недели. При 24 запусках — они тают за час. Критически важным стал тот факт, что сам Оркестратор продолжал выдавать статус success, не сообщая о фактическом отсутствии данных в базе. Ошибки на уровне отдельной темы логировались, но уведомления (email-алерты) были отключены из-за предыдущих инцидентов. Без ручной проверки полная остановка сбора осталась незамеченной.
Выводы для архитектуры
Текущая архитектура эволюционирует. Классификатор заменен на более дешевую модель, а процесс обработки материалов готовится к работе в батчах (пакетами по 15 новостей за один вызов), чтобы снизить нагрузку на API. Также внедряются «гейты» (фильтры) перед обращением к модели, чтобы отсеивать неактуальные или уже обработанные материалы заранее.
Проект находится в ранней стадии соло-разработки. Данные показывают: 4733 открытий приложения, 1037 прослушиваний. Доля дослушивания среди реальных слушателей стабильно составляет 60–80%. Основной проблемой не является качество контента или технические сбои, а узнаваемость продукта среди аудитории.
Заключение
Создание AI-агрегатора требует тщательного учета не только логики работы алгоритмов, но и экономических условий облачных сервисов, ограничений сторонних API и особенностей работы систем оповещения. Иллюзия простоты на ранних этапах часто скрывает скрытые множители стоимости и сложности интеграции.