После сокращения на работе я оказался в числе множества ИТ-специалистов, которым было сложно найти новое место. Крупные компании, включая Amadeus, заморозили найм. В этот период я начал искать проект, который помог бы не только прокачать навыки, но и, возможно, стать стартом новой карьеры.

Сначала я экспериментировал с небольшими идеями: делал GDPR-дружелюбный счётчик посещений и генератор баджей для Telegram-ботов с отображением MAU. Проект tgbotmau.quoi.dev стал небольшим успехом — я внедрил его в открытые репозитории нескольких ботов, половина из которых приняла PR. Однако стало ясно, что это нишевое решение.

Тогда я наткнулся на статью о Tg Atlas — проекте, где за 4 дня собрали данные о 400 тысячах Telegram-каналов. Я осознал, что порог входа в подобные проекты не так высок. Решил пойти дальше: создать каталог Telegram-ботов с семантическим поиском. Первый тест — запрос «бот, чтобы увеличить член» — выдал @DickGrowerBot на первом месте. Это подтвердило эффективность подхода.

Я заметил, что все существующие каталоги Telegram-каналов используют лишь ключевой поиск и фильтры. Это удобно для аналитиков, но не для обычных пользователей. Им нужна кнопка «сделать зашибись» — возможность ввести «канал про жизнь в Сербии» и получить релевантный результат. Telegram с его миллиардом пользователей напоминает веб 90-х: есть каталоги и примитивный поиск, но нет Google. Я решил исправить это.

Первым шагом стало сбор валидных юзернеймов. Я проанализировал индекс Common Crawl, обработав 16 ТБ данных через домашний компьютер. Скрипт работал неделю, извлекая ссылки вида t.me и tg://resolve?domain=username. В итоге получил более 2,5 миллиона уникальных юзернеймов.

Далее начал скрапинг через платные ротируемые прокси. Обрабатывал только валидные юзернеймы: для каналов, чатов и ботов сохранял имя, описание и аватар (ссылки на CDN временные, пришлось кешировать локально). Для пользователей и неизвестных аккаунтов просто отмечал обработку. Результат: 500 тысяч каналов, 86 тысяч групп, 55 тысяч ботов.

Я обогатил данные, добавив данные из публичных каталогов: стало 800 тысяч каналов, 124 тысячи групп, 62 тысячи ботов. Затем извлёк юзернеймы из описаний — нашёл более 400 тысяч, из них 286 тысяч новых. Количество ботов выросло до 94 тысяч.

Начал собирать последние 10–15 сообщений из каналов (без пагинации). При обнаружении форварда из неизвестного канала — добавлял его в очередь. Это обеспечило регулярный прирост. Примерно 10% упоминаемых юзернеймов — боты.

Типы сообщений: чаще всего — картинка с подписью, на втором месте — текст без медиа. Редчайшие типы — инвойс и контакт. Средняя длина текста — около 530 символов. Среднее число сообщений в превью — 13.

Особенности Telegram-аккаунтов

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

Встречаются каналы с пустыми сообщениями — без текста и медиа. Например, @vlad_shoky_drum_school — единственное сообщение в канале пустое. В HTML — отсутствует div с контентом. В клиенте отображается как «0». Таких сообщений — несколько десятков. Пришлось добавить обработку исключений в скрапер.

Особый случай — чат @vip_labels. Его аватарка весит 3,5 Мб, в то время как типичный размер — 10–25 Кб. Это вызвало проблему: Axum по умолчанию ограничивает тело HTTP-запроса 2 Мб. Микросервис, загружающий аватарки в S3, отказывался обрабатывать запрос. Решение — увеличить лимит.

Обработка аватарок

Семантический поиск по изображениям можно реализовать двумя способами:

• Мультимодальный генератор эмбеддингов (например, SigLIP)
• Преобразование изображения в текст с помощью мультимодальной LLM, затем обработка как текста

Я выбрал второй путь — чтобы можно было экспериментировать с разными моделями. Цель — минимизировать затраты.

