Como é que a profundidade do reranqueador afeta a latência da pesquisa privada?

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

A profundidade do reranker aumenta a latência da pesquisa privada aproximadamente em função do número de candidatos avaliados, embora o processamento em lotes, o comprimento das sequências, a arquitetura do modelo e o hardware tornem a curva não linear.

Um recuperador de primeira fase pode devolver 20, 100 ou 500 fragmentos candidatos antes de um cross-encoder ou LLM local os reordenar. Uma reordenação mais profunda dá à passagem relevante mais oportunidades de sobreviver a uma ordenação inicial fraca, mas cada candidato acrescenta trabalho de tokenização e inferência. Quando a recuperação de documentos relevantes estabiliza, uma profundidade adicional consome sobretudo mais capacidade de computação e pode prolongar as consultas interativas mais lentas.

A profundidade é o número de candidatos que entra na segunda fase

A profundidade do reranker é diferente do top-k final. Um pipeline pode avaliar cem candidatos e devolver cinco, pelo que a latência é determinada por cem comparações entre consulta e documento, embora o modelo de linguagem veja apenas algumas. O comprimento do texto candidato determina o número de tokens processados em cada comparação.

A experiência da Elastic sobre a profundidade da reordenação mede a qualidade da recuperação à medida que a profundidade da reordenação varia e fornece orientações específicas para cada modelo. Os resultados mostram que a profundidade útil depende do recuperador de primeira fase e do reranker, e não de um único valor fixo. Este efeito deve continuar a ser mensurável na carga de trabalho pretendida para o servidor doméstico.

Uma primeira fase fraca pode exigir maior profundidade para incluir a resposta, enquanto um recuperador híbrido forte pode apresentar bons candidatos mais cedo. Por isso, a profundidade do reranker não pode compensar candidatos que nunca foram recuperados. Esta distinção é importante quando várias fases do pipeline partilham o mesmo orçamento de armazenamento e memória.

O custo da inferência aumenta com os candidatos e os respetivos tokens

Os cross-encoders processam conjuntamente a consulta e cada candidato, pelo que duplicar a profundidade duplica aproximadamente os pares avaliados antes dos efeitos do processamento em lotes. Lotes maiores podem melhorar a utilização do acelerador, mas também exigem mais memória e podem atrasar o primeiro resultado concluído até ao fim de um lote.

Um estudo sobre a reordenação por pares relata grandes reduções de latência ao limitar o conjunto reordenado, escolher modelos mais pequenos, reduzir a precisão e controlar o trabalho de saída. Demonstra que a profundidade é uma de várias opções multiplicativas de disponibilização do serviço. Este limite deve ser testado com dados domésticos representativos, e não presumido.

A reordenação em CPU pode apresentar uma curva quase linear, enquanto as curvas em GPU podem conter patamares eficientes seguidos de quebras causadas pela memória ou pelas filas. A latência de cauda também aumenta quando os comprimentos dos candidatos variam, porque os fragmentos longos dominam o trabalho dos lotes. Este efeito deve continuar a ser mensurável na carga de trabalho pretendida para o servidor doméstico.

Os ganhos de qualidade estabilizam antes do custo

Aumentar a profundidade só ajuda enquanto existir evidência relevante abaixo do limite atual e o reranker conseguir identificá-la. Depois de a recuperação da primeira fase saturar, mais candidatos acrescentam elementos de distração e custos, podendo por vezes reduzir a estabilidade da ordenação em consultas ambíguas.

Uma avaliação de ponta a ponta controlada compara configurações de recuperadores e rerankers utilizando eficácia, qualidade da geração, custo e latência. Isto apoia a escolha da profundidade a partir de uma fronteira de ponta a ponta, em vez de otimizar as pontuações de ordenação isoladamente. Esta distinção é importante quando várias fases do pipeline partilham o mesmo orçamento de armazenamento e memória.

O limite de falha é uma profundidade escolhida com base na latência média de consultas uniformes e em modelos já aquecidos. Modelos frios, fragmentos longos, utilizadores simultâneos e leituras a partir do NAS podem elevar significativamente o p95 ou o p99 acima da mediana, mesmo quando a relevância média melhora ligeiramente.

-15% OFF

Perguntas frequentes sobre a profundidade dos candidatos do reranker

Reordenar 100 candidatos é duas vezes mais lento do que reordenar 50?

Pode aproximar-se do dobro do trabalho de avaliação, mas o tempo total pode ser menor ou maior, dependendo da utilização dos lotes, dos comprimentos dos tokens, dos limites de memória e das filas. Meça o modelo implementado em vez de presumir uma proporção perfeitamente linear.

Um top-k final maior exige uma profundidade maior do reranker?

Normalmente, o conjunto de candidatos deve ser maior do que o número de resultados finais, mas o multiplicador necessário depende da recuperação da primeira fase e da diversidade dos resultados. Devolver mais passagens não justifica automaticamente avaliar centenas de candidatos fracos. Este limite deve ser testado com dados domésticos representativos, e não presumido.

A colocação em cache das pontuações do reranker pode reduzir a latência?

A cache ajuda no caso de pares de consulta e candidato repetidos ou de consultas normalizadas estáveis, mas a pesquisa privada contém frequentemente formulações únicas e documentos em mudança. A invalidação da cache deve acompanhar as versões dos documentos e as alterações do modelo para evitar ordenações obsoletas. Este efeito deve continuar a ser mensurável na carga de trabalho pretendida para o servidor doméstico.

Encontre a menor profundidade no patamar de qualidade

Crie um conjunto de consultas etiquetado com termos exatos, paráfrases, nomes ambíguos e negativos difíceis. Teste profundidades do reranker como 10, 25, 50, 100 e 200, medindo a recuperação da primeira fase, o nDCG ou MRR final, a cobertura das citações, o tempo de CPU ou GPU, a memória e a latência p50, p95 e p99.

Compare a curva com os fatores de decisão em fatores de decisão do reranker. Mantenha constantes a geração de candidatos da primeira fase, o comprimento dos fragmentos, o modelo do reranker, o top-k final, a simultaneidade e o estado da cache, para que a profundidade seja a única variável alterada. Esta distinção é importante quando várias fases do pipeline partilham o mesmo orçamento de armazenamento e memória.

Selecione a menor profundidade cuja qualidade seja estatisticamente indistinguível do patamar e cuja latência de cauda cumpra o objetivo interativo. Encaminhe a investigação em segundo plano para um perfil mais profundo apenas quando a recuperação adicional tiver valor medido. Este limite deve ser testado com dados domésticos representativos, e não presumido.

Centro de Tecnologia e IA

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.