Photon: Construcción de un motor de recuperación y clasificación desde cero

Cómo los formatos de datos especializados, las lecturas por lotes y la separación de la creación de índices de la atención de consultas mejoran la búsqueda nativa de IA.

AutoresPerplexity Engineering

Introducción

La pila de búsqueda nativa de IA de Perplexity recupera y clasifica las páginas candidatas, sacando a la superficie el contenido más relevante para que el modelo fundamente sus respuestas. Originalmente, esta etapa se ejecutaba en un motor de código abierto que adaptamos a nuestro sistema. Sin embargo, a medida que nuestro índice y nuestras cargas de trabajo crecían, alcanzamos límites estrictos en cuanto a costes, latencia de cola y tiempo de recuperación de nodos que no podíamos resolver dentro de la plataforma de terceros existente.

Para superar estos retos, construimos Photon, un nuevo motor interno de recuperación y clasificación. Esto continúa con nuestro enfoque de construir infraestructura de búsqueda basada en IA desde cero, tal como lo hicimos con CobbleDB, nuestro almacén distribuido de clave-valor para servir registros de páginas, y nuestra API de búsqueda.

Photon utiliza formatos de datos compactos para leer y decodificar únicamente lo que cada consulta necesita, con almacenamiento en caché consciente de lotes y lecturas asíncronas para reducir el acceso al disco y solapar las esperas. La creación de índices se ejecuta de forma independiente a la atención de consultas, actualizando un grupo de servicio a la vez y calentando sus cachés antes de dirigirle las consultas activas.

Photon ahora impulsa nuestra canalización de búsqueda y es también la base de una nueva opción predefinida rápida para nuestra API de búsqueda, con una latencia de llamada de búsqueda única de 160 ms en p50 y 230 ms en p95. A lo largo de seis pruebas de rendimiento públicas, la opción predefinida rápida redujo el coste estimado de modelo más búsqueda por tarea en un 68%, manteniendo una calidad de tarea agregada comparable a la de la opción predefinida predeterminada. La lanzamos hoy para que los desarrolladores puedan acceder a estas mejoras.

Latencia de llamadas de búsqueda única autoinformada. PPLX Fast informa una latencia p50 de 160 ms y una latencia p95 de 230 ms. Exa Instant informa p90, no p95, para su valor de cola alta; los valores de cola alta de Parallel no están publicados. Los percentiles informados y las configuraciones de medición no constituyen una comparación controlada en igualdad de condiciones.
Calidad de tarea agregada frente al coste total estimado de modelo más búsqueda para las mismas 3554 tareas seleccionadas. Las puntuaciones están ponderadas por el recuento de tareas y los costes cubren el conjunto completo de tareas. PPLX Fast obtiene una puntuación de 64,3% a 59,73 $, frente al 64,0% a 187,60 $ de la opción predefinida de PPLX predeterminada, lo que supone un coste estimado aproximadamente un 68% menor para el mismo número de tareas.

Lo que requiere el motor de recuperación y clasificación

Para cada consulta, el motor de recuperación y clasificación busca en un índice grande y distribuido para seleccionar y ordenar un pequeño conjunto de páginas relevantes dentro del presupuesto de latencia de la pila de búsqueda. El sistema también debe mantener el índice actualizado a medida que llegan nuevas páginas y las existentes cambian, sin permitir que ese trabajo ralentice las consultas activas.

Evaluamos varias opciones de código abierto y elegimos un motor de recuperación y clasificación maduro y de propósito general que satisfacía nuestras necesidades iniciales. Luego lo adaptamos a nuestra arquitectura y cargas de trabajo, manteniendo una latencia y un rendimiento estables a escala de producción.

Dónde se quedaba corto nuestro sistema anterior

Mantuvimos nuestra propia bifurcación para adaptar el motor a nuestro creciente índice, pero abordar las limitaciones clave requirió cada vez más rediseñar grandes partes de la plataforma. Varias restricciones resultaron difíciles de resolver sin cambios arquitectónicos fundamentales:

1. Costes de escala. Tanto el número de documentos que almacenamos como la cantidad de datos por documento que necesitamos recuperar y clasificar han ido creciendo con el tiempo. Este escalado ejerció presión sobre nuestro hardware, especialmente sobre la cantidad de RAM disponible. Para controlar los costes, necesitábamos representaciones de datos más compactas y un control más preciso sobre lo que permanece en la memoria y lo que se lee del disco bajo demanda.

