Tác giả: Jon Handler 

Ngày đăng: 03 tháng 3 2025 

Danh mục: Amazon OpenSearch Service, Generative AI

Năm 2023, chúng tôi đã viết blog về khả năng cơ sở dữ liệu vector của OpenSearch Service. Kể từ đó, OpenSearch và Amazon OpenSearch Service đã phát triển để mang lại hiệu suất tốt hơn, chi phí thấp hơn và mang lại sự đánh đổi tốt hơn giữa các yếu tố. Chúng tôi đã cải thiện các phương pháp tìm kiếm kết hợp từ vựng (lexical) và ngữ nghĩa (semantic) của OpenSearch Service, sử dụng cả vector dày đặc (dense vectors) và vector thưa (sparse vectors). Chúng tôi đã đơn giản hóa việc kết nối và quản lý large language models (LLMs) được lưu trữ trong các môi trường khác. Chúng tôi đã ra mắt tính năng phân mảnh gốc (native chunking) và tinh gọn hóa việc tìm kiếm các tài liệu đã được phân mảnh.

Trong khi năm 2023 chứng kiến sự bùng nổ của LLMs cho generative AI và vector embeddings được tạo bởi LLM cho tìm kiếm ngữ nghĩa, năm 2024 là năm của sự củng cố và hiện thực hóa các ý tưởng. Các ứng dụng dựa trên Truy xuất Tăng cường Tạo sinh (Retrieval Augmented Generation – RAG) bắt đầu chuyển từ giai đoạn chứng minh khái niệm (proof of concept – POC) sang môi trường production (vận hành chính thức), với tất cả các mối lo ngại đi kèm như hiện tượng ảo giác (hallucinations), nội dung không phù hợp và chi phí. Các nhà phát triển ứng dụng tìm kiếm bắt đầu chuyển khối lượng công việc tìm kiếm ngữ nghĩa của họ sang production, tìm kiếm độ phù hợp được cải thiện để thúc đẩy doanh nghiệp của họ.

Khi bước sang năm 2025, hỗ trợ OpenSearch 2.17 của OpenSearch Service mang những cải tiến này đến dịch vụ. Trong bài viết này, chúng tôi sẽ xem xét các đổi mới năm 2024 với cách bạn có thể áp dụng các tính năng mới để giảm chi phí, giảm độ trễ và cải thiện độ chính xác của kết quả tìm kiếm và văn bản được tạo ra.

Sử dụng OpenSearch Service như một cơ sở dữ liệu vector 

Amazon OpenSearch Service như một cơ sở dữ liệu vector cung cấp cho bạn các khả năng cốt lõi để lưu trữ vector embeddings từ LLMs và sử dụng thông tin vector và từ vựng để truy xuất tài liệu dựa trên sự tương đồng từ vựng của chúng, cũng như độ gần trong không gian vector. OpenSearch Service tiếp tục hỗ trợ ba engine vector: Facebook AI Similarity Search (FAISS), Non-Metric Space Library (NMSLIB), và Lucene. Dịch vụ hỗ trợ cả khớp lân cận gần nhất chính xác (exact nearest-neighbor matching) và khớp lân cận gần nhất xấp xỉ (approximate nearest-neighbor matching – ANN). Đối với ANN, dịch vụ cung cấp cả Hierarchical Navigable Small World (HNSW) và Inverted File (IVF) cho việc lưu trữ và truy xuất. Dịch vụ còn hỗ trợ nhiều thước đo khoảng cách (distance metrics), bao gồm Cartesian distance, cosine similarity, Manhattan distance, và nhiều hơn nữa.

Chuyển đổi sang tìm kiếm hybrid

Nhiệm vụ của công cụ tìm kiếm là nhận đầu vào ý định của người tìm kiếm, được nắm bắt qua các từ, vị trí, phạm vi số, ngày tháng (và với multimodal search, rich media như hình ảnh, video và âm thanh) và trả về một tập kết quả từ bộ sưu tập tài liệu đã được lập chỉ mục đáp ứng nhu cầu của người tìm kiếm. Đối với một số truy vấn, như “phụ kiện ống nước CPVC”, các từ trong mô tả sản phẩm và từ người tìm kiếm sử dụng đã đủ để mang lại kết quả chính xác, sử dụng chỉ số tương đồng Term Frequency-Inverse Document Frequency (TF/IDF) tiêu chuẩn. Những truy vấn này được đặc trưng bởi mức độ cụ thể cao trong ý định của người tìm kiếm, phù hợp với các từ họ sử dụng cũng như tên và mô tả sản phẩm. Khi ý định của người tìm kiếm trừu tượng hơn, như “một nơi ấm cúng để cuộn mình bên lò sưởi”, các từ ít có khả năng cung cấp kết quả phù hợp.

