Опубликовано: 26.09.2026 | Источник: TechCrunch

Платформа AI-разметки данных в дипломе: архитектура, метрики качества и экономика распределённой команды

Индийская Deccan AI привлекла $25 млн и делает ставку на одну простую вещь: обучение моделей упирается не в железо, а в качество размеченных данных. Компания держит пул экспертов внутри одной страны, чтобы управлять качеством в быстрорастущем, но фрагментированном рынке AI-тренировки. Для выпускника ИТ-направления это не новость из мира стартапов, а готовый каркас темы. Разметка данных — это распределённая система: очередь задач, роли, контроль качества, аудит, метрики согласованности, API для заказчиков и MLOps-контур вокруг. Ровно тот набор сущностей, который защищаемая ВКР обязана показать в проектной и исследовательской части.

Почему кейс Deccan AI тянет на полноценную тему

Формально в статье две строки: деньги и география. Фактически там спрятана архитектурная проблема. Когда исполнителей сотни и они разбросаны, возникает вопрос: как гарантировать, что два человека разметили одно и то же изображение или фрагмент текста одинаково? Ответ — инженерный, а не организационный: пересечения (overlap), контрольные задания, золотой стандарт, расчёт согласованности, автоматические триггеры на переразметку. Всё это описывается диаграммами, формализуется и измеряется. Появляется естественный мостик к ISO/IEC 25010 — функциональная полнота, точность, удобство использования и сопровождаемость становятся не абстракцией, а характеристиками вашей системы.

Второй слой — экономика. Заказчик платит за час работы эксперта, а получает — число корректно размеченных объектов. Разница между этими величинами и есть предмет расчёта в третьей главе.

Три темы ВКР, которые защищаются без натяжек

1. Проектирование платформы разметки данных с контролем качества на стороне исполнителя

• Актуальность: рынок AI-тренировки фрагментирован, крупные игроки концентрируют исполнителей в одном регионе ради управляемости — прямой отсыл к кейсу Deccan AI.
• Цель: разработать сервис распределения заданий и контроля качества разметки.
• Задачи: анализ существующих платформ; проектирование модели данных и очереди заданий; реализация механизма пересечений и расчёта согласованности; оценка производительности под нагрузкой.
• Структура: Глава 1 — обзор рынка и стандартов (ISO/IEC 25010, ГОСТ 34.602-89); Глава 2 — архитектура, схема БД, REST/gRPC-контракты; Глава 3 — нагрузочное тестирование и расчёт стоимости обработки одного задания.

2. Конвейер автоматической валидации разметки на базе Airflow и OpenTelemetry

• Актуальность: рост объёмов данных требует не ручных проверок, а наблюдаемого пайплайна с метриками и алертами.
• Цель: построить конвейер проверок, снижающий долю брака до порогового значения.
• Задачи: формализовать правила валидации; реализовать DAG-и; внедрить трассировку и метрики; сравнить время обнаружения дефекта до и после.
• Структура: Глава 1 — Data Quality и MLOps; Глава 2 — проектирование конвейера; Глава 3 — эксперимент и метрики MTTR.

3. Сравнительный анализ экономической эффективности in-house и краудсорсинговой разметки

• Актуальность: статья показывает, что модель с внутренним пулом экспертов выигрывает контрактом на $25 млн — значит, гипотезу можно проверить численно.
• Цель: построить модель совокупной стоимости владения для двух сценариев.
• Задачи: собрать исходные данные; построить модель TCO; учесть стоимость переделок; сформулировать условия применимости.
• Структура: Глава 1 — рынок и подходы; Глава 2 — модель и допущения; Глава 3 — сценарии, чувствительность, выводы.

Аналитическая глава: как превратить новость в обоснование стека

Первая глава у большинства студентов превращается в пересказ документации. Чтобы этого избежать, ведите сравнение по критериям, а не по «плюсам и минусам». Ниже — заготовка, которую можно адаптировать под свою тему: она показывает, что выбор инструмента у вас обоснован, а не взят из первого туториала.

