Photon: بناء محرك استرجاع وترتيب من الصفر

المقدمة

تسترجع بنية البحث الأصلية للذكاء الاصطناعي لـ Perplexity وتصنف صفحات المرشحين، وتبرز المحتوى الأكثر صلة للنموذج لترسيخ إجاباته. في الأصل، كانت هذه المرحلة تعمل على محرك مفتوح المصدر قمنا بتكييفه مع نظامنا. ومع ذلك، مع نمو فهرسنا وأحمال عملنا، واجهنا حدودًا صارمة للتكاليف، وزمن الانتقال الذيلي، وقت استرداد العقد والتي لم نتمكن من حلها داخل منصة الطرف الثالث الحالية.

للتغلب على هذه التحديات، قمنا بناء Photon، وهو محرك استرجاع وترتيب داخلي جديد. ويستمر هذا في نهجنا المتمثل في بناء بنية تحتية للبحث قائمة على الذكاء الاصطناعي من الصفر، كما فعلنا مع CobbleDB، وهو مخزن القيمة المفتاحية الموزع الخاص بنا لخدمة سجلات الصفحات، وSearch API الخاص بنا.

يستخدم Photon تنسيقات بيانات مدمجة لقراءة وفك تشفير ما تحتاجه كل استعلام فقط، مع التخزين المؤقت المدرك للدفعات والقراءات غير المتزامنة لتقليل الوصول إلى القرص وتداخل عمليات الانتظار. يعمل بناء الفهرس بشكل منفصل عن خدمة الاستعلام، حيث يقوم بتحديث مجموعة خدمة واحدة في كل مرة وتدفئة مخازنها المؤقتة قبل توجيه الاستعلامات الحية إليها.

يشغّل Photon الآن خط أنابيب البحث الخاص بنا وهو أيضًا أساس الإعداد السريع الجديد لواجهة برمجة تطبيقات البحث الخاصة بنا، مع زمن انتقال لطلب بحث فردي يبلغ 160 مللي ثانية عند p50 و230 مللي ثانية عند p95. عبر ستة معايير عامة، قلل الإعداد السريع التكلفة المقدرة للنموذج بالإضافة إلى البحث لكل مهمة بنسبة 68% مع الحفاظ على جودة مهام إجمالية قابلة للمقارنة مع الإعداد الافتراضي. نحن نطلقه اليوم لكي يتمكن المطورون من الوصول إلى هذه التحسينات.

تكبير

تكبير

ما يتطلبه محرك الاسترجاع والترتيب

لكل استعلام، يبحث محرك الاسترجاع والترتيب في فهرس كبير وموزع لتحديد وترتيب مجموعة صغيرة من الصفحات ذات الصلة ضمن ميزانية زمن الانتقال لبنية البحث. يجب على النظام أيضًا تحديث الفهرس مع وصول صفحات جديدة وتغيير الصفحات الحالية، دون السماح لهذا العمل بإبطاء الاستعلامات الحية.

لقد قيّمنا العديد من الخيارات مفتوحة المصدر واخترنا محرك استرجاع وترتيب عام النطاق وناضجًا يلبي احتياجاتنا الأولية. ثم قمنا بتكييفه مع بنيتنا وأحمال عملنا، مع الحفاظ على زمن انتقال مستقرار وإنتاجية على نطاق الإنتاج.

أين قصر نظامنا السابق

لقد حافظنا على نسختنا المتفرعة لتكييف المحرك مع فهرسنا النامي، ولكن معالجة القيود الرئيسية تطلبت بشكل متزايد إعادة تصميم أجزاء كبيرة من المنصة. ثبت صعوبة حل العديد من القيود دون إجراء تغييرات هيكلية أساسية:

1. تكاليف القياس. كلا من عدد المستندات التي نخزنها وكمية بيانات المستند الفردي التي نحتاج إلى استرجاعها وترتيبها في تزايد بمرور الوقت. وضع هذا القياس ضغطًا على أجهزتنا، وخاصة كمية ذاكرة الوصول العشوائي المتاحة. للتحكم في التكاليف، احتجنا إلى تمثيلات بيانات أكثر دمجًا وتحكمًا أدق فيما يبقى في الذاكرة وما يتم قراءته من القرص عند الطلب.

