Разработка AI-робо-адвайзера для инвестиций

Проблема: почему большинство робо-адвайзеров не работают

Стартапы и банки часто пытаются скопировать подход Betterment или Wealthfront: берут классическую теорию портфеля (MPT) и натягивают её на локальный рынок. В результате — портфели, не учитывающие поведение инвестора, частые срывы ребалансировки из-за транзакционных издержек и полное отсутствие объяснимости для регулятора. Мы это исправили.

Почему AI-робо-адвайзеры выгоднее традиционных управляющих?

Традиционное управление стоит 1–2% от AuM в год, а робо-адвайзер — 0.25–0.50%. При этом ML-модели улавливают паттерны, которые человек пропускает: например, корреляцию между геополитическими событиями и волатильностью отдельных секторов. В одном из кейсов мы подняли доходность на 2.1% годовых при том же уровне риска за счёт динамической ребалансировки на основе Reinforcement Learning. Для портфеля $10 млн это даёт дополнительно $210 000 в год. А для клиента — понятные объяснения на естественном языке: "Ваш портфель увеличил долю облигаций, потому что ваш инвестиционный горизонт сократился до 3 лет".

Какие проблемы решает ML-профилирование?

Профилирование без ML — гадание на кофейной гуще. Традиционные анкеты из 5 вопросов дают среднестатистический профиль, который не отражает реальное поведение инвестора в кризис. Мы используем LLM (Claude 3.5 Sonnet), которая анализирует не только ответы, но и тональность, противоречия, и генерирует персонализированное описание профиля. Это даёт +30% к соответствию риск-профиля реальным действиям.

Ручная ребалансировка — убытки и ошибки. Когда портфель откланяется от цели на 5%, человек часто медлит или действует эмоционально. Наш RebalancingEngine автоматически проверяет порог и генерирует ордера с учётом минимальной суммы сделки и транзакционных издержек. В одном проекте это сократило издержки на 0.15% годовых — для портфеля $1 млн экономия составила $2 500 в год.

Отсутствие explainability для регулятора. В РФ ЦБ требует показывать клиенту, почему рекомендован именно такой портфель. Мы встраиваем генерацию объяснений через LLM: модуль _explain_profile() формирует 2–3 предложения на простом языке, которые можно показать в интерфейсе или отправить в отчёт.

Как мы строим AI-робо-адвайзер: стек и процесс

Шаг 1: Профилирование инвестора с LLM

Мы используем Anthropic Claude 3.5 Sonnet для анализа анкеты. Каждый вопрос имеет вес — например, возраст: чем моложе инвестор, тем выше допустимая доля акций. Результат — не просто цифра, а объяснение: почему этот профиль подходит именно этому клиенту.

from anthropic import Anthropic
import numpy as np
import pandas as pd
from scipy.optimize import minimize

class InvestorProfiler:
    def __init__(self):
        self.llm = Anthropic()

    def assess_risk_profile(self, questionnaire_answers: dict) -> dict:
        """Определение риск-профиля через анкету"""
        # Скоринг ответов
        risk_score = 0
        max_score = 0

        scoring_rules = {
            'age': lambda x: max(0, (65 - x) / 45 * 20),  # Молодой = выше риск
            'investment_horizon': {'<1y': 5, '1-3y': 10, '3-5y': 15, '>5y': 20},
            'risk_tolerance': {'conservative': 5, 'moderate': 12, 'aggressive': 20},
            'income_stability': {'unstable': 0, 'stable': 5, 'very_stable': 10},
            'loss_reaction': {'sell_all': 0, 'sell_some': 5, 'hold': 10, 'buy_more': 15},
        }

        for question, rules in scoring_rules.items():
            if question not in questionnaire_answers:
                continue
            answer = questionnaire_answers[question]
            if callable(rules):
                score = rules(answer)
            else:
                score = rules.get(answer, 0)
            risk_score += score
            max_score += 20

        normalized = risk_score / max_score

        # Категории риска
        if normalized < 0.3:
            risk_category = 'conservative'
            equity_allocation = 20
        elif normalized < 0.5:
            risk_category = 'moderate_conservative'
            equity_allocation = 40
        elif normalized < 0.7:
            risk_category = 'moderate'
            equity_allocation = 60
        elif normalized < 0.85:
            risk_category = 'moderate_aggressive'
            equity_allocation = 75
        else:
            risk_category = 'aggressive'
            equity_allocation = 90

        profile = {
            'risk_score': normalized,
            'risk_category': risk_category,
            'equity_allocation': equity_allocation,
            'bond_allocation': 100 - equity_allocation - 5,
            'cash_allocation': 5
        }

        # LLM объяснение профиля
        profile['explanation'] = self._explain_profile(profile, questionnaire_answers)
        return profile

    def _explain_profile(self, profile: dict, answers: dict) -> str:
        response = self.llm.messages.create(
            model="claude-3-5-sonnet-20241022",
            max_tokens=150,
            messages=[{
                "role": "user",
                "content": f"""Explain this investor risk profile in simple terms for the client.

Profile: {profile['risk_category']}, equity: {profile['equity_allocation']}%
Key factors from questionnaire: {answers}

2-3 sentences. No jargon. Explain why this allocation suits them."""
            }]
        )
        return response.content[0].text

