Photon: Construindo um Motor de Recuperação e Classificação do Zero

Como formatos de dados especializados, leituras em lote e a separação da construção de índices melhoram a busca nativa de IA.

AutoresPerplexity Engineering

Introdução

A pilha de busca nativa de IA da Perplexity recupera e classifica páginas candidatas, trazendo à tona o conteúdo mais relevante para o modelo fundamentar suas respostas. Originalmente, esse estágio era executado em um motor de código aberto que adaptamos ao nosso sistema. No entanto, à medida que nosso índice e cargas de trabalho cresciam, atingimos limites rígidos de custos, latência de cauda e tempo de recuperação de nós que não conseguíamos resolver dentro da plataforma de terceiros existente.

Para superar esses desafios, construímos o Photon, um novo motor próprio de recuperação e classificação. Isso continua nossa abordagem de construir infraestrutura de busca com foco em IA do zero, como fizemos com o CobbleDB, nosso armazenamento chave-valor distribuído para servir registros de páginas, e nossa API de Busca.

O Photon usa formatos de dados compactos para ler e decodificar apenas o que cada consulta precisa, com cache compatível com lotes e leituras assíncronas para reduzir o acesso ao disco e sobrepor esperas. A construção de índices é executada separadamente do atendimento de consultas, atualizando um grupo de atendimento por vez e aquecendo seus caches antes de direcionar consultas ativas para ele.

O Photon agora alimenta nosso pipeline de busca e também é a base de uma nova predefinição rápida para nossa API de Busca, com latência de chamada de busca única de 160 ms no p50 e 230 ms no p95. Em seis benchmarks públicos, a predefinição rápida reduziu o custo estimado de modelo mais busca por tarefa em 68%, mantendo uma qualidade de tarefa agregada comparável à predefinição padrão. Estamos lançando-o hoje para que os desenvolvedores possam acessar essas melhorias.

Latência de chamada de busca única auto-relatada. O PPLX Fast relata latência p50 de 160 ms e latência p95 de 230 ms. O Exa Instant relata p90, não p95, para seu valor de cauda alta; os valores de cauda alta da Parallel não são publicados. Os percentis relatados e as configurações de medição não são uma comparação controlada de igual para igual.
Qualidade agregada da tarefa versus o custo total estimado de modelo mais busca para as mesmas 3.554 tarefas selecionadas. As pontuações são ponderadas pela contagem de tarefas, e os custos cobrem o conjunto completo de tarefas. O PPLX Fast pontua 64,3% a $59,73, versus 64,0% a $187,60 para a predefinição padrão do PPLX, com um custo estimado aproximadamente 68% menor para o mesmo número de tarefas.

O que o motor de recuperação e classificação requer

Para cada consulta, o motor de recuperação e classificação busca em um índice grande e distribuído para selecionar e ordenar um pequeno conjunto de páginas relevantes dentro do orçamento de latência da pilha de busca. O sistema também deve manter o índice atualizado à medida que novas páginas chegam e as existentes mudam, sem permitir que esse trabalho desacelere as consultas ativas.

Avaliamos várias opções de código aberto e escolhemos um motor de recuperação e classificação maduro e de uso geral que atendia às nossas necessidades iniciais. Em seguida, o adaptamos à nossa arquitetura e cargas de trabalho, mantendo latência e vazão estáveis em escala de produção.

Onde nosso sistema anterior falhou

Mantivemos nossa própria bifurcação para adaptar o motor ao nosso índice crescente, mas resolver limitações importantes exigia cada vez mais redesenhar grandes partes da plataforma. Várias restrições provaram ser difíceis de resolver sem mudanças arquiteturais fundamentais:

1. Custos de dimensionamento. Tanto o número de documentos que armazenamos quanto a quantidade de dados por documento que precisamos recuperar e classificar têm crescido ao longo do tempo. Esse dimensionamento exerceu pressão sobre o nosso hardware, especialmente sobre a quantidade de RAM disponível. Para controlar custos, precisávamos de representações de dados mais compactas e controle mais refinado sobre o que permanece na memória e o que é lido do disco sob demanda.

