Photon: Construír un motor de recuperación e ordenación desde cero

Introdución

A pila de busca nativa de intelixencia artificial de Perplexity recupera e ordena páxinas candidatas, sacando á superficie o contido máis relevante para que o modelo basee as súas respostas. Orixinalmente, esta etapa executábase nun motor de código aberto que adaptamos ao noso sistema. Con todo, a medida que o nosso índice e as nosas cargas de traballo medraban, atopamos límites difíciles nos custos, na latencia de cola e no tempo de recuperación de nós que non podíamos resolver dentro da plataforma de terceiros existente.

Para superar estes desafíos, construímos Photon, un novo motor de recuperación e ordenación propio. Isto continúa co noso enfoque de construír infraestrutura de busca impulsada por intelixencia artificial desde cero, como fixemos con CobbleDB, o noso almacén de clave-valor distribuído para servir rexistros de páxinas, e a nosa API de busca.

Photon utiliza formatos de datos compactos para ler e descodificar só o que cada consulta necesita, con caché consciente de lotes e lecturas asíncronas para reducir o acceso ao disco e superpoñer as esperas. A construción de índices execútase por separado do servizo de consultas, actualizando un grupo de servizo á vez e quentando as súas cachés antes de derivar as consultas en directo cara a el.

Photon alimenta agora a nosa canalización de busca e é tamén a base dun novo preaxuste rápido para a nosa API de busca, cunha latencia de chamada de busca única de 160 ms en p50 e 230 ms en p95. A través de seis puntos de referencia públicos, o preaxuste rápido reduciu o custo estimado de modelo máis busca por tarefa nun 68 % mentres mantiña unha calidade de tarefa agregada comparable á do preaxuste predeterminado. Publicámolo hoxe para que os desenvolvedores poidan acceder a estas melloras.

Ampliar

Ampliar

O que require o motor de recuperación e ordenación

Para cada consulta, o motor de recuperación e ordenación busca nun índice grande e distribuído para seleccionar e ordenar un pequeno conxunto de páxinas relevantes dentro do orzamento de latencia da pila de busca. O sistema tamén debe manter o índice actualizado a medida que chegan novas páxinas e as existentes cambian, sen permitir que ese traballo ralentice as consultas en directo.

Avaliamos varias opcións de código aberto e eliximos un motor de recuperación e ordenación maduro e de propósito xeral que cumpría as nosas necesidades iniciais. Despois adaptámosno á nosa arquitectura e cargas de traballo, mantendo unha latencia e un rendemento estables a escala de produción.

Onde o noso sistema anterior quedou curto

Mantemos a nosa propia bifurcación para adaptar o motor ao noso índice en crecemento, pero abordar as limitacións clave requiriu cada vez máis redeseñar grandes partes da plataforma. Varios constrinximentos resultaron difíciles de resolver sen cambios arquitectónicos fundamentais:

1. Custos de escalado. Tanto o número de documentos que almacenamos como a cantidade de datos por documento que necesitamos recuperar e ordenar estiveron crecendo co tempo. Este escalado puxo presión no noso hardware, especialmente na cantidade de RAM dispoñible. Para controlar os custos, necesitabamos representacións de datos máis compactas e un control máis fino sobre o que permanece na memoria e o que se le do disco baixo demanda.

2. Pobre latencia de cola. No tráfico de produción, o tempo de resposta p99 do sistema antigo era de aproximadamente 800 ms. O conxunto de datos superaba a RAM dispoñible, polo que non poderiamos usar mlock para mantelo enteiramente na memoria. O acceso a datos non residentes podía desencadear fallos de páxina importantes, detendo a execución da consulta mentres o sistema operativo le desde o disco.

O motor tamén fusionaba periodicamente o seu índice de disco principal con índices máis pequenos vertidos desde a memoria. Durante este proceso de fusión de índices de disco, o número de fallos de páxina subiu aínda máis, coa latencia p99 alcanzando aproximadamente 1,2 s durante 10–15 minutos. A medida que as cachés se quentaban, a frecuencia de fallos de páxina e a latencia diminuíron, o que suxire que as lecturas en frío eran un contribuinte importante aos picos. A precarga de datos e o quecemento do índice reduciron os picos pero non abordaron adecuadamente a alta latencia de cola.

