تحسينات على جميع مستويات الجهد في Agent API

تتيح مستويات الجهد في Perplexity Agent API للمطورين اختيار التوازن بين التكلفة والسرعة وعمق البحث لكل مهمة. واليوم، أصبحت تكلفة كل مستوى جهد أقل لكل استعلام، مع جودة بحث أعلى أو دون تغيير. ويتوفر مستوى ultra جديد لأوسع الأبحاث نطاقًا وأكثرها شمولًا. وأي طلب يختار المستوى باسمه، مثل effort="fast"، يحصل على الإعداد المحدَّث تلقائيًا.

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

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

تحسّن أداء medium من 55% إلى 77% على BrowseComp وDSQA، بينما انخفضت التكاليف بنحو 90%. ويُعد BrowseComp وDSQA معيارَي أداء بحثيين عامّين؛ أما WANDR فهو معيار الأداء الخاص بـ Perplexity لمهام البحث الطويلة متعددة الكيانات. ويؤدي xhigh أعمالًا وكيلية مثل تنفيذ التعليمات البرمجية في Sandbox، والحفاظ على حلقات طويلة من استخدام الأدوات، والعمل عبر مصادر كثيرة في آنٍ واحد. وقد حافظ xhigh على نتيجته في WANDR عند 76.5% مع تشغيله بنحو 25% من تكلفة إعداد أغسطس 2026.

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

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

أدى حل كل تحدٍّ من هذه التحديات إلى خفض التكاليف لكل مستوى جهد دون تقليل الأداء.

لكل مستوى جهد ميزانية بحث ثابتة تتكوّن من ثلاثة مكوّنات:

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

الميزانية هي المفاضلة المحورية: فالمزيد من الخطوات يعني إجابات أفضل، وكل خطوة تترتب عليها تكاليف. مع openai/gpt-6-luna، يؤدي رفع حد الخطوات من 1 إلى 15 إلى زيادة الدقة على BrowseComp + DSQA من 41% إلى 80%، بينما ترتفع التكلفة لكل استعلام من 0.0017 دولار إلى 0.0152 دولار، أي نحو 9 أضعاف التكلفة مقابل نحو ضعفَي النتيجة.

لا يتحكم حد الخطوات وحده في تكلفة البحث. فضمن ميزانية الخطوات الخمس نفسها، يُجري openai/gpt-6.1-terra استدعاءات أدوات أكثر من openai/gpt-6-luna، لأن النماذج الأقدر تميل إلى إصدار عدة استدعاءات في خطوة واحدة. وتضع مستويات الجهد حدًا أقصى لكل من استدعاءات الأدوات والخطوات. وبالنسبة إلى هذه النماذج، يكتسب الحد الأقصى لاستدعاءات الأدوات أهمية حد الخطوات نفسها.

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

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

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

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

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

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

بدلًا من تسليم الوكيل صفحة كاملة، يُجري fetch_url أولًا مرحلة استخراج. إذ يُرسَل نص الصفحة إلى نموذج أصغر مع المهمة الحالية للوكيل. ويُرجع النموذج المقاطع ذات الصلة فقط، مقتبسةً حرفيًا حتى يتمكن الوكيل من الاستشهاد بها. وخلال أحد التقييمات، تقلّصت صفحة من 5,561 رمزًا إلى 293 رمزًا، ما أتاح مساحة لمزيد من السياق ذي الصلة.

أدى استخدام fetch_url مع الاستخراج عند مستوى الجهد high إلى خفض رموز الإدخال لكل استعلام بنحو 50%. كما حسّن الاستخراج الأداء على معايير الأداء، إذ حقق 88.0% بتكلفة 0.073 دولار لكل استعلام، مقارنةً بـ 83.5% بتكلفة 0.094 دولار من دون استخراج.

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

سياق أكبر لكل عملية بحث: تُرجع كل عملية بحث الآن ما يصل إلى 4K من الرموز (tokens) في النتائج بدلًا من 2K. فيجد الوكيل ما يحتاج إليه أسرع، ما يؤدي إلى عمليات بحث أقل وتكلفة أدنى.

محرّك مقتطفات جديد: تحصل نتائج البحث على مقتطفات تطابق الاستعلام بشكل أفضل، فلا يُثقَل الوكيل بنصوص غير ذات صلة.
البحث السريع: بسعر 1.00 دولار لكل 1K طلب، يقلّل Fast Search كلًّا من التكلفة وزمن الاستجابة لكل استدعاء بحث.

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

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

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

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

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

