Sự tiến hóa của tính năng "More Like This": Từ so khớp từ khóa đến tìm kiếm ngữ nghĩa

Trong nhiều kịch bản tìm kiếm, người dùng thường không bắt đầu từ một ô truy vấn rỗng, mà từ một kết quả đã có sẵn. Một người đọc mở một bài báo và muốn tìm tài liệu liên quan. Một người mua hàng xem thẻ sản phẩm và tìm kiếm các lựa chọn thay thế tương tự. Một kỹ sư hỗ trợ điều tra một sự cố và muốn xem các trường hợp trước đó có cùng triệu chứng. Trong tất cả các tình huống này, người dùng đã có một tài liệu liên quan làm điểm khởi đầu.

Kịch bản này truyền thống được gọi là More Like This (MLT): một chức năng để tìm các tài liệu tương tự với tài liệu đã chọn. Bài viết này sẽ đi sâu vào sự tiến hóa của MLT, từ phương pháp so khớp từ khóa cổ điển đến các kỹ thuật tìm kiếm vector hiện đại.

Sự tiến hóa của More Like This

More Like This (MLT) cổ điển hoạt động như thế nào?

Cách tiếp cận MLT cổ điển, hay tìm kiếm tài liệu tương tự, dựa trên việc so sánh các kết quả khớp về mặt văn bản (lexical). Quy trình thường diễn ra như sau:

1. Hệ thống tìm kiếm lấy tài liệu nguồn.
2. Phân tích văn bản của nó.
3. Chọn các thuật ngữ mang tính thông tin.
4. Xây dựng một truy vấn từ các thuật ngữ đó.
5. Tìm kiếm các tài liệu có tập từ khóa tương tự.
6. Trả về danh sách các tài liệu tương tự.

Về mặt nội bộ, phương pháp này sử dụng các cơ chế tìm kiếm toàn văn quen thuộc như TF-IDF hoặc BM25, tần suất thuật ngữ, từ dừng (stopwords), và các giới hạn tần suất tài liệu. Đây là một cơ chế tìm kiếm đầy đủ, không chỉ là một yếu tố giao diện, được sử dụng rộng rãi cho các bài viết liên quan, sản phẩm, phát hiện trùng lặp và cơ sở kiến thức nội bộ.

Điểm mạnh của phương pháp từ vựng (Lexical)

MLT từ vựng hoạt động tốt khi các từ khóa cụ thể, mã định danh và các công thức ổn định là quan trọng. Ví dụ bao gồm:

• Mã lỗi (error codes).
• Mã SKU sản phẩm.
• Số hiệu phụ tùng.
• Tên hàm.
• Stack traces.
• Các văn bản pháp lý.

Lý do là sự khớp chính xác ở đây rất quan trọng. Nếu hai báo cáo sự cố chứa cùng một mã lỗi hoặc stack trace, tìm kiếm toàn văn sẽ thấy sự khớp trực tiếp. Ví dụ, khi tìm kiếm vé hỗ trợ với mã ERR_404, MLT từ vựng sẽ nhanh chóng tìm thấy mọi lần xuất hiện của mã đó, trong khi tìm kiếm vector có thể trả về các vé mô tả vấn đề tương tự nhưng không giống hệt nhau.

Hơn nữa, MLT từ vựng rất rẻ để chạy. Chỉ mục đảo ngược (inverted index) đã có sẵn trong công cụ tìm kiếm, các bộ phân tích đã được cấu hình và thứ hạng đã hoạt động.

Hạn chế của phương pháp cổ điển

Hạn chế rõ ràng là: Nếu hai tài liệu mô tả cùng một thứ nhưng bằng những từ khác nhau, MLT từ vựng có thể thất bại trong việc liên kết chúng. Đồng nghĩa hoạt động không đồng đều. Cách diễn đạt khác (paraphrases) khó xử lý hơn. Tương đồng đa ngôn ngữ thường không khả dụng. Ví dụ, "rò rỉ bộ nhớ" (memory leak) và "tăng trưởng heap không giới hạn" (unbounded heap growth) có thể mô tả cùng một vấn đề, nhưng một bộ phân tích tiêu chuẩn sẽ thấy các token khác nhau.

Embeddings thay đổi cuộc chơi

Sử dụng embeddings — các biểu diễn dạng số của tài liệu — thay đổi nguyên tắc so sánh: thay vì so sánh từ ngữ, hệ thống so sánh các biểu diễn vector.

Một tài liệu không còn chỉ được biểu diễn dưới dạng tập hợp các thuật ngữ có trọng số. Nó có thể được lưu trữ dưới dạng một vector dày đặc. Các vector lân cận thường tương ứng với các tài liệu tương tự về ý nghĩa, ngay cả khi chúng được viết bằng những từ khác nhau.

Cách tiếp cận từ vựng tìm kiếm sự khớp bằng từ và thuật ngữ, trong khi tìm kiếm embedding nhìn vào sự gần gũi của các biểu diễn vector tài liệu. Cách đầu tiên tối ưu cho các khớp chính xác như mã lỗi và SKU. Cách thứ hai tìm thấy các tài liệu gần gũi về mặt ngữ nghĩa, ngay cả khi chúng được diễn đạt khác nhau.