3. Recuperación e sincronización longas. No sistema anterior, despregar un clúster adicional e sincronizar os seus datos podía levar máis dunha semana. A sincronización tamén era necesaria ao engadir grupos de nodos para albergar copias de datos adicionais ou recuperar de fallos de nodos. Durante a recuperación, unha maior proporción das respostas de busca eran parciais, o que reducía as puntuacións de calidade da resposta final.

En última instancia, concluímos que sería máis sinxelo e barato construír desde cero en vez de continuar adaptando e mantendo a nosa bifurcación. Tirando da nosa experiencia coa operación do sistema anterior, un pequeno equipo de enxeñaría traballou xunto cun enxame de axentes de codificación persistentes para construír Photon.

Onde se sitúa Photon na pila de busca

Photon está deseñado para dous fluxos de traballo principais: servir solicitudes de busca e inxectar actualizacións da canalización de procesamento.

Unha solicitude do servizo de busca de nivel superior chega ao intermediario de Photon a través dun equilibrador de carga. O intermediario selecciona un grupo de fragmentos e reenviará a solicitude a cada fragmento, monitorizando os tempos de espera e emitindo solicitudes adicionais cando sexa necesario.

Cada fragmento realiza a recuperación, a ordenación inicial e a ordenación de segunda etapa, e logo devolve os seus mellores candidatos ao intermediario. O intermediario combina estes candidatos nunha única lista ordenada e busca campos clave de documento para as páxinas seleccionadas dos fragmentos relevantes. A continuación, devolve estes resultados ao servizo de busca de nivel superior, que recolle o contido de páxinas necesario para que o axente xere unha resposta fundamentada.

As actualizacións de índices seguen un camiño separado. Pillar, a nosa capa de publicación, prepara os datos e almacenaos nas táboas de YTsaurus. Os indexadores convirten estas táboas en estruturas de índice que os fragmentos poden cargar para a busca. O controlador coordina a preparación de datos, a construción de índices e a implementación de novas versións de índices nos grupos de servizo. Antes de xestionar o tráfico en directo, cada fragmento reproduciu consultas de busca reais para quentar as súas cachés.

Ampliar

Deseñar Photon para os nosos fluxos de traballo

Tres opcións de deseño fan que Photon sexa moi axeitado para a nosa carga de traballo: representacións de datos compactas, caché e lecturas de disco asíncronas, e a separación das actualizacións de índices da atención de consultas.

Representacións de datos para a recuperación e a ordenación

A recuperación e a ordenación acceden aos datos do documento de xeito diferente. A recuperación léxica comeza cos termos de busca e atopa os documentos que os conteñen. A ordenación necesita entón información detallada sobre cada documento seleccionado, incluíndo as frecuencias dos termos e as posicións.

Photon utiliza dúas representacións complementarias para admitir estes patróns de acceso. Un índice invertido almacena unha lista de documentos coincidentes para cada termo, chamada lista de publicación, para apoiar a selección de candidatos. Os rexistros por documento separados proporcionan os datos necesarios para a ordenación. Tamén optimizamos como se almacenan e percorren as listas de publicación para mellorar a selección dentro dun orzamento de traballo fixo.

As representacións de datos especializadas permítennos almacenar datos clave de forma máis eficiente. Un índice invertido máis compacto reduce a cantidade de datos lidos ou movidos por consulta, o que mellora a latencia ao eliminar operacións de E/S innecesarias. Estes formatos tamén fan posible comprobar se un documento aparece nun lista sen descodificalo por completo, unha propiedade na que se apoia a nosa lóxica de percorrido para controlar canto traballo fai unha consulta baixo un orzamento fixo. Optimizar os rexistros por documento permítennos almacenar máis datos por documento para a ordenación, á vez que reduce os custos de escalado asociados co noso sistema anterior.

