최신 AI 워크로드를 위한 경량 벡터 데이터베이스

홈 » Python » 최신 AI 워크로드를 위한 경량 벡터 데이터베이스

이 글에서는 벡터 데이터베이스 환경을 살펴보고, 특히 경량 온프레미스 옵션에 중점을 둡니다.벡터 데이터베이스란 무엇인지, 일반 벡터 인덱스와 어떻게 다른지, 자연어 처리(NLP) 및 관계형 알고리즘(RAG)에 어떻게 활용되는지, 어떤 엔진과 확장 기능(Milvus, Qdrant, PostgreSQL pgvector, VDB 같은 내장 라이브러리 등)을 고려해 볼 만한지, 그리고 거리 측정 방식과 인공신경망(ANN) 알고리즘이 품질과 성능에 어떤 영향을 미치는지 살펴봅니다.

벡터 데이터베이스란 무엇이며 왜 중요한가요?

기존 관계형 데이터베이스는 행과 열로 구성된 구조화된 데이터에 강점을 보입니다.하지만 방대한 양의 비정형 콘텐츠를 처리해야 할 때는 어려움을 겪습니다. PDF, 채팅 기록, 이미지 또는 센서 데이터를 기존 SQL 스키마에 로드한 다음 AI 처리를 위해 준비하는 작업은 번거로울 뿐만 아니라, 정확한 일치가 아닌 의미적 유사성이 필요한 경우 계산 효율성도 떨어집니다.

벡터 데이터베이스는 토큰이나 키워드 대신 밀집 벡터를 직접 처리함으로써 이 문제를 해결합니다."이 필드에 '스마트폰'이라는 단어가 포함되어 있습니까?"라고 묻는 대신, "쿼리 임베딩과 가장 유사한 저장된 벡터는 무엇입니까?"라고 물으면 시스템은 정확히 같은 단어를 사용하지 않더라도 의미적으로 관련된 항목을 반환합니다.

키워드 매칭에서 벡터 공간에서의 유사성으로의 이러한 전환이 가능하게 하는 것입니다. 시맨틱 검색강력한 추천 기능과 강력한 검색 증강 생성(RAG) 기능이제 기업들은 전용 벡터 엔진을 사용하거나 기존 데이터베이스 내에서 벡터 유형을 활성화함으로써 기존 비즈니스 데이터와 "시맨틱 메모리"를 단일 아키텍처에서 결합할 수 있습니다.

벡터, 임베딩, 그리고 그것들이 실제로 해결하는 문제

모든 벡터 데이터베이스의 핵심에는 벡터가 있습니다. 벡터는 다차원 공간에서 항목의 위치를 ​​나타내는 숫자들의 순서가 지정된 목록입니다.각 벡터는 문장, 단락, 이미지, 제품, 사용자 프로필과 같은 객체에 해당하며, 기계 학습 모델이 학습한 수십, 수백 또는 수천 개의 차원을 따라 인코딩됩니다.

서로 다른 임베딩 모델은 서로 다른 벡터 공간과 차원을 정의합니다.어떤 프로그램은 384차원 벡터를 출력하고, 어떤 프로그램은 768차원 이상의 벡터를 출력합니다. 차원이 커질수록 더 풍부한 뉘앙스를 표현할 수 있지만, 효율적으로 인덱싱하기는 더욱 어려워집니다. 벡터 데이터베이스는 바로 이러한 점, 즉 대규모의 긴 부동 소수점 벡터를 처리하는 데 특화되어 있습니다.

그들이 해결하는 진정한 문제는 비정형 데이터에 대한 기존 키워드 검색의 경직성입니다."스마트폰"이라는 일반적인 검색으로는 "휴대폰"이나 "모바일 기기"만 언급된 문서를 찾을 수 없습니다. 오타를 허용하는 키워드 검색이 어느 정도 도움이 되지만, "자연 채광이 좋은 미드센추리 모던 주택"이 모든 매물에서 찾아볼 수 있는 문자 그대로의 문구가 아니라 스타일을 나타낸다는 점을 제대로 인식하지 못합니다.

