Photon: Sıfırdan Getirme ve Sıralama Motoru Oluşturma

Giriş

Perplexity'nin yapay zeka tabanlı arama yığını, aday sayfaları getirir ve sıralar, modelin yanıtlarını dayandırması için en ilgili içeriği yüzeye çıkarır. Aslında bu aşama, sistemimize uyarladığımız açık kaynaklı bir motor üzerinde çalışıyordu. Bununla birlikte, dizinimiz ve iş yüklerimiz büyüdükçe, mevcut üçüncü taraf platformunda çözemediğimiz maliyetler, kuyruk gecikmesi ve düğüm kurtarma süresi konusunda sert sınırlamalara çarptık.

Bu zorlukların üstesinden gelmek için şirket içi yeni bir getirme ve sıralama motoru olan Photon'u inşa ettik. Bu, sayfa kayıtlarına hizmet etmek için dağıtılmış anahtar-değer depomuz olan CobbleDB ve Search API ile yaptığımız gibi, sıfırdan yapay zeka öncelikli arama altyapısı oluşturma yaklaşımımızı sürdürmektedir.

Photon, disk erişimini azaltmak ve beklemeleri üst üste bindirmek için toplu iş farkındalıklı önbelleğe alma ve eşzamansız okumalar ile yalnızca her sorgunun ihtiyaç duyduğu verileri okumak ve kodunu çözmek için kompakt veri biçimleri kullanır. Dizin oluşturma, sorgu sunumundan ayrı olarak çalışır; her seferinde bir sunum grubunu günceller ve canlı sorguları yönlendirmeden önce önbelleklerini ısıtır.

Photon artık arama boru hattımıza güç veriyor ve p50'de 160 ms ve p95'te 230 ms tekli arama çağrısı gecikmesiyle Arama API'miz için yeni bir hızlı ön ayarın temelini oluşturuyor. Altı genel kıyaslama genelinde, hızlı ön ayar, varsayılan ön ayarla karşılaştırılabilir toplam görev kalitesini korurken görev başına tahmini model artı arama maliyetini %68 oranında azalttı. Geliştiricilerin bu iyileştirmelere erişebilmesi için onu bugün yayınlıyoruz.

Büyüt

Büyüt

Getirme ve sıralama motorunun gereksinimleri

Her sorgu için getirme ve sıralama motoru, arama yığınının gecikme bütçesi dahilinde küçük bir ilgili sayfa setini seçmek ve sıralamak için büyük, dağıtılmış bir dizini arar. Sistem ayrıca, bu çalışmanın canlı sorguları yavaşlatmasına izin vermeden, yeni sayfalar geldikçe ve mevcut sayfalar değiştikçe dizini güncel tutmalıdır.

Çeşitli açık kaynaklı seçenekleri değerlendirdik ve ilk ihtiyaçlarımızı karşılayan olgun, genel amaçlı bir getirme ve sıralama motoru seçtik. Ardından üretim ölçeğinde istikrarlı gecikme ve aktarım hızı sağlayarak mimarimize ve iş yüklerimize uyarladık.

Önceki sistemimizin yetersiz kaldığı yerler

Motoru büyüyen dizinimize uyarlamak için kendi çatallamamızı koruduk, ancak temel sınırlamaları ele almak giderek platformun büyük bir kısmının yeniden tasarlanmasını gerektirdi. Birkaç kısıtlama, temel mimari değişiklikler olmaksızın çözülmesinin zor olduğunu kanıtladı:

1. Ölçeklendirme maliyetleri. Hem depoladığımız belge sayısı hem de getirmemiz ve sıralamamız gereken belge başına veri miktarı zamanla artmaktadır. Bu ölçeklendirme donanımımıza, özellikle de mevcut RAM miktarına baskı yaptı. Maliyetleri kontrol etmek için daha kompakt veri temsiline ve bellekte neyin kalacağı ve istek üzerine diskten neyin okunacağı konusunda daha hassas kontrole ihtiyacımız vardı.

