Khai thác GPT-3 cho các giải pháp tìm kiếm được cải thiện

Các ứng dụng hiện đại thường kết hợp các giải pháp tìm kiếm để cho phép người dùng truy cập nhanh nội dung hiện có theo yêu cầu. Thật khó để hình dung bất kỳ chức năng nào khác có thể truy xuất thông tin này một cách hiệu quả, làm cho tìm kiếm trở thành một tính năng thiết yếu trong hầu hết các ứng dụng.

Tùy chọn giải pháp tìm kiếm tùy chỉnh

Đồng thời, ngay cả khi nhu cầu truy vấn và tìm kiếm là rất phổ biến, các ứng dụng khác nhau có những cách tiếp cận khác nhau đáng kể.

Trong hầu hết các trường hợp, các công ty vẫn ở mức tìm kiếm rất cơ bản bằng cách truy vấn trực tiếp cơ sở dữ liệu OLTP. Yêu cầu có thể giống như sau: SELECT id, title FROM, entities WHERE, description LIKE '%bow% .

Tuy nhiên, thường xuyên hơn, chúng được biểu diễn trong các cấu trúc nối bảng phức tạp, nhiều cấp độ, không thể đọc được, chậm và nguyên thủy. Chúng không thể hiểu ngữ cảnh, yêu cầu nhiều tùy chỉnh và rất khó triển khai đúng cách.

Mặc dù có thể cải thiện thời gian thực hiện truy vấn thông qua các chế độ xem cụ thể hóa, bộ nhớ đệm truy vấn và các kỹ thuật khác, nhưng độ phức tạp được thêm vào dẫn đến độ trễ đáng kể giữa các cập nhật chính và kết quả tìm kiếm nhất quán.

Các giải pháp thay thế hiệu quả hơn cho các giải pháp tìm kiếm dựa trên cơ sở dữ liệu nguyên thủy có thể tạo thành các công cụ tìm kiếm nguồn mở như Apache Lucene, Apache Solr, Elaticsearch, Sphinx, MeiliSearch, Typesense, v.v.

Chúng có xu hướng tương đối nhanh hơn và tốt hơn nhiều trong việc xử lý các truy vấn phức tạp và làm việc với các bộ lọc. Nhưng một khi các công cụ tìm kiếm này được so sánh với các đối tác như Google Tìm kiếm hoặc DuckDuckGo, rõ ràng là các giải pháp nguồn mở không thể xây dựng ngữ cảnh tìm kiếm và phương thức truy vấn phù hợp — chúng không thể hiểu truy vấn nếu người dùng đưa ra yêu cầu tìm kiếm mơ hồ.

Trích xuất ý nghĩa từ truy vấn

Hãy tưởng tượng bạn chỉ đơn giản là không thể nhớ loại trái cây có múi màu vàng có vị chua đó được gọi là gì! Nhưng bạn muốn tìm kiếm ứng dụng cho một bài báo về cách trồng loại quả bí ẩn này. Làm thế nào để bạn đi về tìm kiếm đó?

Truy vấn của bạn có thể là “Cách trồng cam quýt chua vàng trong nhà”. Bất kỳ công cụ tìm kiếm nguồn mở nào đã nói ở trên có thể gặp khó khăn đáng kể để trả về các kết quả có liên quan cho truy vấn này, ngay cả khi cơ sở dữ liệu có chứa các bài báo về việc trồng “chanh”.

Đó là bởi vì việc trích xuất ý nghĩa từ một truy vấn là một nhiệm vụ ngôn ngữ tự nhiên và khó có thể giải quyết được nếu không có các thành phần AI. GPT-3 làm tốt nhiệm vụ này.

Ưu đãi OpenAI API nhúng dựa trên GPT-3 chuyển đổi văn bản ngôn ngữ tự nhiên thành một vectơ số dấu phẩy động. Phép nhúng về cơ bản là một không gian có chiều thấp trong đó các vectơ có chiều cao có thể được chuyển dịch. Trong trường hợp này, vectơ chiều cao là văn bản và chiều thấp là vectơ đầu ra có kích thước cố định. Khoảng cách giữa các vectơ thể hiện mức độ tương quan của chúng. Khoảng cách càng nhỏ thì tương quan càng cao. Bằng cách xác định lại văn bản dưới dạng biểu mẫu dựa trên vectơ, nhiệm vụ được giảm xuống thành vấn đề tìm kiếm ML cổ điển.

Lựa chọn mô hình phù hợp

