Skip to main content
Este relatório compara o mecanismo de recuperação MKA1 com um conjunto de dados padrão de recuperação de informações. Ele demonstra recuperação de nível RAG sob alto volume de documentos — indexando milhares de documentos, executando centenas de consultas rotuladas e medindo precisão e latência em cada etapa do pipeline. O benchmark usa o SciFact da suíte de benchmarks BEIR — 5.183 resumos científicos com 300 consultas de teste e julgamentos de relevância anotados por humanos. Todos os embeddings foram gerados com auto (4.096 dimensões). Foram medidas duas configurações do mecanismo de recuperação:
  • Armazenamento híbrido (“Text Store”): armazenamento sem configuração com recuperação híbrida automática — similaridade vetorial combinada com pesquisa de texto completo.
  • Tabela tipada (“Tables”): um esquema explícito (ID do documento, conteúdo, vetor de 4.096 dimensões) com pesquisa vetorial pura sob distância cosseno.
As aplicações acessam esse mecanismo por meio dos armazenamentos vetoriais da plataforma, que adicionam ingestão de arquivos, fragmentação, tenancy e medição de uso. Os números abaixo medem o próprio mecanismo de recuperação.

​
Resumo dos resultados

Uma consulta de recuperação passa por duas etapas: inferência de embedding (converter o texto da consulta em um vetor) e pesquisa no banco de dados (encontrar os vetores mais próximos no armazenamento). O tempo total de resposta é a soma de ambos. A latência da pesquisa no banco de dados é informada pelo próprio servidor e exclui a sobrecarga de rede e a inferência de embedding. O tempo de resposta ponta a ponta inclui tudo o que um cliente mediria.

​
Metodologia

Conjunto de dados. O corpus completo do SciFact e a divisão de teste: 5.183 resumos científicos, 300 consultas de alegações científicas e os julgamentos oficiais binários de relevância (cada uma das 300 consultas possui rótulos). Embeddings. Cada documento (título + resumo) e cada consulta foram incorporados com o modelo de embedding auto (4.096 dimensões) por meio da API de embeddings da plataforma, em lotes de 64. O embedding do corpus teve média de 8,2 ms por documento; a inferência de embedding de consultas mediu 12 ms por consulta. Indexação. O mesmo corpus e os mesmos embeddings pré-computados foram indexados em ambas as configurações do mecanismo em lotes de 100 documentos. A taxa de indexação foi medida ao longo da execução completa de 5.183 documentos: 182 documentos/seg para o armazenamento híbrido e 166 documentos/seg para a tabela tipada. Execução de consultas. Todas as 300 consultas foram executadas em cada configuração, recuperando os 10 principais resultados. Foram registradas duas latências por consulta: o tempo de pesquisa no banco de dados informado pelo servidor (tempo puro do mecanismo, sem rede) e o tempo de resposta ponta a ponta observado pelo cliente. As tabelas acima apresentam p50/p95 entre todas as 300 consultas. Pontuação. Os rankings recuperados foram pontuados em relação aos julgamentos de relevância com as métricas padrão do BEIR — NDCG@10, Recall@10 e MRR@10 — calculadas por consulta e calculadas em média sobre todas as consultas com rótulos.

​
Interpretação dos resultados

​
Contexto de precisão

O placar do BEIR informa NDCG@10 no SciFact como referência: Pontuações NDCG@10 na faixa de 70–76 indicam forte qualidade de recuperação, competitiva com os principais modelos de embedding.

​
O que observar

  • NDCG@10 é a métrica principal. Ela penaliza documentos relevantes que aparecem em posições mais baixas.
  • Recall@10 mede quantos documentos relevantes aparecem entre os 10 principais resultados — importante para pipelines RAG nos quais a geração subsequente depende da completude da recuperação.
  • MRR@10 mede quão rapidamente o primeiro resultado relevante aparece — importante para pesquisas voltadas ao usuário.
  • Híbrido vs. vetor puro: a configuração híbrida combina automaticamente similaridade vetorial com correspondência de palavras-chave em texto completo; a configuração de vetor puro troca isso por uma latência de pesquisa ligeiramente menor. Sua precisão neste conjunto de dados é quase idêntica — a vantagem da recuperação híbrida aumenta em corpora nos quais termos exatos importam (nomes, códigos, tokens raros).

​
Como interpretar a divisão de latência

Uma consulta de recuperação possui três componentes de latência:
  1. Inferência de embedding — o tempo para converter o texto da consulta em um vetor. Isso é inferência de modelo e é igual independentemente da configuração de armazenamento.
  2. Pesquisa no banco de dados — o tempo que o mecanismo gasta encontrando vetores próximos, conforme informado pelo servidor. Esse é o tempo puro de pesquisa, sem sobrecarga de rede.
  3. Resposta ponta a ponta — o que o cliente observa: ida e volta na rede + roteamento do gateway + pesquisa no banco de dados.
Se a latência ponta a ponta for alta, mas a pesquisa no banco de dados for rápida, o gargalo será a sobrecarga de rede ou do gateway. A própria pesquisa no banco de dados pode ser ajustada ainda mais com índices vetoriais aproximados quando os corpora crescerem muito mais.

​
Veja também

  • Arquivos e armazenamentos vetoriais — a superfície de recuperação da plataforma sobre a qual as aplicações são construídas, incluindo ingestão de arquivos, fragmentação e pesquisa.
  • Avaliação de GraphRAG — recuperação com reconhecimento de grafo comparada com RAG plano em questões de múltiplos saltos.