벡터 데이터베이스: 기술 입문서 [PDF]

 (tge-data-web.nyc3.digitaloceanspaces.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • AI 애플리케이션이 비정형·고차원 데이터를 다루면서, 벡터 데이터베이스는 데이터를 숫자 배열 형태로 저장·검색하는 전용 시스템으로 중요해짐
  • 핵심은 행·열이나 명시적 관계보다 데이터 속성 간 유사도를 기준으로 레코드를 연결해 암묵적 의미를 활용하는 데 있음
  • 의미 관계를 다차원 벡터로 인코딩하면 유사도 검색, 클러스터링, 분류 같은 분석 작업을 더 빠르게 수행할 수 있음
  • 생성형 AI에서는 대량의 고차원 데이터를 관리하고, 유사 벡터 검색을 통해 학습과 추론 속도 및 개인화 결과를 개선하는 데 쓰임
  • 고급 인덱싱은 검색 대상을 관련성 높은 부분집합으로 줄여 검색 시간을 낮추고, 유사도와 다른 조건을 결합한 복잡한 쿼리를 가능하게 함

벡터 데이터베이스가 다루는 데이터 형태

  • 벡터 데이터베이스는 고차원 데이터 표현인 벡터를 저장, 관리, 처리하기 위한 특수 데이터베이스임
  • 전통적 데이터베이스가 데이터를 행과 열에 저장하는 것과 달리, 벡터 데이터베이스는 데이터를 다차원 공간의 벡터로 저장함
  • 각 벡터는 데이터 포인트의 특성이나 속성을 나타내는 숫자 배열임

의미와 유사도 기반 연결

  • 전통적 데이터베이스는 명시적 링크나 계층을 기반으로 요소 간 관계를 설정함
  • 벡터 데이터베이스는 데이터 속성의 유사도를 기준으로 레코드를 알고리듬적으로 연결함
  • 이 방식은 데이터베이스 요소 안의 암묵적 의미를 바탕으로 더 직관적인 연결을 만들 수 있음

분석 쿼리에 맞춘 구조

  • 데이터가 의미 관계를 반영하는 다차원 벡터, 즉 숫자 배열로 인코딩되면 고급 분석 작업을 빠르게 수행할 수 있음
  • 지원되는 작업에는 유사도 검색, 클러스터링, 분류가 포함됨
  • 계산 모델은 패턴 탐지, 예측 분석, 높은 분석 요구사항을 가진 애플리케이션에 적합함

AI와 생성형 AI에서의 활용

  • AI와 머신러닝의 확산은 벡터 데이터베이스 수요가 커진 주요 배경임
  • 생성형 AI 영역에서 벡터 데이터베이스는 대량의 고차원 데이터를 효율적으로 저장하고 관리하도록 설계됨
  • 유사 벡터를 빠르게 검색하고 결과를 회수할 수 있어 생성형 AI 모델의 학습과 추론 과정을 크게 빠르게 할 수 있음
  • 생성형 AI 시스템이 사용자에게 더 개인화되고 관련성 높은 콘텐츠를 제공하는 데도 활용됨

인덱싱과 복잡한 검색 조건

  • 벡터 데이터베이스는 고급 인덱싱 기법으로 유사 벡터를 빠르게 조회하고 검색함
  • 인덱스는 검색 대상을 더 작고 관련성 높은 벡터 부분집합으로 좁혀 검색 시간을 크게 줄임
  • 유사도 조건과 다른 검색 기준을 결합하는 복잡한 쿼리도 처리할 수 있음
  • 이런 유연성은 정교한 검색 기능이 필요한 고급 AI 애플리케이션에서 중요함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들
  • 추가 자료 몇 가지:
    A Comprehensive Survey on Vector Database: Storage and Retrieval Technique, Challenge: https://arxiv.org/abs/2310.11703
    Survey of Vector Database Management Systems: https://arxiv.org/abs/2310.14021
    What are Embeddings: https://raw.githubusercontent.com/veekaybee/what_are_embeddi...
    출처 표시: https://twitter.com/eatonphil/status/1745524630624862314 및 https://twitter.com/ChristophMolnar/status/17457316026829826...
  • 전용 벡터 데이터베이스가 필요한가 슬라이드는 꽤 흥미롭지만, 정작 그 질문에 답하지는 않음
    나도 궁금하던 부분이라 기준이나 경험칙이 있으면 좋겠음
    최근 Simon Willison의 훌륭한 llm 도구로 임베딩을 다뤄봤는데, 접근 방식이 가장 단순함: 거리 계산용 UDF 몇 개와 함께 SQLite에 임베딩을 저장함
    이 단순함은 매력적이지만, 트래픽과 데이터가 어느 수준을 넘으면 더 전문화된 데이터베이스가 필요할 텐데 그 경계가 어디쯤인지 감이 궁금함
    • 몇 년 전 LSH를 쓰는 벡터 색인을 만든 적이 있음
      검색은 가장 단순하게 전부 훑고 해밍 거리(xor와 popcount)로 비교했는데, 2011년형 MBP 단일 코어에서 20만 개 해시를 10ms 미만에 스캔해 가장 비슷한 항목을 찾을 수 있었음
    • findsight.ai를 구동하는 빠르고 지저분한 엔진을 수천만 개 벡터까지 확장해 본 적이 있고, 자세한 내용은 이 발표에 있음: https://youtu.be/elNrRU12xRc?t=1556
      대략 1천 줄 코드라 결국 외부 벡터 데이터베이스가 필요 없었음
    • 솔직히 10만 개 정도 벡터라면 전부 메모리에 올리는 방식이나 SQLite, pgvector 같은 것으로도 완전히 괜찮음
      하지만 그 이상에서는 Pinecone 같은 쓸 만한 선택지가 복잡해지고 느려지며 터무니없이 비싸짐
      내가 아는 한 가장 나은 선택지는 turbopuffer.com인데, Pinecone보다 100배쯤 저렴하고 실제로 확장되는 것처럼 보임
      슬라이드의 추천 벡터 DB 목록에 없어서 괜찮은 추천으로 던져둠
    • 경우마다 다르겠지만, 몇 주 전에 올라온 이 글이 우리가 실제로 필요한 것을 어떻게 생각해야 하는지에 집중하는 데 큰 도움이 됐음: 결국 필요한 건 검색 엔진이었음
      https://news.ycombinator.com/item?id=38703943
  • 몇 달 전 TGE Data의 비공개 고객을 위해 벡터 데이터베이스 수업을 했고, 이후 더 넓은 audience를 위해 짧은 강의로 녹화하기로 했음
    이 강의는 벡터, 벡터 데이터베이스, 색인, 유사도 검색의 기본 개념을 다루는 이론과 데모를 섞었고, 마지막에는 Pinecone과 Weaviate 데이터베이스 데모로 끝남
    • 멋지다. 그럼 영상도 있는 건가?
  • 좋은 입문 자료지만, 이런 소개들이 특성 선택 문제를 너무 빨리 지나친다고 느낌
    이 단계에서 인간의 판단이 아주 미묘하게, 때로는 거의 무시될 정도로 들어가는데, 겉으로는 매우 자동화된 “그냥 수학” 시스템처럼 보이게 됨
    오디오를 예로 들면, N차원 벡터를 만들기 위해 어떤 특성을 뽑을 것인가? 쉬운 답은 “가능한 한 많이”일 수 있음
    하지만 첫째, 쉽게 이름 붙일 수 있는 특성조차 특성화 데이터에 접근하지 못할 수 있음
    둘째, 도메인 지식이 깊지 않으면 써야 할 잠재 특성의 존재조차 모를 수 있음
    셋째, 도메인 지식이 깊어도 여전히 써야 할 잠재 특성을 모를 수 있음
    예를 들어 Reich식 위상 이동 미니멀 음악의 팬이라고 하자. 이 장르의 대표곡, 예컨대 Piano Phase와 비슷한 음악을 찾으려고 벡터 데이터베이스에 간접 질의함
    데이터베이스는 지배 주파수, 음 시작 간격, 음량, 주파수 분포 기반 음색 특성, 겉보기 근음과 음계 등 여러 오디오·음악 특성을 사용함
    그런데 데이터베이스의 특성 집합에 “시간에 따른 음과 음 사이 간격이 일정함”이 없으면, 질의는 음색·화성·선율·리듬이 비슷한 것을 찾을 수는 있어도 핵심 특징인 두 선율선의 상대 위상이 꾸준히 변하는 것을 공유하는 곡을 찾는 건 순전히 운에 맡기게 됨
    시각, 텍스트, 수치 등 어떤 데이터에도 비슷한 예를 만들기 어렵지 않음
    물론 이 말이 벡터 데이터베이스와 특성 분류가 쓸모없다는 뜻은 아님
    특정 데이터셋에서 일치 패턴을 찾거나 못 찾을 때 초기에 물어야 할 질문 중 하나는 특성 집합이 완전하다고 강하게 보장되는지, 아니라면 어떻게 확장해야 하는지임
    • 벡터 데이터베이스는 검색과 검색 결과 회수에 맞춰져 있음
      보통 벡터를 만드는 방식은 대규모 사전학습 모델을 미세조정하고 내부 표현을 추출하는 것임
      데이터셋에 성공적인 질의와 회수 결과가 들어 있으므로, 원시 입력을 사용해 벡터 데이터베이스가 지원하는 유사도 목적에 맞춰 손실 함수를 최적화하면 됨
      표·텍스트·이미지·오디오 같은 일반적인 양식에서는 특성 선택에 인간 판단이 거의 들어가지 않고, 그냥 어텐션을 적용하면 됨
      참고로 E5-Mistral 같은 최신 텍스트-벡터 모델은 데이터셋에 인간 큐레이션조차 필요로 하지 않음
    • “모르는 것을 모른다”는 점을 잘 짚었음
      Steve Reich 애호가를 또 보니 반갑고, 내가 좋아하는 Music for 18 Musicians와 비슷한 곡 추천이 궁금함
  • 훌륭한 개요지만 마지막 섹션은 Postgres+pgvector 같은 벡터 저장소와 Pinecone 같은 벡터 데이터베이스 중 무엇을 쓸지 결정하는 뻔한 질문을 다루지 않음
    질의 속도, 삽입·색인 구축 속도, 사용 편의성 등 여러 절충점을 논의해서 각 애플리케이션에 맞는 선택을 돕는 발표를 더 보고 싶음
    • 예전에 여러 벡터 검색 도구 비교를 모으기 시작했음: http://vectorsearch.dev/
      PR은 언제든 환영함
    • 전자는 벡터 확장이라고 부르겠음
      데이터베이스는 저장소에 이런저런 기능이 붙은 것임
  • digitaloceanspaces.com은 S3 스타일 호스팅 제공자이므로, Hacker News가 이를 특별 처리해서 도메인을 단순히 digitaloceanspaces.com으로 표시하는 대신 tge-data-web.nyc3.digitaloceanspaces.com 같은 식으로 보여주면 좋겠음
    다만 S3도 같은 문제가 있어 보임: https://news.ycombinator.com/item?id=38876761
    다른 곳에는 선례가 있음. x.github.io 하위 도메인 사이트들은 여기서 특별 처리됨: https://news.ycombinator.com/from?site=lfranke.github.io
  • 이 자료는 엔지니어가 출발점으로 삼기에는 상당히 위험해 보임
    의미 기준으로 군집화된다거나 분석에 최적화되어 있다는 식의 표현은 의문스럽다
    군집화는 계산한 임베딩에 달려 있음. 임베딩이 데이터의 의미를 잘 근사한다고 믿는다면 그런 식으로 생각해도 괜찮을 수 있음
    하지만 이를 깨는 임베딩은 쉽게 상상할 수 있음. 예를 들어 의미가 같은 오디오 파일과 텍스트 파일을 같은 임베딩 과정에 넣어도, 멀티모달이 아니라면 임베딩 벡터 공간에서는 멀리 떨어질 가능성이 큼
    앞으로는 의미적 유사도보다 활용 방식에 따라 벡터 공간에서 가까이 배치하는 임베딩도 분명 나올 것이라고 봄
    추천 시스템을 만든다면 일회성 구매의 여러 변형을 가까이 묶고 싶지 않음
    예를 들어 의미적으로 가장 비슷한 항공편은 같은 목적지의 다른 시간대 항공편이나 가까운 공항행 항공편이겠지만, 실제로는 그 항공편을 산 사람들이 자주 함께 구매한 호텔을 묶고 싶을 수 있음
    벡터 데이터베이스는 시간 인식 같은 추가 차원도 데이터에 넣을 수 있음. 의미를 인코딩한 벡터를 반드시 써야 하는 건 아님
    그래서 벡터 데이터베이스는 입력 벡터 기반 조회나 검색에 최적화되어 있지, OLAP 질의와 유사하지 않음
    Snowflake보다는 Elasticsearch에 더 가깝다. 벡터 공간에 대한 리포팅이나 대규모 분석을 기대하고 벡터 데이터베이스를 쓴다면, 내가 알기로 당장 쓸 만한 제품은 없음
    • 임베딩 계산은 아직도 나에게 미스터리임
      사과 사진에서 “사과다움”을 나타내는 벡터로 가고, 그 벡터를 일반적인 수학으로 다른 벡터와 비교하는 건 이해함
      이해가 안 되는 건 누가/무엇이 이미지를 입력으로 받아 벡터를 출력하느냐임
      문서도 마찬가지임. 배열에 숫자 하나를 더 넣는 식으로 차원을 추가하고 싶다면, 벡터 데이터베이스의 어느 부분을 수정해야 그 차원이 벡터 계산에 포함되는가?
      아니면 문서·이미지·무엇이든 벡터 표현으로 바꾸는 과정은 데이터베이스 바깥의 다른 방식으로 이루어지는 건가?
      수정: 임베딩 계산은 머신러닝 알고리즘이 할 일처럼 보이지만, 그러면 그 알고리즘도 먼저 학습해야 함. 결국 끝없이 학습으로 이어지는 셈
  • 왜 PQ가 “색인 전략”으로 나열됐는지 모르겠음
    PQ는 벡터 압축·양자화 기법이지 검색 공간을 분할하는 수단이 아님
    전수 검색/평면 색인, IVF 색인, HNSW에서 PQ로 벡터를 인코딩할 수 있고, Faiss에는 각각 IndexPQ, IndexIVFPQ, IndexHNSWPQ로 들어 있음
    원한다면 k-D 트리나 ANNOY와도 쓸 수 있음
    “질의 속도가 정밀도보다 중요할 때 매우 큰 데이터셋에는 HNSW나 Annoy를 쓰라”는 말도 문제 있음
    그래프 기반 기법은 메모리 오버헤드와 구축 비용이 크고, 10억 규모 데이터셋에는 실용적이지 않음
    보통 IVF 기법보다 더 정확하고 빠르긴 하지만, 비슷한 정확도를 얻으려면 IVF는 많은 셀을 방문해야 하기 때문임
    반면 IVF는 다른 기법과 달리 큰 오버헤드 없이 1조 규모 데이터베이스까지 확장 가능하면서도 합리적인 속도·정확도 절충을 제공함
    나는 “질의 속도가 중요하지만 높은 정확도도 원하고, 평면/전수 색인이 비현실적인 중간 규모 데이터셋에 쓰라”고 하겠음
    • 연속 공간을 이산 공간으로 바꾸는 것임
      먼저 PQ를 하고, 새 이산 벡터에 대해 KNN을 수행하면 됨
      이렇게 하면 어휘 공간을 고정 크기로 압축할 수 있음
  • 15번 슬라이드 표에서 Traditional Databases와 Vector Databases의 Indexing & Search Efficiency 칸이 서로 바뀐 것처럼 보임
    • 나도 마지막 행은 서로 바뀐 것처럼 보임
  • SQLite처럼 내장형 임베딩 데이터베이스 추천이 있을까?
    소규모 문제용이지만, LMDB + FAISS보다 편하면 좋겠음
    • txtai(https://github.com/neuml/txtai)를 살펴볼 수 있음
      Python 프로세스 안에서 실행 가능하고, 콘텐츠는 SQLite에 저장하며 임베딩 벡터는 로컬 벡터 색인 형식(Faiss, HNSW, Annoy)에 저장하는 기능을 지원함
      참고로 내가 txtai의 주 작성자임
    • 방금 DuckDB로 HN 댓글 유사도 검색을 하는 개념 증명을 끝냈음
      https://github.com/patricktrainer/hackernews-comment-search
    • 참고로 Simon Willison의 llm 도구는 SQLite와 몇 가지 UDF만 사용함
      그 단순함이 매력적이지만 언제, 왜 충분하지 않게 되는지는 잘 감이 없음
    • Python에서는 Chroma [1]를 내장형으로 사용할 수 있는 것으로 알고 있음
      Go용으로는 최근 Chroma 인터페이스에서 영감을 받아 chromem-go를 만들기 시작했음: https://github.com/philippgille/chromem-go
      아직 고급 기능이나 대규모 용도는 아니지만 RAG 데모는 동작함
      [1] https://github.com/chroma-core/chroma
    • https://github.com/asg017/sqlite-vss
답변달기