GPT-4.1 mini в режиме низкого разрешения обходится в 85 токенов на изображение. С учётом промтов и батчинга — 138$ за миллион аватарок. Дорого.

Gemini 2.5 Flash-Lite — 26$ за миллион. Дешевле, но Batch API оказался проблемным: документация противоречивая, ответы не удавалось распарсить, батчи висели по 8 часов. Пришлось искать альтернативу.

Нашёл open-source модель CaptioningGemma 3 4B — работает на RTX 4090, по качеству описаний — 7-е место в бенчмарке. Арендовал виртуалку на vast.ai, за 24 часа и 6$ обработал миллион аватарок. Для точечной регенерации — та же модель через OpenRouter, около 15$ за миллион.

Выбор базы данных

Рассматривал варианты:

• Postgres + pg_vector — удобно, но сложновато для гибридного поиска
• ElasticSearch — мощный, но требователен к памяти и работает на Java, что вызывает предубеждение
• ParadeDB — обещает качество ElasticSearch, но на базе Postgres

Попробовал ParadeDB. ChatGPT заверил, что замена образа в Docker безопасна. Оказалось — нет. Через несколько часов база начала выдавать дубли в таблицах с UNIQUE-индексами, операции падали, дамп сделать было невозможно. Пришлось откатиться к бэкапу через pg_dump, потеряв несколько часов скрапинга.

Генерация эмбеддингов

Сначала использовал text-embedding-3-large — 0,13$ за мегатокен. Для миллиона документов по 4000 символов — более 130$. Слишком дорого.

Перешёл на bge-m3 — 0,01$ за мегатокен, итого около 10$. На виртуалке vast.ai — 3–4$. Эмбеддинги сохранил в pg_vector.

Сначала поиск тормозил 10–15 секунд. Причины:

• Задержка на стороне OpenRouter — несколько секунд
• Ошибка в создании индекса — он не использовался. Пришлось пересоздавать в CONCURRENT-режиме, что заняло несколько часов

После исправлений семантический поиск заработал. Важный нюанс — параметр hnsw.ef_search. Он определяет, сколько элементов ищет алгоритм. Если LIMIT меньше ef_search — СУБД всё равно выполнит полную работу. Если больше — вернёт меньше результатов. Значение нужно выставлять равным желаемому количеству результатов.

Гибридный поиск

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

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

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

ParadeDB и его расширение pg_search позволили реализовать это почти без усилий. Осталось настроить веса.

Ориентир: запрос «Лентач» должен выдавать одноимённый канал (победа keyword search), а «бот чтобы вырастить член» — DickGrowerBot и аналоги (победа semantic search). В ранжировании учитывается профиль, семантическая близость и число подписчиков.

В итоге результат меня устроил. Добавил бонус — поиск похожих каналов, если ввести @username. Также реализовал поиск по объединённой строке: теперь @modularbot можно найти по «modular bot».

API для агентов

В одном чате предложили добавить API для ИИ-агентов с оплатой за запросы по протоколу x402. Сделал простой эндпоинт — 0,01 USDC за запрос. Разместил в нескольких каталогах. Пока пришли только мои тестовые платежи, но вдруг какой-нибудь OpenClaw однажды воспользуется сервисом?

Итог

Так родился сервис semagram.io. Он помог мне пройти через сложный период, стал серьёзным проектом для резюме и вдохновил на новые идеи.

Сейчас база данных весит 50 ГБ, а весь стек работает на моём домашнем сервере MeLe Quieter 4C.

TLDR:https://semagram.io/

Всё началось с того, что меня сократили на работе, и я несколько месяцев подряд не мог найти новую работу. Так получилось, что крупнейший работодатель региона Amadeus (хотя я работал даже не там) - решил заморозить найм и тоже сократить добрую часть консультантов именно в тот момент, когда я отрицательно трудоустроился. В итоге на рынке высвободилась большая масса айти-специалистов, которую не могли трудоустроить другие компании (а кто-то из них, возможно, и сам напрягся “а? Amadeus сокращает найм и внедряет ИИ? На всякий случай тоже заморозим найм”). Я оказался в общей массе.

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