Để phục vụ người dùng tốt nhất trong phạm vi các truy vấn, các nhà phát triển đã bắt đầu áp dụng phương pháp hybrid search, sử dụng cả truy xuất từ vựng và ngữ nghĩa với xếp hạng kết hợp. OpenSearch cung cấp hybrid search có thể kết hợp các truy vấn từ vựng, truy vấn k-Nearest Neighbor (k-NN) và truy vấn neural sử dụng plugin neural search của OpenSearch. Nhà phát triển có thể triển khai ba cấp độ hybrid search – lọc từ vựng cùng với vectors, kết hợp điểm từ vựng và vector, và khả năng chuẩn hóa và kết hợp điểm số được tích hợp sẵn (out-of-the-box).

Năm 2024, OpenSearch đã cải thiện khả năng hybrid search với logic tính điểm có điều kiện, cải tiến cấu trúc, loại bỏ các tính toán lặp lại và không cần thiết, và tối ưu hóa cấu trúc dữ liệu, mang lại cải thiện độ trễ gấp 4 lần. OpenSearch cũng đã thêm hỗ trợ song song hóa xử lý truy vấn cho hybrid search, có thể cải thiện độ trễ lên đến 25%. OpenSearch đã phát hành tính năng lọc sau (post-filtering) cho các truy vấn hybrid, giúp tinh chỉnh thêm kết quả tìm kiếm. Năm 2024 cũng chứng kiến việc OpenSearch Service phát hành hỗ trợ tổng hợp (aggregations) cho các truy vấn hybrid.

Sparse vector search là một cách khác để kết hợp thông tin từ vựng và ngữ nghĩa. Sparse vectors giảm các thuật ngữ corpus xuống khoảng 32.000 thuật ngữ, giống hoặc gần với nguồn. Sparse vectors sử dụng trọng số chủ yếu là 0 hoặc gần 0 để cung cấp một tập token có trọng số nắm bắt ý nghĩa của các thuật ngữ. Các truy vấn được chuyển đổi thành tập token đã giảm, với khái quát hóa được cung cấp bởi sparse models. Năm 2024, OpenSearch đã giới thiệu xử lý hai giai đoạn cho sparse vectors giúp cải thiện độ trễ cho xử lý truy vấn.

Tập trung vào độ chính xác

Một trong những mối quan tâm chính của các nhà phát triển khi đưa workload vào môi trường production là cân bằng giữa độ chính xác của việc truy xuất (và độ chính xác của văn bản được tạo ra) với chi phí và độ trễ của giải pháp. Trong năm 2024, OpenSearch và OpenSearch Service đã mang đến các khả năng cân bằng giữa chi phí, độ trễ và độ chính xác. Một lĩnh vực đổi mới của dịch vụ là đưa ra các phương pháp khác nhau để giảm lượng RAM tiêu thụ bởi vector embeddings thông qua các phương pháp k-NN vector quantization. Ngoài những phương pháp mới này, OpenSearch từ lâu đã hỗ trợ product quantization cho FAISS engine. Product quantization sử dụng training để xây dựng các centroids cho vector clusters trên các sub-vectors có chiều giảm và truy vấn bằng cách khớp các centroids này. Chúng tôi đã viết blog về lợi ích về độ trễ và chi phí của product quantization.

Bạn sử dụng chiến lược chunking để chia các tài liệu dài thành các phần nhỏ hơn, có thể truy xuất được. Ý tưởng cốt lõi đằng sau việc này là các đoạn văn bản lớn chứa nhiều “bể” ý nghĩa khác nhau, được nắm bắt trong các câu, đoạn văn, bảng và hình ảnh. Bạn chọn các chunks là các đơn vị có ý nghĩa, trong các nhóm từ liên quan. Trong năm 2024, OpenSearch đã thực hiện quy trình này với truy vấn k-NN đơn giản, giảm bớt nhu cầu về logic xử lý tùy chỉnh. Giờ đây, bạn có thể biểu diễn các tài liệu dài dưới dạng nhiều vector trong một trường lồng nhau (nested field). Khi bạn chạy các truy vấn k-NN, mỗi nested field được xử lý như một vector đơn (một tài liệu dài được mã hóa). Trước đây, bạn phải triển khai logic xử lý tùy chỉnh trong ứng dụng của mình để hỗ trợ truy vấn các tài liệu được biểu diễn dưới dạng vector chunks. Với tính năng này, bạn có thể chạy các truy vấn k-NN, giúp việc tạo ứng dụng tìm kiếm vector trở nên liền mạch.

