CIAN: ML System Design

Начать нужно с цели поиска и метрик: клики, открытия, сохранения, чаты/звонки, качественные лиды и выручка с охранными метриками по задержке, пустым выдачам и релевантности. Для объявлений нужны гео, цена, комнаты, площадь, тип объекта, текстовые атрибуты и признаки из фото; дальше строится поиск кандидатов и ранжировщик.

Сначала фиксируем продуктовую поверхность: поиск покупки, долгосрочной аренды, посуточной аренды, квартир или домов может иметь разные интенты. Метрики должны отражать не только CTR, но и открытия карточек, сохранения, сообщения, звонки, качественные лиды, сделки и выручку. Охранные метрики: задержка, пустые выдачи, жалобы, географическое покрытие, баланс платной и органической выдачи, ликвидность для продавцов.

Для объявления нужны структурные признаки: гео, цена, число комнат, площадь, этаж, тип объекта, тип сделки, доступность. Из текста можно извлекать мягкие атрибуты: ремонт, вид, парковка, техника, шум, близость к метро или парку. Из фото полезны качество, ракурс/комната, визуальные эмбеддинги и признаки интерьера.

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

Для частых и точных ограничений лучше извлекать атрибуты из запроса и искать по структурированному или полнотекстовому индексу. Для редких и мягких формулировок нужен векторный поиск по описаниям, чанкам и иногда изображениям. Кандидатов из разных источников объединяем и передаем в ранжировщик с признаками источника совпадения.

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

Для редких формулировок, где нет заранее заведенного признака, нужен векторный поиск. Описание объявления можно разбивать на чанки и строить эмбеддинги, чтобы запросы вроде "тихая квартира рядом с парком" доставали релевантные объявления даже без точного флага. Лексический поиск все равно нужен для адресов, метро, редких имен и точных совпадений.

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

Train on exposed query-listing pairs using graded actions, sampled and impression-based negatives, and position-bias correction. Blend monetization with relevance through expected value and hard relevance/quality guardrails.

The ranker row should represent a listing in a query and user context. Labels can be graded: impression with no action, open, favorite, message, call, qualified lead, booking or purchase. Exposure logs are important because unshown listings are not clean negatives.

Negatives can include random listings, shown-but-not-clicked impressions and hard negatives from the same city/price/type that were skipped in favor of clicked listings. Position bias must be handled with features, debiasing, counterfactual logging or cautious interpretation. Pairwise/listwise losses often fit ranking better than pure pointwise classification, but production simplicity matters.

Monetization should not be a raw score bonus. Better framing is expected marketplace value: relevance probability times business value, with constraints on relevance, geography, quality, paid quota, user harm and seller fairness. Keep organic and paid candidates eligible only when they satisfy the query; then blend with calibrated scores and A/B-test revenue, lead quality and user guardrails.

Evaluate components with proxy labels and the whole pipeline with business A/B metrics. Always slice by geo, price, property type, query class, paid/organic mix and latency.

Component metrics answer whether each block works: attribute extraction F1, geo parsing accuracy, retrieval recall@K, ranker nDCG/MRR, calibration and coverage. These metrics are useful for debugging but do not prove product value.

The full pipeline needs online evaluation: CTR, listing opens, favorites, calls/messages, qualified leads, bookings/purchases, revenue and retention. Guardrails should include latency, empty results, complaint rate, diversity, long-tail coverage, fairness between paid and organic content and seller-side liquidity.

Slicing matters because real-estate search is heterogeneous. A model can improve Moscow rentals and hurt regional daily rentals, or improve cheap apartments and hurt premium new builds. Good evaluation reports slice by city/region, price band, property type, transaction type, query intent and paid-content exposure.

Use geocoding/entity resolution for explicit places, user/session context for ambiguity, hierarchical geo cells for retrieval, and shard indexes by geo while precomputing listing embeddings offline.

Geo is not just another text token. Queries can mention city, district, metro, street, landmark or ambiguous names that exist in many regions. A robust system combines NER/geocoding, dictionaries, maps data, user/session location and selected transaction context.