O índice invertido

Para cada termo, o índice invertido almacena unha lista de publicación. Estas listas poden abranguer desde un puñado de documentos ata millóns, polo que ningún formato único funciona ben para todas as listas. Photon elixe o formato en función do número de documentos que conteñen o termo.

As listas curtas usan unha representación en liña que cabe nunha soa páxina e non require ningunha táboa de bloques. As listas máis longas que non caben no formato en liña divídense en bloques que abranguen intervalos fixos de identificadores de documentos. A representación de cada bloque depende da súa densidade: os bloques dispersos almacenan matrices ordenadas de desprazamentos de ID de documento, mentres que os bloques densos usanmapas de bits. Os bloques dispersos usan a busca a galope, que avanza en pasos cada vez máis grandes para omitir rexións da lista. Os bloques densos permiten comprobacións de pertenza buscando o bit correspondente a un documento.

A frecuencia de consulta dun termo determina onde se coloca a súa lista de publicación no disco. As listas consultadas con frecuencia almacénanse preto unhas das outras, concentrando datos quentes nunha rexión de almacenamento máis pequena. Dentro de cada lista, os documentos ordenaranse por un sinal de utilidade separado para que os candidatos máis prometedores se atopen antes.

Ampliar

Percorrido de listas dentro dun orzamento de traballo

A selección de candidatos require percorrer listas de publicación para atopar documentos potencialmente relevantes. Escanear exhaustivamente cada lista é custoso, polo que Photon usa un algoritmo semellante a WAND que percorre só algunhas listas mentres segue tendo en conta as coincidencias nas outras.

O algoritmo divide as listas en dous grupos. As listas de condución avanzan o percorrido e propoñen documentos candidatos. As listas de sondaxe contribúen ás puntuacións deses candidatos pero non xeran candidatos por si mesmas.

A puntuación de candidatos combina a cobertura ponderada de termos de consulta e unha contribución de frecuencia, coa normalización da lonxitude do documento e un límite nas ganancias de termos repetidos. Photon comproba primeiro a presenza de termos nas matrices e nos mapas de bits para limitar a puntuación máxima posible de cada segundo candidato. Le as frecuencias exactas dos termos só para os candidatos que aínda poidan cumprir o limiar de selección.

A selección procede entón en tres pasos:

• Percorrido: Comezar cun requisito estrito de cobertura de consultas. Se se atopan moi poucos candidatos, repetir cun requisito relaxado.
• Retención: Os candidatos mantéñense nun conxunto delimitado usando unha puntuación que combina cobertura e frecuencia. A medida que os principais candidatos recollidos melloran, o limiar de admisión sube.
• Selección final: Os resultados finais para a pasada escóllense do conxunto retido en función das puntuacións de frecuencia. Cada campo executa a súa propia pasada e os resultados únense usando pesos de campo.

O algoritmo produce un conxunto de candidatos de documentos relevantes que se usarán nunha ordenación posterior.

Ampliar

Docblob

Despois de que se seleccionan as páxinas candidatas, a fase de ordenación necesita frecuencias de termos, cobertura de campos e as localizacións e proximidade das aparicións. Obter estes datos a través do índice invertido requiriría accesos espallados a través de moitos pares de termo-documento. En Photon, almacenamos un rexistro compacto por documento chamado docblob que contén frecuencias de termos, en que campos apareceu un termo e onde ocorreu no documento. Como resultado, ordenar un candidato só require unha busca por documento.

O formato está construído para evitar descodificar máis do necesario. Dentro dun docblob, os campos agrúpanse por analisador de texto. Cada grupo almacena unha lista de termos ordenada codificada con Elias-Fano, polo que se pode buscar un termo de consulta directamente sen ampliar toda a lista primeiro. Un máscara de campo marca onde se produciu un termo, un reconto de frecuencia fai un seguimento de con que frecuencia, e as posicións reais viven en bloques separados por par de termo-campo codificados como diferenzas de posición. Só se descodifican os bloques dos termos que coinciden realmente, mentres que todo o demais do rexistro permanece no formato comprimido.