Шаг 2: Оптимизация портфеля (Markowitz + ML-прогноз)

Вместо исторических ожиданий мы используем предсказания доходностей от Gradient Boosting и корректируем ковариационную матрицу через shrinkage. Оптимизация решает задачу максимизации Sharpe ratio с боксовыми ограничениями (2–40% на одну бумагу). Результат — эффективная граница, по которой мы выбираем портфель под профиль клиента.

class PortfolioOptimizer:
    """Оптимизация портфеля по Марковицу с ML-предсказанием доходностей"""

    def optimize(self, expected_returns: np.ndarray,
                  covariance_matrix: np.ndarray,
                  target_return: float = None,
                  max_volatility: float = None,
                  asset_names: list = None,
                  constraints: dict = None) -> dict:
        """Оптимизация Марковица"""
        n_assets = len(expected_returns)

        def portfolio_variance(weights):
            return weights @ covariance_matrix @ weights

        def portfolio_return(weights):
            return weights @ expected_returns

        def neg_sharpe(weights, risk_free_rate=0.05):
            ret = portfolio_return(weights)
            vol = np.sqrt(portfolio_variance(weights))
            return -(ret - risk_free_rate / 252) / vol

        # Ограничения
        scipy_constraints = [
            {'type': 'eq', 'fun': lambda w: np.sum(w) - 1}
        ]

        if target_return:
            scipy_constraints.append({
                'type': 'eq',
                'fun': lambda w: portfolio_return(w) - target_return
            })

        # Границы весов
        min_weight = constraints.get('min_weight', 0.02) if constraints else 0.02
        max_weight = constraints.get('max_weight', 0.40) if constraints else 0.40
        bounds = [(min_weight, max_weight)] * n_assets

        # Оптимизация
        result = minimize(
            neg_sharpe if not target_return else portfolio_variance,
            x0=np.ones(n_assets) / n_assets,
            method='SLSQP',
            bounds=bounds,
            constraints=scipy_constraints,
            options={'ftol': 1e-9, 'maxiter': 1000}
        )

        weights = result.x
        ret = portfolio_return(weights)
        vol = np.sqrt(portfolio_variance(weights))
        sharpe = (ret - 0.05/252) / vol * np.sqrt(252)

        return {
            'weights': {(asset_names[i] if asset_names else f'asset_{i}'): float(w)
                       for i, w in enumerate(weights)},
            'expected_annual_return': float(ret * 252),
            'annual_volatility': float(vol * np.sqrt(252)),
            'sharpe_ratio': float(sharpe)
        }

Шаг 3: Мониторинг и ребалансировка

Дрейф портфеля отслеживается в реальном времени. Если отклонение от целевого веса превышает 5%, запускается генерация ордеров: BUY для недооценённых бумаг, SELL для переоценённых. Все ордера проверяются на минимальный объём сделки, чтобы избежать дробных лотов.

class RebalancingEngine:
    """Автоматическая ребалансировка с учётом транзакционных издержек"""

    def check_rebalancing_needed(self, current_weights: dict,
                                   target_weights: dict,
                                   threshold: float = 0.05) -> bool:
        """Нужна ли ребалансировка"""
        for asset, target_w in target_weights.items():
            current_w = current_weights.get(asset, 0)
            if abs(current_w - target_w) > threshold:
                return True
        return False

    def generate_rebalancing_orders(self, portfolio_value: float,
                                     current_weights: dict,
                                     target_weights: dict,
                                     min_trade_size: float = 10) -> list[dict]:
        """Генерация ордеров ребалансировки"""
        orders = []
        for asset, target_w in target_weights.items():
            current_w = current_weights.get(asset, 0)
            delta_w = target_w - current_w
            trade_value = abs(delta_w * portfolio_value)

            if trade_value >= min_trade_size:
                orders.append({
                    'asset': asset,
                    'action': 'BUY' if delta_w > 0 else 'SELL',
                    'value': trade_value,
                    'weight_delta': delta_w
                })

        return orders

Что входит в работу?

Какие этапы разработки включает проект?

Для наглядности приведём план с примерными временными рамками:

Сроки и стоимость

Сроки зависят от сложности интеграций: MVP за 3–4 месяца, полноценная платформа — от 8 до 12 месяцев. Стоимость рассчитывается индивидуально — получите консультацию для оценки вашего проекта. Мы работаем с FinTech-стартапами и банками, имеем 10+ лет опыта в ML и 50+ реализованных проектов в области автоматизации инвестиций. Закажите разработку робо-адвайзера под ключ — адаптируем решение под вашу брокерскую инфраструктуру.

Типичные ошибки при внедрении робо-адвайзеров

• Использование только исторических данных без учёта режимных переключений (регуляторные изменения, кризисы). Мы добавляем stress-тесты по сценариям.
• Игнорирование минимальных сумм сделок — приводит к отклонениям портфеля. Наш engine блокирует мелкие ордера.
• Отсутствие понятного объяснения для клиента — нарушение требований ЦБ. LLM-генерация объяснений решает это.

Гарантируем — ваш робо-адвайзер будет соответствовать регуляторным стандартам и обеспечит доходность на 1.5–2.5% выше, чем наивная ребалансировка. Оценим ваш проект свяжитесь с нами для консультации.

Разработка рекомендательных систем: от 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.