2. Mala latencia de cola. En el tráfico de producción, el tiempo de respuesta p99 del sistema antiguo era de unos 800 ms. El conjunto de datos superaba la RAM disponible, por lo que no pudimos usar mlock para mantenerlo íntegramente en la memoria. El acceso a datos no residentes podía desencadenar fallos de página importantes, lo que paralizaba la ejecución de consultas mientras el sistema operativo leía del disco.

El motor también fusionaba periódicamente su índice de disco principal con índices más pequeños vaciados de la memoria. Durante este proceso de fusión del índice de disco, el número de fallos de página aumentaba aún más, y la latencia p99 alcanzaba aproximadamente 1,2 s durante 10-15 minutos. A medida que las cachés se calentaban, tanto la frecuencia de los fallos de página como la latencia disminuían, lo que sugería que las lecturas en frío eran un factor importante en los picos. La precarga de datos y el calentamiento del índice redujeron los picos, pero no abordaron adecuadamente la alta latencia de cola.

3. Recuperación y sincronización prolongadas. En el sistema anterior, desplegar un clúster adicional y sincronizar sus datos podía llevar más de una semana. La sincronización también era necesaria al añadir grupos de nodos para albergar copias de datos adicionales o al recuperarse de fallos en los nodos. Durante la recuperación, una mayor proporción de las respuestas de búsqueda eran parciales, lo que reducía las puntuaciones de calidad de la respuesta final.

En última instancia, concluimos que sería más sencillo y económico construir desde cero en lugar de seguir adaptando y manteniendo nuestra bifurcación. Aprovechando nuestra experiencia en la operación del sistema anterior, un pequeño equipo de ingeniería trabajó junto a un enjambre de agentes de codificación persistentes para construir Photon.

Dónde encaja Photon en la pila de búsqueda

Photon está diseñado para dos flujos de trabajo principales: atender solicitudes de búsqueda e ingerir actualizaciones de la canalización de procesamiento.

Una solicitud del servicio de búsqueda de nivel superior llega al agente de transacciones de Photon a través de un equilibrador de carga. El agente de transacciones selecciona un grupo de particiones y reenvía la solicitud a cada partición, supervisando los tiempos de espera y emitiendo solicitudes adicionales cuando es necesario.

Cada partición realiza la recuperación, la clasificación inicial y la clasificación de segunda etapa, y luego devuelve sus mejores candidatos al agente de transacciones. El agente de transacciones combina estos candidatos en una sola lista clasificada y recupera los campos clave de los documentos para las páginas seleccionadas de las particiones relevantes. A continuación, devuelve estos resultados al servicio de búsqueda de nivel superior, que recopila el contenido de la página necesario para que el agente genere una respuesta fundamentada.

Las actualizaciones de los índices siguen una ruta separada. Pillar, nuestra capa de publicación, prepara los datos y los almacena en tablas de YTsaurus. Los indexadores convierten estas tablas en estructuras de índice que las particiones pueden cargar para la búsqueda. El controlador coordina la preparación de datos, la creación de índices y el despliegue de nuevas versiones de índices en los grupos de servicio. Antes de gestionar el tráfico activo, cada partición reproduce consultas de búsqueda reales para calentar sus cachés.

Una consulta se desplaza desde el servicio de búsqueda de nivel superior a través del equilibrador de carga y el agente de transacciones hasta un grupo de particiones seleccionado. Cada partición recupera y clasifica a los candidatos; el agente de transacciones fusiona los resultados, recupera los campos de los documentos para las páginas seleccionadas y los devuelve al servicio de búsqueda de nivel superior. Los pasos numerados muestran el orden. Las flechas sólidas transportan solicitudes y las flechas discontinuas devuelven los resultados. Las etiquetas de fase del lado izquierdo distinguen la selección de candidatos de las lecturas de resúmenes.

Diseño de Photon para nuestros flujos de trabajo

Tres decisiones de diseño hacen que Photon se adapte perfectamente a nuestra carga de trabajo: representaciones de datos compactas, almacenamiento en caché y lecturas de disco asíncronas, y la separación de las actualizaciones de los índices de la atención de consultas.

