24 марта 2026 года система анализа текстов «Думейт» объявила о запуске чат-бота в мессенджере Max. Логика простая: пользователь отправляет документ в диалог и получает отчёт о заимствованиях и о признаках машинной генерации текста. Для выпускника ИТ-направления это не просто новость из отраслевой ленты, а готовый каркас для дипломного проекта. Здесь есть публично зафиксированный кейс, типовая цепочка «мессенджер → вебхук → очередь сообщений → сервис анализа → отчёт», а также набор метрик, которые можно посчитать и защитить перед комиссией. Разберём, как превратить этот сюжет в инженерную работу, а не в пересказ пресс-релиза.
Актуальность. Аналитические сервисы уходят из веб-интерфейса в привычные точки входа — мессенджеры. Значит, появляется отдельный класс задач: интеграция внешнего аналитического движка с платформой обмена сообщениями, работа с файлами разных форматов и асинхронная доставка длинных отчётов.
Цель: спроектировать и реализовать бота, который принимает документ, запускает проверку на заимствования и на ИИ-генерацию и возвращает структурированный отчёт пользователю.
Задачи:
Структура: Глава 1 — анализ предметной области, обзор Bot API и аналогов; Глава 2 — проектирование архитектуры, схемы данных, алгоритм обработки очереди; Глава 3 — реализация, тестирование, расчёт трудозатрат и экономического эффекта внедрения.
Актуальность. Детекторы машинного текста перестали быть экзотикой: сервисы вроде «Думейт» встраивают их в массовый продукт. Но качество таких детекторов редко проверяют всерьёз — а это идеальная ниша для исследовательской части ВКР.
Цель: сравнить методы выявления сгенерированного текста по формальным метрикам на подготовленном наборе данных.
Задачи:
Структура: Глава 1 — обзор методов и метрик, анализ публикаций; Глава 2 — методика формирования датасета и признаки; Глава 3 — эксперименты, таблицы результатов, интерпретация ошибок.
Актуальность. Проверка объёмного документа занимает от секунд до нескольких минут. Если вебхук мессенджера держит соединение открытым, платформа отвалится по таймауту. Отсюда задача про очереди, ретраи и идемпотентность — ровно то, что проверяют на защите.
Цель: обеспечить обработку пиковой нагрузки без потери заданий и с предсказуемым временем ответа.
Задачи:
Структура: Глава 1 — теория надёжности и очередей; Глава 2 — архитектура, диаграммы последовательности; Глава 3 — сценарии отказов, нагрузочные эксперименты, выводы по SLO.
Первая глава диплома часто превращается в реферат. Чтобы этого избежать, привяжите обзор к конкретному решению из статьи: какие классы задач закрывает бот в мессенджере, а какие остаются за веб-сервисом.
| Метод | Принцип | Плюсы | Ограничения |
|---|---|---|---|
| Шинглы + MinHash | Сравнение множеств пересекающихся фрагментов по сигнатурам | Устойчив к вставкам и перестановкам, быстро работает на больших корпусах | Требует хранилища сигнатур, плохо ловит смысловой пересказ |
| SimHash | Хеш документа, близость по расстоянию Хэмминга | Компактное представление, быстрый поиск похожих | Чувствителен к порогу, слабее на коротких текстах |
| Векторные представления | Сравнение косинусной близости эмбеддингов | Ловит перефразирование | Дороже по вычислениям, нужна модель и её версионирование |
| Гибрид | Сигнатуры для точных совпадений + эмбеддинги для пересказа | Баланс качества и стоимости | Сложнее сопровождать, нужна калибровка порогов |
Не пишите «выбрали Python, потому что он удобный». Пишите так: «Python выбран из-за зрелых библиотек для извлечения текста и NLP; PostgreSQL — для транзакционного хранения пользователей и отчётов; Redis — для очереди и кеша результатов; Docker — для воспроизводимости окружения; CI/CD-пайплайн на базе GitLab CI — для автоматического прогона тестов при каждом коммите». Каждое утверждение — с альтернативой, которую вы отклонили.
Опишите путь запроса по шагам: мессенджер отправляет вебхук → сервис-приёмник валидирует подпись и кладёт задание в очередь → воркер скачивает файл, извлекает текст, разбивает на фрагменты → параллельно запускаются модуль заимствований и модуль детекции ИИ → результаты агрегируются в отчёт → бот отправляет ответ в диалог. Такая схема сразу даёт материал для диаграммы последовательности и диаграммы компонентов, оформленных по ГОСТ 19.701-90.
@app.post("/webhook/max")
async def handle_update(update: Update, queue: TaskQueue):
doc = update.message.document
if doc is None:
return {"status": "ignored"}
task_id = await queue.enqueue(
user_id=update.user_id,
file_id=doc.file_id,
idempotency_key=update.event_id,
)
return {"status": "accepted", "task_id": task_id}
Обратите внимание на idempotency_key: мессенджеры умеют повторять доставку одного и того же события, и без защиты вы получите дубли проверок. Это маленькая деталь, которая на защите звучит весомее целой главы теории.
Минимальный рабочий вариант: нормализация текста, разбиение на шинглы длиной 3–5 слов, вычисление сигнатур, поиск кандидатов в индексе, подсчёт доли совпавших фрагментов с исключением цитат и библиографии. Обязательно опишите порог срабатывания и то, как его калибровали — например, на вручную размеченной выборке из 200 работ.
Точность в отрыве от полноты бессмысленна. Показывайте матрицу ошибок и объясняйте, какой тип ошибки дороже: ложное обвинение студента в генерации или пропуск сгенерированного текста. Для учебного сервиса ложноположительные срабатывания критичнее — они ведут к апелляциям.
| Метрика | Что показывает | Целевой ориентир для ВКР |
|---|---|---|
| Precision | Доля верных срабатываний среди всех «подозрительных» | ≥ 0,90 |
| Recall | Доля найденных сгенерированных фрагментов | ≥ 0,75 |
| F1 | Баланс точности и полноты | ≥ 0,82 |
| ROC-AUC | Разделяющая способность при разных порогах | ≥ 0,90 |
| FPR | Доля ложных обвинений | ≤ 0,05 |
Здесь пригодятся SLO, RTO и RPO. SLO — время ответа: например, 95% отчётов выдаются быстрее 30 секунд для документа до 20 страниц. RTO — сколько сервис восстанавливается после падения воркера. RPO — сколько заданий допустимо потерять; при работе с очередью с подтверждениями — ноль. Сбор метрик описывайте через OpenTelemetry: трассировка запроса от вебхука до отправки отчёта, счётчики ошибок по типам, гистограмма времени обработки. Для требований к качеству программного продукта удобно опереться на ISO/IEC 25010 — там есть готовые характеристики: производительность, надёжность, удобство использования.
Три ошибки, которые чаще всего топят такие работы
Ядро — приём вебхуков и очередь — пишется за пару дней. Основное время уходит на извлечение текста из разных форматов, калибровку порогов и нагрузочные эксперименты. Для ВКР достаточно работающего прототипа на ограниченном наборе форматов, если границы применимости честно описаны в выводах.
Зависит от требований кафедры, но прототип почти всегда усиливает защиту. Даже минимальная реализация даёт реальные числа: время обработки, долю ошибок, потребление памяти. Без них третья глава превращается в рассуждения.
Три источника: открытые корпуса студенческих работ, тексты, сгенерированные несколькими моделями по единым промптам, и работы после ручной правки. Последняя категория самая ценная — она показывает, как детектор ведёт себя на «смешанных» текстах.
Единый нотации на всю работу: UML для взаимодействия компонентов, схемы алгоритмов по ГОСТ 19.701-90 для логики обработки. Все элементы на схеме должны быть подписаны и упомянуты в тексте — «висячие» блоки вызывают вопросы у рецензента.
Если тема уже выбрана, но непонятно, как свести её к измеримым результатам, — начните с бесплатной консультации: разберём структуру, подскажем, где взять данные и какие метрики считать. Средний объём проработки под ключ — около 120 часов: от постановки задачи до готовых расчётов и оформления. Поможем с любой темой, связанной с анализом текстов, ботами и сервисной архитектурой.
Что проверить перед сдачей
Источник: «Думейт» запустила сервис проверки студенческих работ на плагиат и ИИ в мессенджере Max (опубликовано 2026-03-24)
```