2. سوء زمن الانتقال الذيلي. على حركة مرور الإنتاج، كان وقت استجابة p99 للنظام القديم حوالي 800 مللي ثانية. تجاوزت مجموعة البيانات ذاكرة الوصول العشوائي المتاحة، لذلك لم نتمكن من استخدام mlock للاحتفاظ بها بالكامل في الذاكرة. قد يؤدي الوصول إلى البيانات غير المقيمة إلى حدوث أخطاء جسيمة في الصفحات، مما يؤدي إلى توقف تنفيذ الاستعلام بينما يقرأ نظام التشغيل من القرص.

قام المحرك أيضًا بدمج فهرس القرص الرئيسي الخاص به بشكل دوري مع فهارس أصغر يتم مسحها مؤقتًا من الذاكرة. وأثناء عملية دمج فهرس القرص هذه، ارتفع عدد أخطاء الصفحات بشكل أكبر، حيث وصل زمن الانتقال p99 إلى ما يقرب من 1.2 ثانية لمدة 10-15 دقيقة. ومع دفء ذاكرات التخزين المؤقت، انخفضت frequency أخطاء الصفحات وزمن الانتقال كلاهما، مما يشير إلى أن القراءات الباردة كانت مساهمًا رئيسيًا في الارتفاعات. أدى التحميل المسبق للبيانات وتدفئة الفهرس إلى تقليل الارتفاعات ولكنه لم يعالج بشكل كافٍ زمن الانتقال الذيلي المرتفع.

3. الاسترداد والمزامنة الطويلة. في النظام السابق، كان نشر مجموعة إضافية ومزامنة بياناتها قد يستغرق أكثر من أسبوع. وكانت المزامنة مطلوبة أيضًا عند إضافة مجموعات من العقد للاحتفاظ بنسخ بيانات إضافية أو التعافي من فشل العقد. أثناء الاسترداد، كانت نسبة أكبر من استجابات البحث جزئية، مما أدى إلى خفض درجات جودة الإجابة النهائية.

في النهاية، خلصنا إلى أنه سيكون من الأبسط والأرخص البناء من الصفر بدلاً من الاستمرار في تعديل وصيانة نسختنا المتفرعة (fork). وبالاعتماد على خبرتنا في تشغيل النظام السابق، عمل فريق هندسي صغير جنباً إلى جنب مع سرب من وكلاء البرمجة المستمرين لبناء Photon.

أين يندرج Photon في بنية البحث

تم تصميم Photon لخدمة نوعين أساسيين من سير العمل: خدمة طلبات البحث واستيعاب التحديثات من خط أنابيب المعالجة.

يصل طلب من خدمة البحث ذات المستوى الأعلى إلى وسيط Photon من خلال موزع الحمل. يختار الوسيط مجموعة أجزاء ويوجه الطلب إلى كل جزء، مراقبًا مهلة الانتظار وإصدار طلبات إضافية عند الحاجة.

يُجري كل جزء عمليات الاسترجاع والترتيب الأولي وترتيب المرحلة الثانية، ثم يعيد أفضل مرشحيه إلى الوسيط. يدمج الوسيط هؤلاء المرشحين في قائمة مرتبة واحدة ويجلب حقول المستندات الرئيسية للصفحات المحددة من الأجزاء ذات الصلة. ثم يعيد هذه النتائج إلى خدمة البحث ذات المستوى الأعلى، والتي تجمع محتوى الصفحة اللازم للوكيل لتوليد إجابة مؤسسة.

تتبع تحديثات الفهرس مسارًا منفصلًا. تقوم Pillar، طبقة النشر الخاصة بنا، بإعداد البيانات وتخزينها في جداول YTsaurus. تقوم المفهرسات بتحويل هذه جداول إلى هياكل فهرس يمكن للأجزاء تحميلها للبحث. تنسق وحدة التحكم إعداد البيانات، وبناء الفهرس، ونشر إصدارات الفهرس الجديدة إلى مجموعات الخدمة. قبل التعامل مع حركة المرور الحية، يعيد كل جزء تشغيل استعلامات البحث الحقيقية لتدفئة مخازنه المؤقتة.