Representaciones de datos para la recuperación y la clasificación

La recuperación y la clasificación acceden a los datos de los documentos de forma diferente. La recuperación léxica comienza con los términos de búsqueda y encuentra los documentos que los contienen. A continuación, la clasificación necesita información detallada sobre cada documento seleccionado, incluidas las frecuencias de los términos y sus posiciones.

Photon utiliza dos representaciones complementarias para admitir estos patrones de acceso. Un índice invertido almacena una lista de documentos coincidentes para cada término, llamada lista de publicaciones (posting list), para admitir la selección de candidatos. Los registros independientes por documento proporcionan los datos necesarios para la clasificación. También optimizamos la forma en que se almacenan y recorren las listas de publicaciones para mejorar la selección bajo un presupuesto de trabajo fijo.

Las representaciones de datos especializadas nos permiten almacenar datos clave de forma más eficiente. Un índice invertido más compacto reduce la cantidad de datos leídos o movidos por consulta, lo que mejora la latencia al eliminar operaciones de E/S innecesarias. Estos formatos también hacen posible comprobar si un documento aparece en una lista sin decodificarlo por completo, una propiedad en la que se basa nuestra lógica de recorrido para controlar la cantidad de trabajo que realiza una consulta bajo un presupuesto fijo. La optimización de los registros por documento permite almacenar más datos por documento para la clasificación, a la vez que reduce los costes de escala asociados con nuestro sistema anterior.

El índice invertido

Para cada término, el índice invertido almacena una lista de publicaciones. Estas listas pueden oscilar entre un puñado de documentos y millones, por lo que ningún formato único funciona bien para todas las listas. Photon elige el formato en función del número de documentos que contienen el término.

Las listas cortas utilizan una representación en línea que cabe dentro de una sola página y no requiere ninguna tabla de bloques. Las listas más largas que no caben en el formato en línea se dividen en bloques que cubren rangos fijos de identificadores de documentos. La representación de cada bloque depende de su densidad: los bloques dispersos almacenan matrices ordenadas de desplazamientos de ID de documento, mientras que los bloques densos utilizan mapas de bits. Los bloques dispersos utilizan la búsqueda en salto (galloping search), que avanza en pasos cada vez mayores para omitir regiones de la lista. Los bloques densos permiten comprobaciones de pertenencia consultando el bit correspondiente a un documento.

La frecuencia de consulta de un término determina dónde se coloca su lista de publicaciones en el disco. Las listas consultadas con frecuencia se almacenan cerca unas de otras, concentrando los datos activos en una región de almacenamiento más pequeña. Dentro de cada lista, los documentos se ordenan mediante una señal de utilidad independiente para que los candidatos más prometedores se encuentren antes.

Photon elige una representación de lista de publicaciones por longitud y densidad de bloque. Las listas cortas caben en línea dentro de una página. Las listas más largas se dividen en rangos de ID de documento fijos, con matrices de desplazamiento ordenadas para bloques dispersos y mapas de bits para bloques densos.

Recorrido de listas dentro de un presupuesto de trabajo

La selección de candidatos requiere recorrer las listas de publicaciones para encontrar documentos potencialmente relevantes. El escaneo exhaustivo de cada lista es costoso, por lo que Photon utiliza un algoritmo de tipo WAND que recorre solo algunas listas sin dejar de tener en cuenta las coincidencias en las demás.

El algoritmo divide las listas en dos grupos. Las listas de control avanzan en el recorrido y proponen documentos candidatos. Las listas de sondeo contribuyen a las puntuaciones de dichos candidatos, pero no generan candidatos por sí mismas.

La puntuación de candidatos combina la cobertura ponderada de los términos de consulta y una contribución de frecuencia, con la normalización de la longitud del documento y un límite en las ganancias de los términos repetidos. Photon comprueba primero la presencia de términos en las matrices y mapas de bits para acotar la puntuación máxima posible de cada candidato. Lee las frecuencias exactas de los términos solo para los candidatos que aún puedan alcanzar el umbral de selección.

