AI-система детекции сгенерированных текстов для учебных заведений

AI-система детекции сгенерированных текстов: где ломается проверка

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

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

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

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

Что даёт внедрение: скорость проверки и разбор спорных работ

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

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

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

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

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

Режимы работы: пакетная проверка, поток и встраивание в контур

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

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

Этапы внедрения: от аудита работ до передачи регламентов

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

1. Аудит работ. Разбираем архив: типы заданий, языки, следы перевода и правок. Выделяем классы текстов, где детекция ненадёжна, — их закрываем процедурно.
2. Пилот на выборке. Готовим размеченный набор — машинные, человеческие, смешанные, отредактированные — и прогоняем систему вслепую, без подсказок о происхождении текста.
3. Схема проверки. Определяем, где стоит детектор: при сдаче, при перепроверке, в апелляции. От места зависит формат ответа — вероятность, подсветка фрагментов или пояснение.
4. Настройка порогов. Подбираем границы «пропустить / на ручную проверку / вернуть» под допустимую долю ложных срабатываний в вашем профиле заданий.
5. Контроль качества. Следим за метриками на живом потоке: доля ручных разборов, расхождения с решениями преподавателей, поведение после смены версий.
6. Передача регламентов. Документируем пороги, порядок апелляции, действия при сбое и правила обновления, обучаем сотрудников на реальных примерах.

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

Что передаём на руки: модели, правила разметки, документация

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

• Модель и карта порогов — рабочая сборка плюс описание, как порог влияет на баланс ложных срабатываний и пропусков, и какие диапазоны подходят для коротких ответов, эссе и курсовых.
• Разметка данных — корпус с метками и протокол разметки: какие признаки эксперт считал доказательством генерации, как размечал смешанные работы, как разрешал расхождения между разметчиками.
• Правила классификации — формальные критерии классов, отдельная зона «требует ручной проверки» и трактовка пограничных значений, чтобы преподаватель не решал это интуитивно.
• Регламент для преподавателя — пошаговый сценарий при срабатывании: фиксация результата, разговор со студентом, точка, где подключается учебная часть.
• Политика хранения работ — сроки хранения текстов и результатов проверки, кто имеет доступ, как удаляется работа по запросу студента.
• Документация — схема потока данных, описание интеграции с учебной платформой, журнал решений по модели и причины каждого изменения порогов.
• Инструкция по дообучению — как добавить свои примеры, какие метрики смотреть после обновления и как откатить модель, если качество просело.

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

Кейс: точность разбора заявок в приёмной комиссии до и после

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

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

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

Что дал разбор по фрагментам

После: расхождение между экспертами сократилось до 8%, доля апелляций — втрое меньше, среднее время разбора одной работы упало до 4 минут. Отдельно проверили ложные срабатывания на текстах авторов с неродным языком — именно эта группа чаще всего попадала под подозрение; риск подтверждают и внешние разборы, включая Turnitin.

Главный класс ошибок, который удалось убрать, — обвинения абитуриентов с формальным или шаблонным стилем письма. Комиссия видит не ярлык «сгенерировано», а конкретные фрагменты-основания, и апелляция разбирается по ним, а не по общему впечатлению.

Детекция текста или проверка на заимствования: в чём разница

Это разные задачи, и решают их разными методами. Проверка на заимствования отвечает на вопрос «есть ли этот фрагмент в известном источнике», а детекция сгенерированного текста — «написан ли он моделью». Первая работает с базой источников, вторая — со свойствами самого текста.

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

Сгенерированный текст почти никогда не совпадает с источником дословно: модель строит новые формулировки, а не копирует корпус. Работа, перефразированная через генератор, получит низкий процент заимствований — при том, что собственного вклада в неё нет. Здесь проверка на заимствования молчит по построению, а не из-за ошибки в настройке порогов.

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

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

Технические сомнения: ложные срабатывания, языки, нагрузка

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

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

Где хранятся работы и кто их видит?

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

Как убедиться, что система не врёт, до включения в учебный процесс?

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

Обсудим задачу: какие работы проверяем и в каком объёме

В одном из вузов проверка держалась на ручном разборе: преподаватель открывал историю правок в документе и выносил вердикт сам. Мы разделили поток на два уровня — автоматическую разметку по фрагментам с вероятностью генерации и отдельную очередь для спорных случаев.

Доля работ, уходивших на ручной вердикт, сократилась с 40% до 6%, а ответ студенту стал приходить в тот же день вместо нескольких суток. Держится это не на «пороге чувствительности», а на разметке контура проверки под правила конкретного учебного заведения.

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

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

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