Список литературы тоже умеет галлюцинировать: как я делаю систему проверки научных источников

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

Тема моей ВКР звучит так:

«Разработка системы автоматической проверки подлинности источников в научных публикациях с использованием методов машинного обучения»

Если убрать дипломный официальный стиль, то по‑человечески идея такая:

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

• источник подтвержден

• источник, скорее всего, реальный, но данных маловато

• источник не удалось подтвердить

А если в ссылке есть кривые поля, система должна не просто сказать «что‑то не так», а по возможности показать, что именно не так и как запись должна выглядеть корректнее.

Почему эта проблема вообще стала такой заметной

Если раньше список литературы казался чем‑то очень скучным и техническим, то сейчас он внезапно оказался в центре вполне реальной проблемы.

С ростом генеративных моделей стало видно, что ссылки в научных и околонаучных текстах умеют не просто содержать опечатки, а буквально выдумываться. Где‑то искажается DOI, где‑то ломается название статьи, где‑то смешиваются авторы, а где‑то источник вообще существует только в фантазии модели.

И вот это уже не история про «ой, запятая не там».

Это история про достоверность текста как такового.

Если в публикации стоят несуществующие или искаженные источники, это бьет сразу по нескольким вещам:

1. по качеству самой работы

2. по доверию к автору

3. по времени рецензентов и редакторов, которым приходится все это проверять руками

4. по воспроизводимости научного результата, потому что по плохой ссылке ты просто никуда не придешь

Отдельно меня зацепило то, что проблема здесь двойная.

С одной стороны, есть оформление: ссылка может быть написана в ГОСТ, APA, IEEE или в каком‑то очень авторском жанре, который, видимо, появился в 03:17 перед дедлайном. С другой стороны, есть подлинность: даже идеально оформленная ссылка может вести в никуда.

И если честно, в какой‑то момент мне стало интересно не просто «починить формат», а именно научить систему различать:

• запись, которая реально существует

• запись, которая выглядит правдоподобно, но подтверждений мало

• запись, которая собрана с ошибками

• запись, которую лучше сразу отдать человеку, а не делать вид, что алгоритм все понял

Что я сначала подумала про эту задачу

На старте мне казалось, что все будет довольно линейно.

Примерно так:

1. Берем PDF

2. Находим раздел со списком литературы

3. Вытаскиваем DOI или URL

4. Проверяем, существует ли ссылка

5. Если что‑то не сходится, помечаем запись как подозрительную

Очень стройный план. Очень оптимистичный. Очень недолго прожил. Потому что довольно быстро выяснилось, что проблема начинается сильно раньше DOI.

Чтобы вообще дойти до этапа «проверить источник», системе нужно сначала:

• вытащить текст из документа

• понять, где в этом тексте начинается и заканчивается список литературы

• отделить реальные библиографические записи от мусора, колонтитулов и служебных кусочков

• разбить сплошной блок на отдельные источники

• вытащить из каждой строки авторов, название, год, журнал, том, номер, страницы, DOI, URL и все остальное

• понять, какие поля отсутствуют, а какие просто распознаны криво

То есть еще до собственно валидации начинается очень насыщенная жизнь.

Где задача оказалась сложнее, чем выглядела

Библиография не живет в одном аккуратном формате

Это, наверное, первое, что по‑настоящему отрезвляет.

В теории у нас есть стандарты оформления. На практике у нас есть:

• ГОСТ

• APA

• IEEE

• смешанные списки

• частично заполненные записи

• статьи без DOI

• книги, сайты, сборники, отчеты, патенты

• и, конечно, ссылки, которые выглядят так, будто человек очень надеялся, что никто не будет их читать слишком внимательно

Одна и та же задача «вытащить автора, название и год» начинает вести себя по‑разному в зависимости от типа источника, языка, качества исходного текста и степени библиографической дисциплины автора.

PDF вообще не обязан любить тех, кто потом будет его парсить

Если документ уже лежит в PDF, это не значит, что внутри нас ждет красивый логический текст. Там могут быть: повторяющиеся шапки и футеры; разрывы строк в неудобных местах; нестабильный порядок текстовых блоков; скан без нормального текстового слоя; куски, в которых визуально все понятно человеку, но машине это надо еще как‑то объяснить.

Поэтому у меня один из первых технических выводов был очень простой:

прежде чем проверять подлинность ссылок, надо вообще научиться надежно извлекать и структурировать библиографию из документа.