2. Pobre latência de cauda. No tráfego de produção, o tempo de resposta p99 do sistema antigo era de cerca de 800 ms. O conjunto de dados excedia a RAM disponível, então não podíamos usar mlock para mantê-lo inteiramente na memória. O acesso a dados não residentes podia disparar falhas de página graves, travando a execução da consulta enquanto o sistema operacional lia do disco.

O motor também mesclava periodicamente seu índice de disco principal com índices menores descarregados da memória. Durante esse processo de fusão de índices de disco, o número de falhas de página subia ainda mais, com a latência p99 atingindo aproximadamente 1,2 s por 10 a 15 minutos. Conforme os caches aqueciam, a frequência de falhas de página e a latência diminuíam, sugerindo que leituras frias eram um grande contribuidor para os picos. Pré-carregar dados e aquecer o índice reduziu os picos, mas não abordou adequadamente a alta latência de cauda.

3. Recuperação e sincronização demoradas. No sistema anterior, implantar um cluster adicional e sincronizar seus dados podia levar mais de uma semana. A sincronização também era necessária ao adicionar grupos de nós para conter cópias de dados adicionais ou ao se recuperar de falhas de nós. Durante a recuperação, uma parcela maior das respostas de busca era parcial, o que reduzia as pontuações de qualidade da resposta final.

Em última análise, concluímos que seria mais simples e barato construir do zero em vez de continuar adaptando e mantendo nossa bifurcação. Com base em nossa experiência operando o sistema anterior, uma pequena equipe de engenharia trabalhou ao lado de um enxame de agentes de codificação persistentes para construir o Photon.

Onde o Photon se encaixa na pilha de busca

O Photon foi projetado para dois fluxos de trabalho principais: atender a solicitações de busca e ingerir atualizações do pipeline de processamento.

Uma solicitação do serviço de busca de nível superior chega ao corretor Photon através de um balanceador de carga. O corretor seleciona um grupo de partições e encaminha a solicitação para cada partição, monitorando tempos limite e emitindo solicitações adicionais quando necessário.

Cada partição realiza recuperação, classificação inicial e classificação de segundo estágio, retornando seus melhores candidatos para o corretor. O corretor combina esses candidatos em uma única lista classificada e busca campos de chave de documento para as páginas selecionadas nas partições relevantes. Em seguida, ele retorna esses resultados para o serviço de busca de nível superior, que reúne o conteúdo de página necessário para o agente gerar uma resposta fundamentada.

As atualizações de índice seguem um caminho separado. A Pillar, nossa camada de publicação, prepara os dados e os armazena em tabelas do YTsaurus. Os indexadores convertem essas tabelas em estruturas de índice que as partições podem carregar para busca. O controlador coordena a preparação de dados, a construção de índices e a implantação de novas versões de índice para grupos de atendimento. Antes de lidar com o tráfego ativo, cada shard reproduz consultas de busca reais para aquecer seus caches.

Uma consulta passa do serviço de busca de nível superior através do balanceador de carga e do corretor para um grupo de partições selecionado. Cada partição recupera e classifica candidatos; o corretor mescla os resultados, busca campos de documento para as páginas selecionadas e os retorna ao serviço de busca de nível superior. As etapas numeradas mostram a ordem. Setas sólidas transportam solicitações, e setas tracejadas transportam resultados de volta. Os rótulos de fase do lado esquerdo distinguem a seleção de candidatos das leituras de resumo.

Projetando o Photon para nossos fluxos de trabalho

Três escolhas de design tornam o Photon adequado para nossa carga de trabalho: representações de dados compactas, cache e leituras de disco assíncronas, e a separação de atualizações de índice do atendimento de consultas.

Representações de dados para recuperação e classificação

