Организация доступа к исследованиям в области искусственного интеллекта требует надежной поисковой системы. Современный поиск на papers with code помогает разработчикам и автономным агентам быстро находить профильные научные работы через веб-интерфейс или специальную командную строку pwc search CLI, которую агенты задействуют посредством навыков (Skill). Поиск научной литературы существенно отличается от работы с обычным текстом. Качественная поисковая машина должна безошибково находить публикации по точному названию или идентификатору arXiv, а также корректно обрабатывать сложные запросы вроде «small language models for code generation», даже если эти слова не стоят рядом в тексте статьи. Система обязана распознавать запрос «the original BERT paper» как навигационный, справляться с опечатками и неполными названиями, а также сохранять высокую скорость ответа даже в ситуациях, когда модель работает «холодной» или временно недоступна.

Для проекта Papers with Code разработчики реализовали гибридную поисковую архитектуру. Этот подход опирается на практический опыт специалистов ML6 в создании систем на базе RAG (Retrieval-Augmented Generation) для коммерческих заказчиков. Как правило, гибридный поиск превосходит чисто текстовые или векторные решения по отдельности, объединяя сильные стороны обоих подходов. Классический поиск по ключевым словам гарантирует точные вхождения терминов, тогда как векторный поиск отвечает за поиск нечетких, семантически близких понятий. Использование реранкеров, также известных как кросс-энкодеры, способно дополнительно повысить качество выдачи, хотя это неизбежно влечет за собой дополнительные накладные расходы и рост задержки (латентности).

Архитектура гибридного поиска

В основе инфраструктуры лежит СУБД PostgreSQL, возможности полнотекстового поиска которой обеспечивают быструю лексическую базу. Для работы с плотными эмбеддингами применяется расширение pgvector, добавляющее семантическую составляющую, а алгоритм ранжирования Reciprocal Rank Fusion (RRF) объединяет оба потока данных. Для генерации плотных векторов задействованы три сервиса от Hugging Face:

• Hugging Face Jobs предоставляет масштабируемые вычислительные мощности графических процессоров (GPU) для обработки всего массива научных публикаций.
• Hugging Face Storage Buckets отвечает за стабильную передачу данных между базой данных, экспериментами и фоновыми задачами.
• Hugging Face Inference Endpoints обслуживает низколатентные эмбеддинги для обработки живых запросов и инкрементальных обновлений.

В настоящее время система поддерживает актуальные векторы для более чем 110 тысяч научных работ, поступающих из репозиториев arXiv и Daily Papers. Проект разделяет поисковый процесс на автономную подготовку массива данных (offline corpus build) и онлайн-обслуживание запросов (online search service). Ресурсоемкие операции с упором на пропускную способность выполняются через фоновые задачи Jobs. Готовые артефакты хранятся в защищенном хранилище Bucket. На пути пользовательского запроса находится исключительно легковесный этап генерации векторного представления, работающий через защищенную конечную точку Inference Endpoint. Если этот эндпоинт оказывается перегружен, работает вхолощую или временно недоступен, поиск автоматически переключается на стандартный полнотекстовый режим. Такое разделение делает систему одновременно отказоустойчивой и быстрой.

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

• используемый репозиторий модели и точная ревизия;
• размерность выходного вектора;
• версия формата входных данных;
• тип входной сущности (запрос или документ);
• метод нормализации;
• криптографический хеш содержимого исходного названия и аннотации.

В продакшене используется модель Qwen/Qwen3-Embedding-0.6B, закрепленная за конкретной ревизией, с 256-мерными L2-нормализованными векторами. Данная модель была отобрана с помощью бенчмарка MTEB leaderboard, который служит основным ориентиром для сравнения подобных решений. Новейшие архитектуры эмбеддингов, включая семейство Qwen3, поддерживают две новые функциональные возможности. В частности, они позволяют указывать динамический размер эмбеддинга, гибко балансируя между качеством и затратами на скорость вычислений и объем хранения. В экосистеме Qwen эта технология известна под аббревиатурой MRL, что означает Matryoshka Representation Learning (обучение матрёшечных представлений).