2. Kötü kuyruk gecikmesi. Üretim trafiğinde, eski sistemin p99 yanıt süresi yaklaşık 800 ms idi. Veri kümesi mevcut RAM'i aştı, bu nedenle tamamen bellekte tutmak için mlock kullanamadık. Yerleşik olmayan verilere erişmek, işletim sisteminin diskten okuma yaparken sorgu yürütmeyi durdurmasına neden olan büyük sayfa hatalarını tetikleyebilirdi.

Motor ayrıca ana disk dizinini bellekten temizlenen daha küçük dizinlerle periyodik olarak birleştirirdi. Bu disk dizini füzyon süreci sırasında, sayfa hatası sayısı daha da arttı ve p99 gecikmesi 10-15 dakika boyunca yaklaşık 1,2 saniyeye ulaştı. Önbellekler ısındıkça sayfa hatası sıklığı ve gecikme azaldı, bu da soğuk okumaların ani artışlara büyük katkıda bulunduğunu gösterdi. Verileri önceden yüklemek ve dizini ısıtmak ani artışları azalttı ancak yüksek kuyruk gecikmesini yeterince ele almadı.

3. Uzun süren kurtarma ve senkronizasyon. Önceki sistemde, ek bir küme dağıtmak ve verilerini senkronize etmek bir haftadan uzun sürebilirdi. Senkronizasyon, ek veri kopyaları tutmak için düğüm grupları eklendiğinde veya düğüm arızalarından kurtulurken de gerekliydi. Kurtarma sırasında, arama yanıtlarının daha büyük bir kısmı kısmiydi, bu da nihai yanıt kalitesi puanlarını düşürdü.

Sonuç olarak, çatallamamızı uyarlamaya ve bakımını yapmaya devam etmektense sıfırdan inşa etmenin daha basit ve daha ucuz olacağı sonucuna vardık. Önceki sistemi işletme deneyimimizden yararlanarak, küçük bir mühendislik ekibi Photon'u inşa etmek için kalıcı kodlama ajanlarından oluşan bir grupla birlikte çalıştı.

Photon'un arama yığınındaki yeri

Photon iki birincil iş akışı için tasarlanmıştır: arama isteklerine hizmet vermek ve işleme boru hattından güncellemeleri almak.

Üst düzey arama servisinden gelen bir istek, bir yük dengeleyici aracılığıyla Photon broker'ına ulaşır. Broker bir parça grubu seçer ve zaman aşımını izleyerek ve gerektiğinde ek istekler yayınlayarak isteği her bir parçaya iletir.

Her parça getirme, ilk aşama sıralaması ve ikinci aşama sıralaması gerçekleştirir, ardından en iyi adaylarını broker'a geri döndürür. Broker bu adayları tek bir sıralanmış listede birleştirir ve seçilen sayfalar için ilgili parçalardan anahtar belge alanlarını getirir. Ardından bu sonuçları, ajanın temellendirilmiş bir yanıt üretmesi için gereken sayfa içeriğini toplayan üst düzey arama servisine geri döndürür.

Dizin güncellemeleri ayrı bir yolu takip eder. Yayın katmanımız olan Pillar, verileri hazırlar ve YTsaurus tablolarında depolar. Dizin oluşturucular bu tabloları parçaların arama için yükleyebileceği dizin yapılarına dönüştürür. Denetleyici, veri hazırlamayı, dizin oluşturmayı ve yeni dizin sürümlerinin sunum gruplarına dağıtılmasını koordine eder. Canlı trafiği işlemeden önce, her parça önbelleklerini ısıtmak için gerçek arama sorgularını yeniden oynatır.

Büyüt

Photon'u iş akışlarımız için tasarlama

Üç tasarım tercihi Photon'u iş yükümüz için çok uygun hale getiriyor: kompakt veri temsilleri, önbelleğe alma ve eşzamansız disk okumaları ve dizin güncellemelerini sorgu sunumundan ayırma.

Getirme ve sıralama için veri temsilleri

Getirme ve sıralama, belge verilerine farklı şekillerde erişir. Sözlüksel getirme sorgu konularıyla başlar ve bunları içeren belgeleri bulur. Sıralama ise seçilen her belge hakkında terim frekansları ve konumları dahil olmak üzere ayrıntılı bilgiye ihtiyaç duyar.