A recuperação e a classificação acessam os dados dos documentos de maneira diferente. A recuperação lexical começa com os termos de consulta e encontra documentos que os contêm. A classificação precisa de informações detalhadas sobre cada documento selecionado, incluindo frequências de termos e posições.

O Photon usa duas representações complementares para dar suporte a esses padrões de acesso. Um índice invertido armazena uma lista de documentos correspondentes para cada termo, chamada de lista de postagem, para apoiar a seleção de candidatos. Registros separados por documento fornecem os dados necessários para a classificação. Também otimizamos como as listas de postagem são armazenadas e percorridas para melhorar a seleção sob um orçamento de trabalho fixo.

Representações de dados especializadas nos permitem armazenar dados importantes com mais eficiência. Um índice invertido mais compacto reduz a quantidade de dados lidos ou movidos por consulta, melhorando a latência ao eliminar operações de E/S desnecessárias. Esses formatos também tornam possível verificar se um documento aparece em uma lista sem decodificá-lo totalmente, uma propriedade na qual nossa lógica de travessia confia para controlar quanto trabalho uma consulta faz sob um orçamento fixo. Otimizar registros por documento nos permite armazenar mais dados por documento para classificação, reduzindo também os custos de dimensionamento associados ao nosso sistema anterior.

O índice invertido

Para cada termo, o índice invertido armazena uma lista de postagem. Essas listas podem variar de um punhado de documentos a milhões, portanto, nenhum formato único funciona bem para todas as listas. O Photon escolhe o formato com base no número de documentos que contêm o termo.

Listas curtas usam uma representação embutida que cabe em uma única página e não requer tabela de blocos. Listas mais longas que não cabem no formato embutido são divididas em blocos que cobrem intervalos fixos de identificadores de documento. A representação de cada bloco depende de sua densidade: blocos esparsos armazenam matrizes ordenadas de deslocamentos de IDs de documentos, enquanto blocos densos usam mapas de bits. Blocos esparsos usam busca galopante, que avança em passos cada vez maiores para pular regiões da lista. Blocos densos permitem verificações de pertencimento consultando o bit correspondente a um documento.

A frequência de consulta de um termo determina onde sua lista de postagem é colocada no disco. Listas consultadas com frequência são armazenadas próximas umas das outras, concentrando dados quentes em uma região de armazenamento menor. Dentro de cada lista, os documentos são ordenados por um sinal de utilidade separado para que candidatos mais promissores sejam encontrados mais cedo.

O Photon escolhe uma representação de lista de postagem por comprimento e densidade de bloco. Listas curtas cabem embutidas em uma página. Listas mais longas são divididas em intervalos fixos de IDs de documentos, com matrizes de deslocamento ordenadas para blocos esparsos e mapas de bits para blocos densos.

Percorrendo listas dentro de um orçamento de trabalho

A seleção de candidatos requer percorrer listas de postagem para encontrar documentos potencialmente relevantes. Varrer exaustivamente todas as listas é caro, por isso o Photon usa um algoritmo semelhante ao WAND que percorre apenas algumas listas, contabilizando ainda as correspondências nas outras.

O algoritmo divide as listas em dois grupos. As listas de direcionamento avançam a travessia e propõem documentos candidatos. As listas de sondagem contribuem para as pontuações desses candidatos, mas não geram candidatos por conta própria.

A pontuação de candidatos combina a cobertura ponderada de termos de consulta e uma contribuição de frequência, com normalização do comprimento do documento e um teto nos ganhos de termos repetidos. O Photon primeiro verifica a presença de termos nas matrizes e mapas de bits para delimitar a pontuação máxima possível de cada candidato. Ele lê frequências exatas de termos apenas para candidatos que ainda possam atender ao limite de seleção.

A seleção prossegue em três etapas:

  • Travessia: Comece com um requisito estrito de cobertura de consulta. Se poucos candidatos forem encontrados, repita com um requisito relaxado.
  • Retenção: Os candidatos são mantidos em um conjunto delimitado usando uma pontuação que combina cobertura e frequência. À medida que os principais candidatos coletados melhoram, o limite de admissão sobe.
  • Seleção final: Os resultados finais para a passagem são escolhidos do conjunto retido com base nas pontuações de frequência. Cada campo executa sua própria passagem, e os resultados são mesclados usando pesos de campo.