Esa descodificación selectiva permítelle a docblob admitir o almacenamento de máis datos por documento sen un aumento de custo proporcional. O crecemento do rexistro non forza máis traballo por busca, porque a ordenación só toca as pezas relevantes para os termos coincididos en lugar de todo o rexistro.

Ampliar

Lecturas por lotes e traballo coa memoria

Aínda coas representacións de datos máis eficientes, a RAM agótase antes que outros recursos, polo que con frecuencia necesitamos acceder aos datos almacenados no disco. Photon usa lecturas de disco asíncronas e unha caché optimizada para lecturas por lotes para acelerar estes accesos, recortando o tempo de espera por solicitude. Isto contribúe a unha mellora significativa na latencia de cola en comparación co sistema anterior.

Ampliar

Esperas de disco superpostas

A ordenación require obter as características dun cento de documentos situados en diferentes partes dun ficheiro. O noso sistema antigo usaba mmap para mapear o ficheiro no espazo de enderezos virtual para que puidese lerse a través de punteiros de memoria. Con todo, acceder a unha páxina que estaba ausente da memoria aínda requiría unha lectura de disco. O fío tiña que esperar polos datos antes de continuar coa computación, e este tempo de espera sumábase cando o proceso necesitaba ler rexistros en frío secuencialmente.

Photon aproveita o feito de que os desprazamentos de rexistros se coñecen de antemán, polo que podemos enviar varias lecturas á vez. Isto xérao o reactor: os fíos de traballo adicados envían lotes a través de io_uring e pasan os datos que len ao código que os chama. Cada fío mantén o seu propio io_uring; os lotes envíanse ao reactor con menos carga. Os descritores de ficheiros previamente rexistrados e as reservas de búfer reducen a sobrecarga das lecturas repetidas. Esta execución asíncrona permite que as esperas de varias operacións se superpoñan, o que reduce a latencia de cola.

Reducir o número de accesos á unidade

Antes de enviar lecturas, Photon comproba todo o lote na caché en memoria. Só as solicitudes de rexistros que faltan van ao disco; os datos lidos entón encherán a caché.

A caché está deseñada para lecturas por lotes. En concreto:

• Non hai ningunha asignación separada nun acerto. En cambio, os datos cópianse nun búfer preparado de antemán polo código que chama.
• Non hai ningunha adquisición de bloqueo por parte do lector. En cambio, comproba a versión dos datos e reintenta se entra en conflito cunha escritura.
• Utiliza a expulsión CLOCK, en lugar de requirir actualizacións a unha lista LRU compartida en cada lectura.
• Utiliza a prebusca da caché da CPU, onde os metadatos e os datos para os próximos rexistros solicítanse de antemán.

Estas optimizacións reducen a latencia sen prexudicar o rendemento nas cargas de traballo que nos importan.

Construír e actualizar o índice por separado da atención

En Photon, a construción de índices e a atención de consultas execútanse en nós diferentes. Os indexadores transforman os datos en estruturas de almacenamento listas, mentres que os nós de servizo os len e realizan a recuperación e a ordenación. Como resultado, a construción de índices non compite coas consultas de busca pola CPU, e os recursos para estas tarefas pódense escalar de forma independente.

Esta separación aborda os gurgullos de estrangulamento de recuperación e sincronización presentes na implementación anterior. Dado que a construción de índices se executaba dentro do mesmo clúster que servía consultas, recuperar un nodo fallido ou engadir unha nova copia dos datos podía significar reindexar documentos no mesmo sitio, un proceso que levaba días e aumentaba as respostas parciais durante a recuperación. Photon elimina ese acoplamento; os indexadores execútanse como traballos distribuídos que producen estruturas de índice versionadas e listas para servir independentemente dos nós de servizo, polo que construír a seguinte versión do índice xa non compite co tráfico en directo.

Ampliar

Preparación e construción distribuída