A continuación, la selección se realiza en tres pasos:

  • Recorrido: comience con un requisito estricto de cobertura de consultas. Si se encuentran muy pocos candidatos, repita con un requisito relajado.
  • Retención: los candidatos se mantienen en un conjunto acotado utilizando una puntuación que combina la cobertura y la frecuencia. A medida que los mejores candidatos recopilados mejoran, el umbral de admisión aumenta.
  • Selección final: los resultados finales de la pasada se eligen del conjunto retenido en función de las puntuaciones de frecuencia. Cada campo ejecuta su propia pasada y los resultados se combinan utilizando ponderaciones de campo.

El algoritmo produce un conjunto de candidatos de documentos relevantes que se utilizarán en una clasificación posterior.

Recorrido de candidatos acotados ilustrativo. Las listas de control proponen documentos, mientras que los límites superiores permiten podar los candidatos que están por debajo del umbral de admisión actual sin necesidad de leer las listas de sondeo ni las frecuencias exactas. El umbral aumenta a medida que mejora el conjunto retenido. Las puntuaciones se inventan a efectos ilustrativos y los candidatos retenidos no garantizan ser un top-k exacto.

Docblob

Una vez seleccionadas las páginas candidatas, la fase de clasificación necesita las frecuencias de los términos, la cobertura de los campos y las ubicaciones y la proximidad de las apariciones. Obtener estos datos a través del índice invertido requeriría accesos dispersos en muchos pares término-documento. En Photon, almacenamos un registro compacto por documento llamado docblob que contiene las frecuencias de los términos, los campos en los que apareció un término y el lugar del documento en el que ocurrió. Como resultado, clasificar a un candidato solo requiere una búsqueda por documento.

El formato está diseñado para evitar decodificar más de lo necesario. Dentro de un docblob, los campos se agrupan por analizador de texto. Cada grupo almacena una lista de términos ordenada codificada con Elias-Fano, de modo que se puede buscar un término de consulta directamente sin necesidad de expandir toda la lista primero. Una máscara de campo marca dónde apareció un término, un recuento de frecuencias realiza un seguimiento de cuántas veces lo hizo, y las posiciones reales residen en bloques separados por par término-campo codificados como diferencias de posición. Solo se decodifican los bloques de los términos que realmente coincidieron, mientras que todo lo demás del registro permanece en el formato comprimido.

Esa codificación selectiva permite a docblob admitir el almacenamiento de más datos por documento sin un aumento proporcional del coste. El crecimiento del registro no obliga a realizar más trabajo por cada búsqueda, porque la clasificación solo accede a las piezas relevantes para los términos coincidentes en lugar de a todo el registro.

Un docblob agrupa los datos de clasificación en un registro compacto por documento. Los términos de consulta se buscan en una lista de términos codificada con Elias-Fano; las máscaras de campo, las frecuencias y los bloques de posición proporcionan los datos necesarios para los términos coincidentes, mientras que los términos no relacionados permanecen comprimidos. Los ID de los términos y las posiciones son ilustrativos.

Lecturas por lotes y trabajo con la memoria

Incluso con unas representaciones de datos más eficientes, la RAM sigue agotándose antes que otros recursos, por lo que con frecuencia necesitamos acceder a los datos almacenados en el disco. Photon utiliza lecturas de disco asíncronas y una caché optimizada para lecturas por lotes para acelerar estos accesos, recortando el tiempo de espera por solicitud. Esto contribuye a una mejora significativa en la latencia de cola en comparación con el sistema anterior.

Photon comprueba un lote de desplazamientos de registros conocidos en su caché antes de emitir lecturas de disco. Los aciertos de caché se copian en un búfer preparado; los fallos se envían a través de io_uring para que las esperas de disco puedan solaparse, y los datos devueltos llenan la caché. Los registros y las líneas de tiempo son esquemáticos, no latencias medidas.

Solapamiento de las esperas de disco

La clasificación requiere obtener las características de un centenar de documentos ubicados en diferentes partes de un archivo. Nuestro sistema anterior utilizaba mmap para asignar el archivo al espacio de direcciones virtuales para poder leerlo a través de punteros de memoria. Sin embargo, acceder a una página ausente de la memoria seguía requiriendo una lectura de disco. El hilo tenía que esperar a que estuvieran los datos antes de continuar con el cálculo, y este tiempo de espera se acumulaba cuando el proceso necesitaba leer registros en frío secuencialmente.

