AWS એ તેના Agent Toolkit માં amazon-opensearch-service skill ઉમેરી છે, અને મેં Amazon OpenSearch Serverless NextGen પર retrieval-augmented generation (RAG) backend બનાવતા તેને ફૂલ-સ્ટેક ટેસ્ટ દ્વારા પરખ્યું છે. આ ટૂલ પ્રોડક્શન-ગ્રેડ OpenSearch ક્લસ્ટર તૈયાર કરવા માટે જરૂરી સમયમાં મોટો ઘટાડો કરે છે, પરંતુ જ્યારે તમે AI એજન્ટને NextGen serverless એન્વાયરમેન્ટમાં vector search કોન્ફિગર કરવા માટે કહો છો, ત્યારે તે હજુ પણ મુશ્કેલી અનુભવે છે.

આ skill શા માટે મહત્વની છે

OpenSearch હવે એવા એન્ટરપ્રાઇઝ માટે ડિફોલ્ટ સ્ટેક છે જેને સર્ચેબલ ટેક્સ્ટ, લોગ એનાલિટિક્સ અને વધતા જતા vector-based similarity searchની જરૂર છે. ક્લસ્ટર સેટઅપ કરવા માટે તમારે ડઝનબંધ પરસ્પર જોડાયેલા નિર્ણયો લેવા પડે છે: એન્ક્રિપ્શન પોલિસી, નેટવર્ક આઇસોલેશન, ડેટા-એક્સેસ રોલ્સ, ઇન્સ્ટન્સ સાઇઝિંગ, શાર્ડ એલોકેશન અને vector workloads માટે k-NN એન્જિનની પસંદગી. જો તમે એક પણ સ્ટેપ ચૂકી જાઓ, તો તમે મોંઘા over-provisioning અથવા બ્રોકન સર્ચ પાઇપલાઇન સાથે અંતે આવી શકો છો.

આ નવી skill એક એવા AI એજન્ટનું વચન આપે છે જે કુદરતી ભાષાના (natural-language) સૂચનોને સંપૂર્ણ OpenSearch ડિપ્લોયમેન્ટ માટે જરૂરી API કોલ્સ અને કોન્ફિગરેશન ફાઇલોની ચોક્કસ શ્રેણીમાં રૂપાંતરિત કરે છે.

આ skill ખરેખર શું છે

તે કોઈ ચેટબોટ નથી જેની સાથે તમે વાતચીત કરી શકો. તેને એક સ્ટ્રક્ચર્ડ નોલેજ બેઝ તરીકે વિચારો જેને ઓટોમેટેડ કોડિંગ એજન્ટ ક્વેરી કરી શકે છે. આ પેકેજમાં નીચેની બાબતોનો સમાવેશ થાય છે:

  • Sizing formulas જે અપેક્ષિત ક્વેરી વોલ્યુમ અને ડેટા સાઇઝને ચોક્કસ ઇન્સ્ટન્સ-ટાઇપ અને સ્ટોરેજ-ટિયર ભલામણોમાં ફેરવે છે.
  • Engine selection logic જે વર્કલોડ પેટર્ન (text-only, hybrid, pure vector) ને યોગ્ય k-NN એન્જિન અથવા હાઇબ્રિડ સર્ચ કોન્ફિગરેશન સાથે મેચ કરે છે.
  • Migration checklists જે Solr અથવા Elasticsearch ના સ્કીમાને OpenSearch ના સમકક્ષમાં મેપ કરે છે.
  • Query DSL recipes જે સામાન્ય સર્ચ પેટર્ન માટે OpenSearch ની Domain Specific Language ના તૈયાર સ્નિપેટ્સ પૂરા પાડે છે.

આ skill પાંચ મુખ્ય કાર્યોની આસપાસ ફરે છે:

  1. Migration – હાલના Solr/ES સ્કીમાનું રૂપાંતર કરવું.
  2. Provisioning – ઇન્સ્ટન્સ સાઇઝ, સ્ટોરેજ ટિયર્સ અને નેટવર્ક પોલિસીની ગણતરી કરવી.
  3. Search – k-NN એન્જિન, હાઇબ્રિડ સર્ચ સેટઅપ પસંદ કરવા અને relevance parameters ટ્યુન કરવા.
  4. Log analytics – Piped Processing Language (PPL) ક્વેરીઝ અને પાઇપલાઇન ડેફિનેશન હેન્ડલ કરવું.
  5. Trace analytics – OpenTelemetry કલેક્ટર્સ અને Data Prepper પાઇપલાઇન્સ કોન્ફિગર કરવા.