Similarity search được thiết kế xoay quanh việc tìm k vectors gần nhất, đại diện cho top-k tài liệu tương tự nhất. Trong năm 2024, OpenSearch đã cập nhật giao diện truy vấn k-NN để bao gồm việc lọc kết quả k-NN dựa trên khoảng cách và điểm vector, bên cạnh hỗ trợ top-k hiện có. Điều này lý tưởng cho các trường hợp sử dụng mà mục tiêu của bạn là truy xuất tất cả các kết quả có độ tương tự cao hoặc đủ (ví dụ: >= 0.95), giảm thiểu khả năng bỏ sót các kết quả có liên quan cao vì chúng không đáp ứng ngưỡng top-k.

Giảm chi phí cho workload production

Trong năm 2024, OpenSearch đã giới thiệu và mở rộng các phương pháp lượng tử hóa vô hướng (scalar quantization) và lượng tử hóa nhị phân (binary quantization) giúp giảm số bit được sử dụng để lưu trữ mỗi vector. OpenSearch đã hỗ trợ lượng tử hóa tích (product quantization) cho các vector. Khi sử dụng các phương pháp scalar và byte quantization này, OpenSearch giảm số bit được sử dụng để lưu trữ vectors trong chỉ mục k-NN từ số thực dấu phẩy động 32-bit xuống còn 1 bit cho mỗi chiều. Đối với scalar quantization, OpenSearch hỗ trợ half precision (còn gọi là fp16), và quarter precision với số nguyên 8-bit cho độ nén gấp hai và bốn lần tương ứng.

Đối với binary quantization, OpenSearch hỗ trợ nén 1-bit, 2-bit và 4-bit cho độ nén 32, 16 và 8 lần tương ứng. Các phương pháp quantization này có tổn thất, giảm độ chính xác. Trong quá trình kiểm tra, chúng tôi đã thấy tác động tối thiểu đến độ chính xác – chỉ khoảng 2% trên một số bộ dữ liệu chuẩn hóa – với mức giảm RAM tiêu thụ lên đến 32 lần.

Việc xử lý các vector dày đặc (dense vectors) trong bộ nhớ (in-memory) làm tăng chi phí tỷ lệ thuận với số lượng vectors, chiều vector và các tham số bạn đặt cho việc indexing. Trong năm 2024, OpenSearch đã mở rộng xử lý vector để bao gồm tìm kiếm vector dựa trên disk. Với tính năng tìm kiếm vector dựa trên đĩa (disk-based), OpenSearch giữ một vector có số bit giảm trong bộ nhớ để tạo ra các ứng viên phù hợp, truy xuất các vector độ chính xác đầy đủ cho việc tính điểm và xếp hạng cuối cùng. Độ nén mặc định 32 lần có nghĩa là giảm nhu cầu RAM xuống 32 lần với mức giảm tương ứng trong chi phí của giải pháp.

Trong năm 2024, OpenSearch đã giới thiệu hỗ trợ cho JDK21, mà người dùng có thể sử dụng để chạy các cluster OpenSearch trên phiên bản Java mới nhất. OpenSearch tiếp tục nâng cao hiệu suất bằng cách thêm hỗ trợ cho các tập lệnh Single Instruction, Multiple Data (SIMD) cho các truy vấn tìm kiếm chính xác. Các phiên bản trước đã hỗ trợ SIMD cho các truy vấn tìm kiếm ANN. Việc tích hợp SIMD cho tìm kiếm chính xác không yêu cầu các bước cấu hình bổ sung, tạo ra cải thiện hiệu suất liền mạch. Bạn có thể mong đợi sự giảm đáng kể trong độ trễ truy vấn và trải nghiệm tìm kiếm hiệu quả và phản hồi nhanh hơn, với hiệu suất nhanh hơn khoảng 1.5 lần so với các triển khai không sử dụng SIMD.

Tăng tốc độ đổi mới

Vào tháng 11 năm 2023, OpenSearch 2.9 đã được phát hành trên Amazon OpenSearch Service. Phiên bản này bao gồm các giao diện cơ sở dữ liệu vector cấp cao như neural search, hybrid search và AI connectors. Ví dụ, người dùng có thể sử dụng neural search để chạy các truy vấn ngữ nghĩa với đầu vào văn bản thay vì vectors. Sử dụng AI connectors đến các dịch vụ như Amazon SageMaker, Amazon Bedrock và OpenAI, neural search mã hóa văn bản thành vectors sử dụng các mô hình ưa thích của khách hàng và viết lại các truy vấn dựa trên văn bản thành các truy vấn k-NN một cách trong suốt. Hiệu quả, neural search đã giảm bớt nhu cầu khách hàng phải phát triển và quản lý middleware tùy chỉnh để thực hiện chức năng này, vốn được yêu cầu bởi các ứng dụng sử dụng API k-NN.