벡터 데이터베이스는 임베딩을 저장함으로써 유사성 검색을 가능하게 합니다. 쿼리와 문서는 모두 벡터이며, 해당 공간에서의 유사성은 의미적 관련성을 나타냅니다.그렇기 때문에 "휴대폰"을 검색하면 "스마트폰"만 언급하는 문서도 함께 검색 결과에 나타날 수 있습니다. 형태는 다를지라도 이러한 단어들이 공간의 같은 영역에 삽입되기 때문입니다.

벡터 인덱스와 전체 벡터 데이터베이스 비교

"벡터 인덱스"라는 개념과 완전한 형태의 벡터 데이터베이스라는 개념을 구분하는 것이 유용합니다.둘 다 벡터를 다루지만, 문제의 다른 측면을 다루고 서로 다른 기능 세트를 제공합니다.

벡터 인덱스는 최근접 이웃 검색에 최적화된 데이터 구조입니다.벡터 집합과 쿼리 벡터를 제공하면 저장된 항목 중 가장 가까운 항목을 알려줍니다. FAISS와 같은 라이브러리는 이러한 기능을 훌륭하게 수행하며, 근사 최근접 이웃(ANN) 검색 및 클러스터링을 위한 효율적인 알고리즘을 구현하지만, 완전한 데이터베이스 시스템은 아닙니다.

반면 벡터 데이터베이스는 이러한 인덱스를 데이터베이스 기능으로 감쌉니다. 메타데이터 저장, 스키마 관리, 보안, 리소스 관리, 동시성 제어, 장애 복구 및 더 넓은 데이터 생태계와의 통합 등이 포함됩니다. 조직은 인덱스 구조뿐만 아니라 임베딩과 원본 객체(또는 해당 객체에 대한 참조)를 모두 이곳에 보관합니다.

기업용 벡터 데이터베이스는 벡터 유사도와 구조화된 속성에 대한 필터를 결합하는 쿼리 언어 및 API도 제공합니다.예를 들어 "프로젝트가 X이고 생성일이 최근 30일 이내인 이 단락과 유사한 문서"를 쿼리할 수 있는데, 이는 인덱스 라이브러리만으로는 깔끔하게 처리하기 어렵습니다.

일부 최신 관계형 시스템은 네이티브 벡터 유형을 추가하여 "벡터 지원 데이터베이스"가 되었습니다.예를 들어 Oracle Database와 MySQL은 이제 기존의 숫자 및 텍스트 필드와 함께 벡터를 지원합니다. 이를 통해 비즈니스 기록과 임베디드 데이터를 하나의 엔진에 저장하여 별도의 벡터 저장소와 기본 데이터베이스 간의 데이터 일관성 문제를 방지할 수 있습니다.

벡터 데이터베이스가 자연어 처리 및 생성형 인공지능에 어떻게 활용될 수 있을까요?

의미 검색은 가장 눈에 띄는 활용 사례 중 하나입니다.단순한 키워드 매칭 방식 대신, 사용자 검색어와 색인된 모든 문서를 함께 포함하여 검색 결과를 제공합니다. 이를 통해 검색어와 가장 유사한 벡터를 가진 문서를 찾아낼 수 있습니다. 동의어, 의역, 심지어 주제에서 약간 벗어나지만 문맥상 관련성이 있는 표현까지 처리할 수 있어 일반 텍스트 검색보다 관련성이 크게 향상됩니다.

이 의미론적 계층은 오타와 불필요한 표현의 영향을 줄여줍니다.사용자가 쿼리를 완벽하게 작성할 필요는 없습니다. 전체적인 의미가 유사하기만 하면 임베딩 모델이 쿼리를 적절한 문서 근처에 배치하고 벡터 데이터베이스가 해당 문서를 표시합니다.

효율적인 임베딩 관리 또한 핵심적인 역할 중 하나입니다.벡터 데이터베이스는 대규모 모델에서 생성된 방대한 양의 텍스트 임베딩을 저장, 인덱싱 및 검색하는 데 최적화되어 있습니다. 이를 통해 애플리케이션은 이를 파일 모음이나 특정 애플리케이션 프로세스 내의 임시 배열이 아닌, 밀리초 단위로 액세스할 수 있는 빠르고 쿼리 가능한 "메모리 뱅크"로 취급할 수 있습니다. 대규모 모델에서 생성된 임베딩 대규모 환경에서 실용성을 확보하려면 런타임과 가속기에 의존하는 경우가 많습니다.