Photon, bu erişim modellerini desteklemek için iki tamamlayıcı temsil kullanır. Tersine çevrilmiş bir dizin, aday seçimini desteklemek için gönderim listesi adı verilen her terim için eşleşen belgelerin bir listesini depolar. Ayrı belge başına kayıtlar, sıralama için gereken verileri sağlar. Ayrıca, sabit bir iş bütçesi altında seçimi iyileştirmek için gönderim listelerinin nasıl depolandığını ve geçildiğini optimize ediyoruz.

Özelleştirilmiş veri temsilleri, ana verileri daha verimli bir şekilde depolamamızı sağlar. Daha kompakt bir tersine çevrilmiş dizin, sorgu başına okunan veya taşınan veri miktarını azaltarak gereksiz G/Ç işlemlerini ortadan kaldırarak gecikmeyi iyileştirir. Bu biçimler ayrıca, sorgu mantığımızın sabit bir bütçe altında bir sorgunun ne kadar iş yaptığını kontrol etmek için dayandığı bir özellik olan, bir belgenin tamamen kodu çözülmeden bir listede görünüp görünmediğini kontrol etmeyi mümkün kılar. Belge başına kayıtları optimize etmek, sıralama için belge başına daha fazla veri depolamamıza olanak tanırken, aynı zamanda önceki sistemimizle ilişkili ölçeklendirme maliyetlerini de azaltır.

Tersine çevrilmiş dizin

Her terim için tersine çevrilmiş dizin bir gönderim listesi depolar. Bu listeler avuç dolusu belgeden milyonlarca belgeye kadar uzanabilir, bu nedenle hiçbir tek biçim her liste için iyi çalışmaz. Photon biçimi terimi içeren belge sayısına göre seçer.

Kısa listeler, tek bir sayfa içine sığan ve blok tablosu gerektirmeyen satır içi bir temsil kullanır. Satır içi biçime uymayan daha uzun listeler, belge tanımlayıcılarının sabit aralıklarını kapsayan bloklara bölünür. Her bloğun temsili yoğunluğuna bağlıdır: seyreltik bloklar sıralı belge kimliği uzaklıkları dizilerini saklarken, yoğun bloklar bittakımları kullanır. Seyreltik bloklar, listenin bölgelerini atlamak için giderek büyük adımlarla ilerleyen dörtnala arama (galloping search) kullanır. Yoğun bloklar, bir belgeye karşılık gelen biti arayarak üyelik kontrollerine izin verir.

Bir terimin sorgu frekansı, gönderim listesinin diskte nereye yerleştirileceğini belirler. Sık sorgulanan listeler birbirine yakın depolanır ve sıcak verileri daha küçük bir depolama bölgesinde yoğunlaştırır. Her liste içinde belgeler, daha umut verici adaylarla daha erken karşılaşılması için ayrı bir kullanışlılık sinyaline göre sıralanır.

Büyüt

Bir iş bütçesi dahilinde listeleri geçme

Aday seçimi, potansiyel olarak ilgili belgeleri bulmak için gönderim listelerinin taranmasını gerektirir. Her listeyi ayrıntılı olarak taramak pahalıdır, bu nedenle Photon, diğerlerindeki eşleşmeleri hesaba katmaya devam ederken yalnızca bazı listeleri tarayan WAND benzeri bir algoritma kullanır.

Algoritma listeleri iki gruba ayırır. Sürüş listeleri geçişi ilerletir ve aday belgeleri önerir. Yoklama listeleri bu adayların puanlarına katkıda bulunur ancak kendileri aday üretmez.

Aday puanlaması, ağırlıklı sorgu konusu kapsamını ve frekans katkısını, belge uzunluğu normalleştirmesi ve yinelenen konulardan elde edilen kazançlar üzerindeki bir üst sınır ile birleştirir. Photon, her adayın olası maksimum puanını sınırlamak için önce dizilerde ve bittakımlarında konu varlığını kontrol eder. Tam terim frekanslarını yalnızca seçim eşiğini hala karşılayabilecek adaylar için okur.

Seçim daha sonra üç adımda ilerler:

• Geçiş: Katı bir sorgu kapsamı gereksinimi ile başlayın. Çok az aday bulunursa esnetilmiş bir gereksinimle tekrarlayın.
• Tutma: Adaylar, kapsamı ve sıklığı birleştiren bir puan kullanılarak sınırlı bir sette tutulur. Toplanan en iyi adaylar geliştikçe kabul eşiği yükselir.
• Son seçim: Geçiş için son sonuçlar, frekans puanlarına göre tutulan kümeden seçilir. Her alan kendi geçişini çalıştırır ve sonuçlar alan ağırlıkları kullanılarak birleştirilir.

Algoritma, daha ileri sıralamada kullanılmak üzere ilgili belgelerden oluşan bir aday kümesi üretir.

Büyüt

Docblob

Aday sayfalar seçildikten sonra, sıralama aşaması terim frekanslarını, alan kapsamını ve oluşumların konumlarını ve yakınlığını gerektirir. Bu verileri tersine çevrilmiş dizin aracılığıyla elde etmek, birçok terim-belge çifti arasında dağıtılmış erişimler gerektirir. Photon'da, terim frekanslarını, bir terimin hangi alanlarda göründüğünü ve bellek içinde nerede oluştuğunu içeren docblob adı verilen kompakt bir belge başına kayıt depolarız. Sonuç olarak, bir adayı sıralamak belge başına yalnızca bir arama gerektirir.

Biçim, gereğinden fazla kod çözmekten kaçınmak için oluşturulmuştur. Bir docblob içinde alanlar metin analizörüne göre gruplandırılır. Her grup Elias-Fano ile kodlanmış sıralı bir konu listesi depolar, böylece bir sorgu konusu önce tüm listeyi genişletmeden doğrudan aranabilir. Bir alan maskesi bir konunun nerede oluştuğunu işaretler, bir frekans sayımı ne sıklıkla olduğunu takip eder ve gerçek konumlar konum farklılıkları olarak kodlanmış konu-alan çifti başına ayrı bloklarda yaşar. Yalnızca gerçekten eşleşen konuların bloklarının kodu çözülürken, kayuttaki diğer her şey sıkıştırılmış biçimde kalır.

Bu seçici kod çözme, docblob'un orantılı bir maliyet artışı olmaksızın belge başına daha fazla veri depolamayı desteklemesine olanak tanır. Kaydı büyütmek, arama başına daha fazla iş yapmaya zorlamaz; çünkü sıralama, tüm kayıt yerine yalnızca eşleşen konuyla ilgili parçalara dokunur.

Büyüt

Toplu okumalar ve bellekle çalışma

Daha verimli veri temsillerine rağmen RAM diğer kaynaklardan önce tükenmektedir, bu nedenle diskte depolanan verilere sıklıkla erişmemiz gerekir. Photon, bu erişimleri hızlandırmak için eşzamansız disk okumaları ve toplu okumalar için optimize edilmiş bir önbellek kullanarak istek başına bekleme süresini kısaltır. Bu, önceki sisteme kıyasla kuyruk gecikmesinde önemli bir iyileştirmeye katkıda bulunur.

Büyüt

Örtüşen disk beklemeleri

Sıralama, bir dosyanın farklı yerlerinde bulunan yüz belgenin özelliklerinin elde edilmesini gerektirir. Önceki sistemimiz, bellek işaretçileri aracılığıyla okunabilmesi için dosyayı sanal adres alanına eşlemek üzere mmap kullandı. Bununla birlikte, bellekten eksik olan bir sayfaya erişmek hala bir disk okuması gerektiriyordu. Konu, hesaplamaya devam etmeden önce verileri beklemek zorundaydı ve süreç soğuk kayıtları ardışık olarak okuması gerektiğinde bu bekleme süresi birikti.

Photon, kayıt uzaklıklarının önceden bilindiği gerçeğinden yararlanır, böylece aynı anda birkaç okuma gönderebiliriz. Bu işlem reaktör tarafından yönetilir: özel iş parçacığı kümeleri io_uring aracılığıyla toplu işler gönderir ve okudukları verileri çağrı koduna iletir. Her konu kendi io_uring yapısını korur; toplu işler en az yük altındaki reaktöre gönderilir. Önceden kaydedilmiş dosya tanımlayıcıları ve arabellek havuzları, tekrarlanan okumaların yükünü azaltır. Bu eşzamansız yürütme, birkaç işlemin bekleme sürelerinin örtüşmesini sağlayarak kuyruk gecikmesini azaltır.