Việc chuyển đổi văn bản tài liệu thành đại diện véc-tơ có thể diễn ra trong nền, trong khi việc véc-tơ hóa truy vấn tìm kiếm sẽ diễn ra trong thời gian chạy. Có một số dòng mô hình GPT-3 mà OpenAI cung cấp:

 text-search-ada-doc-001: 1024 text-search-babbage-doc-001: 2048 text-search-curie-doc-001: 4096 text-search-davinci-doc-001: 12288

Kích thước vectơ cao hơn dẫn đến nhiều thông tin được nhúng hơn và do đó, chi phí cũng cao hơn và tìm kiếm chậm hơn.

Tài liệu thường dài và truy vấn thường ngắn và không đầy đủ. Do đó, vector hóa của bất kỳ tài liệu nào khác đáng kể so với vector hóa của bất kỳ truy vấn nào khi xem xét mật độ và kích thước của nội dung. OpenAI biết điều đó và vì vậy họ cung cấp hai mô hình được ghép nối, -doc và -query :

 text-search-ada-query-001: 1024 text-search-babbage-query-001: 2048 text-search-curie-queryc-001: 4096 text-search-davinci-query-001: 12288

Điều quan trọng cần lưu ý là cả truy vấn và tài liệu đều phải sử dụng cùng một họ mô hình và có cùng độ dài của vectơ đầu ra.

tập dữ liệu mẫu

Có thể dễ dàng nhất để quan sát và hiểu sức mạnh của giải pháp tìm kiếm này thông qua các ví dụ. Đối với ví dụ này, chúng ta hãy vẽ trên Bộ dữ liệu phim TMDB 5000 chứa siêu dữ liệu về khoảng 5.000 phim từ TMDb. Chúng tôi sẽ xây dựng một giải pháp tìm kiếm chỉ dựa trên tài liệu phim chứ không phải đánh giá.

Tập dữ liệu chứa nhiều cột, nhưng quá trình véc tơ hóa của chúng tôi sẽ chỉ được xây dựng xung quanh các cột tiêu đề và tổng quan.

Ví dụ về bản ghi:

 Title: Harry Potter and the Half-Blood Prince Overview: As Harry begins his sixth year at Hogwarts, he discovers an old book marked as 'Property of the Half-Blood Prince', and begins to learn more about Lord Voldemort's dark past.

Hãy ánh xạ tập dữ liệu thành văn bản sẵn sàng để lập chỉ mục:

 datafile_path = "./tmdb_5000_movies.csv" df = pd.read_csv(datafile_path) def combined_info(row): columns = ['title', 'overview'] columns_to_join = [f"{column.capitalize()}: {row[column]}" for column in columns] return '\n'.join(columns_to_join) df['combined_info'] = df.apply(lambda row: combined_info(row), axis=1)

Quá trình nhúng rất đơn giản:

 def get_embedding(text, model="text-search-babbage-doc-001"): text = text.replace("\n", " ") return openai.Embedding.create(input = [text], model=model)['data'][0]['embedding'] get_embedding(df['combined_info'][0])

Khối mã này xuất ra một danh sách có kích thước bằng với các tham số mà mô hình đang vận hành, trong trường hợp text-search-babbage-doc-001 là 2048.

Một quy trình nhúng tương tự sẽ được áp dụng cho tất cả các tài liệu mà chúng tôi muốn tìm kiếm trên:

 df['combined_info_search'] = df['combined_info'].apply(lambda x: get_embedding(x, model='text-search-babbage-doc-001')) df.to_csv('./tmdb_5000_movies_search.csv', index=False)

Cột combined_info_search sẽ chứa biểu diễn véc-tơ của văn_bản tổ hợp.

Và, thật ngạc nhiên, đó đã là nó! Cuối cùng, chúng tôi đã sẵn sàng để thực hiện một truy vấn tìm kiếm mẫu:

 from openai.embeddings_utils import get_embedding, cosine_similarity def search_movies(df, query, n=3, pprint=True): embedding = get_embedding( query, engine="text-search-babbage-query-001" ) df["similarities"] = df.combined_info_search.apply(lambda x: cosine_similarity(x, embedding)) res = ( df.sort_values("similarities", ascending=False) .head(n) .combined_info ) if pprint: for r in res: print(r[:200]) print() return res res = search_movies(df, "movie about the wizardry school", n=3)