Одного DOI недостаточно

Это была еще одна важная точка. Да, DOI очень удобен. Если он есть и корректно резолвится, жить сразу становится легче. Но дальше начинаются реальные случаи:

• DOI нет

• DOI написан с ошибкой

• есть только URL

• URL умер, но сам источник существует

• источник есть в реестрах, но в записи искажены авторы или заголовок

• русскоязычный источник нормально ищется по метаданным, но не живет по сценарию «нашел DOI и успокоился»

В этот момент становится понятно, что простой проверки «URL/DOI доступен или нет» недостаточно. Нужна более широкая логика сопоставления: по идентификаторам, по названию, по авторам, по году, по косвенным подтверждениям из внешних баз.

Нельзя просто сказать «алгоритм решил»

Для такой задачи мало выдать ярлык true/false.

Если системой будут пользоваться авторы, редакторы или рецензенты, им важно понимать:

• почему ссылка признана достоверной

• почему запись ушла в сомнительные

• какие поля не совпали

• что именно система предлагает исправить

То есть здесь нужен не только результат, но и объяснимость. И мне это, кстати, нравится отдельно: я не хотела делать черный ящик, который торжественно выдает вердикт и исчезает в туман.

Почему я не остановилась на готовых инструментах

Когда я начала смотреть аналоги, очень быстро стало видно, что сильные инструменты есть, но они обычно закрывают часть задачи, а не весь сценарий. Я смотрела в сторону инструментов вроде GROBID, CERMINE, AnyStyle, а также на API и каталоги вроде Crossref.

Есть решения, которые хорошо извлекают и структурируют библиографию.

Есть реестры и API, которые хороши для проверки конкретных метаданных.

Есть инструменты, полезные для поиска DOI или нормализации ссылок.

Но вот сквозной путь:

извлечь -> разобрать -> проверить -> объяснить -> предложить корректировку -> собрать отчет
закрывается уже не так часто.

Особенно если учитывать несколько неприятных, но очень жизненных условий:

• работа с PDF

• разнородные форматы ссылок

• русскоязычные записи и ГОСТ

• случаи без DOI

• необходимость объяснить итоговый вердикт, а не просто вернуть «не найдено»

Мне не хотелось написать «еще один парсер ради парсера». Мне хотелось сделать именно сквозную систему, которая не теряет смысл задачи на середине пайплайна.

Как в итоге выглядит мой текущий пайплайн

Сейчас логика системы у меня выглядит так:

Документ (PDF/DOCX)
-> извлечение текста
-> поиск блока библиографии
-> разбиение на отдельные записи
-> парсинг полей записи
-> проверка DOI/URL
-> поиск подтверждений во внешних реестрах
-> оценка достоверности
-> нормализация и отчет

Если чуть подробнее, то на текущем этапе прототип умеет:

• принимать документ через веб‑интерфейс

• извлекать текст и строить промежуточную JSON‑структуру

• находить блок списка литературы не только по заголовку Литература или References, а по набору эвристик

• разбивать этот блок на отдельные библиографические записи

• извлекать поля вроде авторов, названия, года, DOI, URL, журнала, тома, номера и страниц

• считать parse confidence — насколько вообще похоже, что запись распарсилась адекватно

• проверять DOI и URL

• искать дополнительные подтверждения через внешние источники вроде Crossref, OpenAlex, Wikidata, ORCID, Google Scholar и веб‑поиска

• присваивать каждой записи статус достоверности

• сохранять структурированный результат и отчет

Для записи система в итоге формирует не просто «ок/не ок», а более полезный результат:

verified — источник подтвержден

likely_verified — скорее достоверный, но подтверждений не идеально много

unverified — надежных сигналов недостаточно

unknown — данных для уверенного решения не хватило.

Мне было важно заложить не бинарную логику, а нормальную рабочую шкалу неопределенности. Потому что реальный мир в таких задачах почти никогда не делится на красивое «истина/ложь».

Зачем здесь вообще машинное обучение, если уже есть правила

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

Поэтому я пошла в гибридную схему:

• правила и эвристики закрывают извлечение признаков, проверку DOI/URL и базовую валидацию

• ML‑слой помогает оценивать достоверность записи в более неидеальных случаях

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

Сейчас ML‑модель у меня использует признаки вроде:

• наличия названия, года, журнала, DOI, URL

• уверенности парсинга

