Recherche sémantique Telegram : Scraping et Embeddings

Construire une recherche sémantique mondiale sur les canaux et bots Telegram

Un développeur a créé une base de données de millions de comptes Telegram en extrayant et en traitant des données pour une recherche sémantique. Le projet repose sur une infrastructure de 14 microservices conçue pour les ingénieurs intermédiaires à confirmés. L'objectif central est une recherche hybride sur les descriptions, les messages et les photos de profil — aucune configuration de filtre n'est nécessaire.

Plus de 2,5 millions de pseudos uniques ont été collectés à partir de Common Crawl (index de 16 To), traités en streaming sur un PC personnel en seulement une semaine. Résultats valides : 800 000 chaînes, 124 000 groupes, 94 000 bots. Des données supplémentaires ont été enrichies grâce à des annuaires publics et aux liens présents dans les descriptions.

Extraction des données

Extraction via proxys rotatifs utilisant des pseudos valides (basée sur des expressions régulières). Les données stockées incluent :

• Nom, description, photo de profil (liens CDN mis en cache).
• Derniers 10 à 15 messages sans pagination (type de message, texte ; longueur moyenne : 530 caractères).

Les messages transférés sont mis en file d'attente pour traitement. Statistiques des messages :

• Texte uniquement.
• Image avec légende.
• Très rarement : facture, contact.

Pour les bots : utilisation du protocole MTProto (grammers) via ResolveUsername + GetFullUser pour récupérer la description et les commandes. À utiliser avec précaution en raison des limites de fréquence de ResolveUsername.

Gestion des cas particuliers :

• Erreurs CDN 500 sur les avatars (ex. @magiskcnshare) — ignorés après 3 tentatives.
• Messages vides (@vlad_shoky_drum_school).
• Avatars volumineux (3,5 Mo, ex. @vip_labels) — augmentation de la limite Axum à 4 Mo.

Traitement des images

Recherche sémantique sur les photos de profil en utilisant la génération de légendes (approche textuelle au lieu d'embeddings multimodaux, pour expérimentation).

Options et coûts pour 1 million d’images :

| Modèle | Prix ($) | Tokens/image | État |

|--------|----------|---------------|------|

| GPT-4o mini (faible résolution) | 138 | 85 | Coûteux |

| Gemini 2.5 Flash-Lite | 26 | Faible | API par lots instable |

| Gemma 3 4B (vast.ai) | ~0,24/jour | - | Choisi : RTX 4090, 1M en 24h |

Gemma 3 4B (7e place au classement Roboflow pour la génération de légendes) — open source, exécution locale. Régénération via OpenRouter (15 $ par million).

Base de données et recherche

Options testées :

• Postgres + pg_vector : familier, mais la recherche hybride manuelle est complexe.
• Elasticsearch : puissant, mais nécessite beaucoup de RAM (pile Java lourde).

Choix : ParadeDB (recherche similaire à Elastic sur Postgres 18). Problème lors de la mise à jour de l'image Docker : doublons dans les index UNIQUE ont causé l’échec de la sauvegarde. Solution : retour à une sauvegarde quotidienne pg_dump.

Recherche hybride : correspondance de mots-clés + recherche vectorielle (sémantique).

Génération des embeddings

Testé text-embedding-3-large (0,13 $/M tokens), mais le coût était trop élevé pour 1 million de documents de 4 000 caractères chacun (> 130 $). Passage à bge-m3 (multilingue, leader du benchmark MTEB).

API OpenAI pour 12 000 embeddings : 0,03 $. Montée à grande échelle via OpenRouter.

Principales leçons :

• Plus de 800 000 chaînes indexées avec un contexte sémantique tiré des descriptions et des messages.
• Génération de légendes Gemma 3 4B : faible coût, très précise.
• ParadeDB permet la recherche hybride sans pile Java.
• MTProto utilisé pour les bots (risque de violation des Conditions d'utilisation, mais uniquement des données publiques accessibles).
• Croissance continue via les messages transférés.

Ce projet illustre un pipeline complet : extraction → traitement → recherche vectorielle. Idéal pour des démos de portfolio (Big Data à grande échelle, millions d’enregistrements).

— Editorial Team