Và nói lời tạm biệt với tìm kiếm dựa trên từ khóa  Trong khi GPT 3+ hoặc ChatGPT, kỹ thuật nhanh chóng dễ hiểu hơn bằng trực giác. Với nhiều hướng dẫn và ví dụ có sẵn trên web và phương tiện truyền thông xã hội. Như là   Các phương pháp hay nhất của OpenAI để thúc đẩy kỹ thuật   Danh sách lời nhắc ChatGPT  Các phần nhúng, yêu cầu lập trình và ít được hiểu hơn, do các hành vi phản trực giác khác nhau về cách thức hoạt động của nó. Tuy nhiên, là một công cụ cực kỳ mạnh mẽ để tìm kiếm hoặc được sử dụng cùng với các mô hình dựa trên văn bản hiện có, cho nhiều trường hợp sử dụng khả thi khác.  Các nhúng được cho là một công cụ mạnh mẽ không kém, trong bộ công cụ AI, dành cho các mô hình hướng dẫn. Do khả năng xử lý các tìm kiếm trên các từ và câu khác nhau hoặc thậm chí toàn bộ ngôn ngữ. Tập trung vào việc tìm kiếm tài liệu liên quan cho bất kỳ truy vấn nào.  Ví dụ: nó có thể được sử dụng để tăng sức mạnh tìm kiếm và trả lời từ tài liệu bằng tiếng Anh. Bằng tiếng Anh ...   Hay tiếng Nhật...   Hoặc bất kỳ ngôn ngữ nào khác mà mô hình AI hỗ trợ.  Nhúng vectơ có thể được sử dụng để tìm kiếm hoặc các tác vụ khác như trả lời câu hỏi, phân loại văn bản và tạo văn bản.  Lưu ý rằng bài viết này tập trung vào khía cạnh tìm kiếm, quá trình trả lời là trong một bài viết tiếp theo.  Nhúng véc-tơ là gì?  Để tạo nhúng vectơ, người ta sẽ sử dụng mô hình AI nhúng, mô hình này chuyển đổi bất kỳ văn bản nào (một tài liệu lớn, một câu hoặc thậm chí một từ), thành một "mảng chiều N", được gọi là vectơ.  Ví dụ: một câu như  How do I write a UI test script with Uilicious?  Có thể được chuyển đổi thành một mảng (được gọi là vectơ) thông qua   :  mô hình nhúng văn bản OpenAI-ada-002 [0.010046141, -0.009800113, 0.014761676, -0.022538893, ... an a 1000+ numbers]  Vectơ này thể hiện sự hiểu biết tóm tắt của mô hình AI về văn bản. Đây có thể được coi là một "bản tóm tắt N từ" được viết bằng ngôn ngữ mà chỉ AI mới có thể hiểu được.  Trường hợp các tài liệu liên quan sẽ có khoảng cách gần nhau, dựa trên sự hiểu biết của AI về tài liệu (chứ không chỉ văn bản của nó).  Đây là một bước nhảy vọt vượt xa các tìm kiếm từ khóa đơn giản của các công cụ tìm kiếm cổ điển, vì nó có thể xử lý các biến thể trong cấu trúc câu và ngôn ngữ (miễn là mô hình AI được đào tạo để hiểu ngôn ngữ đã nói).  Lấy ví dụ sau đây làm ví dụ giả thuyết, được đơn giản hóa quá mức không chính xác thành không gian 2 chiều để dễ hiểu hơn:   Có thể được trình bày trực quan như sau trong không gian 2D.  Ví dụ: D1,2,3 là tất cả các tài liệu liên quan đến cách sử dụng Uilicious theo nhiều cách khác nhau và được nhóm lại với nhau trong một cụm  D4 và D5, chỉ đơn giản là các liên kết và không có giá trị cố hữu nào ngoài giá trị đó, được nhóm riêng trong một cụm khác.  Ngoài ra, D1 & D2 còn được nhóm lại với nhau, vì chúng nói về các lệnh thử nghiệm Uilicious, sử dụng ngôn ngữ thử nghiệm dựa trên JavaScript rất riêng của chúng tôi.  Mặc dù D3 được nhóm riêng, vì nó liên quan đến việc sử dụng trực tiếp giao thức trình điều khiển web trên cơ sở hạ tầng của chúng tôi, dành cho trường hợp sử dụng và đối tượng khác.  Tương tự, đối với Q1 và Q2, mặc dù có sự khác biệt lớn về cấu trúc câu và ngôn ngữ, nhưng vì về cơ bản là cùng một câu hỏi nên hai câu hỏi được nhóm lại với nhau.  Ngoài ra, mặc dù về mặt kỹ thuật, câu hỏi có thể được diễn giải theo cả hai cách (sử dụng tập lệnh kiểm tra Uilicious hoặc giao thức trình điều khiển web), bởi vì câu hỏi ngụ ý việc sử dụng tập lệnh kiểm tra Uilicious trên trình quản trị web, vị trí của nó "gần" hơn với D1 & D2 và xa hơn D3.  Do đó, mặc dù có sự trùng lặp lớn về từ khóa, nhưng các sắc thái này trong các nhóm được AI ghi lại trong các phần nhúng. Làm nổi bật sự khác biệt đặc biệt của nó đối với tìm kiếm từ khóa  Tuy nhiên, trên thực tế, thay vì một mảng 2 chiều được đơn giản hóa quá mức mà con người có thể dễ dàng hiểu được, một phép nhúng có thể dễ dàng trở thành một mảng hơn 1.000 chiều. Mảng này là duy nhất cho mô hình AI cụ thể được sử dụng và không thể trộn lẫn với các phần nhúng của mô hình AI khác.   Lưu ý toán học: Toán chiều N không tương thích với toán 2/3D  Mặc dù các ví dụ 2 chiều đơn giản hóa rất tốt để hiểu khái niệm cấp cao về nhóm tương đối cho một câu hỏi (hoặc một quan điểm), nhưng nó không thể hiện chính xác một chiều N.  Do phép toán N chiều phức tạp, bạn có thể gặp các tình huống, trong đó A có thể ở gần B, B có thể ở gần C, nhưng A và C có thể được coi là ở xa nhau. Đó là một gotcha cực kỳ phản trực giác.  Khoảng cách như vậy chỉ hữu ích khi được sử dụng so với cùng một điểm và các công thức được sử dụng. Mà có thể được tính toán bằng cách sử dụng    còn được gọi là Định lý Pythagore trên steroid, đây là thước đo khoảng cách phổ biến nhất được sử dụng và là khoảng cách đường thẳng giữa hai điểm trong hình cầu N.  : Khoảng cách Euclide    nó là thước đo khoảng cách góc giữa hai điểm trong hình cầu N và rất hữu ích để đo độ giống nhau của tài liệu hoặc các vectơ khác.  : Độ tương tự Cosine      Khoảng cách     hai số liệu này được sử dụng để đo sự khác biệt giữa hai vectơ và rất hữu ích để đo "khoảng cách chỉnh sửa" giữa hai chuỗi. Manhattan hoặc Hamming :  Mặc dù hiệu quả của mỗi công thức đều có ưu và nhược điểm tương ứng, đối với các trường hợp sử dụng khác nhau. Đối với tìm kiếm văn bản, người ta thường chấp nhận rằng khoảng cách Euclidean "hoạt động tốt hơn" trong hầu hết các trường hợp và "đủ tốt" cho các trường hợp mà các phương pháp khác vượt trội hơn.  Tất cả những thứ đó, được sử dụng để giảm Kích thước N, thành một kích thước duy nhất (khoảng cách), so với một điểm duy nhất. Do đó, điều này có nghĩa là các nhóm có thể/có thể thay đổi đáng kể tùy thuộc vào câu hỏi được hỏi.  Bản chất "tương đối" này của khoảng cách, làm cho các chỉ mục tìm kiếm cơ sở dữ liệu cổ điển không hiệu quả.  Nếu điều đó không có ý nghĩa, thì đây là cách không gian 4 chiều được hiển thị chính xác với N-Spheres toán học.  Bây giờ hãy tưởng tượng 1.000 chiều? Vâng nó không có ý nghĩa gì.  Vì vậy, không làm hỏng chủ đề này bằng một bài báo PHD, tôi sẽ tóm tắt điều này là chỉ tin tưởng vào các giáo sư toán học.  Tất cả những gì chúng ta cần hiểu là nói chung, khoảng cách giữa hai điểm nhúng vectơ càng gần thì khả năng chúng có liên quan với nhau càng cao.  Từ quan điểm triển khai thực tế. Bắt đầu với việc sử dụng khoảng cách Euclide trước. Trước khi cân nhắc sử dụng các công thức khác đã được tinh chỉnh để có kết quả tốt hơn thông qua quá trình thử và sai cho trường hợp sử dụng của bạn (không khuyến nghị).   Tìm kiếm các phần nhúng với cơ sở dữ liệu vectơ  Vì vậy, với điều kiện là chúng tôi có thể chuyển đổi các tài liệu khác nhau thành các tệp nhúng, giờ đây chúng tôi có thể lưu trữ trong cơ sở dữ liệu và thực hiện tìm kiếm với nó.  Tuy nhiên, không giống như cơ sở dữ liệu SQL tìm kiếm bằng văn bản, cả tìm kiếm và dữ liệu đang được tìm kiếm đều là bản thân việc nhúng vectơ. Điều này có nghĩa là các chỉ mục tìm kiếm cơ sở dữ liệu truyền thống không hiệu quả khi tìm kiếm các phần nhúng.  Chúng tôi có thể nhúng tất cả các tài liệu của bạn, tính toán trước và lưu trữ vào cơ sở dữ liệu tìm kiếm vectơ. Điều này sau đó có thể được sử dụng để cung cấp một danh sách các trận đấu, được xếp hạng theo khoảng cách gần nhất.  Điều này có thể được thực hiện bằng cách sử dụng cơ sở dữ liệu vectơ hiện có như    : một cơ sở dữ liệu nguồn mở phổ biến có thể được sử dụng để lưu trữ các phần nhúng vectơ và tìm kiếm chúng một cách hiệu quả. REDIS    : một thư viện được tạo bởi Spotify sử dụng thuật toán được tối ưu hóa để tìm kiếm các phần nhúng một cách nhanh chóng. Làm phiền    : một thư viện do Facebook tạo ra cung cấp các thuật toán tìm kiếm hiệu quả cho các tập dữ liệu lớn. FAISS  Một điều quan trọng cần lưu ý, tìm kiếm vector "công nghệ cơ sở dữ liệu" là tương đối mới. Trong đó phần lớn cơ sở dữ liệu tìm kiếm vectơ được thiết kế cho các trường hợp sử dụng được tìm thấy trong các công ty như Facebook, Spotify hoặc Google, với các bộ kỷ lục có kích thước hàng triệu hoặc hàng tỷ. Và có thể không được tối ưu hóa cho các tập dữ liệu nhỏ.  Đây sẽ là một lĩnh vực thay đổi liên tục trong vài năm tới, đây là một  'danh sách tuyệt vời' của github để giúp theo dõi và tìm cơ sở dữ liệu tìm kiếm vectơ trong tương lai  Do đó, nói chung, chúng tôi nhận thấy đối với các tập dữ liệu nhỏ (<10.000 ~ 100.000 lần nhúng), việc giữ tập dữ liệu nhúng trong bộ nhớ và bình phương khoảng cách euclide cưỡng bức là "đủ tốt" cho nhiều trường hợp sử dụng và đôi khi sẽ vượt trội hơn so với chính thức giải pháp cơ sở dữ liệu (sẽ có chi phí ổ đĩa/mạng) với nội dung như sau.   Nhược điểm rõ ràng của phương pháp này là toàn bộ tập dữ liệu phải đủ nhỏ để vừa với bộ nhớ mà không cần chi phí hoạt động.  Bất kể bạn đang sử dụng tìm kiếm nhúng trong bộ nhớ cục bộ hay cơ sở dữ liệu tìm kiếm vectơ chính thức.  Đó là nó!  Tìm kiếm nhúng chỉ là một thuật toán sắp xếp và xếp hạng hoạt động linh hoạt với nhiều ngôn ngữ và tình huống khác nhau. Câu hỏi cho bạn với tư cách là người đọc là làm thế nào bạn có thể sử dụng nó. Nó có thể được sử dụng vì nó có thể thay thế tìm kiếm của Google hoặc cùng với các công cụ khác, từ trò chuyện đến trò chơi. Các khả năng là vô tận và mở ra để khám phá.  ~ Cho đến lần sau 🖖 sống lâu và thịnh vượng  Eugene Cheah @ tech-talk-cto.com  Ban đầu được đăng trên:    https://substack.tech-talk-cto.com/p/introducing-ai-embeddings-and-how  Tất cả hình ảnh được sử dụng, với sự ghi nhận phù hợp của chúng    của   trên  Người đàn ông trong kính lúp Marten Newhall Bapt   Meme toán học của Zach Galifianakis  Ngăn   của   trên  kéo tệp Jan Antonin Kolar Bapt    của   trên  Hình nền giấc mơ lớn Randy Tarampi Bapt

The writer has included referral links in this story.

2022 - HackerNoon Contributor of the Year - Beginners Guide

2022 - HackerNoon Contributor of the Year - Html

2022 - HackerNoon Contributor of the Year - Javascript

Sleep Well, with Low-Code UI test automation @ uilicious.com

Nominated for 2022 - HackerNoon Contributor of the Year - Beginners Guide

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - HackerNoon Contributor of the Year - Html

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

dài quá đọc không nổi

Make resilience your competitive advantage

Hiểu các nhúng Vector cho tìm kiếm do AI cung cấp

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

581 Stories To Learn About Non Fiction

179 Stories To Learn About Reading

85 Stories To Learn About Productivity Hacks

309 Stories To Learn About Smart Contracts

581 Stories To Learn About Non Fiction

179 Stories To Learn About Reading

85 Stories To Learn About Productivity Hacks

309 Stories To Learn About Smart Contracts

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps