Perplexity Fast Search أم البحث الافتراضي: أي وضع يناسب عملك؟

Perplexity Fast Search أم البحث الافتراضي: أيهما تختار؟

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

يوصي دليل Fast Search المباشر من Perplexity باستخدام fast في الأعمال اليومية للوكلاء، والإبقاء على إعداد web الافتراضي للأسئلة النادرة أو الصعبة أو الملتبسة. جرى التحقق من الأسعار وقياسات المورّد الواردة في هذه المقارنة بالرجوع إلى صفحات Perplexity المباشرة في 24 سبتمبر 2026.

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

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

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

ماذا يتغير في Perplexity Fast Search API مع Photon؟

يغيّر Fast Search ميزانية الاسترجاع، لا نقطة النهاية ولا بنية النتائج. أطلقت Perplexity هذا الوضع في 24 سبتمبر 2026، وهو مدعوم بمحرك Photon الداخلي للاسترجاع والترتيب. وتؤكد وثائق Fast Search المباشرة توافره: فنقطة النهاية نفسها POST /search تعيد مصفوفة results[] المرتبة نفسها، وكل ما يضاف إلى الطلب هو search_type: "fast".

إذا حُذف search_type، تستخدم Perplexity وضع web القياسي. وهذه نقطة مهمة، لأن كلمة «افتراضي» هنا لا تشير إلى نموذج اللغة الافتراضي في تطبيق Perplexity الموجّه للمستهلك، بل إلى وضع الاسترجاع القياسي في Search API. يعيد الوضعان العناوين والروابط والمقتطفات، إلى جانب تواريخ النشر والتحديث الاختيارية، كي تُعالج لاحقاً.

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

Perplexity Photon هو المحرك، وليس وضعاً ثالثاً

Photon بنية تحتية ضمن منظومة البحث لدى Perplexity. وتظل خيارات API هي fast وweb ونوع البحث المنفصل people. لا يختار المطوّر Photon مباشرة، ولا ينشره، ولا يتلقى كائن استجابة مختلفاً.

أما القيد العملي الحالي في حزم SDK، فتوضح Perplexity استخدام extra_body={"search_type": "fast"} مع إصداري مكتبة Python رقم 0.43.4 و0.43.5، لأن التحقق المباشر يرفض القيمة الجديدة. ويحوّل مثال TypeScript القيمة إلى "fast" as any مع SDK 0.38.5 إلى أن تلحق الأنواع بالتحديث. وتتجاوز طلبات HTTP المباشرة كلا القيدين المؤقتين على جانب العميل.

تكلفة Perplexity Search API: ‏$10 مقابل $50 عند 10,000 طلب

الفائز: Fast Search. يفرض جدول أسعار Perplexity المباشر $1 لكل 1,000 طلب خام ناجح عبر Fast Search، و$5 لكل 1,000 طلب ناجح عبر البحث الافتراضي، من دون رسوم إضافية على الرموز في Search API.

الحساب الموحّد لعبء العمل واضح:

• 10,000 استدعاء Fast Search: ‏10,000 × $0.001 = $10.
• 10,000 استدعاء للبحث الافتراضي: ‏10,000 × $0.005 = $50.
• الفارق: $40، أي خفض بنسبة 80% في بند تكلفة الاسترجاع الخام.

لكن مبلغ $40 لا يمثل فاتورة الوكيل كاملة. فهناك في المراحل اللاحقة النموذج الذي يقرأ النتائج، وعمليات الجلب الإضافية، وإعادة المحاولة، والتحقق، والمراجعة البشرية. لا يتفوق Fast فعلياً إلا إذا لم يولّد أكثر من $40 من العمل الإضافي عبر تلك الدفعة المؤلفة من 10,000 طلب.

حتى الاستجابات الناجحة والفارغة لها تكلفة

تُحتسب تكلفة استجابة POST /search الناجحة حتى عندما تكون results[] فارغة. أما الطلبات غير الصالحة، والطلبات المقيدة بمعدل الاستخدام، وحالات الفشل لدى الجهات المزودة في المراحل السابقة فلا تُفوتر وفق قواعد التسعير الحالية. لذلك يصبح معدل النتائج الفارغة مقياساً للميزانية، لا للجودة فحسب.

التجميع يغيّر الفاتورة، لا قرار الجودة

يقبل دليل البدء السريع للاستعلامات المتعددة من Perplexity ما يصل إلى خمسة استعلامات مترابطة في طلب واحد. ويُعد الطلب الناجح متعدد الاستعلامات وحدة فوترة واحدة، مع بقاء كل استعلام محسوباً ضمن حدود معدل الاستخدام. لذا فإن حزم عشرين استعلاماً في أربعة طلبات لكل وضع سيكلف $0.024 إجمالاً، مقابل $0.12 عند إرسال 40 طلباً منفصلاً أحادي الاستعلام.

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

ضع أسعار أدوات Agent API في بند ميزانية مستقل

يعرض جدول أدوات Agent API أسعاراً قياسية مختلفة: $1 لكل 1,000 استدعاء web_search سريع و**$2.50 لكل 1,000 استدعاء قياسي للويب**، إضافة إلى رسوم رموز النموذج المختار. هذه ليست أسعار Search API الخام البالغة $1 و$5. كذلك، لا يُعد Fast Search إعداد fast المنفصل في Agent API، رغم استخدام الكلمة نفسها.

