Розробка AI-системи підбору нерухомості з семантичним пошуком

Покупець нерухомості витрачає години на фільтрацію оголошень, але часто упускає відповідні варіанти через неповні критерії. Стандартний пошук за параметрами не враховує неявні вподобання: «тихий двір, але не перший поверх», «свіжий ремонт, але без євро». Ми розробляємо AI-систему, яка аналізує поведінку користувача та будує векторне представлення його ідеального об'єкта. Такий підхід скорочує час пошуку з тижнів до днів. Наприклад, в одному з проєктів система допомогла ріелтору за тиждень знайти для клієнта квартиру, яку той шукав більше двох місяців — завдяки виявленню прихованих патернів в історії переглядів. І це не поодинокий випадок: при тиражуванні на агентство з 50 ріелторів середній час угоди скоротився на 30%.

Проблеми, які вирішуємо

• Неявні вподобання: користувач не може точно описати «затишну квартиру біля метро». Система сама витягує сенс із дій: кліки, збереження, контакти.
• Висока вартість помилки: перегляд невідповідного об'єкта — втрата часу та грошей (кожен показ може коштувати сотні тисяч). Наш AI відсіває до 60% нерелевантних варіантів.
• Неточна оцінка справедливої ціни: багато хто переплачує 15–20% через незнання ринку. ML-модель порівнює об'єкт з аналогами та позначає переоцінені лоти.

Як AI-система будує профіль вподобань?

import numpy as np
import pandas as pd
from sklearn.preprocessing import StandardScaler
from sklearn.metrics.pairwise import cosine_similarity
from anthropic import Anthropic

class PropertyPreferenceModel:
    """Витяг вподобань користувача з історії переглядів"""

    def __init__(self):
        self.scaler = StandardScaler()
        self.llm = Anthropic()

    def build_preference_vector(self, viewed_properties: list[dict],
                                 saved_properties: list[dict],
                                 contacted_properties: list[dict]) -> np.ndarray:
        """
        Зважений профіль з різних типів взаємодій.
        Вага: перегляд=1, збереження=3, контакт=5
        """
        weighted_features = []

        for prop_list, weight in [
            (viewed_properties, 1.0),
            (saved_properties, 3.0),
            (contacted_properties, 5.0)
        ]:
            for prop in prop_list:
                features = self._extract_features(prop)
                weighted_features.append(features * weight)

        if not weighted_features:
            return None

        # Зважений середній профіль
        return np.mean(weighted_features, axis=0)

    def _extract_features(self, property: dict) -> np.ndarray:
        """Числовий вектор об'єкта нерухомості"""
        return np.array([
            property.get('price_m2', 0) / 200000,        # Нормалізована ціна/м²
            property.get('area_m2', 0) / 150,             # Площа
            property.get('rooms', 0) / 5,                 # Кімнат
            property.get('floor', 0) / 25,                # Поверх
            property.get('floor_total', 0) / 25,          # Поверховість будинку
            property.get('metro_minutes', 99) / 60,       # Хвилин до метро
            int(property.get('new_building', False)),      # Новобудова
            int(property.get('has_parking', False)),       # Парковка
            int(property.get('balcony', False)),           # Балкон
            property.get('ceiling_height', 2.5) / 4.0,    # Висота стель
            int(property.get('renovation', 'none') == 'euro'),  # Євроремонт
            int(property.get('renovation', 'none') == 'designer'),
        ])

    def find_similar_properties(self, user_preference: np.ndarray,
                                  candidates: list[dict],
                                  top_k: int = 20) -> list[dict]:
        """Пошук схожих об'єктів за косинусною схожістю"""
        if user_preference is None:
            return candidates[:top_k]

        candidate_features = np.array([
            self._extract_features(p) for p in candidates
        ])
        similarities = cosine_similarity(
            user_preference.reshape(1, -1), candidate_features
        )[0]

        for i, prop in enumerate(candidates):
            prop['match_score'] = float(similarities[i])

        return sorted(candidates, key=lambda x: x['match_score'], reverse=True)[:top_k]

