TỔNG QUAN CÁC KỸ THUẬT TÌM KIẾM VÀ ỨNG DỤNG CÁ NHÂN HÓA CÓ SỬ DỤNG HỌC MÁY
Các mô hình xếp hạng thông thường
Mô hình xếp hạng là hệ thống giải quyết hoặc xây dựng các vấn đề khác nhau của IR
Thông thường, mô hình xếp hạng được viết gọn trong 4 chữ D, Q, F, R Trong đó các chữ được định nghĩa như sau:
D (Document collection) là tập hợp các tài liệu, trong đó mỗi tài liệu được mô hình hóa dưới dạng nhóm các thuật ngữ chỉ mục Các thuật ngữ chỉ mục này được giả định là độc lập với nhau.
Q (Query collection) là một tập hợp các truy vấn do người dùng kích hoạt, được sử dụng để thu thập thông tin Nó cũng có thể được mô hình hóa như một bộ các thuật ngữ chỉ mục cho các trường hợp cụ thể.
• F là Framework cho mô hình mô tả tài liệu, các câu truy vấn và mối quan hệ giữa chúng
R (hàm xếp hạng) gán một điểm số thực cho mỗi cặp (𝑞 𝑖 , ⅆ 𝑖 ), trong đó 𝑞 𝑖 thuộc tập truy vấn Q và ⅆ 𝑖 thuộc tập tài liệu D Dựa trên truy vấn (𝑞 𝑖 ), các tài liệu sẽ được sắp xếp theo điểm số đã được tính toán.
Mô hình truy xuất thông tin truyền thống là một phương pháp đơn giản và phổ biến, sử dụng lý thuyết tập hợp cùng với các toán tử Boolean như NOT, OR, AND và các quy tắc cú pháp Mô hình này chỉ trả về các tài liệu hoàn toàn khớp với truy vấn, trong khi các tài liệu liên quan khác không được đề cập Ví dụ, hệ thống có 4 bản ghi có thể minh họa cho cách hoạt động của mô hình này.
Nhà ở Cầu Giấy có diện tích 50m2, phù hợp với nhu cầu tìm kiếm của người dùng Hệ thống phân tích thông tin để cung cấp kết quả chính xác, loại trừ các tùy chọn không phù hợp như diện tích 20m2.
Bảng 2.1 Biểu diễn có hoặc không xuất hiện trong doc của các index
Truy vấn với phép toán AND:
1001(Nhà)AND1001(Cầu Giấy)AND1011(không 20m2) = 1001
kết quả hệ thống sẽ đưa ra cho bạn Doc4, Doc1 Ưu điểm:
• Cú pháp truy vấn dễ hiểu, dễ làm
• Tốc độ tìm kiếm nhanh với khối lượng database không lớn
• Có thể được mở rộng để xếp hạng được output (ranking output)
• Tìm kiếm chính xác những gì người dùng yêu cầu
• Tương đối hiệu quả về mặt tính toán cho những câu query thông thường
• Chính vì thế thuật toán vẫn được sử dụng rộng rãi trong các quy mô tìm kiếm nhỏ như email, ổ cứng
• Mô hình có tốc độ tìm kiếm khá chậm với các khối lượng dữ liệu lớn
• Không thể biểu diễn các câu truy vấn phức tạp
• Những tài liệu liên quan cũng không được đề cập
• Hệ thống cũng không bắt được tài liệu chứa từ đồng nghĩa
• Thường các bản ghi khó được xếp hạng các bản ghi đã được truy vấn
2.1.2 Mô hình không gian vector (Vector space model)
Mô hình Boolean gặp khó khăn trong việc tìm nạp các thành phần thiếu trong quy trình chấm điểm với các bản ghi đã truy vấn, dẫn đến việc xếp hạng trở nên phức tạp Tuy nhiên, vấn đề này đã được khắc phục nhờ vào mô hình không gian vector.
Trong mô hình không gian vector, thông tin văn bản được đại diện dưới dạng vector, trong đó các phần tử phản ánh mức độ quan trọng của từ và sự hiện diện hay vắng mặt của từ đó trong tài liệu.
Văn bản được biểu diễn dưới dạng các điểm trong không gian Euclid n chiều, với mỗi chiều tương ứng với một từ trong tập hợp từ vựng Phần tử thứ i của vector văn bản, ký hiệu là ⅆ 𝑖, thể hiện số lần xuất hiện của từ thứ i trong văn bản Sự tương đồng giữa hai văn bản được đánh giá qua khoảng cách giữa các điểm hoặc góc giữa các vector trong không gian Mỗi từ trong không gian vector đều có trọng số riêng Trong số nhiều phương pháp xếp hạng, tf-idf là phương pháp phổ biến nhất để đánh giá và xếp hạng từ trong tài liệu.
Term Frequency (tf): là tần số xuất hiện của từ, hoặc cụm từ i trong tài liệu
ⅆ 𝑗 được biểu diễn bằng công thức dưới đây
𝑚𝑎𝑥( freq 𝑖,𝑗 ) Trong đó 𝑓𝑟𝑒𝑞 𝑖,𝑗 là số lần cụm từ i, xuất hiện trong tài liệu ⅆ 𝑗
Tần suất nghịch đảo của tài liệu (idf) là một chỉ số quan trọng trong việc phân tích văn bản, giúp xác định độ hiếm của các từ trong hệ thống Trong khi tần số cho thấy sự phổ biến của từ trong văn bản, tần suất nghịch đảo lại cung cấp cái nhìn sâu sắc về những từ ít xuất hiện, từ đó mang lại thông tin quý giá hơn cho người dùng Công thức tính tần suất nghịch đảo được thể hiện rõ ràng dưới đây.
Trong lĩnh vực tìm kiếm thông tin, số lượng văn bản chứa từ hoặc cụm từ i được ký hiệu là 𝑛𝑖, trong khi N là tổng số văn bản trong cơ sở dữ liệu Quá trình tìm kiếm một cụm từ tương tự như thực hiện một truy vấn toàn văn, trong đó cụm từ cần tìm (query) được so sánh với các tài liệu có sẵn Nếu coi các câu truy vấn là một vector, ta có thể xếp hạng các tài liệu dựa trên độ tương đồng với câu truy vấn Để thực hiện việc này, cần so sánh câu truy vấn với tập hợp tài liệu; tài liệu nào có vector gần với vector của câu truy vấn sẽ có điểm xếp hạng cao hơn Một số phương pháp đánh giá độ tương đồng giữa hai vector bao gồm khoảng cách Euclid, khoảng cách Manhattan và độ tương tự cosin Trong đó, công thức độ tương tự cosin (cosine similarity) thường được sử dụng để tính toán độ tương đồng giữa vector tài liệu và câu truy vấn.
𝑠𝑖𝑚 (ⅆ 𝑖 , 𝑞) = 𝑐𝑜𝑠𝜃 Trong đó góc theta θ là góc tạo bởi 2 vector ⅆ 𝑖 , q
Ranking: Mô hình xếp hạng các tài liệu bằng việc đánh giá góc giữa tài liệu và câu truy vấn Ưu điểm:
• Có thể xếp hạng bằng các kết quả tương đồng
• Kết quả trả về trong khoảng từ 0 đến 1 nên có thể phù hợp với truy vấn
• Các chỉ mục độc lập với nhau nên khi truy vấn có thể làm mất nghĩa của cả câu
• Không có được cái nhìn logic như mô hình Boolean
2.1.3 Mô hình xác suất BM25
Mô hình xác suất mang ý tưởng cơ bản là lấy các tài liệu dựa trên xác suất của tài liệu có liên quan
Mô hình Okapi BM25 là một phiên bản mở rộng của mô hình xác suất, lần đầu tiên được áp dụng trong hệ thống tìm kiếm Okapi Điểm xếp hạng của BM25, viết tắt của Best Match, được tính dựa trên một công thức cụ thể.
Trong công thức tf(qp, D) + k1 ⋅ (1 − b + b ⋅ |a| avgdl), giá trị avgdl đại diện cho độ dài trung bình của văn bản trong tập dữ liệu Các tham số k1 và b là những tham số tùy chọn, với k1 thường nằm trong khoảng từ 1.2 đến 2.0 và b có giá trị cố định là 0,75.
Mô hình này cải thiện được những điểm yếu của hai mô hình trên.
Apache Lucene, Elasticsearch và kỹ thuật tìm kiếm trong Elasticsearch12
Có nhiều công cụ hỗ trợ lập chỉ mục và tìm kiếm tài liệu như Apache Solr, Lucene, và Sphinx Trong luận văn này, tôi đã chọn sử dụng Elasticsearch, một hệ thống tìm kiếm và lập chỉ mục được phát triển trên nền tảng Apache Lucene.
Lucene là phần mềm mã nguồn mở viết bằng Java, được Doug Cutting phát triển và ra mắt lần đầu vào tháng 8 năm 2000 Năm 2001, Lucene gia nhập tổ chức Apache, cung cấp các chức năng phân tích, đánh chỉ mục và tìm kiếm thông tin hiệu quả.
Hai thành phần chức năng chính của Lucene, bao gồm việc tạo chỉ mục và tìm kiếm, là những yếu tố quan trọng hàng đầu cho một hệ thống tìm kiếm thông tin hiệu quả.
Thành phần Tạo chỉ mục trong Lucene thực hiện chức năng xử lý và phân tích dữ liệu trước khi đánh chỉ mục Nó bao gồm các lớp đối tượng quan trọng như Lớp Analyzer, giúp chuẩn bị và chuẩn hóa dữ liệu, Lớp IndexWriter, chịu trách nhiệm tạo, sửa đổi hoặc xóa chỉ mục, Lớp Document và Field, dùng để biểu diễn tài liệu và các trường của tài liệu, và Lớp Directory, cho phép người dùng xác định vùng nhớ để lưu trữ trong quá trình tạo chỉ mục.
Thành phần Tìm kiếm thực hiện chức năng tìm kiếm và trả về kết quả, đồng thời so sánh và đánh giá để lấy về kết quả tốt nhất Trong đó, IndexSearcher thực hiện tìm kiếm dữ liệu trên các chỉ mục do IndexWriter tạo ra, với lớp này chỉ đọc chỉ mục mà không thực hiện chỉnh sửa TopDoc cho phép cấu hình số lượng bản ghi có thứ hạng cao nhất trong kết quả trả về cho người dùng, mỗi đối tượng trong danh sách này có một docID tương ứng liên kết tới tài liệu trả ra Cuối cùng, Query hỗ trợ khả năng tạo các truy vấn khác nhau của người dùng thông qua các API được cung cấp bởi lớp Query và được xử lý bởi QueryParser.
2.2.2 Elasticsearch và kỹ thuật tìm kiếm trong Elasticsearch
Elasticsearch là một công cụ tìm kiếm mạnh mẽ với nhiều REST API đơn giản, cho phép phân tích, lưu trữ và tìm kiếm toàn văn (full-text search) một khối lượng lớn dữ liệu, bao gồm dữ liệu dạng văn bản, số, địa lý, cấu trúc và phi cấu trúc, với tốc độ gần như thời gian thực Nó thường được sử dụng như nền tảng công nghệ để phát triển các tính năng tìm kiếm phức tạp cho các ứng dụng khác.
Elasticsearch, ra mắt vào tháng 2 năm 2010, được phát triển bởi Shay Banon dựa trên các đặc tả API của Lucene Đây là một phần mềm mã nguồn mở viết bằng ngôn ngữ Java, phân tán thời gian thực, có khả năng mở rộng cao và hoạt động dựa trên nền tảng Apache Lucene, theo giấy phép Apache 2.0.
Elasticsearch là một giải pháp lưu trữ dữ liệu mạnh mẽ, có khả năng mở rộng dung lượng lên tới petabyte, hỗ trợ cả dữ liệu có cấu trúc và không có cấu trúc Nó có thể thay thế các cơ sở dữ liệu tài liệu như MongoDB và RavenDB, đồng thời sử dụng tính không chuẩn hóa để tối ưu hóa hiệu suất tìm kiếm.
Elasticsearch là một trong những công cụ tìm kiếm doanh nghiệp hàng đầu, được nhiều tổ chức lớn như Wikipedia, The Guardian, StackOverflow và GitHub sử dụng Theo đánh giá của DB-Engines, Elasticsearch đứng đầu trong danh sách các công cụ tìm kiếm doanh nghiệp phổ biến, tiếp theo là Apache Solr, cũng dựa trên nền tảng Lucene.
Hình 2.1 Danh sách một số sản phẩm sử dụng Elasticsearch
Elasticsearch có nhiều ưu điểm vượt trội hơn các công cụ tìm kiếm khác:
• Tìm kiếm nhanh, gần như theo thời gian thực
• Cấu trúc dữ liệu dưa trên documents thay vì dữ liệu quan hệ dựa trên tables và schema
• Hỗ trợ phát hiện một số kiểu dữ liệu cơ bản Do đo chỉ cân tiến hành index tài liệu ngay sau khi cài đặt xong
• Hỗ trợ các RESTful API và sử dụng các schema-free JSON documents giúp việc sử dụng dễ dàng
• Tính sẵn sàng cao, dễ dàng mở rộng, hỗ trợ cluster, tính năng phân mảnh và tạo bản sao (shards và replica)
Một số khái niệm và kiến trúc của Elasticsearch
Cluster trong Elasticsearch là một nhóm các nút (nodes) liên kết với nhau, giữ toàn bộ dữ liệu Sức mạnh của cluster đến từ khả năng phân phối các tác vụ, tìm kiếm và lập chỉ mục trên tất cả các nút trong nhóm Mỗi cluster được xác định bằng một tên duy nhất, với tên mặc định là.
Elasticsearch tự động tổ chức lại cụm khi các nút tham gia hoặc rời bỏ, nhằm phân phối đồng đều dữ liệu trên các nút hiện có.
Node là thành phần chính trong cluster, đóng vai trò là server độc lập để lưu trữ dữ liệu, lập chỉ mục và tìm kiếm Mỗi node có một định danh duy nhất (node_name) và được kết nối với một cluster thông qua tên cluster Trong một cluster, số lượng node là không giới hạn và có ba loại node chính: Master node, chịu trách nhiệm quản lý các hoạt động như tạo, xóa Index và điều chỉnh shard; Data node, lưu trữ dữ liệu tại các shard và thực hiện các thao tác CRUD; và Client node (Ingest node), xử lý tài liệu, điều hướng và cân bằng tải các truy vấn mà không lưu trữ dữ liệu hay trở thành Master node Nếu một Data node gặp sự cố, cluster vẫn hoạt động bình thường và tự động tổ chức lại các shard trên các node khác.
Hình 2.2 Ví dụ về kiến trúc của một Elasticsearch cluster
Shard và replicas là những khái niệm quan trọng trong Elasticsearch, cho phép một index lưu trữ lượng lớn dữ liệu vượt quá giới hạn phần cứng của một node Chẳng hạn, một index chứa một tỷ documents với dung lượng 1TB có thể không phù hợp với dung lượng đĩa của một node hoặc có thể quá chậm để xử lý yêu cầu tìm kiếm Để khắc phục vấn đề này, Elasticsearch cho phép chia nhỏ chỉ mục thành nhiều phần gọi là shard, bao gồm hai loại: primary và replica.
Hình 2.3 Ví dụ mô tả về Elasticsearch shard và replicas
Trong môi trường mạng hoặc đám mây, việc có cơ chế chuyển đổi dự phòng là rất quan trọng để xử lý các lỗi có thể xảy ra, đặc biệt khi shard hoặc node không hoạt động Elasticsearch hỗ trợ tạo bản sao chỉ mục, được gọi là replica shards, nhằm đảm bảo dữ liệu luôn sẵn sàng và an toàn.
Index là một tập hợp các tài liệu có những đặc điểm tương tự, chẳng hạn như index cho dữ liệu khách hàng, danh mục sản phẩm và dữ liệu đơn hàng Mỗi index được xác định bằng một tên chữ thường, được sử dụng để thực hiện các hoạt động như lập index, tìm kiếm, cập nhật và xóa tài liệu Một cluster có thể chứa nhiều index khác nhau.
Cá nhân hóa trong tìm kiếm (Personalized search)
Hệ thống tìm kiếm cá nhân hóa (personalized search) là một công nghệ điều chỉnh kết quả tìm kiếm dựa trên thông tin và sở thích của người dùng, nhằm mang đến trải nghiệm tìm kiếm phù hợp và hiệu quả hơn.
Nỗ lực cá nhân hóa trong luận văn này tập trung vào việc xếp hạng lại kết quả tìm kiếm nhằm nâng cao chất lượng tìm kiếm Đồng thời, nghiên cứu cũng hướng tới việc tích hợp các thành phần cá nhân hóa vào hệ thống tìm kiếm để tối ưu hóa trải nghiệm người dùng.
Sơ đồ hoạt động của hệ thống này sẽ giống như sau:
Hình 2.4 Sơ đồ đơn giản một hệ thống cá nhân hóa tìm kiếm
Học để xếp hạng (learning to rank) là một ứng dụng của học máy, thường sử dụng phương pháp học có giám sát hoặc nửa giám sát để giải quyết vấn đề xếp hạng trong tìm kiếm Dữ liệu đào tạo cho mô hình này bao gồm danh sách các kết quả tìm kiếm cho một truy vấn cụ thể, cùng với mức độ liên quan của từng kết quả Dữ liệu này thường được tạo ra thông qua việc kiểm tra các kết quả và quyết định xem có nên đưa vào hoặc loại trừ từng kết quả khỏi tập dữ liệu.
Có nhiều mô hình xếp hạng khác nhau, như BM25 và LMIR, với các tham số tự chọn như k1, b và λ Việc tinh chỉnh các tham số này thường dựa trên cảm tính và so sánh thủ công hiệu suất tìm kiếm, dẫn đến khó khăn vì mỗi truy vấn có thể yêu cầu các tham số khác nhau Hơn nữa, việc kết hợp các mô hình xếp hạng để tạo ra một mô hình mới hiệu quả hơn cũng là một thách thức Sử dụng học máy trong xếp hạng giúp tự động điều chỉnh các tham số và kết hợp nhiều đặc trưng, từ đó nâng cao hiệu suất xếp hạng.
Có 3 hướng tiếp cận chính của mô hình học để xếp hạng:
Phương pháp Pointwise chỉ tập trung vào việc phân tích một tài liệu tại một thời điểm, sử dụng các kỹ thuật phân loại hoặc hồi quy để dự đoán mức độ phù hợp của tài liệu đó, với một số thuật toán tiêu biểu như OPRF và SLR Ngược lại, phương pháp Pairwise so sánh hai tài liệu cùng lúc, cũng áp dụng phân loại hoặc hồi quy để xác định tài liệu nào trong hai tài liệu được xếp hạng cao hơn, với các thuật toán nổi bật như SVM-rank, RankRLS và Xgboost.
Phương pháp Listwise: Xem xét thứ tự tối ưu của toàn bộ danh sách tài liệu Một số thuật toán ứng dụng phương pháp này: PermuRank, ListMLE, Listnet, …
Phương pháp Listwise xử lý toàn bộ danh sách tài liệu như một tập dữ liệu đầu vào và áp dụng các mô hình xác suất để tối ưu thứ tự tài liệu, tuy nhiên, nó phức tạp hơn so với các phương pháp Pointwise và Pairwise Trong đó, ListNet là một thuật toán học máy nổi bật, nhằm tối ưu hóa chức năng sắp xếp danh sách dựa vào xác suất tài liệu thứ j xuất hiện ở vị trí cao nhất, được tính từ tổng xác suất hoán vị mà tài liệu đó được xếp hạng trên cùng trong một truy vấn ListNet sử dụng mạng nơ-ron để huấn luyện và áp dụng thuật toán Gradient Descent để tối ưu hóa hàm mất mát trên toàn bộ danh sách.
ListMLE là một thuật toán học máy thuộc phương pháp Listwise, nổi bật với hiệu suất cao Thuật toán này xác định phân bố xác suất dựa trên mô hình Plackett-Luce theo cách tiếp cận từ trên xuống, giúp tính toán vị trí thông tin một cách hiệu quả.
2.3.3 Phương pháp Pairwise và thuật toán SVMRank Để giải quyết bài toán Pairwise, vấn đề xếp hạng (ranking) được đưa về bài toán phân lớp cho từng cặp đối tượng tài liệu Giá trị của hàm phân lớp là giá trị xếp hạng đối tượng
SVM (Support Vector Machine) là một thuật toán học máy phân lớp nhị phân có giám sát, nhằm chia các đối tượng thành hai lớp Nguyên tắc chính của SVM là xác định siêu phẳng tối ưu, phân chia không gian các đối tượng thành hai nửa, với khoảng cách lớn nhất từ siêu phẳng tới các đối tượng gần nhất trong cả hai lớp.
SVMRank là một thuật toán học máy dựa trên SVM, được thiết kế để giải quyết vấn đề xếp hạng tài liệu Thuật toán này hoạt động theo phương pháp phân loại theo cặp tài liệu (pairwise).
Giả sử dữ liệu đầu vào là tập tài liệu trong không gian n chiều X € 𝑅 𝑛, với n là số đặc trưng của tài liệu Kết quả xếp hạng được biểu diễn bằng Y = {𝑟 1 , 𝑟 2 , … , 𝑟 𝑞 }, trong đó q là số lượng các hạng có thể Các hạng này được sắp xếp theo thứ tự ưu tiên như 𝑟 𝑞 › 𝑟 𝑞−1 › › 𝑟 1, với "›" thể hiện mối quan hệ ưu tiên giữa các tài liệu Tồn tại một tập hợp các hàm xếp hạng f ∈ F, mỗi hàm f có khả năng quyết định quan hệ ưu tiên giữa các tài liệu.
Giả sử có một tập tài liệu đã được xếp hạng S = {(𝑥𝑖, 𝑦𝑖)} với i = 1, t từ không gian X × Y Mục tiêu là học hàm xếp hạng f* tốt nhất từ F để tối thiểu hóa độ sai lệch (loss value) theo một hàm tính độ sai lệch đã cho (lost function) trên tập dữ liệu này Phương pháp SVM được sử dụng để tìm siêu phẳng, từ đó suy ra hàm xếp hạng Để xác định siêu phẳng tối ưu, Joachims đã đề xuất công thức tối ưu.
Dựa trên phương pháp SVMRank này, Joachims đưa ra các công cụ SVMLight, SVMRank hỗ trợ việc học để xếp hạng
Mặc dù phương pháp Pairwise có độ chính xác thấp hơn so với phương pháp Listwise vì chỉ xếp hạng dựa trên các cặp tài liệu, nhưng nó lại có ưu điểm về tốc độ và tính đơn giản trong quá trình đào tạo và đánh giá Phương pháp Pairwise kết hợp với thuật toán SVMRank cho phép thực thi nhanh chóng và dễ dàng, do đó, trong luận văn này, SVMRank sẽ được lựa chọn làm thuật toán học máy để xây dựng hệ thống thử nghiệm.
Trong nhiều trường hợp, điểm số ban đầu của hệ thống xếp hạng kết quả có thể không đạt yêu cầu Để nâng cao điểm số này, chúng ta có thể xác định một tập hợp các đặc trưng bổ sung ngoài điểm số tìm kiếm cơ bản, giúp cải thiện hiệu quả của hệ thống xếp hạng Các đặc trưng này có thể bao gồm:
• Giá trị BM25 (search metric)
• Điểm xếp hạng trang tài liệu (Document pagerank score)
• Tài liệu sử dụng gần đây (Document recency)
• Thông tin về phiên của người dùng
• Sản phẩm mua gần đây của người dùng (với các hệ thống ecommerce)
• Sản phẩm đang trong giỏ hàng của người dùng (với các hệ thống ecommerce)
• Số liệu đo lường Click-Through Rate
Các đặc trưng có thể được gán thủ công giá trị đại diện để thể hiện mức độ liên quan tới kết quả tìm kiếm, nhưng phương pháp này tốn nhiều thời gian và không dựa trên dữ liệu.
PHÂN TÍCH THIẾT KẾ VÀ TRIỂN KHAI HỆ THỐNG TÌM KIẾM TRÊN NỀN TẢNG MICROSOFT AZURE
Mô hình tổng quan và kiến trúc hệ thống
Dựa trên các nghiên cứu và giới thiệu đã đề cập, tôi đề xuất một hệ thống dịch vụ tìm kiếm và ứng dụng cá nhân hóa sử dụng công nghệ học máy Mô hình tổng quan của hệ thống sẽ được trình bày như sau.
Hình 3.1 Mô hình tổng quát hệ thống tìm kiếm
Các thành phần chính của mô hình trên:
Bộ thư viện client cung cấp các phương thức và hàm để chuyển đổi dữ liệu phù hợp, giúp tương tác hiệu quả với các API của hệ thống dịch vụ tìm kiếm.
Cổng API (API gateway/proxy) là điểm truy cập chính cho hệ thống tìm kiếm, thực hiện các chức năng như cân bằng tải, xác thực và ủy quyền các yêu cầu từ phía client, cũng như sửa đổi dữ liệu và câu truy vấn trước khi chuyển tiếp đến các thành phần tiếp theo.
Crawler là công cụ thu thập dữ liệu, thực hiện việc lấy thông tin một cách có hệ thống từ các nguồn bên ngoài, khác với dữ liệu nội bộ của khách hàng Nó hỗ trợ nhiều loại định dạng dữ liệu web như HTML, XML, Atom và các định dạng khác.
• Search engine: Công cụ tìm kiếm, chứa các API thực hiện việc phân tích dữ liệu, lập chỉ mục và tìm kiếm dữ liệu
• Personalization service: dịch vụ cá nhân hóa, thực hiện việc theo dõi, thu thập và phân tích dữ liệu người dùng
Dựa trên mô hình tổng quan và kinh nghiệm thực tiễn, luận văn này giới thiệu kiến trúc và cơ sở hạ tầng của hệ thống cung cấp dịch vụ tìm kiếm được triển khai trên nền tảng Microsoft Azure.
Hình 3.2 Kiến trúc cơ sở hạ tầng hệ thống tìm kiếm triển khai dựa trên Azure
Một số thành phần chính trong kiến trúc trên:
• Client: Bộ thư viện client cho phép khách hàng/lập trình viên kết nối và sử dụng các API của dịch vụ tìm kiếm, hỗ trợ C#
Cổng vào ứng dụng (app gateway) là địa chỉ công cộng của hệ thống dịch vụ tìm kiếm, có chức năng hỗ trợ cân bằng tải, kiểm tra, cô lập và thông báo khi dịch vụ phía sau gặp sự cố.
Proxy là một tập hợp các máy chủ không trạng thái, có nhiệm vụ xác thực và phân quyền, định tuyến các yêu cầu đến các dịch vụ tương ứng, đồng thời thực hiện tiền xử lý và sửa đổi yêu cầu khi cần thiết.
• Redis: một bộ các redis server lưu dữ liệu về khóa và thông tin tài khoản khách hàng
• Stream service, Journal service, Ingest function, Track processor: các stateless microservices hỗ trợ tính năng stream request
• Runner: stateless microservice hỗ trợ tính năng thu thập dữ liệu web
• Internal load balancer: cân bằng tải nội bộ đứng phía trước các Elasticsearch client nodes
• Elasticsearch cluster: cụm Elasticsearch server bao gồm các master, client và data node
Thiết kế của một số thành phần chính trong hệ thống được mô tả tiếp sau đây
Thiết kế Client
Bộ thư viện client này cung cấp các phương thức tương tác với hầu hết các API công khai của dịch vụ tìm kiếm, hiện tại chỉ hỗ trợ ngôn ngữ C# Nó bao gồm một số chức năng chính quan trọng.
Thực hiện việc phiên dịch cấu trúc dữ liệu được miêu tả ở phía client sang định dạng json mà Elasticsearch có thể hiểu được
Bộ thư viện client hỗ trợ lập trình viên trong việc tạo và đăng ký quy ước phiên dịch kiểu dữ liệu, xác định các thuộc tính nào sẽ được phiên dịch Qua đó, bộ thư viện này hình thành quy tắc lập chỉ mục cho các giá trị thuộc tính dữ liệu.
Hình 3.3 Sơ đồ hoạt động Index/Reindex
Lên lịch lập chỉ mục tự động là một chức năng quan trọng trong client, nơi mà công việc lập chỉ mục (Indexing job) hoạt động như một lớp trình bao bọc Nhiệm vụ của nó là tự động cập nhật chỉ mục theo thời gian đã định hoặc khi có sự kiện được đăng ký xảy ra.
Hình 3.4 Sơ đồ hoạt động Indexing Job
Tạo kịch bản tìm kiếm toàn văn bản và tìm kiếm truyền thống, đồng thời thực hiện các truy vấn tập trung vào dữ liệu với đối sánh chính xác bằng cách sử dụng các bộ lọc tương tự như trong truy vấn cơ sở dữ liệu.
Một số kiểu tìm kiếm và tương tác của chức năng Search:
• Tìm kiếm toàn văn bản (Full-text search) cho phép tạo yêu cầu lập chỉ mục và truy vấn với từng loại đối tượng hoặc từng trường thông tin
Tìm kiếm hợp nhất cho phép lập chỉ mục và truy vấn các đối tượng từ các lớp hiện có mà không cần ánh xạ chúng tới một kiểu trung gian được đưa vào chỉ mục.
Từ đồng nghĩa giúp nâng cao kết quả tìm kiếm bằng cách xác định và sử dụng các từ có nghĩa tương tự, tạo ra mối quan hệ một chiều hoặc hai chiều giữa các cụm từ.
Bộ lọc (Filtering) giúp thu hẹp kết quả tìm kiếm, chẳng hạn như giới hạn tìm kiếm văn bản tự do cho sách trong một danh mục cụ thể, hoặc áp dụng cho các truy vấn tương tự như truy vấn vào cơ sở dữ liệu.
Tổng hợp và tìm kiếm theo khía cạnh (Aggregations, Facets) là phương pháp khám phá dữ liệu lớn thông qua việc tạo ra các bản tóm tắt phức tạp và cho phép người dùng thu hẹp tìm kiếm đến các phân vùng cụ thể Một ứng dụng điển hình là việc tạo đám mây thẻ sản phẩm, giúp khách truy cập dễ dàng điều hướng và giới hạn kết quả tìm kiếm theo các danh mục như loại sản phẩm, phạm vi giá hoặc tên tác giả.
• Phân trang (Pagination) cho phép hạn chế và phân chia hiển thị kết quả tìm kiếm
Tìm kiếm theo ngôn ngữ cụ thể và định tuyến ngôn ngữ giúp lập trình viên xác định các ngôn ngữ hỗ trợ của dữ liệu, đồng thời giới hạn truy vấn tìm kiếm chỉ trong các tài liệu bằng một ngôn ngữ nhất định.
Việc thực hiện nhiều tìm kiếm trong một yêu cầu cho phép tiến hành các tìm kiếm riêng biệt, từ đó tăng tốc độ truy xuất dữ liệu hiệu quả hơn.
Hình 3.5 Sơ đồ hoạt động Search
Search statistics enhance features such as autocomplete, spelling suggestions, and related queries, all of which are powered by the search statistics API provided by the search service.
• Tracking: Để thu thập thống kê lịch sử tìm kiếm cho phân tích sau này
Tính năng Autocomplete cho phép ứng dụng dự đoán phần còn lại của từ mà người dùng đang nhập, dựa vào lịch sử tìm kiếm hoặc các thiết lập từ người quản trị.
Kiểm tra chính tả: Dựa trên các tìm kiếm của người dùng khác, thống kê tìm kiếm có thể cung cấp chức năng kiểm tra chính tả Các truy vấn phổ biến tương tự với truy vấn của người dùng sẽ được áp dụng để cải thiện độ chính xác trong việc phát hiện lỗi chính tả.
Đôi khi, việc khám phá các mối quan hệ tìm kiếm mang lại giá trị thực tiễn, như khi người dùng tìm kiếm A cũng có thể tìm kiếm B Trong thống kê tìm kiếm, khái niệm này được gọi là các truy vấn liên quan (Related queries, DidYouMean).
Hình 3.6 Sơ đồ hoạt động Search statistics
Thiết kế Proxy service và tích hợp Personalization service
Proxy là điểm truy cập chính vào hệ thống dịch vụ tìm kiếm, tiếp nhận tất cả các lệnh gọi API từ client và chuyển hướng chúng đến các dịch vụ phía sau Nó có khả năng định tuyến yêu cầu, xác thực và phân quyền, cũng như tiền xử lý, chỉnh sửa và bổ sung yêu cầu trước khi chuyển tiếp.
Proxy được phát triển bằng Javascript, CoffeeScript, Nodejs và Express framework
Một số luồng hoạt động chính của Proxy
Xác thực yêu cầu (request authentication) thực hiện việc
• Phân tích khóa xác thực của yêu cầu từ request parameter/querystring
• Tìm kiếm và so sánh khóa xác thực với khóa và thông tin tài khoản/chỉ mục được lưu trữ trong redis
• Kiểm tra hành động của yêu cầu so với phân quyền trong thông tin tài khoản
Hình 3.7 Sơ đồ hoạt động Request Authentication
3.3.2 Request tracking và Personalization tracking
Request tracking involves gathering information about incoming requests to a proxy, identifying each request through a unique request identity or correlation ID, and generating log entries for systems that require this logging information, such as personalization, logs, and statistics.
When a request includes personalization options in the headers, the Proxy generates an additional request to the personalization system to retrieve the personalization tracking ID This information is then attached to the original request before redirecting it to the Search Statistics service.
Dữ liệu truy vấn của người dùng sẽ được hệ thống theo dõi gửi đến dịch vụ cá nhân hóa, nơi nó sẽ được thu thập, lưu trữ và sử dụng để huấn luyện và đánh giá hệ thống tìm kiếm của dịch vụ này.
• Personalization Search Tracking API endpoint:
• https://.peerius.com/tracker/api/v1_3/search/tracking
• Personalization Search Clicks API endpoint:
• https://.peerius.com/tracker/api/v1_3/search/clicks
"currentURI" : "www.retailer.com/home",
"https://www.google.co.uk/?gws_rd=ssl#q=retailer" ,
"userAgent" : "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36",
Hình 3.8 Sơ đồ hoạt động Request Tracking
Hình 3.9 Mô hình theo dõi lịch sử truy vấn của Personalization service
Dữ liệu lịch sử truy vấn của người dùng thể hiện mối liên hệ giữa các tìm kiếm, lịch sử truy cập và thông tin cá nhân hóa Những dữ liệu này sẽ được lọc và trích xuất các thông số đặc trưng liên quan đến việc cá nhân hóa trải nghiệm người dùng.
Hình 3.10 Mô hình học để xếp hạng của Personalization service
Danh sách đánh giá sẽ phân loại tài liệu dựa trên một từ khóa tìm kiếm nhất định, giúp xác định thứ tự lý tưởng cho từ khóa đó Chẳng hạn, nếu chúng ta đánh giá tài liệu từ 0 đến 4, trong đó 4 là mức độ liên quan cao nhất, có thể áp dụng cho một danh sách đánh giá tên phim với từ khóa tìm kiếm cụ thể.
Hình 3.11 Ví dụ về danh sách đánh giá
Vector đặc trưng trong mô hình huấn luyện bao gồm các điểm số được tính toán từ truy vấn của người dùng, kết hợp với mức độ liên quan của tài liệu trong danh sách đánh giá và các thông số cá nhân hóa của người dùng Dưới đây là một số thuộc tính của vector đặc trưng.
Bảng 3.1 Mô tả một số đặc trưng cho mô hình học để xếp hạng
Thứ tự Tên thuộc tính Mô tả
1 grade Xếp hạng độ liên quan giữa câu truy vấn và tài liệu
2 queryId Id của truy vấn
3 docId Id của tài liệu
4 titleBM25Score Điểm BM25 của truy vấn và tiêu đề tài liệu
5 descBM25Score Điểm BM25 của truy vấn và nội dung tài liệu
6 descTfidfScore Điểm TFIDF của nội dung tài liệu
7 docPageRank Xếp hạng của tài liệu trong trang web
8 userLocationScore Xếp hạng độ liên quan giữa vị trí người dùng và website
9 userVisitedCount Số lượt ghé thăm tài liệu của người dùng
10 totalClicks Tổng số lượt click của tài liệu
Sau khi trích xuất vector đặc trưng, chúng ta có thể tiến hành huấn luyện mô hình bằng cách sử dụng Elasticsearch Learning to Rank cùng với các thư viện chứa thuật toán huấn luyện như SVMRank.
Thuật toán SVM được sử dụng trong thư viện SVMRank và Elasticsearch Learning to rank là SVM phân loại nhiều lớp với các cài đặt:
• Sử dụng nhân tuyến tính (linear kernel)
• Tham số C mặc định là 0.1
Hình 3.12 Vector đặc trưng cho việc huấn luyện học để xếp hạng
Tiến hành thu thập dữ liệu lịch sử truy vấn tìm kiếm và lịch sử click của người dùng trong khoảng thời gian từ 90 đến 180 ngày
Kết quả của quá trình huấn luyện là mô hình đã được tối ưu hóa, có thể là Cây hồi quy, Cây quyết định tăng cường độ dốc hoặc trọng số tuyến tính đơn giản Những mô hình này sử dụng các đặc trưng cơ bản và áp dụng các thuật toán như SVM hoặc hồi quy tuyến tính để đạt được hiệu suất cao trong dự đoán.
Sau khi huấn luyện bằng thuật toán SVM, chúng tôi đã thu được một kết quả trọng số cho các đặc trưng cơ bản Để tối ưu hóa và dễ dàng sử dụng dịch vụ cá nhân hóa như một dịch vụ bên ngoài, chúng tôi lựa chọn thuật toán SVM và chuyển đổi kết quả huấn luyện thành các giá trị boosting cho các thuộc tính của tài liệu trong hệ thống tìm kiếm.
3.3.3 Request routing/forwarding và Personalized search Điều hướng/chuyển tiếp yêu cầu (Request routing/forwarding) thực hiện phân tích và chỉnh sửa các parameters và body của yêu cầu để chuyển tiếp yêu cầu đến API service hoặc chỉ mục tìm kiếm tương ứng
Khi có yêu cầu tìm kiếm cá nhân hóa, kết quả tìm kiếm sẽ được chuyển đến hệ thống cá nhân hóa để tiến hành xếp hạng lại và sắp xếp lại các kết quả.
Hệ thống thực hiên các bước sau:
To retrieve boosting values after the training process, call the Personalization Search API at the endpoint: https://.peerius.com/tracker/api/v1_4/search/personalisation/attributes An example of the response will be provided.
"personalisationAttributesId": "1247795301|GM tOFrxV6NGv2zNmkwzfaQ",
• Xây dựng lại truy vấn tìm kiếm dựa trên các giá trị boosting do Personalization Search API trả ra post test/_search {
"query_string": { "query": "some query string here" }
"filter": { "term": { "availability": "in stock"
"boost_mode": "multiply", "score_mode": "avg"
Hình 3.14 Sơ đồ hoạt động Request routing/forwarding
Thiết kế Stream service và Ingest Function
Trong hệ thống tìm kiếm, quá trình lập chỉ mục tiêu tốn nhiều tài nguyên xử lý và có độ phức tạp cao Thời gian chạy lâu có thể dẫn đến hiện tượng thắt cổ chai và nghẽn tiến trình, gây khó khăn cho hệ thống trong việc phục vụ các yêu cầu khác, đặc biệt là yêu cầu tìm kiếm.
Cần thiết phải thiết kế một hệ thống có khả năng tạm thời phong tỏa các yêu cầu lập chỉ mục, chuyển hướng chúng đến các vùng lưu trữ tạm thời, và điều chỉnh lưu lượng tài liệu lập chỉ mục được chấp nhận dựa trên mức độ sử dụng hiện tại của hệ thống.
Hình 3.15 Sơ đồ hoạt động Stream service
The stream service is designed to meet specific demands, including indexing, tracking, and bulk deletion requests, which are stored in an event store awaiting processing by Elasticsearch The Ingest Function is a serverless service that receives events from the event store to handle and forward requests or actions to other services Additionally, the Ingest Function can adjust data intake (throttle) based on the current load of the backend processing services.
Hình 3.16 Sơ đồ hoạt động Ingest Function
Thiết kế Runner (Crawler)
Runner là dịch vụ kiểm tra cài đặt trình thu thập dữ liệu (crawler) và bộ hẹn giờ thu thập dữ liệu, đồng thời thực hiện thu thập dữ liệu từ các nguồn bên ngoài Mỗi tài khoản khách hàng sẽ được tạo một “connector” riêng để khởi tạo các trình thu thập cho từng nguồn dữ liệu khác nhau.
Các cài đặt thu thập dữ liệu của khách hàng được lưu trữ trong một chỉ mục đặc biệt của cụm ES, với "connector" liên tục theo dõi các cài đặt này và khởi động trình thu thập (crawler) khi cần thiết.
Crawler là một thành phần của Runner, có chức năng duyệt toàn bộ nội dung trên web, phân tách các đường dẫn con (child links) và phân tích nội dung từ nhiều định dạng khác nhau như HTML, XML, Atom và sitemaps Nó cũng thực hiện việc phân tích tệp robots.txt và sau đó tạo, cập nhật hoặc xóa các tài liệu tương ứng trong chỉ mục của Elasticsearch (ES).
Hình 3.17 Sơ đồ hoạt động Runner
Thiết kế Elasticseach cluster
Để tối ưu hóa khả năng xử lý, mở rộng và phân tán của Elasticsearch (ES), việc phân loại rõ ràng từng server ES theo loại node là rất quan trọng.
Theo đó, cụm ES sẽ có 3 kiểu server ứng với 3 node type của ES:
Master node bao gồm ba máy chủ Elasticsearch (ES) được cấu hình chỉ để chạy master node, với số lượng không thay đổi trong quá trình vận hành Trong số ba master node, một node sẽ được bầu chọn làm leader, trong khi hai node còn lại đóng vai trò dự phòng Nếu leader gặp sự cố, hệ thống sẽ tự động chuyển giao quyền lãnh đạo cho một trong các master node dự phòng còn lại.
Data node là một Azure scale set, ban đầu bao gồm 3 node Các node này lưu trữ dữ liệu của Elasticsearch (ES) và có khả năng tự động phân bổ cũng như phân phối dữ liệu một cách đồng đều khi thêm hoặc giảm số lượng data node.
Client node là một Azure scale set với ba node mặc định, có khả năng mở rộng thành nhiều node giống hệt nhau Đây là dạng stateless không chứa dữ liệu, chủ yếu đảm nhiệm vai trò điều hướng, xử lý yêu cầu và tổng hợp kết quả từ master node và data node Tất cả yêu cầu từ các dịch vụ khác đến ES sẽ được thiết kế để gửi tới các client node, với một load balancer đứng phía trước để cân bằng tải và tạo ra một endpoint duy nhất cho cụm ES Do đó, client node cần có cấu hình phần cứng cao hơn để đáp ứng yêu cầu này.
Phiên bản ES được sử dụng trong luận văn này đã được mở rộng với các plugin, dựa trên tài liệu phát triển plugin của ES, nhằm bổ sung một số tính năng mới.
• Thống kê tìm kiếm (Search statistics)
• Bổ sung bộ phân tích cho nhiều ngôn ngữ (add more Analysis)
• Bổ sung Admin Index chứa các metadata, cài đặt của khách hàng
Hình 3.18 Sơ đồ thiết kế Elasticseach cluster
KẾT QUẢ THỬ NGHIỆM VÀ ĐÁNH GIÁ
Triển khai hệ thống thử nghiệm
The backend system is a search service deployed on the Microsoft Azure platform, utilizing a CI/CD process It employs Octopus Deploy to automate testing and facilitate deployment across various states.
• Xác thực, đăng ký, quản lý người đăng ký tài khoản dịch vụ tìm kiếm
• Lưu trữ và lập chỉ mục các tài liệu mà client gửi về
• Kết nối tới các services khác bên ngoài dịch vụ tìm kiếm
The frontend connects to the search service using the default Net API Client, integrated with the Episerver CMS/Commerce Developer version to create a test dataset.
• Kết nối và tương tác với Backend
• Tạo DB và dữ liệu thử nghiệm
• Cung cấp các thao tác sử dụng thông thường của người dùng, các thao tác tìm kiếm và lập chỉ mục tìm kiếm, tương tác với Backend
Hình 4.1 Kiến trúc hệ thống tìm kiếm triển khai thử nghiệm trên Azure
For optimal performance in Azure, the following VM and VMSS SKUs are recommended: For the Elasticsearch (ES) master node, utilize 3 Standard_F16s nodes with 16 vCPUs, 32 GiB memory, 32 GiB SSD OS storage, and 120 GiB log storage The ES client node should consist of 3 Standard_D8s_v3 nodes featuring 8 vCPUs, 32 GiB memory, 32 GiB SSD OS storage, and 120 GiB log storage For the ES data node, deploy 6 Standard_D16s_v3 nodes equipped with 16 vCPUs, 64 GiB memory, 32 GiB SSD OS storage, 256 GiB SSD data storage, and 120 GiB log storage The proxy requires 3 Standard_D4s_v3 nodes with 4 vCPUs, 16 GiB memory, 32 GiB SSD OS storage, and 120 GiB log storage For the runner, use Standard_F2s_v2 with 2 vCPUs, 4 GiB memory, 16 GiB SSD OS storage, and 120 GiB log storage Finally, for Kubernetes (K8S), ensure a minimum of 2048 MiB memory, at least 1 CPU, and enable autoscaling.
• CPU: Intel Core I7 4700MQ/7700, 4 cores, 8 threads
Thử nghiệm và kết quả
4.2.1 Lập chỉ mục nội dung website hiện tại
• Tạo một cms/commerce website có hỗ trợ search client (trong thử nghiệm này sử dựng bộ Episerver CMS/Commerce)
• Tạo 1,000+ và 100,000+ contents/items có thể được index
• Tiến hành index toàn bộ website và tính toán thời gian thực hiện
Hình 4.2 Giao diện website thử nghiệm
Hình 4.3 Kết quả 1 lần index toàn bộ website
Thống kê thời gian thực hiện thử nghiệm:
Bảng 4.1 Thống kê thời gian lập chỉ mục nội bộ trang web
4.2.2 Lập chỉ mục nội dung bên ngoài
• Tạo một cms/commerce website có hỗ trợ search client (trong thử nghiệm này sử dựng bộ Episerver CMS/Commerce)
• Tạo một crawler job với mục tiêu là 1 website bên ngoài với số lượng content vào khoảng 500 và 7000 items
• Tiến hành chạy crawler job
Hình 4.4 Kết quả thử nghiệm crawler
Thống kê thời gian thực hiện thử nghiệm:
Bảng 4.2 Thông kê thời gian lập chỉ mục bên ngoài
• Tạo một cms/commerce website trên Azure, có hỗ trợ search client (trong thử nghiệm này sử dựng bộ Episerver CMS/Commerce)
• Lập chỉ mục dữ liệu của website trên
• Sử dụng k6.io – một công cụ kiểm tra tải và hiệu suất dich vụ – để tạo kịch bản và tiến hành kiểm tra
• Kịch bản test: mô phỏng 2500 người dùng từ 6 địa điểm khác nhau truy cập liên tục tới website và có sử dụng chức năng tìm kiếm
Hình 4.5 Kết quả thử nghiệm trên k6.io
Hình 4.6 Thống kê truy cập trên Kibana
• Thời gian thử nghiệm: 50 phút
• Tổng số truy cập tới website: 252239
• Số truy cập trung bình trong 1 giây (RPS): 83
• Tổng số truy vấn tìm kiếm: 96534
• Số truy vấn tìm kiếm trung bình trong 1 giây (QPS): 32.2
• Đỗ trễ truy vấn tìm kiếm trung bình: 39ms
4.2.4 Cá nhân hóa tìm kiếm
• Tạo một cms/commerce website, có hỗ trợ search client (trong thử nghiệm này sử dựng bộ Episerver CMS/Commerce)
• Cài đặt các thống số cho dịch vụ Personalization
• Lập chỉ mục dữ liệu của website trên
• Tiến hành tìm kiếm, thử nghiệm truy cập vào 1 kết quả tìm kiếm ngẫu nhiên
• So sánh danh sách kết quả tìm kiếm ban đầu và sau khi truy cập vào 1 kết quả tìm kiếm
Hình 4.7 Kết quả tìm kiếm ban đầu
Hình 4.8 Kết quả tìm kiếm sau khi truy cập vào một số trang ngẫu nhiên
Khi so sánh kết quả của hai lần tìm kiếm, chúng ta nhận thấy rằng kết quả thứ 5 và thứ 6 đã được nâng lên vị trí thứ 2 và thứ 3 trong các lần tìm kiếm tiếp theo Điều này cho thấy các trang này đã từng được người dùng truy cập, và hệ thống đã theo dõi để cá nhân hóa các lần tìm kiếm sau.