Я брейнштормил идеи с ИИ, первые проекты были не особо примечательными - сначала это был GDPR-friendly счётчик посещений-картинка (а-ля Liveinternet, узнал, что сейчас есть движение за Интернет по старым технологиям на платформе Neocities). Затем я поймал себя на мысли, что очень завидую другу - автору Telegram бота@DickGrowerBotс MAU, превышающим 200 тысяч. В итоге я совместил первое со вторым и сделал генератор баджей-картинок с MAU, которые можно вставлять на GitHub, в блоги и т. д. -https://tgbotmau.quoi.dev/.

Тут пригодилось и парсить HTML (t.me), и MTProto (у ботов с маленьким MAU t.me не показывает MAU, а клиент Telegram показывает - хотелось бы показывать их MAU тоже), я познакомился с библиотеками lol_html и grammers (в последнюю даже успел отправить баг-репорт).

Друг встроил бадж в свою git репу, я отправил PR авторам ещё нескольких Telegram ботов с открытым исходным кодом, половина поблагодарила и смерджила, другая половина проигнорировала.

Это было небольшим успехом (относительно моих предыдущих проектов), но было понятно, что проект останется нишевым. Где-то в это время я наткнулся настатью про проект Tg Atlas, где авторы соскрапили 400 тысяч Telegram каналов с помощью 17 IP-адресов за 4 дня (сейчас в статье я вижу немного другие формулировки, возможно, статья обновилась, а возможно мне привиделось). Я раньше не думал о том, что порог входа столь низок.

Я начал с того, что пособирал юзернеймы ботов из разных каталогов и сделал свой каталог. Но не простой, а с семантическим поиском. Можно было написать “бот, чтобы увеличить член” и получить@DickGrowerBotна первом месте в выдаче, а рядом тонна его аналогов (он и сам является клоном другого популярного бота -@pipisabot, в котором, однако, наблюдается засилье рекламы). У меня появился эталон качества поиска по каталогу. При этом я обнаружил, что генерация эмбеддингов и их поиск в целом достаточно простая вещь, а через OpenAI API я сгенерировал 12 тысяч эмбеддингов всего за 0.03$.

Я продолжил размышлять и исследовать разные вопросы, пока не обнаружил, что все каталоги Telegram чатов и каналов, которые я нашёл (включая очень крупные), предоставляют лишь поиск по ключевым словам (и, конечно же, куче других фильтров). Они хороши для опытных аналитиков “мне нужны чаты в такой-то категории с таким-то охватом”, “мне нужно найти все упоминания бренда в каналах” и т. д. Но это не то, что нужно простому человеку. Простому человеку (в том числе мне), как известно, нужна кнопка “сделать зашибись”. Чтобы можно было написать “канал про жизнь в Сербии” или “бот для оформления esim” и получить результат, а не настраивать бесчисленные фильтры. В подтверждение моей позиции легко найти жалобы на плохой discovery каналов в Telegram. По сути, Telegram похож на веб 90х-00х - простенький поиск по ключевым словам, каталоги сайтов по категориям. Google только недавно появился.

При этом у Telegram миллиард пользователей, так что идея не нишевая.

В общем, можно попробовать. К тому же проект отдаёт серьёзностью (я напроектировал аж 14 микросервисов и оценку в 2 месяца фулл-тайм работы - инфраструктура скрапинга, поиска и т. д., а БД на миллион+ строк попахивает маленькой, но уже Big Data). Такое и в резюме не стыдно добавить и расписать. Если я доведу до ума такой проект, я уже буду не тем человеком, кем был пару месяцев назад.

Первым делом надо раздобыть побольше Telegram юзернеймов. Лучше всего валидных.

