Benchmark Qdrant Supernova : le rappel FineWeb-10B n'est pas la pertinence

Ce qu'un benchmark Qdrant Supernova peut réellement prouver

Un benchmark Qdrant Supernova peut vous dire si un système vectoriel reproduit un classement de voisins défini dans des conditions connues. C'est utile. C'est aussi plus étroit que ce que beaucoup d'équipes voudraient obtenir.

Le rappel des voisins exacts n'est pas la pertinence humaine, et ce n'est pas l'exactitude des réponses. Avec FineWeb-10B, le travail sérieux commence avant toute comparaison de bases de données. Vous devez définir la charge de travail, préserver son identité et rendre la règle de notation vérifiable. Sinon, le benchmark devient une façon soignée de comparer des expériences qui ne correspondent pas.

Voici le problème pratique. Un système de recherche peut renvoyer les passages les plus proches de l'embedding d'une question tout en manquant le passage qui répond à cette question. Le classement peut être fidèle à l'espace d'embedding alors que l'application donne à l'utilisateur une réponse faible. Ce n'est pas une petite réserve. C'est la limite entre un benchmark vectoriel et une évaluation RAG.

Fidélité des voisins, pertinence humaine et exactitude des réponses

Traitez ces éléments comme des objectifs différents.

Le rappel des voisins mesure l'accord avec une référence exacte pour une représentation, une métrique, un filtre et un seuil précisés. La pertinence humaine demande si le matériau récupéré aide à satisfaire le besoin d'information. L'exactitude des réponses demande si la réponse finale est exacte et étayée par les preuves récupérées.

L'annonce de publication de Qdrant rapporte 10,07 Md de vecteurs denses et 10,07 Md de vecteurs creux. La fiche FineWeb-10B décrit des références top-1000 exactes et 100 000 requêtes denses, ainsi que des ensembles de requêtes creuses et filtrées distincts. Ces chiffres sont rapportés par l'éditeur. Ce ne sont pas des mesures Optijara.

Pourquoi c'est une méthode, pas un classement de bases de données

Optijara n'a pas téléchargé le corpus complet ni exécuté un benchmark complet ou par fragment pour cet article. Il s'agit d'une conception expérimentale, pas d'un rapport de résultats.

L'annonce donne l'échelle. La fiche du jeu de données définit les données. Le guide du rappel explique la sémantique de notation. Cet article relie ces sources en expériences bornées et en plan de validation de production distinct. Il ne revendique pas une originalité exhaustive. Pour la question connexe du choix de modèle, consultez le test d'acceptation de récupération par embeddings.

Relier les modules Supernova aux artefacts de benchmark

Le tableau des modules

Le dépôt Supernova et la documentation de module liée décrivent ce cycle de vie. L'essentiel est de traiter chaque point de contrôle comme une preuve à conserver, pas comme une commande exécutée une fois puis oubliée.

Verrouiller la documentation avant de copier des commandes

La page d'accueil de la documentation et le dépôt exposent différentes générations de commandes. Choisissez un commit, utilisez cette documentation, puis inspectez l'aide de la CLI installée. La liste d'installation du README racine ne prouve pas que nova-bf est installé. Aucune commande exécutable dans cet article n'a été testée à l'installation.

Le support backend exige aussi de l'attention. Le guide de chargement documente le comportement de reprise propre à Qdrant. Le guide du rappel documente le signalement des égalités propre à Qdrant. Le support de requête pour plusieurs bases de données ne signifie pas que chaque fonctionnalité se comporte de la même manière partout.

Le Benchmark Fidelity Ladder : construire d'abord la plus petite expérience valide

Le Benchmark Fidelity Ladder est la méthode éditoriale proposée par Optijara, pas une norme de benchmark établie. Ses échelons sont un fragment borné, une référence exacte de fragment, des charges de travail alignées, des conditions opérationnelles comparables et des requêtes de production jugées séparément.

La version assumée est simple : ne mettez pas à l'échelle une mauvaise expérience. Un petit benchmark avec une identité propre vaut mieux qu'un grand benchmark avec des jointures cachées, une arithmétique inconnue, un état de cache vague et une notation floue.

Borner le corpus et préserver son identité

Commencez par une liste de fichiers immuable et un ensemble de requêtes fixe. Ne dépendez pas de ce qu'un lecteur en streaming rencontre en premier. Enregistrez les ID source préservés, les graines de sélection, les dimensions, la normalisation, le dtype, la métrique de distance, le seuil demandé, le tokenizer, les règles de filtrage et la politique d'égalité.

Empreintez séparément les fichiers du corpus, les vecteurs de requête et les configurations. Les sommes de contrôle du texte des requêtes n'établissent pas l'égalité des embeddings, comme l'avertit la fiche FineWeb-10B. Une requête peut avoir le même texte et un vecteur différent si la révision du modèle, le tokenizer, la normalisation ou le code distant a changé.