Photon aprovecha el hecho de que los desplazamientos de los registros se conocen de antemano, por lo que podemos enviar varias lecturas a la vez. Esto lo gestiona el reactor: los hilos de trabajo dedicados envían lotes a través de io_uring y pasan los datos leídos al código que realiza la llamada. Cada hilo mantiene su propio io_uring; los lotes se envían al reactor con menos carga. Los descriptores de archivos prerregistrados y las reservas de búferes reducen la sobrecarga de las lecturas repetidas. Esta ejecución asíncrona permite que las esperas de varias operaciones se solapen, lo que reduce la latencia de cola.

Reducción del número de accesos a la unidad

Antes de enviar las lecturas, Photon comprueba todo el lote en la caché en memoria. Solo las solicitudes de registros faltantes van al disco; a continuación, los datos leídos llenan la caché.

La caché está diseñada para lecturas por lotes. Específicamente:

  • No hay asignación separada en caso de acierto. En su lugar, los datos se copian en un búfer preparado de antemano por el código que realiza la llamada.
  • El lector no adquiere ningún bloqueo. En su lugar, comprueba la versión de los datos y lo vuelve a intentar si entra en conflicto con una escritura.
  • Utiliza la expulsión CLOCK, en lugar de requerir actualizaciones a una lista LRU compartida en cada lectura.
  • Utiliza la prebúsqueda en la caché de la CPU, donde los metadatos y los datos de los próximos registros se solicitan de antemano.

Estas optimizaciones reducen la latencia sin perjudicar el rendimiento en las cargas de trabajo que nos importan.

Creación y actualización del índice de forma independiente al servicio

En Photon, la creación de índices y la atención de consultas se ejecutan en diferentes nodos. Los indexadores transforman los datos en estructuras de almacenamiento listas, mientras que los nodos de servicio los leen y realizan la recuperación y la clasificación. Como resultado, la creación de índices no compite con las consultas de búsqueda por la CPU, y los recursos para estas tareas se pueden escalar de forma independiente.

Esta separación aborda los cuellos de botella de recuperación y sincronización presentes en la implementación anterior. Dado que la creación de índices se ejecutaba dentro del mismo clúster que atendía las consultas, recuperar un nodo fallido o añadir una nueva copia de los datos podía significar reindexar los documentos en el mismo lugar, un proceso que llevaba días y aumentaba las respuestas parciales durante la recuperación. Photon elimina dicho acoplamiento; los indexadores se ejecutan como trabajos distribuidos que producen estructuras de índice versionadas y listas para servir de forma independiente a los nodos de servicio, por lo que construir la siguiente versión del índice ya no compite con el tráfico activo.

La creación de índices se ejecuta de forma independiente a la atención de consultas activas. Pillar exporta los datos de origen, YTsaurus prepara tablas versionadas por partición, y los indexadores en paralelo escriben estructuras de índice listas para servir en el almacenamiento de objetos. Los nodos de servicio cargan esas estructuras para la recuperación y la clasificación; la concurrencia del indexador y el recuento de particiones se configuran de forma independiente.

Preparación y construcción distribuida

Una compilación comienza seleccionando los documentos para el índice activo y produciendo la exportación de origen. El controlador registra la versión de origen, las tablas de entrada y el número esperado de particiones (shards). Los trabajos de MapReduce en YTsaurus preparan el texto, los metadatos, los fragmentos, las características y las incrustaciones precalculadas en tablas versionadas particionadas por partición. Cada indexador transmite la tabla preparada, construye las estructuras para su partición y fusiona los segmentos de texto. El índice listo, junto con una descripción de sus componentes, se carga en el almacenamiento de objetos.

El recuento de particiones y el número de indexadores que se ejecutan simultáneamente se configuran de forma independiente, por lo que una compilación puede ejecutarse en varias oleadas, o se pueden asignar más máquinas para trabajar en paralelo. La preparación distribuida y los indexadores en paralelo permiten construir todo el índice web en un número de horas de un solo dígito, una mejora significativa con respecto al sistema anterior.

Despliegue de una nueva versión