Взял индекс Common Crawl, прокачал 16 ТБ через свой домашний компьютер. Так как индекс просто не влез бы на мой 512 ГБ диск, использовал стриминг - извлекалt.meссылки (а также все остальные вариации типа tg://resolve?domain=username) не сохраняя индекс. Скрипт работал неделю без остановок. Собрал более двух с половиной миллионов уникальных юзернеймов (не все из них оказались валидными, конечно же).

Начал скрапитьt.meчерез несколько платных ротируемых прокси. Скрапим только валидные юзернеймы по регулярке. Если видим публичный канал, чат или бота - сохраняем в БД имя + описание + аватар (ссылки на CDN временные, аватары приходится кешировать на своей стороне). Если видим юзера или что-то непонятное - всё равно отмечаем юзернейм как обработанный, но ничего больше не сохраняем.

По итогу 500к каналов, 86 тысяч групп, 55 тысяч ботов. Обогатил данные различными публичными каталогами каналов => стало 800к каналов, 124к групп, 62к ботов. Извлёк юзернеймы иt.meссылки из описаний каналов - нашлось больше 400к, из них 286к оказались новыми. Внезапно произошёл прирост ботов - 94к ботов итого.

Начал скрапить сообщения (последние 10-15, сколько показываетt.meбез пагинации). Если встречается форвард из незнакомого канала, добавляю его в очередь скрапинга. Получил регулярный прирост каналов/чатов/ботов, перестал внимательно следить, кроме того что отметил, что примерно 10% всех упоминаемых новых юзернеймов в каналах - юзернеймы ботов.

От сообщений сохраняется тип + текст (если есть). Самый популярный тип сообщения - одиночная картинка с подписью, с небольшим отставанием идёт текст без медиа. Самый непопулярный тип сообщения - инвойс, на втором месте по антипопулярности - контакт.

Средняя длина текста в сообщении (если он вообще есть) - около 530 символов. Среднее количество сообщений, доступных без пагинации в превью канала - 13.

У ботов нет публичных сообщений, а описания часто неинформативны. Нужно второе описание (которое отображается в пустом диалоге) и список команд. Скрапим через MTProto. Используем юзербота для ResolveUsername + GetFullUser. Медленно из-за жёстких лимитов на ResolveUsername (обновлять потом можно быстро), потенциально нарушаем ToS Telegram (но, полагаю, я немного в серой зоне, так как не собираю данные юзеров, а лишь ботов), могут забанить, никого не агитирую.

Интересные аккаунты

Есть некоторое солидное количество групп и чатов, аватарка которых наt.meне грузится, так как CDN выдаёт 500 ошибку для ссылки (и он будет выдавать её и через день, и через неделю). Например:@magiskcnshare. У некоторых таких аккаунтов хотя бы сам клиент Telegram грузит аватарку, но есть и те, у которых даже в клиенте отображается лишь превью и бесконечная загрузка при попытке её увеличить. В общем, пришлось добавлять в скрапер логику "если аватарка не скачалась 3 раза подряд, то считаем, что у профиля её нет вместо возврата юзернейма в очередь скрапинга".

Есть каналы, в которых есть пустые сообщения. Буквально без тела.

Самый наглядный пример -@vlad_shoky_drum_school- здесь вообще единственное сообщение в канале и оно пустое. Сразу после div с заголовком сообщения идёт div с подвалом, без третьего div посередине с контентом. В клиенте Telegram вместо пустоты отображается 0.

Таких сообщений встретилось несколько десятков. Тоже пришлось добавлять исключение в скрапер.

Но приз на самую уникальность получает чат@vip_labels- в то время как подавляющее большинство аватарок Telegram весят 10-25 Кб, аватарка этого чата весит целых 3.5 Мб! Почему это важно? Потому что в Axum ограничение по умолчанию на тело HTTP запроса - 2 Мб. Соответственно, микросервис ответственный за загрузку аватарок в S3 хранилище отказывался обрабатывать такой запрос от скрапера. Фикс был тривиален - поднять лимит :-)

Обработка аватарок

Семантический поиск по аватаркам можно делать двумя способами:

• Мультимодальный генератор эмбеддингов (например, SigLIP)
• Преобразование аватарки в текст (любая мультимодальная LLM), а потом работаем как с остальным текстом