Unha compilación comeza seleccionando documentos para o índice activo e producindo a exportación de orixe. O controlador rexistra a versión de orixe, as táboas de entrada e o número agardado de fragmentos. Os traballos de MapReduce en YTsaurus preparan texto, metadatos, fragmentos, características e incrustacións precalculadas en táboas versionadas e particionadas por fragmento. Cada indexador transmite a táboa preparada, constrúe as estruturas para o seu fragmento e une os segmentos de texto. O índice listo, xunto cunha descrición dos seus compoñentes, cárgase no almacenamento de obxectos.

O reconto de fragmentos e o número de indexadores que se executan concorrentemente configúranse de forma independente, polo que unha compilación pode executarse en varias ondas, ou se poden asignar máis máquinas para traballar en paralelo. A preparación distribuída e os indexadores paralelos permiten que o índice web completo se constrúa nun número de horas dun só díxito, unha mellora significativa sobre o sistema anterior.

Despregar unha nova versión

Antes do despregamento, o controlador comproba que o novo índice estea listo. Se os datos están incompletos, o despregamentobloquéase automaticamente.

Cando hai varios grupos de servizo, o controlador anovados un á vez. Primeiro elimina un grupo do encamiñamento do intermediario e iníciao na nova versión do índice. Antes de servir solicitudes, os fragmentos pasan por unha etapa de quecemento separada baseada en rexistros de busca, o que prepobla o estado inicial e fai que a transición ao tráfico real sexa máis suave. Despois do quecemento, o controlador comproba o estado do índice e a preparación, e logo devolve o grupo ao encamiñamento. Os outros grupos continúan servindo solicitudes durante este tempo. Como o estado de operación persiste, un reinicio non forza a que unha compilación comece de novo; o controlador pode reengancharse á preparación xa en progreso, reutilizar un resultado listo ou continuar cunha rotación interrompida dende o paso gardado.

Os tempos de actualización de datos difieren entre os sectores de busca. Para os sectores con altos requisitos de frescura, a entrega de documentos leva un número de minutos dun só díxito. Pódese despregar unha copia adicional dos datos nunha media hora aproximadamente; os índices listos cárganse e adjúntanse aos fragmentos sen reindexar os documentos de orixe.

Ampliar

Migración e validación dentro da nosa pila de busca

O noso primeiro obxectivo era substituír o sistema antigo por un motor que preservase a funcionalidade e a calidade da busca á vez que reducía os tempos de resposta. Validamos Photon por etapas, comezando con probas de carga reproducibles e avaliacións de calidade fóra de liña antes de pasar ao tráfico en directo. Photon alimenta agora a recuperación e a ordenación na nosa pila de busca de produción, con tempos de resposta substancialmente menores que os do sistema antigo.

Probas de carga e avaliacións

Para as probas de rendemento, construímos unha ferramenta de probas de carga que reproduce consultas dos nosos rexistros de busca a taxas de chegada configurables. Compara resultados entre execucións e aplica probas estatísticas para avaliar se as diferenzas de rendemento observadas son consistentes. Por separado, avaliamos Photon e o sistema antigo nos mesmos conxuntos de datos nos nosos sistemas de avaliación fóra de liña internos para comprobar se había regresións de calidade.

Despois destas comprobacións, enviamos consultas en directo a ambos os motores simultaneamente mediante tráfico na sombra. Isto permitiunos comparar o seu rendemento e resultados en cargas de traballo de produción antes de cambiar que motor servía aos usuarios. A continuación, activamos Photon para pequenos subconxuntos de usuarios e ampliamos gradualmente o lanzamento, monitorizando a calidade e o rendemento en todo momento. A primeira versión pasou as probas de aceptación sen regresións de calidade, e continuamos o lanzamento ata que Photon serviu todo o tráfico de produción.

Melhoras medidas en produción

No noso fluxo de traballo de produción, o tempo de resposta p99 baixou de aproximadamente 800 ms no sistema antigo a aproximadamente 65 ms en Photon. Esta medición cobre todas as etapas dentro de Photon, pero exclúe as etapas posteriores na pila de busca de nivel superior. Tampouco observamos xa os picos de latencia asociados anteriormente co cambio de versións de índices.

