AWS đã thêm amazon-opensearch-service skill vào Agent Toolkit của mình, và tôi đã tiến hành kiểm thử full-stack bằng cách xây dựng một backend tạo lập tăng cường truy xuất (RAG) trên Amazon OpenSearch Serverless NextGen. Công cụ này giúp cắt giảm đáng kể thời gian cần thiết để thiết lập một cụm OpenSearch đạt chuẩn production, nhưng nó vẫn gặp trục trặc khi bạn yêu cầu một AI agent cấu hình tìm kiếm vector trong môi trường serverless NextGen.

Tại sao skill này lại quan trọng

OpenSearch hiện là stack mặc định cho các doanh nghiệp cần tìm kiếm văn bản, phân tích log và ngày càng nhiều hơn là tìm kiếm tương đồng dựa trên vector. Việc thiết lập một cụm (cluster) buộc bạn phải đưa ra hàng tá quyết định liên kết chặt chẽ với nhau: các chính sách mã hóa, cô lập mạng, vai trò truy cập dữ liệu, kích thước instance, phân bổ shard, và đối với các khối lượng công việc vector, là việc lựa chọn engine k-NN. Chỉ cần thiếu một bước, bạn sẽ kết thúc với việc cấp phát dư thừa (over-provisioning) tốn kém hoặc một pipeline tìm kiếm bị lỗi.

Skill mới này hứa hẹn sẽ là một AI agent có khả năng chuyển đổi các hướng dẫn bằng ngôn ngữ tự nhiên thành chính xác chuỗi các lệnh gọi API và các tệp cấu hình cần thiết cho một triển khai OpenSearch hoàn chỉnh.

Skill này thực sự là gì

Đây không phải là một chatbot để bạn có thể trò chuyện. Hãy coi nó như một cơ sở kiến thức có cấu trúc mà một automated coding agent có thể truy vấn. Gói này bao gồm:

  • Các công thức tính toán kích thước (Sizing formulas) giúp chuyển đổi khối lượng truy vấn dự kiến và kích thước dữ liệu thành các đề xuất cụ thể về loại instance và tầng lưu trữ.
  • Logic lựa chọn engine giúp khớp các mẫu khối lượng công việc (chỉ văn bản, hybrid, hoặc thuần vector) với engine k-NN hoặc cấu hình tìm kiếm hybrid phù hợp.
  • Danh sách kiểm tra di chuyển (Migration checklists) giúp ánh xạ các schema từ Solr hoặc Elasticsearch sang các schema tương đương trong OpenSearch.
  • Các công thức Query DSL cung cấp các đoạn mã sẵn có của Ngôn ngữ đặc thù của miền (Domain Specific Language) của OpenSearch cho các mẫu tìm kiếm phổ biến.

Skill này xoay quanh năm tác vụ cốt lõi:

  1. Migration – chuyển đổi các schema Solr/ES hiện có.
  2. Provisioning – tính toán kích thước instance, các tầng lưu trữ và chính sách mạng.
  3. Search – lựa chọn engine k-NN, thiết lập tìm kiếm hybrid và tinh chỉnh các tham số về độ liên quan (relevance).
  4. Log analytics – xử lý các truy vấn Piped Processing Language (PPL) và các định nghĩa pipeline.
  5. Trace analytics – cấu hình các bộ thu thập OpenTelemetry và các pipeline Data Prepper.

Những điểm mạnh của nó

Trong quá trình chạy thử nghiệm, điểm tiết kiệm thời gian lớn nhất là logic trình tự chính sách (policy sequencing logic). Skill này biết thứ tự chính xác và cung cấp cho tôi một danh sách kiểm tra từng bước, giúp cắt giảm đáng kể thời gian thiết lập của tôi.

Đối với các managed domains kiểu Classic, các đề xuất của skill về nâng cấp instance và toán học về shard khớp với cấu hình thực tế của cụm. Nó đọc số lượng node hiện tại, mức sử dụng lưu trữ và độ trễ truy vấn, sau đó cho bạn biết liệu bạn có cần thêm shard, instance lớn hơn hay một tầng lưu trữ khác hay không. Những lời khuyên dựa trên ngữ cảnh đó thường nằm rải rác ở nhiều tài liệu AWS khác nhau.

