AWS הוסיפה את המיומנות amazon-opensearch-service ל-Agent Toolkit שלה, ואני העברתי אותה בדיקת full-stack בבניית backend של retrieval-augmented generation (RAG) על גבי Amazon OpenSearch Serverless NextGen. הכלי מקצץ משמעותית את הזמן הדרוש להקמת אשכול OpenSearch ברמת ייצור (production-grade), אך הוא עדיין נתקל בבעיות כשמבקשים מסוכן AI להגדיר חיפוש וקטורי (vector search) בסביבת ה-serverless של NextGen.

למה המיומנות הזו חשובה

OpenSearch הוא כעת ה-stack ברירת המחדל עבור ארגונים הזקוקים לטקסט הניתן לחיפוש, ניתוח לוגים (log analytics), ובתדירות הולכת וגוברת, גם חיפוש דמיון מבוסס וקטורים. הקמת אשכול מחייבת אתכם לקבל עשרות החלטות משולבות: מדיניות הצפנה, בידוד רשת, תפקידי גישה לנתונים, קביעת גודל מופעים (instance sizing), הקצאת shards, ועבור עומסי עבודה וקטוריים, בחירת מנוע k-NN. פספוס של שלב אחד עלול להוביל להקצאת יתר (over-provisioning) יקרה או לצינור חיפוש (search pipeline) תקול.

המיומנות החדשה מבטיחה סוכן AI שמתרגם הוראות בשפה טבעית לסדרה המדויקת של קריאות API וקבצי קונפיגורציה הנדרשים לפריסת OpenSearch מלאה.

מה המיומנות הזו היא באמת

זהו אינו צ'אטבוט שאפשר לנהל איתו שיחה. חשבו על זה כעל בסיס ידע מובנה שסוכן קוד אוטומטי יכול לשאול. החבילה כוללת:

  • נוסחאות sizing שהופכות נפח שאילתות וגודל נתונים צפויים להמלצות קונקרטיות על סוגי מופעים (instance-type) ושכבות אחסון (storage-tier).
  • לוגיקת בחירת מנוע המתאימה דפוסי עומסי עבודה (טקסט בלבד, היברידי, וקטורי טהור) למנוע ה-k-NN המתאים או להגדרת חיפוש היברידי.
  • רשימות תיוג (checklists) להגירה הממפות סכמות מ-Solr או Elasticsearch למקבילות שלהן ב-OpenSearch.
  • מתכוני Query DSL המספקים קטעי קוד מוכנים מתוך ה-Domain Specific Language של OpenSearch עבור דפוסי חיפוש נפוצים.

המיומנות סובבת סביב חמש משימות ליבה:

  1. Migration (הגירה) – המרת סכמות Solr/ES קיימות.
  2. Provisioning (הקצאת משאבים) – חישוב גדלי מופעים, שכבות אחסון ומדיניות רשת.
  3. Search (חיפוש) – בחירת מנועי k-NN, הגדרות חיפוש היברידי וכיוונון פרמטרי רלוונטיות.
  4. Log analytics (ניתוח לוגים) – טיפול בשאילתות Piped Processing Language (PPL) והגדרות pipeline.
  5. Trace analytics (ניתוח עקבות) – הגדרת collectors של OpenTelemetry ו-pipelines של Data Prepper.

איפה היא מצטיינת

במהלך בדיקת הריצה שלי, החוסך הגדול ביותר בזמן היה לוגיקת רצף המדיניות (policy sequencing logic). המיומנות יודעת מה הסדר הנכון ומספקת לי רשימת תיוג שלב אחר שלב, מה שקיצץ את זמן ההקמה שלי באופן דרמטי.

עבור דומיינים מנוהלים קלאסיים, ההמלצות של המיומנות על שדרוגי מופעים ומתמטיקת shards תואמות את קונפיגורציית האשכול בפועל. היא קוראת את מספר ה-nodes הנוכחי, השימוש באחסון וזמן השהיה (latency) של השאילתות, ואז אומרת לך אם אתה זקוק ליותר shards, מופעים גדולים יותר או שכבת אחסון שונה. הייעוץ המודע להקשר הזה בדרך כלל מפוזר במסמכי AWS מרובים.

המיומנות גם מבינה דגלים (flags) ספציפיים ל-NextGen כגון scale-to-zero, שאומר לשירות ה-serverless לשחרר משאבי מחשוב כאשר ה-collection אינו בשימוש. על ידי סימון נכון של אפשרות זו, הכלי שומר על עלויות נמוכות ללא צורך בכיוונונים ידניים.

הפער הבולט

הטיפול של המיומנות ב-vector mapping ב-NextGen Serverless עדיין תקוע בלוגיקה של Classic. כשביקשתי מהסוכן להקים collection עם יכולות וקטוריות, הוא הציע מנוע FAISS. ב-Classic Serverless ניתן לבחור מנוע k-NN, אך ב-NextGen הפעולה מופשטת (abstracted) – האצת וקטורים מנוהלת באופן אוטומטי ולא ניתן לציין את המנוע כלל. לכן, ההמלצה נכשלת לחלוטין.

חוסר דיוק שני, פחות דרמטי, נגע לציפיות לזמן השהיה בכתיבה (write-latency). העוזר הזהיר מפני עיכובי כתיבה של 30 עד 60 שניות, נתון שהיה תקף לפריסות Classic Serverless ישנות יותר. בבדיקת ה-NextGen שלי, מסמכים הפכו לניתנים לחיפוש תוך כשעתיים שניות בערך, מה שהפך את האזהרה למיושנת.

טעויות אלו חשובות מכיוון שצוותים רבים מאמצים את NextGen בדיוק בשל המודל התפעולי המפושט שלו. אם סוכן ה-AI דוחף הגדרות מתקופת ה-Classic על אשכול NextGen, זה עלול לגרום לכשלים בפריסה או למחזורי ניפוי שגיאות (debugging) מיותרים.

מי צריך (ולמי לא כדאי) להשתמש בה

אם אתם מקימים באופן קבוע אשכולות OpenSearch – בין אם עבור חיפוש טקסט מלא, איסוף לוגים (log aggregation) או עומסי עבודה היברידיים – המיומנות היא רשת ביטחון איתנה. היא תופסת השמטות נפוצות כגון:

  • 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:

  1. 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).
  2. 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.