Sürücü erişimlerinin sayısını azaltma

Okumaları göndermeden önce Photon, bellek içi önbellekteki tüm toplu işi kontrol eder. Yalnızca eksik kayıtlar için olan istekler diske gider; okunan veriler daha sonra önbelleği doldurur.

Önbellek, toplu okumalar için tasarlanmıştır. Özellikle:

• İsabet durumunda ayrı bir tahsis yoktur. Bunun yerine veriler, çağrı kodu tarafından önceden hazırlanmış bir arabelleğe kopyalanır.
• Okuyucu tarafından kilit edinimi yoktur. Bunun yerine veri sürümünü kontrol eder ve bir yazma ile çakışırsa yeniden dener.
• Her okumada paylaşılan bir LRU listesinin güncellenmesini gerektirmek yerine CLOCK çıkarma işlemini kullanır.
• Sonraki kayıtlar için meta verilerin ve verilerin önceden istendiği CPU önbellek ön getirme özelliğini kullanır.

Bu optimizasyonlar, önem verdiğimiz iş yüklerindeki performansa zarar vermeden gecikmeyi azaltır.

Dizini sunumdan ayrı olarak oluşturma ve güncelleme

Photon'da dizin oluşturma ve sorgu sunumu farklı düğümlerde çalışır. Dizin oluşturucular verileri hazır depolama yapılarına dönüştürürken, sunum düğümleri bunları okur ve getirme ve sıralama gerçekleştirir. Sonuç olarak, dizin oluşturma arama sorgularıyla CPU için rekabet etmez ve bu görevler için kaynaklar bağımsız olarak ölçeklendirilebilir.

Bu ayrım, önceki uygulamada mevcut olan kurtarma ve senkronizasyon darboğazlarını ele alır. Dizin oluşturma, sorgulara hizmet veren kümenin içinde çalıştığından, arızalı bir düğümü kurtarmak veya verilerin yeni bir kopyasını eklemek, belgeleri yerinde yeniden dizine eklemek anlamına gelebilirdi; bu süreç günler sürer ve kurtarma sırasında kısmi yanıtları artırırdı. Photon bu bağımlılığı ortadan kaldırır; dizin oluşturucular, sunum düğümlerinden bağımsız olarak sürümlendirilmiş, sunuma hazır dizin yapıları üreten dağıtılmış işler olarak çalışır, böylece dizinin bir sonraki sürümünü oluşturmak artık canlı trafikle rekabet etmez.

Büyüt

Hazırlık ve dağıtılmış bina

Bir derleme, etkin dizin için belgeleri seçerek ve kaynak dışarı aktarımını üreterek başlar. Denetleyici kaynak sürümünü, girdi tablolarını ve beklenen parça sayısını kaydeder. YTsaurus içerisindeki MapReduce işleri; metni, meta verileri, parçaları, özellikleri ve önceden hesaplanmış gömmeleri parça başına bölümlere ayrılmış sürümlendirilmiş tablolara hazırlar. Her dizin oluşturucu hazırlanan tabloyu akış olarak alır, parçası için yapıları oluşturur ve metin segmentlerini birleştirir. Bileşenlerinin açıklamasıyla birlikte hazır dizin nesne depolama alanına yüklenir.

Parça sayısı ve eşzamanlı olarak çalışan dizin oluşturucuların sayısı bağımsız olarak yapılandırılır, böylece bir derleme birkaç dalga halinde çalışabilir veya paralel çalışmak için daha fazla makine ayrılabilir. Dağıtılmış hazırlık ve paralel dizin oluşturucular, önceki sisteme göre önemli bir iyileştirme olarak, tüm web dizininin tek haneli saatler içinde oluşturulmasına olanak tanır.

Yeni bir sürüm dağıtma

Dağıtımdan önce denetleyici yeni dizinin hazır olduğunu kontrol eder. Veriler eksikse dağıtım otomatik olarak engellenir.