تكبير

تصميم Photon لسير العمل لدينا

تُبقي ثلاثة خيارات تصميم Photon ملائمًا تمامًا لسير العمل الخاص بنا: تمثيل البيانات المدمجة، والتخزين المؤقت وقراءات القرص غير المتزامنة، وفصل تحديثات الفهرس عن خدمة الاستعلام.

تمثيلات البيانات للاسترجاع والترتيب

يصل استرجاع البيانات وترتيبها إلى بيانات المستند بطرق مختلفة. يبدأ الاسترجاع المعجمي بعبارات الاستعلام ويعثر على المستندات التي تحتوي عليها. يحتاج الترتيب بعد ذلك إلى معلومات مفصلة حول كل مستند مُحدد، بما في ذلك ترددات المصطلحات والمواضع.

يستخدم Photon تمثيلين متكاملين لدعم أنماط الوصول هذه. يخزن الفهرس المعكوس قائمة بالمستندات المتطابقة لكل مصطلح، تسمى قائمة النشر، لدعم اختيار المرشحين. توفر السجلات المنفصلة لكل مستند البيانات اللازمة للترتيب. كما نقوم بتحسين كيفية تخزين قوائم النشر واجتيازها لتحسين الاختيار ضمن ميزانية عمل ثابتة. يتيح لنا تحسين السجلات لكل مستند تخزين المزيد من البيانات لكل مستند للترتيب، مع تقليل تكاليف القياس المرتبطة بنظامنا السابق.

تمكننا تمثيل البيانات المتخصصة من تخزين البيانات الرئيسية بشكل أكثر كفاءة. يقلل الفهرس المعكوس الأكثر دمجًا من كمية البيانات المقروءة أو المنقولة لكل استعلام، مما يحسن زمن الانتقال عن طريق القضاء على عمليات الإدخال/الإخراج غير الضرورية. تجعل هذه التنسيقات من الممكن أيضًا التحقق مما إذا كان المستند يظهر في قائمة دون فك تشفيره بالكامل، وهي مخصصة تعتمد عليها منطق اجتيازنا للتحكم في مقدار العمل الذي يقوم به الاستعلام بميزانية ثابتة. يتيح تحسين السجلات لكل مستند تخزين المزيد من البيانات لكل مستند للترتيب، مع تقليل تكاليف القياس المرتبطة بنظامنا السابق.

الفهرس المعكوس

لكل مصطلح، يخزن الفهرس المعكوس قائمة نشر. يمكن أن تتراوح هذه القوائم من حفنة من المستندات إلى ملايين، لذلك لا يوجد تنسيق واحد يعمل بشكل جيد لكل قائمة. يختار Photon التنسيق بناءً على عدد المستندات التي تحتوي على المصطلح.

تستخدم القوائم القصيرة تمثيلًا مضمنًا يناسب صفحة واحدة ولا يتطلب جدول حظر. بينما تُقسم القوائم الأطول التي لا تتناسب مع التنسيق المضمن إلى كتل تغطي نطاقات ثابتة من معرِّفات المستندات. يعتمد تمثيل كل كتلة على كثافتها: تخزن الكتل المتفرقة مصفوفات مرتبة لإزاحات معرفات المستندات، بينما تستخدم الكتل الكثيفة الصور النقطية (bitmaps). تستخدم الكتل المتفرقة بحث الجري (galloping search)، والذي يتقدم بخطوات أكبر فأكبر لتخطي مناطق القائمة. تسمح الكتل الكثيفة بإجراء عمليات التحقق من العضوية من خلال البحث عن البت المقابل للمستند.

