Búsqueda semántica de Telegram: Raspado y embeddings

Construyendo una búsqueda semántica global en canales y bots de Telegram

Un desarrollador creó una base de datos con millones de cuentas de Telegram mediante el scraping y procesamiento de datos para búsqueda semántica. El proyecto cuenta con una infraestructura de 14 microservicios diseñada para ingenieros intermedios a senior. El enfoque principal es la búsqueda híbrida en descripciones, mensajes y fotos de perfil — sin necesidad de configurar filtros.

Se recopilaron más de 2.5 millones de nombres de usuario únicos a partir de Common Crawl (índice de 16 TB), procesados mediante streaming en una PC doméstica en solo una semana. Resultados válidos: 800k canales, 124k grupos, 94k bots. Los datos adicionales se enriquecieron usando directorios públicos y enlaces incluidos en las descripciones.

Escaneo de datos

Escaneo mediante proxies rotativos usando nombres de usuario válidos (basado en expresiones regulares). Los datos almacenados incluyen:

• Nombre, descripción, foto de perfil (enlaces CDN cacheados).
• Últimos 10–15 mensajes sin paginación (tipo de mensaje, texto; longitud promedio: 530 caracteres).

Los mensajes reenviados se colocan en cola para su procesamiento. Estadísticas de mensajes:

• Solo texto.
• Imagen con leyenda.
• Rara vez: factura, contacto.

Para bots: uso de MTProto (grammers) mediante ResolveUsername + GetFullUser para obtener descripción y comandos. Usar con precaución debido a los límites de tasa de ResolveUsername.

Manejo de casos especiales:

• Errores 500 del CDN en avatares (por ejemplo, @magiskcnshare) — omitidos tras 3 intentos.
• Mensajes vacíos (@vlad_shoky_drum_school).
• Avatares grandes (3.5 MB, por ejemplo, @vip_labels) — aumento del límite de Axum a 4 MB.

Procesamiento de imágenes

Búsqueda semántica en fotos de perfil usando generación de descripciones (bajo texto, no multimodal, por experimentación).

Opciones y costos para 1 millón de imágenes:

| Modelo | Precio ($) | Tokens/imagen | Estado |

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

| GPT-4o mini (baja resolución) | 138 | 85 | Caro |

| Gemini 2.5 Flash-Lite | 26 | Bajo | API por lotes inestable |

| Gemma 3 4B (vast.ai) | ~$0.24/día | - | Elegido: RTX 4090, 1M en 24h |

Gemma 3 4B (7º lugar en benchmark de Roboflow para generación de descripciones) — código abierto, ejecución local. Regeneración mediante OpenRouter ($15 por millón).

Base de datos y búsqueda

Opciones probadas:

• Postgres + pg_vector: conocido, pero la búsqueda híbrida manual es compleja.
• Elasticsearch: potente, pero alto consumo de RAM (dependiente de Java).

Elegido: ParadeDB (búsqueda similar a Elastic sobre Postgres 18). Problema durante la actualización de imagen Docker: duplicados en índices UNIQUE causaron fallo en el volcado. Solución: reversión al respaldo diario pg_dump.

Búsqueda híbrida: coincidencia de palabras clave + búsqueda vectorial (semántica).

Generación de embeddings

Probado text-embedding-3-large (0.13$/M tokens), pero el costo era demasiado alto para 1M documentos de 4.000 caracteres cada uno (> $130). Se cambió a bge-m3 (multilingüe, líder en benchmark MTEB).

API de OpenAI para 12k embeddings: $0.03. Escalabilidad a millones mediante OpenRouter.

Conclusiones clave:

• Más de 800k canales indexados con contexto semántico extraído de descripciones y mensajes.
• Generación de descripciones con Gemma 3 4B: bajo costo y alta precisión.
• ParadeDB permite búsqueda híbrida sin dependencia de Java.
• Uso de MTProto para bots (riesgo de Términos de Servicio, pero solo se accede a datos públicos).
• Crecimiento continuo gracias a mensajes reenviados.

Este proyecto demuestra un flujo completo: escaneo → procesamiento → búsqueda vectorial. Ideal para demostraciones de portafolio (Big Data a gran escala, millones de registros).

— Editorial Team