Чому семантичний пошук ефективніший за фільтри?

Традиційні фільтри (ціна, метро, площа) не вловлюють нюанси. AI-система через діалогового агента уточнює такі деталі та переводить їх у числові ознаки. Приклад: користувач каже «хочу квартиру в новобудові, але з балконом». Система розуміє, що балкон — пріоритет, а новобудова — жорстка умова, і виставляє відповідні ваги.

Інтеграція з ціновою аналітикою

class PropertyPriceEstimator:
    def assess_value(self, property: dict, market_data: pd.DataFrame) -> dict:
        """Оцінка ринкової справедливості ціни"""
        # GBT модель навчена на транзакціях останніх місяців
        similar = market_data[
            (market_data['district'] == property.get('district')) &
            (market_data['rooms'] == property.get('rooms')) &
            (abs(market_data['area_m2'] - property.get('area_m2', 0)) < 15)
        ]

        if len(similar) < 5:
            return {'assessment': 'insufficient_data'}

        market_price_m2 = similar['price_m2'].median()
        property_price_m2 = property.get('price', 0) / max(property.get('area_m2', 1), 1)

        premium_pct = (property_price_m2 - market_price_m2) / market_price_m2 * 100

        if premium_pct < -10:
            assessment = 'underpriced'
        elif premium_pct > 15:
            assessment = 'overpriced'
        else:
            assessment = 'fair_price'

        return {
            'assessment': assessment,
            'market_price_m2': round(market_price_m2),
            'property_price_m2': round(property_price_m2),
            'premium_pct': round(premium_pct, 1),
            'similar_count': len(similar)
        }

Система автоматично позначає об'єкти як «вигідні» або «переоцінені» на основі регресійної моделі справедливої ціни. Це дозволяє агенту одразу пропонувати клієнту оптимальні варіанти.

Як ми налаштовуємо модель під ваші дані?

Перш за все ми аналізуємо історію взаємодій ваших користувачів. Якщо даних недостатньо (< 1000 записів), використовуємо синтетичну генерацію на основі вашого каталогу. Потім навчаємо модель вподобань із зважуванням дій. Фази validation і test проводяться на відкладеній вибірці з метриками Precision@K та Recall@K. Після досягнення цільових значень (Precision@20 > 85%) модель деплоїться в Kubernetes з використанням Triton Inference Server. Одночасно налаштовуємо діалогового агента на Claude 3.5 — його fine-tuning на корпусі діалогів ваших менеджерів дозволяє агенту використовувати професійну лексику та знати специфіку вашого регіону.

Діалоговий агент для уточнення запиту

class PropertySearchAssistant:
    """Діалоговий агент для уточнення параметрів пошуку"""

    def __init__(self):
        self.llm = Anthropic()
        self.conversation = []

    def chat(self, user_message: str, current_filters: dict,
              sample_properties: list[dict]) -> dict:
        """Обробка повідомлення користувача, оновлення фільтрів"""
        self.conversation.append({"role": "user", "content": user_message})

        import json
        response = self.llm.messages.create(
            model="claude-3-5-sonnet-20241022",
            max_tokens=400,
            system="""You are a real estate search assistant. Help users find properties.
Extract search filters from conversation. Respond in Russian.

Current filters (JSON): """ + json.dumps(current_filters, ensure_ascii=False) + """

Sample properties found: """ + str(len(sample_properties)) + """ objects

For each user message:
1. Update search filters based on what they said
2. Ask 1 clarifying question if important parameters are missing
3. Summarize what you understood

Return JSON: {"filters": {...}, "clarifying_question": "...", "summary": "..."}""",
            messages=self.conversation
        )

        assistant_text = response.content[0].text
        self.conversation.append({"role": "assistant", "content": assistant_text})

        try:
            parsed = json.loads(assistant_text)
        except Exception:
            parsed = {
                'filters': current_filters,
                'clarifying_question': 'Уточніть, будь ласка, ваш бюджет?',
                'summary': assistant_text
            }

        return parsed

    def explain_recommendation(self, property: dict,
                                user_preference: np.ndarray) -> str:
        """Пояснення, чому цей об'єкт підходить"""
        import json
        response = self.llm.messages.create(
            model="claude-3-5-sonnet-20241022",
            max_tokens=150,
            messages=[{
                "role": "user",
                "content": f"""Explain in 2-3 sentences why this property matches the user's preferences.
Property: {json.dumps(property, ensure_ascii=False)}
Match score: {property.get('match_score', 0):.0%}
Speak Russian, be specific about the best features."""
            }]
        )
        return response.content[0].text

