Amazon Bedrock Web Search: اختبار قبول للإجابات المستندة إلى مصادر لأنظمة الإنتاج

ابدأ باختبار أدلة الاستشهادات، وليس بملخص إطلاق

أصبح Amazon Bedrock Web Search الآن أداة مدمجة لتأصيل استجابات نماذج الأساس المحددة في نتائج الويب. أعلنت AWS الإتاحة العامة في 04 أغسطس 2026، وتصف الميزة بأنها قدرة من Bedrock على جانب الخادم يمكنها استرجاع معرفة حديثة من الويب، وإرجاع استشهادات بالمصادر، وتجنب تكامل منفصل مع مزود بحث خارجي. هذا مفيد، لكنه لا يكفي كدليل للاستخدام في الإنتاج.

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

تقول وثائق AWS إن Web Search متاح لنماذج OpenAI GPT المقدمة عبر نقطة نهاية Amazon Bedrock bedrock-mantle باستخدام Responses API. النماذج المدعومة المدرجة في الوثائق الحالية هي openai.gpt-5.4 و openai.gpt-5.5 و openai.gpt-5.6، بما في ذلك متغيرات luna و terra و sol. المناطق الموثقة هي US East (N. Virginia) us-east-1 و US East (Ohio) us-east-2 و US West (Oregon) us-west-2. يجب التعامل مع هذه التفاصيل كقيود نشر، لا كهوامش. إذا كان مسار الإنتاج لديك خارج هذه النماذج أو المناطق، فهذه الأداة الأصلية ليست المسار الذي يجب اختباره أولا.

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

اختبار Optijara لقبول الإجابات المستندة إلى مصادر

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

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

تخطيط الاستعلام واستدعاء الاسترجاع

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

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

يجب أن يختبر المسار أيضا سلوك عدم خروج البيانات. تنص وثائق AWS على أن Web Search يقدم افتراضيا من فهرس الويب والذاكرة المؤقتة في Amazon Bedrock، وأن بيانات الطلب لا تغادر حدود AWS لأغراض الاسترجاع. وتوضح الوثائق نفسها أن معامل external_web_access وصلاحية IAM المسماة bedrock-websearch:ExternalWebAccess يتحكمان فيما إذا كان البحث والجلب قد يصلان مباشرة إلى الويب الخارجي، وأن ضبط external_web_access على false يبقي الاسترجاع داخل حدود AWS. يجب أن يشغل اختبار القبول لديك حالتي السياسة المسموح بهما صراحة وأن يتحقق من سلوك التفويض والإجابة المرصود.

اكتمال الاستشهادات، وأمانة المقاطع، والمصادر المتضاربة

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

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

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

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

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

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

يجب قياس زمن الاستجابة كتوزيع، لا كمتوسط واحد. تتبع p50 و p95 و p99 للمسارات المؤصلة وغير المؤصلة. قم بتضمين بدايات التشغيل الباردة، والأدوار متعددة الاستعلامات، وسلوك البث، وإعادات المحاولة. قد يبدو المسار مقبولا في عرض تجريبي ومع ذلك يفشل SLO إنتاجيا عندما يزداد الذيل الطويل.

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

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

مصفوفة قرار مسار التأصيل

قائمة تنفيذ مرجعية

1. تأكد من أن النموذج هو openai.gpt-5.4 أو openai.gpt-5.5 أو openai.gpt-5.6 على Bedrock bedrock-mantle Responses API.
2. تأكد من أن منطقة النشر هي us-east-1 أو us-east-2 أو us-west-2.
3. قرر ما إذا كان external_web_access يجب أن يكون false للاسترجاع المضبوط الحدود.
4. اضبط إجراءات IAM للبحث والجلب، وامنح ExternalWebAccess فقط عندما تسمح السياسة بذلك.
5. خزّن تعليقات الاستجابة الخام واعرض عناوين URL للمصادر بجانب نص الإجابة.
6. ابن مجموعة معيارية تضم حقائق حديثة، وحقائق قديمة، ومصادر متضاربة، وتسعيرا، ووثائق، وضوابط سلبية.
7. قيّم اكتمال الاستشهادات، وسلطة المصدر، وأمانة المقاطع، وفجوة الحداثة، والاستدعاء، وزمن الاستجابة، والتكلفة، وجودة الرفض.
8. عرّف مسارات الرجوع الاحتياطي إلى الاسترجاع المباشر، أو RAG خاص، أو إجابة مخزنة مؤقتا، أو استجابة تفيد بعدم كفاية الأدلة.
9. راقب CloudTrail، وسجلات التطبيق، واستخدام الرموز، واستدعاءات الأدوات، ورموز الحالة، وأخطاء الاستشهاد.
10. ابدأ بكناري، ثم وسع فقط عندما تبقى النتائج المقاسة داخل العتبات.

أخطاء شائعة، ومحاذير، وقياس

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

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

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