Papers with Code : comment l'IA réinvente la recherche scientifique en 3 étapes

UNE RECHERCHE SCIENTIFIQUE DIFFÉRENTE DES AUTRES

Chercher un article scientifique n’est pas comme chercher une recette sur Google. Un bon moteur doit trouver un titre exact ou un identifiant arXiv, mais aussi comprendre une requête comme « petits modèles de langage pour la génération de code » même si ces mots n’apparaissent pas ensemble dans un papier. Il doit reconnaître qu’une recherche sur « l’article original de BERT » est une demande de navigation, tolérer des titres incomplets ou des fautes de frappe, et rester rapide même quand le service est temporairement indisponible. Pour Papers with Code, recherche hybride signifie combiner plusieurs approches pour obtenir le meilleur résultat.

LE SYSTÈME HYBRIDE : MOTS-CLÉS ET VECTEURS SÉMANTIQUES

La recherche par mots-clés trouve les mentions exactes, tandis que la recherche par vecteurs identifie des termes sémantiquement proches. Par exemple, une recherche sur « chatbot » peut aussi retourner des articles sur les « assistants conversationnels » grâce à l’embedding (un vecteur numérique qui représente le sens d’un texte). Les rerankers (ou cross-encoders) améliorent encore les résultats en réévaluant les documents trouvés, mais ils ajoutent de la complexité et du temps de réponse. Papers with Code utilise une base de données PostgreSQL pour la recherche lexicale rapide, pgvector pour les embeddings denses, et un algorithme de fusion de rangs appelé RRF (Reciprocal Rank Fusion) pour combiner les deux approches.

LE MODÈLE D'EMBEDDING : QWEN3 POUR TRANSFORMER LES TEXTES EN VECTEURS

Pour créer ces vecteurs, Papers with Code utilise Qwen/Qwen3-Embedding-0.6B, un modèle d’embedding léger mais puissant. Chaque article est transformé en un vecteur de 256 dimensions grâce à une formule simple : le titre normalisé suivi d’un saut de ligne, puis l’abstract normalisé. Ce format est versionné comme une API : chaque génération de vecteurs est liée à une révision précise du modèle, ce qui évite les problèmes quand un modèle est mis à jour. Le modèle est choisi grâce au MTEB leaderboard, le benchmark de référence pour comparer les modèles d’embedding. Qwen3 permet aussi d’utiliser des embeddings Matryoshka, des vecteurs qui peuvent être réduits à différentes tailles sans perdre leur efficacité, ce qui permet de tester plusieurs dimensions (256, 512, 1024) sans refaire tout le travail d’inférence.

LES JOBS : TRAVAILLER EN BATCH POUR CRÉER UNE BASE DE DONNÉES DE VECTEURS

Créer des embeddings pour des milliers d’articles est une tâche lourde qui nécessite une puissance GPU. C’est là que les Hugging Face Jobs entrent en jeu. Un Job est une tâche batch définie par une commande, un matériel (ici, un GPU NVIDIA L4 avec 24 Go de VRAM), et éventuellement une image Docker. Dans ce cas, le script embedpapersjob.py est exécuté pour transformer chaque article en vecteur. Le processus commence par exporter les articles depuis une base de données PostgreSQL, puis les stocke dans des fichiers JSONL (un format où chaque ligne est un objet JSON). Ces fichiers sont ensuite montés dans un Bucket (un stockage objet comme S3) et utilisés par le Job pour générer les embeddings.

Voici la commande exacte utilisée :

hf jobs uv run \
  --flavor l4x1 \
  --timeout 6h \
  --volume hf://buckets/OWNER/pwc-paper-embeddings:/bucket \
  embedpapersjob.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

Le Job traite chaque fichier d’entrée, génère les embeddings, et les stocke dans des fichiers .parquet (un format efficace pour les données tabulaires) et des fichiers .complete.json (pour vérifier l’intégrité des données). Chaque shard (morceau de données) a un marqueur de complétion, ce qui permet de reprendre le travail en cas d’interruption sans tout recommencer. Lors d’un test sur 5 000 articles, le Job a généré environ 75 embeddings par seconde en 1024 dimensions sur un GPU L4.

LES BUCKETS : LE LIEN ENTRE LES DONNÉES ET LES OUTILS

Les Buckets sont des espaces de stockage objet sur Hugging Face Hub, similaires à S3, optimisés pour les workloads d’IA. Ils permettent de monter directement un stockage dans un Job sans avoir à configurer une intégration séparée. Pour Papers with Code, les Buckets servent de frontière entre trois systèmes aux cycles de vie différents : les Jobs (calcul), la base de données PostgreSQL (stockage structuré), et l’index HNSW (recherche vectorielle).

Les artefacts sont organisés en runs immuables (inchangeables) pour éviter les conflits :

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

Les Buckets sont mutables (modifiables), mais l’immuabilité est gérée au niveau applicatif : un ID de run n’est jamais écrasé, et chaque artefact est vérifié par un manifeste et un checksum (une somme de contrôle pour détecter les modifications). Une fois les embeddings générés, ils sont importés dans PostgreSQL après vérification de leur schéma, de leur checksum, de leur dimension, de leur normalisation, et de leur unicité. Un index HNSW est ensuite construit pour permettre une recherche vectorielle rapide.

LES INFERENCE ENDPOINTS : LA RECHERCHE SEMANTIQUE EN TEMPS RÉEL

Une fois les embeddings stockés, il faut encore transformer la requête de l’utilisateur en vecteur pour effectuer une recherche sémantique. C’est le rôle des Inference Endpoints, des services d’inférence protégés qui exposent le modèle d’embedding via une API. Le modèle est déployé avec Text Embeddings Inference (TEI), une infrastructure optimisée pour les embeddings. L’endpoint accepte le texte de la requête et retourne un vecteur de 256 dimensions, prêt à être utilisé pour la recherche.

La recherche elle-même se fait avec une requête SQL qui calcule la distance cosinus entre le vecteur de la requête et les embeddings des articles :

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

L’index HNSW permet d’effectuer cette recherche en quelques millisecondes. Lors d’un test sur 5 000 articles, l’index en 256 dimensions a atteint un Recall@20 de 0,9955 par rapport à une recherche exacte, avec des latences de 1,31 ms (p50) et 2,21 ms (p95). Le stockage utilisé était 27 % plus petit que pour la version en 1024 dimensions, tout en conservant une qualité de recherche quasi identique.

UN SYSTÈME CONÇU POUR LES DÉFAILLANCES : LE FALLBACK LEXICAL

Les Inference Endpoints sont configurés pour s’adapter à la charge : ils peuvent passer à zéro réplica (zéro instance active) quand il n’y a pas de trafic, ce qui réduit les coûts. Mais cela signifie aussi que le premier utilisateur après une période d’inactivité doit attendre que l’endpoint démarre (cold start). Pour éviter que l’utilisateur attende trop longtemps, le système est conçu pour basculer automatiquement vers la recherche lexicale si l’endpoint est en cours de démarrage, en timeout, ou retourne un vecteur mal formé. Les utilisateurs reçoivent donc toujours des résultats, même si la recherche sémantique n’est pas disponible.

L’endpoint est aussi surveillé via un tableau de bord qui affiche des analytics clés, comme le nombre de requêtes, les latences, et les erreurs.

LA RECHERCHE HYBRIDE : LE MEILLEUR DES DEUX MONDES

Pour chaque requête, le système combine les résultats de la recherche lexicale (jusqu’à 50 candidats) et de la recherche sémantique (jusqu’à 50 candidats) en utilisant l’algorithme RRF. La formule de fusion est simple :

Ici, w_lexical et w_semantic sont les poids des deux branches (actuellement égaux), k est une constante (fixée à 60), et rank est le rang du document dans chaque branche. Si un article est bien classé dans les deux branches, il aura un score plus élevé dans la fusion. La recherche lexicale reste excellente pour les termes exacts, les identifiants, et les noms rares, tandis que la recherche sémantique améliore le rappel pour les requêtes conceptuelles.