L'analyse de reproductibilité OpenBind couvre l'écart connexe entre une étiquette de benchmark et la validité en conditions réelles. Ici, le manifeste a une seule mission : rendre récupérable le corpus réellement recherché.

Recalculer la référence exacte pour ce fragment

Ne filtrez pas une liste top-1000 publiée pour le corpus complet sur les ID présents dans votre fragment en l'appelant vérité terrain exacte du fragment. Ce raccourci perd des voisins valides dans le fragment mais absents de la liste globale tronquée.

Recalculez la référence sur exactement le corpus sélectionné et les vecteurs de requête choisis, avec la métrique et les filtres retenus. Conservez la configuration de génération à côté de la référence. Un fichier nommé vérité terrain ne suffit pas. Vous devez savoir comment ses scores ont été produits.

Aligner les charges de travail avant d'ajouter des questions de production

Utilisez cette checklist de mise en oeuvre avant d'augmenter l'échelle. Chaque ligne doit laisser un artefact inspectable.

Concevoir une matrice de tests qui sépare rappel, pertinence et opérations

Expériences FineWeb denses, creuses et filtrées

La fiche FineWeb-10B précise des vecteurs denses à norme unitaire, qui prennent en charge un classement par cosinus ou produit scalaire équivalent. Elle précise aussi des poids creux non normalisés évalués par produit scalaire. Préservez ces conditions. Des classements exacts denses et creux indépendants ne sont pas une vérité terrain pour une règle de fusion hybride.

Le guide de force brute définit la correspondance textuelle comme un comportement AND de mots-tokens en minuscules, pas comme une recherche d'expression. Alignez la tokenisation, la logique booléenne, les bornes de dates, la gestion des valeurs nulles et la sémantique d'appartenance. Un champ nommé keyword_phrase ne remplace pas l'opération documentée.

Extension multi-vectorielle optionnelle à corpus aligné

PubMed-MV fournit des représentations denses, creuses et en vecteurs de tokens sur les mêmes résumés. Utilisez sa définition documentée de MaxSim dans une expérience bornée séparément. Ne comparez pas directement ses résultats principaux avec FineWeb et ne lisez pas la fidélité des voisins comme de la pertinence clinique.

Coyo-VE est une autre charge de travail distincte. Sa fiche précise des embeddings et des légendes, pas des octets d'image. Aucun jeu de données compagnon ne vous permet d'ignorer l'identité du corpus, des requêtes et de la représentation.

Conditions équitables de chargement et de requête

Fixez le matériel, les versions backend, la réplication, la quantification, les paramètres d'index, les index de filtres, la concurrence et le mélange de requêtes. Définissez explicitement les protocoles de cache froid et chaud. Une répétition non spécifiée n'est pas une politique de cache représentative.

Si un modèle de langage local consomme les passages récupérés, gardez son appareil et son runtime d'évaluation séparés des mesures du moteur vectoriel. Le test de réalité du déploiement MiniCPM5-2B couvre cette question de déploiement adjacente, pas les performances de recherche FineWeb.

Le guide de chargement distingue l'indexation après téléversement de la comptabilité ingestion-plus-indexation en ligne d'Elasticsearch. Par conséquent, index_seconds seul n'est pas une horloge équitable entre backends. Mesurez le parcours complet depuis la configuration jusqu'à la même condition prête pour les requêtes, tout en conservant les phases propres au backend.

Utilisez un plan de mesure qui garde les dénominateurs et les échecs visibles :

Pour une expérience RAG soutenue par Claude, figez l'identifiant du modèle, le prompt, l'ordre des passages récupérés et les paramètres de génération. Sauvegardez les ID de passages et les URL sources avec chaque réponse. Jugez si les citations étayent les affirmations et si l'exception demandée a reçu une réponse. Enregistrez séparément la latence de récupération et de génération. Étiquetez cela comme une expérience d'application, pas comme un résultat nova-storm.

Ce que les équipes mesurent mal avec le rappel nova-storm

Mauvais seuil, listes courtes et traitement inégal des égalités

Trouver un ID top-10 renvoyé n'importe où dans une référence top-1000 n'est pas du recall@10. Le recall@10 compare le classement renvoyé avec le seuil exact correspondant. Le guide de rappel actuel tronque la vérité terrain plus profonde à top_k et identifie la sémantique modifiée avec schema_version: 2. Réconciliez les définitions avant de combiner des traces anciennes et actuelles.

Rapportez séparément les requêtes à référence courte et les requêtes en profondeur complète, et précisez la politique de dénominateur. Préservez les cas sans résultat comme tests opérationnels. Une moyenne combinée sans tailles de groupe masque la charge de travail réellement évaluée.

