۸۰۰ میلیثانیه به ۶۵ میلیثانیه؛ این جهش خیرهکننده در کاهش تأخیر (Latency) بازیابی دادهها در محیط عملیاتی Perplexity است. برای دستیابی به این عدد، این شرکت موتور بازیابی متنباز قبلی خود را بهطور کامل کنار گذاشت و Photon را جایگزین کرد؛ یک موتور اختصاصی برای بازیابی و بازرتبهبندی (Reranking) که تماماً با زبان Rust توسعه یافته است.
این تغییر استراتژیک، یکی از گلوگاههای حیاتی در جستوجوی مبتنی بر هوش مصنوعی را هدف قرار داده است: دشواری حفظ سرعت زمانی که حجم شاخصها (Indices) از ظرفیت حافظه RAM فراتر میرود. همانطور که در تحلیل قبلی ما دربارهی کاهش تهاجمی تأخیر در سرویسهای SaaS اشاره کردیم، اقدام Perplexity نشاندهنده یک روند گستردهتر در صنعت است؛ جایی که پشتههای جستوجوی آماده (Off-the-shelf) جای خود را به سامانههای تخصصی و بهینه در مصرف حافظه میدهند تا بتوانند گردشهای کاری عاملمحور (Agentic) را در زمان واقعی پشتیبانی کنند. این رویکرد بهینهسازی زیرساختی شباهت زیادی به استراتژیهای کاهش هزینه در مقیاس سازمانی دارد، مشابه آنچه در بهرهگیری از زیرساختهای Bare Metal برای کاهش هزینههای RAG مشاهده کردیم.
محدودیتهای موتور قدیمی
طبق گزارشهای فنی، تصمیم Perplexity برای بازنویسی از صفر، ناشی از سه محدودیت اصلی در مقیاس بالا بود. نخست، تأخیر p99 در محیط عملیاتی به نزدیکی ۸۰۰ میلیثانیه رسیده و ناپایدار شده بود. به دلیل اینکه حجم دادهها از RAM موجود بیشتر بود، تیم توسعه نمیتوانست از mlock استفاده کند و در نتیجه، خوانشهای سرد (Cold reads) باعث بروز خطاهای صفحهای (Page faults) شدید میشد که پرسوجوها را متوقف میکرد.
دوم، سیستم با جهشهای ناگهانی در زمان ادغام (Merge spikes) مواجه بود؛ بهطوری که هنگام ادغام شاخصهای دیسک، تأخیر p99 برای بازههای ۱۰ تا ۱۵ دقیقهای به ۱.۲ ثانیه میرسید. در نهایت، فرآیند بازیابی (Recovery) بسیار کند بود و همگامسازی یک خوشه (Cluster) اضافی بیش از یک هفته زمان میبرد. تیم مهندسی به این نتیجه رسید که ساخت یک موتور Rust، سادهتر و ارزانتر از نگهداری یک نسخه تغییریافته (Fork) از موتورهای متنباز است.
به نقل از تحلیل فنی Marktechpost، موتور Photon این مشکلات را از طریق چندین بهینهسازی در سطح پایین معماری حل کرده است:
بهینهسازی حافظه و دیسک
- لیستهای پست تطبیقی (Adaptive Posting Lists): لیستهای کوتاه بهصورت درونخطی در یک صفحه ذخیره میشوند، اما لیستهای بلندتر به بلوکهایی با بازههای ثابت ID سند تقسیم شدهاند. بلوکهای پراکنده از آرایههای آفست مرتب با جستوجوی Galloping استفاده میکنند و بلوکهای متراکم برای بررسی عضویت از بیتمپها (Bitmaps) بهره میبرند.
- پیمایش بودجهبندی شده (Budgeted Traversal): الگوریتمی شبیه به WAND، لیستها را به دو دسته «راننده» و «کاوشگر» تقسیم میکند. ابتدا با بررسیهای ارزان، حداکثر امتیاز احتمالی کاندیدا تعیین میشود و تنها در صورتی که کاندیدا از آستانه عبور کند، فرکانس دقیق عبارت خوانده میشود.
- رکوردهای Docblob: هر سند دارای یک رکورد فشرده از فرکانسها و ماسکهای فیلد است. عبارات با رمزگذاری Elias-Fano ذخیره شدهاند تا رتبهبند تنها عبارات تطبیقیافته را رمزگشایی کند و برای هر سند تنها به یک جستوجو نیاز باشد.
ورودی/خروجی و مقیاسپذیری
- یکپارچگی با io_uring: آفست رکوردها از پیش مشخص هستند و این امکان را میدهد که خوانشهای دیسک بهصورت دستهای (Batch) از طریق io_uring ارسال شوند.
- حذف CLOCK: خوانندگان هیچ قفلی (Lock) را اشغال نمیکنند و سیستم بهجای لیست LRU مشترک، از سیاست حذف CLOCK برای کاهش تداخل (Contention) استفاده میکند.
- شاردبندی نسخهدار (Versioned Sharding): شاخصهای شارد نسخهدار از جداول YTsaurus در گرههای اختصاصی ساخته میشوند. یک کنترلکننده، گروههای سرویسدهنده را یکییکی میچرخاند و با بازپخش پرسوجوهای لاگ، حافظه پنهان (Cache) را گرم میکند. این سازوکار اجازه میدهد یک شاخص کامل وب در کمتر از ۱۰ ساعت ساخته شود.
نتایج عملیاتی
انتقال به Photon دستاوردهای سختافزاری و عملکردی چشمگیری داشت. تأخیر p99 بازیابی و رتبهبندی از ۸۰۰ میلیثانیه به ۶۵ میلیثانیه کاهش یافت. علاوه بر این، Photon با ۲۰٪ ماشینهای سرویسدهنده کمتر نسبت به گرههای قبلی اجرا میشود.
Perplexity همچنین مقدار دادههای ذخیرهشده برای هر سند را ۲.۵ برابر افزایش داد تا کیفیت رتبهبندی بهبود یابد. شرکت اشاره کرد که برای تثبیت همین حجم از داده با mlock، به ۴.۶ برابر حافظه مقیم (Resident memory) نسبت به آنچه Photon امروز مصرف میکند، نیاز بود. همچنین، تغییر نسخههای شاخص دیگر باعث جهش تأخیر نمیشود.
در ۲۴ سپتامبر ۲۰۲۶، Perplexity حالت «جستوجوی سریع» (Fast Search) را برای API خود عرضه کرد. این حالت، Photon را با یک مدل رتبهبندی سبکتر که مخصوص حلقههای عاملمحور تنظیم شده، ترکیب میکند. در تستهای انجامشده روی ۳۵۵۴ وظیفه (با استفاده از محکهایی نظیر WideSearch و SEAL-Hard)، هزینه Fast Search حدود ۵۹.۷۳ دلار بود، در حالی که حالت پیشفرض ۱۸۷.۶۰ دلار هزینه داشت. این یعنی کاهش ۶۸ درصدی هزینه در حالی که امتیاز کیفیت (۶۴.۳٪ در برابر ۶۴.۰٪) تقریباً ثابت مانده است.
با این حال، این سرعت با یک افت کیفیت قابل اندازهگیری همراه است. بنچمارکهای داخلی نشان میدهند که ارتباط (DCG) از ۲.۴۵ به ۲.۲۱ و در دسترس بودن پاسخها از ۰.۵۹۶ به ۰.۵۶۷ (کاهش ۲.۹ واحد درصدی) رسیده است. Perplexity توصیه میکند برای پرسوجوهای دشوار و مبهم از حالت پیشفرض و برای وظایف روزمره عاملها از Fast Search استفاده شود.
برای جامعه فنی، این انتقال ثابت میکند که استراتژی «Fork و نگهداری» برای موتورهای جستوجو در مقیاس بالا به سقف خود میرسد. Perplexity با مهاجرت به Rust و پیادهسازی چیدمانهای سفارشی حافظه، لایه بازیابی را برای عصر عاملها بهینه کرده است. این تلاش برای حذف پیچیدگیهای لایه ذخیرهسازی، همراستا با رویکردهایی است که در حذف هزینه مدیریت پایگاهدادههای برداری توسط Gemini File Search دیدیم تا توسعهدهندگان بتوانند مستقیماً بر روی منطق بازیابی تمرکز کنند.
توسعهدهندگان اکنون میتوانند از طریق API با تنظیم search_type: "fast" در درخواست POST /search با قیمت ۱ دلار بهازای هر ۱۰۰۰ درخواست به این قابلیت دسترسی داشته باشند. در SDK پایتون نسخههای 0.43.4 و 0.43.5، این کار با ارسال extra_body={"search_type": "fast"} انجام میشود.
گام بعدی شما
- اگر از APIهای جستوجوی هوش مصنوعی برای عاملهای خود استفاده میکنید، حالت Fast Search را برای کاهش هزینهها تست کنید.
- در معماریهای بازیابی داده، بررسی کنید آیا استفاده از زبانهایی با کنترل حافظه دقیق مانند Rust میتواند گلوگاههای I/O شما را حل کند یا خیر.
- موازنه بین DCG (کیفیت) و Latency (سرعت) را در کاربردهای خود تعریف کنید تا بدانید کجا مدلهای سبکتر را جایگزین کنید.
اما رقابت در لایه زیرساختی تازه آغاز شده است؛ بررسی خواهیم کرد که آیا رقبایی مانند Exa و Tavily نیز برای رقابت در معیار «هزینه بهازای هر توکن»، به بازنویسی موتورهای خود روی Rust روی میآورند یا خیر.
گفتگو