GeekNews의 xguru님께 허락을 받고 GN에 올라온 글들 중에 AI 관련된 소식들을 공유하고 있습니다. 
소개
- 벡터는 잘 연구된 수학적 구조이고, 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 커뮤니티는 확장가능하고 안전한 방식으로 지원할 방법을 찾을 것임