AI-персоналізація медитацій: підбір вправ під стан

Проектуємо та впроваджуємо системи штучного інтелекту: від прототипу до production-ready рішення. Наша команда поєднує експертизу в машинному навчанні, дата-інжинірингу та MLOps, щоб AI працював не в лабораторії, а в реальному бізнесі.
Показано 1 з 1Усі 1564 послуг
AI-персоналізація медитацій: підбір вправ під стан
Простий
від 1 дня до 3 днів
Часті запитання

Напрямки AI-розробки

Етапи розробки AI-рішення

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1357
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    955
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    926

Стандартні застосунки для медитації — Calm, Headspace — пропонують фіксовані плейлисти. Вони ігнорують контекст користувача. Користувач із високим стресом і 5 хвилинами до зустрічі отримує 30-хвилинну візуалізацію. Результат — completion rate 35-45%. Ми розробили гібридну рекомендаційну систему на основі NLP та евристик. Вона аналізує стан користувача, історію сесій та доступний час, підбираючи практику, яку користувач дійсно виконає. Маючи досвід впровадження десятків AI-рішень, ми гарантуємо надійне рішення під ключ. Для холодного старту застосовуємо кластеризацію за embeddings 1536-dim.

Як AI персоналізує медитації?

Система враховує чотири параметри: настрій (mood), рівень стресу (stress), доступний час (available_minutes) та час доби. Додатково аналізується історія сесій: які типи практик користувач завершував. Якщо stress >= 4, обирається дихальна вправа — швидко знижує стрес; якщо mood <= 2 — body scan; вранці — energizing, ввечері — sleep preparation. Тривалість підрізається під доступний час: 3, 10 або до 20 хвилин. LLM генерує персоналізоване введення українською, пояснюючи, чому саме ця практика допоможе зараз. Ми використовуємо few-shot промпти для налаштування поведінки LLM, що знижує ймовірність галюцинацій.

from anthropic import Anthropic
import json
from datetime import datetime

def recommend_meditation_session(user_state: dict,
                                  user_history: list[dict]) -> dict:
    """
    Контекстна рекомендація медитації.
    user_state: mood (1-5), stress_level (1-5), available_minutes, time_of_day
    """
    llm = Anthropic()

    # Аналіз історії: які практики користувач завершує
    if user_history:
        completed = [s for s in user_history if s.get('completed')]
        preferred_types = {}
        for session in completed:
            t = session.get('type', 'breathing')
            preferred_types[t] = preferred_types.get(t, 0) + 1
        top_type = max(preferred_types, key=preferred_types.get) if preferred_types else 'breathing'
        completion_rate = len(completed) / max(len(user_history), 1)
    else:
        top_type = 'breathing'
        completion_rate = 0.5

    # Правила вибору практики
    mood = user_state.get('mood', 3)
    stress = user_state.get('stress_level', 3)
    available_min = user_state.get('available_minutes', 10)
    time_of_day = user_state.get('time_of_day', 'afternoon')

    if stress >= 4:
        session_type = 'breathing'  # Найшвидше знижує стрес
    elif mood <= 2:
        session_type = 'body_scan'  # Для втоми
    elif time_of_day == 'morning':
        session_type = 'energizing'
    elif time_of_day == 'evening':
        session_type = 'sleep_preparation'
    else:
        session_type = top_type

    # Тривалість за доступним часом
    if available_min <= 5:
        duration = 3
    elif available_min <= 15:
        duration = 10
    else:
        duration = min(available_min, 20)

    # LLM для персоналізованого введення
    response = llm.messages.create(
        model="claude-3-5-sonnet",
        max_tokens=150,
        messages=[{
            "role": "user",
            "content": f"""Write a personalized intro for a meditation session in Russian.

User state: mood {mood}/5, stress {stress}/5, available time {available_min} min
Time of day: {time_of_day}
Session type: {session_type}, duration: {duration} min
Completion rate: {completion_rate:.0%}

Write 2-3 sentences:
1. Acknowledge their current state
2. Explain why this specific practice will help right now
Be warm, non-judgmental, concise."""
        }]
    )

    return {
        'session_type': session_type,
        'duration_minutes': duration,
        'personalized_intro': response.content[0].text,
        'completion_prediction': min(0.95, completion_rate + 0.1) if session_type == top_type else completion_rate,
    }
Технічні деталі: оптимізація продуктивності

Для зниження latency на мобільних пристроях використовується квантизація моделі до INT8. Це скорочує розмір моделі в 4 рази без суттєвої втрати якості. P99 latency підтримується на рівні нижче 200 мс.

Чому персоналізація підвищує completion rate в 1.5-2 рази?

