번역: 모든 DB는 머지않아 벡터 데이터베이스가 될 것이다

"왜 어떤 데이터베이스든 언젠가는 벡터 데이터베이스가 될 것인가" 라는 주제로 재미있는 글이 업로드 되었다. 

출처: https://nextword.substack.com/p/vector-database-is-not-a-separate

Vector database is not a separate database category

이 글의 요점은 "기존 데이터베이스 업계가 벡터 검색 및 RAG 워크로드를 도입하고 있다는 것" 이고 "이로 인해 별도의 벡터 데이터베이스가 필요하지 않을 수 있으며, 고객과 데이터베이스 회사 간의 관계가 변화하고 있다는 것" 이다. 이 글을 번역하면 다음과 같다. 

 

점차 이러한 것들이 명확해 지고 있다. 

- 모든 데이터베이스는 어떤 형태로든 벡터 검색을 제공할 것이다.
- 이것은 그래프, 관계형, 문서 및 키-값 데이터베이스뿐만 아니라 캐시도 포함합니다.
- "벡터 데이터베이스"와 "아닌 것" 사이가 모호해질것이다. 
- Pinecone, Weaviate, Milvus 등과 같은 특수화된 "벡터 데이터베이스" 현재 카테고리는 경쟁 속에서 상대적인 움직임과 차별성을 잃을 것이다.
- 기존 데이터베이스는 새로운 RAG(검색 증강 생성) 워크로드를 캡처하기 위해 기존의 워크로드/고객 기반을 활용하려고 할 것이다.

결과적으로 "벡터 데이터베이스"가 별도의 데이터베이스 범주인지 아니면 모든 데이터베이스가 제공할 수 있는 기능인지 의심할 가치가 있다. 

생성 AI가 급부상함에 따라 일부 질의의 상당한 부분이 "밀도 벡터 검색(dense vector search)" 방식으로 수행될 것이다.
이 워크로드를 잃을 만큼 정신나간 데이터베이스 회사는 없다. 따라서 텍스트를 저장할 수 있는 거의 모든 데이터베이스가 벡터 검색을 제공할 것이다.

 

실제로, 이러한 "데이터베이스의 벡터 DB화"는 이미 진행되고 있다.

2023년 2분기까지 "벡터 검색"은 주로 Pinecone, Milvus, Weaviate 등의 스타트업 데이터베이스 회사와 관련되어 있었다.
그러나 기존 기업들은 빠르게 이를 따라잡았고 이제는 모든 클라우드 네이티브 공급업체가 "벡터 검색" 시장에 진입하고 있다.
데이터베이스를 판매하지 않는 Cloudflare도 시장에 진입했다. 이는 "데이터에 인접한" 회사라면 RAG 워크로드의 일부를 원하기 때문이다.
- Cloudflare는 2023년 9월 27일에 벡터라이즈를 출시했다.
- MongoDB Atlas Vector Search는 2023년 6월 22일에 출시했다.
- Databricks는 2023년 6월 28일에 발표하였다.
- Oracle은 2023년 9월 19일에 통합 벡터 데이터베이스를 발표하였다.
- IBM은 2023년 4분기에 벡터 데이터베이스 미리보기를 발표할 예정이다..
- Elastic 및 Microsoft와 같은 회사는 이미 훨씬 이전에 벡터 데이터베이스 옵션을 갖고 있었다.

그러나 여기에는 대기업이 FOMO(놓치기 싫어하는 두려움)를 따라가는 것 이상의 일이 벌어지고 있다. 기업 데이터베이스 사용자가 벡터 검색을 제공하는 것은 상당한 의미가 있다. 왜냐하면 별도의 벡터 데이터베이스로 데이터 이동을 줄일 수 있기 때문이다. 벡터와 원본 문서를 동일한 위치에 저장하면 지연 시간도 감소한다. 따라서 기존 데이터베이스 기업이 이 시장에 진입하면 고객이 이익을 얻게 된다.

 

기본적으로 별도의 벡터 데이터베이스를 가지고 있으면 비용과 복잡성을 추가될 수 있다. MongoDB 상점에서 지역 간에 저장된 5억 개 이상의 문서가 있는 경우를 상상해봐라. 별도의 벡터 데이터베이스를 사용한다면 Pinecone과 같은 것이 두 데이터베이스 간에 수십억 개의 임베딩을 이동해야 할 수도 있으며 이는 많은 비용을 초래할 뿐만 아니라 사용자가 임베딩을 생성하는 것을 책임지게 된다.

하나의 데이터베이스(Mongo, Elastic)가 벡터 검색을 지원한다면 더 빠르고 저렴하며 간단하다.

물론 벡터 검색을 제공하는 것도 방어적인 조치이다.

검색 증강 생성(RAG)은 생성 AI의 상위 2개 워크로드 중 하나로 설정되어 있으며 다른 하나는 추론이다. 벡터 검색을 제공하지 않으면 RAG 워크로드를 잃게 되고 고객이 다른 데이터베이스로 마이그레이션 한다는 것을 의미한다. 이는 관리하고 있는 데이터베이스 회사에게 실존적인 위협이다.

그리고 여기서 멈추지 않을 이유가 무엇이 있을까?

기존 데이터베이스는 RAG 워크로드의 전체 수명주기를 더 많이 흡수하게 될 것이다.

- 임베딩은 점점 데이터베이스에서 기본적으로 지원되는 것이 될 것이다. (즉, 데이터베이스 사용자는 문서를 삽입하고 데이터베이스가 벡터 저장소로 로컬로 임베딩을 생성하도록 처리함)

- 심지어 end-to-end RAG 및 재순위 지정도 데이터베이스에서 기본적으로 지원될 수 있다.

이렇게 좁혀지는 트렌드의 일부는 다음과 같은 결과가 예상된다.
- 고객은 특수화된 벡터 데이터베이스가 필요한지 아니면 기존 데이터베이스에서 제공되는 것을 사용해야 하는지 점점 의문을 제기하게 될 것이다.
- 모든 데이터베이스는 프로덕션 RAG 워크로드에 자신을 삽입하려고 할 것이다.
- 데이터베이스 및 AI 회사의 로드맵이 점점 충돌할 것이다.
- 스타트업 벡터 데이터베이스 회사는 성장 속도가 급속하게 둔화될 것이다. 2023년 상반기까지는 기업 구매자들이 Gen AI 워크로드에 대한 약간의 이해와 주저로 인해 상대적으로 부족한 상태였다. 그러나 현재 2023년 4분기에는 기업들이 벡터 검색이 무엇인지에 대해 잘 이해하고 있으며 현재의 데이터 인프라와 원활하게 통합되는 솔루션을 선호한다.

현재의 데이터베이스가 벡터 검색 기능을 추가하는 것보다 더 좋은 방법은 무엇일까?

 

라는 것이다. 

 

이 글을 읽고 벡터 데이터베이스와 백터 검색이 무엇인지,생성 AI 및 RAG 워크로드에 대해 알아볼 필요가 있는 것 같다.