Benchmark Qdrant Supernova: recall no FineWeb-10B não é relevância

O que um benchmark Qdrant Supernova pode realmente provar

Um benchmark Qdrant Supernova pode dizer se um sistema vetorial reproduz uma classificação de vizinhos definida sob condições conhecidas. Isso é útil. Também é mais estreito do que muitas equipes gostariam que fosse.

A recall de vizinhos exatos não é relevância humana, e não é correção da resposta. Com o FineWeb-10B, o trabalho sério começa antes de qualquer comparação de bases de dados. É preciso definir a carga de trabalho, preservar sua identidade e tornar a regra de pontuação auditável. Caso contrário, o benchmark se torna uma forma polida de comparar experiências incompatíveis.

Aqui está o problema prático. Um sistema de recuperação pode devolver as passagens mais próximas de uma incorporação da pergunta e ainda assim deixar escapar a passagem que responde à pergunta. A classificação pode ser fiel ao espaço de embeddings enquanto a aplicação dá ao usuário uma resposta fraca. Isso não é uma pequena ressalva. É a linha entre um benchmark vetorial e uma avaliação RAG.

Fidelidade de vizinhos, relevância humana e correção da resposta

Trate estes como alvos diferentes.

A recall de vizinhos mede a concordância com uma referência exata para uma representação, métrica, filtro e cutoff especificados. A relevância humana pergunta se o material recuperado ajuda com a necessidade de informação. A correção da resposta pergunta se a resposta final é precisa e apoiada pela evidência recuperada.

O anúncio de lançamento da Qdrant informa 10,07B vetores densos e 10,07B vetores esparsos. O cartão do FineWeb-10B descreve referências top-1000 exatas e 100.000 consultas densas, além de conjuntos de consultas esparsas e filtradas separados. Esses números são informados pelo publicador. Não são medições da Optijara.

Por que isto é um método, não uma tabela de classificação de bases de dados

A Optijara não baixou o corpus completo nem executou um benchmark completo ou por shard para este artigo. Este é um desenho experimental, não um relatório de resultados.

O anúncio fornece a escala. O cartão do conjunto de dados define os dados. O guia de recall explica a semântica de pontuação. Este artigo conecta essas fontes em experiências delimitadas e em um plano separado de validação em produção. Ele não reivindica originalidade exaustiva. Para a questão relacionada de seleção de modelos, veja o teste de aceitação de recuperação por embeddings.

Mapeie módulos Supernova para artefatos de benchmark

A tabela de módulos

O repositório Supernova e a documentação de módulos vinculada descrevem este ciclo de vida. O ponto principal é tratar cada checkpoint como evidência a reter, não como um comando que você executou uma vez e esqueceu.

Fixe a documentação antes de copiar comandos

A página inicial da documentação e o repositório expõem diferentes gerações de comandos. Escolha um commit, use essa documentação e depois inspecione a ajuda da CLI instalada. A lista de instalação no README raiz não prova que nova-bf esteja instalado. Nenhum comando executável neste artigo foi testado quanto à instalação.

O suporte a backends também exige cuidado. O guia de carregamento documenta comportamento de retomada específico da Qdrant. O guia de recall documenta relato de empates específico da Qdrant. Suporte para consultar várias bases de dados não significa que todos os recursos se comportem da mesma forma em todos os lugares.

A Escada de Fidelidade de Benchmark: construa primeiro a menor experiência válida

A Escada de Fidelidade de Benchmark é o método editorial proposto pela Optijara, não um padrão de benchmark estabelecido. Seus degraus são um shard delimitado, uma referência exata desse shard, cargas de trabalho correspondentes, condições operacionais comparáveis e consultas de produção julgadas separadamente.

A versão opinativa é simples: não escale uma experiência ruim. Um benchmark pequeno com identidade limpa supera um benchmark grande com joins ocultos, aritmética desconhecida, estado de cache vago e pontuação pouco clara.

Delimite o corpus e preserve sua identidade

Comece com uma lista de arquivos imutável e um conjunto de consultas fixo. Não dependa do que um leitor em streaming por acaso encontrar primeiro. Registre IDs de origem preservados, sementes de seleção, dimensões, normalização, dtype, métrica de distância, cutoff solicitado, tokenizer, regras de filtro e política de empates.