Điều này mở rộng phạm vi của loại tìm kiếm này. Bạn có thể so sánh không chỉ bài viết, mà còn cả sản phẩm, hình ảnh, đoạn mã, sự kiện người dùng hoặc các đoạn ngữ cảnh trong hệ thống RAG.

Trong thực tế, tìm kiếm từ vựng không biến mất. Các mã lỗi chính xác, SKU, tên, tham chiếu luật định vẫn được xử lý tốt hơn về mặt từ vựng. Đó là lý do các hệ thống sản xuất thường sử dụng tìm kiếm kết hợp (hybrid search): tìm kiếm toàn văn cung cấp các kết quả khớp chính xác, tìm kiếm vector thêm kết quả theo ý nghĩa, bộ lọc giới hạn không gian tìm kiếm, và xếp hạng lại (reranking) tinh chỉnh thứ tự cuối cùng.

MLT dưới dạng tra cứu vector từ chỉ mục

Nếu biểu diễn vector đã được tính toán trước cho một tài liệu và lưu trữ trong chỉ mục, MLT hiện đại có thể được mô tả đơn giản:

1. Lấy tài liệu nguồn.
2. Truy xuất biểu diễn vector đã tính toán trước của nó từ chỉ mục.
3. Tìm các vector gần nhất.
4. Trả về các tài liệu mà các vector đó thuộc về.

Đây vẫn là More Like This: người dùng bắt đầu từ một tài liệu và nhận được kết quả liên quan. Chỉ có phương pháp so sánh thay đổi. Thay vì trích xuất thuật ngữ, công cụ tìm kiếm sử dụng biểu diễn vector của tài liệu nguồn.

Trong Manticore Search, thao tác này có thể thực hiện trực tiếp ở mức công cụ tìm kiếm. Một ví dụ SQL tối thiểu trông như sau:

SELECT id, title, knn_dist()
FROM products
WHERE knn(embedding, 10, 123)
LIMIT 10;

Ở đây, embedding là trường chứa vector embedding đã tính toán trước, 123 là ID của tài liệu nguồn, và 10 là số lượng tài liệu gần nhất cần trả về. Hàm knn_dist() trả về khoảng cách giữa các vector: giá trị nhỏ hơn có nghĩa là gần gũi hơn về mặt ngữ nghĩa với tài liệu nguồn.

Tại sao tìm kiếm nên được xử lý trong công cụ tìm kiếm?

Bạn có thể triển khai kịch bản này trong ứng dụng: trước tiên lấy tài liệu, sau đó trích xuất vector của nó, rồi gửi một truy vấn KNN riêng, và cuối cùng kết hợp kết quả với bộ lọc. Tuy nhiên, cách tiếp cận đó làm phức tạp kiến trúc hệ thống.

Khi hệ thống tìm kiếm tự thực hiện việc tra cứu, quy trình sẽ ngắn gọn hơn:

1. Ứng dụng chuyển ID của tài liệu nguồn.
2. Hệ thống tìm kiếm tìm thấy biểu diễn vector đã tính toán trước trong chỉ mục.
3. Hệ thống tìm kiếm chạy tìm kiếm láng giềng gần nhất (KNN) hoặc biến thể xấp xỉ của nó (ANN).
4. Hệ thống tìm kiếm trả về các tài liệu tìm thấy với cùng các bộ lọc truy cập và siêu dữ liệu.

Lợi ích của cách tiếp cận này bao gồm:

• Ít yêu cầu liên dịch vụ hơn từ ứng dụng.
• Các vector lớn không cần phải được gửi qua các API bên ngoài.
• Bộ lọc stays gần với tìm kiếm.
• Kết quả dễ dàng tái tạo và gỡ lỗi hơn.
• Ứng dụng không cần một lớp bổ sung để tính toán sự tương tự — mọi thứ chạy bên trong công cụ tìm kiếm.

Sự tiến hóa của MLT

Sự tiến hóa của MLT có thể được mô tả như sau:

• Những năm 2000: MLT chủ yếu dựa vào phân tích từ vựng, TF-IDF, BM25 và sự trùng lặp thuật ngữ.
• Những năm 2010: Word2Vec và GloVe xuất hiện và được sử dụng rộng rãi, giúp xây dựng embeddings ngữ nghĩa của từ và văn bản.
• Đầu những năm 2020: FAISS và các thư viện ANN tương tự cho phép chạy tìm kiếm vector hiệu quả ngay cả trên các tập dữ liệu rất lớn.
• Giữa những năm 2020: RAG, đề xuất và tìm kiếm từ một đối tượng hiện có khiến việc tra cứu bằng vector lưu trữ trở thành một kịch bản sản phẩm phổ biến.

Kết luận

More Like This đã chuyển từ tìm kiếm hoàn toàn dựa trên từ vựng sang các giải pháp kết hợp (hybrid) kết hợp cơ chế từ vựng, vector và lọc.

Khái niệm cốt lõi vẫn giữ nguyên: người dùng chọn một tài liệu nguồn, và hệ thống tìm các tài liệu liên quan đến nó, tính đến cả sự tương tự về từ vựng và ngữ nghĩa. Các hệ thống sản xuất vẫn cần tìm kiếm chính xác cho mã định danh, mã lỗi và các khớp nghiêm ngặt khác, đồng thời cần giám sát chất lượng tìm kiếm để đảm bảo độ chính xác và độ phủ.