يحدد تردد الاستعلام للمصطلح مكان وضع قائمة النشر الخاصة به على القرص. تُخزن القوائم المطلوبة بشكل متكرر بالقرب من بعضها البعض، مما يركز البيانات الساخنة في منطقة تخزين أصغر. داخل كل قائمة، يتم ترتيب المستندات حسب إشارة فائدة منفصلة بحيث يتم مواجهة المرشحين الأكثر واعدة في وقت مبكر.

تكبير

اجتياز القوائم ضمن ميزانية العمل

يتطلب اختيار المرشح اجتياز قوائم النشر للعثور على المستندات ذات الصلة المحتملة. يُعد الفحص الشامل لكل قائمة مكلفًا، لذلك يستخدم Photon خوارزمية تشبه WAND والتي تجتاز بعض القوائم فقط بينما تظل تأخذ في الاعتبار التطابقات في القوائم الأخرى.

يقسم الخوارزمية القوائم إلى مجموعتين. تدفع قوائم القيادة (Driving lists) عملية الاجتياز وتقترح المستندات المرشحة. تساهم قوائم التحقيق (Probe lists) في درجات هؤلاء المرشحين ولكنها لا تولد مرشحين بنفسها.

يجمع تسجيل النقاط للمرشحين بين تغطية مصطلحات الاستعلام الموزونة ومساهمة التردد، مع تطبيع طول المستند وحد أقصى للمكاسب من المصطلحات المتكررة. يتحقق Photon أولاً من وجود المصطلح في المصفوفات والخرائط النقطية لتحديد الحد الأقصى للنتيجة الممكنة لكل مرشح. وهو يقرأ ترددات المصطلحات الدقيقة فقط للمرشحات التي يمكنها تلبية عتبة الاختيار.

ثم يستمر الاختيار في ثلاث خطوات:

• الاجتياز: ابدأ بمتطلبات تغطية استعلام صارمة. إذا تم العثور على عدد قليل جدًا من المرشحين، كرر مع متطلب مخفف.
• الاحتفاظ: يتم الاحتفاظ بالمرشحات في مجموعة محددة باستخدام نتيجة تجمع بين التغطية والتردد. ومع تحسن أفضل المرشحات المُجمعة، ترتفع عتبة القبول.
• الختيار النهائي: يتم اختيار النتائج النهائية للجولة من المجموعة المحتفظ بها بناءً على درجات التردد. يُجري كل حقل جولته الخاصة، وتُدمج النتائج باستخدام أوزان الحقول.

تنتج الخوارزمية مجموعة مرشحة من المستندات ذات الصلة لاستخدامها في مزيد من الترتيب.

تكبير

Docblob

بعد اختيار صفحات المرشحين، تحتاج مرحلة الترتيب إلى ترددات المصطلحات، وتغطية الحقول، ومواقع القرب للتكرارات. إن الحصول على هذه البيانات من خلال الفهرس المعكوس يتطلب وصولات مبعثرة عبر العديد من أزواج مصطلح-مستند. في Photon، نقوم بتخزين سجل مدمج لكل مستند يسمى docblob والذي يحتوي على ترددات المصطلحات، والحقول التي ظهر فيها المصطلح، ومكان حدوثه في المستند. ونتيجة لذلك، فإن ترتيب المرشح يتطلب بحثًا واحدًا فقط لكل مستند.

تم تصميم التنسيق لتجنب فك التشفير أكثر من اللازم. داخل docblob، يتم تجميع الحقول حسب محلل النص. تخزن كل مجموعة قائمة مصطلحات مرتبة مشفرة باستخدام Elias-Fano، بحيث يمكن البحث عن مصطلح استعلام مباشرة دون توسيع القائمة بأكملها أولاً. يحدد قناع الحقل مكان حدوث المصطلح، ويتتبع عداد التردد عدد المرات، وتعيش المواضع الفعلية في كتل منفصلة لكل زوج من أزواج مصطلح وحقل مشفرة كاختلافات في الموضع. يتم فك تشفير الكتل الخاصة بالمصطلحات المتطابقة بالفعل فقط، بينما يظل كل شيء آخر في السجل بالتنسيق المضغوط.

