Поддомен статьи: AI/ML + Data Engineering (аналитика и рекомендации в e-commerce). Роль: Data/ML-инженер.

Рекомендательная система для маркетплейса в дипломе: от парсинга цен до метрик качества

Что в статье ZDNET действительно полезно для ВКР

Автор ZDNET называет Sony WH-1000XM6 единственными премиальными наушниками, которые стоит покупать, и напоминает: сейчас они на распродаже Amazon Spring Sale. Казалось бы, при чём тут диплом программиста? При том, что сценарий «пользователь ищет премиальный товар в ограниченном бюджете, а площадка должна предложить ему ровно то, что он купит» — это классическая задача рекомендательных систем и ценового мониторинга. Именно её мы разберём как кейс для ВКР. Не «обзор наушников», а полноценная инженерная постановка: собрать данные о ценах и отзывах, построить модель ранжирования, посчитать Precision@k и NDCG, обернуть это в API и защитить перед комиссией. Плюс работа автоматически получает актуальный прикладной контекст, который любят на защитах.

Вопрос исследовательской задачи: где здесь research, а где engineering

Вопрос 1. Где брать датасет, если нет доступа к данным Amazon?

Реальные продажи вам никто не отдаст. Рабочие варианты: Kaggle-датасеты Amazon Reviews 2023 (McAuley Lab), 20–30 тыс. карточек, спарсенных с открытых страниц маркетплейсов — если соблюдаете robots.txt и не публикуете персональные данные, или синтетика, сгенерированная редактором на 100–200 тыс. взаимодействий. На защите важно честно указать: «источник — полусинтетический датасет, ограничение исследования — отсутствие кликовых логов; в перспективе — интеграция с реальным логом событий». Комиссия это принимает, а вот попытку выдать синтетику за продовые данные — нет.

Вопрос 2. Требует ли вуз реального ML или достаточно «полки с фильтрами»?

По опыту защит 2023–2025: профильные кафедры ждут хотя бы одну обученную модель с обоснованным выбором метрики. Бакалавру достаточно коллаборативной фильтрации (ALS/implicit) + content-based (TF-IDF по описаниям) в ансамбле. Магистру — уже стоит добавить нейросетевой ранкер (двухбашенную архитектуру) и сравнение офлайн-метрик (MAP@k, NDCG@k) с офлайн-эффектом на бейзлайне.

Вопрос 3. Как считать эффективность, чтобы цифры что-то значили?

Группируйте метрики по ISO/IEC 25010: functional suitability — Precision@10, Recall@10; performance efficiency — p95 задержки рекомендации (цель ≤ 200 мс), пропускная способность API; reliability — доля 5xx за час нагрузки; maintainability — цикломатическая сложность SonarQube. Не смешивайте офлайн и онлайн метрики в одной таблице — разводите разделы «Офлайн-оценка» и «Нагрузочное тестирование».

Вопрос 4. Какие схемы обязательны по нормоконтролю?

Минимум: контекстная диаграмма C4 (уровень 1), диаграмма компонентов C4 (уровень 2), UML sequence для сценария «запрос рекомендаций», ER-диаграмма БД. Если строите как автоматизированную систему — по ГОСТ 34.601-90 оформляете этапы создания, а схемы алгоритмов по ГОСТ 19.701-90. Перечислять всё в тексте недостаточно — на каждую схему нужна ссылка и абзац интерпретации.

Три темы ВКР, которые вырастают из этого кейса

Как встроить материал в главы

Глава 1. Не «обзор литературы», а обзор источников данных

Первая глава валится у 70% студентов, потому что там пересказ Wikipedia. Сделайте иначе: возьмите статью ZDNET как пример пользовательского интента («хочу хорошие наушники, но не за фулл-прайс») и разложите его на признаки для модели: цена в момент показа, скидка относительно rolling median за 90 дней, рейтинг и число отзывов, брендовая принадлежность к премиум-кластеру. Это уже постановка задачи, а не реферат.

Глава 2. Архитектура и код

Опишите поток данных словами и в C4. Простой и честный вариант:

Парсеры (Playwright/Celery beat)
        ↓
Raw Landing (S3/MinIO, JSON)
        ↓
Airflow DAG: clean → normalize → load
        ↓
PostgreSQL (SKU, prices, reviews)
        ↓
Feature Store (Redis, features за 5 мин)
        ↓
ML-сервис на FastAPI (ALS + TF-IDF ensemble)
        ↓