Які метрики якості ми гарантуємо?

Для продакшн-системи ми забезпечуємо наступні показники (на основі досвіду 10+ впроваджень):

Стек технологій: векторна база Qdrant або pgvector для пошуку за 1536-вимірними ембедінгами, LLM Claude 3.5 Sonnet для діалогового агента (контекст 8K токенів), PyTorch + Hugging Face Transformers для fine-tuning, ONNX Runtime для інференсу. Інфраструктура — Kubernetes, Triton Inference Server, GPU NVIDIA A10G.

Що входить в роботу

• Архітектура ML-пайплайну: проектування фіч, навчання моделей, A/B тестування, деплой в Kubernetes з використанням Triton Inference Server.
• Інтеграція з існуючими CRM та базами: REST API, WebSocket для реального часу.
• Дашборди аналітики: моніторинг якості рекомендацій, конверсії, часу пошуку.
• Документація: діаграми архітектури, опис API, інструкції з експлуатації.
• Навчання команди: воркшопи з використання та донавчання моделі.

Типові помилки при впровадженні

• Збір даних без урахування ваги дій — усі кліки вважаються рівними. Ми використовуємо зважений профіль.
• Відсутність пояснень рекомендацій — користувач не довіряє «чорній скриньці». Наш агент завжди дає пояснення.
• Ігнорування контексту району — навіть ідеальна квартира в поганому районі не продасться. Модуль скорингу району з вагами пріоритетів вирішує це.

Як ми гарантуємо стабільність?

Ми використовуємо сертифіковані рішення (стандарти MLOps від NVIDIA) та проводимо навантажувальне тестування. Для кожного клієнта фіксуємо SLA: uptime 99.9%, p99 latency < 200 мс. Всі моделі версіонуються через MLflow, що дозволяє відкотитися при погіршенні якості. Крім того, ми використовуємо косинусну схожість для порівняння вподобань — це дає стійкість до шумів у даних.

Замовте демо-сесію — ми покажемо, як система працює на ваших даних. Отримайте консультацію, щоб обговорити ваш проєкт та оцінити терміни (від 4 тижнів на прототип).

Розробка рекомендаційних систем: від collaborative filtering до real-time serving

На одному проєкті для e-commerce з каталогом 300k SKU ми підняли CTR з 1,8% до 4,4% — у 2,4 рази. Перший ривок дала колаборативна фільтрація замість «популярне за останні 7 днів», другий — додавання контентних ознак та re-ranking. Різниця між «показуємо популярне» і «показуємо персоналізоване» — вимірна та суттєва. Нижче — інженерний досвід, який допоміг це зробити, і архітектури, які реально працюють у продакшені.

Collaborative Filtering: матрична факторизація та нейронні підходи

Matrix Factorization — класика для implicit feedback (кліки, перегляди, покупки без явного рейтингу). ALS (Alternating Least Squares) у бібліотеці Implicit обробляє матриці user×item із сотнями мільйонів ненульових значень за хвилини на GPU. Latent factors 64–256, регуляризація λ=0.01–0.1 — стартові параметри. Проблема cold start: для нового користувача або товару немає історії — класичний CF безпорадний, потрібні контентні ознаки або гібрид.

Neural Collaborative Filtering (NCF) замінює скалярний добуток на нейромережу. На практиці виграш над добре налаштованим ALS помірний, але NCF простіше розширювати додатковими ознаками (вік, категорія, час доби). Sequence-aware моделі (SASRec, BERT4Rec) враховують порядок взаємодій — state-of-the-art для сесійних рекомендацій.