يتيح فك التشفير الانتقائي هذا لـ docblob دعم تخزين المزيد من البيانات لكل مستند دون زيادة تناسبية في التكلفة. لا يؤدي نمو السجل إلى فرض المزيد من العمل لكل عملية بحث، لأن الترتيب يمس فقط الأجزاء ذات الصلة بالمصطلحات المتطابقة بدلاً من السجل بأكمله.

تكبير

القراءات المجمعة والتعامل مع الذاكرة

حتى مع تمثيلات البيانات الأكثر كفاءة، لا تزال ذاكرة الوصول العشوائي تنفد قبل الموارد الأخرى، لذلك نحتاج متكررًا إلى الوصول إلى البيانات المخزنة على القرص. يستخدم Photon قراءات قرص غير متزامنة وذاكرة تخزين مؤقت محسنة للقراءات المجمعة لتسريع هذه الوصولات، مما يقلل من وقت الانتظار لكل طلب. يساهم هذا في تحسن كبير في زمن الانتقال الذيلي مقارنة بالنظام السابق.

تكبير

تداخل عمليات انتظار القرص

يتطلب الترتيب الحصول على ميزات مئة مستند موجودة في أجزاء مختلفة من الملف. استخدم نظامنا السابق mmap لتعيين الملف في مساحة عنوان افتراضية حتى يمكن قراءته من خلال مؤشرات الذاكرة. ومع ذلك، فإن الوصول إلى صفحة غير موجودة في الذاكرة كان لا يزال يتطلب قراءة القرص. كان على السلسلة انتظار البيانات قبل متابعة الحساب، وتراكم وقت الانتظار هذا عندما احتاج العملية إلى قراءة السجلات الباردة بالتسلسل.

يستفيد نظام Photon من حقيقة أن إزاحات السجلات معروفة مسبقًا، لذا يمكننا إرسال عدة عمليات قراءة دفعة واحدة. يُدير المُفاعِل (reactor) هذه العملية: حيث تُرسل سلاسل العمال المخصصة دفعات عبر io_uring وتمرر البيانات التي قرأتها إلى كود الاستدعاء. تحافظ كل سلسلة على io_uring الخاص بها؛ وتُرسل الدفعات إلى المُفاعِل الأقل حملاً. تقلل مُصفِّفات الملفات المُسجلة مسبقًا وتجمعات المخزن المؤقت من العبء الناتج عن القراءات المتكررة. يتيح هذا التنفيذ غير المتزامن تداخل عمليات الانتظار لعدة عمليات، مما يقلل من زمن الانتقال الذيلي.

تقليل عدد مرات الوصول إلى القرص

قبل إرسال القراءات، يتحقق Photon من الدفعة بأكملها في ذاكرة التخزين المؤقت الموجودة في الذاكرة. تذهب طلبات السجلات المفقودة وحدها إلى القرص؛ ثم تملأ البيانات المقروءة ذاكرة التخزين المؤقت.

تم تصميم ذاكرة التخزين المؤقت للقراءات المجمعة. وتحديدًا:

• لا يوجد تخصيص منفصل عند الاصطدام. بدلاً من ذلك، يتم نسخ البيانات إلى مخزن مؤقت مُعد مسبقًا بواسطة كود الاستدعاء.
• لا يوجد استحواذ على القفل من قبل القارئ. بدلاً من ذلك، يتحقق من إصدار البيانات ويعيد المحاولة إذا كان يتعارض مع عملية الكتابة.
• وهو يستخدم إخلاء CLOCK، بدلاً من طلب تحديثات لقائمة LRU مشتركة عند كل قراءة.
• وهو يستهلك مسبق جلب ذاكرة التخزين المؤقت لوحدة المعالجة المركزية، حيث تُطلب البيانات الوصفية والبيانات الخاصة بالسجلات القادمة مسبقًا.

تُقلل هذه التحسينات من زمن الانتقال دون الإضرار بالأساس بالأداء على أحمال العمل التي نُعنى بها.

بناء وتحديث الفهرس بشكل منفصل عن الخدمة