Với các phiên bản 2.11 và 2.13 sau đó, OpenSearch đã lần lượt thêm các giao diện cấp cao cho tìm kiếm đa phương thức (multimodal search) và tìm kiếm đối thoại (conversational search). Với multimodal search, khách hàng có thể chạy các truy vấn ngữ nghĩa sử dụng kết hợp đầu vào văn bản và hình ảnh để tìm kiếm hình ảnh. Như được minh họa trong bài blog OpenSearch này, multimodal cho phép các mô hình tìm kiếm mới. Ví dụ, một khách hàng thương mại điện tử có thể sử dụng ảnh một chiếc áo và mô tả các thay đổi như “với màu sa mạc” để mua sắm quần áo theo sở thích của họ. Được hỗ trợ bởi connector đến Amazon Bedrock Titan Multimodal Embeddings G1, việc tạo vector và viết lại truy vấn được xử lý bởi OpenSearch.

Conversational search đã kích hoạt một mô hình tìm kiếm khác, mà người dùng có thể sử dụng để khám phá thông tin thông qua chat. Các tìm kiếm hội thoại chạy RAG pipelines, sử dụng connectors đến các LLM sinh thành như Anthropic’s Claude 3.5 Sonnet trong Amazon Bedrock, OpenAI ChatGPT, hoặc DeepSeek R1 để tạo ra các phản hồi hội thoại. Một module bộ nhớ hội thoại cung cấp cho LLMs bộ nhớ liên tục bằng cách lưu giữ lịch sử cuộc trò chuyện.

Với OpenSearch 2.17, hỗ trợ cho các trường hợp sử dụng AI tìm kiếm đã được mở rộng thông qua các pipeline AI-native. Với ML inference processors (yêu cầu tìm kiếm, phản hồi, ingestion), khách hàng có thể làm phong phú luồng dữ liệu trên OpenSearch với bất kỳ mô hình machine learning (ML) hoặc dịch vụ AI nào. Trước đây, các phần bổ sung bị giới hạn ở một vài loại mô hình như các mô hình text embedding để hỗ trợ neural search. Không có giới hạn về hỗ trợ loại mô hình, toàn bộ phạm vi các trường hợp sử dụng AI tìm kiếm có thể được cung cấp bởi các API pipeline tìm kiếm và ingestion của OpenSearch.

Kết luận

OpenSearch tiếp tục khám phá và nâng cao các tính năng của mình để xây dựng các giải pháp tìm kiếm ngữ nghĩa và cơ sở dữ liệu vector có khả năng mở rộng, hiệu quả về chi phí và độ trễ thấp. Neural plugin của OpenSearch Service, framework connector và các API cấp cao giảm độ phức tạp cho các nhà phát triển, làm cho cơ sở dữ liệu vector của OpenSearch Service dễ tiếp cận và mạnh mẽ hơn. Những cải tiến năm 2024 bao gồm tìm kiếm chính xác dựa trên văn bản, tìm kiếm ngữ nghĩa và tìm kiếm hybrid. Những cải tiến về hiệu suất, đổi mới tính năng và tích hợp này cung cấp nền tảng vững chắc để tạo ra các giải pháp dựa trên AI mang lại hiệu suất tốt hơn và kết quả chính xác hơn. Hãy thử các tính năng mới này với phiên bản mới nhất của OpenSearch.

Về Tác giả

Jon Handler

Jon Handler là Giám đốc Solutions Architecture cho Search Services tại Amazon Web Services, có trụ sở tại Palo Alto, CA. Jon làm việc chặt chẽ với OpenSearch và Amazon OpenSearch Service, cung cấp trợ giúp và hướng dẫn cho nhiều khách hàng có workload generative AI, tìm kiếm và phân tích log cho OpenSearch. Trước khi gia nhập AWS, sự nghiệp của Jon với tư cách là nhà phát triển phần mềm bao gồm bốn năm lập trình một công cụ tìm kiếm thương mại điện tử quy mô lớn. Jon có bằng Cử nhân Nghệ thuật từ Đại học Pennsylvania, và bằng Thạc sĩ Khoa học và Tiến sĩ về Khoa học Máy tính và Trí tuệ Nhân tạo từ Đại học Northwestern.