실제로 이는 여러 자연어 처리 애플리케이션에서 나타납니다.챗봇과 AI 비서는 벡터 데이터베이스를 사용하여 이전 대화나 문서의 관련 부분을 검색하고, 질의응답 시스템은 문서를 임베딩으로 변환하여 적절한 구절을 검색하고 종합함으로써 복잡한 질문에 답변합니다. 감정 및 의도 분석은 벡터에 인코딩된 풍부한 의미론적 관계를 활용하여 이점을 얻고, 추천 엔진은 임베딩 공간의 근접성을 기반으로 항목과 사용자 간의 유사성을 추론합니다.

검색 증강 생성(RAG)에서의 벡터 검색

검색 증강 생성(RAG)은 벡터 검색과 대규모 언어 모델을 결합하여 환각이나 오래된 지식과 같은 문제를 해결합니다.LLM은 고정된 학습 마감일이 있으며, 추론 시점에 명시적으로 제공하지 않는 한 귀하의 독점 문서를 볼 수 없습니다.

일반적인 RAG 파이프라인은 지식 기반을 더 작은 부분으로 나누는 것으로 시작합니다. 예를 들어 텍스트 덩어리당 200~500단어 정도의 크기로 데이터를 분할한 후, 선택한 모델을 사용하여 각 덩어리를 임베딩 벡터로 인코딩합니다. 이러한 벡터들은 제목, 태그, 출처 URL과 같은 메타데이터와 함께 벡터 데이터베이스에 저장됩니다.

사용자가 질문을 하면 시스템은 해당 쿼리를 동일한 모델에 포함시킵니다. 저장된 임베딩에 대해 유사성 검색을 수행합니다. 가장 유사한 상위 k개의 청크는 질문과 "관련"이 있는 것으로 간주되며, 데이터베이스의 ANN 인덱스 덕분에 밀리초 단위로 검색됩니다.

추출된 코드 조각들은 LLM 프롬프트 앞에 추가되거나 다른 방식으로 삽입됩니다.이것이 바로 "증강" 부분입니다. 모델은 원래 사용자 요청과 여러 관련 외부 컨텍스트 정보를 모두 받아 추측이 아닌 사실에 근거한 답변을 제공합니다.

마지막으로, LLM은 검색된 컨텍스트에 기반한 응답을 생성합니다.데이터베이스 콘텐츠를 지속적으로 업데이트할 수 있기 때문에 RAG는 LLM이 모델 자체를 재학습시키지 않고도 최신 도메인별 정보를 사용하여 답변할 수 있도록 하며, 출력을 실제 문서에 기반하여 제공함으로써 오류를 줄입니다.

유사성 검색은 실제로 어떻게 작동할까요?

벡터 검색은 내부적으로 쿼리 벡터를 저장된 여러 벡터와 비교하고 거리 또는 유사도 점수에 따라 순위를 매기는 방식입니다.문제는 수백만 또는 수십억 개의 벡터가 고차원 공간에 존재할 때 이를 빠르고 정확하게 수행하는 것입니다.

기본적인 단계는 엔진 종류에 관계없이 동일합니다.먼저 데이터를 벡터화합니다. 텍스트, 이미지, 오디오 또는 기타 콘텐츠를 임베딩 모델을 통해 입력하여 벡터를 생성합니다. 그런 다음 이러한 벡터를 데이터베이스에 저장하고(종종 ID 및 메타데이터와 함께), 그 위에 하나 이상의 인공신경망(ANN) 인덱스를 구축합니다.

쿼리 시점에 사용자 입력도 벡터에 포함됩니다.그런 다음 데이터베이스는 해당 인덱스를 사용하여 코사인 유사도, 유클리드 거리, 내적 또는 기타 선택된 측정 기준에 따라 가장 가까운 이웃을 찾고 유사도 점수와 함께 가장 일치하는 항목을 반환합니다.

