키워드 기반 검색에 작별 인사  GPT 3+ 또는 ChatGPT에서는 프롬프트 엔지니어링이 직관적으로 이해하기 쉽습니다. 웹과 소셜 미디어에서 다양한 가이드와 예시를 확인할 수 있습니다. 와 같은   신속한 엔지니어링을 위한 OpenAI 모범 사례   ChatGPT 프롬프트 목록  임베딩은 프로그래밍이 필요하며 작동 방식에 대한 다양한 반직관적 동작으로 인해 이해가 잘 되지 않습니다. 그러나 는 검색을 위한 매우 강력한 도구이거나 기존 텍스트 기반 모델과 함께 사용하여 다양한 다른 사용 사례에 사용할 수 있습니다.  임베딩은 AI 툴킷 내에서 명령 모델을 위한 똑같이 강력한 도구입니다. 다양한 단어와 문장, 심지어 전체 언어에 대한 검색을 처리할 수 있는 능력이 있기 때문입니다. 모든 쿼리에 대해 관련 문서 검색에 집중합니다.  예를 들어, 영어 기반 문서에서 검색 및 답변을 강화하는 데 사용할 수 있습니다. 영어로 ...   아니면 일본어 ...   또는 AI 모델이 지원하는 다른 언어.  벡터 임베딩은 검색이나 질문 답변, 텍스트 분류, 텍스트 생성과 같은 기타 작업에 사용할 수 있습니다.  이 문서는 검색 측면에 중점을 두고 있으며 답변 프로세스는 후속 문서에 있습니다.  벡터 임베딩이란 무엇입니까?  벡터 임베딩을 생성하려면 모든 텍스트(큰 문서, 문장 또는 단어까지)를 벡터라고 하는 "N 차원 배열"로 변환하는 임베딩 AI 모델을 사용합니다.  예를 들어  How do I write a UI test script with Uilicious?    통해 배열(벡터라고 함)로 변환 가능:  OpenAI text-embedding-ada-002 모델을 [0.010046141, -0.009800113, 0.014761676, -0.022538893, ... an a 1000+ numbers]  이 벡터는 텍스트에 대한 AI 모델의 요약된 이해를 나타냅니다. 이는 AI만이 이해할 수 있는 언어로 작성된 'N단어 요약'이라고 생각하면 된다.  AI가 문서(텍스트뿐만 아니라)에 대한 이해를 기반으로 관련 문서가 서로 가까운 거리를 갖는 경우.  이는 문장 구조와 언어의 변화를 처리할 수 있기 때문에 기존 검색 엔진의 단순한 키워드 검색을 뛰어넘는 큰 도약입니다(AI 모델이 해당 언어를 이해하도록 훈련된 경우).  이해하기 쉽도록 2차원 공간으로 부정확하게 지나치게 단순화한 가상의 예를 들어 다음을 살펴보겠습니다.   2D 공간에서는 다음과 같이 시각적으로 표현될 수 있습니다.  예를 들어 D1,2,3은 모두 Uilicious를 다양한 방식으로 사용하는 방법과 관련된 문서이며 하나의 클러스터로 그룹화되어 있습니다.  단순한 링크일 뿐 그 이상의 고유 가치가 없는 D4와 D5는 다른 클러스터에 별도로 그룹화됩니다.  또한 D1과 D2는 고유한 JavaScript 기반 테스트 언어를 사용하는 유용한 테스트 명령에 관한 것이므로 함께 그룹화됩니다.  D3는 별도로 그룹화되어 있지만 인프라에서 웹 드라이버 프로토콜을 직접 사용하는 것과 관련되어 있으며 이는 다양한 사용 사례와 대상을 대상으로 합니다.  마찬가지로 Q1과 Q2의 경우에도 문장 구조와 언어의 급격한 차이에도 불구하고 본질적으로 동일한 질문이기 때문에 두 질문을 하나로 묶습니다.  또한 질문은 기술적으로 두 가지 방법(Uilicious 테스트 스크립트 또는 웹드라이버 프로토콜 사용)으로 해석될 수 있지만 질문은 웹드라이버를 통한 Uilicious 테스트 스크립트 사용을 암시하기 때문에 해당 위치는 D1 및 D2에 "더 가깝고" 더 멀리 있습니다. D3.  따라서 키워드가 크게 중복됨에도 불구하고 그룹화의 이러한 뉘앙스는 임베딩 내에 인코딩된 AI에 의해 포착됩니다. 키워드 검색과의 차별점 강조  그러나 실제로는 사람이 이해하기 쉬운 지나치게 단순화된 2차원 배열 대신 임베딩은 쉽게 1,000차원 배열이 될 수 있습니다. 이 배열은 사용된 특정 AI 모델에 고유하며 다른 AI 모델의 임베딩과 혼합될 수 없습니다.   수학 참고사항: N차원 수학은 2/3D 수학과 호환되지 않습니다.  지나치게 단순화된 2차원 예는 하나의 질문(또는 하나의 관점)을 기준으로 그룹화하는 상위 수준 개념을 이해하는 데 좋지만 N차원을 정확하게 나타내지는 않습니다.  복잡한 N 차원 수학으로 인해 A가 B에 가까울 수 있고 B가 C에 가까울 수 있지만 A와 C는 서로 멀리 있다고 간주될 수 있는 상황이 발생할 수 있습니다. 이는 매우 반직관적인 문제입니다.  이러한 거리는 동일한 점과 사용된 공식을 기준으로 사용할 때만 유용합니다. 다음을 사용하여 계산할 수 있습니다.    스테로이드에 대한 피타고라스 정리라고도 알려져 있으며, 가장 일반적으로 사용되는 거리 측정법이며 N구체의 두 점 사이의 직선 거리입니다.  : 유클리드 거리(Euclidean distance)    N구체의 두 점 사이의 각도 거리를 측정하는 것으로 문서나 다른 벡터의 유사성을 측정하는 데 유용합니다.  : 코사인 유사성          이 두 측정항목은 두 벡터 간의 차이를 측정하는 데 사용되며 두 문자열 간의 "편집 거리"를 측정하는 데 유용합니다. Manhattan 또는 Hamming Distance:  각 공식의 효율성에는 각기 다른 사용 사례에 대한 장단점이 있습니다. 텍스트 검색의 경우 일반적으로 유클리드 거리가 대부분의 경우 "더 잘 작동"하고 다른 방법이 앞선 경우에는 "충분히 좋다"는 것이 인정됩니다.  이 모든 것은 사실상 N차원을 단일 점을 기준으로 단일 차원(거리)으로 줄이는 데 사용됩니다. 결과적으로 이는 질문에 따라 그룹화가 크게 변경될 수 있음을 의미합니다.  이러한 거리의 "상대성" 특성으로 인해 기존 데이터베이스 검색 색인이 효과적이지 않습니다.  이것이 말이 되지 않는다면, 이것이 수학 N-Spheres를 사용하여 4차원 공간을 올바르게 시각화하는 방법입니다.  이제 1,000차원을 상상해 보세요. 응, 말도 안 돼.  따라서 PHD 논문으로 이 주제를 벗어나지 않고 단지 수학 교수님들을 신뢰하는 것으로 요약하겠습니다.  우리가 이해해야 할 것은 일반적으로 두 벡터 임베딩 지점 사이의 거리가 가까울수록 서로 관련될 가능성이 높아진다는 것입니다.  실제 구현 관점에서 볼 때. 먼저 유클리드 거리를 사용하여 시작하십시오. 사용 사례에 대한 시행착오를 통해 더 나은 결과를 위해 미세 조정된 다른 공식 사용을 고려하기 전에(권장되지 않음)   벡터 데이터베이스로 임베딩 검색  따라서 다양한 문서를 임베딩으로 변환할 수 있으므로 이제 데이터베이스 내에 저장하고 검색을 수행할 수 있습니다.  그러나 텍스트로 검색하는 SQL 데이터베이스와 달리 검색과 검색되는 데이터 모두 벡터 임베딩 자체입니다. 이는 임베딩 검색 시 기존 데이터베이스 검색 인덱스가 효과적이지 않음을 의미합니다.  귀하의 모든 문서를 임베딩하고 미리 계산하여 벡터 검색 데이터베이스에 저장할 수 있습니다. 그런 다음 가장 가까운 거리에 따라 순위가 매겨진 일치 목록을 제공하는 데 사용할 수 있습니다.  이는 다음과 같은 기존 벡터 데이터베이스를 사용하여 수행할 수 있습니다.    : 벡터 임베딩을 저장하고 효율적으로 검색하는 데 사용할 수 있는 인기 있는 오픈 소스 데이터베이스입니다. REDIS    : 최적화된 알고리즘을 사용하여 임베딩을 빠르게 검색하는 Spotify에서 만든 라이브러리입니다. Annoy    : 대규모 데이터 세트에 대한 효율적인 검색 알고리즘을 제공하는 Facebook에서 만든 라이브러리입니다. FAISS  주목해야 할 주요 사항 중 하나는 벡터 검색 "데이터베이스 기술"이 비교적 새로운 것입니다. 대부분의 벡터 검색 데이터베이스는 수백만 또는 수십억 규모의 기록 세트를 갖춘 Facebook, Spotify 또는 Google과 같은 회사에서 발견된 사용 사례를 위해 설계되었습니다. 소규모 데이터세트에는 최적화되지 않을 수도 있습니다.  이는 향후 몇 년 동안 끊임없이 변화하는 분야가 될 것입니다. 여기   있습니다. 미래의 벡터 검색 데이터베이스를 추적하고 찾는 데 도움이 되는 github 'awesome-list'가  따라서 일반적으로 임베딩이 10,000개 ~ 100,000개 미만인 작은 데이터 세트의 경우 임베딩 데이터 세트를 메모리에 유지하고 유클리드 거리 제곱을 무차별 대입하는 것이 많은 사용 사례에서 "충분히 좋으며" 언젠가는 형식적인 성능보다 성능이 뛰어날 것으로 나타났습니다. 다음과 같은 데이터베이스 솔루션(디스크/네트워크 오버헤드가 있음).   이 접근 방식의 명백한 단점은 전체 데이터 세트가 오버헤드 없이 메모리에 들어갈 만큼 작아야 한다는 것입니다.  로컬 인메모리 임베딩 검색을 사용하든, 공식 벡터 검색 데이터베이스를 사용하든 상관없습니다.  그게 다야!  검색 포함은 다양한 언어 및 시나리오에서 유연하게 작동하는 정렬 및 순위 알고리즘입니다. 독자로서 당신이 해야 할 질문은 그것을 어떻게 사용할 수 있는가 하는 것입니다. Google 검색을 대체하여 그대로 사용할 수도 있고 채팅, 게임 등 다른 도구와 함께 사용할 수도 있습니다. 가능성은 무한하며 탐험의 여지가 열려 있습니다.  ~ 다음 시간까지 🖖 오래오래 번영하세요  유진 체아 @ tech-talk-cto.com  원본 게시 위치:    https://substack.tech-talk-cto.com/p/introducing-ai-embeddings-and-how  사용된 모든 이미지(적절한 저작자 표시 포함)    의   이  Unsplash Marten Newhall 돋보기를 쓴 남자   Zach Galifianakis 수학 밈    의   가  Unsplash Jan Antonin Kolar 만든 파일 서랍    의   가 만든  Unsplash Randy Tarampi Dream big 벽지

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

이 오디오는 이야기의 원래 언어로 제작되었습니다!

AI 기반 검색을 위한 벡터 임베딩 이해

About Author

코멘트

태그 걸기

이 기사는 다음에서 발표되었습니다.

Related Stories

독특한 생태계를 강화하는 비트코인 UTXO 모델

보이지 않는 레이어: 사용자 인터뷰가 대체할 수 없는 자산인 이유

Crypto Growth: 효과적인 사용자 페르소나 만들기

작업 흐름을 10배 향상하는 방법: 17가지 필수 앱

독특한 생태계를 강화하는 비트코인 UTXO 모델

보이지 않는 레이어: 사용자 인터뷰가 대체할 수 없는 자산인 이유

Crypto Growth: 효과적인 사용자 페르소나 만들기

작업 흐름을 10배 향상하는 방법: 17가지 필수 앱

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps