Vector는 PostgreSQL의 새 JSON 입니다

(jkatz05.com)

26P by xguru 10달전 | favorite | 댓글 6개

벡터는 잘 연구된 수학적 구조이고, JSON은 데이터 교환 형식임
하지만 데이터 저장 및 검색 세계에서 두가지 데이터 표현 방식은 공용어가 되었으며, 최신 어플리에키션 개발에서 곧 필수적인 요소가 될 것
현재의 경향이 지속된다면 벡터 역시 어플리케이션 구축에 있어서 JSON만큼 중요해 질 것
생성형 AI의 결과물에 대해 저장 및 쿼리하기 위해 PostgreSQL이 자연적으로 선택되었음
하지만 이게 새로운 데이터 패턴은 아님. 수학적 개념으로서의 벡터는 수백년간 존재해왔음
벡터의 기본 데이터구조인 배열은 대부분의 전산학입문 과정에서 가르침. PostgreSQL도 20년 이상 Vector 오퍼레이션을 지원해왔음
그럼 새로운게 무얼까? 이런 AI/ML 알고리듬의 "접근성"과 일부 "현실 세계" 구조(텍스트,이미지,비디오)를 벡터로 표현하고 이를 나중에 응용프로그램에서 사용하는게 얼마나 "쉽게 가능한가?"임
또한 이런 시스템의 출력("임베딩")을 데이터 스토리에 저장하는 것도 새로운게 아니라고 할 수 있지만, 새로운 패턴은 이런 데이터를 모든 어플리케이션에서 거의 실시간으로 쿼리하고 반환하는 "접근성"임
그럼 이게 PostgreSQL과 무슨 관련이 있을까?
- 데이터 타입을 효율적인 저장하고 검색하는 공통 패턴은 앱 개발을 크게 단순화 시켜줬고, 사람들이 데이터를 같은 공간에 저장하고 기존 도구들로 작업가능하게 해줌
- 우리는 10년전에 JSON으로 이걸 보았고, 이제 벡터 데이터로 이 패턴을 보는 중

PostgreSQL의 JSON에 대한 간략한 역사

(원문을 참조하세요)

벡터의 부상 "새로운 종류의 JSON"

요즘 인기가 급상승
일반적인 사용 사례는 저장된 데이터에 모델을 구축하고 벡터형식으로 변환한 다음 "시맨틱 검색"에 이용하는 것
- 이 경우, 검색에 들어온 새로운 입력을 벡터 포맷으로 변환한뒤 데이터베이스에서 가장 비슷한 것을 검색하는 것
- 유사성은 유클리드/코사인 거리등 거리함수를 이용하며, 결과는 종종 k-NN(Nearest Neighbors) 또는 가장 유사한 개체 k로 제한됨
- 벡터의 트레이닝 세트를 인코드하는데 많은 시간이 걸릴수 있으므로, DB와 같은 곳에 캐시하고 그곳에서 k-NN 쿼리를 실행하는 것이 좋음
- 시맨틱 검색을 위해 쿼리할 준비가 된 일련의 벡터들을 가지는 것이 보통 사용자에게 더 나은 경험을 제공하므로 "벡터 데이터베이스"의 필요성이 대두
벡터 저장은 PostgreSQL에는 새로운 것이 아님
- 실제로 PostgreSQL은 여러차원의 데이터(예: matrix)를 저장 가능하기 때문에 잘못된 이름임
- 기본적으로 PostgreSQL의 배열에는 두 배열 사이의 "거리" 계산과 같은 벡터를 위한 기능이 제한적으로 포함되어 있긴 함
- 스토어드 프로시저를 작성할수 있찌만 개발자에게 좀 더 작업이 필요함
다행이 cube 데이터 타입은 이런 제한을 극복함
- cube는 20년 이상 사용되었으며, 고차원 벡터에 대한 작업을 수행할 수 있게 설계됨
- cube에는 유클리드 거리를 포함하여 벡터 유사성 검색에 사용되는 대부분의 일반적인 거리 함수를 포함
- GiST 인덱스를 이용하여 효율적인 K-NN 쿼리도 수행 가능
- 하지만 cube는 100차원의 벡터 까지만 저장가능하며, 최신 AI/ML 시스템은 그 이상의 차원을 요구함

pgvector: PostgreSQL에서 벡터를 저장하고 검색하기 위한 오픈 소스 확장

pgvector를 사용하면 벡터를 저장하고 다양한 거리 메트릭(유클리드, 코사인, 내적 등)으로 k-NN 쿼리 수행 가능
현재 pvector는 벡터 인덱싱의 IVR FLAT 메소드를 구현한 한개의 인덱스 ivfflat 와 함께 제공
인덱스된 벡터 데이타를 쿼리하는 것은 일반 데이터를 쿼리하는 것은 다를 수 있음
고차원 벡터에서 가장 가까운 이웃 검색을 수행하는 비용때문에 많은 벡터 인덱싱 방법은 정답에 "충분히 가까운" "대략적인" 답을 찾음
이것은 "ANN(Approximate Nearest Neighbor)" 검색 분야로 이어짐
사람들이 ANN 쿼리에 대해서 보는 두가지 차원은 성능과 "recall"(관련된 결과가 리턴되는 백분률) 사이의 균형
- ivfflat 을 예로 보면, ivfflat 인덱스 생성시 몇개의 리스트를 포함할지 결정함
- 각 리스트는 "중심"을 나타내며, 이 중심은 k-means 알고리듬으로 계산됨
- 모든 센터가 결정되면, ivfflat은 각 벡터가 가장 가까운 센터를 결정하고 그걸 인덱스에 추가함
- 벡터 데이터를 쿼리할때가 되면, ivfflat.probes 변수에 따라 얼마나 많은 센터를 체크해야할지 결정함
- 여기서 ANN 성능/리콜 트레이드오프를 볼 수 있음. 더 많은 센터를 방문할때마다 더 정확한 결과를 내지만, 성능이 저하됨

PostgreSQL에서 벡터를 더 잘지원하기 위한 다음 단계

JSON 타입을 공식 지원했던 PostgreSQL 9.2 버전때 처럼, 벡터 데이터를 PostgreSQL에 저장하는 방법의 초기 단계에 잇음
PostgreSQL 과 pgvector는 이미 좋지만, 훨씬 더 좋아질 것
pgvector는 이미 일반적인 AI/ML 데이터 사례들을 처리 가능. 많은 사용자가 이미 배포하여 사용중
다음 단계는 개선 및 확장을 돕는 것이며 대부분 이미 진행중
- 더 많은 병렬화를 추가
- 2천개 이상의 차원이 있는 벡터에 대한 지원
- 계산 속도를 높이기 위해 하드웨어 가속 활용
PostgreSQL을 벡터 "데이터베이스"로 사용하는 것에 많은 기대가 있음
JSON의 역사에서 볼 수 있듯이 PostgreSQL 커뮤니티는 확장가능하고 안전한 방식으로 지원할 방법을 찾을 것임