في Photon، يعمل بناء الفهرس وخدمة الاستعلام على عقد مختلفة. تحول المفهرسات البيانات إلى هياكل تخزين جاهزة، بينما تقرأها عقد الخدمة وتجري الاسترجاع والترتيب. ونتيجة لذلك، لا يتنافس بناء الفهرس مع استعلامات البحث على وحدة المعالجة المركزية، ويمكن توسيع موارد هذه المهام بشكل مستقل.

يعالج هذا الفصل اختناقات الاسترداد والمزامنة الموجودة في التنفيذ السابق. نظرًا لأن بناء الفهرس يعمل داخل نفس 群组 الذي يخدم الاستعلامات، فإن استرداد عقدة فاشلة أو إضافة نسخة جديدة من البيانات يمكن أن يعنى إعادة فهرسة المستندات في مكانها، وهي عملية استغرقت أيامًا وزادت الاستجابات الجزئية أثناء الاسترداد. يزيل Photon هذا الارتباط؛ وتعمل المفهرسات كمهام موزعة تنتج هياكل فهرس جاهزة للخدمة ذات إصدارات بشكل مستقل عن عقد الخدمة، بحيث لم يعد بناء الإصدار التالي من الفهرس يتنافس مع حركة المرور الحية.

تكبير

الإعداد والبناء الموزع

يبدأ البناء بتحديد المستندات الخاصة بالفهرس النشط وإنتاج تصدير المصدر. تسجل وحدة التحكم إصدار المصدر، وجداول الإدخال، والعدد المتوقع من الأجزاء (shards). تُعد مهام MapReduce في YTsaurus النصوص، والبيانات الوصفية، والاجزاء، والميزات، والتضمينات المحسوبة مسبقًا في جداول ذات إصدارات مقسمة حسب الجزء. يقوم كل مفهرس ببث الجدول المُعد، وبناء الهياكل الخاصة بجزئه، ودمج مقاطع النص. يتم تحميل الفهرس الجاهز، إلى جانب وصف لمكوناته، إلى التخزين الكائني.

يتم تكوين عدد الأجزاء وعدد المفهرسات قيد التشغيل المتزامن بشكل مستقل، بحيث يمكن تشغيل البناء في عدة موجات، أو يمكن تخصيص المزيد من الأجهزة للعمل بالتوازي. يتيح الإعداد الموزع والمفهرسات المتوازية بناء فهرس الويب الكامل في رقم من خانة واحدة من الساعات، وهو تحسن كبير مقارنة بالنظام السابق.

نشر إصدار جديد

قبل النشر، تتحقق وحدة التحكم من جاهزية الفهرس الجديد. إذا كانت البيانات غير مكتملة، يتم حظر النشر تلقائيًا.

عندما تكون هناك مجموعات خدمة متعددة، تقوم وحدة التحكم بتحديثها واحدة تلو الأخرى. تقوم أولاً بإزالة مجموعة من توجيه الوسيط وتبدأها على إصدار الفهرس الجديد. قبل خدمة الطلبات، تمر الأجزاء بمرحلة تدفئة منفصلة استنادًا إلى سجلات البحث، مما يؤدي إلى ملء الحالة الأولية مسبقًا ويجعل الانتقال إلى حركة المرور الحقيقية أكثر سلاسة. بعد التدفئة، تتحقق وحدة التحكم من حالة الفهرس والجاهزية، ثم تعيد المجموعة إلى التوجيه. تستمر المجموعات الأخرى في خدمة الطلبات خلال هذا الوقت. نظرًا لحفظ حالة التشغيل، فإن إعادة التشغيل لا تجبر البناء على البدء من جديد؛ بل يمكن لوحدة التحكم إعادة الاتصال بالإعداد قيد tiến hành، أو إعادة استخدام نتيجة جاهزة، أو مواصلة التبديل المقاطع من الخطوة المحفوظة.

