AWS ತನ್ನ Agent Toolkit ಗೆ amazon-opensearch-service skill ಅನ್ನು ಸೇರಿಸಿದೆ, ಮತ್ತು ನಾನು Amazon OpenSearch Serverless NextGen ನಲ್ಲಿ retrieval-augmented generation (RAG) backend ಅನ್ನು ನಿರ್ಮಿಸುವ ಮೂಲಕ ಇದನ್ನು ಪೂರ್ಣ-ಸ್ಟ್ಯಾಕ್ ಪರೀಕ್ಷೆಗೆ ಒಳಪಡಿಸಿದೆ. ಈ tool ಒಂದು production-grade OpenSearch cluster ಅನ್ನು ಸಿದ್ಧಪಡಿಸಲು ಬೇಕಾಗುವ ಸಮಯವನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಆದರೆ NextGen serverless ಪರಿಸರದಲ್ಲಿ vector search ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು AI agent ಗೆ ಕೇಳಿದಾಗ ಇದು ಎಡವುತ್ತದೆ.
ಈ skill ಏಕೆ ಮುಖ್ಯ
ಹುಡುಕಬಹುದಾದ ಪಠ್ಯ (searchable text), log analytics ಮತ್ತು ಹೆಚ್ಚುತ್ತಿರುವ vector-based similarity search ಅಗತ್ಯವಿರುವ ಉದ್ಯಮಗಳಿಗೆ OpenSearch ಈಗ ಡಿಫಾಲ್ಟ್ ಸ್ಟ್ಯಾಕ್ ಆಗಿದೆ. ಒಂದು cluster ಅನ್ನು ಸೆಟಪ್ ಮಾಡುವುದು ನೀವು ಡಜನ್ಗಟ್ಟಲೆ ಪರಸ್ಪರ ಸಂಬಂಧಿತ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವಂತೆ ಮಾಡುತ್ತದೆ: encryption policies, network isolation, data-access roles, instance sizing, shard allocation, ಮತ್ತು vector workloads ಗಾಗಿ k-NN engine ಆಯ್ಕೆ. ಒಂದು ಹಂತವನ್ನು ತಪ್ಪಿಸಿದರೆ, ನೀವು ದುಬಾರಿ over-provisioning ಅಥವಾ ಹಾಳಾದ search pipeline ಅನ್ನು ಎದುರಿಸಬೇಕಾಗುತ್ತದೆ.
ಹೊಸ skill ಒಂದು AI agent ಅನ್ನು ಭರವಸೆ ನೀಡುತ್ತದೆ, ಇದು ನೈಸರ್ಗಿಕ ಭಾಷೆಯ ಸೂಚನೆಗಳನ್ನು (natural-language instructions) ಸಂಪೂರ್ಣ OpenSearch deployment ಗೆ ಅಗತ್ಯವಿರುವ ನಿಖರವಾದ API calls ಮತ್ತು configuration files ಗಳ ಸರಣಿಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.
ಈ skill ವಾಸ್ತವವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ
ಇದು ನೀವು ಸಂಭಾಷಣೆ ನಡೆಸಬಹುದಾದ chatbot ಅಲ್ಲ. ಇದನ್ನು ಸ್ವಯಂಚಾಲಿತ coding agent ವೊಂದು ಪ್ರಶ್ನೆ ಕೇಳಬಹುದಾದ ಒಂದು structured knowledge base ಎಂದು ಭಾವಿಸಿ. ಈ package ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:
- Sizing formulas: ನಿರೀಕ್ಷಿತ query volume ಮತ್ತು data size ಅನ್ನು ನಿರ್ದಿಷ್ಟ instance-type ಮತ್ತು storage-tier ಶಿಫಾರಸುಗಳಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.
- Engine selection logic: workload patterns (text-only, hybrid, pure vector) ಅನ್ನು ಸೂಕ್ತವಾದ k-NN engine ಅಥವಾ hybrid search configuration ಗೆ ಹೊಂದಿಸುತ್ತದೆ.
- Migration checklists: Solr ಅಥವಾ Elasticsearch ಸ್ಕೀಮಾಗಳನ್ನು OpenSearch equivalents ಗೆ ಮ್ಯಾಪ್ ಮಾಡುತ್ತದೆ.
- Query DSL recipes: ಸಾಮಾನ್ಯ search patterns ಗಾಗಿ OpenSearch ನ Domain Specific Language ನ ಸಿದ್ಧಪಡಿಸಿದ snippets ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಈ skill ಐದು ಪ್ರಮುಖ ಕಾರ್ಯಗಳ ಸುತ್ತ ಸುತ್ತುತ್ತದೆ:
- Migration – ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ Solr/ES schemas ಗಳನ್ನು ಪರಿವರ್ತಿಸುವುದು.
- Provisioning – instance sizes, storage tiers, ಮತ್ತು network policies ಗಳನ್ನು ಲೆಕ್ಕಹಾಕುವುದು.
- Search – k-NN engines, hybrid search setups, ಮತ್ತು relevance parameters ಗಳನ್ನು ಟ್ಯೂನ್ ಮಾಡುವುದು.
- Log analytics – Piped Processing Language (PPL) queries ಮತ್ತು pipeline definitions ಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು.
- Trace analytics – OpenTelemetry collectors ಮತ್ತು Data Prepper pipelines ಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು.
ಇದು ಎಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ
ನನ್ನ ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ, ಅತಿ ಹೆಚ್ಚು ಸಮಯ ಉಳಿಸಿದ ಅಂಶವೆಂದರೆ policy sequencing logic. ಈ skill ಸರಿಯಾದ ಕ್ರಮವನ್ನು ತಿಳಿದಿದೆ ಮತ್ತು ನನಗೆ ಹಂತ-ಹಂತದ checklist ಅನ್ನು ನೀಡುತ್ತದೆ, ಇದು ನನ್ನ setup ಸಮಯವನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡಿತು.
ಕ್ಲಾಸಿಕ್ managed domains ಗಾಗಿ, instance upgrades ಮತ್ತು shard mathematics ಕುರಿತಾದ skill ನ ಶಿಫಾರಸುಗಳು ನೈಜ cluster configuration ಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತವೆ. ಇದು ಪ್ರಸ್ತುತ node count, storage usage, ಮತ್ತು query latency ಅನ್ನು ಓದುತ್ತದೆ, ನಂತರ ನಿಮಗೆ ಹೆಚ್ಚಿನ shards, ದೊಡ್ಡ instances, ಅಥವಾ ವಿಭಿನ್ನ storage tier ಅಗತ್ಯವಿದೆಯೇ ಎಂದು ತಿಳಿಸುತ್ತದೆ. ಅಂತಹ context-aware ಸಲಹೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಅನೇಕ AWS docs ಗಳಾದ್ಯಂತ ಚದುರಿಹೋಗಿರುತ್ತವೆ.
ಈ skill scale-to-zero ನಂತಹ NextGen-ನಿರ್ದಿಷ್ಟ flags ಗಳನ್ನು ಸಹ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ, ಇದು collection ನಿಷ್ಕ್ರಿಯe (idle) ಇದ್ದಾಗ compute resources ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು serverless service ಗೆ ಸೂಚಿಸುತ್ತದೆ. ಇದನ್ನು ಸರಿಯಾಗಿ ಗುರುತಿಸುವ ಮೂಲಕ, tool ಮಾನವ ಹಸ್ತಕ್ಷೇಪವಿಲ್ಲದೆ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಇಡುತ್ತದೆ.
ಕಂಡುಬರುತ್ತಿರುವ ದೊಡ್ಡ ಕೊರತೆ
NextGen Serverless ನಲ್ಲಿ vector mapping ಅನ್ನು ನಿರ್ವಹಿಸುವಲ್ಲಿ ಈ skill ಇನ್ನೂ Classic logic ನಲ್ಲಿ ಸಿಲುಕಿಕೊಂಡಿದೆ. vector-enabled collection ಅನ್ನು ಸೆಟಪ್ ಮಾಡಲು ನಾನು agent ಗೆ ಕೇಳಿದಾಗ, ಅದು FAISS engine ಅನ್ನು ಶಿಫಾರಸು ಮಾಡಿತು. Classic Serverless ನಲ್ಲಿ ನೀವು k-NN engine ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು, ಆದರೆ NextGen ಅದನ್ನು ಅಬ್ಸ್ಟ್ರಾಕ್ಟ್ ಮಾಡುತ್ತದೆ—vector acceleration ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನೀವು engine ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಆದ್ದರಿಂದ, ಈ ಶಿಫಾರಸು ಸಂಪೂರ್ಣವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ.
ಎರಡನೆಯದು, ಸ್ವಲ್ಪ ಕಡಿಮೆ ತೀವ್ರತೆಯ ಅಸಮತೋಲನವೆಂದರೆ write-latency ನಿರೀಕ್ಷೆಗಳು. ಅಸಿಸ್ಟೆಂಟ್ 30 ರಿಂದ 60 ಸೆಕೆಂಡುಗಳ write delays ಬಗ್ಗೆ ಎಚ್ಚರಿಸಿತು, ಈ ಅಂಕಿಅಂಶವು ಹಳೆಯ Classic Serverless deployments ಗೆ ಅನ್ವಯಿಸುತ್ತಿತ್ತು. ನನ್ನ NextGen ಪರೀಕ್ಷೆಯಲ್ಲಿ, ದಾಖಲೆಗಳು (documents) ಸುಮಾರು ಎರಡು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಹುಡುಕಲು ಸಾಧ್ಯವಾಗುವಂತಾದವು (searchable), ಇದರಿಂದಾಗಿ ಆ ಎಚ್ಚರಿಕೆ ಅಪ್ರಸ್ತುತವಾಯಿತು.
ಈ ತಪ್ಪುಗಳು ಮುಖ್ಯವಾಗಿವೆ ಏಕೆಂದರೆ ಅನೇಕ ತಂಡಗಳು ಅದರ ಸರಳೀಕೃತ ಕಾರ್ಯಾಚರಣಾ ಮಾದರಿಗಾಗಿ (simplified operational model) NextGen ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುತ್ತವೆ. AI assistant, Classic-ಕಾಲದ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು NextGen cluster ಮೇಲೆ ಹೇರಿದರೆ, ಅದು deployment ವೈಫಲ್ಯ ಅಥವಾ ಅನಗತ್ಯ debugging cycles ಗೆ ಕಾರಣವಾಗಬಹುದು.
ಇದನ್ನು ಯಾರು ಬಳಸಬೇಕು (ಮತ್ತು ಬಳಸಬಾರದು)
ನೀವು ನಿಯಮಿತವಾಗಿ OpenSearch clusters ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ—ಪೂರ್ಣ-ಪಠ್ಯ ಹುಡುಕಾಟ (full-text search), log aggregation, ಅಥವಾ hybrid workloads ಗಾಗಿ—ಈ skill ಒಂದು ಭದ್ರವಾದ ಸುರಕ್ಷತಾ ಜಾಲವಾಗಿದೆ. ಇದು ಈ ಕೆಳಗಿನ ಸಾಮಾನ್ಯ ಲೋಪದೋಷಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತದೆ:
- ಕಲೆಕ್ಷನ್ ರಚನೆಗೆ ಮೊದಲು ಎನ್ಕ್ರಿಪ್ಶನ್ ಪಾಲಿಸಿಗಳನ್ನು ಲಗತ್ತಿಸಲು ಮರೆಯುವುದು.
- NextGen ಕಲೆಕ್ಷನ್ ಅಗ್ಗ ಮತ್ತು ನಿರ್ವಹಿಸಲು ಸುಲಭವಾಗಿದ್ದರೂ, ತಪ್ಪಾಗಿ Classic ಕಲೆಕ್ಷನ್ ಅನ್ನು ಪ್ರೊವಿಷನ್ ಮಾಡುವುದು.
- ದೊಡ್ಡ ವೆಕ್ಟರ್ ವರ್ಕ್ಲೋಡ್ಗಳನ್ನು ತಡೆದುಕೊಳ್ಳಲಾಗದ ಇನ್ಸ್ಟೆನ್ಸ್ ಗಾತ್ರವನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು.
ಯಾವ ತಂಡಗಳ ಮುಖ್ಯ ಅಗತ್ಯವು ಶುದ್ಧ ವೆಕ್ಟರ್ ಸರ್ಚ್ ಆಗಿದೆಯೋ, ಅವರಿಗೆ ಈ ಕೌಶಲ್ಯವು ಹೆಚ್ಚಿನ ಪ್ರಯೋಜನವನ್ನು ನೀಡುವುದಿಲ್ಲ. Amazon ನ S3 Vectors ಸೇವೆಯು ಸರಳ RAG ಪೈಪ್ಲೈನ್ಗಳಿಗಾಗಿ ವೇಗವಾದ ಮತ್ತು ಅಗ್ಗದ ಮಾರ್ಗವನ್ನು ಒದಗಿಸುತ್ತದೆ ಮತ್ತು ಇದು ಈ ಕೌಶಲ್ಯವು ಸಹಾಯ ಮಾಡುವ ಸಂಕೀರ್ಣ ಪ್ರೊವಿಷನಿಂಗ್ ಹಂತಗಳನ್ನು ಬಯಸುವುದಿಲ್ಲ.
ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು
ಈ ಕೌಶಲ್ಯವು ಈಗಾಗಲೇ ಉಪಯುಕ್ತವಾಗಿದೆ, ಆದರೆ ಅದರ ಮುಂದಿನ ಆವೃತ್ತಿಗೆ ಎರಡು ಅಪ್ಡೇಟ್ಗಳ ಅಗತ್ಯವಿದೆ:
- NextGen-ಅರಿವಿರುವ ವೆಕ್ಟರ್ ಲಾಜಿಕ್ – ಇಂಜಿನ್ ಆಯ್ಕೆಯು ಅನಗತ್ಯ ಎಂಬುದನ್ನು ಅಸಿಸ್ಟೆಂಟ್ ಗುರುತಿಸಬೇಕು ಮತ್ತು ಬದಲಾಗಿ ಸರ್ವರ್ಲೆಸ್ ಮಾಡೆಲ್ನಲ್ಲಿ ವೆಕ್ಟರ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ವಾಸ್ತವವಾಗಿ ಪರಿಣಾಮ ಬೀರುವ ಪ್ಯಾರಾಮೀಟರ್ಗಳ ಮೂಲಕ (ಉದಾಹರಣೆಗೆ, ಡೈಮೆನ್ಶನ್ ಮಿತಿಗಳು, ಬ್ಯಾಚ್ ಗಾತ್ರ) ಬಳಕೆದಾರರಿಗೆ ಮಾರ್ಗದರ್ಶನ ನೀಡಬೇಕು.
- ಪ್ರಸ್ತುತ ಲೇಟೆನ್ಸಿ ಬೆಂಚ್ಮಾರ್ಕ್ಗಳು – ಬಳಕೆದಾರರು ವಾಸ್ತವಿಕ ನಿರೀಕ್ಷೆಗಳನ್ನು ಹೊಂದಲು, Classic ಮತ್ತು NextGen ಎರಡಕ್ಕೂ ಇತ್ತೀಚಿನ ರೈಟ್-ಲೇಟೆನ್ಸಿ ಅಂಕಿಅಂಶಗಳೊಂದಿಗೆ ಜ್ಞಾನ ಕೋಶವನ್ನು ನವೀಕರಿಸಬೇಕು.
ಈ ಮಧ್ಯೆ, ಈ ಕೌಶಲ್ಯವನ್ನು ಅನುಭವಿ OpenSearch ಎಂಜಿನಿಯರ್ಗೆ ಬದಲಿಯಾಗಿ ನೋಡಬೇಡಿ, ಬದಲಾಗಿ ಮಾರ್ಗದರ್ಶಿಯಾಗಿ ಪರಿಗಣಿಸಿ.
ಸಾರಾಂಶ
amazon-opensearch-service ಕೌಶಲ್ಯವು ಸಂಕೀರ್ಣ OpenSearch ಕಾನ್ಫಿಗರೇಶನ್ಗಳ ಕಲಿಕೆಯ ಹಂತವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ದುಬಾರಿ ಪಾಲಿಸಿ ತಪ್ಪುಗಳನ್ನು ತಪ್ಪಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಇದರ ನ್ಯೂನತೆಗಳು ಹೊಸದಾಗಿ ಬಂದ ಸರ್ವರ್ಲೆಸ್ ವೆಕ್ಟರ್ ವೈಶಿಷ್ಟ್ಯಗಳಿಗೆ ಸೀಮಿತವಾಗಿವೆ, ಅಂದರೆ ನೀವು ಯಾವುದೇ ವೆಕ್ಟರ್ ಸಂಬಂಧಿತ ಸಲಹೆಗಳನ್ನು ಇತ್ತೀಚಿನ NextGen ಡಾಕ್ಯುಮೆಂಟೇಶನ್ನೊಂದಿಗೆ ಮರುಪರಿಶೀಲಿಸಿದರೆ, ಇದು ಹೆಚ್ಚಿನ ವರ್ಕ್ಲೋಡ್ಗಳಿಗಾಗಿ ಮೌಲ್ಯಯುತ ಸಹಾಯಕನಾಗಿ ಉಳಿಯುತ್ತದೆ.