API Gateway → клиент

Пример DAG для обновления цен — на нём удобно показать ретраи, SLA и идемпотентность:

from datetime import datetime, timedelta
from airflow import DAG
from airflow.operators.python import PythonOperator
from airflow.providers.postgres.hooks.postgres import PostgresHook

def fetch_and_upsert(**ctx):
    hook = PostgresHook(postgres_conn_id="dw")
    rows = fetch_prices(ctx["ds"])  # идемпотентный клиент
    hook.run(
        """
        INSERT INTO prices (sku_id, price, captured_at, source)
        VALUES %s
        ON CONFLICT (sku_id, captured_at) DO NOTHING
        """,
        parameters=(rows,),
    )

with DAG(
    dag_id="price_tracking",
    start_date=datetime(2026, 1, 1),
    schedule="*/15 * * * *",
    catchup=False,
    default_args={"retries": 3, "retry_delay": timedelta(minutes=2)},
) as dag:
    PythonOperator(task_id="upsert_prices", python_callable=fetch_and_upsert)

В разделе про модель обязательно приложите формулу метрики — комиссия задаёт по ней вопросы чаще, чем по архитектуре:

import numpy as np

def ndcg_at_k(ranked, relevance, k=10):
    """ranked: список item_id по убыванию скора; relevance: dict item_id -> gain"""
    dcg = sum(
        relevance.get(item, 0) / np.log2(i + 2)
        for i, item in enumerate(ranked[:k])
    )
    ideal = sorted(relevance.values(), reverse=True)[:k]
    idcg = sum(g / np.log2(i + 2) for i, g in enumerate(ideal))
    return dcg / idcg if idcg else 0.0

Глава 3. Тестирование и эффективность

Не ограничивайтесь «модель показала 0.42 NDCG@10». Разложите эффект на три слоя: алгоритмический (прирост метрики относительно top-sellers), инженерный (p95 латентности, стоимость инфраструктуры в месяц), продуктовый (гипотетический рост конверсии в офлайн-симуляции). Про OWASP API Security Top 10 упомяните в подразделе «безопасность»: авторизация запросов к рекомендациям, rate limiting, защита от IDOR при обращении к истории пользователя.

Чек-лист перед сдачей
  • Все задачи во введении дословно перекликаются с выводами по главам.
  • Каждая схема пронумерована, есть ссылка в тексте и абзац-интерпретация.
  • Датасет описан: источник, объём, ограничения, способ получения (этический блок — обязателен).
  • Метрики посчитаны на hold-out выборке, а не на train, и указаны гиперпараметры.
  • ТЗ и структура работы оформлены по ГОСТ 34 (если применимо) и ГОСТ 19.701-90 для схем алгоритмов.
  • Код в приложениях — с комментариями на русском, либо с аннотацией на английском, если так требует кафедра.
  • Проверена уникальность текста и корректность цитирования внешних источников (включая статью-триггер).
Три типичные ошибки на защите
  1. «Мы просто посчитали Accuracy». Для рекомендаций Accuracy почти бесполезна — класс несбалансирован, интересен только top-k. Переходите на Precision@k, MAP@k, NDCG@k и обосновывайте выбор k через бизнес-логику: сколько карточек реально просматривает пользователь. В кейсе со статьёй — это 3–5 позиций «лучшие варианты».
  2. «Спарсили Amazon без оговорок». Защита по парсингу крупных маркетплейсов без оговорок о robots.txt, rate limit и Terms of Service превращается в дискуссию о правовых рисках. Добавьте раздел «Ограничения и этика» — 300 знаков текста снимают 20 минут вопросов.
  3. «Архитектура = скриншот дипломного проекта». Картинка без легенды и без привязки к задачам не принимается. Стройте C4 по уровням и подписывайте внешние системы (внешний маркетплейс, платёжный провайдер, CDN).
Если тема ещё не сформулирована или кажется, что 120 часов на её раскрытие не хватит — можно начать с бесплатной консультации: эксперт разберёт ваш черновик, подскажет, где усилить исследовательскую часть, а где — инженерную. Оставить заявку на консультацию.

Материал подготовлен экспертами компании IT-Diplom. Мы помогаем студентам с 2010 года. Если вам нужна помощь в разработке темы или оформлении работы, наши специалисты готовы подсказать.

Последнее обновление: 2026-09-20

Источник: Sony's latest headphones are the only ones I'd splurge on (and they're on sale) (опубликовано 2026-03-25)