El 24 de septiembre de 2026, Perplexity presentó Photon como el motor interno de recuperación y clasificación que ya utiliza en su búsqueda de producción. La empresa cifra en unos 65 milisegundos el p99 de sus etapas internas, frente a unos 800 milisegundos en el sistema anterior; esa cifra no abarca las fases posteriores de la búsqueda. Fast Search, por su parte, es una modalidad de la API basada en Photon, con mediciones propias.
Qué hace Photon en la búsqueda de Perplexity
Photon recupera páginas candidatas de la web y las ordena para la búsqueda de Perplexity. No es un buscador de consumo independiente: trabaja dentro de la infraestructura que selecciona resultados para el servicio de búsqueda con IA.
El 24 de septiembre, Perplexity también anunció el lanzamiento de Fast Search en su API de búsqueda. Es una configuración orientada a flujos de trabajo con agentes y combina Photon con una clasificación más ligera. Por eso, sus cifras de latencia corresponden a llamadas de API y no deben confundirse con el p99 del motor en producción.
Cómo procesa Photon una consulta
Una solicitud pasa por un balanceador de carga hasta un broker, que elige un grupo de shards —particiones del índice— y distribuye el trabajo. Los shards recuperan candidatos y los clasifican; después, el broker reúne los resultados y obtiene campos clave de los documentos seleccionados.
Cómo se construye el índice
Photon separa la construcción del índice de la atención de consultas. Pillar prepara los datos de origen en tablas de YTsaurus; los indexadores crean estructuras por shard y el controlador despliega las nuevas versiones entre los grupos que atienden las consultas.
Para recuperar candidatos, Photon utiliza un índice invertido y distintas representaciones para listas de términos cortas y largas. También agrupa lecturas de disco de forma asíncrona y comprueba la caché antes de recurrir al disco. Perplexity afirma que esta arquitectura necesita alrededor de un 20 % menos de máquinas equivalentes para atender consultas y almacena unas 2,5 veces más datos por documento que el sistema anterior. La empresa añade que puede construir el índice web completo en un número de horas de una sola cifra.
Qué mide el p99 de latencia
Perplexity compara el p99 de producción del flujo de recuperación y clasificación del sistema anterior —unos 800 ms— con el de las etapas internas de Photon —unos 65 ms—. El p99 es el tiempo por debajo del cual se completó el 99 % de las solicitudes medidas. En el caso de Photon, la cifra termina antes de las etapas posteriores del sistema de búsqueda de nivel superior.
| Sistema | Latencia p99 comunicada | Alcance |
| Sistema anterior de recuperación y clasificación | Unos 800 ms | Flujo de recuperación y clasificación en producción |
| Photon | Unos 65 ms | Etapas internas de recuperación y clasificación; excluye las fases posteriores de búsqueda |
Fast Search: latencia, benchmarks y coste
Perplexity comunica para una llamada individual de Fast Search una latencia de 160 ms en p50 y 230 ms en p95. Son percentiles de una llamada a la API, no la misma medición que el p99 de producción de Photon.
En seis benchmarks —WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 y SEAL-Hard—, con 3.554 tareas seleccionadas, Perplexity comunicó una puntuación del 64,3 % para Fast Search y del 64,0 % para su configuración predeterminada. El coste estimado de modelo más búsqueda para ese conjunto fue de 59,73 dólares y 187,60 dólares, respectivamente.
| Métrica | Fast Search | Configuración predeterminada | Contexto |
| Puntuación | 64,3 % | 64,0 % | Seis benchmarks y 3.554 tareas seleccionadas |
| Coste estimado de modelo más búsqueda | 59,73 dólares | 187,60 dólares | Coste estimado para el mismo conjunto de tareas |
| Relevancia DCG | 2,21 | 2,45 | Pruebas internas de consultas de cola larga |
| Disponibilidad de respuestas | 0,567 | 0,596 | Pruebas internas de consultas de cola larga |
La tarifa de la API es otra medida: la documentación de Perplexity fija Fast Search en 1 dólar por cada 1.000 solicitudes exitosas. Para activarlo, la solicitud a POST /search debe incluir search_type: "fast"; max_results admite valores de 1 a 20.