AWS مهارت amazon-opensearch-service را به Agent Toolkit خود اضافه کرده است و من آن را با یک تست فولاستک برای ساخت یک بکاِند تولید بازیابیافزوده (RAG) روی Amazon OpenSearch Serverless NextGen مورد آزمایش قرار دادم. این ابزار زمان مورد نیاز برای راهاندازی یک کلاستر OpenSearch در سطح تولید را به شدت کاهش میدهد، اما زمانی که از یک عامل هوش مصنوعی (AI agent) میخواهید جستجوی برداری (vector search) را در محیط سرورلس NextGen پیکربندی کند، همچنان دچار خطا میشود.
چرا این مهارت اهمیت دارد
OpenSearch اکنون به پشته (stack) پیشفرض برای سازمانهایی تبدیل شده است که به متن قابل جستجو، تحلیل لاگ و بهطور فزایندهای، جستجوی شباهت مبتنی بر بردار نیاز دارند. راهاندازی یک کلاستر شما را مجبور به اتخاذ دهها تصمیم درهمتنیده میکند: سیاستهای رمزنگاری، جداسازی شبکه، نقشهای دسترسی به داده، تعیین اندازه نمونه (instance sizing)، تخصیص شارد (shard allocation) و برای بارهای کاری برداری، انتخاب موتور k-NN. اگر مرحلهای را از قلم بیندازید، با تخصیص بیش از حد منابع (over-provisioning) پرهزینه یا یک خط لوله جستجوی خراب مواجه خواهید شد.
این مهارت جدید نویدبخش یک عامل هوش مصنوعی است که دستورالعملهای زبان طبیعی را به مجموعهای دقیق از فراخوانیهای API و فایلهای پیکربندی مورد نیاز برای یک استقرار کامل OpenSearch ترجمه میکند.
این مهارت در واقع چیست
این یک چتبات نیست که بتوانید با آن گفتگو کنید. آن را به عنوان یک پایگاه دانش ساختاریافته در نظر بگیرید که یک عامل کدنویسی خودکار میتواند از آن پرسوجو کند. این بسته شامل موارد زیر است:
- فرمولهای تعیین اندازه (Sizing formulas) که حجم پرسوجوی مورد انتظار و اندازه دادهها را به توصیههای مشخص برای نوع نمونه (instance-type) و سطح ذخیرهسازی تبدیل میکند.
- منطق انتخاب موتور (Engine selection logic) که الگوهای بار کاری (فقط متن، ترکیبی، یا صرفاً برداری) را با موتور k-NN مناسب یا پیکربندی جستجوی ترکیبی مطابقت میدهد.
- چکلیستهای مهاجرت (Migration checklists) که طرحوارهها (schemas) را از Solr یا Elasticsearch به معادلهای OpenSearch نگاشت میکند.
- دستورالعملهای Query DSL که قطعهکدهای آمادهای از زبان اختصاصی دامنه (Domain Specific Language) مربوط به OpenSearch را برای الگوهای جستجوی رایج ارائه میدهد.
این مهارت حول پنج وظیفه اصلی میچرخد:
- مهاجرت (Migration) – تبدیل طرحوارههای موجود Solr/ES.
- تخصیص منابع (Provisioning) – محاسبه اندازه نمونهها، سطوح ذخیرهسازی و سیاستهای شبکه.
- جستجو (Search) – انتخاب موتورهای k-NN، تنظیمات جستجوی ترکیبی و تنظیم پارامترهای مرتبط بودن (relevance).
- تحلیل لاگ (Log analytics) – مدیریت پرسوجوهای زبان پردازش لولهای (PPL) و تعاریف خط لوله.
- تحلیل ردپا (Trace analytics) – پیکربندی جمعآوریکنندههای OpenTelemetry و خط لولههای Data Prepper.
نقاط قوت
در طول اجرای تست من، بزرگترین صرفهجویی در زمان، منطق توالیبندی سیاستها (policy sequencing logic) بود. این مهارت ترتیب صحیح را میداند و یک چکلیست مرحلهبهمرحله به من میدهد که زمان راهاندازی من را به طرز چشمگیری کاهش داد.
برای دامنههای مدیریتشده کلاسیک (classic managed domains)، توصیههای این مهارت در مورد ارتقای نمونهها و محاسبات شارد با پیکربندی واقعی کلاستر مطابقت دارد. این ابزار تعداد گرههای فعلی، میزان استفاده از ذخیرهسازی و تأخیر پرسوجو را میخواند و سپس به شما میگوید که آیا به شاردهای بیشتر، نمونههای بزرگتر یا سطح ذخیرهسازی متفاوتی نیاز دارید یا خیر. این مشاوره آگاه از متن (context-aware) معمولاً در چندین سند مختلف AWS پراکنده است.
این مهارت همچنین پرچمهای (flags) مخصوص NextGen مانند scale-to-zero را درک میکند، که به سرویس سرورلس دستور میدهد در زمانی که مجموعه (collection) بیکار است، منابع محاسباتی را آزاد کند. با علامتگذاری صحیح این مورد، ابزار هزینهها را بدون نیاز به تنظیمات دستی پایین نگه میدارد.
شکاف آشکار
مدیریت نگاشت برداری در NextGen Serverless توسط این مهارت هنوز در منطق Classic گیر کرده است. وقتی از عامل هوش مصنوعی خواستم یک مجموعه با قابلیت برداری را راهاندازی کند، موتور FAISS را پیشنهاد داد. در Classic Serverless شما میتوانید یک موتور k-NN انتخاب کنید، اما در NextGen این موضوع انتزاع شده است؛ شتابدهنده برداری بهطور خودکار مدیریت میشود و شما اصلاً نمیتوانید موتور را مشخص کنید. بنابراین، این پیشنهاد کاملاً اشتباه است.
نابرابری دوم که شدت کمتری داشت، مربوط به انتظارات تأخیر در نوشتن (write-latency) بود. دستیار هوش مصنوعی درباره تأخیرهای نوشتن ۳۰ تا ۶۰ ثانیهای هشدار داد، رقمی که مربوط به استقرارهای قدیمیتر Classic Serverless بود. در تست NextGen من، اسناد تقریباً در عرض دو ثانیه قابل جستجو شدند که باعث شد آن هشدار بیمصرف شود.
این لغزشها مهم هستند زیرا بسیاری از تیمها دقیقاً به دلیل مدل عملیاتی سادهشده، از NextGen استفاده میکنند. اگر دستیار هوش مصنوعی تنظیمات دوران Classic را روی یک کلاستر NextGen اعمال کند، میتواند باعث شکست در استقرار یا چرخههای عیبیابی بیمورد شود.
چه کسی باید (و نباید) از آن استفاده کند
اگر بهطور منظم کلاسترهای 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.