Qwen/Qwen3-Embedding-0.6B

Технические подробности реализации доступны по соответствующей ссылке. Для обеспечения высокой скорости поиска разработчики остановились на размере эмбеддинга, равном 256. Модели эмбеддингов Qwen поддерживают два типа подсказок (промптов): документный промпт, применяемый для встраивания научных работ, и поисковый промпт для обработки пользовательских запросов в реальном времени. Этот единый конвейер охватывает весь путь данных: от экспорта эмбеддингов через графический процессор (GPU) до базы данных PostgreSQL и последующего онлайн-поиска.

Создание эмбеддингов для всего корпуса документов представляет собой классическую пакетную задачу (batch workload). Такой процесс требует графического ускорителя на сравнительно короткое время, отличается высокой пропускной способностью и не должен потреблять ресурсы в периоды между запусками. Инструмент Hugging Face Jobs оптимально подходит под эти критерии: задача задается с помощью команды, конфигурации оборудования и опционального Docker-образа, а также поддерживает выполнение скриптов uv со встроенными зависимостями.

Процесс построения корпуса начинается с экспорта актуальной версии каждой научной работы на основе снимка базы данных PostgreSQL с изолированным уровнем транзакций (repeatable-read). Модуль экспорта потоково передает строки вместо того, чтобы загружать весь каталог в оперативную память, записывает данные в виде ограниченных по размеру JSONL-фрагментов и формирует манифест с количеством строк и контрольными суммами SHA-256. Затем эта неизменяемая директория запускных файлов синхронизируется с приватным хранилищем Storage Bucket и монтируется напрямую с помощью утилиты hf-mount в рабочую среду задания l4x1, использующую графический процессор NVIDIA L4 с 24 ГБ видеопамяти.

С точки зрения рабочей среды (воркера) это выглядит как обычная файловая система, запускаемая следующей командой:

hf jobs uv run --flavor l4x1 --timeout 6h --volume hf://buckets/OWNER/pwc-paper-embeddings:/bucket embed_papers_job.py --input /bucket/runs/RUN_ID/input --output /bucket/runs/RUN_ID/output --model Qwen/Qwen3-Embedding-0.6B --revision MODEL_REVISION --dimensions 256 --allow-matryoshka

В ходе выполнения воркер выполняет следующие операции:

• проверяет входной манифест и контрольные суммы каждого фрагмента;
• загружает зафиксированную ревизию модели;
• сортирует тексты по длине для минимизации избыточного заполнения (padding);
• вызывает функцию encode_document пакетами, как указано в системной документации модели;
• автоматически уменьшает размер пакета при нехватке видеопамяти на GPU;
• усекает и нормализует представление Matryoshka до 256 измерений;
• атомарно записывает фрагменты в формате Parquet в кодировке float16;
• фиксирует показатели производительности, версии используемых пакетов, характеристики оборудования, пиковое потребление видеопамяти, количество строк и контрольные суммы выходных данных.

Каждый успешно обработанный фрагмент снабжается собственным маркером, благодаря чему перезапущенное задание может пропускать уже проверенную работу. Это критически важно при обработке масштабного массива документов: повторный запуск возобновляет прерванный процесс, а не перезаписывает существующие эмбеддинги. В ходе пилотного тестирования на 5000 научных работ задача Qwen обрабатывала примерно 75 документов в секунду при размерности 1024 на графическом процессоре L4. Тот же проход можно детерминированно воспроизвести для размерностей 512 и 256, что позволяет сопоставить соотношение затрат на хранение и поиск без дополнительных расходов на инференс.

