В апреле я рассказывала на SE7ENе о своем дипломном проекте — системе для верификации источников в научных работах. На тот момент до защиты оставалось два месяца, проект представлял собой «сырой» прототип, а я пыталась понять, что из задуманного реально воплотить в жизнь.
С того времени система заметно эволюционировала.
Во-первых, я успешно защитила диплом. Работа получила оценку «отлично» и была отмечена как лучшая на потоке, что стало приятным достижением.
Во-вторых, проект превратился из учебной поделки в полноценный инженерный продукт. Появились инструменты для оптического распознавания символов (OCR), кэширование, возможность работы в офлайн-режиме, оценка на корпусах текстов, классификация ошибок и специализированные ML-модели для узких задач.
И самое важное: после защиты стало ясно, что диплом — это формальность, а вот проблема — реальна. По мере развития системы вскрывались типичные «боли»: PDF-верстка, некачественный OCR, скудные метаданные, специфика русскоязычных источников и капризы внешних API. Вечное «источник не найден: это системный сбой или его действительно нет?» стало главной точкой роста.
Эта статья — не финальный отчет об успешном завершении, а рефлексия о том, что удалось внедрить, как переосмыслить архитектуру и почему проверка библиографии оказалась гораздо более глубокой задачей, чем казалось в начале пути.
Что проверяет система
Официально тема моей работы звучала так:
«Разработка системы автоматической проверки подлинности источников в научных публикациях с использованием методов машинного обучения»
Если проще: система анализирует научный текст, вычленяет список литературы, разбирает каждую библиографическую запись, сопоставляет её с внешними базами и выдает не просто бинарный ответ, а детальный анализ.
Результат может выглядеть так:
-
источник верифицирован;
-
источник предположительно существует, но данных недостаточно;
-
подтвердить источник не удалось;
-
источник найден, но в оформлении есть неточности;
-
запись распознана некачественно, нужна ручная модерация.
Поначалу я полагала, что главная сложность — работа с DOI и URL. Казалось бы: извлек DOI, отправил запрос — получил ответ. Но на деле DOI — лишь середина пути. Сначала нужно извлечь текст из PDF, отсечь «шум» (колонтитулы), разделить список на записи, распарсить авторов, названия, годы и журналы, не исказив при этом смысл.
Эволюция пайплайна
Первая версия была прямолинейной:
документ -> текст -> список литературы -> записи -> DOI/URL -> проверка -> статусТекущий пайплайн стал гораздо более надежным. Система принимает PDF и DOCX, при необходимости использует OCR, удаляет артефакты форматирования, ищет библиографический раздел (не только по классическим заголовкам) и выполняет нормализацию текста.
Отдельный блок посвящен фильтрации «шума»: система исправляет разрывы строк в DOI, ошибки кодировок и типичные огрехи OCR. Записи декомпозируются на поля, после чего начинается интеллектуальный поиск через Crossref, OpenAlex, Wikidata, ORCID, PubMed и Google Scholar. Внедрение SQLite-кэша позволило реализовать офлайн-режим и снизить нагрузку на внешние API.
Главное новшество — интерпретируемость. Теперь система классифицирует тип проблемы:
-
ошибки в DOI/URL;
-
несовпадения по авторам, заголовкам или году издания;
-
ошибки журнала/издателя;
-
риски, связанные с некачественным OCR или парсингом.
DOI — не панацея
Я перестала считать отсутствие DOI доказательством «фейковости» источника. Это опасное упрощение.
Источники могут существовать без DOI, иметь битые ссылки или быть некорректно проиндексированы. Поэтому сейчас моя система использует многофакторный подход. Она взвешивает данные: резолвится ли DOI, открывается ли ссылка, находится ли публикация в независимых каталогах, насколько совпадают метаданные. Итоговый вердикт — это комбинация всех этих признаков.
Архитектура пайплайна сегодня
PDF/DOCX -> извлечение текста -> OCR (при необходимости) -> очистка от колонтитулов -> поиск блока литературы -> сегментация -> нормализация -> парсинг полей -> оценка качества -> внешняя проверка -> сопоставление -> ML-оценка -> классификация рисков -> финальный отчет (HTML/JSON)Для пользователя формируется подробная карточка записи, где видны исходные данные, найденные расхождения и причины вердикта системы.
Место машинного обучения
Я отказалась от идеи «одной универсальной модели» в пользу двух специализированных:
-
source_trust: оценивает общую надежность источника на основе признаков (качество метаданных, результаты внешних проверок). -
reference_match: определяет, соответствует ли найденная в каталоге карточка запрошенному источнику (особенно важно при частичных совпадениях авторов или названий).
ML здесь — не замена логики, а надстройка, позволяющая точнее анализировать пограничные случаи.
Метрики и реальный мир
На тестовой выборке из 41 записи сегментация сработала безупречно (F1=1.0), но я понимала, что это — «тепличные» условия. Корпусная оценка на 500 документах PMC показала более суровую картину: библиографические разделы находятся в 96,8% случаев, а recall по извлечению записей составляет около 82%. Эти цифры честнее отражают сложность работы с PDF.
Почему человеческий контроль неизбежен
Я осознала, что «human-in-the-loop» — это не костыль, а верная стратегия. Задача системы — не выносить окончательный приговор, а помочь эксперту сэкономить время, подсветив подозрительные участки и аргументировав риски. Понятие unknown (неопределенность) стало полноценным и очень важным результатом работы.
Планы и итоги
Проект перерос дипломные рамки. В планах — расширение датасета для работы с ГОСТом и русскоязычными источниками, доработка модуля автоисправления и создание удобного интерфейса для научной редактуры.
Когда я только начинала, тема казалась рутинной «техничкой». На выходе же я получила сложную инженерную задачу на стыке NLP, поиска, машинного обучения и UX. Моя система еще не идеальна, но она выполняет главное: учит нас не доверять библиографии слепо, даже если она выглядит безупречно.
