A Perplexity colocou em produção o Photon, um mecanismo próprio de recuperação e ranqueamento para busca, escrito em Rust, e o usou como base para um novo modo rápido da Search API. Segundo a empresa, a mudança reduziu a latência p99 dessa etapa de cerca de 800 ms para 65 ms. Para quem constrói agentes que pesquisam antes de responder, a novidade é relevante menos pelo nome do motor e mais pelo que ela expõe: busca na web passou a ser parte mensurável do custo, da velocidade e da qualidade de uma aplicação de IA.
O anúncio foi publicado pela equipe de engenharia da Perplexity em 24 de setembro de 2026. A companhia afirma que o preset fast da API entrega 160 ms no percentil 50 e 230 ms no percentil 95 por chamada de busca. Esses são números declarados pela própria empresa, não uma medição independente do NoticIA, e devem ser lidos nesse contexto.
O que mudou na infraestrutura de busca da Perplexity
Um modelo de linguagem não pesquisa a web sozinho: antes de formular uma resposta com fontes, um sistema precisa encontrar documentos candidatos, ordená-los e entregar conteúdo suficiente para a etapa de geração. Esse conjunto de tarefas é chamado de recuperação e ranqueamento. Até então, a Perplexity usava um mecanismo de código aberto adaptado à sua arquitetura; com Photon, decidiu controlar internamente os formatos de dados, as leituras em disco e a atualização do índice.
Na descrição técnica, a solicitação chega a um broker por um balanceador de carga. O broker escolhe um grupo de shards, acompanha timeouts e distribui a consulta. Cada shard recupera candidatos, aplica uma ordenação inicial e uma segunda etapa de ranking. O broker reúne os resultados e busca os campos necessários dos documentos antes de devolvê-los ao serviço que alimentará o agente ou a resposta final.
Essa separação importa porque a busca de baixa latência lida com duas pressões opostas: o índice precisa receber páginas novas e alterações continuamente, enquanto as consultas ao vivo não podem sofrer com esse trabalho. A Perplexity diz que separou construção e serviço do índice, preparando versões em nós dedicados e fazendo a troca gradual dos grupos que atendem tráfego. O objetivo é evitar os picos de latência que costumavam ocorrer durante fusões de índice.
Como Photon tenta reduzir leituras caras
O núcleo do Photon combina duas representações de dados. A primeira é um índice invertido: para cada termo, ele mantém uma lista dos documentos que o contêm. É a estrutura usada para selecionar rapidamente candidatos. A segunda é o docblob, um registro compacto por documento com frequências dos termos, campos em que apareceram e posições. Em vez de fazer muitos acessos espalhados para cada par termo-documento, o ranking consulta um registro por documento selecionado e decodifica apenas os termos que correspondem à consulta.
As listas de postagem também variam conforme o tamanho e a densidade. Listas curtas podem ficar inline; listas maiores são divididas em blocos por intervalo de IDs. Blocos esparsos usam arrays de offsets e busca galloping; blocos densos usam bitmaps. Não é uma única técnica milagrosa: é uma tentativa de escolher uma estrutura mais econômica para cada padrão de dados.
Outro ponto é a leitura assíncrona em lote via io_uring. Quando o sistema já conhece os offsets dos registros necessários, ele pode pedir vários blocos ao disco sem esperar um a um. A abordagem reduz o custo de faltas de página que, no desenho anterior mapeado em memória, contribuíam para a pior cauda de latência. A Perplexity também afirma que os leitores não usam locks e que a cache adota CLOCK em vez de uma lista LRU compartilhada.
Os números divulgados e seus limites
| Métrica | Resultado informado pela Perplexity | Como interpretar |
|---|---|---|
| p99 de recuperação e ranking | ~800 ms para ~65 ms | Refere-se às etapas Photon, não necessariamente ao tempo total de uma resposta com LLM. |
| Fast Search p50 / p95 | 160 ms / 230 ms | Latência de uma chamada de busca, sob a medição da fornecedora. |
| Custo estimado em seis benchmarks | US$ 59,73 vs. US$ 187,60 no preset padrão | Estimativa de modelo mais busca para 3.554 tarefas; não é uma garantia de conta para todo produto. |
| Qualidade agregada | 64,3% no Fast vs. 64,0% no padrão | Resultado agregado nos benchmarks selecionados pela empresa. |
| Trade-off interno | -0,24 em relevância e cerca de -3 p.p. em disponibilidade de resposta | Indica perda em consultas long-tail, de cobertura ampla e diversidade. |
A companhia informa ainda que o Photon usa aproximadamente 20% menos máquinas equivalentes de serving e armazena 2,5 vezes mais dados por documento que os nós anteriores. Também afirma que manter o mesmo conjunto de dados todo fixado em RAM com mlock demandaria 4,6 vezes a memória residente atual. São indicadores úteis para entender a direção do projeto, mas não substituem benchmarks reproduzíveis, com corpus, hardware e carga de consulta publicados.
Fast Search: quando velocidade vale a perda de cobertura
O novo modo rápido está disponível como preset hospedado na Search API; o Photon não foi lançado como código aberto nem pode ser auto-hospedado. A documentação e o anúncio recomendam o modo para tarefas agentivas rotineiras e sensíveis à latência. Para perguntas ambíguas, difíceis ou que dependem de ampla cobertura, a própria Perplexity recomenda o preset padrão.
Essa distinção é prática. Um agente que precisa confirmar um dado simples ou reunir resultados iniciais pode se beneficiar de respostas mais rápidas e baratas. Já uma análise jurídica, uma investigação de mercado ou uma resposta que servirá de base para decisão de alto impacto não deveria trocar cobertura por velocidade sem validação adicional. Em fluxos críticos, a busca também precisa ter citação verificável, filtros de fonte e, quando necessário, uma segunda consulta de confirmação.
Impacto para equipes no Brasil
Para desenvolvedores brasileiros, a novidade reforça que o custo de um agente não é apenas o token do modelo. Chamadas de busca, reranking, navegação e extração de páginas acumulam latência e custo a cada etapa. Uma arquitetura saudável mede cada componente separadamente: tempo de recuperação, quantidade de resultados, taxa de resultados utilizáveis, custo por tarefa concluída e taxa de revisão humana.
O anúncio também não altera o fato de que dados brasileiros, consultas em português e fontes locais podem ter comportamento diferente dos benchmarks divulgados. Antes de migrar um produto para um preset rápido, uma equipe deve testar consultas reais do seu domínio — inclusive termos com acentos, nomes de empresas locais e perguntas que exigem fontes primárias. O teste deve comparar não só o tempo de resposta, mas a evidência retornada e a taxa de respostas incompletas.
Análise do NoticIA: a busca virou a camada que define o agente
Na análise do NoticIA, Photon ilustra uma mudança estrutural no mercado de IA aplicada: modelos semelhantes podem gerar respostas muito diferentes conforme a recuperação disponível antes da geração. Em vários produtos, a vantagem competitiva deixa de estar apenas no modelo escolhido e passa a incluir índice, ranking, cache, observabilidade e política de fontes.
O ponto mais saudável do anúncio é a explicitação do trade-off. A Perplexity não apresenta o modo rápido como superior em tudo: ela admite perda em relevância e disponibilidade para ganhar tempo e custo. Essa transparência deveria ser padrão em APIs para agentes. A limitação é que a maior parte das métricas ainda vem do fornecedor; compradores precisam medir com sua própria carga antes de transformar um número de benchmark em requisito de produção.
Conclusão
Photon não é um novo modelo de IA. É infraestrutura de busca que a Perplexity afirma já operar em produção e que sustenta um modo de API mais rápido. A redução de latência relatada mostra por que o desenho do índice importa para agentes que usam web search. O uso responsável, porém, exige escolher o modo rápido para tarefas em que uma pequena perda de cobertura seja aceitável e manter o modo mais robusto — com validação de fontes — quando precisão, diversidade e completude forem mais importantes.
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