Il est possible d’améliorer encore les résultats en ajoutant un reranker après la fusion, comme Qwen3-Reranker, pour réévaluer les documents en fonction de leur pertinence globale.

MISE À JOUR CONTINUE : LES PETITS CHANGEMENTS SANS REFAIRE TOUT

Le corpus initial est généré par des Jobs, mais Papers with Code évolue en permanence : de nouveaux articles arrivent, des abstracts sont corrigés, et de nouvelles versions d’articles sont publiées sur arXiv. Relancer un Job GPU pour quelques articles modifiés serait inefficace. À la place, un processus incrémental s’exécute toutes les heures et sélectionne les articles manquants ou modifiés, puis envoie un delta (un lot de 500 articles maximum) à l’endpoint TEI pour générer les nouveaux embeddings. Chaque article est verrouillé pendant l’inférence, et son checksum est vérifié pour s’assurer qu’il n’a pas changé pendant le traitement. Si un article est modifié pendant l’inférence, son embedding est jeté et repris lors du prochain run.

Ce processus incrémental maintient l’index actif proche du catalogue en direct, sans transformer l’endpoint en un processeur batch non borné.

LES RECOMMANDATIONS DE PAPIERS : GRATUITES GRÂCE AUX EMBEDDINGS

Les mêmes embeddings utilisés pour la recherche servent aussi à recommander des articles similaires sur chaque page de papier. Comme le vecteur de l’article source est déjà stocké, la recommandation ne nécessite aucun appel au modèle en temps réel : c’est une simple requête de plus proche voisin sur l’index actif. Si un vecteur est temporairement manquant, l’application peut utiliser une ancienne version d’arXiv ou se rabattre sur une solution de repli basée sur les citations et les tâches associées. Les données de citation sont récupérées via l’API Semantic Scholar, et un outil en ligne de commande s2-cli a été développé pour interroger son graphe de citations. Cet outil est utilisé par l’agent conversationnel accessible sur https://paperswithcode.co/chat.

6 LEÇONS APPRISES POUR CONSTRUIRE UN SYSTÈME ROBUSTE

1. Séparer les workloads : Les Jobs optimisent le débit et le coût, tandis que les Inference Endpoints optimisent la disponibilité et la latence des requêtes. Les deux ne doivent pas être mélangés.

2. Le stockage comme contrat : Les Buckets fournissent une frontière claire entre le calcul et la production. Les artefacts checksumés créent une barrière vérifiable avant que les données n’entrent dans l’index de production.

3. Épingler plus que le nom du modèle : La révision, la dimension, le prompt, la normalisation et le format d’entrée affectent tous la recherche. Ils doivent être stockés ensemble et validés partout.

4. Concevoir pour les démarrages à froid : Le passage à zéro réplica est utile pour les trafics intermittents, mais seulement si le produit a un fallback rapide. La recherche hybride offre ce fallback naturellement : la recherche lexicale est toujours utile seule.

5. Les petits vecteurs comme fonctionnalité système : Les embeddings Matryoshka permettent d’évaluer la qualité, la mémoire, la taille de l’index et la latence comme un seul compromis. Dans leur pilote, 256 dimensions ont préservé le rappel ANN tout en réduisant significativement le stockage par rapport à 1024 dimensions.

6. L’activation doit être ennuyeuse : Les nouvelles générations sont importées à côté de l’actuelle, indexées indépendamment, vérifiées pour une couverture complète et actuelle, puis activées de manière atomique. Le retour en arrière est un changement de configuration, pas un recomputation d’urgence.

ESSAYEZ VOUS-MÊME : PAPERS WITH CODE EN ACTION

Vous pouvez tester le moteur de recherche de Papers with Code directement sur https://paperswithcode.co, ou discuter avec un agent conversationnel sur https://paperswithcode.co/chat. N’hésitez pas à donner votre avis pour aider à améliorer le système .