Skill này cũng hiểu các flag dành riêng cho NextGen như scale-to-zero, giúp yêu cầu dịch vụ serverless giải phóng tài nguyên tính toán khi collection đang ở trạng thái rảnh (idle). Bằng cách gắn flag này một cách chính xác, công cụ giúp giữ chi phí ở mức thấp mà không cần điều chỉnh thủ công.

Lỗ hổng đáng kể

Cách xử lý việc ánh xạ vector trong NextGen Serverless của skill này vẫn đang bị kẹt trong logic của bản Classic. Khi tôi yêu cầu agent thiết lập một collection hỗ trợ vector, nó đã đề xuất engine FAISS. Trong bản Classic Serverless, bạn có thể chọn engine k-NN, nhưng ở NextGen, điều đó đã được trừu tượng hóa—việc tăng tốc vector được quản lý tự động và bạn không thể chỉ định engine. Do đó, đề xuất này hoàn toàn sai lệch.

Một điểm thiếu chính xác thứ hai, ít nghiêm trọng hơn, liên quan đến kỳ vọng về độ trễ ghi (write-latency). Trợ lý đã cảnh báo về độ trễ ghi từ 30 đến 60 giây, một con số vốn áp dụng cho các triển khai Classic Serverless cũ hơn. Trong bài kiểm tra NextGen của tôi, các tài liệu có thể tìm kiếm được chỉ trong khoảng hai giây, khiến cảnh báo trên trở nên lỗi thời.

Những sai sót này rất quan trọng vì nhiều đội ngũ áp dụng NextGen chính vì mô hình vận hành đơn giản hóa của nó. Nếu trợ lý AI đẩy các thiết lập từ thời Classic vào một cụm NextGen, nó có thể gây ra lỗi triển khai hoặc các chu kỳ gỡ lỗi không cần thiết.

Ai nên (và không nên) sử dụng nó

Nếu bạn thường xuyên khởi tạo các cụm OpenSearch—cho dù là để tìm kiếm toàn văn, tổng hợp log hay các khối lượng công việc hybrid—thì skill này là một mạng lưới an toàn vững chắc. Nó giúp phát hiện các sai sót phổ biến như:

  • Quên đính kèm các chính sách mã hóa trước khi tạo collection.
  • Vô tình khởi tạo một collection Classic trong khi một collection NextGen sẽ rẻ hơn và dễ quản lý hơn.
  • Chọn kích thước instance không thể đáp ứng các khối lượng công việc vector lớn.

Đối với các nhóm có nhu cầu chính là tìm kiếm vector thuần túy, kỹ năng này mang lại ít lợi thế. Dịch vụ S3 Vectors của Amazon cung cấp một lộ trình nhanh hơn, rẻ hơn cho các pipeline RAG đơn giản, và nó không yêu cầu các bước khởi tạo phức tạp mà kỹ năng này hỗ trợ.

Những điều cần lưu ý tiếp theo

Kỹ năng này đã hữu ích, nhưng phiên bản tiếp theo cần hai bản cập nhật:

  1. Logic vector nhận biết NextGen – trợ lý phải nhận ra rằng việc lựa chọn engine là không cần thiết, thay vào đó hãy hướng dẫn người dùng qua các tham số thực sự ảnh hưởng đến hiệu suất vector trong mô hình serverless (ví dụ: giới hạn số chiều, kích thước batch).
  2. Các điểm chuẩn về độ trễ hiện tại – cơ sở kiến thức nên được cập nhật với các số liệu về độ trễ ghi (write-latency) mới nhất cho cả Classic và NextGen, để người dùng có được những kỳ vọng thực tế.

Trong thời gian chờ đợi, hãy coi kỹ năng này như một người hướng dẫn, chứ không phải sự thay thế cho một kỹ sư OpenSearch dày dạn kinh nghiệm.

Bài học rút ra

Kỹ năng amazon-opensearch-service giúp rút ngắn lộ trình học tập cho các cấu hình OpenSearch phức tạp và giúp tránh các sai lầm về chính sách gây tốn kém. Những thiếu sót của nó chỉ giới hạn ở các tính năng vector serverless mới nhất, điều này có nghĩa là nó vẫn là một trợ lý giá trị cho hầu hết các khối lượng công việc—với điều kiện bạn phải kiểm tra kỹ lại bất kỳ lời khuyên nào liên quan đến vector dựa trên tài liệu NextGen mới nhất.