Đây là những kết quả chúng tôi nhận được:

 Title: Harry Potter and the Philosopher's StoneOverview: Harry Potter has lived under the stairs at his aunt and uncle's house his whole life. But on his 11th birthday, he learns he's a powerful wizard — with a place waiting for him at the Hogwarts School of Witchcraft and Wizardry. As he learns to harness his newfound powers with the help of the school's kindly headmaster, Harry uncovers the truth about his parents' deaths — and about the villain who's to blame. Title: Harry Potter and the Goblet of FireOverview: Harry starts his fourth year at Hogwarts, competes in the treacherous Triwizard Tournament and faces the evil Lord Voldemort. Ron and Hermione help Harry manage the pressure — but Voldemort lurks, awaiting his chance to destroy Harry and all that he stands for. Title: Harry Potter and the Prisoner of AzkabanOverview: Harry, Ron and Hermione return to Hogwarts for another magic-filled year. Harry comes face to face with danger yet again, this time in the form of an escaped convict, Sirius Black — and turns to sympathetic Professor Lupin for help.

Tổng quan về ' Harry Potter và Hòn đá phù thủy ' chứa các từ 'thầy phù thủy' và 'trường học' và xuất hiện đầu tiên trong kết quả tìm kiếm. Kết quả thứ hai không còn chứa từ 'school', nhưng vẫn giữ lại các từ gần với 'wizardry', 'Triwizard'. Kết quả thứ ba chỉ chứa một từ đồng nghĩa với 'wizardry' - ma thuật.

Tất nhiên, có vô số phim khác trong cơ sở dữ liệu này về trường học hoặc pháp sư (hoặc cả hai), nhưng những phim trên là những phim duy nhất được trả lại cho chúng tôi. Đây là bằng chứng rõ ràng rằng giải pháp tìm kiếm hoạt động và thực sự hiểu ngữ cảnh truy vấn của chúng tôi.

Chúng tôi đã sử dụng mô hình Babbage chỉ với 2048 tham số. Davinci có nhiều hơn sáu lần (12.288) tham số và do đó, có thể hoạt động tốt hơn đáng kể đối với các truy vấn có độ phức tạp cao.

Giải pháp tìm kiếm đôi khi có thể không tạo ra kết quả phù hợp với một số truy vấn. Ví dụ: truy vấn 'phim về phù thủy trong trường học' tạo ra:

 Title: Harry Potter and the Philosopher's StoneOverview: Harry Potter has lived under the stairs at his aunt and uncle's house his whole life. But on his 11th birthday, he learns he's a powerful wizard — with a place waiting for him at the Hogwarts School of Witchcraft and Wizardry. As he learns to harness his newfound powers with the help of the school's kindly headmaster, Harry uncovers the truth about his parents' deaths — and about the villain who's to blame. Title: Dumb and Dumberer: When Harry Met LloydOverview: This wacky prequel to the 1994 blockbuster goes back to the lame-brained Harry and Lloyd's days as classmates at a Rhode Island high school, where the unprincipled principal puts the pair in remedial courses as part of a scheme to fleece the school. Title: Harry Potter and the Prisoner of AzkabanOverview: Harry, Ron and Hermione return to Hogwarts for another magic-filled year. Harry comes face to face with danger yet again, this time in the form of an escaped convict, Sirius Black — and turns to sympathetic Professor Lupin for help.

Bạn có thể thắc mắc 'Dumb and Dumberer: When Harry Met Lloyd' đang làm gì ở đây? Rất may, sự cố này không được sao chép trên các tham số có nhiều tham số hơn.

Tính khoảng cách giữa truy vấn và tài liệu

Kết quả tìm kiếm phải bao gồm các tài liệu được sắp xếp theo thứ tự giảm dần theo mức độ liên quan. Để đạt được điều này, chúng ta nên biết khoảng cách giữa truy vấn hiện tại và từng tài liệu. Độ dài càng ngắn, đầu ra tương đối phù hợp hơn. Sau đó, sau khi đạt được phạm vi tiếp cận tối đa đã xác định, chúng ta nên ngừng xem xét mức độ liên quan của các tài liệu còn lại.

Trong ví dụ nói trên, chúng tôi đã sử dụng đồng dạng cosin để tính khoảng cách do không gian vectơ có nhiều chiều. Với mô hình bắp cải, chúng ta có 2048 tham số.

Các thuật toán tính toán khoảng cách có xu hướng thể hiện sự tương đồng (khác biệt) này giữa truy vấn và tài liệu bằng một số duy nhất. Tuy nhiên, chúng ta không thể dựa vào khoảng cách Euclide vì lời nguyền của chiều - khoảng cách sẽ quá giống nhau. Điều này là do khoảng cách Euclide trở nên rất phi thực tế ngoài khoảng bảy chiều - tại thời điểm này, khoảng cách rơi vào cùng một nhóm và trở nên gần như giống hệt nhau.

Nếu muốn, bạn có thể kiểm tra kho lưu trữ kết quả tại đây:

Ngoài ra, bạn có thể chơi với nó trong Google Colab tại đây .

Độ phức tạp về thời gian

Chúng tôi đã sử dụng phương pháp brute force để sắp xếp các tài liệu. Hãy xác định:

● n: số điểm trong tập dữ liệu huấn luyện

● d: chiều dữ liệu

Độ phức tạp thời gian tìm kiếm cho các giải pháp vũ phu là O(n * d * n * log(n)) . Tham số d phụ thuộc vào mô hình (trong trường hợp của Babbage, nó bằng 2048) trong khi chúng ta có khối O(nlog(n)) do bước sắp xếp.

Ở giai đoạn này, điều quan trọng là phải nhắc nhở bản thân rằng các mô hình nhỏ hơn sẽ nhanh hơn và rẻ hơn. Chẳng hạn, trong bước tính toán độ tương tự của trường hợp tìm kiếm, mô hình Ada nhanh hơn hai lần, trong khi mô hình Davinci chậm hơn sáu lần.

Tính toán độ tương tự cosine giữa truy vấn và 4803 tài liệu có kích thước 2048 mất 1260 ms trên M1 Pro của tôi. Trong triển khai hiện tại, thời gian cần thiết để tính toán sẽ tăng tuyến tính với tổng số tài liệu. Đồng thời, phương pháp này hỗ trợ song song hóa tính toán.

Các giải pháp thay thế cho giải pháp vũ phu

Trong các giải pháp tìm kiếm, các truy vấn phải được hoàn thành càng nhanh càng tốt. Và mức giá này thường được trả cho thời gian đào tạo và lưu trữ trước. Chúng ta có thể sử dụng các cấu trúc dữ liệu như cây kd, cây r hoặc cây bóng. Hãy xem xét bài viết từ Hướng tới khoa học dữ liệu về phân tích độ phức tạp tính toán của các phương pháp này: Tất cả chúng đều dẫn đến độ phức tạp tính toán gần bằng O(k * log(n)) , trong đó k là số phần tử mà chúng tôi muốn trả về trong một đợt.

Cây Kd, cây bóng và cây r tạo thành cấu trúc dữ liệu được sử dụng để lưu trữ và tìm kiếm hiệu quả các điểm trong không gian N chiều, chẳng hạn như các vectơ ý nghĩa của chúng ta.

Kd và cây bóng là các cấu trúc dữ liệu dựa trên cây sử dụng lược đồ phân vùng nhị phân, lặp lại để phân chia không gian thành các vùng, với mỗi nút trong cây đại diện cho một vùng con. Cây Kd đặc biệt hiệu quả trong việc tìm kiếm các điểm trong một phạm vi cụ thể hoặc tìm hàng xóm gần nhất với một điểm nhất định.

Tương tự, cây r cũng được sử dụng để lưu trữ các điểm trong không gian N chiều, tuy nhiên, chúng hiệu quả hơn nhiều trong việc tìm kiếm các điểm trong một vùng cụ thể hoặc tìm tất cả các điểm trong một khoảng cách nhất định của một điểm nhất định. Điều quan trọng là, r-tree sử dụng sơ đồ phân vùng khác với kd tree và ball tree; chúng chia không gian thành 'hình chữ nhật' thay vì phân vùng nhị phân.

Việc triển khai cây nằm ngoài phạm vi của bài viết này và các triển khai khác nhau sẽ dẫn đến kết quả tìm kiếm khác nhau.

thời gian truy vấn

Có lẽ, nhược điểm đáng kể nhất của giải pháp tìm kiếm hiện tại là chúng ta phải gọi API OpenAI bên ngoài để truy xuất vectơ nhúng truy vấn. Cho dù thuật toán của chúng tôi có thể tìm thấy những người hàng xóm gần nhất nhanh đến mức nào, thì vẫn cần phải thực hiện bước chặn tuần tự.

 Text-search-babbage-query-001 Number of dimensions: 2048 Number of queries: 100 Average duration: 225ms Median duration: 207ms Max duration: 1301ms Min duration: 176ms

 Text-search-ada-query-002 Number of dimensions: 1536 Number of queries: 100 Average duration: 264ms Median duration: 250ms Max duration: 859ms Min duration: 215ms

 Text-search-davinci-query-001 Number of dimensions: 12288 Number of queries: 100 Average duration: 379ms Median duration: 364ms Max duration: 1161ms Min duration: 271ms

Nếu lấy trung vị làm điểm tham chiếu, chúng ta có thể thấy rằng ada-002 chậm hơn +28% và davinci-001 chậm hơn +76%.

