Нейросеть для поиска научных статей: как работает поиск по смыслу

Поиск6 августа 2026 г.18 мин чтения

Нейросети для поиска научных статей ищут по смыслу: они переводят запрос и аннотации статей в числовые векторы и находят работы, близкие по значению, даже если в них нет ни одного слова из запроса. Так работают семантический поиск OpenAlex, Elicit, Consensus, Find Papers в Asta от Ai2 и похожие сервисы. Для разведки темы они удобны и находят статьи с непривычной терминологией, но полноту классического поиска пока не дают: в проверке 2025 года на четырёх обзорах (два из них кокрейновские) Elicit нашёл в среднем 39,5% включённых исследований, а исходный поиск этих обзоров по нескольким базам с дополнительными методами нашёл 94,5% (Lau, Golder, 2025).

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

Как работает поиск по смыслу

Привычный поиск в eLibrary, Google Scholar или строке PubMed сопоставляет слова. Система находит документы, где встречаются термины запроса или их формы, и ранжирует их, например, по модели BM25: чем чаще термин встречается в документе и чем реже во всей коллекции, тем выше документ в списке. Такой поиск быстрый и предсказуемый, но он не знает, что «инфаркт миокарда», «myocardial infarction» и «heart attack» описывают одно и то же. PubMed частично выручает автоматическим сопоставлением терминов с рубриками MeSH (Automatic Term Mapping), а eLibrary и Google Scholar так не умеют.

Семантический поиск превращает каждый текст (запрос и каждую статью) в вектор из нескольких сотен или тысяч чисел, который называют эмбеддингом (embedding). Модель обучена так, что тексты с близким значением получают близкие векторы. Поиск сводится к геометрической задаче: найти статьи, чьи векторы ближе всего к вектору запроса. Поэтому второе название технологии: векторный поиск. Например, OpenAlex кодирует заголовок и аннотацию каждой работы вектором из 1024 чисел и сравнивает его с вектором запроса по косинусному сходству (OpenAlex Help Center).

	Поиск по ключевым словам	Семантический поиск
Что сопоставляет	Слова и их формы	Близость по смыслу (векторы)
Запрос «сахарный диабет 2 типа» находит статьи, где сказано	«сахарный диабет 2 типа»	«инсулиннезависимый диабет», «СД2», а при многоязычной модели и «type 2 diabetes», «T2DM»
Синонимы	Нужно перечислять вручную	Подбирает близкие понятия сам
Язык	Ищет в пределах языка запроса	Связывает языки, только если модель многоязычная
Воспроизводимость	Одна и та же строка даёт тот же результат на ту же дату	Результат меняется вместе с моделью и версией сервиса
Где сильнее	Точный термин, код, автор, название шкалы	Тема, описанная своими словами; незнакомая терминология
Где слабее	Синонимия, перефразировки	Точные условия, отрицания («без», «кроме»), числовые диапазоны

Гибридный поиск и «умная сортировка»

Многие сервисы совмещают оба подхода. Consensus ищет по заголовкам и аннотациям одновременно через эмбеддинги и через BM25, а затем пересортировывает 1500 лучших результатов с учётом свежести публикации, цитируемости и авторитета журнала (Consensus).

Слово «ИИ» рядом с поиском ещё не означает поиска по смыслу. По описанию разработчиков 2023 года, поиск по релевантности в Semantic Scholar устроен как поиск по ключевым словам: индекс Elasticsearch по заголовкам, аннотациям и авторам находит до 1000 совпадений, а обученная модель LightGBM их пересортировывает. Собственные смысловые векторы статей (модель SPECTER) Semantic Scholar использует для рекомендаций похожих работ и разрешения неоднозначности авторов; основная строка поиска на них не опирается (Kinney и соавт., The Semantic Scholar Open Data Platform). Плотный смысловой поиск по корпусу Semantic Scholar Ai2 сейчас предлагает через инструменты Asta (Ai2, Asta).

Поисковые агенты на основе больших языковых моделей

Следующий шаг после векторного поиска: агент, который ищет в несколько проходов. Paper Finder от Ai2 (теперь инструмент Find Papers в Asta) разбивает запрос на части, переформулирует его с помощью языковой модели, ищет по нескольким векторным индексам, идёт по ссылкам назад и вперёд по цитированию, оценивает релевантность каждой статьи и объясняет, почему она подходит (Ai2, Asta). Сами разработчики называют слабые места: запросы, для которых у пользователя нет нужного словаря, длинные расплывчатые запросы, числовые диапазоны и условия-отрицания (Ai2, Introducing Paper Finder). По цитированиям в несколько проходов ищет и Undermind. Elicit тоже отбирает статьи в несколько этапов: сначала по векторам, затем моделью-классификатором (Elicit Help Center).

Почему поиск по смыслу находит работы с другой терминологией

Синонимы и аббревиатуры. «Сахарный диабет 2 типа», «инсулиннезависимый сахарный диабет», «type 2 diabetes», «T2DM», «NIDDM». Для поиска по словам это пять разных запросов. Смысловой поиск связывает их сам, а при поиске по словам все варианты приходится перечислять вручную.

Смена терминов со временем. Названия понятий меняются, а старые статьи остаются со старыми названиями. Обзор за несколько десятилетий, построенный на одном современном термине, рискует их не найти. Список прежних и параллельных названий удобно брать из входных терминов рубрики MeSH: у рубрики о диабете 2 типа их около тридцати, от «adult-onset diabetes mellitus» до «maturity-onset diabetes».

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

Язык публикации. Многоязычная модель помещает русский и английский тексты об одном понятии рядом, и тогда русский запрос находит английскую статью. Но многоязычность нужно проверять у конкретного сервиса: OpenAlex, например, использует модель GTE Large EN (OpenAlex Help Center), которую разработчики заявляют как англоязычную (карточка модели), поэтому запрос к нему разумнее формулировать по-английски.

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

По аннотации или по полному тексту

Большинство сервисов строит векторы по заголовку и аннотации. OpenAlex кодирует заголовок и аннотацию каждой работы. Elicit анализирует полный текст только открытых статей или статей по подписке пользователя, а в остальных случаях опирается на заголовок и аннотацию (Elicit Help Center). Consensus на первом этапе сопоставляет запрос с заголовками и аннотациями.

У аннотации ограниченный словарь. В неё редко попадают названия шкал, дозировки, версии программ и подробности выборки из раздела «Материалы и методы». Если критерий отбора касается такой детали (например, «исследования, где выгорание измеряли по MBI»), поиск по аннотации её не увидит, какой бы умной ни была модель. Такие критерии проверяют уже на этапе полнотекстового отбора.

Какие инструменты умеют искать по смыслу

Сведения ниже взяты из документации разработчиков на сентябрь 2026 года. Подробное сравнение ИИ-сервисов по цене, поддержке русского языка, оплате из Беларуси и России и оформлению по ГОСТ собрано в статье «Elicit и Consensus на русском: чем заменить».

Инструмент	Как ищет	Корпус (по данным разработчика)	Что учесть
OpenAlex, параметр API `search.semantic`	Векторы по заголовку и аннотации, модель GTE Large EN	Заголовок и аннотация каждой работы OpenAlex	До 50 результатов на запрос, 1 запрос в секунду, запрос до 2000 знаков; лучше работает на длинном описании темы или аннотации. Платно: 1 доллар за 1000 запросов, с бесплатным ключом API даётся 1 доллар в день. Запрос можно задать прямо в адресной строке браузера: `api.openalex.org/works?search.semantic=...`
Semantic Scholar	По описанию разработчиков 2023 года: поиск по словам (Elasticsearch) и пересортировка моделью LightGBM; векторы SPECTER для рекомендаций похожих статей	Более 200 млн статей	Поиск по релевантности работает по словам; «похожие статьи» дают смысловое расширение; смысловой поиск по корпусу Ai2 развивает в Asta
Asta, Find Papers (Ai2)	Агент: переформулирует запрос, ищет по векторным индексам, идёт по цитированиям, объясняет релевантность	Индекс Semantic Scholar	Слабо работает с числовыми диапазонами и отрицаниями
Elicit	Отбор кандидатов по векторам, затем модель-классификатор оценивает релевантность; в режиме систематического обзора есть булев поиск	Около 138 млн статей из Semantic Scholar, PubMed и OpenAlex после удаления дублей	Серая литература и часть отчётов клинических исследований находятся хуже; книг и диссертаций в корпусе нет. Булев поиск есть только в режиме систематического обзора на тарифах Pro и выше, усечение `*` пока не поддерживается
Consensus	Гибрид: эмбеддинги и BM25 по заголовкам и аннотациям, затем пересортировка с учётом свежести, цитируемости и журнала	Более 220 млн работ из Semantic Scholar, OpenAlex, собственного обхода сайтов и партнёрств с издательствами	Ранжирование учитывает цитируемость и репутацию журнала, поэтому малоцитируемые работы и статьи в малоизвестных журналах могут оказаться ниже
Undermind	Агент: несколько последовательных поисков, чтение найденного, переход по цитированиям	На главной странице сервиса не указан	Один поиск занимает несколько минут

Отдельно о ChatGPT и других чат-ботах без подключённой базы статей. Такой бот составляет список по памяти модели, и в нём встречаются несуществующие статьи. Как быстро проверить ссылку и DOI, разобрано в статье «ChatGPT выдумывает источники».

Справочник самих баз (Scopus, Web of Science, PubMed, eLibrary, КиберЛенинка, репозитории вузов Беларуси, диссертации) вынесен в статью «Где искать научные статьи». В документации перечисленных ИИ-сервисов нет данных о том, насколько полно в них представлены русскоязычные журналы, поэтому для тем, где важна русскоязычная литература, отдельный поиск в КиберЛенинке и eLibrary остаётся обязательным.

Как совмещать смысловой поиск с булевой строкой протокола

Для систематического обзора поиск должен быть воспроизводимым: другой исследователь, запустив ту же строку в той же базе, получает тот же набор записей на ту же дату. Смысловой поиск этому требованию не отвечает. Авторы проверки Elicit прямо предупреждают, что один и тот же вопрос до и после обновления сервиса может дать два разных ответа от двух разных версий (Lau, Golder, 2025). Сам Elicit называет булев поиск необходимым там, где нужен точный контроль над результатами и соответствие PRISMA (Elicit Help Center). Поэтому смысловой поиск встраивают в стратегию в двух местах: до булевой строки (разведка и сбор терминов) и после неё (дополнительный метод поиска).

Шаг 1. Разведка темы

Опишите тему развёрнуто, как аннотацию будущего обзора, и запустите смысловой поиск в одном-двух сервисах. Цель на этом шаге: набрать 10-20 заведомо подходящих статей и понять, как авторы называют ваши понятия. Для сложных вопросов, которые плохо укладываются в PICO, руководство Cochrane (глава 4, раздел 4.4.2, редакция марта 2025 года) допускает и такой ход: попросить чат-бот вроде ChatGPT или Claude предложить структуру поиска по подробному описанию вопроса (Cochrane Handbook, глава 4). Предложения чат-бота остаются черновиком, который проверяет человек.

Шаг 2. Сбор терминов по блокам вопроса

Разложите вопрос на понятия по схеме PICO или её аналогу и для каждого понятия выпишите все варианты из найденных статей: синонимы, аббревиатуры, старые названия, написание через дефис и без, рубрики контролируемого словаря (MeSH в PubMed, Emtree в Embase). Найденные на шаге 1 статьи удобно просматривать именно ради словаря: заголовок, аннотация, ключевые слова, рубрики.

Шаг 3. Булева строка

Внутри блока термины соединяют через OR, блоки между собой через AND. Пример для темы «машинное обучение для прогноза осложнений после операций»:

("machine learning" OR "deep learning" OR "artificial intelligence"
 OR "neural network*" OR "random forest" OR "gradient boosting")
AND
("postoperative complication*" OR "surgical complication*"
 OR "adverse event*" OR "surgical site infection*")
AND
(predict* OR prognos* OR "risk model*" OR "risk stratification")

Синтаксис усечения (*), фразового поиска и полей отличается от базы к базе, поэтому строку адаптируют под каждую базу и сохраняют все версии. Cochrane рекомендует до запуска отдать стратегию на рецензию библиографу или специалисту по информационному поиску (раздел 4.4.8). Место поиска в общем маршруте обзора описано в пошаговом руководстве по систематическому обзору.

Шаг 4. Смысловой поиск как дополнительный метод

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

В отчёте такие поиски описывают по расширению PRISMA-S: инструмент указывают в пункте 7 «Другие методы», дату поиска в пункте 13, число найденных записей в пункте 15, способ удаления дублей в пункте 16 (Rethlefsen и соавт., PRISMA-S). Запишите точный текст запроса, название сервиса, дату и сохраните выгрузку результатов: повторить такой поиск позже, скорее всего, не получится. Как отражать эти числа в блок-схеме, разобрано в статье о чек-листе и блок-схеме PRISMA 2020.

Шаг 5. Поиск по цитированиям

Просмотрите списки литературы включённых статей и работы, которые их цитируют (PRISMA-S, пункт 5). Агентные инструменты вроде Find Papers в Asta частично делают это сами, но в отчёте поиск по цитированиям описывают как отдельный метод.

Как проверить полноту поиска

Полноту поиска (чувствительность, recall) Cochrane определяет как долю найденных релевантных публикаций от всех релевантных публикаций в источнике (Cochrane Handbook, раздел 4.4.3). Всех релевантных публикаций никто не знает, поэтому на практике считают относительную полноту (relative recall) по контрольному набору. Пошаговую процедуру описали Lagisz и соавт. в журнале Research Synthesis Methods (Lagisz и соавт., 2025):