결과는 일반적으로 유사도 점수에 따라 순위가 매겨지므로 가장 가까운 벡터가 먼저 표시됩니다.또한 많은 검색 엔진은 메타데이터(예: 가격 범위, 위치, 카테고리)로 필터링하는 동시에 벡터 유사성을 최적화하여 비즈니스에 더욱 적합한 결과를 제공하는 하이브리드 쿼리를 지원합니다.

이 모든 과정을 대규모로 빠르게 처리하기 위해 최신 벡터 데이터베이스는 근사 최근접 이웃 알고리즘을 사용합니다.그들은 속도와 메모리 사용량에서 엄청난 개선을 이루는 대신 약간의 재현율 손실을 감수하는데, 이는 대부분의 실제 AI 애플리케이션에 허용 가능한 수준입니다.

주요 인공신경망 알고리즘: HNSW, LSH 및 곱 양자화

계층적 탐색 가능 소규모 세계(HNSW)는 벡터 데이터베이스에서 가장 널리 사용되는 인공신경망 알고리즘 중 하나입니다.이 방식은 벡터를 여러 그래프 계층으로 구성합니다. 상위 계층은 노드 수가 적고 장거리 연결을 가지는 반면, 하위 계층은 노드 수가 많아지고 최하위 계층에서는 모든 노드가 연결됩니다.

탐색 과정에서 HNSW는 최상층의 진입점에서 시작하여 가까운 이웃을 향해 탐욕스럽게 이동합니다.검색을 세분화하면서 계층을 아래로 이동합니다. 이러한 계층형 그래프 구조는 재현율과 지연 시간 사이의 효율적인 균형을 제공하며, 이것이 바로 HNSW가 Milvus, Qdrant 등의 검색 엔진에 사용되는 이유입니다.

지역 민감 해싱(LSH)은 유사한 벡터를 높은 확률로 동일한 버킷에 매핑하는 해시 함수를 사용하는 다른 접근 방식을 취합니다.기존 해싱 방식은 충돌을 피하려고 하는 반면, LSH는 유사한 항목에 대해서는 충돌을 허용합니다. 여러 개의 해시 테이블을 구축하여 각 쿼리가 전체 데이터셋 대신 일치하는 버킷의 후보만 검사하도록 합니다.

이는 확률적인 방식으로 인접 구조를 보존하면서 차원을 효과적으로 축소합니다.LSH는 후보 생성 속도가 매우 빨라야 하고 근사 결과를 허용할 수 있는 경우 고차원 데이터에 매우 유용할 수 있습니다.

곱 양자화(PQ)는 벡터를 압축하여 메모리를 절약하고 거리 계산 속도를 높이는 데 중점을 둡니다.이 방법은 각 고차원 벡터를 여러 개의 하위 벡터로 분할한 다음, 각 하위 공간을 개별적으로 양자화하고 가장 가까운 중심점의 ID만 저장하여 짧은 코드를 생성합니다.

이 압축 방식을 사용하면 거리 추정 기능은 유지하면서 메모리 사용량을 90% 이상 줄일 수 있습니다.PQ는 손실 압축 방식이며 검색 정확도를 약간 떨어뜨릴 수 있지만, RAM이 주요 병목 현상인 대규모 데이터 컬렉션에 매우 강력하며 FAISS와 같은 도구 및 일부 벡터 데이터베이스 백엔드에서 필수적으로 사용됩니다.

거리 측정 방법: 유클리드 거리 vs 코사인 거리 및 기타 방법

벡터 검색의 품질은 선택하는 거리 또는 유사도 측정 방법에 따라 크게 달라집니다.가장 일반적인 두 가지 선택 사항은 유클리드 거리(L2)와 코사인 유사도(또는 그 보완 개념인 코사인 거리)입니다.

유클리드 거리는 n차원 공간에서 두 점 사이의 직선 거리를 측정하는 단위입니다.벡터 P와 Q의 경우, 유사도는 두 벡터의 좌표 차이 제곱의 합의 제곱근입니다. 거리가 짧을수록 유사도가 높으며, 그 범위는 0(동일한 벡터)부터 무한대까지입니다.