Хранилища Storage Buckets представляют собой изменяемое объектное хранилище на платформе Hub, совместимое с протоколом S3 и оптимизированное под задачи искусственного интеллекта. К ним можно обращаться по путям формата hf://buckets/... и монтировать их в режиме чтения и записи внутри задач без необходимости создавать отдельные интеграции для хранения данных. Для разработчиков такое хранилище выступает не просто местом для складирования векторов, а служит границей между тремя изолированными системами с собственными жизненными циклами:

• производственная база данных экспортирует исходные записи;
• эфеемерные задания обрабатывают эти записи и генерируют векторы;
• модуль импорта проверяет результаты перед обновлением поискового индекса.

Все артефакты структурируются по неизменяемым префиксам запусков:

runs/<run-id>/
├── input/
│ ├── manifest.json
│ └── papers-*.jsonl
└── output/
├── manifest.json
├── embeddings-*.parquet
└── embeddings-*.complete.json

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

Обработка запросов и гибридный поиск

Пакетное создание эмбеддингов закрывает задачу индексации документов, однако пользовательский запрос требует векторного преобразования в момент обращения к системе в рамках того же контрактного соглашения модели. Для этого разворачивается закрепленная версия модели в качестве защищенной конечной точки вычислений Inference Endpoint, работающей на базе движка Text Embeddings Inference (TEI). Эндпоинт принимает текст запроса и возвращает нормализованный 256-мерный вектор, используя специальный промпт модели. Альтернативно здесь также могут применяться такие решения, как vLLM или SGLang.

Далее программный интерфейс выполняет поиск по косинусному расстоянию над активным поколением pgvector:

SELECT paper_id, embedding <=> CAST(:query_vector AS halfvec(256)) AS distance FROM paper_embeddings WHERE generation_id = :active_generation ORDER BY embedding <=> CAST(:query_vector AS halfvec(256)) LIMIT 50;

Индекс HNSW обеспечивает высокую скорость подобных выборок. На тестовой пилотной базе из 5000 научных работ 256-мерный индекс Qwen продемонстрировал метрику Recall@20 на уровне 0.9955 по сравнению с точным поиском, при этом задержка поиска HNSW составила 1.31 мс (p50) и 2.21 мс (p95). Сама таблица и индекс заняли примерно 27% от объема памяти 1024-мерной версии, сохранив при этом сопоставимую точность приближенного поиска соседей (ANN).

Особенности масштабирования и отказоустойчивости эндпоинта

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

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

• жесткий производственный тайм-аут продолжительностью в одну секунду;
• неблокирующее ограничение уровня параллелизма;
• проверка размерности ответа, на конечных значениях и норме векторов;
• краткосрочное кэширование по ключу запроса и поколению эмбеддингов;
• автоматическое срабатывание предохранителя цепи (circuit breaker) после череды неудачных попыток;
• исключение исходного текста запроса из системных журналов с сохранением исключительно нормализованного цифрового отпечатка.

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

Объединение результатов семантического и лексического поиска

В рамках каждого поискового запроса лексическая составляющая извлекает до 50 кандидатов с помощью взвешенного полнотекстового поиска PostgreSQL. Параллельно семантическая ветка извлекает до 50 кандидатов через расширение pgvector. Итоговые позиции ранжирования объединяются методом взвешенного обратного рангового слияния (Reciprocal Rank Fusion — RRF). Этот алгоритм отличается простотой и надежностью, так как оперирует именно позициями в выдаче, а не разномасштабными сырыми баллами из разных систем.

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

Кроме того, система сохраняет детерминированное поведение идентификации поверх объединенного ранжирования: точные названия и идентификаторы arXiv остаются на самом верху; таксономия методов распознает навигационные запросы вроде «оригинальной статьи о BERT»; неполные заголовки и незначительные опечатки используют консервативных триграммных кандидатов; а сомнительные нечеткие совпадения воздерживаются от выдачи, вместо того чтобы навязывать неудачный результат. Стоит отметить, что гибридный поиск не всегда является оптимальным выбором: рекомендуется начинать с ключевых слов в качестве простого и быстрого базового уровня, добавляя семантический или гибридный поиск лишь тогда, когда это действительно дает ощутимый прирост качества извлечения. Качество поиска можно дополнительно повысить за счет интеграции реранкера после ключевого, семантического или гибридного этапа, используя такую модель, как Qwen3-Reranker.