تجيب المقارنة الأقدم لتكلفة Perplexity مقابل Exa مقابل Tavily عن سؤال اختيار المورّد. أما هذا القرار فيأتي على مستوى أعمق، بعد أن تصبح Perplexity جزءاً من المنظومة بالفعل.

Fast يتفوق في زمن الاستجابة، مع تحفظ على قياس المورّد

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

هذه القيم المئينية مهمة. تمثل p50 الطلب الواقع في المنتصف، بينما تمثل p95 العتبة التي يكتمل ضمنها 95% من الطلبات. ويتأثر الوكيل الذي يجري عدة عمليات بحث متسلسلة بالطرف البطيء أكثر من تأثره بالوسيط، لأن استدعاء أداة واحداً متأخراً قد يبقي الخطة بأكملها معلقة.

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

تلخص صياغة الممارس Mikhail Basyuk المعيار الصحيح: لا تكون p95 الأقل من 250 ms مفيدة إلا إذا بقيت الصلة التي تحتاج إليها المهمة. يجب أن تظهر السرعة والأدلة على لوحة القياس نفسها.

البحث الافتراضي يتفوق في التغطية

الفائز: البحث الافتراضي على الويب في الأبحاث الصعبة والملتبسة. يمنح مخطط الاسترجاع الداخلي من Perplexity وضع Fast Search درجة صلة 2.21 مقابل 2.45 للوضع الافتراضي، بفارق 0.24 نقطة. ويبلغ توافر الإجابة 0.567 مقابل 0.596، بفارق 2.9 نقطة مئوية.

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

وتعرض Perplexity أيضاً نتيجة تبدو معاكسة في مخطط المورّد التجميعي عبر ستة اختبارات مرجعية عامة للوكلاء و3,554 مهمة مختارة: سجل Fast نسبة 64.3% بتكلفة إجمالية مقدرة قدرها $59.73 للنموذج والبحث، بينما سجل الوضع الافتراضي 64.0% بتكلفة $187.60. ويصف المورّد إعداد fast بأنه أوفر بنحو 68% مع جودة إجمالية متقاربة للمهام.

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

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

كيف تضبط نوع البحث على Perplexity Fast Search؟

استخدم الطلب نفسه مرتين وغيّر search_type فقط. أبقِ query وmax_results وsearch_context_size وعوامل التصفية والمنطقة وموقع العميل ثابتة. توضح مرجعية Search API المباشرة أن web هو الوضع الافتراضي، وأن القيمة الافتراضية لـmax_results هي 10، ولحجم السياق المستخرج هي high. اضبط متغيري المقارنة صراحة كي لا يغيّر أي إعداد افتراضي مستقبلي في API نتيجة إعادة التشغيل.

يمكن تشغيل زوج الطلبات التالي كما هو مكتوب:

set -euo pipefail
: "${PERPLEXITY_API_KEY:?Set PERPLEXITY_API_KEY first}"

QUERY='Which CRM has the stronger current EU data residency and audit-control evidence?'
COMMON=$(jq -nc --arg query "$QUERY" '{
  query: $query,
  max_results: 10,
  search_context_size: "high"
}')

for MODE in fast web; do
  jq --arg mode "$MODE" '. + {search_type: $mode}' <<<"$COMMON" |
    curl -sS 'https://api.perplexity.ai/search' \
      -H "Authorization: Bearer $PERPLEXITY_API_KEY" \
      -H 'Content-Type: application/json' \
      -o "$MODE.json" \
      -w "$MODE\tHTTP %{http_code}\t%{time_total}s\n" \
      --data-binary @-
done

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

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

عند مستوى الاستعلام الواحد، تكلف هذه الطلبات الخام الناجحة البالغ عددها 40 مبلغ $0.12 قبل أي استدعاء لنموذج لاحق: $0.02 مقابل 20 استدعاء fast، و$0.10 مقابل 20 استدعاء للبحث الافتراضي.

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

ما التكلفة الفعلية للتحويل؟

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

ضع search_type ضمن مفتاح التخزين المؤقت. فلا ينبغي لاستجابة fast مخزنة أن تلبي بصمت طلباً لاحقاً للبحث الافتراضي دفع صاحبه مقابل استرجاع أوسع. وللسبب نفسه، ضمّن حجم السياق، وعدد النتائج، وعوامل التصفية، والدولة، واللغة.

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

اجعل إعادة المحاولة واعية بالوضع. فإعادة الطلب بعد انتهاء المهلة ضمن الوضع نفسه إجراء لتحسين التوافر، بينما إعادة الطلب بالانتقال من fast إلى web تصعيد متعلق بالجودة ويغيّر السعر. لا ينبغي جمع الحدثين في عدّاد واحد.

من ينبغي ألا يتحول إلى Fast Search؟

لا تجعل Fast Search الوضع الافتراضي الشامل في الحالات التالية:

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

النهج الأفضل للانتقال هو إطلاق موجّه على مراحل. انقل فئة متكررة واحدة إلى fast، وأبقِ web مساراً للتصعيد، وقارن الأدلة المقبولة قبل التوسع.

خطوة يوم الاثنين

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

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

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

هذه هي النتيجة العملية لـPhoton: ليس إعداداً عالمياً واحداً أقل تكلفة، بل موجّه عملي لمخاطر البحث. ينفق الوكيل $1 لكل 1,000 استدعاء عندما يكون الاستعلام متسامحاً مع النقص، ويدفع $4 الإضافية فقط حين يستطيع الاسترجاع الأوسع منع إخفاق أعلى تكلفة.

الأسئلة الشائعة

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