Antes del despliegue, el controlador comprueba que el nuevo índice esté listo. Si los datos están incompletos, el despliegue se bloquea automáticamente.

Cuando hay varios grupos de servicio, el controlador los actualiza uno a uno. Primero, elimina un grupo del enrutamiento del agente de transacciones y lo inicia con la nueva versión del índice. Antes de atender solicitudes, las particiones pasan por una fase de calentamiento separada basada en registros de búsqueda, lo que pre-llena el estado inicial y hace que la transición al tráfico real sea más fluida. Tras el calentamiento, el controlador comprueba el estado y la preparación del índice, y luego devuelve el grupo al enrutamiento. Los demás grupos continúan atendiendo solicitudes durante este tiempo. Debido a que el estado de la operación se persiste, un reinicio no obliga a que una compilación comience de nuevo; el controlador puede volver a adjuntarse a una preparación ya en progreso, reutilizar un resultado listo o continuar una rotación interrumpida desde el paso guardado.

Los tiempos de actualización de los datos difieren entre los sectores verticales de búsqueda. En los sectores con altos requisitos de frescura, la entrega de documentos toma un número de minutos de un solo dígito. Se puede desplegar una copia adicional de los datos en aproximadamente media hora; los índices listos se cargan y se adjuntan a las particiones sin necesidad de reindexar los documentos de origen.

El controlador comprueba que un nuevo índice esté completo y, a continuación, rota un grupo de servicio a la vez. Un grupo abandona el enrutamiento del agente de transacciones, carga la nueva versión, calienta sus cachés con consultas del registro de búsqueda y supera las comprobaciones de preparación antes de volver al tráfico. Los demás grupos siguen atendiendo y el estado persistente del controlador permite reanudar una rotación interrumpida.

Migración y validación en nuestra pila de búsqueda

Nuestro primer objetivo era sustituir el sistema antiguo por un motor que conservara la funcionalidad y la calidad de la búsqueda al tiempo que reducía los tiempos de respuesta. Validamos Photon por etapas, empezando por pruebas de carga reproducibles y evaluaciones de calidad sin conexión antes de pasar al tráfico activo. Photon ahora impulsa la recuperación y la clasificación en nuestra pila de búsqueda de producción, con tiempos de respuesta sustancialmente menores que los del sistema antiguo.

Pruebas de carga y evaluaciones

Para las pruebas de rendimiento, construimos una herramienta de prueba de carga que reproduce consultas de nuestros registros de búsqueda a tasas de llegada configurables. Compara los resultados entre ejecuciones y aplica pruebas estadísticas para evaluar si las diferencias de rendimiento observadas son coherentes. Por separado, evaluamos Photon y el sistema antiguo en los mismos conjuntos de datos en nuestros sistemas de evaluación sin conexión internos para comprobar si había regresiones en la calidad.

Tras estas comprobaciones, enviamos consultas activas a ambos motores simultáneamente utilizando tráfico en la sombra. Esto nos permitió comparar su rendimiento y resultados en cargas de trabajo de producción antes de cambiar el motor que daba servicio a los usuarios. A continuación, habilitamos Photon para pequeños subconjuntos de usuarios y ampliamos gradualmente el despliegue, supervisando la calidad y el rendimiento en todo momento. La primera versión superó las pruebas de aceptación sin regresiones en la calidad, y continuamos el despliegue hasta que Photon dio servicio a todo el tráfico de producción.

Mejoras medidas en producción

En nuestro flujo de trabajo de producción, el tiempo de respuesta p99 se redujo de aproximadamente 800 ms en el sistema antiguo a aproximadamente 65 ms en Photon. Esta medición cubre todas las etapas dentro de Photon, pero excluye las etapas posteriores en la pila de búsqueda de nivel superior. Tampoco observamos ya los picos de latencia asociados anteriormente con el cambio de versiones de índice.

Photon utiliza aproximadamente un 20% menos de máquinas de servicio equivalentes que los nodos de contenido del sistema antiguo, a la vez que almacena aproximadamente 2,5 veces más datos por documento. Tras la migración, utilizamos estos datos adicionales para mejorar la calidad de la clasificación por encima de la del sistema antiguo.

Photon también reduce la cantidad de datos que deben permanecer en la memoria. Fijar el mismo conjunto de datos de Photon en la RAM con mlock requeriría una memoria residente estimada en 4,6 veces la que Photon utiliza actualmente.