Birden fazla sunum grubu olduğunda, denetleyici bunları teker teker günceller. Önce bir grubu broker yönlendirmesinden çıkarır ve yeni dizin sürümünde başlatır. İsteklere hizmet vermeden önce parçalar, ilk durumu önceden dolduran ve gerçek trafiğe geçişi daha sorunsuz hale getiren arama günlüklerine dayalı ayrı bir ısınma aşamasından geçer. Isınmadan sonra denetleyici dizin durumunu ve hazırlığını kontrol eder, ardından grubu yönlendirmeye döndürür. Diğer gruplar bu süre zarfında isteklere hizmet vermeye devam eder. İşlem durumu kalıcı hale getirildiği için, yeniden başlatma bir derlemenin baştan başlamasını zorlamaz; denetleyici devam etmekte olan hazırlığa yeniden bağlanabilir, hazır bir sonucu yeniden kullanabilir veya kaydedilen adımdan kesintiye uğrayan bir rotasyona devam edebilir.

Veri güncelleme süreleri arama dikeyine göre değişir. Yüksek tazelik gereksinimleri olan dikeyler için belge teslimi tek haneli dakika sürer. Verilerin ek bir kopyası yarım saat içinde dağıtılabilir; hazır dizinler kaynak belgeleri yeniden dizine eklemeden yüklenir ve parçalara bağlanır.

Büyüt

Arama yığınımız içinde geçiş ve doğrulama

İlk hedefimiz, yanıt sürelerini azaltırken işlevselliği ve arama kalitesini koruyan bir motorla eski sistemin yerini almaktı. Canlı trafiğe geçmeden önce tekrarlanabilir yük testleri ve çevrimdışı kalite değerlendirmeleriyle başlayarak Photon'u aşamalı olarak doğruladık. Photon artık eski sisteme göre önemli ölçüde daha düşük yanıt süreleriyle üretim arama yığınımızdaki getirme ve sıralama işlemlerine güç veriyor.

Yük testi ve değerlendirmeler

Performans testi için, arama günlüklerimizdeki sorguları yapılandırılabilir varış oranlarında yeniden oynatan bir yük testi aracı oluşturduk. Çalışmalar arasındaki sonuçları karşılaştırır ve gözlemlenen performans farklarının tutarlı olup olmadığını değerlendirmek için istatistiksel testler uygular.

Bu kontrollerden sonra, gölge trafiği kullanarak her iki motora da aynı anda canlı sorgular gönderdik. Bu, hangi motorun kullanıcılara hizmet vereceğini değiştirmeden önce üretim iş yüklerindeki performanslarını ve sonuçlarını karşılaştırmamıza olanak tanıdı. Ardından Photon'u küçük kullanıcı alt kümeleri için etkinleştirdik ve kalite ile performansı sürekli izleyerek dağıtımı kademeli olarak genişlettik. İlk sürüm kalite düşüşü yaşamadan kabul testini geçti ve Photon tüm üretim trafiğine hizmet verene kadar dağıtıma devam ettik.

Üretimde ölçülen iyileştirmeler

Üretim iş akışımızda, p99 yanıt süresi eski sistemde yaklaşık 800 ms'den Photon'da yaklaşık 65 ms'ye düştü. Bu ölçüm Photon içindeki tüm aşamaları kapsar, ancak üst düzey arama yığınındaki sonraki aşamaları hariç tutar. Ayrıca artık dizin sürümlerini değiştirmeyle önceden ilişkilendirilen gecikme artışlarını gözlemlemiyoruz.

Photon, belge başına yaklaşık 2,5 kat daha fazla veri depolarken eski sistemin içerik düğümlerine kıyasla yaklaşık %20 daha az eşdeğer sunum makinesi kullanır. Geçişin sonrasında, sıralama kalitesini eski sistemin ötesine geçirecek şekilde geliştirmek için bu ek verileri kullandık.

Photon ayrıca bellekte kalması gereken veri miktarını da azaltır. Aynı Photon veri kümesini RAM'de mlock ile sabitlemek, Photon'un şu anda kullandığından tahmini olarak 4,6 kat daha fazla yerleşik bellek gerektirirdi.

