Perplexity موتور جست‌وجوی Photon را برای کاهش تأخیر معرفی کرد

موتور جست‌وجوی Photon، سامانه تازه Perplexity برای بازیابی و رتبه‌بندی نتایج، بنا بر اعلام این شرکت اکنون در خدمت تمام ترافیک تولیدی آن قرار دارد و تأخیر صدک ۹۹ را از حدود ۸۰۰ به حدود ۶۵ میلی‌ثانیه رسانده است. Photon که با زبان برنامه‌نویسی Rust ساخته شده، جایگزین موتور متن‌بازی شده که Perplexity پیش‌تر آن را منشعب کرده و برای زیرساخت جست‌وجوی خود تغییر داده بود. این موتور همچنین پشتوانه حالت جدید Fast Search در API جست‌وجوی شرکت است؛ حالتی که برای پاسخ‌گویی سریع‌تر به درخواست‌های عامل‌های هوش مصنوعی طراحی شده است.

کاهش تأخیر می‌تواند در کاربردهایی اهمیت داشته باشد که یک عامل برای انجام کار، بارها به جست‌وجوی وب مراجعه می‌کند. بااین‌حال، سرعت بیشتر در Fast Search با افتی در برخی سنجه‌های ارتباط نتایج همراه بوده است. Perplexity این حالت را برای کارهای روزمره عامل‌ها مناسب می‌داند و استفاده از تنظیم پیش‌فرض را برای پرسش‌های دشوار یا مبهم توصیه می‌کند.

چرا Perplexity موتور جست‌وجوی Photon را ساخت؟

به گفته Perplexity، موتور پیشین با بزرگ‌شدن نمایه جست‌وجو به چند محدودیت عملیاتی برخورد. نمایه، مجموعه‌ای سازمان‌یافته از اطلاعات اسناد و صفحات است که سامانه برای پاسخ‌دادن به جست‌وجوها از آن استفاده می‌کند. بخشی از این مجموعه از ظرفیت حافظه اصلی دستگاه‌ها بیشتر شده بود؛ در نتیجه، نگه‌داشتن همه داده‌ها در حافظه با سازوکاری مانند mlock امکان‌پذیر نبود.

این محدودیت در زمان خواندن داده از دیسک به شکل تأخیرهای ناگهانی خود را نشان می‌داد. صفحه‌هایی که از قبل در حافظه نبودند، باید از دیسک خوانده می‌شدند و این فرایند گاهی اجرای درخواست‌ها را متوقف می‌کرد. در گزارش شرکت، تأخیر صدک ۹۹ سامانه قدیمی در محیط تولید نزدیک به ۸۰۰ میلی‌ثانیه بود. صدک ۹۹ یعنی زمانی که ۹۹ درصد درخواست‌ها در همان مدت یا کمتر از آن پاسخ می‌گیرند؛ بنابراین این شاخص برای نشان‌دادن تجربه درخواست‌های کندتر، نه فقط میانگین، به کار می‌رود.

مشکل دیگری هنگام ادغام بخش‌های نمایه روی دیسک رخ می‌داد. Perplexity می‌گوید در این دوره‌ها تأخیر صدک ۹۹ برای ۱۰ تا ۱۵ دقیقه تا حدود ۱٫۲ ثانیه بالا می‌رفت. بازیابی پس از مشکل نیز ساده نبود: راه‌اندازی و همگام‌سازی یک خوشه دیگر می‌توانست بیش از یک هفته طول بکشد و احتمال دریافت پاسخ ناقص را افزایش دهد.

تیم شرکت در نهایت به این نتیجه رسید که ساخت موتور تازه از پایه، از نگه‌داری نسخه تغییریافته سامانه قبلی ساده‌تر و کم‌هزینه‌تر است. Photon اکنون مرحله بازیابی و رتبه‌بندی را در ترافیک عملیاتی Perplexity انجام می‌دهد، اما خود موتور به‌صورت متن‌باز منتشر نشده است. در نتیجه، سازمان‌های دیگر نمی‌توانند آن را روی زیرساخت خودشان نصب و اجرا کنند.

Photon چگونه نتایج را بازیابی و رتبه‌بندی می‌کند؟

در معماری Photon، یک متوازن‌کننده بار درخواست را به کارگزاری می‌فرستد؛ کارگزار درخواست را میان گروهی از شاردها توزیع می‌کند و زمان‌پایان‌ها را زیر نظر می‌گیرد. شارد، بخشی از داده‌های نمایه‌شده است که بخشی از کار جست‌وجو را انجام می‌دهد. هر شارد بازیابی اولیه و دو مرحله رتبه‌بندی را پیش می‌برد؛ سپس کارگزار نامزدها را با هم ادغام می‌کند و اطلاعات کلیدی اسناد برگزیده را می‌خواند.

