أضافت AWS مهارة amazon-opensearch-service إلى مجموعة أدوات الوكيل (Agent Toolkit) الخاصة بها، وقد قمت باختبارها عبر اختبار كامل المكونات (full-stack test) لبناء خلفية برمجية لتقنية التوليد المعزز بالاسترجاع (RAG) على Amazon OpenSearch Serverless NextGen. تقلص هذه الأداة الوقت اللازم لإعداد cluster من OpenSearch بمستوى الإنتاج، لكنها لا تزال تتعثر عندما تطلب من وكيل ذكاء اصطناعي تكوين البحث الشعاعي (vector search) في بيئة NextGen serverless.
لماذا تهم هذه المهارة
أصبح OpenSearch الآن الحزمة الافتراضية للمؤسسات التي تحتاج إلى نصوص قابلة للبحث، وتحليلات السجلات، وبشكل متزايد، البحث عن التشابه القائم على المتجهات (vector-based similarity search). إن إعداد cluster يجبرك على اتخاذ عشرات القرارات المترابطة: سياسات التشفير، وعزل الشبكة، وأدوار الوصول إلى البيانات، وتحديد حجم المثيلات (instance sizing)، وتخصيص الأجزاء (shard allocation)، وبالنسبة لأعباء عمل المتجهات، اختيار محرك k-NN. أي خطوة مفقودة قد تؤدي بك إلى الإفراط في تخصيص الموارد بتكلفة عالية أو مسار بحث معطل.
تعد المهارة الجديدة بوكيل ذكاء اصطناعي يترجم التعليمات باللغة الطبيعية إلى سلسلة دقيقة من استدعاءات API وملفات التكوين المطلوبة لنشر OpenSearch بشكل كامل.
ما هي هذه المهارة في الواقع
ليست روبوت دردشة يمكنك إجراء محادثة معه. فكر فيها كقاعدة معرفية مهيكلة يمكن لوكيل برمجة مؤتمت الاستعلام منها. تتضمن الحزمة ما يلي:
- معادلات تحديد الحجم (Sizing formulas) التي تحول حجم الاستعلام المتوقع وحجم البيانات إلى توصيات ملموسة لأنواع المثيلات ومستويات التخزين.
- منطق اختيار المحرك الذي يطابق أنماط أعباء العمل (نص فقط، هجين، متجهات فقط) مع محرك k-NN المناسب أو تكوين البحث الهجين.
- قوائم مراجعة الهجرة التي تقوم برسم خرائط المخططات (schemas) من Solr أو Elasticsearch إلى ما يعادلها في OpenSearch.
- وصفات Query DSL التي توفر مقتطفات جاهزة من لغة OpenSearch المخصصة للمجال (Domain Specific Language) لأنماط البحث الشائعة.
تتمحور المهارة حول خمس مهام أساسية:
- الهجرة (Migration) – تحويل مخططات Solr/ES الحالية.
- التخصيص (Provisioning) – حساب أحجام المثيلات، ومستويات التخزين، وسياسات الشبكة.
- البحث (Search) – اختيار محركات k-NN، وإعدادات البحث الهجين، وضبط معايير الصلة (relevance parameters).
- تحليلات السجلات (Log analytics) – التعامل مع استعلامات لغة Piped Processing Language (PPL) وتعاريف مسارات البيانات (pipeline definitions).
- تحليلات التتبع (Trace analytics) – تكوين مجمّعات OpenTelemetry ومسارات Data Prepper.
أين تتألق هذه المهارة
خلال تجربة الاختبار الخاصة بي، كان أكبر موفر للوقت هو منطق تسلسل السياسات. تعرف المهارة على الترتيب الصحيح وتزودني بقائمة مراجعة خطوة بخطوة، مما قلل وقت الإعداد بشكل كبير.
بالنسبة للنطاقات المدارة الكلاسيكية، تتطابق توصيات المهارة بشأن ترقيات المثيلات وحسابات الأجزاء (shard mathematics) مع تكوين الـ cluster الفعلي. فهي تقرأ عدد العقد الحالي، واستخدام التخزين، وزمن انتقال الاستعلام، ثم تخبرك ما إذا كنت بحاجة إلى المزيد من الأجزاء (shards)، أو مثيلات أكبر، أو مستوى تخزين مختلف. عادة ما تكون هذه النصائح المدركة للسياق (context-aware advice) مبعثرة عبر وثائق AWS المتعددة.
كما تفهم المهارة أيضاً العلامات (flags) الخاصة بـ NextGen مثل scale-to-zero، والتي تخبر الخدمة عديمة الخادم (serverless) بتحرير موارد الحوسبة عندما تكون المجموعة خاملة. ومن خلال تحديد هذا بشكل صحيح، تحافظ الأداة على انخفاض التكاليف دون الحاجة إلى تعديلات يدوية.
الفجوة الصارخة
لا تزال معالجة المهارة لـ vector mapping في NextGen Serverless عالقة في منطق الإصدار الكلاسيكي (Classic). عندما طلبت من الوكيل إعداد مجموعة مفعلة بالمتجهات (vector-enabled collection)، اقترح محرك FAISS. في الإصدار الكلاسيكي من Serverless يمكنك اختيار محرك k-NN، ولكن NextGen يقوم بتجريد ذلك (abstracts that away) — حيث تتم إدارة تسريع المتجهات تلقائيًا ولا يمكنك تحديد المحرك على الإطلاق. لذلك، تفشل التوصية تمامًا.
تضمن الخطأ الثاني، وهو أقل حدة، عدم الدقة في توقعات زمن انتقال الكتابة (write-latency). حذر المساعد من تأخيرات في الكتابة تتراوح بين 30 إلى 60 ثانية، وهو رقم ينطبق على عمليات نشر Classic Serverless القديمة. في اختبار NextGen الخاص بي، أصبحت المستندات قابلة للبحث في حوالي ثانيتين، مما جعل التحذير غير ذي صلة.
هذه العثرات مهمة لأن العديد من الفرق تتبنى NextGen تحديدًا لنموذجه التشغيلي المبسط. إذا قام مساعد الذكاء الاصطناعي بفرض إعدادات عصر Classic على cluster من نوع NextGen، فقد يتسبب ذلك في فشل النشر أو دورات تصحيح أخطاء لا داعي لها.
من يجب عليه (ومن لا يجب) استخدامها
إذا كنت تقوم بإنشاء clusters من OpenSearch بانتظام — سواء للبحث في النص الكامل، أو تجميع السجلات، أو أعباء العمل الهجينة — فإن هذه المهارة تعد شبكة أمان قوية. فهي تكتشف حالات السهو الشائعة مثل:
- Forgetting to attach encryption policies before collection creation.
- Accidentally provisioning a Classic collection when a NextGen one would be cheaper and easier to manage.
- Selecting an instance size that cannot sustain large vector workloads.
For teams whose primary need is pure vector search, the skill offers little advantage. Amazon’s S3 Vectors service provides a faster, cheaper path for simple RAG pipelines, and it does not require the complex provisioning steps the skill helps with.
What to watch next
The skill is already useful, but its next iteration needs two updates:
- NextGen-aware vector logic – the assistant must recognize that engine selection is unnecessary and instead guide the user through the parameters that actually affect vector performance in the serverless model (e.g., dimension limits, batch size).
- Current latency benchmarks – the knowledge base should be refreshed with the latest write-latency figures for both Classic and NextGen, so users get realistic expectations.
In the meantime, treat the skill as a guide, not a replacement for a seasoned OpenSearch engineer.
Takeaway
The amazon-opensearch-service skill trims the learning curve for complex OpenSearch configurations and helps avoid costly policy missteps. Its shortcomings are confined to the newest serverless vector features, which means it remains a valuable assistant for most workloads—provided you double-check any vector-related advice against the latest NextGen documentation.