이 지표는 크기에 민감합니다.한 벡터가 다른 벡터보다 훨씬 길다면(예: 더 긴 문서 또는 더 큰 특징 값을 나타내는 경우), 두 벡터가 대략 같은 방향을 가리키더라도 유클리드 거리는 그 차이를 반영합니다. 이는 절대적인 크기가 의미론적 의미를 가질 때, 예를 들어 물리적 좌표나 크기가 중요한 연속적인 수치 특징에 대해 잘 작동합니다.

반면 코사인 유사도는 두 벡터의 길이가 아닌 각도를 살펴봅니다.코사인 거리는 벡터의 내적을 벡터 노름의 곱으로 나눈 값입니다. 많은 실제 시스템에서는 코사인 거리 = 1 − 코사인 유사도를 사용하는데, 여기서 0은 동일한 방향을 의미하고 값이 클수록 유사성이 작음을 나타냅니다.

코사인 유사도는 크기를 무시하기 때문에 방향이 의미론적 정보를 담고 있을 때 이상적인 방법입니다.텍스트 기반 애플리케이션에서 동일한 주제에 대한 두 문서(하나는 짧고 하나는 긴 문서)는 여전히 매우 유사한 것으로 간주되어야 합니다. 코사인 거리는 이를 가능하게 하지만, 유클리드 거리는 단순히 데이터 개수가 더 많다는 이유만으로 긴 문서에 불이익을 줄 수 있습니다.

자연어 처리에서 흔히 볼 수 있는 고차원 희소 공간에서 코사인 유사도는 유클리드 거리보다 더 안정적인 성능을 보이는 경향이 있습니다.차원의 저주라는 현상 때문에 매우 높은 차원에서는 모든 유클리드 거리가 비슷하게 보여 판별력이 떨어질 수 있습니다. 코사인 함수는 정규화된 벡터에 적용되어 텍스트 임베딩에서 보다 의미 있는 유사도 순서를 제공하는 경우가 많습니다.

측정 기준을 선택하는 것은 궁극적으로 해당 분야에서 "유사성"이 무엇을 의미하는지에 대한 문제입니다.만약 규모가 중요하다면(예를 들어, 편차의 크기에 기반한 이상 탐지) 유클리드 기하학이 적합할 수 있습니다. 길이보다 주제적 유사성이나 방향 정렬이 더 중요하다면 코사인 기하학이 일반적으로 더 적합합니다. 일부 데이터베이스는 벡터를 정규화했을 때 코사인 함수와 밀접한 관련이 있는 내적을 측정 기준으로 제공하기도 합니다.

널리 사용되는 벡터 데이터베이스 및 벡터 지원 시스템

벡터 스토리지 옵션 생태계는 완전 관리형 클라우드 서비스부터 자체 호스팅 오픈 소스 엔진 및 라이브러리 방식 솔루션에 이르기까지 폭발적으로 확장되었습니다.최적의 선택은 규모, 예산, 운영상의 제약, 그리고 기존 데이터 인프라와의 통합 수준에 따라 달라집니다.

고성능 유사성 검색을 위해 처음부터 전용 벡터 데이터베이스가 구축되었습니다.일반적으로 여러 개의 ANN 인덱스, 정교한 압축 방식, 풍부한 메타데이터 필터링, 그리고 프로덕션 수준의 클러스터링 및 장애 조치를 지원합니다.

Milvus는 대규모 워크로드를 위해 설계된 강력한 오픈 소스 벡터 데이터베이스의 대표적인 예입니다.이 플랫폼은 머신러닝, 딥러닝, 유사성 검색 및 추천 시스템을 대상으로 하며, GPU 가속, 분산 쿼리 및 IVF, HNSW, PQ와 같은 다양한 인덱싱 방식을 지원합니다.

이러한 구성 가능성을 통해 필요에 따라 리콜 속도, 지연 시간 및 저장 공간 사용량의 균형을 맞출 수 있습니다.Milvus는 수십억 개의 벡터, 다국어 콘텐츠 및 엄격한 성능 요구 사항을 가진 기업에 적합하며 복잡한 데이터 플랫폼에 원활하게 통합됩니다.

