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.
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

Um LLM local pode retomar a geração depois de o seu processo reiniciar?
Uma explicação da retoma da geração de LLM baseada primeiro no mecanismo, das suas concessões em termos de recursos partilhados, de três perguntas frequentes...

Pode um servidor doméstico executar embeddings e transcodificação de vídeo na mesma GPU integrada?
Uma explicação baseada primeiro no mecanismo dos embeddings partilhados da iGPU e da transcodificação, das suas cedências em termos de recursos partilhados, três perguntas...

Como é que o tempo de vida do token de acesso afeta a segurança e o atrito no agregado familiar?
Uma explicação baseada primeiro no mecanismo da duração dos tokens de acesso, os compromissos relativos aos recursos partilhados, três perguntas frequentes sobre a propagação...

