تعلّمت Bedrock Knowledge Base اختيار عمق البحث: من صفر استدعاء لنموذج اللغة إلى RAG الوكيلي

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

تسدّ AWS هذه الفجوة في Amazon Bedrock Managed Knowledge Base. فقد كان الوضع الوكيلي وحده متاحاً سابقاً عبر AgenticRetrieveStream، والآن أُضيف وضعان آخران.

معامل واحد بدلاً من واجهتي API

يتم التحكم في كل شيء عبر maxAgentIteration. أصبح النطاق الآن من 0 إلى 5، ويتوقف سلوك الاستعلام على القيمة.

0 — بحث فقط. تُجري الخدمة بحثاً واحداً مضموناً ولا تولّد شيئاً. لا توجد استدعاءات لـ foundation model، وهو عملياً مكافئ لواجهة Retrieve API المعتادة. يناسب هذا الوضع من انتقلوا بالفعل إلى AgenticRetrieveStream ولا يريدون التحول إلى واجهة أخرى لمجرد استعلام بلا توليد. وإذا ضُبط generateResponse=true مع القيمة 0 فسيعود خطأ 4xx، لأن الإجابة تحتاج إلى نموذج لغوي.

1 — RAG الكلاسيكي. بحث واحد واستدعاء واحد للنموذج لتوليد الإجابة، دون تخطيط أو إعادة صياغة للاستعلام. مثال من المقال: «ما المستندات اللازمة لفتح حساب تجاري لرائد أعمال فردي؟». قائمة التحقق موجودة في القاعدة، والمخطِّط لن يضيف هنا سوى التأخير. وإذا كان معظم حركة الاستعلامات أسئلة مباشرة ومحددة بوضوح، فتلمّح AWS إلى أن هذا هو خيارك الافتراضي.

2–5 — الوضع الوكيلي. يقسّم النموذج السؤال إلى استعلامات فرعية، ويبحث في كل منها، ويقيّم هل ما وُجد كافٍ، وعند الحاجة يدقّق البحث أو يجلب المستند كاملاً. القيم 2–5 تعمل كما كانت، فلن تتعطل الاستعلامات القائمة.

كيف تُحتسب التكرارات

القاعدة بسيطة: تكرار واحد يساوي استدعاءً واحداً لـ foundation model. ويُخصَّص التكرار الأخير دائماً لتوليد الإجابة. لذلك تمنح القيمة n حتى n−1 جولة تخطيط، وكل جولة تتكون من إعادة صياغة الاستعلام ثم البحث.

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

وتشدد AWS على أن البحث الواحد لا يعني قاعدة معرفة واحدة. فالأوضاع الثلاثة كلها، بما فيها 0 و1، تعمل مع عدة قواعد. ويضيف الوضع الوكيلي تفكيك السؤال وتقييم الأدلة المعثور عليها والبحث التكراري، أما دعم تعدد القواعد فلا يعتمد عليه.

وفي مثال المصرف يبدو الأمر هكذا. لسؤال قائمة تحقق الرائد الفردي نضبط maxAgentIteration=1 وgenerateResponse=true. وللمقارنة بين الرائد الفردي والشركة ذات المسؤولية المحدودة مع فحوص غير المقيمين نضبط 4، أي حتى ثلاث جولات تخطيط. وحين يحتاج الموظف إلى نص اللائحة نفسه لا إلى تلخيصه، نضبط 0 وgenerateResponse=false، فيعرض التطبيق المقاطع مع روابط المصادر. والانتقال من الاستدعاء الوكيلي إلى RAG العادي هو تعديل رقم واحد في JSON.

القيود وما يُفعل عملياً

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

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

الثالث: أمثلة المصرف في المقال توضيحية. ولا تقدّم AWS أي قياسات للتأخير أو التكلفة أو الجودة. والقول إن single-shot يخفض زمن الاستجابة واستهلاك النموذج مقارنة بالوضع الوكيلي منطقي، لكن لا أرقام تسنده. فلا تأخذه على أنه مسلَّم به.

وهذه خطة عملية:

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

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