તે ક્યાં શ્રેષ્ઠ કામ કરે છે

મારા ટેસ્ટ રન દરમિયાન, સૌથી વધુ સમય બચાવનાર બાબત પોલિસી સિક્વન્સિંગ લોજિક હતું. આ skill સાચો ક્રમ જાણે છે અને મને સ્ટેપ-બાય-સ્ટેપ ચેકલિસ્ટ આપે છે, જેનાથી મારો સેટઅપ સમય નોંધપાત્ર રીતે ઘટી ગયો.

ક્લાસિક મેનેજ્ડ ડોમેન્સ માટે, ઇન્સ્ટન્સ અપગ્રેડ અને શાર્ડ મેથેમેટિક્સ પર skill ની ભલામણો વાસ્તવિક ક્લસ્ટર કોન્ફિગરેશન સાથે મેળ ખાય છે. તે વર્તમાન નોડ કાઉન્ટ, સ્ટોરેજ વપરાશ અને ક્વેરી લેટન્સી વાંચે છે, અને પછી તમને જણાવે છે કે તમારે વધુ શાર્ડ્સ, મોટા ઇન્સ્ટન્સ અથવા અલગ સ્ટોરેજ ટિયરની જરૂર છે કે નહીં. આ પ્રકારની context-aware સલાહ સામાન્ય રીતે અનેક AWS ડોક્યુમેન્ટ્સમાં વિખરાયેલી હોય છે.

આ skill scale-to-zero જેવા NextGen-વિશિષ્ટ ફ્લેગ્સને પણ સમજે છે, જે સર્વરલેસ સર્વિસને જણાવે છે કે જ્યારે કલેક્શન નિષ્ક્રિય (idle) હોય ત્યારે કમ્પ્યુટ રિસોર્સિસ રિલીઝ કરી દેવા. આને યોગ્ય રીતે ફ્લેગ કરીને, આ ટૂલ મેન્યુઅલ ફેરફારો વગર ખર્ચ ઓછો રાખે છે.

મોટી ખામી

NextGen Serverless માં vector mapping નું skill દ્વારા કરવામાં આવતું હેન્ડલિંગ હજુ પણ Classic લોજિક પર અટકેલું છે. જ્યારે મેં એજન્ટને vector-enabled કલેક્શન સેટઅપ કરવા કહ્યું, ત્યારે તેણે FAISS એન્જિન સૂચવ્યું. Classic Serverless માં તમે k-NN એન્જિન પસંદ કરી શકો છો, પરંતુ NextGen તેને એબ્સ્ટ્રેક્ટ (abstract) કરે છે—vector acceleration આપમેળે મેનેજ કરવામાં આવે છે અને તમે એન્જિનને બિલકુલ સ્પેશિફાય કરી શકતા નથી. તેથી, આ ભલામણ સંપૂર્ણપણે નિષ્ફળ જાય છે.

બીજી, ઓછી ગંભીર અચોકસાઈ રાઈટ-લેટન્સી (write-latency) અપેક્ષાઓ સાથે જોડાયેલી હતી. આસિસ્ટન્ટે 30 થી 60 સેકન્ડના રાઈટ ડિલે (write delays) વિશે ચેતવણી આપી હતી, જે આંકડો જૂના Classic Serverless ડિપ્લોયમેન્ટ્સ માટે લાગુ પડતો હતો. મારા NextGen ટેસ્ટમાં, ડોક્યુમેન્ટ્સ લગભગ બે સેકન્ડમાં સર્ચેબલ થઈ ગયા હતા, જેનાથી આ ચેતવણી બિનજરૂરી બની ગઈ.

