Антиплагиат онлайн – бесплатная проверка текста на уникальность
Если вы много пишете или проверяете, если вам срочно нужно определить качество текста и наличие его копий в интернете, вам не обойтись без программы антиплагиат.
Хорошая программа Антиплагиат поможет избежать грамматических, стилистических ошибок и опечаток, сделать текст более структурированным, полезным и интересным. С ее помощью можно добиться самого главного – уникальности, ведь без нее поисковые механизмы не распознают текст и могут даже заблокировать сайт, на котором он расположен.
Наша программа Антиплагиат работает онлайн и совершенно бесплатно, причем без регистрации. Вам не придется устанавливать на свой компьютер специальные драйвера и программы: просто загрузите текст в поле на нашем сайте и нажмите кнопку проверки уникальности текста на плагиат. И уже через мгновение вы получите полный анализ материала любого объема.
Преимущества проверки текста на Антиплагиат
Наша программа онлайн-проверки на плагиат выполнит анализ даже большого текста совершенно бесплатно и в минимальные сроки.
Благодаря специальным алгоритмам программа проверяет уникальность текста и помогает исключить:
- дубликаты,
- некачественный рерайт,
- заимствования.
Если проверить в ней текст на уникальность онлайн, можно даже выявить обработку синонимайзерами и программами для повышения процента оригинальности.
А вот и другие преимущества программы:
- Работает онлайн (не придется скачивать и засорять компьютер).
- Уникальный алгоритм поиска совпадений.
- Не зависит от скорости интернета.
- Проверка текста совершенно бесплатно.
- Проверка на антиплагиат больших объемов текста онлайн.
- Работа с программой без регистрации.
Во время проверки программа подсвечивает неуникальные куски текста, благодаря чему вы можете повысить уникальность текста онлайн бесплатно.
fastfine.ru
Система поиска плагиата / Habr
Предисловие
Одно время мне везло на всякие странные работы. Например, я чуть было не устроился админом в синагогу. Остановила меня только предчувствие, что меня там как последнего гоя будут заставлять работать по субботам.
Формулировка ее была очень проста. Сочинители курсовых — удаленные работники, очень часто — арабы и негры, для которых английский язык был неродным, и ленивы они были ничуть не меньше самих студентов. Нередко они шли по пути наименьшего сопротивления и вместо написания оригинальной работы тупо передирали ее из Интернета, целиком или частями. Соответственно, надо было найти источник (или источники), сравнить, как-то определить процент сплагиаченности и передать собранные сведения для уличения нерадивых.
Дело несколько облегчалось языком курсовых — он был исключительно английским, без падежей и сложных флективных форм; и сильно усложнялось тем, что непонятно было, с какой стороны вообще за это дело браться.
В качестве языка реализации был выбран Перл, что оказалось очень удачным. Ни на каком статическом компилируемом языке с их ригидностью и тормознутостью запуска решить эту задачу вообще было невозможно. Переписать готовое решение можно, а придти к нему путем многочисленных проб — никак нельзя. Ну и плюс куча отличных обкатанных библиотек.
Тупики
Первоначально ковыряться в задаче поручили какому-то патлатому студенту. Тот долго не мудрствовал. Раз надо искать в Интернете, значит, понадобится поисковик. Запихаем туда весь текст, а Гугл сам найдет, откуда что взято. Потом прочитаем найденные источники и сравним их с кусками исходного текста.
Разумеется, с этим ничего не получилось.
Во-первых, если отправить в Гугл весь текст целиком, то искать он будет очень плохо. В конце концов, у них там хранятся индексы, в которых количество рядом стоящих слов неизбежно ограничено.
Во-вторых, очень быстро выяснилось, что Гугл совсем не любит, когда в нем много ищут с одного и того же адреса. До этого я думал, что фраза «Тебя что, в Гугле забанили?» — это просто шутка. Оказалось, ничего подобного. Гугл после определенного количества запросов действительно банит, выводя достаточно сложную каптчу.
Ну и сама идея разбора HTML не сильно удачна — поскольку программа может упасть в любой момент, когда в Гугле решат чуть поправить верстку страницы с результатами поиска.
Студент решил зашифроваться и лазить в поисковую машину через открытые прокси: находить в интернете список и ходить через них. На деле половина этих прокси вообще не работала, а остальная половина безбожно тормозила, так что ничем хорошим процесс не заканчивался.
Ну и в-третьих, поиск кусков текста с помощью посимвольного сравнения оказался нереально медленным и совершенно непрактичным. А вдобавок еще и бесполезным — поскольку у кенийцев вполне хватало хитрости не переписывать тексты дословно, а слегка менять формулировки там и сям.
Пришлось начать с чтения специализированной литературы. Поскольку задача оказалась маргинальной, ни в одном учебнике и ни в одной солидной книге она описана не была. Все, что я нашел, была куча научных статей по частным вопросам и одна обзорная диссертация какого-то чеха. Увы, она попалась мне слишком поздно — к тому времени я и так уже знал все описанные там методы.
Отвлекаясь от темы, не могу не заметить, что почти все научные статьи, печатаемые в компетентных журналах, а) труднодоступны и б) довольно бесполезны. Те сайты, где они хранятся, и на которые выдает первые ссылки поисковик, всегда платные и весьма кусачи — обычно чуть ли не десять долларов за публикацию. Впрочем, пошарившись получше, можно, как правило, отыскать ту же самую статью и в открытом доступе. Если не удалось и это, можно попробовать написать автору, который, как правило, не отказывает в любезности выслать копию (из чего я делаю вывод, что от сложившейся системы сами авторы мало что получают, а доходы идут кому-то другому).
Впрочем, от каждой конкретной статьи практической пользы обычно немного. В них, за редким исключением, нет информации, по которой можно сесть и тут же набросать алгоритм. Там бывают или абстрактные идеи без всяких указаний, как же их реализовать; или куча математических формул, пробившись через которые понимаешь, что то же самое можно было написать в двух строчках и человеческим языком; или результаты экспериментов, проведенных авторами, с неизменным комментарием: «ясно далеко не все, нужно продолжать дальше». Не знаю, то ли эти статьи пишутся для галочки или, вернее, для каких-то внутринаучных ритуалов, то ли жаба давит делиться реальными наработками, которые вполне успешно можно использовать в собственном стартапе. В любом случае, эрозия науки налицо.
Кстати сказать, самый большой и известный сайт для поиска плагиата называется Turnitin. Это практический монополист в этой области. Внутренняя его работа засекречена не хуже, чем военная база, — я не нашел ни одной статьи, даже коротенькой заметки, повествующей хоть в самом общем виде о том, какие алгоритмы там применяются. Сплошная загадка.
Впрочем, от лирики вернемся снова к тупикам, на этот раз уже к моим собственным.
Не оправдала себя идея с отпечатками документов (document fingerprinting). В теории выглядело неплохо — по каждому документу, выкачанному из Интернета, считается его отпечаток — какое-то длинное число, как-то отражающее содержимое. Предполагалось, что будет заведена база, в которой вместо самих документов будут храниться url и отпечатки, и тогда будет достаточно сравнить исходный текст с базой отпечатков, чтобы сразу найти подозреваемых. Это не работает — чем отпечатки короче, тем сравнение хуже, а когда они достигают уже половины длины источника, то хранить их становится бессмысленным. Плюс изменения, которые устраивают авторы, чтобы обмануть распознавание. Ну и плюс огромный объем интернета — хранение даже самых коротких отпечатков очень быстро становится обременительным из-за гигантского размера данных.
Разбор и нормализация
Этот этап поначалу кажется банальным и неинтересным — ну понятно, что на входе явно будет текст в формат MS Word, а отнюдь не текстовый файл; его надо разобрать, разбить на предложения и на слова. На самом деле тут кроется огромный источник улучшения качества проверки, который далеко опережает любые хитрые алгоритмы. Это как с распознаванием книжек — если оригинал криво отсканирован и заляпан чернилами, то никакие последующие ухищрения это уже не исправят.
Кстати сказать, и разбор, и нормализация требуются не только для исходного текста, но и для всех ссылок, найденных в Интернете, так что помимо качества тут требуется еще и скорость.
Итак, к нам попал документ в одном из распространенных форматов. Большинство из них разобрать легко — например, HTML отлично читается с помощью HTML::Parser, всякие PDF и PS можно обработать, вызвав внешнюю программу типа pstotext. Разбор документов OpenOffice — просто удовольствие, можно даже прикрутить XSLT, если вы наслаждаетесь извращениями. Общую картину портит только гадский Word — более ублюдочный формат текста найти невозможно: адски сложный в разборе и лишенный всякой структуры внутри. За подробностями отсылаю к своей предыдущей статье. Была бы моя воля, я бы его вообще никогда не разбирал, но он распространен гораздо больше всех остальных форматов, вместе взятых. То ли это закон Грешэма в действии, то ли происки мирового зла. Если Бог всеблаг, то почему все пишут в формате Ворда?
В процессе разбора, если попался нормальный формат, из текста можно узнать всякие полезные вещи: например, найти оглавление документа и исключить его из процесса сравнения (там все равно ничего полезного нет). То же самое можно проделать с таблицами (коротенькие строчечки в ячейках таблицы дают много ложных срабатываний). Можно вычислить заголовки глав, выкинуть картинки, пометить интернет-адреса. Для веб-страниц имеет смысл исключить боковые колонки и колонтитулы, если они отмечены в файле (html5 это позволяет).
Да, кстати, еще ведь могут быть архивы, которые надо распаковать и достать оттуда каждый файл. Главное, не спутать архив с каким-нибудь сложным запакованным форматом типа OOXML.
Получив просто текст, мы можем поработать над ним еще. Только на пользу пойдет выкидывание титульной страницы и служебной информации, которую университеты требуют в обязательном порядке («Работа студента такого-то», «проверил профессор Сякой Т.О.»). Заодно можно расправиться со списком литературы. Найти его не так-то просто, ибо названий у него не меньше дюжины («References»,«List of reference»,«Works Cited»,«Bibliography» и так далее). Впрочем, он может вообще быть никак не подписан. Его лучше всего из текста просто выкинуть, потому что список очень мешает распознаванию, создавая при этом немалую нагрузку.
Полученный текст надо нормализовать, то есть облагородить, придав ему унифицированную форму. Первым делом надо найти все кириллические и греческие буквы, по написанию похожие на соответствующие английские. Хитроумные авторы специально вставляют их в текст, чтобы обмануть проверку на плагиат. Но не тут-то было: подобный фокус — это стопроцентная улика и повод гнать такого автора в шею.
Потом все простонародные сокращенные формы типа can’t заменяются на полные.
Теперь надо поменять все высокохудожественные уникодовские символы на простые — кавычки елочкой, кавычки в виде перевернутых запятых, длинные и полудлинные тире, апострофы, троеточия а также лигатуры ff, ffi,st и всякое такое. Заменить два апострофа подряд на нормальные кавычки (почему-то такое попадается очень часто), а два тире — на одно. Все последовательности пробельных символов (а их тоже куча) заменить на один обычный пробел. Вышвырнуть после этого из текста, все что не укладывается в диапазон символов ASCII. И напоследок убрать все управляющие символы, кроме обычного перевода строки.
Вот теперь текст готов к сравнению.
Дальше разбиваем его на предложения. Это не так-то просто, как кажется с первого взгляда. В сфере обработки естественного языка вообще всё кажется легким только поначалу и со стороны. Предложения могут заканчиваться точкой, троеточием, восклицательным и вопросительным знаком или вообще никак не заканчиваться (в конце абзаца).
Плюс точки могут стоять после всяких сокращений, который совсем не являются концом предложения. Полный список занимает полстраницы — Dr. Mr. Mrs. Ms. Inc. vol. et.al. pp. и так далее, и тому подобное. И плюс интернет-ссылки: хорошо, когда в их начале стоит протокол, но есть он там далеко не всегда. Например, статья может вообще рассказывать про разные сетевые магазины и постоянно упоминать Amazon.com. Так что еще нужно знать все домены — десяток основных и двести штук доменов по странам.
И заодно терять точность, поскольку весь процесс теперь становится вероятностным. Каждая конкретная точка может быть, а может и не быть концом предложения.
Первоначальная версия разбиения текста на предложения была написана в лоб — с помощью регулярных выражений находились все неправильные точки, заменялись на другие символы, текст бился на предложения по оставшимся, потом символы точек возвращались назад.
Затем мне стало стыдно, что я не использую передовые методы, разработанные современной наукой, так что я начал изучать другие варианты. Нашел фрагмент на Яве, разобрал за пару геологических эпох (ох и скучный же, монотонный и многословный язык). Нашел питоновский NLTK. Но больше всего мне понравилась работа некоего Дэна Гиллика (Dan Gillick, «Improved Sentence Boundary Detection»), в которой он хвастался, что его метод наголову превосходит все остальные. Метод строился на байесовских вероятностях и требовал предварительного обучения. На тех текстах, по которым я его натаскивал, он был превосходен, а на остальных… Ну не то, чтобы очень плох, но и не намного лучше той самой стыдной версии со списком аббревиатур. К ней я в конце концов и вернулся.
Поиск в Интернете
Итак, теперь мы имеем текст и надо заставить Гугл поработать за нас, поискать куски, разбросанные по всему Интернету. Разумеется, обычным поиском пользоваться нельзя, а как надо? Конечно, же с помощью Google API. Вcего-то делов. Условия там куда либеральнее, удобный и стабильный интерфейс для программ, никаких разборов HTML. Количество запросов в сутки хоть и ограничено, но на деле Гугл его не проверял. Если не наглеть, конечно, посылая запросы миллионами.
- Разбиваем текст на слова
- Выкидываем так называемые стоп-слова (служебные, попадающиеся чаще всего — a, on и так далее. Я пользовался списком, взятым из mysql)
- Формируем запросы из восьми слов с перекрытием (то есть, первый запрос — слова 1-8, второй 2-9 и так далее. Можно даже с перекрытием в два слова, это экономит запросы, но немного ухудшает качество)
- Если текст большой (>40kb), то можно выкинуть каждый третий запрос, а если очень большой (>200 kb), то даже каждый второй. Это вредит поиску, но не так уж сильно, очевидно, потому что плагиаторы обычно прут целыми абзацами, а не отдельными фразами
- Дальше посылаем все запросы на Гугл, даже одновременно.
- И, наконец, получаем ответы, разбираем, делаем общий список и выкидываем из него дубликаты. Еще можно отсортировать список полученных адресов по количеству пришедших дубликатов и отрезать последние, считая их не показательными и на что особо не влияющими. К сожалению, тут мы встречаемся с так называемым распределением Ципфа, которое при поиске плагиата глядит из каждого угла. Это такая экспонента вверх ногами с очень длинным и унылым хвостом, тянущимся в бесконечность. Полностью хвост обработать невозможно, а где резать — непонятно. Где бы ты ни отчекрыжил, качество ухудшится. Вот и со списком адресов так. Поэтому я резал его, исходя из эмпирической формулы, зависящей от длины текста. Это, во всяком случае, гарантировало какое-то стабильное время обработки как функцию числа букв
Алгоритм отлично работал, пока Гугл не спохватился и не прикрыл лафу. API остался, даже улучшился, но фирма стала хотеть за него деньги, и довольно немаленькие — 4 доллара за 1000 запросов. Пришлось смотреть альтернативы, коих было ровно две — Бинг и Яху. Бинг был бесплатным, но на этом его достоинства и заканчивались. Искал он заметно хуже Гугла. Может, последний — и новая корпорация Зла, но их поисковик по-прежнему лучший в мире. Впрочем, Бинг искал даже хуже самого себя — через API он находил в полтора раза меньше ссылок, чем из пользовательского интерфейса. Еще он имел отвратительную привычку часть запросов заканчивать с ошибкой и их приходилось повторять заново. Очевидно, таким образом в Майкрософте регулировали поток обращений. Кроме того, количество слов в строке поиска пришлось уменьшить до пяти, стоп-слова оставлять, перекрытие делать только в одно слово.
Яху находился где-то посередине между Гуглом и Бингом — и по цене, и по качеству поиска.
В процессе возникла еще одна идейка. Начальник отдела обнаружил проект, который каждые сутки собирал содержимое всего Интернета и складывал где-то на Амазоне. Нам оставалось только взять оттуда данные и проиндексировать в своей полнотекстовой базе, а потом в ней искать что надо. Ну фактически написать свой собственный Гугл, только без паука. Это было, как вы догадываетесь, совершенно нереально.
Поиск в локальной базе
Одной из сильных сторон Turnitin служит его популярность. Туда шлют множество работ: студенты — свои, преподаватели — студенческие, и их база поиска всё время увеличивается. В результате они могут находить краденое не только из интернета, но и из прошлогодней курсовой.
Мы пошли по тому же пути и сделали еще локальную базу — с готовыми заказами, а также с материалами, которые пользователи прикладывали к своим заявкам («Вот статья, по теме которой надо написать эссе»). Писатели, как выяснилось, очень любят переписывать свои же предыдущие работы.
Все это добро лежало в полнотекстовой базе KinoSearch (сейчас переименован в Люси). Индексатор работал на отдельной машине. Кинопоиск показал себя хорошо — хотя счет документам шел на сотни тысяч, искал быстро и тщательно. Единственный недостаток — при добавлении полей в индекс или смене версии библиотеки приходилось переиндексировать всё заново, что длилось несколько недель.
Сравнение
Ну теперь самое ядреное — без которого все остальное никому не нужно. Проверок нам нужно две — сначала сравнить два текста и определить, что в одном есть куски из другого. Если таких кусков нет, то дальше можно не продолжать и сэкономить вычислительные мощности. А если есть, тогда в дело вступает более сложный и тяжелый алгоритм, который ищет похожие предложения.
Первоначально для сравнения документов использовался алгоритм шинглов — кусков нормализованного текста с перекрытиями. По каждому куску считается некая контрольная сумма, которая потом используется для сравнения. Алгоритм был реализован и даже работал в первой версии, но оказался хуже алгоритма поиска в векторных пространствах. Впрочем, сама идея шинглов неожиданно пригодилась при поиске, но об этом я уже писал.
Итак, считаем некий коэффициент совпадения между документами. Алгоритм будет тот же, что и в поисковых машинах. Я изложу его по-простому, по-колхозному, а научное описание можно найти в научной же книжке (Маннинг К., Рагхаван П., Шютце Х. Введение в информационный поиск. — Вильямс, 2011). Надеюсь ничего не перепутать, а это вполне возможно — тут самая сложная часть системы, да еще и постоянно менявшаяся.
Итак, берем все слова из обоих статей, выделяем основу слова, выкидываем дубли и строим гигантскую матрицу. В колонках у нее будут те самые основы, а строк всего две — первый текст и второй текст. На пересечении ставим цифру — сколько раз конкретное слово встретилось в данном тексте.
Модель достаточно простая, называется она «мешком слов», потому что никак не учитывает порядок слов в тексте. Но для нас она — самое то, потому что плагиаторы при переделке текста очень часто меняют слова местами, переформулируя списываемое.
Выделение основ слова на лингвистическом жаргоне называется стеммингом. Я проводил его с помощью библиотеки Snowball — быстро и никаких проблем. Стемминг нужен для улучшения распознания плагиата — потому что ушлые авторы не просто переписывают чужой текст, а косметически его меняют, нередко превращая одну часть речи в другую.
Итак, мы получили некоторую матрицу из основ, которая описывает огромное многовекторное пространство. Теперь мы считаем, что наши тексты — это два вектора в этом пространстве, и считаем косинус угла между ними (через скалярное произведение). Это и будет мера сходства между текстами.
Просто, изящно и в большинстве случаев верно. Плохо работает только, если один текст намного больше другого.
Опытным путем было найдено, что тексты с коэффициентом сходства <0.4 можно не рассматривать. Впрочем, потом, после жалоб службы поддержки о не найденных паре-тройки сплагиаченных предложений, порог пришлось понизить до 0.2, что сделало его достаточно бесполезным (и тут проклятый Ципф).
Ну и пару слов о реализации. Поскольку сравнивать все время приходится один и тот же текст, то есть смысл заранее получить список его основ и количество их вхождений. Таким образом, четверть матрицы уже будет готова.
Для перемножения векторов я сначала использовал PDL (а что еще?), но потом, в погоне за скоростью, заметил, что вектора получаются жутко разрежённые, и написал собственную реализацию на базе перловских хэшей.
Теперь нам нужно найти коэффициент сходства между предложениями. Тут есть два варианта и оба представляют собой вариации на все ту же тему векторного пространства.
Можно поступить совсем просто — взять слова из обоих предложений, составить векторное пространство из них и посчитать угол. Единственное — не нужно даже пытаться учитывать количество вхождений каждого слова — все равно слова в одном предложении повторяются очень редко.
Но можно сделать и хитрее — применить классический алгоритм tf/idf из книжки, только вместо коллекции документов у нас будет коллекция предложений из обоих текстов, а вместо документов — соответственно, предложения. Берем общее векторное пространство для обоих текстов, (уже полученное, когда мы вычисляли сходство между двумя текстами), строим векторы, в векторах заменяем количество вхождений на ln(вхождения/к-во предложений). Тогда результат будет получше — не радикально, но заметно.
Если порог сходства между двумя предложениями превышает определенную величину, то записываем найденные предложения в базу, чтобы потом тыкать сходством плагиаторов.
И еще — если в предложении всего одно слово, то мы его даже ни с чем не сравниваем — бесполезно, алгоритм на таких огрызках не работает.
Если коэффициент сходства больше 0.6 — тут к гадалке не ходи, это перефразированная копия. Если меньше 0.4 — сходство случайное или вообще его нет. А вот в промежутке образуется серая зона — это может быть и плагиат, и просто совпадение, когда на взгляд человека в текстах нет ничего общего.
Тогда в игру вступает еще один алгоритм, который я почерпнул из хорошей статьи (Yuhua Li, Zuhair Bandar, David McLean and James O’Shea. «A Method for Measuring Sentence Similarity and its Application to Conversational Agents»). Тут уже в дело идет тяжелая артиллерия — лингвистические признаки. Алгоритм требует учесть неправильные формы спряжения, отношения между словами вроде синонимии или гиперонимии, а также редкость слова. Для всего этого добра требуется соответствующая информация в машинно-читаемом виде. К счастью, добрые люди из Принстонского университета давно уже занимаются специальной лексической базой для английского языка, называющейся Wordnet. На CPAN есть и готовый модуль для чтения. Единственное, что я сделал, — переложил информацию из текстовых файлов, в которых она хранится в Принстоне, в таблицы MySQL, ну и соответственно переписал модуль. Чтение из кучи текстовых файлов ни удобством, ни скоростью не отличается, а хранение ссылок в виде смещений в файле не назовешь особенно элегантным.
Вторая версия
Хм… Вторая. А где же первая? Ну про первую рассказывать нечего. Она брала текст и последовательно выполняла все шаги алгоритма — нормализовала, искала, сравнивала и выдавала результат. Соответственно, ничего параллельно делать не могла и была медленной.
Поскольку основное время работы уходит на получение ссылок и стягивание информации из Интернета, то доступ к сети — первый кандидат на оптимизацию. Последовательный доступ был заменен на параллельное скачивание (LWP на асинхронный Curl). Скорость работы, разумеется, выросла фантастически. Радость не смогли испортить даже глюки в модуле, когда он получал 100 запросов, выполнял 99 и неопределенно долго висел на последнем.
Общая архитектура новой системы была сочинена по образцу ОС. Есть управляющий модуль, который запускает дочерние процессы, выделяя им по «кванту» времени (5 минут). За это время процесс должен прочитать из базы, на чем там остановились прошлый раз, выполнить следующее действие, записать в базу информацию по продолжению и завершиться. За 5 минут можно сделать любую операцию, кроме скачивания и сравнения ссылок, поэтому это действие разбивалось на части — 100 или 200 ссылок за раз. Через пять минут диспетчер прервет исполнение по-любому. Не успел? Попробуешь в следующий раз.
Впрочем, сам рабочий процесс тоже должен следить по таймеру за своим выполнением, потому что всегда есть риск нарваться на какой-нибудь сайт, который подвесит всё (например, на одном таком сайте перечислялись 100000 слов английского языка — и больше ничего там не было. Понятно, что описанные выше алгоритмы будут искать сходство трое суток и, может быть, даже когда-нибудь найдут).
Количество рабочих процессов можно было менять, в теории — даже динамически. На практике три процесса были оптимальны.
Ну, ясно, что еще была база данных MySQL, в которой хранятся тексты для обработки и промежуточные данные, а заодно и окончательные результаты. И веб-интерфейс, на котором пользователи могли посмотреть, что там в данный момент обрабатывается, и на какой оно стадии.
Задачам определялся приоритет, чтобы более важные выполнялись быстрее. Приоритет считался как некоторая функция от размера файла (чем больше, тем медленнее он обрабатывается) и срока сдачи работы (чем он ближе, тем быстрее нужны результаты). Диспетчер выбирал следующую задачу по самому большому приоритету, но с некоторой случайной поправкой — иначе низкоприоритетные задачи вообще не дождались бы своей очереди, пока есть более высокоприоритетные.
Третья версия
Третья версия была продуктом эволюционного развития с точки зрения алгоритмов обработки, и революцией в архитектуре. Помнится, торчал я как-то на холоде, перед неудачным свиданием, в ожидании Годо, и вспоминал читанный недавно рассказ о сервисах Амазона. И файлы они хранят, и машины виртуальные делают, и даже есть у них всякие непонятные службы из трех букв. Тут-то меня и осенило. Вспомнил я гигантскую креветку, виденную как-то в севастопольском аквариуме. Стоит она посреди камней, машет лапками и фильтрует воду. Несет течение к ней всякие вкусные кусочки, а она их отбирает, воду выплевывает дальше. А если поставить много таких креветок в ряд, так они же все там профильтруют за двадцать минут. А если еще эти ракообразные и разного вида будут, вылавливать каждое своё, так вообще — какие перспективы открываются.
Переводя с образного языка на технический. У Амазона есть служба очередей SQS — такие непрерывные конвейеры, по которым идут данные. Делаем несколько программ, которые выполняют только одно действие — никаких переключений контекстов, порождений дочерних процессов и прочих накладных расходов. «Кран с утра до вечера наполняет водой одни и те же ведра. Газовая Плита подогревает одни и те же кастрюли, чайники и сковородки».
Реализация оказалась простой и красивой. Каждый описанный выше шаг алгоритма — отдельная программа. Под каждую есть собственная очередь. В очередях ходят сообщения XML, где написано, что и как надо сделать. Есть еще одна очередь управления и отдельная программа-диспетчер, которая следит за порядком, обновляет данные о ходе работ, уведомляет пользователя о случившихся проблемах. Отдельные программы могут слать ответ диспетчеру, а могут напрямую и в следующую очередь — как удобно. Если произошла ошибка — то отсылают сообщение об этому диспетчеру, а он уж разбирается.
Автоматически получается исправление ошибок. Если программа не справилась с заданием и, допустим, упала, то она будет перезапущена, а невыполненная задача остается в очереди и всплывет через какое-то время вновь. Ничего не потерялось.
Единственная сложность с Амазоном — служба очередей гарантирует, что каждое сообщение будет доставлено минимум один раз. То есть, доставлено оно по-любому будет, но не факт, что однажды. К этому надо быть готовым и писать процессы так, чтобы они подобающим образом реагировали на дубли — или не обрабатывали их (что не очень удобно, потому что надо вести какой-то учет), или же обрабатывали идемпотентно.
Скачанные из Интернета файлы, естественно, в сообщениях не пересылались — и неудобно, и в SQS есть ограничение на размер. Вместо этого они складывались на S3, а в сообщениях отсылалась только ссылка. Диспетчер после завершения задачи все эти временные хранилища вычищал.
Промежуточные данные (например, сколько ссылок нам надо прочитать и сколько уже сделано) хранились в Amazon Simple Data Storage — простой, но распределенной базе данных. У SDS тоже были ограничения, которые стоило учитывать. Например, она не гарантировала мгновенного обновления.
Ну и, наконец, готовые результаты — тексты с указанием плагиата, я стал складывать не в базу MySQL, а в CouchDB. Все равно в реляционной базе они хранились нереляционно — в текстовых полях в формате Data::Dumper (это перловский аналог JSONа). CouchDB был всем хорош, как царица Савская, но имел один недостаток, зато фатальный. К его базе невозможно обратиться с произвольным запросом — для любого запроса должны быть заранее построены индексы, то есть их надо предугадать заранее. Если хрустального шара нет, то надо начинать процесс индексирования — а для большой базы он длится несколько часов (!) и при этом все остальные запросы не выполняются. Сейчас бы я использовал MongoDB — там есть фоновое индексирование.
У получившейся схемы было огромное преимущество перед старой — она естественно масштабировалась. Действительно, никаких локальных данных у нее нет, все распределено (кроме базы результатов), все экземпляры рабочих процессов совершенно однотипны. Их можно сгруппировать по тяжести — на одной машине запускать все легкие, требующие мало ресурсов, а тормозным вроде процесса сравнения текстов выделить отдельный виртуальный сервер. Мало? Не тянет? Можно еще один. Не справляется еще какой-нибудь процесс? Вынесем и его на отдельную машину. В принципе, это даже можно делать автоматически — видим, что в одной из очередей скопилось слишком много необработанных сообщений, поднимаем еще один сервер EC2.
Впрочем, суровая тетка Жизнь, как водится, внесла в эту идиллию свои коррективы. С технической стороны архитектура была идеальна, а вот с экономической выяснилось, что использование SDS (да и S3) оказывается совсем невыгодным. Обходится очень уж дорого, особенно база.
Пришлось спешно выносить промежуточные данные в старый добрый MySQL, а скачанные документы складывать на жестком диске, расшаренном по NFS. Ну и заодно забыть о беспроблемном масштабировании.
Нереализованные планы
Изучая обработку естественного языка, в частности, по исчерпывающей книге Мэннинга, я никак не мог отделаться от мысли, что все описанные там методы — просто уловки ad hoc, фокусы под конкретную задачу, совершенно не обобщаемые. Лем еще в 2001 году уедал информатику, так и не придумавшую за сорок лет искусственный интеллект, хотя трещали на эту тему много. Тогда же он мрачно предсказывал, что положение в обозримом будущем не изменится. Машина как не понимала смысла, так понимать и не будет. Философ оказался прав.
Точно такой же уловкой был и поиск плагиата. Ну породить ИИ и ждать человеческого осмысления текста я не надеялся, не так уж я наивен, но долго бродила в голове мысль приделать синтаксический анализ, чтобы хотя бы распознавать одинаковые по смыслу предложения, только стоящие в разных залогах (активном и страдательном). Однако все парсеры естественного языка, которые я находил, были крайне сложными, вероятностными, давали результаты в непонятной форме и требовали огромных вычислительных ресурсов. В общем, думаю, что на нынешней стадии развития наук это нереально.
Человеческий фактор
Система писалась так, чтобы работать в полностью автоматическом режиме, так что тут люди ничем подкузьмить не могли. Кроме того, со мной в паре трудился очень хороший сисадмин, благодаря которому все сервера настроены были отлично, а простои разного рода сводились к минимуму. Но оставались ведь еще и пользователи — служба поддержки. Ну и начальство, конечно же.
И те, и другие долгое время были убеждены, что поиском плагиата занимается не компьютер, а маленький человечек (или даже целая толпа), который сидит внутри компьютера. Он почти как настоящий, в частности, отлично понимает все, о чем пишется в курсовых на любую тему, а плагиат находит потому, что держит в голове все содержимое Интернета. Впрочем, когда эти человечки лажали, спрашивали, вопреки всякой логике, почему-то не с них, а с меня. Одно слово — филологи.
Мне стоило больших трудов объяснить, что плагиат ищет все-таки компьютер, который совершенно не понимает того, что делает. Где-то через год до начальства это дошло, до остальных, кажется, не до конца.
Была у саппорта еще и другая мода — ввести несколько предложений в Гугл и радостно мне сообщать, что Гугл плагиат нашел, а моя система — нет. Ну что я мог на это сказать? Объяснять про распределение Ципфа, рассказать, что ради скорости и уменьшения объема памяти пришлось идти на компромиссы, а каждый такой компромисс означал ухудшение качества? Безнадежно. К счастью, в большинстве таких случаев оказывалось, что Гугл нашел материал на каком-нибудь платном сайте, к которому доступу у системы просто не было.
Еще была фишка — доложить, что Turnitin обнаружил плагиат, а наша система не обнаружила. И тут нереально было объяснить, что Turnitin, скорее всего, пишет целая команда квалифицированных специалистов с дипломами в соответствующей области, а сам сайт имеет интимные отношения с каким-то крутым поисковиком. Опять-таки, к счастью, большинство не обнаруженных случаев плагиата были с платных сайтов или из других студенческих работ, в общем, для нас никак недоступны.
Несколько месяцев я пытался удовлетворить требование директора о фиксированном времени обработки — каждая работа не должна проверяться более часа. У меня это никак не получалось, я не спал ночами, пока однажды мне не подсказали, что, в сущности, от меня хотят изобрести вечный двигатель — такой, мощность которого будет расти при увеличении нагрузки. В жизни таких не бывает, в мире программ — тоже. Когда требование было переформулировано — каждая работа не более определенного объема (50 страниц) должна искаться не более часа, если в это время в очереди нет огромных диссертаций — дело пошло на лад. Условия были жесткими, но хотя бы в принципе реализуемыми.
Временами радовала служба поддержки. Объяснить их логику я затрудняюсь, но периодически, при сильной загрузке очереди проверки они… запихивали в нее дополнительные копии работ. Ну то есть, если в пробке стоит сто автомобилей, то надо на дорогу пригнать еще сто, и тогда дело пойдет на лад. Объяснить им ошибку я так и не смог, и такие дела были запрещены чисто административно.
Напутствие комментаторам
Мой печальный опыт показывает, что на Хабре есть некоторое количество малолеток, по непонятным причинам считающим, что они сразу от рождения превосходно разбираются во всех отраслях знания, придуманных человечеством. Прямо по Чехову — «она у меня эмансипе, все у нее дураки, одна она умная». Если вы принадлежите к таким товарищам и решите написать мне, что я идиот, ничего не разумею, не понимаю простых вещей и т.п., то прошу помнить, что разработанная мной система эксплуатировалась в хвост и в гриву два года, 24 часа в сутки, почти без простоев, и сэкономила заказчику несколько мешков денег. Поэтому при сочинении комментариев описанного выше типа прошу сразу указывать аналогичные характеристики системы, разработанной вами. Ну чтобы ваша гениальность была заметна сразу, без наводящих вопросов.
habr.com
как найти плагиат с английского языка в русских научных статьях / «Антиплагиат» corporate blog / Habr
В нашей первой статье в корпоративном блоге компании Антиплагиат на Хабре я решил рассказать о том, как работает алгоритм поиска переводных заимствований. Несколько лет назад возникла идея сделать инструмент для обнаружения в русскоязычных текстах переведенного и заимствованного текста из оригинала на английском языке. При этом важно, чтобы этот инструмент мог работать с базой источников в миллиарды текстов и выдерживать обычную пиковую нагрузку Антиплагиата (200-300 текстов в минуту).«
В течение 12 лет своей работы сервис Антиплагиат обнаруживал заимствования в рамках одного языка. То есть, если пользователь загружал на проверку текст на русском, то мы искали в русскоязычных источниках, если на английском, то в англоязычных и т. д. В этой статье я расскажу об алгоритме, разработанном нами для обнаружения переводного плагиата, и о том, какие случаи переводного плагиата удалось найти, опробовав это решение на базе русскоязычных научных статей.
Я хочу расставить все точки над «i»: в статье речь пойдёт только о тех проявлениях плагиата, которые связаны с использованием чужого текста. Всё, что связано с воровством чужих изобретений, идей, мыслей, останется за рамками статьи. В тех случаях, когда мы не знаем, насколько правомерным, корректным или этичным было такое использование, мы будем говорить «заимствование текста» или «текстовое заимствование». Слово «плагиат» мы используем только тогда, когда попытка выдать чужой текст за свой очевидна и не подлежит сомнению.
Над этой статьей мы работали вместе с Rita_Kuznetsova и Oleg_Bakhteev. Мы решили, что образы Пиноккио и Буратино служат прекрасной иллюстрацией к проблеме поиска плагиата из иностранных источников. Сразу оговорюсь, что мы ни в коем случае не обвиняем А.Н.Толстого в плагиате идей Карло Коллоди.
Для начала я коротко расскажу, как работает «обычный Антиплагиат». Мы построили своё решение на основе т.н. «алгоритма шинглов», который позволяет быстро находить заимствования в очень больших коллекциях документов. Этот алгоритм основан на разбиении текста документа на небольшие перекрывающиеся последовательности слов определенной длины – шинглы. Обычно используется шинглы длиной от 4 до 6 слов. Для каждого шингла рассчитывается значение хэш-функции. Поисковый индекс формируется как отсортированный список значений хэш-функции с указанием идентификаторов документов, в которых встретились соответствующие шинглы.
Проверяемый документ также разбивается на шинглы. Затем по индексу находятся документы с наибольшим количеством совпадений по шинглам с проверяемым документом.
Этот алгоритм успешно зарекомендовал себя в поиске заимствований как на английском, так и на русском языке. Алгоритм поиска по шинглам позволяет быстро обнаруживать заимствованные фрагменты, при этом он позволяет искать не только полностью скопированный текст, но и заимствования с небольшими изменениями. Подробнее о задаче обнаружения нечетких текстовых дубликатов и методах её решения можно узнать, например, из статьи Ю. Зеленкова и И. Сегаловича.
По мере развития системы поиска «почти дубликатов» становилось недостаточно. У многих авторов возникала потребность быстро повысить процент оригинальности документа, или, говоря иначе, тем или иным способом «обмануть» действующий алгоритм и получить более высокий процент оригинальности. Естественно, самый действенный способ, который приходит на ум, – это переписать текст другими словами, то есть перефразировать его. Однако основной недостаток такого способа – на реализацию уходит слишком много времени. Поэтому нужно что-то более простое, но гарантированно приносящее результат.
Тут на ум приходит заимствование из иностранных источников. Стремительный рост современных технологий и успехи машинного перевода позволяют получить оригинальную работу, которая при беглом взгляде выглядит так, как будто её написали самостоятельно (если не вчитываться внимательно и не искать ошибки машинного переводчика, которые, впрочем, легко исправить).
До недавнего времени обнаружить такой вид плагиата было можно, только обладая широкими знаниями по тематике работы. Автоматического инструмента детектирования заимствований такого рода не существовало. Это хорошо иллюстрирует случай со статьей «Корчеватель: Алгоритм типичной унификации точек доступа и избыточности». Фактически «Корчеватель» — это перевод автоматически сгенерированной статьи «Rooter: A Methodology for the Typical Unification of Access Points and Redundancy». Прецедент был создан искусственно с целью проиллюстрировать проблемы в структуре журналов из списка ВАК в частности и в состоянии российской науки в целом.
Увы, но переведённая работа «обычным Антиплагиатом» не нашлась бы – во-первых, поиск осуществляется по русскоязычной коллекции, а во-вторых, нужен иной алгоритм поиска таких заимствований.
Очевидно, что если и заимствуют тексты путем перевода, то преимущественно из англоязычных статей. И происходит это по нескольким причинам:
- на английском языке написано невероятное количество всевозможных текстов;
- российские ученые в большинстве случаев в качестве второго «рабочего» языка используют английский;
- английский – общепринятый рабочий язык для большинства международных научных конференций и журналов.
Исходя из этого, мы решили разрабатывать решения для поиска заимствований с английского на русский язык. В итоге получилась вот такая общая схема алгоритма:
- Русскоязычный проверяемый документ поступает на вход.
- Выполняется машинный перевод русского текста на английский язык.
- Происходит поиск кандидатов в источники заимствований по проиндексированной коллекции англоязычных документов.
- Производится сопоставление каждого найденного кандидата с английской версией проверяемого документа – определение границ заимствованных фрагментов.
- Границы фрагментов переносятся в русскоязычную версию документа. При завершении процесса формируется отчёт о проверке.
Первая задача, которую нужно решить после появления проверяемого документа, – это перевод текста на английский язык. Для того, чтобы не зависеть от сторонних инструментов, мы решили использовать готовые алгоритмические решения из открытого доступа и обучать их самостоятельно. Для этого необходимо было собрать параллельные корпуса текстов для пары языков «английский – русский», которые есть в открытом доступе, а также попробовать собрать такие корпуса самостоятельно, анализируя веб-страницы двуязычных сайтов. Разумеется, качество обученного нами переводчика уступает лидирующим решениям, но ведь от нас никто и не требует высокого качества перевода. В итоге удалось собрать около 20 миллионов пар предложений научной тематики. Такая выборка подходила для решения стоявшей перед нами задачи.
Реализовав машинный переводчик, мы столкнулись с первой трудностью – перевод всегда неоднозначен. Один и тот же смысл может быть выражен разными словами, может меняться структура предложения и порядок слов. А так как перевод делается автоматически, то сюда накладываются ещё и ошибки машинного перевода.
Чтобы проиллюстрировать эту неоднозначность, мы взяли первый попавшийся препринт с arxiv.org
и выбрали небольшой фрагмент текста, который предложили перевести двум коллегам с хорошим знанием английского языка и двум известным сервисам машинного перевода.
Проанализировав результаты, мы сильно удивились. Ниже видно, насколько разными получились переводы, хотя общий смысл фрагмента сохранился:
Мы предполагаем, что текст, который на первом шаге нашего алгоритма мы автоматически перевели с русского на английский, ранее мог быть переведен с английского на русский. Естественно, каким именно образом был осуществлён исходный перевод, нам неизвестно. Но даже если бы мы это знали, шансы получить в точности исходный текст были бы ничтожно малы.
Здесь можно провести параллель с математической моделью «зашумленного канала» (noisy channel model). Допустим, какой-то текст на английском прошёл через «канал с шумом» и стал текстом на русском языке, который, в свою очередь, прошёл ещё через один «канал с шумом» (естественно, это уже был другой канал) и стал на выходе текстом на английском языке, который отличается от оригинала. Наложение такого двойного «шума» – одна из основных проблем поставленной задачи.
Стало очевидно, что, даже имея переведенный текст, корректно найти в нём заимствования, осуществляя поиск по коллекции источников, состоящей из многих миллионов документов, обеспечивая достаточную полноту, точность и скорость поиска, при помощи традиционного алгоритма шинглов невозможно.
И тут мы решили уйти от старой схемы поиска, основанной на сопоставлении слов. Нам однозначно нужен был другой алгоритм детектирования заимствований, который, с одной стороны, мог бы сопоставлять фрагменты текстов «по смыслу», а с другой, оставался таким же быстрым, как алгоритм шинглов.
Но что же делать с шумом, который дает нам «двойной» машинный перевод в текстах? Будут ли обнаружены тексты, порождённые разными переводчиками, как на примере ниже?
Поиск «по смыслу» мы решили обеспечить через кластеризацию английских слов так, чтобы семантически близкие слова и словоформы одного и того же слова попали в один кластер. Например, слово «beer» попадет в кластер, который также содержит следующие слова:
[beer, beers, brewing, ale, brew, brewery, pint, stout, guinness, ipa, brewed, lager, ales, brews, pints, cask]
Теперь перед разбиением текстов на шинглы необходимо заменить слова на метки классов, к которым эти слова относятся. При этом за счёт того, что шинглы строятся с перекрытием, можно не обращать внимания на определенные неточности, присущие алгоритмам кластеризации.
Несмотря на погрешности кластеризации, поиск документов-кандидатов происходит с достаточной полнотой – нам достаточно, чтобы совпало всего несколько шинглов, и по-прежнему с высокой скоростью.
Итак, документы-кандидаты на наличие переводных заимствований найдены, и можно приступить к «смысловому» сравнению текста каждого кандидата с проверяемым текстом. Здесь нам шинглы уже не помогут – этот инструмент для решения этой задачи слишком неточен. Мы попробуем реализовать такую идею: каждому фрагменту текста поставим в соответствие точку в пространстве очень большой размерности, при этом будем стремиться к тому, чтобы фрагменты текстов, близкие по смыслу, были представлены точками, расположенными в этом пространстве неподалеку (были близки по некоторой функции расстояния).
Рассчитывать координаты точки (или чуть более научно – компоненты вектора) для фрагмента текста мы будем с помощью нейронной сети, а обучать эту сеть будем с помощью данных, размеченных асессорами. Роль асессора в этой работе – создать обучающую выборку, то есть указать для некоторых пар фрагментов текста, являются ли они близкими по смыслу или нет. Естественно, что чем больше удастся собрать размеченных фрагментов, тем лучше будет работать обученная сеть.
Ключевая задача во всей работе — правильно выбрать архитектуру и обучить нейронную сеть. Наша сеть должна отображать текстовый фрагмент произвольной длины в вектор большой, но фиксированной размерности. При этом она должна учитывать контекст каждого слова и синтаксические особенности текстовых фрагментов. Для решения задач, связанных с какими-либо последовательностями (не только текстовыми, но и, например, биологическими) существует целый класс сетей, которые называются рекуррентными. Основная идея этой сети состоит в том, чтобы получать вектор последовательности, итеративно добавляя информацию о каждом элементе этой последовательности. На практике такая модель имеет множество недостатков: её сложно тренировать, и она достаточно быстро «забывает» информацию, которая была получена из первых элементов последовательности. Поэтому на основе этой модели было предложено множество более удобных архитектур сетей, которые исправляют эти недостатки. В нашем алгоритме мы используем архитектуру GRU. Эта архитектура позволяет регулировать, сколько информации должно быть получено из очередного элемента последовательности и сколько информации сеть может «забыть».
Для того, чтобы сеть хорошо работала с разными видами перевода, мы обучали её как на примерах ручного, так и машинного перевода. Сеть обучалась итеративно. После каждой итерации мы изучали, на каких фрагментах она ошибалась сильнее всего. Такие фрагменты мы также давали сети для обучения.
Интересно, но использование готовых нейросетевых библиотек, таких как word2vec, успеха не принесло. Их результаты мы использовали в работе в качестве оценки базового уровня, ниже которого опускаться было нельзя.
Стоит отметить ещё один немаловажный момент, а именно — размер фрагмента текста, который будет отображаться в точку. Ничто не мешает, например, оперировать с полными текстами, представляя их в виде единого объекта. Но в этом случае близкими будут только тексты, полностью совпадающие по смыслу. Если же в тексте будет заимствована только какая-то часть, то нейронная сеть расположит их далеко, и мы ничего не обнаружим. Хорошим, хотя и не бесспорным, вариантом является использование предложений. Именно на нём мы решили остановится.
Давайте попробуем оценить, какое количество сравнений предложений нужно будет выполнить в типичном случае. Допустим, и проверяемый документ, и документы кандидаты содержат по 100 предложений, что соответствует размеру средней научной статьи. Тогда на сравнение каждого кандидата нам потребуется 10 000 сравнений. Если кандидатов будет всего 100 (на практике из многомиллионного индекса иногда поднимаются и десятки тысяч кандидатов), то нам потребуется 1 миллион сравнений расстояний для поиска заимствований всего в одном документе. А поток проверяемых документов часто переваливает за 300 в минуту. При этом сам по себе расчёт каждого расстояния – тоже не самая простая операция.
Чтобы не сравнивать все предложения со всеми, используем предварительный отбор потенциально близких векторов на основе LSH-хэширования. Основная идея этого алгоритма в следующем: каждый вектор мы умножаем на некоторую матрицу, после чего запоминаем, какие компоненты результата умножения имеют значение больше нуля, а какие – меньше. Такую запись про каждый вектор можно представить двоичным кодом, обладающим интересным свойством: близкие векторы имеют схожий двоичный код. Таким образом, при правильном подборе параметров алгоритма мы сокращаем количество требуемых попарных сравнений векторов до небольшого числа, которое можно провести за приемлемое время.
Отобразим результаты работы нашего алгоритма – теперь при загрузке пользователем документа можно выбрать проверку по коллекции переводных заимствований. Результат проверки виден в личном кабинете:
Итак, алгоритм готов, проведено его обучение на модельных выборках. Удастся ли нам найти что-то интересное на практике?
Мы решили поискать переводные заимствования в крупнейшей электронной библиотеке научных статей eLibrary.ru, основу которой составляют научные статьи, входящие в Российский индекс научного цитирования (РИНЦ). Всего мы проверили около 2,5 млн научных статей на русском языке.
В качестве области поиска мы проиндексировали коллекцию англоязычных архивных статей из фондов elibrary.ru, сайты журналов открытого доступа, ресурс arxiv.org, англоязычную википедию. Общий объем базы источников в боевом эксперименте составил 10 миллионов текстов. Может показаться странным, но 10 миллионов статей – это очень небольшая база. Количество научных текстов на английском языке исчисляется, как минимум, миллиардами. В этом эксперименте, располагая базой, в которой находилось менее 1% потенциальных источников заимствований, мы считали, что даже 100 выявленных случаев будут удачей.
В результате мы обнаружили более 20 тысяч статей, содержащих переводные заимствования в значительных объемах. Мы пригласили экспертов для детальной проверки выявленных случаев. В результате удалось проверить чуть меньше 8 тысяч статей. Результаты анализа этой части выборки представлены в таблице:
| Тип срабатывания | Количество |
|---|---|
| Заимствование | 2627 |
| Переводные заимствования (текст переведен с английского языка и выдан за оригинальный) |
921 |
| Заимствования «наоборот» – из русского языка в английский (определялось по дате публикаций) | 1706 |
| Легальные заимствования | 2355 |
| Двуязычные статьи (работы одного и того же автора на двух языках) |
788 |
| Цитаты законов (использование формулировок законов) |
1567 |
| Cамоцитирование (переводное цитирование автором своей же англоязычной работы) |
660 |
| Ошибочные срабатывания (из-за некорректного перевода или ошибки нейронной сети) |
507 |
| Другое (проверяемые статьи содержали фрагменты на английском языке, или сложно отнести к какой-либо категории) |
1540 |
| Всего | 7689 |
Часть результатов относится к легальным заимствованиям. Это переводные работы тех же авторов или выполненные в соавторстве, часть результатов — корректные срабатывания одинаковых фраз, как правило, одних и тех же юридических законов, переведённых на русский язык. Но значительная часть результатов — это некорректные переводные заимствования.
Исходя из анализа, можно сделать несколько интересных выводов, например, о распределении процента заимствований:
Видно, что чаще всего заимствуют небольшие фрагменты, однако встречаются работы, заимствованные целиком и полностью, включая графики и таблицы.
Из гистограммы, приведенной ниже, видно, что заимствовать предпочитают из недавно опубликованных статей, хотя встречаются работы, где источник датируется, например, 1957 г.
Мы использовали метаданные, предоставленные eLibrary.ru, в том числе о том, к какой области знания относится статья. Используя эту информацию, можно определить, в каких российских научных областях чаще всего заимствуют путём перевода с английского.
Самый наглядный способ убедиться в корректности результатов – это сравнить тексты обеих работ – проверяемой и источника, положив их рядом.
Сверху – работа на английском языке с arxiv.org, снизу – русскоязычная работа, которая целиком и полностью, включая графики и результаты, является переводом. Соответствующие блоки отмечены красным. Примечательным является и тот факт, что авторы пошли ещё дальше – оставшиеся куски оригинальной статьи они тоже перевели и опубликовали ещё пару «своих» статей. На оригинал авторы решили не ссылаться. Информация обо всех найденных случаях переводных заимствований передана в редакции научных журналов, выпустивших соответствующие статьи.
Таким образом, результат не мог нас не порадовать – система «Антиплагиат» получила новый модуль для обнаружения переводных заимствований, который проверяет русскоязычные документы теперь и по англоязычным источникам.
Творите собственным умом!
habr.com