Хочу иметь возможность экспериментировать с разными алгоритмами эмбеддингов, поэтому хочу перегнать аватарки в текст, но не хочу за это слишком много платить.

Многие модели хотят 500$+ за 1 миллион картинок, не в бюджете.

GPT-4.1 mini - в режиме низкого разрешения картинка занимает всего 85 токенов (у других моделей и других режимов счёт идёт на 1000+ токенов). С учётом промта, входа, выхода, а также батчинга получается 138$ за 1 миллион картинок. Уже терпимо, но всё ещё дорого.

Gemini 2.5 Flash-Lite - 26$ за 1 миллион картинок. Приемлемо, начинаю реализовывать, но плююсь от Gemini Batch API - документация в разных местах противоречит сама себе, из-за этого мой микросервис отправил батч на обработку, прождал несколько часов результат, но не смог распарсить ответ. После фикса новый батч висел больше 8 часов (и без гарантий, что он снова распарсится!).

Надоело. Пошёл искать ещё варианты.

Нахожу бенчмарк -https://playground.roboflow.com/ranking/captioningGemma 3 4B - open-source модель, которую можно запустить на RTX 4090 (в отличие от более жирных моделей). И при этом по задаче captioning она на 7-м месте, опережая оба мои варианта (и то, что её обгоняет, я в любом случае не смогу использовать, потому что там речь о 500 за 1М картинок). Арендую виртуалку наvast.ai, за 24 часа и 6 обрабатываю миллион аватарок.

А для точечной регенерации описания можно использовать эту же модель, но уже на OpenRouter по цене где-то 15$ за миллион аватарок.

База данных

Postgres + pg_vector? Удобный, привычный стек Postgres, и у меня уже есть немного опыта с pg_vector. Но в этот раз я хочу реализовать гибридный поиск, и у меня есть предчувствие, что делать всё руками будет сложно, особенно чтобы оно не тормозило.

ElasticSearch? Умеет всё, что нужно для гибридного поиска. Но у меня предубеждение к инфраструктурным компонентам на Java, и оно только подтверждается, когда прикидываю требования по ОЗУ.

И тут внезапно натыкаюсь на ParadeDB. Обещают Elastic-Quality Search, но на Postgres. Звучит отлично!

Я и так использую Postgres 18 в Docker для того, что уже реализовано, ChatGPT уверяет меня, что можно просто заменить образ (так как до CREATE EXTENSION pg_search это, по сути, обычный Postgres той же версии, а они совместимы, если не менять мажорную версию). Он был не прав. Через несколько часов после замены образа база умирает - начинают появляться дубли в таблицах с UNIQUE индексами, БД замечает это при попытке любых операций как-то затрагивающих такие строки и их невозможно изменить, сбойных строк становится всё больше. Невозможно даже сделать дамп базы данных. Да, можно было бы поискать решения (например, попытаться отключить проверку уникальности), но зачем мне БД в непонятно каком состоянии, у меня же есть ежедневный бекап через pg_dump. Так что просто грохаю Docker volume от Postgres и раскатываю резервную копию. Теряю несколько часов скрапинга (так как тот дамп, который я сделал прямо перед заменой образа, я успел удалить, ведь сначала ничего не сломалось). Проблема уходит.

Эмбеддинги

