AWS telah menambah skill amazon-opensearch-service ke dalam Agent Toolkit miliknya, dan saya telah mengujinya melalui ujian full-stack dengan membina backend retrieval-augmented generation (RAG) pada Amazon OpenSearch Serverless NextGen. Alat ini memendekkan masa yang diperlukan untuk menyediakan kluster OpenSearch gred pengeluaran, tetapi ia masih tersandung apabila anda meminta ejen AI untuk mengkonfigurasi carian vektor dalam persekitaran serverless NextGen.

Mengapa skill ini penting

OpenSearch kini merupakan stack lalai untuk perusahaan yang memerlukan teks yang boleh dicari, analitik log, dan semakin meningkat, carian keserupaan berasaskan vektor. Menyediakan kluster memaksa anda membuat berpuluh-puluh keputusan yang saling berkait: polisi penyulitan, pengasingan rangkaian, peranan akses data, saiz instans, peruntukan shard, dan, untuk beban kerja vektor, pilihan enjin k-NN. Terlepas satu langkah dan anda akan berakhir dengan peruntukan berlebihan (over-provisioning) yang mahal atau saluran paip carian yang rosak.

Skill baharu ini menjanjikan ejen AI yang menterjemah arahan bahasa tabii kepada siri panggilan API dan fail konfigurasi yang tepat yang diperlukan untuk penyebaran OpenSearch yang lengkap.

Apakah sebenarnya skill ini

Ia bukan chatbot yang boleh anda ajak berbual. Anggap ia sebagai pangkalan pengetahuan berstruktur yang boleh dicapai oleh ejen pengekodan automatik. Pakej ini merangkumi:

  • Formula saiz yang menukarkan jangkaan volum pertanyaan dan saiz data kepada cadangan jenis instans dan tahap storan yang konkrit.
  • Logik pemilihan enjin yang memadankan corak beban kerja (hanya teks, hibrid, vektor tulen) dengan enjin k-NN atau konfigurasi carian hibrid yang sesuai.
  • Senarai semak migrasi yang memetakan skema daripada Solr atau Elasticsearch ke setara OpenSearch.
  • Resipi Query DSL yang menyediakan keratan kod siap guna bagi Domain Specific Language OpenSearch untuk corak carian biasa.

Skill ini berpusat pada lima tugas teras:

  1. Migrasi – menukar skema Solr/ES sedia ada.
  2. Provisioning – mengira saiz instans, tahap storan, dan polisi rangkaian.
  3. Carian – memilih enjin k-NN, tetapan carian hibrid, dan menala parameter relevansi.
  4. Analitik log – mengendalikan pertanyaan Piped Processing Language (PPL) dan definisi saluran paip.
  5. Analitik jejak (trace analytics) – mengkonfigurasi pengumpul OpenTelemetry dan saluran paip Data Prepper.

Di mana ia menyerlah

Semasa ujian saya, penjimatan masa terbesar adalah logik turutan polisi. Skill ini mengetahui urutan yang betul dan memberikan saya senarai semak langkah demi langkah, yang memendekkan masa penyediaan saya secara drastik.

Untuk domain terurus klasik, cadangan skill ini tentang naik taraf instans dan matematik shard sepadan dengan konfigurasi kluster sebenar. Ia membaca jumlah nod semasa, penggunaan storan, dan kependaman pertanyaan, kemudian memberitahu anda sama ada anda memerlukan lebih banyak shard, instans yang lebih besar, atau tahap storan yang berbeza. Nasihat berasaskan konteks tersebut biasanya tersebar di pelbagai dokumentasi AWS.

Skill ini juga memahami flag khusus NextGen seperti scale-to-zero, yang memberitahu perkhidmatan serverless untuk melepaskan sumber pengkomputeran apabila koleksi dalam keadaan pegun (idle). Dengan menandakan ini dengan betul, alat ini mengekalkan kos yang rendah tanpa pelarasan manual.

Jurang yang ketara

Pengendalian skill ini terhadap pemetaan vektor dalam NextGen Serverless masih terperangkap dalam logik Klasik. Apabila saya meminta ejen untuk menyediakan koleksi yang menyokong vektor, ia mencadangkan enjin FAISS. Dalam Classic Serverless, anda boleh memilih enjin k-NN, tetapi NextGen mengabstraksikan perkara itu—pecutan vektor diuruskan secara automatik dan anda tidak boleh menentukan enjin sama sekali. Oleh itu, cadangan tersebut gagal sepenuhnya.

Ketidaktepatan kedua yang kurang drastik melibatkan jangkaan kependaman penulisan (write-latency). Pembantu tersebut memberi amaran tentang kelewatan penulisan selama 30 hingga 60 saat, satu angka yang terpakai untuk penggunaan Classic Serverless yang lebih lama. Dalam ujian NextGen saya, dokumen boleh dicari dalam masa kira-kira dua saat, menjadikan amaran tersebut tidak lagi relevan.

Kesilapan ini penting kerana banyak pasukan menggunakan NextGen justru kerana model operasinya yang dipermudahkan. Jika pembantu AI mengenakan tetapan era Klasik ke atas kluster NextGen, ia boleh menyebabkan kegagalan penyebaran atau kitaran penyahpepijatan yang tidak perlu.

Siapa yang patut (dan tidak patut) menggunakannya

Jika anda kerap menyediakan kluster OpenSearch—sama ada untuk carian teks penuh, agregasi log, atau beban kerja hibrid—skill ini adalah jaring keselamatan yang kukuh. Ia mengesan kecuaian biasa seperti:

  • Terlupa melampirkan polisi penyulitan sebelum penciptaan koleksi.
  • Secara tidak sengaja menyediakan koleksi Classic sedangkan koleksi NextGen adalah lebih murah dan lebih mudah untuk diuruskan.
  • Memilih saiz instans yang tidak dapat menampung beban kerja vektor yang besar.

Bagi pasukan yang keperluan utamanya adalah carian vektor tulen, kemahiran ini menawarkan sedikit kelebihan. Perkhidmatan S3 Vectors Amazon menyediakan laluan yang lebih pantas dan lebih murah untuk saluran paip RAG yang ringkas, dan ia tidak memerlukan langkah penyediaan kompleks yang dibantu oleh kemahiran ini.

Apa yang perlu diperhatikan seterusnya

Kemahiran ini sudah pun berguna, tetapi iterasi seterusnya memerlukan dua kemas kini:

  1. Logik vektor peka-NextGen – pembantu tersebut mesti menyedari bahawa pemilihan enjin adalah tidak perlu dan sebaliknya membimbing pengguna melalui parameter yang sebenarnya mempengaruhi prestasi vektor dalam model tanpa pelayan (contohnya, had dimensi, saiz kelompok).
  2. Penanda aras kependaman semasa – pangkalan pengetahuan harus dikemas kini dengan angka kependaman-tulis terkini untuk kedua-dua Classic dan NextGen, supaya pengguna mendapat jangkaan yang realistik.

Sementara itu, anggap kemahiran ini sebagai panduan, bukan pengganti kepada jurutera OpenSearch yang berpengalaman.

Rumusan

Kemahiran amazon-opensearch-service mengurangkan keluk pembelajaran untuk konfigurasi OpenSearch yang kompleks dan membantu mengelakkan kesilapan polisi yang memakan kos. Kekurangannya terhad kepada ciri vektor tanpa pelayan yang terbaharu, yang bermaksud ia kekal sebagai pembantu yang berharga untuk kebanyakan beban kerja—dengan syarat anda menyemak semula sebarang nasihat berkaitan vektor dengan dokumentasi NextGen terkini.