Hızlı Arama API'si ön ayarının değerlendirilmesi

Photon'u ayrıca gecikmeye duyarlı iş akışları için tasarlanmış Arama API'miz için yeni bir hızlı ön ayarın temel olarak kullandık. Ölçümlerimize göre, hızlı ön ayar için tekli arama çağrısı gecikmesi p50'de 160 ms ve p95'te 230 ms'dir; bildirilen kuyruk persentilleri farklı olsa da diğer Arama API sağlayıcılarının kendi bildirdiği sayı ۲ından düşük veya onlarla karşılaştırılabilirdir.

Hızlı ön ayarı altı ajan tabanlı kıyaslamada değerlendirdik: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 ve SEAL-Hard. Bu değerlendirmeler genelinde, test edilen yapılandırmalar arasında en düşük tahmini toplam model artı arama maliyetine ve en yüksek toplu görev puanına sahipti.

Hızlı ön ayar, Photon'u ajan tabanlı iş akışları için optimize edilmiş sıralamayla eşleştirerek, önemli ölçüde daha düşük maliyetle varsayılan ön ayara kıyasla karşılaştırılabilir performans sunar. Bununla birlikte, daha geniş arama kalitesinde bir ödünleşimle birlikte gelir. Hızlı ön ayar, sıralama için varsayılan ön ayardan daha az bilgi işlem gücü kullanır. Uzun kuyruklu sorguları, geniş kapsamı ve sonuç çeşitliliğini kapsayan dahili kıyaslamalarda, ilgililik konusunda 0,24 puan daha düşük ve yanıt kullanılabilirliği konusunda yaklaşık 3 yüzde puan daha düşük puan alır. Modelin kendi akıl yürütme süreci ve bilgisi aradaki farkı telafi etmeye yardımcı olabileceğinden, bunun ajan tabanlı iş akışları için makul bir ödünleşim olduğuna inanıyoruz.

Büyüt

Günlük ajan tabanlı görevler için hızlı ön ayarı öneriyoruz. Zamana o kadar duyarlı olmayan daha zorlu veya belirsiz sorular için, varsayılan ön ayar daha yüksek gecikme süresini ve maliyetini haklı çıkararak daha güvenilir kalite sunar.

Sonuç

Arama yığınımızı istikrarlı bir şekilde Rust tabanlı, şirket içi altyapıya taşıyoruz. Açık kaynaklı motoru özel getirme ve sıralama motorumuz olan Photon ile değiştirmek en son adımdır. Photon bize veri temsilleri, okumaların nasıl organize edildiği ve yeni dizinlerin nasıl dağıtıldığı üzerinde tam kontrol sağlayarak her katmanı iş yüklerimiz için optimize etmemize olanak tanır.

Photon, Perplexity ürünleri arasında daha hızlı aramayı etkinleştirmiş ve Arama API'sindeki yeni hızlı ön ayarımızın temelini sağlamıştır. Geçişin ardından, p99 getirme ve sıralama gecikmesi yaklaşık 800 ms'den 65 ms'ye düştü. Kompakt veri biçimlerimiz ayrıca belge başına 2,5 kat daha fazla veri depolamamıza olanak tanıyarak getirme ve sıralamanın daha zengin belge bilgilerine erişmesini sağlar.

Hızlı ön ayar, p50'de 160 ms ve p95'te 230 ms tekli arama çağrısı gecikmesi sunar. Değerlendirilen altı ajan tabanlı kıyaslama genelinde, varsayılan ön ayara kıyasla görev başına tahmini model artı arama maliyetini %68 oranında azaltırken karşılaştırılabilir bir toplu görev kalitesini korudu. Bu sonuçlar, hem Perplexity ürünleri hem de API'miz ile geliştirme yapan geliştiriciler için arama iş yüklerimiz etrafında tasarlanan altyapının pratik faydalarını göstermektedir.

Photon'un performansını ve depolama verimliliğini artırmaya devam ediyoruz. Amacımız, iş yüklerimiz büyüdükçe aramayı hızlı tutarken aynı donanımda daha büyük bir dizini ve daha zengin belge verilerini desteklemektir.

Alıntı

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