تختلف أوقات تحديث البيانات عبر قطاعات البحث. بالنسبة للقطاعات التي تتطلب نضارة عالية، يستغرق تسليم المستندات بضع دقائق (رقم من خانة واحدة). يمكن نشر نسخة إضافية من البيانات في غضون نصف ساعة تقريبًا؛ ويتم تحميل الفهارس الجاهزة وإرفاقها بالأجزاء دون إعادة فهرسة مستندات المصدر.

تكبير

الترحيل والتحقق ضمن بنية البحث الخاصة بنا

كان هدفنا الأول هو استبدال النظام القديم بمحرك يحافظ على الوظائف وجودة البحث مع تقليل أوقات الاستجابة. لقد تحققنا من صحة Photon على مراحل، بدءًا من اختبارات التحميل القابلة للاستنساخ وتقييمات الجودة غير المتصلة قبل الانتقال إلى حركة المرور الحية. يشغّل Photon الآن الاسترجاع والترتيب في بنية البحث الخاصة بالإنتاج لدينا، مع أوقات استجابة أقل بكثير من النظام القديم.

اختبار التحميل والتقييمات

لاختبار الأداء، قمنا بإنشاء أداة اختبار تحميل تعيد تشغيل الاستعلامات من سجلات البحث الخاصة بنا بمعدلات وصول قابلة للتكوين. وهي تقارن النتائج عبر العمليات وتطبق اختبارات إحصائية لتقييم ما إذا كانت اختلافات الأداء الملاحظة متسقة. وبشكل منفصل، قمنا بتقييم Photon والنظام القديم على نفس مجموعات البيانات في أنظمة التقييم غير المتصلة الداخلية الخاصة بنا للتحقق من أي انحدار في الجودة.

بعد عمليات التحقق هذه، أرسلْنا الاستعلامات الحية إلى كلا المحركين في وقت واحد باستخدام حركة المرور الوهمية (shadow traffic). وقد سمح لنا ذلك بمقارنة أدائهما ونتائجهما على أحمال عمل الإنتاج قبل تغيير المحرك الذي يخدم المستخدمين. ثم قمنا بتفعيل Photon لمجموعات صغيرة من المستخدمين وقمنا بتوسيع طرحه تدريجيًا، مع مراقبة الجودة والأداء طوال الوقت. اجتاز الإصدار الأول اختبار القبول دون انحدار في الجودة، واستمررنا في طرحه حتى خدم Photon جميع حركة مرور الإنتاج.

التحسينات المقاسة في الإنتاج

في سير العمل الخاص بإنتاجنا، انخفض وقت استجابة p99 من حوالي 800 مللي ثانية في النظام القديم إلى حوالي 65 مللي ثانية في Photon. يغطي هذا القياس جميع المراحل داخل Photon، ولكنه يستبعد المراحل اللاحقة في بنية البحث ذات المستوى الأعلى. كما أننا لم نعد نشهد ارتفاعات زمن الانتقال المرتبطة سابقًا بتبديل إصدارات الفهرس.

يستخدم Photon آلات خدمة مكافئة أقل بنسبة 20% تقريبًا من عقد المحتوى للنظام القديم مع تخزين ما يقرب من 2.5 أضعاف البيانات لكل مستند. بعد الترحيل، استخدمنا هذه البيانات الإضافية لتحسين جودة الترتيب بما يتجاوز جودة النظام القديم.

يقلل Photon أيضًا من كمية البيانات التي يجب أن تظل في الذاكرة. يتطلب تثبيت نفس مجموع بيانات Photon في ذاكرة الوصول العشوائي (RAM) باستخدام mlock ما يُقدَّر بـ 4.6 أضعاف الذاكرة المقيمة التي يستخدمها Photon حاليًا.

تقييم إعداد واجهة برمجة تطبيقات البحث السريع

لقد استخدمنا Photon أيضًا كأساس لإعداد سريع جديد لواجهة برمجة تطبيقات البحث الخاصة بنا، مصمم لأحمال العمل الحساسة لزمن الانتقال. بناءً على قياساتنا، فإن زمن الانتقال لطلب بحث فردي للإعداد السريع هو 160 مللي ثانية عند p50 و230 مللي ثانية عند p95، وهو أقل من أو مقارن بالأرقام المبلغ عنها ذاتيًا لموفري واجهة برمجة تطبيقات البحث الآخرين، على الرغم من اختلاف نسب الذيل المُبلغ عنها.