عند اختبار مهمة أخرى من WANDR، حمّل الوكيل مهارة البحث عن الأشخاص (people-search) مع نمط التوزيع المتفرّع (fanout) للعثور على مهندسي الاستنتاج (inference) في لندن. فوسّع 39 مصطلحًا للأدوار إلى 117 استعلامًا، ثم دمج نتائج المرور الأول في 43 ملفًا شخصيًا فريدًا لمزيد من الفرز. ووجّهت مهارة البحث عن الأشخاص الوكيلَ خلال عملية التوسيع هذه دون إضافة سياق غير ذي صلة. والمقتطف أدناه مقتبس من النص البرمجي للوكيل؛ وأسماء الدوال المساعدة توضيحية.

code1

text

Python

# roles contains the 39 role variants selected by the agent.
queries = []
for role in roles:
    queries.extend([
        {"query": f"Google DeepMind {role} London"},
        {"query": f"Google {role} London"},
        {"query": role, "company": "Google", "location": "London"},
    ])

results = pplx_sdk.search.people_many(
    queries, limit_per_query=50, concurrency=8
)

profiles = {}
for result in results:
    if not result.ok:
        continue
    for profile in result.result:
        if "linkedin.com/in/" not in profile.url:
            continue
        url = profile.url.split("?")[0].rstrip("/")
        previous = profiles.get(url, {})
        if url not in profiles or len(profile.summary or "") > len(
            previous.get("summary") or ""
        ):
            profiles[url] = {
                "url": url,
                "title": profile.title,
                "summary": profile.summary,
            }

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

في مهمة أخرى من WANDR، كان على الوكيل فرز الملفات الشخصية لـ 188 مهندسًا. فحمّل نمط نقاط الحفظ لتسجيل كل نتيجة أثناء عمله. واستخرج المرور الأول 160 ملفًا شخصيًا لكنه فشل في 28. وعندما شغّل الوكيل النص البرمجي مرة أخرى، تخطّى الملفات الشخصية التي سبق تسجيلها وأعاد محاولة الـ 28 المتبقية فقط. ومن دون نقطة الحفظ، كان سجل واحد تالف سيعني جلب الملفات الـ 188 كلها من جديد.مقتطف Python مقتبس؛ مع حذف صفحات الإدخال وتعليمة الفرز والمخطط (schema) وعمليات الاستيراد؛ وأسماء الدوال المساعدة توضيحية.

code 2

text

Python

checkpoint = Checkpoint("research/profile-screening")
config = instruction + json.dumps(schema)
config_id = hashlib.md5(config.encode()).hexdigest()[:6]

def checkpoint_key(page):
    url_id = hashlib.md5(page["url_in"].encode()).hexdigest()[:10]
    return config_id + url_id

pending = [
    page for page in pages if not checkpoint.has(checkpoint_key(page))
]
for offset in range(0, len(pending), 20):
    batch = pending[offset : offset + 20]
    inputs = [
        json.dumps({
            "url": page["url_in"], "content": page["content"][:30_000]
        })
        for page in batch
    ]
    results = pplx_sdk.llm.extract_many(
        inputs,
        instruction=instruction,
        output_schema=schema,
        chunk_size=5,
        concurrency=4,
    )
    for page, result in zip(batch, results):
        if not result.ok or result.result.error:
            continue
        checkpoint.record(
            checkpoint_key(page),
            [{"url": page["url_in"], **result.result.result}],
        )

تسجّل نقطة الحفظ النتائج الناجحة، لكنها لا تُطلق عمليات إعادة المحاولة. ويضمن تضمين التعليمة والمخطط (schema) في المفتاح أن يؤدي تغيير معايير الفرز إلى إعادة المعالجة.

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

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

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

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

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

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

يدعم Agent API أدوار وكلاء محددة مسبقًا، ويمكن للمنسّق إنشاء وكلاء فرعيين بتعليمات مخصصة.

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

على WANDR، يحقق ultra نتيجة 85.9% بتكلفة 21.71 دولار لكل مهمة. وهي أعلى نتيجة بين الإعدادات التي خضعت للاختبار.

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

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

جرّب Agent API وقارن مستويات الجهد على أحمال العمل الخاصة بك. واطّلع على تفاصيل مستويات الجهد في وثائق مستويات الجهد في Agent API.

تكلفة البحث

التحكم في ميزانية البحث

إدارة السياق

ضغط السياق

جلب ما يهم فقط

بحث ويب مركّز

اختيار سير العمل الصحيح

اختيار النموذج

التوسّع متعدد الوكلاء

ماذا بعد؟