벡터 검색 성능 향상

벡터 차원 줄이기

Atlas Vector Search는 최대 4096 까지 벡터 차원을 지원합니다. 그러나 벡터 검색 인덱싱 및 쿼리는 벡터가 클수록 더 많은 부동 소수점 비교가 필요하기 때문에 계산 집약적입니다. 따라서 가능하면 임베딩 모델 변경이 벡터 쿼리의 정확도에 미치는 영향을 측정할 수 있는지 확인한 후 차원 수를 줄이는 것이 좋습니다.

쿼리를 실행할 때 벡터 인덱싱 피하기

벡터 임베딩은 인덱싱 중에 계산 리소스를 소비합니다. 벡터 검색 중에는 인덱싱 및 재인덱싱을 피하는 것이 좋습니다. 인덱스할 벡터를 생성하는 임베딩 모델을 변경하기로 결정한 경우, 현재 사용 중인 인덱스를 업데이트하는 대신 새 벡터를 새 인덱스로 다시 인덱싱하는 것이 좋습니다.

결과에서 벡터 필드 제외하기

결과 내 문서의 기존 필드와 $project 단계에서 새로 계산된 필드가 반환되도록 요청할 수 있습니다. 쿼리 성능을 향상시키려면 결과에 모든 필드가 필요한 경우를 제외하고 $project 단계를 사용하여 결과에 반환할 필드를 현명하게 선택합니다. 벡터 임베딩이 크고 결과 반환 시 쿼리 지연 시간에 영향을 줄 수 있으므로 $project 단계에서 벡터 필드를 제외하는 것이 좋습니다.

충분한 메모리 확보

계층적 탐색 가능한 작은 세계 벡터 데이터가 메모리에 저장되어 있을 때 효율적으로 작동합니다. 데이터 노드에 벡터 데이터와 인덱스를 저장할 수 있는 충분한 RAM이 있는지 확인해야 합니다. 벡터 검색 사용 사례에서 메모리를 보다 효율적으로 사용할 수 있도록 데이터 격리 없이 워크로드 격리를 위해 별도의 검색 노드를 배포하는 것이 좋습니다.

파일 시스템 캐시 워밍업

전용 검색 노드 없이 벡터 검색을 수행하는 경우, Hierarchical Navigable Small Worlds 를 탐색할 때 쿼리는 처음에 디스크에서 무작위 검색을 수행합니다. 그래프와 벡터 값을 메모리로 읽습니다. 이로 인해 초기 쿼리의 지연 시간이 매우 길어집니다.Hierarchical Navigable Small Worlds traversal은 모든 인덱싱된 벡터를 메모리로 읽어서 후속 쿼리를 위해 훨씬 더 빠르게 액세스할 수 있습니다.

그러나 대규모 쓰기 또는 인덱스를 다시 작성하는 경우에는 이 캐시 워밍업 프로세스를 반복해야 합니다. 전용 검색 노드를 배포하는 경우 Atlas Vector Search는 인덱스를 파일 시스템 캐시로 자동으로 사전 예열하므로 이 추가 단계가 필요하지 않습니다.