• результатов DOI/URL‑проверки

• числа подтверждений из внешних сервисов

• общей эвристической оценки записи

Мне нравится этот подход тем, что он не пытается магически «угадать все», а работает как дополнительный слой устойчивости поверх более прозрачной логики. То есть не «пусть нейросеть сама разбирается», а «пусть модель помогает там, где правила уже начинают спотыкаться».

Как я вообще собираюсь понимать, что эта штука работает

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

• Парсинг: насколько правильно выделяются авторы, название, год, DOI, URL и другие поля.

• Сопоставление: сколько ссылок удается подтвердить через DOI, URL и внешние реестры.

• Классификация: насколько корректно система присваивает статусы достоверности по сравнению с ручной оценкой.

• Автокоррекция: как часто предложенное исправление действительно улучшает запись, а не делает ее просто по‑другому сломанной.

Мне это кажется важным по очень простой причине:

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

Короче, тут хочется не «собрать один впечатляющий демо‑скрин», а реально понимать, на каком именно этапе система молодец, а на каком ей еще нужно повзрослеть.

Самое интересное для меня в этой теме

Если честно, меня в этой работе сильнее всего зацепило не то, что она «про ML», а то, что она находится на пересечении очень разных вещей: обработки документов, NLP, валидации данных, поиска и сопоставления сущностей, UX для доверия к автоматическому решению.

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

Именно поэтому у меня в архитектуре с самого начала важен human-in-the-loop сценарий:

если система не может уверенно подтвердить запись, она не должна изображать всемогущего оракула. Она должна честно сказать: «вот что я проверила, вот что совпало, вот где сомнения, дальше лучше посмотреть руками».

Мне кажется, для прикладных систем это вообще очень здоровый принцип.

Что уже получилось, а что пока нет

Сейчас у меня уже есть рабочий прототип, который:

• принимает PDF и DOCX

• извлекает библиографию

• разбирает записи на поля

• проверяет идентификаторы и внешние подтверждения

• считает степень достоверности

• показывает структурированные результаты в интерфейсе

• отдает итоговый JSON для дальнейшей обработки.

Но мне очень не хочется делать вид, что задача уже магически закрыта.

У системы пока есть вполне честные ограничения.

Например:

• для сканированных PDF без текстового слоя нужен OCR, и это отдельный пласт работы

• нестандартные и очень шумные ссылки все еще могут парситься неидеально

• внешние сервисы живут по своим правилам: где‑то есть rate limits, где‑то нестабильные ответы, где‑то вообще можно словить CAPTCHA

• не всякую неподтвержденную запись корректно считать фейковой: иногда проблема просто в неполных метаданных

• автокоррекция библиографических полей требует очень аккуратной логики, чтобы не «чинить» запись в сторону новой ошибки.

И вот это, кстати, одна из вещей, за которые я уважаю эту тему. Она не дает сделать вид, что все просто. Любая попытка построить такую систему довольно быстро учит инженерной скромности.

Что я хочу успеть за оставшиеся два месяца

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

В ближайшем плане у меня:

1. доработать устойчивость извлечения ссылок из документов

2. улучшить обработку сложных и смешанных форматов записей

3. расширить и лучше разметить датасет для ML‑оценки достоверности

4. аккуратно доработать механизм автокоррекции

5. прогнать систему на корпусе примеров и зафиксировать метрики по каждому этапу

Для меня важно, чтобы к защите это была не просто «идея с красивой блок‑схемой», а система, про которую можно честно сказать:

вот вход, вот логика обработки, вот где она справляется хорошо, вот где пока нужны ограничения и ручная проверка.

Почему мне вообще захотелось написать об этом

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

Если совсем честно, мне еще и нравится, что это задача не про магию. Здесь не получится красиво кинуть в проблему одну абстракцию, одну модель и уйти в закат. Нужно собирать систему из нескольких слоев, держать в голове ограничения, уважать неопределенность и постоянно выбирать между «автоматизировать» и «не навредить». Это довольно инженерная, довольно живая и местами очень упрямая задача.

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

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

Но если вам близка эта тема, будет очень интересно обсудить:

— как вы бы решали задачу проверки подлинности источников

— где, по‑вашему, в таком пайплайне самые неприятные edge cases

— какие внешние базы или эвристики вы бы добавили

— и насколько вообще, по вашему опыту, проблема фейковых и искаженных ссылок уже успела стать массовой.

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