Соберите контрольный набор заведомо подходящих статей. Берите их из источников вне проверяемой базы: списки литературы в известных обзорах, ручной просмотр журналов, советы коллег, поиск по цитированиям. Набор собирают до разработки строки. Статьи, найденные смысловым поиском на шаге 1, тоже годятся, но разделите их: по одной части подбирайте термины (шаг 2), а другую отложите для проверки. Если проверять строку по статьям, из которых брали термины, полнота окажется завышенной.
Проверьте, какие статьи набора вообще есть в базе, где запускается строка.
Уберите из набора те, которых в базе нет: их отсутствие говорит о покрытии базы, а не о качестве строки.
Запустите поисковую строку.
Посмотрите, сколько статей набора оказалось в её выдаче.
Поделите это число на число статей набора, которые есть в базе.

Пример. В наборе 20 статей, в базе нашлись 19, строка вернула 17 из них. Относительная полнота равна 17 из 19, около 89%. Две пропущенные статьи смотрят отдельно: допустим, в обеих вместо «complication» стоит «morbidity». Термин добавляют в блок исходов, строку перезапускают и считают полноту заново.

Оптимальный размер набора не установлен. В работах по разработке поисковых фильтров он составлял от 15 до 1347 статей; общий принцип такой: чем набор больше, тем надёжнее оценка, а по двум-трём статьям о полноте судить нельзя (Lagisz и соавт., 2025). Общепринятого порога, после которого строку можно больше не улучшать, тоже нет.

Ещё три проверки полезны на практике:

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

Объединённая выдача и удаление дублей

Поиск в нескольких базах и сервисах приносит одни и те же статьи по нескольку раз: запись из PubMed есть в OpenAlex, та же работа приходит из Semantic Scholar. Дубли раздувают скрининг и искажают числа в блок-схеме PRISMA, поэтому их удаляют до отбора и указывают способ удаления в отчёте.

Одна и та же статья в разных источниках выглядит по-разному:

DOI есть не везде, а где есть, может отличаться регистром или префиксом https://doi.org/;
заголовок встречается с другой пунктуацией, в переводе или с опечаткой импорта;
список авторов где-то полный, где-то сокращён до первого автора и «и др.»;
год, том и страницы расходятся между источниками.

Надёжная процедура идёт в два прохода. Сначала записи сверяют по сильным идентификаторам (DOI, PMID). Затем оставшиеся сравнивают нечётко по нормализованным заголовку, первому автору и году, а спорные пары просматривает человек. Сервисы, которые сами объединяют несколько баз, частично делают это за вас: Elicit, например, сводит записи Semantic Scholar, PubMed и OpenAlex в один корпус без дублей. Но итоговое число уникальных записей для отчёта всё равно считается по вашей собственной сводной выгрузке.

Где у поиска по смыслу границы

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

Ограничения выдачи. Смысловой поиск часто отдаёт только верх списка: OpenAlex возвращает до 50 результатов на запрос, Elicit в описании своей методики указывает, что берёт в дальнейший разбор 500 самых релевантных статей (Elicit Help Center). Всё, что ниже этой границы, вы не увидите.

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

Отрицания и числа. Условия вроде «кроме детей» или «выборка больше 100 человек» векторный поиск учитывает плохо. Их проверяют при отборе.

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

Частые вопросы

Какая нейросеть ищет научные статьи по смыслу? Искать по смыслу умеют семантический поиск OpenAlex (через API), Elicit, Consensus, Find Papers в Asta от Ai2 и Undermind. Поиск Semantic Scholar, по описанию разработчиков 2023 года, работает по словам с пересортировкой моделью машинного обучения, а смысловые векторы использует для рекомендаций похожих статей. Сравнение сервисов по цене и поддержке русского языка есть в статье «Elicit и Consensus на русском: чем заменить».

Можно ли заменить булев поиск в систематическом обзоре поиском через нейросеть? Пока нет. В проверке 2025 года на четырёх обзорах Elicit нашёл в среднем 39,5% включённых исследований против 94,5% у полного исходного поиска (несколько баз и поиск по цитированиям), хотя доля релевантных записей в выдаче Elicit была выше (41,8% против 7,55%). Смысловой поиск используют для разведки темы и как дополнительный метод.

Как описать поиск через ИИ-сервис в методах обзора? Укажите название сервиса, точный текст запроса, дату поиска и число найденных записей, а сам поиск отнесите к пункту 7 PRISMA-S «Другие методы». Сохраните выгрузку результатов, потому что повторный запуск после обновления сервиса может дать другой список.

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

Находят ли ИИ-поисковики русскоязычные статьи? Частично. Поддержка русского языка у сервисов разная, а модель семантического поиска OpenAlex рассчитана на английский. Для тем, где важна русскоязычная литература, нужен отдельный поиск в КиберЛенинке и eLibrary с русскими терминами.

Источники

Попробуйте Нейросинт на своём обзоре.

Начать бесплатно →