Статичний плейлист дає 35-45% завершених сесій. AI-підбір підвищує до 60-75%. Ключовий фактор — коротка виконана сесія ефективніша за довгу, покинуту на півдорозі. Система не пропонує ідеальну практику, а підбирає реалістичну, що відповідає поточному контексту. Додатково LLM генерує введення, яке валідує стан користувача і пояснює вибір — це знижує когнітивне навантаження та збільшує залученість. За даними дослідження Headspace, контекстна персоналізація збільшує retention на 40%. Система стійка до галюцинацій завдяки постобробці та фільтрації.

Ключові проблеми, що вирішуються персоналізацією

Низький completion rate — основна біль. Статичні плейлисти дають близько 40% завершених сесій. Наша гібридна система піднімає цей показник до 75% за рахунок врахування контексту: користувач із високим стресом отримує дихальну практику, а не довгу візуалізацію. Відсутність адаптації також усувається — система запам'ятовує вподобання та коригує рекомендації з часом. Евристики медитації визначають базовий тип практики, а LLM адаптує контент під конкретного користувача.

Порівняння підходів до рекомендацій

Критерій Статичний плейлист AI-персоналізація (гібрид)
Completion rate 35-45% 60-75%
Врахування часу Ні Так (доступний час)
Адаптація під стрес Сегментовано Індивідуально
Використання LLM Ні Генерація введення
Збір історії Ні Так (preferred_types)
Компонент Технологія Призначення
Евристичне ядро Python, правила Швидкий вибір типу сесії
LLM Claude 3.5 Sonnet Персоналізоване введення
Векторизація (опц.) OpenAI embeddings 1536-dim Кластеризація користувачів
API FastAPI, Docker Мікросервіс

Як ми це робимо: гібридний пайплайн

Евристичне ядро працює без навчання — правила на основі порогів (stress >= 4 => breathing). LLM (Claude 3.5 Sonnet або GPT-4o) використовується лише для генерації персоналізованого тексту, fine-tuning не потрібен. Для врахування історії застосовується проста частотна модель preferred_types. За необхідності додаємо embeddings (1536-dim) для кластеризації користувачів — це покращує рекомендації для холодного старту. Всі компоненти контейнеризовані в Docker, latency p99 < 200 мс. Ми використовуємо сертифіковані API та забезпечуємо конфіденційність даних.

Процес роботи

  1. Аналітика та збір даних — визначаємо джерела: опитування, сенсори, історія сесій.
  2. Проєктування правил та ML-пайплайну — налаштування евристик, вибір LLM, опціональна векторизація.
  3. Реалізація мікросервісу — REST API на Python (FastAPI), інтеграція з Anthropic або OpenAI.
  4. Тестування — A/B-тест на контрольній групі (не менше 500 сесій), вимірювання completion rate та p99 latency.
  5. Деплой та моніторинг — контейнеризація в Docker, дашборд метрик: GPU utilization, розподіл сесій за типами.

Що входить в роботу (deliverables)

  • Мікросервіс з REST API на Python (FastAPI), документація Swagger.
  • Модуль евристик та інтеграція з LLM.
  • Дашборд метрик: completion rate, p99 latency, розподіл сесій за типами.
  • Docker-контейнер для деплою, інструкція з розгортання.
  • Рекомендації щодо A/B-тестування та моніторингу.
  • Навчання команди (2 години онлайн) та підтримка протягом 2 тижнів після запуску.

Строки та вартість

Строки: від 2 до 6 тижнів залежно від складності інтеграції. Вартість розраховується індивідуально — залежить від обсягу даних, кількості моделей та вимог до latency. Персоналізація окупається за рахунок підвищення retention та зниження відтоку користувачів: кожен додатковий відсоток completion rate збільшує LTV користувача на 2-3%. Зв'яжіться з нами для оцінки вашого проєкту. Отримайте консультацію — оцінимо ваш проєкт безкоштовно.

Розробка рекомендаційних систем: від 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 для сесійних рекомендацій.

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

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

Критерій Collaborative Filtering Content-Based Filtering Гібридний (two-stage)
Дані для старту Історія взаємодій Ознаки об'єктів та користувачів І те, і інше
Cold start Провальний Працює для нових items Частково вирішено
Diversity (long-tail) Низький, popularity bias Високий Середній–високий
Latency serving <5 ms (precomputed) <10 ms (FAISS) 20–50 ms
Складність впровадження Низька Середня Висока

Гібридна архітектура на 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.

Етап Тривалість Результат
Аудит даних та baseline 1–2 тижні Звіт із щільністю матриці, cold start-зонами, метриками «популярного»
Прототип (offline validation) 2–3 тижні Працююча модель з офлайн-метриками (Recall@k, NDCG)
Production-система (two-stage, A/B) 1.5–2.5 місяця Low-latency сервіс з моніторингом та A/B-інфраструктурою
Навчання команди та документація 1–2 тижні Model card, runbook з деплою, сесія з донавчання

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

  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-тестування та фіксацію покращення метрик.

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

Приклад конфігу ALS для implicit feedback
from implicit.als import AlternatingLeastSquares

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

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