Gere fingerprints separados para arquivos do corpus, vetores de consulta e configurações. Checksums de texto de consulta não estabelecem igualdade de embeddings, como alerta o cartão do FineWeb-10B. Uma consulta pode ter o mesmo texto e um vetor diferente se a revisão do modelo, o tokenizer, a normalização ou o código remoto mudaram.

A análise de reprodutibilidade do OpenBind cobre a lacuna relacionada entre um rótulo de benchmark e a validade no mundo real. Aqui, o manifesto tem uma função: tornar recuperável o corpus realmente pesquisado.

Recalcule a referência exata para esse shard

Não filtre uma lista top-1000 publicada de corpus completo para IDs presentes no seu shard e a chame de ground truth exato do shard. Esse atalho perde vizinhos que são válidos dentro do shard, mas nunca apareceram na lista global truncada.

Recalcule a referência exatamente sobre o corpus e os vetores de consulta selecionados, usando a métrica e os filtros escolhidos. Mantenha a configuração de geração junto da referência. Um arquivo chamado ground truth não basta. Você precisa saber como suas pontuações foram produzidas.

Faça as cargas de trabalho corresponderem antes de adicionar perguntas de produção

Use esta checklist de implementação antes de aumentar a escala. Cada linha deve deixar um artefato inspecionável.

Desenhe uma matriz de testes que separe recall, relevância e operações

Experiências FineWeb densas, esparsas e filtradas

O cartão do FineWeb-10B especifica vetores densos de norma unitária, que sustentam classificação por cosseno ou produto escalar equivalente. Ele também especifica pesos esparsos não normalizados avaliados com produto escalar. Preserve essas condições. Classificações exatas densas e esparsas independentes não são ground truth para uma regra de fusão híbrida.

O guia de força bruta define correspondência de texto como comportamento AND de tokens de palavras em minúsculas, não busca por frase. Faça corresponder tokenização, lógica booleana, limites de datas, tratamento de nulos e semântica de associação. Um campo chamado keyword_phrase não substitui a operação documentada.

Extensão multi-vetor opcional com corpus correspondente

PubMed-MV fornece representações densas, esparsas e por vetores de token sobre os mesmos resumos. Use sua definição documentada de MaxSim em uma experiência delimitada separadamente. Não compare seus resultados principais diretamente com o FineWeb nem leia fidelidade de vizinhos como relevância clínica.

Coyo-VE é outra carga de trabalho distinta. Seu cartão especifica embeddings e legendas, não bytes de imagem. Nenhum dos conjuntos de dados acompanhantes permite pular a identidade de corpus, consulta e representação.

Condições justas de carregamento e consulta

Fixe hardware, versões de backend, replicação, quantização, configurações de índice, índices de filtro, concorrência e mix de consultas. Defina explicitamente protocolos de cache frio e quente. Uma repetição de execução não especificada não é uma política de cache representativa.

Se um modelo de linguagem local consumir as passagens recuperadas, mantenha seu dispositivo e avaliação de runtime separados dos tempos do motor vetorial. O teste de realidade de implantação do MiniCPM5-2B cobre essa questão adjacente de implantação, não o desempenho de busca do FineWeb.

O guia de carregamento distingue indexação pós-upload da contabilização inline de ingestão mais índice do Elasticsearch. Como resultado, index_seconds sozinho não é um relógio justo entre backends. Meça o caminho completo desde a configuração até a mesma condição pronta para consulta, enquanto retém fases específicas do backend.

Use um plano de medição que mantenha denominadores e falhas visíveis:

Para uma experiência RAG apoiada por Claude, congele o identificador do modelo, o prompt, a ordem das passagens recuperadas e as configurações de geração. Salve IDs de passagens e URLs de origem com cada resposta. Julgue se as citações sustentam as alegações e se a exceção solicitada foi respondida. Registre latência de recuperação e geração separadamente. Rotule isto como uma experiência de aplicação, não como um resultado nova-storm.

O que as equipes erram ao medir recall com nova-storm

Cutoff errado, listas curtas e tratamento desigual de empates

Encontrar um ID top-10 retornado em qualquer lugar de uma referência top-1000 não é recall@10. Recall@10 compara a classificação retornada com o cutoff exato correspondente. O guia atual de recall trunca ground truth mais profundo para top_k e identifica a semântica alterada com schema_version: 2. Reconcilie definições antes de combinar rastros legados e atuais.