다른 전용 엔진들은 약간씩 다른 틈새시장을 공략합니다.Pinecone은 엄격한 SLA와 강력한 메타데이터 기능을 갖춘 완전 관리형 클라우드 배포에 중점을 둡니다. Weaviate는 GraphQL API, 내장 벡터화 도구 및 하이브리드 키워드+벡터 검색 기능을 제공하는 오픈 소스 엔진을 제공합니다. Qdrant는 고급 ANN 방식과 유연한 필터링 기능을 갖춘 빠른 ​​오픈 소스 벡터 검색 서비스를 제공합니다. Chroma는 간편한 개발자 경험을 통해 간단한 사용 사례 및 실험에 적합합니다. Vespa는 구조화된 필드, 텍스트 및 벡터를 혼합한 하이브리드 검색 및 순위 지정에 탁월합니다. Deep Lake는 머신러닝 프레임워크와의 긴밀한 통합이 중요한 이미지 및 비디오와 같은 멀티모달 데이터 세트에 집중합니다.

동시에 범용 데이터베이스는 벡터 기능을 완전히 포기하기보다는 도입하기 시작했습니다.이미 SQL이나 문서 저장소에 투자한 조직의 경우, 이는 별도의 시스템을 구축하지 않고도 의미 검색 기능을 추가할 수 있는 실용적인 방법입니다.

pgvector 확장 기능을 사용하는 PostgreSQL은 이 분야에서 가장 인기 있는 선택지 중 하나입니다.Pgvector는 고정 차원 벡터를 Postgres 테이블에 직접 저장하는 VECTOR 유형을 도입하고 유클리드 거리, 내적 및 코사인 거리에 대한 유사도 연산자를 제공합니다.

즉, embeddings(id SERIAL PRIMARY KEY, vector VECTOR(768))와 같은 테이블을 만들 수 있습니다.인덱스를 생성한 다음, "L2 거리 순으로 정렬된 가장 가까운 벡터 5개를 반환해 주세요"와 같은 쿼리를 표준 SQL로 실행할 수 있습니다. 이 확장 기능은 상당히 높은 차원의 인덱스를 지원하며 LangChain과 같은 프레임워크에 잘 통합됩니다.

pgvector의 가장 큰 장점은 단순성과 통합입니다.거래 데이터, 분석 테이블 및 임베딩이 모두 하나의 엔진에 저장되며, 백업 및 보안도 하나로 통합됩니다. 하지만 PostgreSQL은 수십억 개의 벡터를 처리하는 워크로드에 특화된 데이터베이스가 아니므로, 극단적인 규모나 초저지연 요구 사항이 있는 경우에는 전용 벡터 데이터베이스가 일반적으로 더 나은 성능을 제공합니다.

Elasticsearch와 OpenSearch 또한 벡터 인식 시스템으로 전환될 수 있습니다. k-NN 플러그인을 통해 가능합니다. 팀에서 이미 로그 또는 전문 검색 클러스터를 운영하고 있다면, 벡터 필드를 활성화하는 것만으로도 아키텍처를 재설계하지 않고 의미 검색 프로토타입을 구현할 수 있습니다. MongoDB 또한 이러한 추세에 발맞춰 경량화된 사용 사례를 위해 문서 중심 검색 생태계에 벡터 검색 기능을 통합했습니다.

내장형 및 경량 옵션: VDB 및 온프레미스 시나리오

모든 프로젝트에 분산형 엔터프라이즈급 벡터 데이터베이스가 필요한 것은 아니며, 또 그럴 만한 비용도 없습니다.MVP, 연구 도구 또는 온디바이스 애플리케이션을 개발하는 많은 창업자와 팀에게는 가볍고 내장된 라이브러리가 훨씬 더 매력적입니다.

VDB는 그러한 경량 솔루션의 한 예입니다. 핵심 벡터 검색 기능을 구현하는 헤더 파일만으로 구성된 C 라이브러리입니다.이 라이브러리는 Apache 2.0 라이선스 하에 배포되며, 멀티스레딩을 위한 선택적 pthreads를 제외하고는 특별한 종속성 없이 C 또는 C++ 애플리케이션에 직접 통합할 수 있습니다.