O algoritmo produz um conjunto candidato de documentos relevantes a serem usados em classificações posteriores.

Travessia ilustrativa de candidatos delimitados. As listas de direcionamento propõem documentos, enquanto os limites superiores permitem que candidatos abaixo do limite de admissão atual sejam podados sem ler listas de sondagem ou frequências exatas. O limite sobe à medida que o conjunto retido melhora. As pontuações são inventadas para ilustração, e os candidatos retidos não são um top-k exato garantido.

Docblob

Após a seleção das páginas candidatas, a fase de classificação precisa de frequências de termos, cobertura de campo e os locais e proximidade das ocorrências. Obter esses dados por meio do índice invertido exigiria acessos dispersos em muitos pares de termo-documento. No Photon, armazenamos um registro compacto por documento chamado docblob que contém frequências de termos, em quais campos um termo apareceu e onde no documento ele ocorreu. Como resultado, classificar um candidato requer apenas uma consulta por documento.

O formato foi construído para evitar a decodificação além do necessário. Dentro de um docblob, os campos são agrupados por analisador de texto. Cada grupo armazena uma lista de termos ordenada codificada com Elias-Fano, para que um termo de consulta possa ser consultado diretamente sem expandir toda a lista primeiro. Uma máscara de campo marca onde um termo ocorreu, uma contagem de frequência rastreia com que frequência, e as posições reais residem em blocos separados por par de termo-campo codificados como diferenças de posição. Apenas os blocos para termos que realmente corresponderam são decodificados, enquanto todo o resto no registro permanece no formato compactado.

Essa decodificação seletiva permite que o docblob suporte o armazenamento de mais dados por documento sem um aumento proporcional de custo. Crescer o registro não força mais trabalho por consulta, porque a classificação toca apenas nas partes relevantes para os termos correspondentes, em vez do registro inteiro.

Um docblob agrupa dados de classificação em um registro compacto por documento. Os termos de consulta são consultados em uma lista de termos codificada em Elias-Fano; máscaras de campo, frequências e blocos de posição fornecem os dados necessários para os termos correspondentes, enquanto termos não relacionados permanecem compactados. IDs de termos e posições são ilustrativos.

Leituras em lote e trabalho com a memória

Mesmo com as representações de dados mais eficientes, a RAM ainda acaba antes de outros recursos, por isso frequentemente precisamos acessar dados armazenados em disco. O Photon usa leituras de disco assíncronas e um cache otimizado para leituras em lote para acelerar esses acessos, cortando o tempo de espera por solicitação. Isso contribui para uma melhoria significativa na latência de cauda em comparação com o sistema anterior.

O Photon verifica um lote de deslocamentos de registros conhecidos em seu cache antes de emitir leituras de disco. Os acertos de cache são copiados para um buffer preparado; as falhas são enviadas através do io_uring para que as esperas de disco possam se sobrepor, e os dados retornados povoam o cache. Os registros e cronogramas são esquemáticos, não latências medidas.

Sobreposição de esperas de disco

A classificação requer a obtenção dos recursos de uma centena de documentos localizados em diferentes partes de um arquivo. Nosso sistema anterior usava mmap para mapear o arquivo no Espaço de endereço virtual para que pudesse ser lido através de ponteiros de memória. No entanto, acessar uma página ausente da memória ainda exigia uma leitura de disco. O tópico precisava esperar pelos dados antes de continuar a computação, e esse tempo de espera acumulava quando o processo precisava ler registros frios sequencialmente.