لقد قيّمنا الإعداد السريع على ستة معايير وكيلة: WideSearch، وBrowseComp، وDSQA، وFRAMES، وSEAL-0، وSEAL-Hard. عبر هذه التقييمات، كان لديه أقل تكلفة مقدرة لإجمالي النموذج بالإضافة إلى البحث وأعلى درجات مهمة إجمالية بين التكوينات المختبرة.

يجمع الإعداد السريع بين Photon والترتيب المُحسَّن لسير العمل الوكيل، مما يوفر أداءً مقارنًا للإعداد الافتراضي بتكلفة أقل بكثير. ومع ذلك، فهو يأتي مع مقايضة في جودة البحث الأوسع. يستخدم الإعداد السريع حسابًا أقل للترتيب مقارنة بالإعداد الافتراضي. وعلى المعايير الداخلية التي تغطي استعلامات الذيل الطويل، والتغطية الواسعة، وتنوع النتائج، فإنه يسجل 0.24 نقطة أقل في الصلة وما يقرب من 3 نقاط مئوية أقل في توفر الإجابة. نعتقد أن هذا مقايضة معقولة لسير العمل الوكيل، حيث يمكن لاستدلال النموذج ومعرفته المساعدة في تعويض الفرق.

تكبير

نوصي بالإعداد السريع لمهام الوكلاء اليومية. بالنسبة للأسئلة الأكثر تحديًا أو غموضًا والتي تكون أقل حساسية للوقت، يقدم الإعداد الافتراضي جودة أكثر قوة، مما يبرر زمن الانتقال والتكلفة الأعلى.

الخاتمة

نحن ننقل باستمرار بنية البحث الخاصة بنا إلى بنية تحتية داخلية قائمة على Rust. ويُعد استبدال المحرك مفتوح المصدر بـ Photon، محرك الاسترجاع والترتيب المخصص لدينا، هو الخطوة الأخيرة. يمنحنا Photon تحكمًا كاملاً في تمثيلات البيانات، وكيفية تنظيم القراءات، وكيفية نشر الفهارس الجديدة، مما يسمح لنا بتحسين كل طبقة لأحمال عملنا.

لقد مكّن Photon بحثًا أسرع عبر منتجات Perplexity ويوفر الأساس لإعدادنا السريع الجديد في واجهة برمجة تطبيقات البحث. بعد الترحيل، انخفض زمن انتقال الاسترجاع والترتيب p99 من ما يقرب من 800 مللي ثانية إلى 65 مللي ثانية. تتيح لنا تنسيقات البيانات المدمجة لدينا أيضًا تخزين 2.5 أضعاف البيانات لكل مستند، مما يمنح الاسترجاع والترتيب إمكانية الوصول إلى معلومات مستندات أغنى.

يوفر الإعداد السريع زمن انتقال لطلب بحث فردي يبلغ 160 مللي ثانية عند p50 و230 مللي ثانية عند p95. وعبر اختبارات الأداء الستة المُقيَّمة، قللت التكلفة المقدرة للنموذج بالإضافة إلى البحث لكل مهمة بنسبة 68% مقارنة بالإعداد الافتراضي مع الحفاظ على جودة مهام إجمالية قابلة للمقارنة. توضح هذه النتائج الفوائد العملية للبنية التحتية المصممة حول أحمال عمل البحث لدينا، سواء لمنتجات Perplexity أو للمطورين الذين يبنون باستخدام واجهة برمجة التطبيقات الخاصة بنا.

نحن نواصل تحسين أداء Photon وكفاءة تخزينه. هدفنا هو دعم فهرس أكبر وبيانات مستندات أغنى على نفس الجهاز مع الحفاظ على سرعة البحث مع نمو أحمال عملنا.

اقتباس

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