إعادة التفكير في البحث كتوليد شفرات

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

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

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

تخدم بنية البحث الخاصة بـ Perplexity آلاف الاستعلامات كل ثانية عبر تطبيقاتنا ومنصة واجهة برمجة التطبيقات (API Platform). في سبتمبر 2025، نشرنا أول نظرة عامة معمارية لأنظمة البحث لدينا. وقد دعم الابتكار المستمر داخل هذه الأنظمة إطلاق عروض جديدة مثل واجهة برمجة تطبيقات البحث، وواجهة برمجة تطبيقات الوكيل، وComputer، مع حلقات التحسين الذاتي التي تعمل على تحسين بنية البحث لخدمة المستخدمين بشكل أفضل مع مرور كل يوم.

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

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

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

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

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

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

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

يعمل البحث كبرمجيات (SaC) على دفع حدود أداء البحث الموجه بالوكلاء عبر مجموعة متنوعة من المعايير القياسية.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تعتمد بنية البحث كبرمجيات (SaC) على مكدس يضم النماذج، وصناديق الحماية الحاسوبية، ومجموعة أدوات تطوير برمجيات للبحث الذكي تقع فوق البنية الأساسية للبحث لدى Perplexity.

يتضمن SaC ثلاث طبقات مترابطة بإحكام:

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

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

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

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

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

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

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

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

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

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

درسنا نهجين لإدارة الحالات الوسيطة عبر الدورات:

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

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

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

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

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

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

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

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

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

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

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

نقدم دراسة حالة تعتمد على مهمة واقعية داخل مجموعة الاختبار الخاصة بنا. تطلب هذه المهمة من الوكيل تحديد وتوصيف أكثر من 200 ثغرة أمنية عالية الخطورة (CVE) من 2023-2025. يجب أن يستشهد كل سجل باستشارة البائع المتأثر نفسه، وتسمية المنتج وإصدار الإصلاح، وإظهار أن إصدار الإصلاح مرتبط بثغرة الضعف الأمنية المحددة.

حقق إجابة SaC نسبة 100% في الدقة، مع انخفاض الاستخدام الإجمالي للرموز بنسبة 85.1% مقارنة بخط الأساس لـ غير SaC (من 288.7 ألف رمز إلى 42.9 ألف رمز). الأنظمة غير التابعة لـ Perplexity التي تم اختبارها، والتي تمت مناقشتها بمزيد من التفصيل في القسم 4، سجلت جميعها أقل من 25%.

نقدم ثلاث كتل شفرات مصممة من المسار لتوضيح كيف تتيح قابلية البرمجة لـ SaC للنموذج تطبيق استراتيجيات فعالة.

python

# Part 1 of 3: fan out over official advisory formats.
templates = [
    ("Mozilla",
     'site:mozilla.org/en-US/security/advisories/mfsa{year} '
     '"CVE-{year}-" "Fixed in" "Impact high"'),
    ("Jenkins",
     'site:jenkins.io/security/advisory/{year} '
     '"CVE-{year}" "Severity" "High" "Fix"'),
    ("Chrome",
     'site:chromereleases.googleblog.com/{year} '
     '"High CVE-{year}" "Stable channel has been updated"'),
    ("Android",
     'source.android.com/docs/security/bulletin/{year}-{month:02d}-01 '
     '"High" "CVE-{year}"'),
    ...
]

queries = [
    {"vendor": vendor, "query": pattern.format(year=year, month=month)}
    for year in [2023, 2024, 2025]
    for vendor, pattern in templates
    for month in ([1] if "{month" not in pattern else range(1, 13))
]

seed_hits = sdk.search.web_many(queries, limit_per_query=8, concurrency=12)

pages = [
    {"vendor": q["vendor"], "url": h.url, "text": join_result_fields(h)}
    for q, hits in zip(queries, seed_hits)
    for h in hits
    if official_vendor_advisory(h.url, q["vendor"])
]

هذه الكتلة الأولى هي تنسيق خالص. يبدأ البرنامج المُولَّد بترميز قاعدة فئة المصدر مباشرة في خطة الاستعلام: فقط تنسيقات الاستشارات المملوكة للبائع ذات صلة. المصادر غير التابعة للبائع بما في ذلك NVD، وMITRE، وتفاصيل CVE، وقصص الأخبار، صفحات CERT، وقواعد البيانات التابعة لجهات خارجية خارج النطاق هيكلياً. تدفع قيود العبارة الدقيقة أيضاً البحث نحو الصفحات التي يحتوي نصها المفهرس بالفعل على تفاصيل CVE الدقيقة المطلوبة لاحقاً.