Represent geo hierarchically: country, region, city, district, neighborhood, metro/landmark and a spatial cell such as geohash/H3. Retrieval can first choose eligible geo scopes, then query only relevant shards or partitions. If the query has no explicit geo, use product context and user defaults carefully.

For load, precompute listing embeddings and listing attribute indexes offline. Online work should mostly parse the query, fetch candidate lists from geo-sharded lexical/vector indexes, and run a bounded ranker. Use ANN parameters, cache hot query parses, batch neural query encoding when useful, and monitor p95/p99 latency by city and query type.

Keep the online path synchronous and bounded: query parser, retrieval services, feature fetch, ranker, blending and fallback. Use async queues for offline index/model updates, not for the user-facing critical path.

A simple online path is: API/search gateway receives query; query parser extracts text embedding, attributes and geo; retrieval services query lexical/vector/structured indexes; feature service fetches bounded item/user/context features; ranker scores candidates; blender applies paid/organic and business constraints; response is returned with logging.

Inter-service calls on the critical path are usually synchronous RPC/HTTP/gRPC with tight timeouts, retries where safe and circuit breakers. If the query parser or ranker fails, degrade to lexical/structured search, cached hot results, previous stable model or business-rule ranking. Kafka or another broker is better for offline index updates, feature refresh, training logs and model publish events, not for waiting on every user query.

Reliability needs health checks that execute real inference, p95/p99 latency monitoring, coverage metrics, cache hit rate, fallback rate, empty-result rate and rollback for model/index versions. Avoid passing huge embeddings or candidate payloads between too many services if co-locating retrieval and ranking is simpler and faster.

Bootstrap from filter sessions by generating natural-language queries for filter combinations, add human/LLM validation, train the parser, then replace synthetic assumptions with real query logs after launch.

When historical text queries do not exist, the strongest source is existing filter behavior. A session with city, price, rooms, dates, amenities and clicked listings can be converted into one or several plausible text queries.

Use LLMs to generate diverse paraphrases from filter JSON, but keep the labels from the original structured filters. Add constraints so generated text does not invent attributes. Sample realistic partial filters, not only fully specified listings. Validate a subset with humans and build adversarial cases for ambiguous geo, slang, typos and long-tail amenities.

The first model can be a multi-label classifier/sequence tagger for attributes plus a geo resolver and text encoder. After launch, log real text queries, clicked/listed items and user corrections. Gradually reweight toward real data and keep synthetic data for coverage and regression tests.

Improve item representation with room/photo classification, image quality, extracted amenities and multimodal embeddings; add user/session context cautiously and measure gains by slices.

After a baseline works, richer item representations often pay off. For photos, classify room type, detect low-quality or irrelevant images, select the best cover photo, extract visible amenities and compute visual embeddings. For text, normalize attributes and enrich descriptions with extracted structured facts.

User and session context can improve relevance: previous searches, viewed listings, favorites, price tolerance, preferred districts, device, travel dates and transaction type. Use it carefully so the model does not override explicit query constraints.

VLMs can help with long-tail visual attributes such as "bright kitchen", "renovated bathroom" or "view of park", but they need evaluation for hallucinations and latency. Many VLM outputs are better used offline to enrich listings rather than online per query. Every improvement should be evaluated by query type, property type, geo and freshness because image-heavy gains may not generalize.

VLM лучше использовать в основном офлайн: извлекать признаки из фото, эмбеддинги, теги комнаты или вида из окна и обогащать объявления. Чат-ассистент должен работать поверх результатов поиска и проверенных фактов объявления, задавать уточнения и собирать подборки, но не выдумывать объекты и не обходить жесткие ограничения ранжирования.

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

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

Чат-ассистент - это UX-слой поверх поиска. Он может принимать запрос, задавать уточняющие вопросы, объяснять компромиссы и собирать подборку из уже найденных реальных объявлений. Для RAG ему нужны результаты поиска и проверенные факты объявления, а не свободная генерация объектов. Метрики: привязанность ответа к источникам, фактологическая точность, успешность задачи, качество лида, задержка и влияние на основные поисковые метрики.