O Photon aproveita o fato de que os deslocamentos de registros são conhecidos antecipadamente, permitindo enviar várias leituras de uma só vez. Isso é gerenciado pelo reator: tópicos de trabalhadores dedicados enviam lotes através de io_uring e passam os dados lidos para o código de chamada. Cada tópico mantém seu próprio io_uring; os lotes são enviados para o reator com menor carga. Descritores de arquivos pré-registrados e pools de buffers reduzem a sobrecarga de leituras repetidas. Essa execução assíncrona permite que as esperas por várias operações se sobreponham, reduzindo a latência de cauda.

Reduzindo o número de acessos à unidade

Antes de enviar leituras, o Photon verifica todo o lote no cache em memória. Apenas solicitações de registros ausentes vão para o disco; os dados lidos então povoam o cache.

O cache foi projetado para leituras em lote. Especificamente:

  • Não há alocação separada em um acerto. Em vez disso, os dados são copiados para um buffer preparado antecipadamente pelo código de chamada.
  • Não há aquisição de bloqueio pelo leitor. Em vez disso, ele verifica a versão dos dados e tenta novamente se houver conflito com uma gravação.
  • Ele usa evicção CLOCK, em vez de exigir atualizações para uma lista LRU compartilhada a cada leitura.
  • Ele usa pré-busca de cache de CPU, onde metadados e dados para registros futuros são solicitados com antecedência.

Essas otimizações diminuem a latência sem prejudicar o desempenho nas cargas de trabalho que nos importam.

Construindo e atualizando o índice separadamente do atendimento

No Photon, a construção de índices e o atendimento de consultas são executados em nós diferentes. Os indexadores transformam dados em estruturas de armazenamento prontas, enquanto os nós de atendimento as leem e realizam a recuperação e a classificação. Como resultado, a construção de índices não compete com as consultas de busca por CPU, e os recursos para essas tarefas podem ser escalados de forma independente.

Essa separação aborda os gargalos de recuperação e sincronização presentes na implementação anterior. Como a construção de índices era executada dentro do mesmo cluster que atendia a consultas, recuperar um nó com falha ou adicionar uma nova cópia dos dados podia significar reindexar documentos no local, um processo que levava dias e aumentava as respostas parciais durante a recuperação. O Photon remove esse acoplamento; os indexadores são executados como trabalhos distribuídos que produzem estruturas de índice versionadas e prontas para atendimento, independentemente dos nós de atendimento, de modo que construir a próxima versão do índice não compete mais com o tráfego ativo.

A construção de índices é executada separadamente do atendimento de consultas ativas. A Pillar exporta dados de origem, o YTsaurus prepara tabelas versionadas por partição e indexadores paralelos gravam estruturas de índice prontas para atendimento no armazenamento de objetos. Os nós de atendimento carregam essas estruturas para recuperação e classificação; a concorrência do indexador e a contagem de partições são configuradas de forma independente.

Preparação e construção distribuída

Uma construção começa selecionando documentos para o índice ativo e produzindo a exportação de origem. O controlador registra a versão de origem, tabelas de entrada e o número esperado de partições. Trabalhos MapReduce no YTsaurus preparam texto, metadados, fragmentos, recursos e incorporações pré-computadas em tabelas versionadas particionadas por partição. Cada indexador transmite a tabela preparada, constrói as estruturas para sua partição e mescla os segmentos de texto. O índice pronto, juntamente com uma descrição de seus componentes, é enviado para o armazenamento de objetos.

A contagem de partições e o número de indexadores executados concorrentemente são configurados de forma independente, para que uma construção possa ser executada em várias ondas, ou mais máquinas possam ser alocadas para trabalhar em paralelo. A preparação distribuída e os indexadores paralelos permitem que todo o índice da Web seja construído em um número de horas de um único dígito, uma melhoria significativa em relação ao sistema anterior.

Implantando uma nova versão

Antes da implantação, o controlador verifica se o novo índice está pronto. Se os dados estiverem incompletos, a implantação é bloqueada automaticamente.