Relate consultas com referência curta separadamente das consultas de profundidade total e especifique a política de denominador. Preserve casos sem resultados como testes operacionais. Uma média combinada sem tamanhos de grupo oculta qual carga de trabalho foi realmente avaliada.

Também separe recall de ID exato de limites tolerantes a empates. Comparar o resultado ajustado por empates da Qdrant com o resultado apenas exato de outro backend altera a regra de pontuação. Não é meramente uma diferença de base de dados.

Erros de precisão e carregamento disfarçados de diferenças de busca

Há um conflito de proveniência não resolvido: o cartão do FineWeb-10B descreve aritmética de ground truth em bfloat16, enquanto a documentação atual de recall diz que nova-bf não tem modo de computação bf16/fp16. Solicite a revisão de tempo de geração e o manifesto aritmético. Não invente uma reconciliação nem diagnostique um bug de base de dados a partir dessa discrepância.

Distinga IDs duplicados, texto duplicado, embeddings duplicados e pontuações empatadas. O cartão FineWeb upstream descreve deduplicação em nível de crawl, não remoção global garantida de duplicatas.

Antes de ajustar um índice, inspecione arquivos ignorados, formas de ID, identidade de vetores de consulta, métrica e filtragem. O cartão do FineWeb-10B observa formas diferentes de identificadores de corpus e referência. Um join fracassado sem explicação é um bloqueador de integridade de dados, não uma oportunidade de ajuste ANN.

Ressalvas, direitos de consulta e critérios de parada por recursos

Revise licenças de código, corpus, consulta e modelo separadamente

O repositório Supernova declara Apache-2.0. O FineWeb upstream especifica ODC-By e termos adicionais do Common Crawl. O cartão do modelo gte-multilingual-base declara Apache-2.0 e inclui exemplos dependentes de código remoto. Nada disso concede permissão ampla para toda entrada.

Os termos do MS MARCO da Microsoft especificam uso não comercial em pesquisa. Revise direitos de consulta antes de adotar a carga de trabalho publicada. Consultas próprias adequadamente permitidas criam uma experiência rotulada separadamente, não um benchmark oficial inalterado. Conjuntos de dados acompanhantes precisam de sua própria revisão de direitos upstream.

Fixe modelo, tokenizer e código remoto. Observar uma revisão atual do repositório não prova qual revisão gerou artefatos publicados. Proveniência de geração ausente limita reivindicações de reprodutibilidade mesmo quando os arquivos são publicamente baixáveis.

Pare antes que uma amostra inválida se torne uma execução cara

Defina tetos específicos do projeto para gastos, tempo decorrido, bytes baixados, disco, RAM do host e memória de GPU antes da execução. Pare ao atingir um teto, diante de falha persistente de carregamento, join de ID fracassado, comportamento de filtro divergente ou incompatibilidade de referência inexplicada. Salve o motivo da parada. Não reduza silenciosamente a carga de trabalho e mantenha o rótulo original.

Um shard com cache quente não pode estabelecer custo de corpus completo ou latência de cauda. Avaliações posteriores devem incluir esforço de implementação, transferência, construção de índice, variação de provedor e hardware, estado ou obsolescência de cache, qualidade de avaliação e operações contínuas. Minimize dados de consultas privadas e mantenha-os fora de artefatos públicos.

Publique um registro de reprodutibilidade, não um vencedor

Um resumo compacto legível por máquina

Este resumo descreve a experiência proposta. Observações nulas são deliberadas: nenhum benchmark ou medição de custo foi realizado.

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

Entregue o manifesto imutável, a configuração versionada, a reconciliação de carregamento, os timestamps de prontidão e os rastros de requisições juntos. Inclua semântica de recall, diagnósticos de empates, grupos de consultas, distribuições de latência, falhas, contabilização de recursos e julgamentos humanos separados.

O que testar em seguida

Primeiro, estabeleça uma referência delimitada confiável. Depois compare condições operacionais correspondentes. Em seguida, pergunte se consultas de produção permitidas recuperam evidência útil e se respostas downstream usam essa evidência corretamente. Uma amostra válida justifica a próxima experiência. Ela não justifica uma alegação de desempenho de corpus completo.