python

# Part 2 of 3: synthesize refinements for sparse vendor-years.
coverage = summarize(pages, by=["vendor", "year", "url_kind"])

prompt = """
Goal: 230+ high or critical CVEs from official vendor advisories.
Avoid aggregators, CERTs, news, NVD, MITRE, and CVE databases.
Current coverage:
{coverage}
Suggest more site-scoped exact-phrase queries for sparse vendor-years.
Prefer per-advisory pages over archive or month-index pages.
Return JSON lines with vendor and query.
""".format(coverage=coverage)

raw = query_llm(prompt)

expanded_queries = [
    row for row in parse_jsonl(raw)
    if official_scope(row["query"]) and mentions_cve_year(row["query"])
]

expanded_hits = sdk.search.web_many(
    unique(expanded_queries),
    limit_per_query=8,
    concurrency=12,
)

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

python

# Part 3 of 3: verify CVE-to-version binding.
all_hits = dedupe_by_url(flatten(seed_hits) + flatten(expanded_hits))

items = [
    {"url": h.url, "vendor_hint": infer_vendor(h.url),
     "text": join_result_fields(h)}
    for h in all_hits
    if official_vendor_advisory(h.url, infer_vendor(h.url))
]

verified = sdk.llm.extract_many(
    items,
    instruction=(
        "Keep only vendor advisories where the page ties a high or critical "
        "CVE to a specific fixed version, build, patch, or security level."
    ),
    schema={
        "matches": bool,
        "cve": str,
        "vendor": str,
        "product": str,
        "fix_version": str,
        "severity": str,
        "source_url": str,
        "evidence": str,
        "version_bound_to_cve": bool,
        "confidence": float,
    },
)

records = [
    to_cve_record(x) for x in verified
    if x.matches and x.version_bound_to_cve
    if high_or_critical(x.severity) and x.confidence > 0.75
]
records = dedupe_by(records, key="cve")

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

نحن نقيم فعالية SaC على مجموعة معايير شاملة، مع التركيز على كل من الأداء المطلق وحدود التكلفة والأداء.

تضم مجموعة المعايير الخاصة بنا خمسة معايير في مجموعها، مصممة لاختبار الإجهاد لخطوط أنابيب عمل الذكاء الاصطناعي المعتمدة على البحث عبر نطاق من المجالات، وتنسيق المهام، ومستويات التعقيد. نحن نستخدم أربعة معايير موجودة مسبقاً: DeepSearchQA (DSQA)، وBrowseComp، وHumanity's Last Exam (HLE)، وWideSearch. بالنسبة للمعايير الثلاثة الأولى (DSQA، BrowseComp، وHLE)، نبلغ عن الدقة كمقياس رئيسي. بالنسبة لـ WideSearch، نبلغ عن درجة F1 حسب الصف.

نستخدم أيضاً معيار WANDR الذي تم تطويره حديثاً، والذي يركز على مهام "البحث الواسع" الصعبة التي تتطلب تنسيقاً دقيقاً للبحث والحوسبة واستدلال النمهذج. يستوحى WANDR من المهام المهنية الكثيفة المعرفة التي تتعامل معها Perplexity Computer للمستخدمين. وهو يتكرر على WideSearch والمعايير المشابهة، لكنه يؤكد على المهام والهياكل الأكثر تعقيداً. سنقوم بنشر معيار WANDR في الأسابيع القادمة.

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

Perplexity (SaC): نقيم بنية SaC ضمن واجهة برمجة تطبيقات وكيل الإنتاج الخاصة بـ Perplexity. يعمل GPT 5.5 (استدلال عالٍ) كالنموذج الأساسي.

OpenAI: نقيم واجهة برمجة تطبيقات الاستجابات من OpenAI مع تمكين كل من البحث (web_search) وقت تشغيل Python (code_interpreter). يعمل GPT 5.5 (استدلال عالٍ) كالنموذج الأساسي.

Anthropic: نقيم وكلاء Anthropic المُدارين مع مجموعة أدوات الوكيل 20260401 والأوامر المسموح بها تلقائياً. يعمل Opus 4.7 (استدلال عالٍ) كالنموذج الأساسي.