આ ભૂલો મહત્વની છે કારણ કે ઘણી ટીમો તેના સરળ ઓપરેશનલ મોડલ માટે જ NextGen અપનાવે છે. જો AI આસિસ્ટન્ટ NextGen ક્લસ્ટર પર Classic-યુગના સેટિંગ્સ લાગુ કરે, તો તેનાથી ડિપ્લોયમેન્ટ નિષ્ફળ જઈ શકે છે અથવા બિનજરૂરી ડીબગિંગ સાયકલ શરૂ થઈ શકે છે.

કોણે (અને કોણે નહીં) તેનો ઉપયોગ કરવો જોઈએ

જો તમે નિયમિતપણે OpenSearch ક્લસ્ટર્સ સેટઅપ કરો છો—પછી તે ફૂલ-ટેક્સ્ટ સર્ચ, લોગ એગ્રીગેશન અથવા હાઇબ્રિડ વર્કલોડ માટે હોય—તો આ skill એક મજબૂત સેફ્ટી નેટ છે. તે નીચે મુજબની સામાન્ય ભૂલોને પકડી લે છે:

  • કલેક્શન બનાવતા પહેલા એન્ક્રિપ્શન પોલિસીઓ જોડવાનું ભૂલી જવું.
  • ભૂલથી Classic કલેક્શન પ્રોવિઝન કરવું જ્યારે NextGen કલેક્શન સસ્તું અને મેનેજ કરવામાં સરળ હોત.
  • એવું ઇન્સ્ટન્સ સાઇઝ પસંદ કરવું જે મોટા વેક્ટર વર્કલોડ્સને સપોર્ટ ન કરી શકે.

જે ટીમોની પ્રાથમિક જરૂરિયાત pure vector search છે, તેમના માટે આ સ્કીલ બહુ ઓછો ફાયદો આપે છે. Amazon ની S3 Vectors સર્વિસ સરળ RAG પાઇપલાઇન્સ માટે ઝડપી અને સસ્તો માર્ગ પૂરો પાડે છે, અને તેમાં તે જટિલ પ્રોવિઝનિંગ સ્ટેપ્સની જરૂર પડતી નથી જેમાં આ સ્કીલ મદદ કરે છે.

આગળ શું ધ્યાન રાખવું

આ સ્કીલ પહેલેથી જ ઉપયોગી છે, પરંતુ તેના આગામી ઇટરેશન માટે બે અપડેટ્સની જરૂર છે:

  1. NextGen-aware vector logic – આસિસ્ટન્ટે એ ઓળખવું જોઈએ કે એન્જિન પસંદગી બિનજરૂરી છે અને તેના બદલે યુઝરને એવા પેરામીટર્સ દ્વારા માર્ગદર્શન આપવું જોઈએ જે સર્વરલેસ મોડેલમાં વેક્ટર પરફોર્મન્સને ખરેખર અસર કરે છે (દા.ત., dimension limits, batch size).
  2. Current latency benchmarks – નોલેજ બેઝને Classic અને NextGen બંને માટે લેટેસ્ટ write-latency આંકડાઓ સાથે રિફ્રેશ કરવું જોઈએ, જેથી યુઝર્સને વાસ્તવિક અપેક્ષાઓ મળે.

તે દરમિયાન, આ સ્કીલને અનુભવી OpenSearch એન્જિનિયરના રિપ્લેસમેન્ટ તરીકે નહીં, પણ એક માર્ગદર્શક (guide) તરીકે ગણો.

Takeaway

amazon-opensearch-service સ્કીલ જટિલ OpenSearch કોન્ફિગરેશન માટેના લર્નિંગ કર્વને ઘટાડે છે અને ખર્ચાળ પોલિસીની ભૂલો ટાળવામાં મદદ કરે છે. તેની મર્યાદાઓ નવીનતમ સર્વરલેસ વેક્ટર ફીચર્સ પૂરતી મર્યાદિત છે, જેનો અર્થ છે કે તે મોટાભાગના વર્કલોડ્સ માટે એક મૂલ્યવાન આસિસ્ટન્ટ બની રહે છે—જો તમે લેટેસ્ટ NextGen ડોક્યુમેન્ટેશન સાથે કોઈપણ વેક્ટર સંબંધિત સલાહની ફરીથી તપાસ કરો.