데이터 3.0 시대에는 대규모 모델+데이터를 통해 기업/개발자가 코드를 덜 사용하거나 애플리케이션을 구축하고 자연어를 통해 서비스를 제공하는 것이 불가피한 추세가 되었습니다. 대규모 언어 모델의 대화 기능을 통해 데이터의 가치를 직접 채굴하고 공개할 수 있으며, 이는 데이터 사용자의 문턱을 크게 낮추고 더 많은 가능성을 열어줄 수 있습니다.
지난 11월에는 " 빅 모델 시대 데이터의 새로운 지평 " 이라는 주제로 오프라인 커뮤니티 밋업을 개최하여 , 산학연 전문가를 초청하여 빅 모델과 데이터에서 도출된 몇 가지 주요 탐구 방향인 벡터 에 대해 집중적으로 논의하였습니다. 데이터베이스 , LLM+ 데이터, LLM+SQL, LLM+Tools는 각각의 기술 탐색 및 실무 경험을 공유하고 주요 문제와 개발 동향을 공동으로 논의합니다. 다음 몇 가지 문제의 내용은 공동 학습 및 토론을 위해 DB-GPT 커뮤니티의 학생들과 텍스트 버전으로 공유됩니다.
이 글에서는 주로 대형 모델 시대를 위한 Milvus 데이터베이스를 공유합니다. Milvus 프로젝트는 2019년부터 오픈 소스로 진행되었으며, 4년이 걸렸으며 두 단계로 나누어졌습니다. 2021년부터는 Cloud Native라는 라벨이 생겼고 , 2022년부터는 AI Native라는 새로운 라벨도 생겼습니다.
벡터 데이터베이스의 탄생은 실제로 비정형 데이터의 처리가 어려운 문제를 해결하기 위한 것입니다. 비정형 데이터에는 오늘날 우리가 말하는 긴 텍스트 정보뿐만 아니라 동영상, 사진, 오디오 등의 다중 모드 정보도 포함되어 있기 때문에 다중 모드 대형 모델도 이제 매우 뜨거운 주제입니다.
2019년경부터 벡터 데이터베이스가 처음 진입한 장면은 이미지 검색과 텍스트-이미지 상호 검색 장면이었기 때문에 초기 목표는 "비정형 데이터를 검색하는 방법과 의미 검색을 수행하는 방법"에 대한 문제를 해결하는 것이 었습니다. 물론 여기에는 실제로 모델적인 측면이나 인프라적인 측면을 포함해 많은 문제가 있습니다.
대형 모델 개발을 포함한 동적 모델 개발을 통해 실제로 문제에 대한 몇 가지 예비 솔루션이 있음을 알 수 있습니다. 하지만 인프라 측면에서 우리가 매우 많은 양의 데이터를 다루고 있다면 어떻게 수십억 단위, 수백억 단위의 이미지와 텍스트에서 필요한 데이터를 신속하게 호출하여 대형 모델에 더 나은 기능을 제공할 수 있습니까? RAG나 Agent의 소위 장기 기억 이든, 대규모 모델 학습 및 추론 과정에서든 실제로 유사한 요구 사항이 있으며, 이는 벡터 데이터베이스 탄생의 원래 의도이기도 합니다.
벡터 검색이 데이터베이스와 결합되는 이유는 무엇입니까? 데이터를 처리하는 방법을 생각한다면 반드시 OB, ODPS 및 다양한 데이터베이스를 활용하는 방법을 떠올릴 것입니다. 하지만 비정형 데이터 분야에서는 AI가 대중화되거나 뉴스 네트워크에서 AI가 대중화되면서 모두가 해낸 일이 굴뚝 스타일의 애플리케이션과 비슷합니다. 즉, 위의 모델을 훈련하고 아래의 데이터를 세척하는 일은 AI팀이 담당하며, 모든 데이터 거버넌스, 모든 인프라 측면, 심지어 파우치까지 알고리즘 팀이 직접 관리합니다. 물론 대형 제조사가 더 나을 수도 있겠지만 앞으로 5~10년 안에 AI가 발전한다면 분명 레이어링 과정이 있을 거라 생각하기 때문에 AI에 대한 아주 좋은 인프라를 제공해드릴 수 있었으면 좋겠습니다. 데이터 쪽..
벡터 데이터베이스란 무엇입니까? 간단히 이해하자면, 벡터 데이터베이스는 고차원 벡터를 관리하고 쿼리하는 시스템 으로 , 몇 가지 주목할만한 기능을 가지고 있습니다.
첫째, 데이터베이스이기 때문에 추가, 삭제, 수정, 조회 등의 기본적인 기능을 가지고 있어야 한다 . 현재 많은 벡터 데이터베이스 나 이전 세대의 벡터 검색 시스템은 업데이트 및 삭제 기능이 매우 약합니다. 여전히 기존 검색과 유사한 오프라인 가져오기 모드입니다. 매일 일괄 데이터가 생성되고 훈련 후 가져옵니다. 이런 관점에서 볼 때 벡터 데이터베이스는 아니고 데이터베이스이기 때문에 기본적인 CRUD가 잘 지원되어야 하며 기본적인 스키마 정의와 명확한 지원 데이터 유형이 있어야 한다.물론 동적 스킴일 수도 있지만, 왜냐하면 데이터베이스로서 데이터베이스의 몇 가지 기본 요구 사항을 충족해야 하기 때문입니다.
둘째, 벡터 데이터베이스에는 강력한 벡터 검색 기능이 있어야 합니다 .
마지막으로 벡터 데이터베이스의 의미가 충분히 풍부해야 하는데 , ANN만 하는 것이 벡터 데이터베이스인가? 제 생각에는 그렇습니다. 벡터 데이터베이스의 가장 기본적인 작업은 가장 가까운 영점 일치입니다. 그러나 실제로 개발 과정에서 벡터 데이터베이스는 많은 새로운 의미를 발전시켰는데, 이는 실제로 매우 흥미로운 주제입니다. Join, Groupby 및 Count와 같은 기존 데이터베이스에서 구현할 수 있는 모든 작업은 벡터 데이터베이스에서 해당 구현을 갖습니다.
벡터 데이터베이스를 사용하는 전체 과정은 세 단계로 나눌 수 있습니다. 첫 번째 단계에서 벡터를 얻는 방법은 무엇입니까? 물론 벡터를 얻는 것은 임베딩 모델에 의존합니다. OpenAI의 Ada 와 BGE 및 Alibaba의 GTE를 포함하여 중국의 매우 우수한 오픈 소스 모델도 실제로 매우 우수한 임베딩 모델입니다. 임베딩이 생성된 후 벡터 데이터베이스에 삽입됩니다. . 그 중간에는 전통적인 검색으로 모두가 하는 일이 있을 것인데, 이는 인덱스 구축의 두 번째 단계이다. 인덱싱은 오프라인이며 컴퓨팅 파워를 많이 소모하므로 벡터 데이터베이스의 핵심 과제는 인덱싱 비용을 줄이는 것입니다. 또 다른 핵심 비용은 온라인 서비스 중 쿼리 부하를 줄이기 위해 인덱싱 프로세스 중에 데이터 내의 일부 연결과 의미를 최대한 많이 마이닝하는 방법입니다. 세 번째 단계는 인덱싱 후 쿼리를 작성하는 단계로, 쿼리에도 핵심적인 과제가 많이 있습니다. 예를 들어 스트리밍 버전을 처리하는 방법, 삭제를 처리하는 방법, 다양한 복잡한 의미를 처리하는 방법, 성능도 매우 중요한 과제입니다.
위 그림은 Milvus 1.0의 아키텍처 다이어그램으로 원래 2019년에 벡터 데이터베이스가 어떤 모습이어야 하는지 정의되었습니다. 간단히 이해하자면 미리 쓰기 로그, 파일을 저장하는 파일 시스템, 벡터 인덱스 Faiss/Annoy/HNSW와 같은 엔진, 일부 메타 및 스키마 정의, 간단한 삭제를 지원할 수 있는 일부 기본 필터링 작업이 있다는 것입니다. 성능이 좋지 않으며 여러 SDK를 지원할 수 있습니다. 이는 벡터 데이터베이스에 대한 최초의 정의이며, 세계 최초의 벡터 데이터베이스 정의라고도 할 수 있습니다. 우리는 벡터 데이터베이스가 무엇인지에 대해 설명하는 SIGMOD 21 기사를 발표한 적이 있습니다 .
얕은 것부터 깊은 것까지, 벡터 데이터베이스의 핵심은 무엇인가요? 사실은 벡터 인덱스 인데 , 벡터 인덱스는 데이터를 고성능으로 인덱싱하고 쿼리할 수 있는 벡터 데이터베이스의 핵심이기도 합니다.
벡터 인덱스 구현에는 다양한 유형이 있습니다. 위 그림에는 숫자 기반, 가장 일반적인 유형인 Annoy 및 해시 기반과 같은 보다 주류인 4가지 구현이 나열되어 있습니다. 성능 및 정확성 문제로 인해 더 이상 업계의 주류 쿼리 모드가 아니며, 가장 주류는 양자화 기반 FAISS입니다. FAISS는 좋은 구현이지만 Quantitation 링크에는 이제 더욱 경쟁력 있는 경쟁자인 Google의 스캔이 있습니다 . 이 프레임워크는 오픈 소스에서 더 나은 성능을 제공하는 프레임워크이기도 합니다. 마지막은 스프라이트 차트인데, 스프라이트 차트 분야에서 가장 잘 알려진 것이 HNSW인데, 실제로는 점프 테이블과 유사한 디자인이다. 아래쪽 레이어는 완전한 그림이고 일부 인덱스 그림은 위쪽 레이어에 구축됩니다. 이렇게 검색을 하면 스킵리스트처럼 될 수도 있는데, 먼저 위에서 몇 개의 이웃 노드를 찾은 뒤, 레이어별로 아래로 검색해서 맨 아래에서 최종 쿼리 결과를 찾는다. Yahoo의 오픈 소스 NGT 및 Microsoft의 오픈 소스 디스크 기반 그래프 솔루션과 같은 다양한 변형 그래프가 있습니다. 관심이 있으시면 관련 논문을 읽어보실 수 있습니다. 기본적으로 모든 프로젝트 뒤에는 해당 논문이 있습니다. 벡터 검색에 대한 링크도 확인할 수 있습니다.
데이터베이스와 벡터 검색이 필요한데 PGVector나 Elasticsearch는 어떨까요? 이것이 테슬라와 클래식카의 관계인데, 이 비유의 주된 이유는 다음과 같습니다.
첫째, 벡터 데이터와 표준 데이터의 데이터 분포에 큰 차이가 있습니다 . 예를 들어 모든 기존 데이터베이스는 기본적으로 라우팅을 위한 해싱 또는 범위 기반 샤딩을 기반으로 하므로 쿼리 중에 기본 키 인덱스와 보조 인덱스를 보다 효율적으로 사용할 수 있습니다. 그러나 벡터 데이터베이스에서는 벡터를 샤딩에 사용할 수 없는 것이 가장 기본적인 로직이므로 대부분의 벡터 데이터베이스에서는 검색 시 모든 샤드를 확인해야 하는데 이는 OLAP에 가까운 장면을 사용하는 것이다. MPP 아키텍처와 다소 유사하지만 정확히 MPP 아키텍처는 아니므로 당연히 많은 OLTP 데이터베이스가 벡터 검색에 적합하지 않습니다.
둘째, 100% 정확하지 않은 문제입니다 . 완전히 옳지 않다는 것은 무엇을 의미합니까? 이는 대형 모델 자체가 그다지 안정적인 시스템이 아니며, 결정론적인 답변을 제공할 수 없기 때문입니다. 대형 모델 검색에는 100% 정답이 필요한 것이 아니라 일치와 유사한 답변이 필요한데, 이것을 모두가 의미론이라고 부릅니다. 그렇다면 이 의미론의 효과는 무엇입니까? OB 시스템이 거래 사용 시나리오에 적용될 수 있다는 것은 누구나 알고 있으며 안정성과 정확성에 의존하므로 거래에 오류가 있을 수 없습니다. 벡터 검색 분야에서는 제약 조건을 제거할 수 있는데 이는 전혀 중요하지 않으며 비교적 합리적인 답을 얻을 수 있다면 괜찮을 것입니다. 따라서 그 뒤에는 최적화를 위한 매우 큰 공간이 있을 것입니다. 모든 데이터베이스가 100% 정확할 필요가 없다면 데이터베이스를 10번, 100번 최적화할 수 있고 공간이 매우 크다고 상상할 수 있습니다. 앞서 언급한 DB용 AI 개념은 기존 데이터베이스에는 적용하기가 매우 어려울 것이지만, 벡터 데이터베이스에서는 작동할 수 있고 매우 잘 작동합니다. 모델을 사용하여 Auto Tune을 수행하면 효과가 매우 좋고 손실이 매우 낮습니다.
셋째, 컴퓨팅 성능 요구 사항입니다 . 기존 데이터베이스 병목 현상은 IO 또는 네트워크에 있을 수 있습니다. 일부 데이터베이스는 CPU에 있을 수 있습니다. 대부분의 데이터베이스, 특히 OLTP 데이터베이스의 병목 현상은 일반적으로 CPU에 있지 않습니다. 그러나 벡터 데이터베이스의 경우 병목 현상은 CPU, 더 정확하게 말하면 메모리 대역폭에 있습니다. 이는 직면한 문제가 기존 데이터베이스와 완전히 다르다는 것을 의미합니다. 따라서 대역폭 최적화, Cache 최적화, 이기종 컴퓨팅 성능 등 다양한 방법이 시도되어야 하는데, 이는 벡터 데이터베이스가 GPU와 잘 결합될 수 있는 이유 중 하나이기도 합니다.
마지막 요점은 의미적 복잡성이 점점 더 높아진다는 것입니다 . 과거에는 ANN에 벡터 데이터베이스를 사용했고, ANN에는 Elasticsearch/PG도 사용할 수 있지만 벡터 데이터베이스는 그 이상입니다.
클러스터링을 기반으로 필터링하는 등 쿼리 패턴이 많이 있음을 알 수 있습니다. 예를 들어 개 사진을 검색했는데 "고양이 사진을 원하지 않는다"라는 표현이 있는데, 이런 유형의 검색어가 fast 에 배치된다면 어떻게 해야 할까요 ? 어렵다고 생각하는데, 전통적인 데이터베이스의 예전 경로로 돌아가는 고양이에만 라벨을 붙일 수 있습니다. 하지만 고양이 클러스터링을 완전히 필터링할 수 있나요? 아니면 KNN 조인이라는 더 흥미로운 시나리오를 수행할 수 있나요? 테이블을 두 개 주고, 한 테이블에는 남자 손님이 있고, 한 테이블에는 여자 손님이 있고, 벡터 근사를 통해 남자 손님과 여자 손님을 매칭하는 모습이 정말 재미있는 장면입니다. 즉, 벡터 데이터베이스는 기존 데이터베이스가 할 수 있는 많은 일을 할 수 있으며, 핵심은 이를 어떻게 수행하느냐이다.
우리는 왜 2.0 제품을 만드는가? 위에서 설명한 Milvus 1.0의 제품 아키텍처는 매우 순진한 데이터베이스 구현입니다. 2021년부터 데이터베이스를 다시 실행하기로 결정했습니다. 하나의 레이블은 클라우드 네이티브 및 확장성 입니다 .
물론 클라우드 네이티브가 되려면 무시할 수 없는 몇 가지 핵심 사항이 있어야 합니다. 첫째, 클라우드 인프라와 어떻게 통합할 것인가? 저장과 계산이 분리된 후 스트리밍 데이터는 분산 WL에 저장됩니다. 두 번째로 중요한 점은 데이터의 양이 늘어나면 사용자 데이터를 수용할 수 없다는 점인데, 이는 분산 시스템을 구축해야 하는 중요한 이유이기도 합니다. 셋째, 퍼블릭 클라우드와 통합하는 방법이다. 2021년에 K8S는 매우 성숙한 시스템이 되었기 때문에 팀은 K8S를 사용하여 상태 비저장 데이터베이스를 더 잘 실행하는 방법에 대해 생각해 왔습니다. 마지막으로 네 번째 요점은 서버리스가 AIGC 사용 시나리오에서 매우 중요한 점이라는 것입니다. 대부분의 대규모 모델은 API 서비스이기 때문에 대부분의 개발자는 기본 인프라 자체를 유지하고 싶어하지 않습니다. 마지막으로 감정입니다. 상업적인 요소를 제쳐두고 Zilliz는 최고의 데이터베이스 제품을 만들고 분산 벡터 데이터베이스를 만들고자 하며 실제로 그 결과를 얻었습니다.
위에 표시된 바와 같이 Milvus2.0이 사용자에게 제공하는 몇 가지 핵심 기능은 다음과 같습니다.
첫째, 클라우드 네이티브 배포 수백억 개의 벡터 확장을 지원하고 스토리지와 컴퓨팅을 분리할 수 있는 충분한 탄력성을 갖기를 희망합니다. 모든 데이터는 객체 스토리지, 메시지 큐 등과 같은 기본 스토리지에 저장됩니다.
第二，流批一体，这并不是所谓的这种传统的 lambda 里面的流式，而是希望真正在一套系统里面能够很好的去解决用户的流式插入，并且能够实时查询的这种能力。
第三，引擎可插拔。大家可以看到整个 record index 有非常多的选择，不同的选择之间是有不同 trade-off。有的性能更好，有的内存占用更低，没有办法说出一个完美的索引，满足所有人的需求。现在来看，可能对于大公司来讲，性能是一个很重要的 concern。但对小公司来讲，可能成本或者内存的占用，这些其实变成非常重要的指标，因此希望引擎本身是可以可插拔的。
最后，云端一体，大家可以非常容易的在自己的笔记本上去做部署，也可以在自己公司的 K8S 里面去跑，更为重要的是可以在云上去跑。
未来在大模型的生态中，API 会成为最重要的一个武器。大家已经看到了OpenAI 的 assistant，包括它的 GPTS，本质上其实就是 functional call。虽然也提供了很多 retrieve 的能力，但至少 function calling 是最重要的。它可以把所有很多东西串在一起，能够帮助开发者最快速的去构建。因此API可能会变成未来数据库产品的一个飞轮。有 SQL 的支持固然很好，但如果没有 SQL 支持，API 足够的 popular，大模型学会了如何去写 API 的话，开发者的门槛一样是很低的。
如上图，这是 Milvus2.0 的最终架构，整个的设计理念其实就两点，第一存算分离，第二所有的计算节点微服务化。所有索引节点，所有的 query 节点，所有的数据节点，包括前面的代理全部都是 K8S 的 pod，全部都是微服务化。所有的数据全部都存在中间这一层，基于 Kafka 和 S3 去存，系统可以跟着 K8S 非常快的去做 scale，只需要去做一些内存的变化，一旦 scale 以后，数据直接从 S3 里面拉起来。
Milvus 还提供了面向 AIGC 场景的一些丰富能力。这些是在上一代的向量检索中所缺失的。
Sparse embedding，就是大家非常熟悉的 TF-IDF（Term Frequency-Inverse Document Frequency）和 BM25（Best Match 25）。但今天的稀疏向量有基于 AI 的提取方式，它可以更好地去帮大家做关键词的匹配，标量和向量的混合查询能力以及丰富的 API 支持。
支持多租户，如果今天要构建一个 knowledge base，可能有 100万个用户，在数据库里面它的 schema 到底应该如何设计？如果使用传统的一个表一个用户的方式，可能的表的数目会爆炸。如何能在一个向量数据库里面很好的去支持多租户是一个挑战，不过 Milvus 已经具备了这种能力。
海量数据离线导入的能力，类似于 hbase 里面的 Bulk Insert、Bulk Load。有这种非常快速可以把亿级甚至 10亿级别的数据导入到向量数据库里面并立即提供查询的一个能力。
另外，Dynamic Schema；Range search；磁盘索引，基于 MMAP 的把数据放在磁盘上的能力，这是绝大多数向量数据库不具备的能力。
除此之外还有很多其他能力，比如说 CDC、多向量的支持、标量索引的倒排等，这些都是在的设计的计划里，预计会在今年陆续上线。
最后说一下性能。提起向量数据库，用户最关心的一定就是性能。如果大家感兴趣或者是做向量数据库，可以跑一下的 VectorDB Benchmark，它是完全开源的，有比较丰富的测试集，包括过滤的测试集、各种各样不同参数的搜索、不同大小的数据集。
那么如何去优化数据集呢？其实主要就三件事情。第一是算力，如何找到最便宜最高效的算力，除了 GPU 以外，ARM 是可以去深度挖的一个点，包括所有 Intel CPU 新的指令集，现在用 AVX-512 VNNI 以及最新一代的 amx 指令集，其实对性能有非常好的提升。目前，支持的 ARM SVE 的厂商比较少，我们是在 amx 上面去做的。另外，支持NVIDIA 最新的 GPU 图索引，我们也把它贡献给了社区，性能比传统的 GPU index 要好很多。
第二个其实是算法侧，算法包括怎么去优化图，怎么去提升图的质量，怎么在搜索的过程中尽可能去剪枝，是优化性能一个很重要的方式。
最后，是查询的调度，包括 dynamic batching，如何做请求的合并，如何让集群的负载变得更加的均衡，回到传统数据库的领域。所以向量检索事情本质上是一个高性能计算加数据库，这是大家要去做的一个事情。
这些传统的场景大家可以看下，不再过多去展开了，大家如果是做这些相关业务的话，可以具体去聊。
第一个应用比较多的场景是 RAG ，主要解决了四个问题。第一个是大模型的幻觉问题，第二个是数据的新鲜度问题，第三个是数据的安全问题，最后一个是用大模型去输出结果如何验证的一个问题。因为 RAG 是会给一个 reference link，无论大家用图数据库来做，还是向量数据库来做，两者之间并不冲突，是一个很好的补充。
第二个有意思的场景叫 Semantic Cache。在 github 上面有一个蛮火项目叫 GPT Cache。最简单的一个思路是用 redis 去缓存 mysql 的数数据，有没有可能去缓存一下大模型的输出的结果，所以就做了这么一个项目。
其实整个的思路没有很复杂，用向量数据库做了语义的检索，如果问题语义匹配的话，就认为答案可能是相似的。目前可能还不完全是一个非常 production ready 的场景。但是确实给了很好的思路，并且在大模型的推理阶段，大家也会用这种类似的思路，基于召回，再去给大模型做加工，可以省掉很多 token，也是蛮常见的一个思路。
最后给大家分享一个比较新的话题，对于 openapi dev day 怎么看？大家也都知道 11月6日新开的发布会，推了几个比较重要的功能。第一个就是构建自己的 GPT，第二个就是关于 GPT-4 turbo支持非常长的 token，第三就是支持召回，支持function call。比较关注的是多模态 API，我们做了很多测试，结果可以给大家简单分享一下。我觉得 openapi 做召回还是在处于非常简单的一个阶段，大家解决不好的事情，它也没有解决的很好，比如说长文本的 summarize，就是给一本书，告诉书是做什么的，其实用 RAG 来解决是非常难的，包括很具体的问题，比如说有 100个 document，每个 document 有个 ID，问 document 的 ID50 讲什么事情？ChatGPT 会告诉搜不出来。我觉得搜索和大模型之间的深度结合，是一个非常好的 topic，本质上基于概率，因此搜索和和生成这两个问题一定是要一起去解决的。但是现在其实无论对谁来讲，都是非常早期的一个阶段。自己更希望大模型的公司，能去构建更好的一个生态，通过这种 function calling，以 agent 作为一个中心，所有的周边厂商提供更好的 API。比如说的图数据库可以提供一套 API，向量数据库提供一套 API，以 agent 为中心去把业务逻辑给串起来，是对未来的一个期望。
https://github.com/eosphoros-ai/DB-GPT
https://github.com/eosphoros-ai/DB-GPT-Hub
https://github.com/eosphoros-ai/DB-GPT-Web
本文分享自微信公众号 - ZILLIZ（Zilliztech）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。