Telegram Semantische Suche: Scraping und Embeddings

Globale semantische Suche über Telegram-Kanäle und -Bots aufbauen

Ein Entwickler hat eine Datenbank mit Millionen von Telegram-Accounts erstellt, indem er Daten für die semantische Suche extrahiert und verarbeitet hat. Das Projekt basiert auf einer Infrastruktur aus 14 Microservices, die gezielt für mittlere bis erfahrene Entwickler konzipiert ist. Der Fokus liegt auf hybrider Suche über Beschreibungen, Nachrichten und Profilbilder – ohne dass Filterkonfiguration nötig ist.

Über 2,5 Millionen eindeutige Benutzernamen wurden aus dem Common Crawl (16 TB Index) gesammelt, verarbeitet und innerhalb einer Woche auf einem Heim-PC in Echtzeit verarbeitet. Ergebnisse: 800.000 Kanäle, 124.000 Gruppen, 94.000 Bots. Zusätzliche Daten wurden durch öffentliche Verzeichnisse und Links aus Beschreibungen angereichert.

Datenextraktion

Extraktion über rotierende Proxy-Server mit gültigen Benutzernamen (regex-basiert). Gespeicherte Daten umfassen:

• Name, Beschreibung, Profilbild (CDN-Links zwischengespeichert).
• Letzte 10–15 Nachrichten ohne Pagination (Nachrichtentyp, Text; Durchschnittslänge: 530 Zeichen).

Weitergeleitete Nachrichten werden zur Verarbeitung in die Warteschlange gestellt. Nachrichtenstatistiken:

• Nur Text.
• Bild mit Untertitel.
• Selten: Rechnung, Kontakt.

Für Bots: MTProto (grammers) via ResolveUsername + GetFullUser zur Abfrage von Beschreibung und Befehlen. Vorsicht bei Rate-Limits von ResolveUsername.

Ausnahmefälle:

• CDN-500-Fehler bei Avataren (z. B. @magiskcnshare) – nach 3 Versuchen übersprungen.
• Leere Nachrichten (@vlad_shoky_drum_school).
• Große Avatare (3,5 MB, z. B. @vip_labels) – Axum-Limit auf 4 MB erhöht.

Bildverarbeitung

Semantische Suche über Profilbilder mittels Captioning (textbasiert statt multimodaler Embeddings für Experimente).

Optionen und Kosten für 1 Million Bilder:

| Modell | Preis ($) | Tokens/Bild | Status |

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

| GPT-4o mini (niedrige Auflösung) | 138 | 85 | Teuer |

| Gemini 2.5 Flash-Lite | 26 | Niedrig | Batch-API instabil |

| Gemma 3 4B (vast.ai) | ~0,24/Tag | - | Ausgewählt: RTX 4090, 1 Mio. in 24 h |

Gemma 3 4B (7. Platz im Roboflow-Captioning-Benchmark) – Open-Source, lokale Ausführung. Neuausführung über OpenRouter (15 $ pro Million).

Datenbank und Suche

Getestete Optionen:

• Postgres + pg_vector: vertraut, aber hybride Suche manuell komplex.
• Elasticsearch: leistungsfähig, aber hoher RAM-Verbrauch (Java-lastig).

Ausgewählt: ParadeDB (Elastic-artige Suche auf Postgres 18). Problem beim Docker-Image-Update: Doppelte Einträge in UNIQUE-Indizes führten zum Dump-Fehler. Lösung: Zurückrollen auf täglichen pg_dump-Backup.

Hybride Suche: Schlüsselwortabgleich + Vektor-(semantische) Suche.

Embedding-Generierung

Getestet: text-embedding-3-large (0,13 $/M Tokens), aber zu teuer für 1 Mio. Dokumente à 4.000 Zeichen (>130 $). Umgestiegen auf bge-m3 (mehrsprachig, führend im MTEB-Benchmark).

OpenAI-API für 12.000 Embeddings: 0,03 $. Skalierung auf Millionen über OpenRouter.

Wichtige Erkenntnisse:

• Über 800.000 Kanäle mit semantischem Kontext aus Beschreibungen und Nachrichten indiziert.
• Gemma 3 4B Captioning: kostengünstig und äußerst präzise.
• ParadeDB ermöglicht hybride Suche ohne Java-Stack.
• MTProto für Bots verwendet (ToS-Risiko, aber nur öffentliche Daten abgerufen).
• Kontinuierliches Wachstum durch weitergeleitete Nachrichten.

Dieses Projekt zeigt einen end-to-end-Pipeline: Extraktion → Verarbeitung → Vektor-Suche. Ideal für Portfolio-Demos (Big Data im großen Maßstab, Millionen von Datensätzen).

— Editorial Team