یکی از اجزای طراحی، شیوه ذخیره فهرست واژه‌هاست. فهرست‌های کوتاه درون یک صفحه جا می‌گیرند، اما فهرست‌های بلند به بلوک‌هایی بر اساس بازه شناسه سند تقسیم می‌شوند. بلوک‌های کم‌تراکم از آرایه‌های مرتب‌شده استفاده می‌کنند و برای جست‌وجو در آن‌ها از روشی به نام جست‌وجوی جهشی بهره می‌برند. بلوک‌های پرتراکم با بیت‌مپ ذخیره می‌شوند؛ ساختاری که حضور یک سند را با بررسی یک بیت مشخص می‌کند.

Photon همچنین از الگوریتمی شبیه WAND برای محدودکردن کار رتبه‌بندی استفاده می‌کند. این الگوریتم فهرست‌ها را به گروه‌هایی تقسیم می‌کند که بعضی برای هدایت جست‌وجو و بعضی برای بررسی نامزدها به کار می‌روند. ابتدا بررسی‌های کم‌هزینه انجام می‌شود تا مشخص شود هر نامزد حداکثر چه امتیازی می‌تواند بگیرد. فراوانی دقیق واژه‌ها فقط زمانی خوانده می‌شود که نامزد امکان عبور از آستانه رتبه‌بندی را داشته باشد.

اطلاعات هر سند نیز در رکوردی فشرده به نام docblob قرار می‌گیرد؛ رکوردی که فراوانی واژه‌ها، نوع فیلدها و موقعیت واژه‌ها را نگه می‌دارد. برای کدگذاری واژه‌ها از روش Elias-Fano استفاده می‌شود تا سامانه هنگام رتبه‌بندی فقط داده‌های مربوط به واژه‌های تطبیق‌یافته را بازگشایی کند. Perplexity می‌گوید برای رتبه‌بندی یک نامزد، یک بار مراجعه به این رکورد کافی است.

برای خواندن داده‌ها از دیسک، Photon درخواست‌های ناهمگام را به‌صورت دسته‌ای می‌فرستد و از رابط io_uring استفاده می‌کند. سامانه ابتدا کل دسته را در حافظه نهان بررسی می‌کند. خواننده‌ها برای دسترسی به داده قفل نمی‌گیرند و سازوکار CLOCK برای بیرون‌راندن داده‌های حافظه نهان جایگزین فهرست مشترک LRU شده است. به بیان ساده، این انتخاب‌ها با هدف جلوگیری از انتظار هم‌زمان بخش‌های مختلف سامانه برای دسترسی به داده انجام شده‌اند.

کاهش تأخیر و هزینه Fast Search

Perplexity می‌گوید تأخیر صدک ۹۹ مرحله‌های بازیابی و رتبه‌بندی Photon از حدود ۸۰۰ به حدود ۶۵ میلی‌ثانیه رسیده است. این عدد فقط به مرحله‌های خود Photon مربوط می‌شود و نباید آن را با زمان کامل پاسخ به کاربر یکی دانست. شرکت همچنین برای یک فراخوانی در Fast Search، تأخیر ۱۶۰ میلی‌ثانیه در صدک ۵۰ و ۲۳۰ میلی‌ثانیه در صدک ۹۵ گزارش کرده است.

طبق اعلام شرکت، Photon با حدود ۲۰ درصد ماشین کمتر از گره‌های محتوایی سامانه قبلی اجرا می‌شود. در عین حال، هر سند در سامانه جدید حدود ۲٫۵ برابر داده ذخیره می‌کند؛ Perplexity می‌گوید از این ظرفیت برای بهبود کیفیت رتبه‌بندی استفاده کرده است. شرکت برآورد کرده که نگه‌داشتن همان مجموعه داده در حافظه با mlock به ۴٫۶ برابر حافظه مقیم مورد استفاده Photon نیاز داشت. همچنین جابه‌جایی میان نسخه‌های نمایه دیگر باعث جهش تأخیر نمی‌شود.

حالت Fast Search از Photon به همراه رتبه‌بندی سبک‌تری استفاده می‌کند که برای جریان کاری عامل‌ها تنظیم شده است. دسترسی به آن از طریق API میزبانی‌شده Perplexity انجام می‌شود: در درخواست POST به مسیر /search باید مقدار search_type روی fast قرار بگیرد. قیمت اعلام‌شده برای این حالت یک دلار به‌ازای هر هزار درخواست است. از آنجا که Photon متن‌باز نیست، این شیوه استفاده جایگزین نصب موتور روی سرور شخصی خواهد بود.