Evaluación de la opción predefinida rápida de la API de búsqueda

También utilizamos Photon como base para una nueva opción predefinida rápida para nuestra API de búsqueda, diseñada para cargas de trabajo sensibles a la latencia. Según nuestras mediciones, la latencia de llamadas de búsqueda única para la opción predefinida rápida es de 160 ms en p50 y 230 ms en p95, inferior o comparable a las cifras autoinformadas por otros proveedores de la API de búsqueda, aunque los percentiles de cola informados difieren.

Evaluamos la opción predefinida rápida en seis pruebas de rendimiento de agentes: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 y SEAL-Hard. En estas evaluaciones, obtuvo el menor coste total estimado de modelo más búsqueda y la mayor puntuación de tarea agregada entre las configuraciones probadas.

La opción predefinida rápida combina Photon con una clasificación optimizada para flujos de trabajo de agentes, ofreciendo un rendimiento comparable al de la opción predefinida predeterminada a un coste sustancialmente menor. Sin embargo, conlleva un compromiso en cuanto a la calidad de búsqueda general. La opción predefinida rápida utiliza menos capacidad de cálculo para la clasificación que la opción predefinida predeterminada. En las pruebas de rendimiento internas que cubren consultas de cola larga, cobertura amplia y diversidad de resultados, obtiene 0,24 puntos menos en relevancia y aproximadamente 3 puntos porcentuales menos en disponibilidad de respuestas. Creemos que este es un compromiso sensato para los flujos de trabajo de agentes, ya que el propio Razonamiento y conocimiento del modelo pueden ayudar a compensar la diferencia.

Comparación interna de la calidad de recuperación entre la opción predefinida de PPLX predeterminada y PPLX Fast. La relevancia (DCG) cae de 2,45 a 2,21, una disminución de 0,24 puntos; la disponibilidad de respuestas cae de 0,596 a 0,567, una disminución de 2,9 puntos porcentuales. Los dos paneles utilizan líneas de base de ejes distintas y distintas de cero, por lo que las alturas de las barras enfatizan las brechas en lugar de las diferencias proporcionales.

Recomendamos la opción predefinida rápida para las tareas de agentes cotidianas. Para preguntas más complejas o ambiguas que no dependen tanto del tiempo, la opción predefinida predeterminada ofrece una calidad más sólida, lo que justifica su mayor latencia y coste.

Conclusión

Estamos trasladando constantemente nuestra pila de búsqueda a una infraestructura propia basada en Rust. La sustitución del motor de código abierto por Photon, nuestro motor personalizado de recuperación y clasificación, es el paso más reciente. Photon nos otorga el control total sobre las representaciones de datos, la forma en que se organizan las lecturas y cómo se despliegan los nuevos índices, lo que nos permite optimizar cada capa para nuestras cargas de trabajo.

Photon ha permitido una búsqueda más rápida en los productos de Perplexity y proporciona la base para nuestra nueva opción predefinida rápida en la API de búsqueda. Tras la migración, la latencia de recuperación y clasificación p99 cayó de aproximadamente 800 ms a 65 ms. Nuestros formatos de datos compactos también nos permiten almacenar 2,5 veces más datos por documento, lo que proporciona a la recuperación y la clasificación acceso a información de documentos más rica.

La opción predefinida rápida ofrece una latencia de llamada de búsqueda única de 160 ms en p50 y de 230 ms en p95. En las seis pruebas de rendimiento de agentes evaluadas, redujo el coste estimado de modelo más búsqueda por tarea en un 68% en relación con la opción predefinida predeterminada, a la vez que mantuvo una calidad de tarea agregada comparable. Estos resultados demuestran los beneficios prácticos de una infraestructura diseñada en torno a nuestras cargas de trabajo de búsqueda, tanto para los productos de Perplexity como para los desarrolladores que construyen con nuestra API.

Seguimos mejorando el rendimiento de Photon y su eficiencia de almacenamiento. Nuestro objetivo es admitir un índice más grande y datos de documentos más ricos en el mismo hardware, manteniendo la búsqueda rápida a medida que crecen nuestras cargas de trabajo.

Citación

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