Hạn chế của nhúng tìm kiếm GPT-3

Liên quan đến Bài viết của Nils Reimer về so sánh mô hình nhúng văn bản dày đặc , chúng tôi có thể kết luận rằng GPT-3 không mang lại hiệu suất hoặc chất lượng đầu ra vượt trội và yêu cầu sự phụ thuộc vào API bên ngoài khá chậm. GPT-3 có khả năng hỗ trợ đầu vào lên tới 4096 mã thông báo (khoảng 3072 từ), tuy nhiên, không có dịch vụ cắt bớt thông qua API và việc cố mã hóa văn bản dài hơn 4096 mã thông báo sẽ dẫn đến lỗi. Do đó, trách nhiệm của người dùng — bạn — là xác định lượng văn bản thực sự có thể được mã hóa.

Ngoài ra, chi phí đào tạo tương đối cao với OpenAI.

Ngoài ra, bạn có thể cân nhắc thử TAS-B hoặc multi-qa-mpnet-base-dot-v1 .

Tìm kiếm hàng xóm gần nhất trong Elaticsearch

Elaticsearch 8.0 hỗ trợ tìm kiếm lân cận gần nhất (ANN) hiệu quả có thể được sử dụng để giải quyết các vấn đề nghiêm trọng của chúng tôi nhanh hơn bất kỳ KNN tuyến tính nào có thể. Elaticsearch 8.0 sử dụng một thuật toán ANN có tên là Hierarchical Navigable Small World graphs (HNSW) để tổ chức các vectơ thành các biểu đồ dựa trên sự giống nhau. Thử nghiệm trên tập dữ liệu gồm 10 triệu vectơ được nhúng, chúng tôi đã đạt được hiệu suất ấn tượng là 200 truy vấn mỗi giây với ANN trên một máy tập trung vào điện toán, trong khi chỉ có 2 truy vấn mỗi giây khi sử dụng KNN. Cả hai đều được cung cấp bởi Elaticsearch.

Theo Tìm kiếm đàn hồi bài đăng trên blog về bản phát hành ANN và điểm chuẩn cho các tìm kiếm vector dày đặc , chi phí của hiệu suất này là 5% thu hồi. Điều này có nghĩa là khoảng 1 trong 10 vectơ gần nhất được tìm thấy không thực sự tương đối. Chúng tôi đã áp dụng một phương pháp kết hợp để cải thiện kết quả này: Yêu cầu k+l thay vì k và áp dụng bộ lọc để loại bỏ các giá trị ngoại lệ. Đáng buồn thay, không có khả năng phân trang. Vì vậy, phương pháp này sẽ chỉ hoạt động trong một số trường hợp sử dụng.

Như bạn hy vọng đã thấy, GPT-3 Embeddings không phải là giải pháp hoàn hảo cho bất kỳ và tất cả các vấn đề tìm kiếm do độ phức tạp trong lập chỉ mục, chi phí cũng như độ phức tạp tính toán cao của hoạt động tìm kiếm, thậm chí là gần đúng. Tuy nhiên, GPT-3 Embeddings vẫn là một lựa chọn tuyệt vời cho bất kỳ ai đang tìm kiếm một xương sống mạnh mẽ cho giải pháp tìm kiếm với yêu cầu lập chỉ mục khiêm tốn và truy vấn không thường xuyên.

Hơn nữa, cũng đáng nói thêm rằng Microsoft gần đây __ đã thông báo __rằng công cụ tìm kiếm Bing hiện sử dụng phiên bản nâng cấp mới của GPT 3.5, được gọi là 'Prometheus' và ban đầu được phát triển cho tìm kiếm. Theo thông báo, mô hình ngôn ngữ Prometheus mới cho phép Bing tăng mức độ liên quan, chú thích chính xác hơn các đoạn trích, cung cấp kết quả mới hơn, hiểu vị trí địa lý và cải thiện bảo mật. Điều này có thể mở ra những khả năng mới cho việc sử dụng mô hình ngôn ngữ tự hồi quy cho các giải pháp tìm kiếm mà chúng tôi chắc chắn sẽ theo dõi trong tương lai.

Người giới thiệu:

1. Mô hình nhúng mới và cải tiến
2. độ phức tạp tính toán hàng xóm gần nhất k
3. scipy.spatial.KDTree
4. cây kd
5. Nhúng văn bản OpenAI GPT-3 — Thực sự là một công nghệ tiên tiến mới trong nhúng văn bản dày đặc?
6. Giới thiệu tính năng tìm kiếm hàng xóm gần nhất trong Elaticsearch 8.0