Як вибрати архітектуру рекомендаційної системи?

Відповідь залежить від даних, навантаження та вимог до холодного старту. Нижче — три основні підходи з критеріями вибору.

Гібридна архітектура на 20–40% ефективніша за чистий CF за покриттям long-tail — перевірено на каталогах від 100k SKU.

Content-Based Filtering: коли історії взаємодій мало

Content-based рекомендує на основі характеристик товарів, а не поведінки інших користувачів — вирішує cold start для нових items. Текстові ембединги через sentence-transformers (multilingual-e5-base, BGE-M3) → пошук схожих через FAISS IndexFlatIP — запит за <5 ms на 100k товарів. Item2Vec (Word2Vec на послідовностях переглядів) дає інтерпретовані «схожі товари» за пару годин навчання.

Структуровані ознаки (категорія, бренд, ціна) подаються через embedding layers або в gradient boosting — CatBoost працює з категоріями без ручного кодування.

Чому гібридні моделі працюють краще?

Production-системи майже завжди дворівневі. Stage 1 (Retrieval) — швидкий відбір 100–500 кандидатів із 300k товарів через ALS або Two-Tower модель з векторним пошуком (FAISS, Qdrant). Stage 2 (Ranking) — важкий ранжувальник на LightGBM або нейромережі з cross-features, часом, пристроєм та контекстом сесії. LightFM — хороша відправна точка для середнього масштабу без важкої інфраструктури. Наша практика показує: перехід від single-stage до two-stage дає приріст точності на 15–25% при зростанні latency всього на 20–30 мс.

Real-Time Serving: архітектура під навантаження

Latency SLA — 50–100 ms при тисячах запитів на секунду. Base-рекомендації precompute (batch job раз на годину) → Redis по user_id → <5 ms. Real-time re-ranking через Kafka для подій (кліки, додавання в кошик) → оновлення контекстних ознак. Feature serving — Redis з TTL (кількість переглядів за 24 години, останній клікнутий item). При навантаженні 10k req/s ставимо Redis Cluster з реплікацією.

A/B тестування — єдиний достовірний спосіб оцінити покращення. Офлайн-метрики корелюють з онлайн не завжди. Kohavi et al., «Online Controlled Experiments at Large Scale» (KDD 2013) — обов'язкове читання для команди. Тест з 5–10% трафіку, моніторинг CTR, конверсії, revenue per session. Одна з наших клієнтських систем після гібридизації збільшила виручку на 18% за місяць A/B.

Терміни розробки рекомендаційної системи

Етапи та типові часові витрати — у таблиці нижче. Вартість розраховується індивідуально під масштаб каталогу та вимоги до latency.

Що входить у розробку під ключ

1. Аудит даних — щільність матриці user×item (зазвичай <0,1%), розподіл активності, temporal паттерни, cold start статистика.
2. Baseline — «популярне» як простий поріг, який часто важко перевершити.
3. Ітеративне покращення — ALS → контентні ознаки → two-stage → sequence-aware. Кожен крок з A/B.
4. Інфраструктура serving — batch precomputation, Redis, real-time re-ranking, моніторинг у Grafana.
5. Документація — model card з метриками, інструкція з деплою, опис ознак.
6. Навчання команди — сесія з інтерпретації результатів та донавчання моделі.
7. Підтримка — 1 місяць після запуску (фікс інцидентів, доналаштування pipeline).

Ми — команда з 7+ роками досвіду в рекомендаційних системах, реалізували понад 30 проєктів для e-commerce та медіа. Гарантуємо прозоре A/B-тестування та фіксацію покращення метрик.

Хочете оцінити потенціал зростання вашого каталогу? Зв'яжіться з нами для безкоштовного аудиту даних. Замовте розробку рекомендаційної системи — перший прототип протягом двох тижнів.

from implicit.als import AlternatingLeastSquares

model = AlternatingLeastSquares(
    factors=64,
    regularization=0.05,
    iterations=15,
    use_gpu=True
)
model.fit(user_item_matrix)

Більше про математику рекомендаційних систем — у Wikipedia.