핵심 기능 세트는 초기 단계 제품에 필요한 대부분의 기능을 포함합니다.VDB는 다양한 유사도 측정 기준(코사인, 유클리드, 내적)을 지원하고, 멀티코어 CPU를 활용하기 위한 멀티스레드 검색 기능을 제공하며, 디스크에서 인덱스를 저장하고 다시 불러올 수 있는 기본적인 영구 저장 기능을 지원하고, 일반적인 AI 스택에 통합할 수 있도록 공식 Python 바인딩을 제공합니다.

헤더 파일만으로 구성되어 있기 때문에 통합이 매우 간단합니다.프로젝트에 헤더 파일을 포함하고, 컴파일하고, 원하는 모델(OpenAI, Cohere, Sentence Transformers 등)로 임베딩을 생성하고, 관련 ID 또는 메타데이터와 함께 VDB에 푸시한 다음, 요청을 처리할 때 가장 가까운 상위 k개 이웃을 쿼리합니다.

이 디자인은 온프레미스 또는 엣지 배포 환경에 매우 적합합니다.LangChain + ChatGPT 스타일의 앱을 개발하면서 모든 것을 자체 방화벽 내에서 관리하고 싶다면, 내장 라이브러리를 사용하면 외부 종속성과 벤더 종속성을 피할 수 있습니다. 클라우드 지연 시간이 허용되지 않는 IoT 또는 엣지 디바이스의 경우, 벡터 스토어가 바이너리에 컴파일되어 있는 것이 큰 장점입니다.

물론 몇 가지 절충점이 있습니다. VDB는 완전한 엔터프라이즈 데이터베이스를 대체하려는 것이 아닙니다.이 방법은 정교한 인공신경망 그래프나 양자화 대신 정확한 (무차별 대입) 검색에 의존하므로 쿼리 시간이 데이터셋 크기에 비례하여 증가합니다. 수만 개 또는 수십만 개의 벡터라면, 특히 멀티스레딩을 사용할 경우 허용 가능한 수준이지만, 수천만 개의 벡터가 있는 경우에는 샤딩을 하거나 자체 인덱싱 계층을 도입하지 않는 한 한계에 부딪힐 가능성이 높습니다.

실제 환경에서의 하이브리드 검색: 벡터와 메타데이터의 결합

실제로 거의 모든 프로덕션 사용 사례에서는 벡터 유사도와 구조화된 속성에 대한 엄격한 필터를 함께 사용합니다.사용자들은 "전체 자료에서 가장 유사한 것"을 원하는 경우가 드물고, "유사하면서도 이러한 제약 조건을 준수하는 것"을 원합니다.

사용자가 집의 느낌을 묘사하는 부동산 검색 애플리케이션을 생각해 보세요. "자연 채광이 풍부한 미드센추리 모던 스타일"이라는 조건을 충족하면서도 "침실 3개", "800,000만 달러 미만", "A 학군"과 같은 엄격한 제약 조건을 요구하는 경우, 일반적인 벡터 검색으로는 학군과 맞지 않는 2만 달러짜리 멋진 미드센추리 빌라를 검색 결과로 보여줄 수 있습니다. 반면 일반 SQL 필터로는 이러한 스타일 쿼리를 제대로 이해할 수 없습니다.

PostgreSQL용 AlloyDB와 같은 엔진은 인라인 필터링을 통해 이 문제를 해결하는 방법을 보여줍니다.AlloyDB는 Postgres와의 호환성을 Google의 확장 가능한 인프라와 결합하고, pgvector를 핵심 확장 기능으로 통합하며, 빠른 유사도 검색을 위해 ScaNN 기반 벡터 인덱스를 추가합니다.

인라인 필터링 기능 덕분에 벡터 인덱스와 SQL 메타데이터 필터가 한 번에 적용됩니다.AlloyDB는 벡터 검색을 수행한 다음 일치하지 않는 행을 필터링하는 대신, 벡터 인덱스를 탐색하면서 숫자 및 범주형 제약 조건을 확인하여 불필요한 작업과 지연 시간 증가를 방지합니다.

