Архитектура поиска в городских чатах: от лог-файлов к живым уведомлениям

# Как искать живой спрос в шумных городских Telegram-чатах

*Городские Telegram-чаты похожи на непрерывный поток логов без схемы. В одном сообщении человек ищет квартиру, в следующем — агент публикует двадцатую копию объявления. Ниже описана система, решающая эту проблему для города Нячанг.*

Поиск полезной информации в общественных Telegram-каналах — это классическая задача, осложненная спецификой пользовательского поведения. Сообщения в таких чатах часто формируются на нормальном языке: «нужен тихий байк без прав», «кто сегодня меняет доллары», «ищу мастера починить кондиционер». Однако технические реализации часто сталкиваются с тем, что автор сообщения использует совершенно иную терминологию: «50cc scooter», «обмен USD», «ремонт сплита». Простой полнотекстовый поиск здесь неэффективен.

Кроме того, возникает проблема с точными сущностями. Для запроса вроде «Honda Lead 2012» семантическая близость не должна вытеснять конкретные данные о модели, годе выпуска и названии. В таких условиях универсальный поисковый движок уступает гибкому маршрутизатору, способному выбирать режим обработки данных.

Гибридный алгоритм маршрутизации

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

* Лексический режим активируется, когда в запросе присутствуют обязательные якоря: конкретные числа, адресные строки, имена моделей или фамилии. Здесь важен точный совпадение фактов. * Векторный режим включается, когда приоритетом является смысл. Запрос преобразуется в эмбеддинг (embedding) и кандидаты ищутся по косинусному расстоянию в базе PostgreSQL с использованием расширения pgvector.

Важно отметить, что порог для оценки близости не является статичным. Распределение кандидатов меняется от запроса к запросу. Поэтому граница допустимого расстояния выбирается динамически, по «локтям» в последовательности полученных дистанций. Если выраженный разрыв в данных отсутствует, система переключается на ограниченный fallback-механизм.

Для тех, кто не знаком с терминологией: эмбеддинг — это способ представления слова или фразы в виде числового вектора, позволяющего компьютеру понимать смысловую близость понятий, а не просто их буквальное совпадение.

Нормализация и управление дублями

Индексировать сырой текст напрямую неудобно и ненадежно. Перед поиском каждое сообщение превращается в структурированное событие. Этот процесс включает извлечение краткого резюме, определение категории и намерения, а также фиксацию временных и предметных атрибутов.

Для векторных данных хранится отдельный статус индекса: pending (ожидание), ready (готово) или failed (ошибка). Это позволяет отдельно обрабатывать сбои при переиндексации, не считая отсутствие вектора отсутствием самого сообщения.

Критически важным этапом является нормализация без искажения фактов. Система не должна «улучшать» данные, которых нет в исходнике. Если в сообщении отсутствует цена, нельзя подставлять типичную для рынка стоимость. Если в тексте неясно, ищут комнату или целую квартиру, классификатор должен сохранить эту неопределенность, а не делать предположение. Сырые сообщения остаются источником истины, а нормализованные поля — лишь поисковым представлением.

Проблема дубликатов также требует особого подхода. Репост одного объявления полезен схлопнуть, но две разные квартиры от одного агента не могут считаться одним предложением. Поэтому дедупликация учитывает не только близость векторов, но и предметные признаки, контактные данные и уникальную «сигнатуру» объявления.

Распознавание намерений: спрос против предложения

Одной из самых сложных задач является различие между спросом и предложением. В контексте уведомлений для бизнеса ошибка в этом разделении является дорогостоящей.

Запрос «Ищу фотографа» отличается от предложения «Снимаю свадьбы». Обычный пользователь может желать видеть предложения, отвечающие его потребностям, но бизнес, подписавшийся на мониторинг канала, хочет знать только о появлении нового спроса.

Система использует явные классы: request (запрос), offer (предложение), info, warning, recommendation и other. При маршрутировании учитывается форма пользовательского запроса. Если человек ищет услугу для себя, ему могут быть показаны предложения. Если же бизнес отслеживает рынок, сообщения с саморекламой не должны засорять канал уведомлений.

Одного слова «ищу» или «предлагаю» недостаточно для точной классификации. В аренде, например, «сниму» и «сдам» различаются одной буквой, но требуют принципиально разных результатов. Противоречащие комбинации отбрасываются или отправляются на повторную обработку.

Фильтрация и язык ответа

Поиск по релевантности (retrieval) отвечает на вопрос «что похоже», но не «что действительно полезно». Поэтому кандидаты проходят финальную фильтрацию. На этом этапе отсеиваются дубли, сообщения с низкой доверительной оценкой (low-confidence) и дубликаты, уже обработанные сегодня. Оставшиеся результаты могут быть сгруппированы и показаны пользователю.

Важный аспект — адаптация под целевую аудиторию. Система должна уметь работать с запросами на любом доступном языке: «нужна няня», «need babysitter», «cherche nounou». При этом ответ и уведомления должны быть выровнены по языку предпочтений пользователя, чтобы не путать его смешением терминов.

Заключение: наблюдательность вместо метрик

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

Главный вывод автора: качество системы нельзя гарантировать абстрактными метриками. Важнее всего — наличие наблюдаемости над очередями, статусами индексации и возможностью ручной проверки на реальных формулировках. Истинная ценность такой системы — не в количестве совпадений, а в способности находить то, что действительно нужно, среди тысяч сообщений, игнорируя шум и дубликаты.