Обширный первоначальный корпус обрабатывается с помощью заданий Jobs, однако платформа Papers with Code постоянно обновляется. Поступают новые научные работы, корректируются аннотации, а новые версии arXiv становятся актуальными. Запуск GPU-задания ради нескольких измененных строк привел бы к избыточным накладным расходам на инициализацию и оркестрацию. Вместо этого ежечасно запускаемый инкрементальный процесс выбирает отсутствующие или изменившиеся по контенту статьи и отправляет ограниченную дельту на ту же конечную точку TEI Endpoint, но на этот раз с использованием промпта для документов. Каждое такое выполнение обрабатывает максимум 500 работ батчами по 16 штук. Перед записью эмбеддинга исходная строка блокируется, а ее хэш содержимого проверяется повторно. Если статья изменилась в процессе инференса, данный вектор отбрасывается и подхватывается следующим запуском.

Такой подход обеспечивает эффективное разделение труда:

• Задания Jobs выполняют полное перепостроение, генерацию новых моделей и масштабное заполнение исторических данных.
• Конечные точки Inference Endpoints обрабатывают интерактивные векторные представления запросов и небольшие инкрементальные обновления документов.
• Хранилища Buckets сохраняют артефакты масштабных сборок, делая этот процесс возобновляемым и прозрачным для аудита.

Ежечасно выполняемый сценарий поддерживает актуальность активного индекса относительно живого каталога, не превращая при этом онлайн-эндпоинт в неконтролируемый пакетный процессор. Те же самые эмбеддинги документов обеспечивают работу рекомендаций похожих статей на каждой странице публикации. Поскольку для исходной работы вектор уже сохранен, поиск связанных материалов не требует обращения к модели в момент запроса. Это всего лишь одиночный запрос поиска ближайших соседей по активному поколению. Если вектор временно отсутствует, приложение может задействовать предыдущую версию arXiv или дополнить результаты с помощью существующих резервных вариантов на основе задач и цитирований.

Данные о цитированиях подгружаются через API Semantic Scholar, а также с помощью утилиты s2-cli — созданного интерфейса командной строки для запросов к графу цитирования Semantic Scholar. Последняя активно используется агентом, доступным по адресу https://paperswithcode.co/chat. Создание эмбеддингов корпуса и эмбеддингов запросов задействуют одну и ту же модель, однако с точки зрения инфраструктуры это две разные задачи. Задания оптимизируются под пропускную способность и контролируемую стоимость, тогда как конечные точки инференса ориентированы на доступность и задержку ответа. Хранилища обеспечивают четкую передачу данных между вычислительной средой и продакшеном. Артефакты с контрольными суммами создают проверяемую границу перед тем, как данные попадут в производственный индекс.

Версия модели, размерность, промпт, нормализация и инструмент форматирования входных данных — все это напрямую влияет на качество поиска. Их необходимо хранить вместе и повсеместно проверять. Масштабирование до нуля полезно при нестабильном трафике, но только в том случае, если в продукте предусмотрен быстрый резервный механизм. Гибридный поиск обеспечил такой резерв естественным образом: лексический поиск всегда полезен сам по себе. Использование матрёшечных эмбеддингов позволяет комплексно оценивать качество, объем памяти, размер индекса и задержку как единый компромиссный параметр. В ходе пилотного тестирования размерность в 256 векторов сохранила полноту аппроксимированного поиска ближайших соседей (ANN recall), при этом существенно сократив объем требуемого хранилища по сравнению с размерностью в 1024 элемента.

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

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

Источник: huggingface.co