AWS தனது Agent Toolkit-இல் amazon-opensearch-service திறனைச் சேர்த்துள்ளது. நான் Amazon OpenSearch Serverless NextGen-இல் ஒரு retrieval-augmented generation (RAG) பின்னணியை (backend) உருவாக்கி, இதை முழுமையான சோதனைக்கு உட்படுத்தினேன். ஒரு ப்ரொடக்ஷன்-கிரேடு (production-grade) OpenSearch கிளஸ்டரை உருவாக்குவதற்குத் தேவையான நேரத்தை இந்தத் கருவி வெகுவாகக் குறைக்கிறது, ஆனால் NextGen serverless சூழலில் வெக்டர் தேடலை (vector search) கட்டமைக்க ஒரு AI ஏஜென்ட்டிடம் கேட்கும்போது, அது இன்னும் தடுமாறுகிறது.
இந்தத் திறன் ஏன் முக்கியமானது
தேடக்கூடிய உரை (searchable text), லாக் பகுப்பாய்வு (log analytics) மற்றும் பெருகிவரும் வெக்டர் அடிப்படையிலான ஒற்றுமைத் தேடல் (vector-based similarity search) தேவைப்படும் நிறுவனங்களுக்கு OpenSearch இப்போது இயல்புநிலைத் தொகுப்பாக (default stack) உள்ளது. ஒரு கிளஸ்டரை அமைக்கும்போது, நீங்கள் பல ஒன்றோடொன்று இணைக்கப்பட்ட முடிவுகளை எடுக்க வேண்டியிருக்கும்: என்க்ரிப்ஷன் கொள்கைகள் (encryption policies), நெட்வொர்க் தனிமைப்படுத்தல் (network isolation), தரவு அணுகல் பாத்திரங்கள் (data-access roles), இன்ஸ்டன்ஸ் அளவு (instance sizing), ஷார்ட் ஒதுக்கீடு (shard allocation) மற்றும் வெக்டர் பணிச்சுமைகளுக்கு (vector workloads), k-NN இன்ஜின் தேர்வு. இதில் ஒரு படி தவறவிட்டாலும், அதிகப்படியான செலவு அல்லது முறிந்துபோன தேடல் வழிமுறைக்கு (broken search pipeline) நீங்கள் ஆளாக நேரிடும்.
இந்த புதிய திறன், இயற்கை மொழி வழிமுறைகளை (natural-language instructions), ஒரு முழுமையான OpenSearch பயன்பாட்டிற்குத் தேவையான துல்லியமான API அழைப்புகள் மற்றும் உள்ளமைவு கோப்புகளாக (configuration files) மாற்றும் ஒரு AI ஏஜென்ட்டை வழங்குகிறது.
இந்தத் திறன் உண்மையில் என்ன
இது நீங்கள் உரையாடக்கூடிய ஒரு சாட்பாட் (chatbot) அல்ல. ஒரு தானியங்கி கோடிங் ஏஜென்ட் (automated coding agent) வினவக்கூடிய ஒரு கட்டமைக்கப்பட்ட அறிவுத் தளம் (structured knowledge base) என்று இதைக் கருதலாம். இந்தத் தொகுப்பு பின்வருவனவற்றை உள்ளடக்கியது:
- Sizing formulas: எதிர்பார்க்கப்படும் வினவல் அளவு (query volume) மற்றும் தரவின் அளவை, குறிப்பிட்ட இன்ஸ்டன்ஸ் வகை மற்றும் ஸ்டோரேஜ்-டியர் (storage-tier) பரிந்துரைகளாக மாற்றும் சூத்திரங்கள்.
- Engine selection logic: பணிச்சுமை முறைகளை (workload patterns - text-only, hybrid, pure vector) பொருத்தமான k-NN இன்ஜின் அல்லது hybrid search உள்ளமைப்போடு இணைக்கும் தர்க்கம்.
- Migration checklists: Solr அல்லது Elasticsearch ஸ்கீமாக்களை (schemas) OpenSearch இணையான வடிவங்களாக மாற்ற உதவும் பட்டியல்கள்.
- Query DSL recipes: பொதுவான தேடல் முறைகளுக்கான OpenSearch-இன் Domain Specific Language-இன் தயார்நிலை துணுக்குகளை (snippets) வழங்கும் முறைகள்.
இந்தத் திறன் ஐந்து முக்கிய பணிகளைச் சுற்றி இயங்குகிறது:
- Migration – ஏற்கனவே உள்ள Solr/ES ஸ்கீமாக்களை மாற்றுதல்.
- Provisioning – இன்ஸ்டன்ஸ் அளவுகள், ஸ்டோரேஜ் டயர்கள் மற்றும் நெட்வொர்க் கொள்கைகளைக் கணக்கிடுதல்.
- Search – k-NN இன்ஜின்கள், hybrid search அமைப்புகள் மற்றும் பொருத்தமான அளவுருக்களை (relevance parameters) சரிசெய்தல்.
- Log analytics – Piped Processing Language (PPL) வினவல்கள் மற்றும் பைப்லைன் வரையறைகளைக் கையாளுதல்.
- Trace analytics – OpenTelemetry சேகரிப்பாளர்கள் (collectors) மற்றும் Data Prepper பைப்லைன்களை உள்ளமைத்தல்.
இது எங்கே சிறப்பாகச் செயல்படுகிறது
எனது சோதனை ஓட்டத்தின் போது, கொள்கை வரிசைப்படுத்தும் தர்க்கம் (policy sequencing logic) நேரத்தை வெகுவாகச் சேமித்தது. இந்தத் திறன் சரியான வரிசையை அறிந்து எனக்குப் படிபடியாக ஒரு சரிபார்ப்புப் பட்டியலை வழங்கியது, இது எனது அமை setups நேரத்தை வியக்கத்தக்க வகையில் குறைத்தது.
கிளாசிக் மேனேஜ்டு டொமைன்களுக்கு (classic managed domains), இன்ஸ்டன்ஸ் மேம்படுத்தல்கள் மற்றும் ஷார்ட் கணிதங்கள் (shard mathematics) குறித்த இந்தத் திறனின் பரிந்துரைகள், உண்மையான கிளஸ்டர் உள்ளமைவுடன் ஒத்துப்போகின்றன. இது தற்போதைய நோட் எண்ணிக்கை (node count), ஸ்டோரேஜ் பயன்பாடு மற்றும் வினவல் தாமதத்தை (query latency) படித்து, உங்களுக்கு கூடுதல் ஷார்ட்கள் தேவையா, பெரிய இன்ஸ்டன்ஸ்கள் தேவையா அல்லது வேறு ஸ்டோரேஜ் டயர் தேவையா என்று கூறுகிறது. இத்தகைய சூழலுக்குத் தகுந்த அறிவுரைகள் (context-aware advice) வழக்கமாக பல AWS ஆவணங்களில் சிதறிக்கிடக்கும்.
மேலும், இந்தத் திறன் scale-to-zero போன்ற NextGen-குறிப்பிட்ட ஃபிளாக்குகளையும் (flags) புரிந்துகொள்கிறது, இது சேகரிப்பு (collection) பயன்பாட்டில் இல்லாதபோது கணினி வளங்களை (compute resources) விடுவிக்குமாறு serverless சேவையைத் தெரிவிக்கும். இதைச் சரியாகக் குறிப்பிடுவதன் மூலம், இந்தத் கருவி கைமுறையாக மாற்றங்கள் செய்யாமலேயே செலவைக் குறைவாக வைத்திருக்க உதவுகிறது.
வெளிப்படையான குறைபாடு
NextGen Serverless-இல் வெக்டர் மேப்பிங் (vector mapping) செய்வதில் இந்தத் திறனின் கையாளுதல் இன்னும் கிளாசிக் தர்க்கத்திலேயே (Classic logic) தங்கியுள்ளது. ஒரு வெக்டர் வசதி கொண்ட சேகரிப்பை அமைக்க ஏஜென்ட்டிடம் கேட்டபோது, அது FAISS இன்ஜினைப் பரிந்துரைத்தது. கிளாசிக் Serverless-இல் நீங்கள் ஒரு k-NN இன்ஜினைத் தேர்ந்தெடுக்கலாம், ஆனால் NextGen அதைத் தானாகவே கையாள்கிறது—வெக்டர் முடுக்கம் (vector acceleration) தானாகவே நிர்வகிக்கப்படுகிறது மற்றும் நீங்கள் இன்ஜினைத் தனிப்பயனாக்க முடியாது. எனவே, அந்தப் பரிந்துரை முற்றிலும் தோல்வியடைகிறது.
இரண்டாவது, சற்று குறைவான துல்லியமற்ற தன்மை எழுத்துத் தாமத எதிர்பார்ப்புகளில் (write-latency expectations) இருந்தது. உதவியாளர் 30 முதல் 60 வினாடிகள் வரை எழுத்துத் தாமதம் ஏற்படும் என்று எச்சரித்தார், ஆனால் இந்த அளவு பழைய கிளாசிக் Serverless பயன்பாடுகளுக்கு மட்டுமே பொருந்தும். எனது NextGen சோதனையில், ஆவணங்கள் தோராயமாக இரண்டு வினாடிகளில் தேடக்கூடிய நிலைக்கு வந்துவிட்டன, இதனால் அந்த எச்சரிக்கை தேவையற்றதாகிவிட்டது.
இந்தத் தவறுகள் முக்கியமானவை, ஏனெனில் பல குழுக்கள் அதன் எளிமையாக்கப்பட்ட செயல்பாட்டு மாதிரிக்காகவே (simplified operational model) NextGen-ஐத் தேர்ந்தெடுக்கின்றன. AI உதவியாளர் கிளாசிக் காலத்து அமைப்புகளை ஒரு NextGen கிளஸ்டரில் திணிக்க முயன்றால், அது பயன்பாட்டுத் தோல்விகளுக்கோ அல்லது தேவையற்ற பிழைத்திருத்த சுழற்சிகளுக்கோ (debugging cycles) வழிவகுக்கும்.
யார் இதைப் பயன்படுத்த வேண்டும் (மற்றும் பயன்படுத்தக் கூடாது)
நீங்கள் முழு உரைத் தேடல் (full-text search), லாக் அக்ரிகேஷன் (log aggregation) அல்லது hybrid workloads ஆகியவற்றிற்காகத் தொடர்ந்து OpenSearch கிளஸ்டர்களை உருவாக்குகிறீர்கள் என்றால், இந்தத் திறன் ஒரு சிறந்த பாதுகாப்பு வலையாகும். இது பின்வருவன போன்ற பொதுவான கவனக்குறைவுகளைக் கண்டறிய உதவுகிறது:
- Collection உருவாக்குவதற்கு முன் encryption policies-களை இணைக்க மறப்பது.
- NextGen வசதி மலிவானதாகவும் மற்றும் நிர்வகிக்க எளிதாகவும் இருக்கும்போது, தவறுதலாக ஒரு Classic collection-ஐ provision செய்வது.
- பெரிய vector workloads-களைத் தாங்க முடியாத ஒரு instance size-ஐத் தேர்ந்தெடுப்பது.
Pure vector search மட்டுமே முதன்மையானத் தேவையாக இருக்கும் குழுக்களுக்கு, இந்தத் திறன் பெரிய அளவில் பயன் தராது. Amazon-இன் S3 Vectors சேவை எளிமையான RAG pipelines-களுக்கு வேகமான மற்றும் மலிவான வழியை வழங்குகிறது, மேலும் இந்தத் திறன் உதவும் சிக்கலான provisioning நிலைகள் இதற்குத் தேவையில்லை.
அடுத்து கவனிக்க வேண்டியவை
இந்தத் திறன் ஏற்கனவே பயனுள்ளதாக உள்ளது, ஆனால் அதன் அடுத்த பதிப்பிற்கு (iteration) இரண்டு மேம்படுத்தல்கள் தேவைப்படுகின்றன:
- NextGen-aware vector logic – engine selection தேவையில்லை என்பதை உதவியாளர் (assistant) உணர வேண்டும்; அதற்குப் பதிலாக, serverless மாடலில் vector செயல்திறனைப் பாதிக்கும் அளவுருக்கள் (parameters) மூலம் பயனரை வழிநடத்த வேண்டும் (எ.கா., dimension limits, batch size).
- Current latency benchmarks – பயனர்கள் யதார்த்தமான எதிர்பார்ப்புகளைப் பெறுவதற்கு, Classic மற்றும் NextGen ஆகிய இரண்டிற்கும் சமீபத்திய write-latency புள்ளிவிவரங்களுடன் அறிவுத் தளம் (knowledge base) புதுப்பிக்கப்பட வேண்டும்.
இதற்கிடையில், இந்தத் திறனை ஒரு அனுபவம் வாய்ந்த OpenSearch பொறியாளருக்குப் பதிலாகக் கருதாமல், ஒரு வழிகாட்டியாகவே (guide) கருதுங்கள்.
சுருக்கம்
amazon-opensearch-service திறன், சிக்கலான OpenSearch கட்டமைப்புகளுக்கான கற்றல் சுமையைக் குறைக்கிறது மற்றும் விலை உயர்ந்த கொள்கை பிழைகளைத் தவிர்க்க உதவுகிறது. இதன் குறைபாடுகள் புதிய serverless vector அம்சங்களுடன் மட்டுமே தொடர்புடையவை, எனவே நீங்கள் சமீபத்திய NextGen ஆவணங்களுடன் (documentation) எந்தவொரு vector தொடர்பான ஆலோசனையையும் சரிபார்த்தால், பெரும்பாலான workloads-களுக்கு இது ஒரு மதிப்புமிக்க உதவியாளராகத் தொடரும்.