결과적으로 미적 선호도와 엄격한 필터 조건을 모두 충족하는 주택을 밀리초 단위로 보여주는 하이브리드 검색이 가능해집니다.이러한 패턴은 전자상거래(스타일 + 가격 + 재고), 콘텐츠 검색(주제 + 언어 + 지역) 등 엄격한 비즈니스 규칙과 '분위기'가 공존해야 하는 모든 영역에 일반화될 수 있습니다.

임베디드부터 실제 응용 프로그램까지

저장 방식을 선택하고 나면 벡터 기반 피처를 구축하는 전반적인 흐름은 비교적 일관적입니다.Milvus, Qdrant, PostgreSQL + pgvector, Elasticsearch k-NN 또는 VDB와 같은 경량 라이브러리를 사용하든 상관없이.

먼저, 코퍼스에 대한 임베딩을 생성합니다.텍스트 데이터의 경우 문서, 지식 기반, 티켓, 이메일 또는 채팅 기록 등이 될 수 있으며, 이미지 및 멀티모달 데이터의 경우 적절한 비전 또는 멀티모달 모델을 사용해야 합니다. 각 항목은 벡터 형태로 표현되며, 필요한 메타데이터가 추가됩니다.

다음으로, 임베딩을 식별자 및 메타데이터와 함께 선택한 벡터 저장소에 저장합니다.벡터 데이터베이스에서는 일반적으로 벡터 및 메타데이터 필드를 포함하는 컬렉션이나 테이블을 생성하는 것을 의미합니다. VDB에서는 디스크 스냅샷을 기반으로 하는 메모리 내 인덱스를 사용하는 것이 될 수 있습니다.

쿼리 시점에 사용자 입력을 동일한 모델에 포함시키고 유사성 검색을 실행합니다.데이터베이스는 가장 유사한 상위 k개의 벡터를 반환하며, 사용자는 ID 또는 저장된 페이로드를 사용하여 해당 항목(문서, 제품, 이미지)을 조회할 수 있습니다.

RAG의 경우, 검색된 콘텐츠를 추가 컨텍스트로 LLM에 전달합니다.추천 시스템에서는 이웃 노드를 직접 순위 후보로 사용합니다. 분석이나 이상 탐지에서는 거리와 이웃 노드를 집계하여 패턴과 이상치를 파악할 수 있습니다.

벡터 데이터베이스를 사용하면 임베딩 모델을 더욱 견고하게 구현하는 것이 더 쉬워집니다.수동으로 파일을 처리하거나 임시 배열을 사용하는 대신, 적절한 리소스 관리, 확장성 조절 기능, 보안 제어 및 복잡한 유사도 + 필터 쿼리를 깔끔하게 표현할 수 있는 쿼리 언어를 사용할 수 있습니다. 이러한 운영상의 고려 사항에는 프로덕션 LLM 및 벡터에 대한 모니터링, 추적 및 거버넌스가 포함됩니다. 자세한 내용은 [설명 참조]를 참조하십시오. AI 관찰 가능성의 계층.

생성형 AI와 결합된 이 스택은 사용자의 데이터에 기반하고 데이터 규모가 커짐에 따라 진화할 수 있는, 개인화된 경험을 제공합니다.고성능 분산 데이터베이스를 선택하든 경량 온프레미스 라이브러리를 선택하든, 임베딩, 유사도 측정, 인공신경망(ANN) 또는 정확한 검색, 메타데이터 필터와 같은 개념적 요소는 동일하게 유지되며 최신 AI 애플리케이션의 핵심을 이룹니다.

인공지능 시스템이 더욱 대화형, 멀티모달형, 그리고 맥락 정보를 필요로 하게 됨에 따라, 의미 기억 계층으로서 벡터 데이터베이스의 역할은 더욱 중요해질 것입니다.벡터가 저장되고, 인덱싱되고, 비교되는 방식을 이해하는 것은 언어 및 비전 모델을 사용하여 진지한 애플리케이션을 개발하는 모든 사람에게 핵심 기술로 빠르게 자리 잡고 있습니다.