هندسة وتقييم واجهة برمجة تطبيقات بحث موجهة للذكاء الاصطناعي

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

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

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

[العثور على search_evals على GitHub]

بناء نظام بحث محسن لنماذج الذكاء الاصطناعي

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

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

تكبير

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

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

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

عندما أدركنا أن جعل Perplexity أفضل يتطلب بناء بنيتنا التحتية المخصصة للبحث، قمنا بتلخيص ملاحظاتنا في ثلاثة معايير رئيسية:

الشمولية، والحداثة، والسرعة: يجب أن يكون فهرس البحث شاملاً، ومحدثاً باستمرار، وممكناً لتحقيق معدل استجابة في الوقت الفعلي.

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

الاسترجاع والترتيب الهجين: يجب أن يدمج كل من خطي أنابيب الاسترجاع والترتيب إشارات معجمية ودلالية لكي تكون النتائج مفيدة للذكاء الاصطناعي.

تكبير

بنية الزحف والفهرسة التحتية

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

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

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

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

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

فهم محتوى ذاتي التحسين بمقياس الإنترنت

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

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

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

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

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

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

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

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

خط أنابيب الاسترجاع والترتيب

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

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

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

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

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

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

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

إرساء حدود جديدة للجودة والأداء

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

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

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

تكبير

تصميم تقييمات موثوقة لسير عمل البحث الموجه بالوكلاء

بدأنا بتحديد ثلاثة مبادئ توجيهية لإطار عمل التقييم الخاص بنا:

طيف التعقيد: يجب أن يقيس إطار عمل التقييم الأداء في كل من حالات استخدام الذكاء الاصطناعي الوكيل البسيطة والمعقدة.

الحياد: يجب أن يقيم إطار عمل التقييم جميع واجهات برمجة التطبيقات على قدم المساواة.

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

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

لدفع تقييماتنا، اعتمدنا أربعة معايير قياسية: SimpleQA وFRAMES للبحث أحادي الخطوة، إلى جانب BrowseComp وHLE للبحث المتعمق. توفر هذه المعايير القياسية مجتمعة مقاييس مقبولة جيداً لوكلاء المعرفة. باتباع الاتفاقية المعمول بها، نقوم بتقييم جميع المعايير باستخدام نفس منهجية تصنيف المطالبات المستخدمة في العمل الأصلي. يمكن مراجعة تنفيذ المعايير القياسية الدقيقة (بما في ذلك منطق المُصنّف) في مستودع GitHub الخاص بنا.

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

نتائج التقييم

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

تكبير

وجدنا أن استثماراتنا المذكورة أعلاه في الفهرس والاسترجاع وكفاءة الترتيب أثمرت بشكل ممتاز. يصل متوسط زمن استجابة Perplexity إلى 358 مللي ثانية، متقدماً بأكثر من 150 مللي ثانية على المزود الثاني الأسرع. يبقى زمن الاستجابة عند النسبة المئوية 95 أقل بكثير من 800 مللي ثانية. مع مقاييس وقت الاستجابة للرمز الأول (TTFT) الطويلة لنماذج الحدود اليوم، فإن كل جزء من الألف من الثانية يهم في خلق تجارب مستخدم مبهجة. لقد أمضينا العامين الماضيين في تحسين زمن الاستجابة لمستخدمينا الخاصين، ونحن ممتنون لأن نفس الاستثمارات ستفيد الآن مجتمع المطورين أيضاً.

زمن استجابة واجهة برمجة تطبيقات البحث

(الطلبات المُبادرة من AWS us-east-1)

النسب المئوية لتأخير واجهة برمجة تطبيقات البحث لطلبات بدأت من AWS us-east-1.

* يستخدم العديد من مزودي واجهات برمجة تطبيقات البحث كشط SERP كأساس لنتائجهم. لالتقاط أداء مثل هذه الأساليب، نستخدم واجهة برمجة تطبيقات نموذجية قائمة على SERP لـ Google تقدمها Tavily.

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

تكبير

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

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

درجات جودة واجهة برمجة تطبيقات البحث على SimpleQA وFRAMES وBrowseComp وHLE.

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

لبنة الأساس للفصل القادم للذكاء الاصطناعي

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

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

اقتباس

@online{perplexity2025ArchitectingAndEvaluatingAnAiFirstSearchApi,
  author = {{Perplexity} and Aleksandr Bogutskii and Aleksandr Nikolenko and Aleksei Bykov and Alexander Pecheny and Alexandr Yarats and Arsenii Shevchenko and Denis Bykov and Dmitry Pervukhin and Ismail Gadzhiev and James Liounis and Kevin Hu and Kirill Priemko and Maksim Gaiduk and Maksim Morozov and Marko Kevac and Michael Liang and Mikhail Galanin and Nandor Licker and Nataliya Pevgova and Nikita Kireev and Nikolai Tretiak and Paul Schofield and Saif Ali Raja and Saleh Alghusson and Sebastian Sepulveda and Sergei Miller and Svyatoslav Feldsherov and Vitalii Polshkov and Vladimir Zaytsev and Denis Yarats},
  title = {{Architecting and evaluating an AI-first Search API}},
  date = {2025-09-25},
  url = {https://www.perplexity.ai/hub/blog/architecting-and-evaluating-an-ai-first-search-api}
}