Photon usa aproximadamente un 20 % menos de máquinas de servizo equivalentes que os nós de contido do sistema antigo mentres almacena aproximadamente 2,5 veces máis datos por documento. Despois da migración, usamos estes datos adicionais para mellorar a calidade da ordenación máis aló da do sistema antigo.

Photon tamén reduce a cantidade de datos que deben permanecer na memoria. Fixar o mesmo conxunto de datos de Photon na RAM con mlock requiriría un estimado de 4,6 veces máis memoria residente da que Photon usa actualmente.

Avaliación do preaxuste rápido da API de busca

Tamén usamos Photon como base para un novo preaxuste rápido para a nosa API de busca, deseñado para cargas de traballo sensibles á latencia. Segundo as nosas medicións, a latencia de chamada de busca única para o preaxuste rápido é de 160 ms en p50 e 230 ms en p95, inferior ou comparable aos números informados por outros provedores da API de busca, aínda que os percentís de cola informados difiren.

Avaliamos o preaxuste rápido en seis puntos de referencia axentes: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 e SEAL-Hard. A través destas avaliacións, tivo o custo estimado total de modelo máis busca máis baixo e a puntuación de tarefa agregada máis alta entre as configuracións probadas.

O preaxuste rápido combina Photon cunha ordenación optimizada para fluxos de traballo axentes, ofrecendo un rendemento comparable ao preaxuste predeterminado a un custo substancialmente menor. Con todo, vén cun compromiso nunha calidade de busca máis ampla. O preaxuste rápido usa menos computación para a ordenación que o preaxuste predeterminado. Nos puntos de referencia internos que abranguen consultas de cola longa, cobertura ampla e diversidade de resultados, obtén unha puntuación 0,24 puntos máis baixa en relevancia e aproximadamente 3 puntos porcentuais máis baixa en dispoñibilidade de respostas. Consideramos que este é un compromiso sensato para os fluxos de traballo axentes, xa que o propio razoamento e coñecemento do modelo poden axudar a compensar a diferenza.

Ampliar

Recomendamos o preaxuste rápido para tarefas axentes do día a día. Para preguntas máis desafiantes ou ambiguas que son menos sensibles ao tempo, o preaxuste predeterminado ofrece unha calidade máis robusta, o que xustifica a súa maior latencia e custo.

Conclusión

Estamos a mover constantemente a nosa pila de busca cara a unha infraestrutura propia baseada en Rust. Substituír o motor de código aberto por Photon, o noso motor personalizado de recuperación e ordenación, é o último paso. Photon dános o control total sobre as representacións de datos, como se organizan as lecturas e como se implementan os novos índices, permitíndonos optimizar cada capa para as nosas cargas de traballo.

Photon permitiu unha busca máis rápida nos produtos de Perplexity e ofrece a base para o noso novo preaxuste rápido na API de busca. Tras a migración, a latencia de recuperación e ordenación p99 baixou de aproximadamente 800 ms a 65 ms. Os nosos formatos de datos compactos tamén nos permiten almacenar 2,5 veces máis datos por documento, dándolle á recuperación e á ordenación acceso a información de documentos máis rica.

O preaxuste rápido ofrece unha latencia de chamada de busca única de 160 ms en p50 e 230 ms en p95. Nos seis puntos de referencia axentes evaluados, reduciu o custo estimado de modelo máis busca por tarefa nun 68 % en relación ao preaxuste predeterminado mentres mantiña unha calidade de tarefa agregada comparable. Estes resultados demostran os beneficios prácticos da infraestrutura deseñada ao redor das nosas cargas de traballo de busca, tanto para os produtos de Perplexity coma para os desenvolvedores que crean coa nosa API.

Seguimos a mellorar o rendemento e a eficiencia de almacenamento de Photon. O noso obxectivo é admitir un índice máis grande e datos de documentos máis ricos no mesmo hardware mantendo a busca rápida a medida que medran as nosas cargas de traballo.

Cita

@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}
}