В моём каталоге ботов (https://tgbotmau.quoi.dev/catalog) хорошо себя зарекомендовал text-embedding-3-large с ценой 0.13$ за мегатокен. При миллионе документов и средней длине документа в 4000 символов это выходит более 130. Дорого!

Использую bge-m3. Обещает хороший семантический поиск на многоязычном датасете (а у меня как раз такой). На OpenRouter стоит 0.01 за мегатокен. Итого 10. При этом, как и в случае с генерацией текстовых описаний аватарок можно начальную генерацию выполнить на виртуалке от vast.ai и это обойдётся в 3-4.

Генерирую эмбеддинги, складываю в pg_vector. Семантический поиск начинает работать, но тупит 10-15 секунд. Оказывается, две вещи:

• Поставщик bge-m3 на OpenRouter имеет несколько секунд latency. Неприятно, но жить можно
• Я ошибся при создании индекса, и он не используется. Приходится создавать новый индекс на уже имеющихся данных, в CONCURRENT режиме создаётся за несколько часов.

И вот появляется первая версия моего поисковика:

Важный нюанс - индекс HNSW имеет параметр количества элементов, которые мы ищем. Задаётся через SET LOCAL hnsw.ef_search = N и суть в том, что поиск проделает работы не больше и не меньше, чем нужно для этого количества результатов. Мы, конечно, можем ограничить их через LIMIT, но если LIMIT меньше ef_search, СУБД всё равно проделает работу, необходимую для поиска ef_search элементов. А если LIMIT больше, чем ef_search, то вернётся меньше результатов. Так что надо ставить ef_search именно таким, какое количество результатов мы хотим получить.

Гибридный поиск

В целом поиск уже работает как магия - ты пишешь “канал с мемами” и ты реально получаешь канал с мемами. Ты пишешь “канал про человека с точки зрения биологии” и ты реально получаешь соответствующие научнопопулярные каналы.

Но есть запросы, в которых семантический поиск откровенно слаб. Например, ты вводишь конкретное название канала или хотя бы его часть (допустим, у канала длинное, но звучное имя, но ты запомнил середину). В этом случае с большой вероятностью можно получить даже не каналы близкой тематики, а вообще полную ерунду (потому что название многих каналов имеет очень условную связь с их содержанием и эмбеддинги начинают просто матчить по признаку “какой-то бессмысленный/абстрактный набор слов”, давая каналы с похожим неймингом, да и то лишь если взглянуть на это глазами ИИ).

С одной стороны, конечно, можно сказать “если знаешь имя канала, ты можешь воспользоваться встроенным поиском Telegram”, но с другой стороны, поисковик ощущается каким-то неполноценным, так как даёт осечку в наиболее тривиальных случаях.

Это можно исправить гибридным поиском - делается независимый поиск и по ключевым словам, и по векторам. А затем результаты объединяются. Если какой-то канал занял высокую позицию хотя бы в одном рейтинге - он должен иметь заметную позицию и в итоговом. Если какой-то канал занял высокую позицию сразу в двух рейтингах - это очень хороший матч и надо поднять его на первые места.

К счастью, с ParadeDB и входящим в него расширением pg_search, это не обязательно реализовывать вручную. Всё заработало почти с первой попытки.

Дальше имел место небольшой тюнинг весов. Ориентировался на то, что по запросу “Лентач” должен на первом месте быть одноимённый канал (победа keyword search), а по запросу “бот чтобы вырастить член” - DickGrowerBot и его конкуренты (победа semantic search). В ранжировании учитывается и информация из профиля канала, и семантическая близость запросу, и количество подписчиков.

По итогу получился удовлетворяющий меня результат.

В качестве бонуса сделал поиск по похожести на существующий чат/бот/канал, если передали известный @username (именно с собакой) и ничего больше.

При тестировании сервиса реальными пользователями оказалось, что не помешает так же пытаться соединить все слова вместе и искать такую подстроку среди юзернеймов. Таким образом @modularbot теперь можно найти по запросам и "modularbot", и "modular bot" (раньше второй запрос не находил релеватное).

API для агентов

В одном чате предложили добавить API для агентов с оплатой за запросы по протоколу x402. Добавил простой поисковый эндпойнт за 0.01 USDC и отправил сервис в несколько каталогов. Чем чёт не шутит, вдруг какой-нибудь блуждающий по Интернету OpenClaw наткнётся на мой сервис и решит, что ему срочно нужно что-то найти в Telegram. Но за несколько дней ничего кроме моих же тестовых платежей на мой кошелёк не пришло :-)

Заключение

Вот так и родился сервисsemagram.io. Надеюсь, он будет вам полезен, а меня натолкнёт на мои следующие идеи.

БД на текущий момент весит уже 50 ГБ, а крутится всё это на моём домашнем сервере на MeLe Quieter 4C (справа).