Quando há vários grupos de atendimento, o controlador os atualiza um de cada vez. Ele primeiro remove um grupo do roteamento do corretor e o inicia na nova versão do índice. Antes de atender a solicitações, as partições passam por um estágio de aquecimento separado baseado em logs de busca, o que pré-popula o estado inicial e torna a transição para o tráfego real mais suave. Após o aquecimento, o controlador verifica o estado e a prontidão do índice e, em seguida, retorna o grupo para o roteamento. Os outros grupos continuam atendendo solicitações durante esse período. Como o estado da operação é persistido, uma reinicialização não força o recomeço de uma construção; o controlador pode se reanexar à preparação já em andamento, reutilizar um resultado pronto ou continuar uma rotação interrompida a partir da etapa salva.

Os tempos de atualização de dados diferem entre os verticais de busca. Para verticais com altos requisitos de frescor, a entrega de documentos leva um número de minutos de um único dígito. Uma cópia adicional dos dados pode ser implantada em cerca de meia hora; índices prontos são carregados e anexados a partições sem reindexar os documentos de origem.

O controlador verifica se um novo índice está completo e, em seguida, alterna um grupo de atendimento por vez. Um grupo deixa o roteamento do corretor, carrega a nova versão, aquece seus caches com consultas de logs de busca e passa nas verificações de prontidão antes de retornar ao tráfego. Outros grupos continuam servindo, e o estado persistido do controlador permite que uma rotação interrompida seja retomada.

Migração e validação em nossa pilha de busca

Nosso primeiro objetivo era substituir o sistema antigo por um motor que preservasse a funcionalidade e a qualidade da busca, reduzindo os tempos de resposta. Validamos o Photon em etapas, começando com testes de carga reproduzíveis e avaliações de qualidade offline antes de passar para o tráfego ativo. O Photon agora alimenta a recuperação e a classificação em nossa pilha de busca de produção, com tempos de resposta substancialmente menores do que o sistema antigo.

Testes de carga e avaliações

Para testes de desempenho, criamos uma ferramenta de teste de carga que reproduz consultas de nossos logs de busca em taxas de chegada configuráveis. Ela compara resultados entre execuções e aplica testes estatísticos para avaliar se as diferenças de desempenho observadas são consistentes. Separadamente, avaliamos o Photon e o sistema antigo nos mesmos conjuntos de dados em nossos sistemas de avaliação offline internos para verificar se há regressões de qualidade.

Após essas verificações, enviamos consultas ativas para ambos os motores simultaneamente usando tráfego fantasma. Isso nos permitiu comparar seu desempenho e resultados em cargas de trabalho de produção antes de alterar qual motor atendia aos usuários. Em seguida, habilitamos o Photon para pequenos subconjuntos de usuários e expandimos gradualmente a implementação, monitorando a qualidade e o desempenho em todo o processo. A primeira versão passou nos testes de aceitação sem regressões de qualidade, e continuamos a implementação até que o Photon atendesse a todo o tráfego de produção.

Melhorias medidas em produção

Em nosso fluxo de trabalho de produção, o tempo de resposta p99 caiu de aproximadamente 800 ms no sistema antigo para aproximadamente 65 ms no Photon. Esta medição cobre todos os estágios dentro do Photon, mas exclui estágios subsequentes na pilha de busca de nível superior. Também não observamos mais os picos de latência anteriormente associados à troca de versões de índice.

O Photon usa aproximadamente 20% menos máquinas de atendimento equivalentes do que os nós de conteúdo do sistema antigo, enquanto armazena aproximadamente 2,5 vezes mais dados por documento. Após a migração, usamos esses dados adicionais para melhorar a qualidade da classificação além daquela do sistema antigo.

O Photon também reduz a quantidade de dados que devem permanecer na memória. Fixar o mesmo conjunto de dados do Photon na RAM com mlock exigiria cerca de 4,6 vezes mais memória residente do que o Photon usa atualmente.

Avaliação da predefinição rápida da API de Busca