Séparez aussi le rappel par ID exact des bornes tolérantes aux égalités. Comparer le résultat ajusté pour égalités de Qdrant avec le résultat exact seulement d'un autre backend change la règle de notation. Ce n'est pas seulement une différence de base de données.

Erreurs de précision et de chargement déguisées en différences de recherche

Il existe un conflit de provenance non résolu : la fiche FineWeb-10B décrit une arithmétique de vérité terrain en bfloat16, tandis que la documentation actuelle du rappel indique que nova-bf n'a pas de mode de calcul bf16/fp16. Demandez la révision de génération et le manifeste arithmétique. N'inventez pas de réconciliation et ne diagnostiquez pas un bogue de base de données à partir de cet écart.

Distinguez les ID dupliqués, le texte dupliqué, les embeddings dupliqués et les scores ex aequo. La fiche FineWeb amont décrit une déduplication au niveau du crawl, pas une garantie de suppression globale des doublons.

Avant d'ajuster un index, inspectez les fichiers ignorés, les formes d'ID, l'identité des vecteurs de requête, la métrique et le filtrage. La fiche FineWeb-10B note des formes d'identifiants différentes pour le corpus et les références. Une jointure échouée et inexpliquée est un blocage d'intégrité des données, pas une occasion de réglage ANN.

Réserves, droits sur les requêtes et critères d'arrêt des ressources

Examiner séparément les licences du code, du corpus, des requêtes et du modèle

Le dépôt Supernova déclare Apache-2.0. FineWeb amont précise ODC-By et des conditions Common Crawl supplémentaires. La fiche du modèle gte-multilingual-base déclare Apache-2.0 et inclut des exemples dépendants du code distant. Aucun de ces éléments n'accorde une autorisation générale pour chaque entrée.

Les conditions MS MARCO de Microsoft précisent une utilisation de recherche non commerciale. Examinez les droits sur les requêtes avant d'adopter la charge de travail publiée. Des requêtes propriétaires correctement autorisées créent une expérience étiquetée séparément, pas un benchmark officiel inchangé. Les jeux de données compagnons nécessitent leur propre examen des droits amont.

Verrouillez le modèle, le tokenizer et le code distant. Observer une révision actuelle du dépôt ne prouve pas quelle révision a généré les artefacts publiés. Une provenance de génération manquante limite les revendications de reproductibilité même lorsque les fichiers sont téléchargeables publiquement.

S'arrêter avant qu'un échantillon invalide devienne une exécution coûteuse

Fixez des plafonds propres au projet pour les dépenses, le temps écoulé, les octets téléchargés, le disque, la RAM hôte et la mémoire GPU avant l'exécution. Arrêtez-vous à un plafond, à un échec de chargement persistant, à une jointure d'ID échouée, à un comportement de filtre divergent ou à une discordance de référence inexpliquée. Sauvegardez la raison de l'arrêt. Ne réduisez pas silencieusement la charge de travail en conservant l'étiquette originale.

Un fragment avec cache chaud ne peut pas établir le coût du corpus complet ni la latence de queue. Les évaluations ultérieures doivent inclure l'effort de mise en oeuvre, le transfert, la construction de l'index, la variance des fournisseurs et du matériel, l'état ou l'obsolescence du cache, la qualité d'évaluation et les opérations continues. Minimisez les données de requêtes privées et gardez-les hors des artefacts publics.

Publier un dossier de reproductibilité, pas un vainqueur

Un résumé compact lisible par machine

Ce résumé décrit l'expérience proposée. Les observations nulles sont délibérées : aucun benchmark ni mesure de coût n'a été effectué.

{
  "framework": "Benchmark Fidelity Ladder",
  "scope": "proposed_bounded_experiment",
  "fullCorpusRun": false,
  "benchmarkExecuted": false,
  "recomputeGroundTruthForShard": true,
  "neighborRecallIsHumanRelevance": false,
  "humanRelevanceIsAnswerCorrectness": false,
  "observedRecall": null,
  "observedP95Ms": null,
  "observedCost": null
}

Transmettez ensemble le manifeste immuable, la configuration versionnée, le rapprochement de chargement, les horodatages de disponibilité et les traces de requêtes. Incluez la sémantique du rappel, les diagnostics d'égalité, les groupes de requêtes, les distributions de latence, les échecs, la comptabilité des ressources et les jugements humains distincts.

Ce qu'il faut tester ensuite

D'abord, établissez une référence bornée fiable. Ensuite, comparez des conditions opérationnelles alignées. Après cela, demandez si les requêtes de production autorisées récupèrent des preuves utiles et si les réponses en aval utilisent correctement ces preuves. Un échantillon valide justifie l'expérience suivante. Il ne justifie pas une affirmation de performance sur le corpus complet.