Отдельная сущность, которую стоит вынести в первую главу, — стандарты оформления и требований. ГОСТ 34.602-89 задаёт состав технического задания на автоматизированную систему, ГОСТ 19.701-90 — правила выполнения схем алгоритмов и программ. Если в аналитическом разделе вы сошлётесь на них напрямую и покажете, какие пункты ТЗ вы закрываете своей архитектурой, работа сразу выглядит взрослее.

Проектная часть: схемы, которые реально ждут на защите

Здесь важно не количество диаграмм, а их связанность. Достаточно четырёх, но каждая должна вытекать из предыдущей.

• Контекстная диаграмма (уровень 0). Заказчик, платформа, внешняя система хранения, пул исполнителей. Показывает границы системы — прямое соответствие разделу «Назначение» в ТЗ.
• Компонентная схема. API-шлюз, сервис заданий, сервис валидации, хранилище артефактов, брокер сообщений, база метрик. Размещение в Kubernetes описывается уже здесь, а не в приложении.
• Диаграмма последовательности. Полный путь одного задания: выдача → разметка → пересечение → автоматическая проверка → арбитраж спорных случаев → фиксация результата.
• Схема данных. Сущности «задание», «исполнитель», «результат разметки», «эталон», «проверка», «аудит».

Если задача — согласованность двух разметок, приведите расчёт коэффициента согласованности и порог, после которого задание уходит в арбитраж. Ниже — минимальный фрагмент, который можно вставить в приложение к диплому как листинг:

def cohens_kappa(a, b, labels):
    n = len(a)
    po = sum(1 for x, y in zip(a, b) if x == y) / n
    pe = sum((a.count(l) / n) * (b.count(l) / n) for l in labels)
    return (po - pe) / (1 - pe) if pe != 1 else 1.0

# задание уходит в арбитраж, если согласованность ниже порога
if cohens_kappa(resp_a, resp_b, LABELS) < 0.75:
    route_to_arbitration(task_id)

Тестирование и метрики: чем измерять качество работы

Самый частый провал на защите — фраза «система работает корректно». Корректность нужно превратить в числа. Разделите метрики на три группы и не смешивайте их в одном графике.

Считайте RTO и RPO честно: остановите сервис, засеките время до возврата в рабочее состояние, зафиксируйте объём потерянных транзакций. Это десять минут эксперимента и половина убедительности третьей главы. Заодно появится материал для сравнения с заявленными требованиями из ТЗ — то самое соответствие «требование → метрика → результат».

Чему вы научитесь на такой теме

• Проектировать распределённые сервисы с очередями задач и чётким разделением ответственности.
• Формализовать качество данных: пороги, арбитраж, эталонные наборы, метрики согласованности.
• Обосновывать стек сравнением по критериям, а не по популярности инструмента.
• Снимать нагрузочные и отказоустойчивые характеристики и подавать их в виде таблицы «требование — метод проверки — результат».
• Оформлять ТЗ, схемы и пояснительные записки в соответствии с ГОСТ 34 и ГОСТ 19.

Частые вопросы студентов

Насколько сложно это реализовать, если у меня нет опыта в распределённых системах?

Для учебного прототипа достаточно трёх сервисов и одной очереди. Возьмите готовый брокер сообщений, разверните всё в Docker Compose — этого хватит для демонстрации архитектуры. Kubernetes нужен только если вы хотите защитить ещё и раздел про отказоустойчивость; в остальных случаях достаточно описать перспективу развёртывания в отдельном подразделе.

Обязательно ли писать код, или достаточно проекта?

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

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

Публичные датасеты для задач классификации и разметки текста, синтетически сгенерированные пары разметок с заданной долей ошибок, а также собственный небольшой набор, размеченный вручную в двух проходах. Последний вариант особенно удобен: вы сразу получаете эталон и можете посчитать метрики на нём.

Как оформлять диаграммы, чтобы их приняли?

Используйте нотации UML для поведения и C4 для структуры, а схемы алгоритмов оформляйте по ГОСТ 19.701-90. Каждая диаграмма должна иметь номер, название и хотя бы один абзац текста, объясняющий, что из неё следует. Диаграмма без интерпретации в тексте почти всегда воспринимается как украшение.

Источник: Mercor competitor Deccan AI raises $25M, sources experts from India (опубликовано 2026-03-26)