در شش آزمون شامل WideSearch، BrowseComp، DSQA، FRAMES، SEAL-0 و SEAL-Hard، مجموع ۳٬۵۵۴ کار با Fast به امتیاز ۶۴٫۳ درصد و هزینه برآوردی ۵۹٫۷۳ دلار برای مدل و جست‌وجو رسید. تنظیم پیش‌فرض امتیاز ۶۴ درصد و هزینه ۱۸۷٫۶۰ دلار داشت. بر اساس همین مقایسه، Perplexity هزینه برآوردی Fast را حدود ۶۸ درصد کمتر از تنظیم پیش‌فرض اعلام کرده است. این نتایج، ادعای شرکت درباره عملکرد در مجموعه آزمون‌های مشخص است و به‌تنهایی تضمین نمی‌کند که هر نوع کاربری همین هزینه یا کیفیت را تجربه کند.

در مقابل، سنجه‌های داخلی شرکت برای جست‌وجوهای کم‌تکرار یا اصطلاحاً long-tail افت را نشان دادند. امتیاز ارتباط نتایج با معیار DCG از ۲٫۴۵ به ۲٫۲۱ رسید و دسترس‌پذیری پاسخ از ۰٫۵۹۶ به ۰٫۵۶۷ کاهش یافت؛ افتی برابر با ۲٫۹ واحد درصد. Perplexity پیشنهاد می‌کند Fast برای چرخه‌های روزمره عامل‌ها به کار رود و تنظیم پیش‌فرض برای پرسش‌هایی که پاسخ‌دادن به آن‌ها دشوار یا مبهم است حفظ شود.

اهمیت تغییر برای API جست‌وجوی Perplexity

Photon فقط یک بهینه‌سازی در پشت‌صحنه نیست: موتور جدید به Fast Search، گزینه‌ای در API جست‌وجوی Perplexity، نیز امکان داده است. سرعت و هزینه جست‌وجو برای عامل‌هایی که در میانه انجام کار به چندین منبع مراجعه می‌کنند، می‌تواند بر هزینه کلی و زمان اجرای وظیفه اثر بگذارد. بااین‌حال، ارقام اعلام‌شده از آزمون‌های Perplexity و فروشندگان مختلف به دست آمده‌اند و شرایط اندازه‌گیری یکسانی ندارند؛ بنابراین مقایسه مستقیم آن‌ها با محصولات دیگر باید با احتیاط انجام شود.

معماری تازه همچنین نشان می‌دهد که گلوگاه یک سامانه جست‌وجوی هوش مصنوعی همیشه خود مدل زبانی نیست. نحوه ذخیره نمایه، خواندن داده از دیسک، بازیابی نامزدها و رتبه‌بندی آن‌ها می‌تواند زمان انتظار و منابع مورد نیاز را تغییر دهد. در این مورد، Perplexity ادعا می‌کند با بازطراحی این لایه‌ها هم تأخیر را پایین آورده و هم تعداد ماشین‌های سرویس‌دهنده را کاهش داده است؛ اما در Fast Search بخشی از کیفیت نتایج را فدای سرعت و هزینه کمتر می‌کند.

این خبر برای چه کسانی اهمیت دارد

این تغییر برای توسعه‌دهندگانی اهمیت دارد که با API جست‌وجوی Perplexity عامل‌های هوش مصنوعی یا گردش‌کارهای خودکار می‌سازند؛ آن‌ها اکنون می‌توانند بر پایه قیمت اعلام‌شده، Fast Search را برای جست‌وجوهای تکراری و روزمره ارزیابی کنند. تیم‌هایی که دقت در پرسش‌های دشوار و مبهم برایشان مهم‌تر از هزینه هستند، باید افت برخی سنجه‌های ارتباط را نیز در نظر بگیرند و تنظیم پیش‌فرض را بررسی کنند.

برای مهندسان زیرساخت جست‌وجو نیز جزئیات Photon نمونه‌ای از راهکارهای مدیریت نمایه بزرگ، کاهش خواندن‌های کند دیسک و تعویض نسخه‌های نمایه بدون جهش تأخیر است. در مقابل، کسب‌وکارهایی که به اجرای محلی یا بررسی کد موتور نیاز دارند، باید توجه کنند که Photon متن‌باز نیست و بنا بر اطلاعات اعلام‌شده فقط به شکل میزبانی‌شده از طریق API در دسترس است.