Exa: نقيم وكيل Exa عبر واجهة برمجة تطبيقات الإنتاج، مع ضبط الجهد على مرتفع.

Parallel: نقيم مهام Parallel عبر واجهة برمجة تطبيقات الإنتاج، مع ضبط المعالج على ultra4x.

يعرض الجدول 1 درجات المعايير لكل نظام. يتفوق SaC على جميع الأنظمة الأخرى على أربعة من المعايير الخمسة. على المعيار المتبقي (HLE)، يتعادل SaC أساساً في المركز الأول مع استجابات OpenAI. يصور الشكل 2 من المقدمة هذه الدرجات في شكل رسومي.

المعيار	Perplexity (SaC)	OpenAI	Anthropic	Exa	Parallel
DSQA	0.871	0.733	0.815	0.530	0.810
BrowseComp	0.805	0.720	0.598	0.380	0.560
HLE	0.612	0.614	0.566	0.387	0.515
WideSearch	0.651	0.522	0.590	0.471	0.584
WANDR	0.386	0.130	0.152	0.057	0.126

الجدول 1 | درجات المعايير لكل نظام مُقيم. أفضل درجة لكل صف بالخط العريض.

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

درجات WANDR عبر الأنظمة المقيمة. تقود واجهة برمجة تطبيقات وكيل Perplexity النظام الأفضل التالي بمعامل 2.5×.

أخيراً، نقيس المكاسب النسبية لـ SaC مقابل خط أنابيب بحث تقليدي أكثر يستفيد من نفس البنية الأساسية للبحث لـ Perplexity. يبلغ الشكل 6 عن الفرق في درجات بين بنيات SaC وغير SaC عبر كل معيار. في جميع المجالات، يوفر SaC دفعة كبيرة في الأداء، مع أكبر مكسب مطلق على DSQA (+19.77 نقطة مئوية، 29%) وأكبر مكسب نسبي على WANDR (+12.00 نقطة مئوية، 45%).

خط الأساس لـ Perplexity مقابل درجات SaC في كل معيار، مع تعليق الدلتا المطلقة والنسبية.

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

درجة DSQA مقابل السعر لكل مهمة. يربط الخط المتقطع تكوينات استدلال نموذج SaC.

على DSQA، تقع جميع إعدادات SaC الثلاثة على الحدود اليمنى العليا. إعداد الاستدلال المنخفض أرخص من جميع الأنظمة الأخرى بينما يؤدي بشكل أفضل من اثنين منها. يتفوق إعداد الاستدلال المتوسط على جميع الأنظمة غير التابعة لـ SaC بأقل من 1 دولار لكل مهمة. يحقق إعداد الاستدلال العالي أعلى أداء بتكلفة تنافسية.

درجة WideSearch مقابل السعر لكل مهمة. يربط الخط المتقطع تكوينات استدلال نموذج SaC.

يظهر WideSearch حدوداً ذات شكل مشابه. كما هو الحال مع DSQA، يحقق إعداد الاستدلال المنخفض أداءً تنافسياً بتكلفة أقل من جميع الأنظمة غير التابعة لـ SaC، بينما يتفوق كل من الاستدلال المتوسط والعالي على الأنظمة غير التابعة لـ SaC في أداء المهمة.

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

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

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

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

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

BibTeX

@online{perplexity2026RethinkingSearchAsCodeGeneration,
  author = {{Perplexity} and Denis Bykov and Aleksandr Nikolenko and Artur Zayats and Maksim Gaiduk and Vitalii Polshkov and Akshay Nair and James Liounis and Kirill Priemko and Ryan Buchmayer and Phi Hoang and Jerry Ma},
  title = {{Rethinking search as code generation}},
  date = {2026-06-01},
  url = {https://perplexity.coolkeypoint.com/hub/blog/rethinking-search-as-code-generation}
}

مقدمة

جمود البحث التقليدي

أنماط الفشل الناتجة عن الجمود

تصميم بنية بحث قابلة للبرمجة

مجموعة أدوات تطوير برمجيات للبحث الذكي (Agentic Search SDK)

صناديق الحماية (Sandboxes)

النماذج

الشفرة كمنسق ومالئ للثغرات

دراسة حالة: استشارات بائع ثغرات الضعف الأمنية (CVE)

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

المعايير والأنظمة

الأداء المقارن

حد التكلفة والأداء

نحو بنية جديدة للحوسبة

اقتباس