Поддомен статьи: 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. Разработка рекомендательной системы для подбора аудиотехники в сегменте «премиум».
Актуальность: статья показывает, что покупатель премиальных наушников выбирает не по цене, а по совокупности характеристик (шумоподавление, автономность, качество звука). Нужна модель, которая это ловит.
Цель: повысить точность подбора товаров относительно популярного бейзлайна (top sellers) минимум на 15% по NDCG@10.
Задачи: 1) собрать и очистить датасет отзывов и цен; 2) реализовать ALS и content-based фильтрацию; 3) сравнить ансамбль с бейзлайном; 4) обернуть в REST API и провести нагрузочное тестирование.
Структура: Гл.1 — анализ подходов к рекомендательным системам, обзор датасетов; Гл.2 — проектирование архитектуры (C4) и реализация ETL + модели; Гл.3 — офлайн-метрики, A/B-имитация, оценка по ISO/IEC 25010. -
Тема 2. Сервис мониторинга цен маркетплейсов с системой оповещений на основе Airflow.
Актуальность: распродажи вроде Amazon Spring Sale длятся дни, а цена меняется по часам. Ручной трекинг не масштабируется.
Цель: обеспечить задержку обнаружения падения цены не более 15 минут при 5000 отслеживаемых SKU.
Задачи: 1) спроектировать ETL-пайплайн (Airflow + PostgreSQL/ClickHouse); 2) реализовать идемпотентные парсеры с ретраями; 3) настроить алертинг и дедупликацию; 4) построить дашборд и нагрузочную модель.
Структура: Гл.1 — анализ источников и правовых ограничений парсинга; Гл.2 — архитектура пайплайна, схема данных; Гл.3 — тесты на отказоустойчивость, метрики свежести данных. -
Тема 3. Сравнительный анализ методов оценки качества рекомендаций в e-commerce (на материале премиальной электроники).
Актуальность: комиссии часто интереснее исследовательская работа, чем ещё один CRUD. Здесь ваша цель — методология.
Цель: показать, как выбор метрики (Precision@k vs MAP@k vs NDCG@k) меняет ранжирование моделей на одном и том же датасете.
Задачи: 1) построить бенчмарк из 4–5 моделей; 2) провести статистическую проверку значимости различий (bootstrap); 3) исследовать смещение popularity-bias; 4) сформулировать рекомендации для индустрии.
Структура: Гл.1 — обзор метрик и литературы; Гл.2 — экспериментальная установка; Гл.3 — результаты, обсуждение ограничений.
Как встроить материал в главы
Глава 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 для схем алгоритмов.
- Код в приложениях — с комментариями на русском, либо с аннотацией на английском, если так требует кафедра.
- Проверена уникальность текста и корректность цитирования внешних источников (включая статью-триггер).
- «Мы просто посчитали Accuracy». Для рекомендаций Accuracy почти бесполезна — класс несбалансирован, интересен только top-k. Переходите на Precision@k, MAP@k, NDCG@k и обосновывайте выбор k через бизнес-логику: сколько карточек реально просматривает пользователь. В кейсе со статьёй — это 3–5 позиций «лучшие варианты».
- «Спарсили Amazon без оговорок». Защита по парсингу крупных маркетплейсов без оговорок о robots.txt, rate limit и Terms of Service превращается в дискуссию о правовых рисках. Добавьте раздел «Ограничения и этика» — 300 знаков текста снимают 20 минут вопросов.
- «Архитектура = скриншот дипломного проекта». Картинка без легенды и без привязки к задачам не принимается. Стройте C4 по уровням и подписывайте внешние системы (внешний маркетплейс, платёжный провайдер, CDN).
Источник: Sony's latest headphones are the only ones I'd splurge on (and they're on sale) (опубликовано 2026-03-25)