Também usamos o Photon como base para uma nova predefinição rápida para nossa API de Busca, projetada para cargas de trabalho sensíveis à latência. De acordo com nossas medições, a latência de chamada de busca única para a predefinição rápida é de 160 ms no p50 e 230 ms no p95, menor ou comparável aos números auto-relatados de outros provedores de API de Busca, embora os percentis de cauda relatados diferiram.

Avaliamos a predefinição rápida em seis benchmarks agênticos: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 e SEAL-Hard. Nessas avaliações, ela teve o menor custo total estimado de modelo mais busca e a maior pontuação agregada de tarefas entre as configurações testadas.

A predefinição rápida combina o Photon com uma classificação otimizada para fluxos de trabalho agênticos, entregando desempenho comparável à predefinição padrão a um custo substancialmente menor. No entanto, isso traz uma compensação na qualidade mais ampla da busca. A predefinição rápida usa menos computação para classificação do que a predefinição padrão. Em benchmarks internos que cobrem consultas de cauda longa, ampla cobertura e diversidade de resultados, ela pontua 0,24 pontos a menos em relevância e aproximadamente 3 pontos percentuais a menos em disponibilidade de resposta. Acreditamos que esta seja uma compensação sensata para fluxos de trabalho agênticos, pois o raciocínio e o conhecimento do próprio modelo podem ajudar a compensar a diferença.

Comparação interna de qualidade de recuperação entre a predefinição padrão do PPLX e o PPLX Fast. A relevância (DCG) cai de 2,45 para 2,21, uma diminuição de 0,24 pontos; a disponibilidade de resposta cai de 0,596 para 0,567, uma diminuição de 2,9 pontos percentuais. Os dois painéis usam linhas de base de eixo diferentes e não nulas, de modo que as alturas das barras enfatizam lacunas em vez de diferenças proporcionais.

Recomendamos a predefinição rápida para tarefas agênticas do dia a dia. Para perguntas mais desafiadoras ou ambíguas que são menos sensíveis ao tempo, a predefinição padrão oferece qualidade mais robusta, justificando sua maior latência e custo.

Conclusão

Estamos migrando constantemente nossa pilha de busca para uma infraestrutura própria baseada em Rust. Substituir o motor de código aberto pelo Photon, nosso motor personalizado de recuperação e classificação, é o passo mais recente. O Photon nos dá controle total sobre as representações de dados, como as leituras são organizadas e como novos índices são implantados, permitindo-nos otimizar cada camada para nossas cargas de trabalho.

O Photon possibilitou uma busca mais rápida nos produtos da Perplexity e fornece a base para nossa nova predefinição rápida na API de Busca. Após a migração, a latência de recuperação e classificação p99 caiu de aproximadamente 800 ms para 65 ms. Nossos formatos de dados compactos também nos permitem armazenar 2,5 vezes mais dados por documento, dando à recuperação e classificação acesso a informações mais ricas sobre os documentos.

A predefinição rápida oferece latência de chamada de busca única de 160 ms no p50 e 230 ms no p95. Nos seis benchmarks agênticos avaliados, ela reduziu o custo estimado de modelo mais busca por tarefa em 68% em relação à predefinição padrão, mantendo uma qualidade de tarefa agregada comparável. Esses resultados demonstram os benefícios práticos da infraestrutura projetada em torno de nossas cargas de trabalho de busca, tanto para os produtos da Perplexity quanto para desenvolvedores que constroem com nossa API.

Continuamos a melhorar o desempenho e a eficiência de armazenamento do Photon. Nosso objetivo é suportar um índice maior e dados de documentos mais ricos no mesmo hardware, mantendo a busca rápida à medida que nossas cargas de trabalho crescem.

Citação

BibTeX
@online{perplexity2026Photon,
  author = {{Perplexity} and Maksim Morozov and Bogdan Savko and Ruslan Kovalev and Aleksei Bykov and Artur Zayats and Denis Bykov and Nikita Kireev and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Photon: Building a retrieval and ranking engine from scratch}},
  date = {2026-09-24},
  url = {https://www.perplexity.ai/hub/blog/photon}
}