로컬 벡터 데이터베이스에서 HNSW 검색은 메모리와 재현율을 어떻게 맞바꿀까요?

HNSW는 탐색 가능한 이웃 그래프를 저장해 메모리를 사용하는 대신 재현율을 높입니다. 그래프의 연결성과 검색 범위에 따라 쿼리가 주변 벡터를 얼마나 철저히 탐색할지가 결정됩니다.

로컬 벡터 데이터베이스에는 가정용 문서, OCR 텍스트, 사진 메타데이터, 매뉴얼, 트랜스크립트, 애플리케이션 기록의 임베딩을 저장할 수 있습니다. 브루트포스 검색은 쿼리와 모든 벡터를 비교하는 반면, HNSW는 계층형 그래프를 탐색해 유용한 동일 주변 영역에 도달하려고 합니다. 이 방식이 빠른 이유는 데이터베이스가 그래프 구조를 미리 추가로 저장하기 때문이며, 정확도는 그래프가 얼마나 촘촘하게 연결되어 있고 쿼리가 얼마나 많은 후보를 탐색하도록 허용되는지에 따라 달라집니다.

HNSW는 저장된 벡터 주변에 계층형 근접 그래프를 추가합니다

각 벡터는 선택된 이웃과 연결된 노드가 됩니다. 일부 노드는 상위 계층에도 나타나며, 장거리 경로를 만들어 검색이 가까운 벡터가 있을 가능성이 높은 영역으로 빠르게 이동하도록 돕습니다.

다층 근접 그래프는 HNSW의 상위 계층에 대략적인 경로를 제공하고, 계층 구조의 하단으로 내려갈수록 더 세밀한 이웃 탐색을 가능하게 합니다.

저장된 간선은 첫 번째 메모리 절충 요소입니다. 벡터로 구성된 단순 배열과 달리 인덱스는 탐색 중 계속 사용할 수 있어야 하는 토폴로지를 유지합니다.

계층 구조는 일반 쿼리가 컬렉션 중 방문하는 범위를 줄이지만 근사 방식입니다. 그래프나 검색 예산이 올바른 경로를 노출하지 못하면 실제 이웃을 놓칠 수 있습니다.

M 매개변수는 더 많은 경로를 만들기 위해 그래프 메모리를 더 사용합니다

HNSW 구현은 일반적으로 `m` 또는 `M`이라고 부르는 연결성 매개변수를 제공합니다. 값을 높이면 노드가 더 많은 이웃 링크를 유지할 수 있어, 벡터 공간의 밀집하거나 불규칙한 영역을 통과하는 대체 경로가 늘어납니다.

HNSW m 값이 높으면 노드당 더 많은 이웃 연결을 저장하므로 일반적으로 탐색 선택지와 재현율이 향상되지만, 그래프 메모리와 구축 작업량도 증가합니다.

메모리 증가는 원본 임베딩 값이 더 커져서가 아니라 그래프 간선과 관련 인덱스 구조에서 발생합니다. 수백만 개의 벡터가 있으면 노드당 링크가 몇 개만 늘어나도 전체 컬렉션에 걸쳐 누적됩니다. `m`을 줄이면 메모리가 제한된 홈 서버에서 더 여유롭게 운영할 수 있지만, 그래프가 지나치게 성기면 검색이 지역적 막다른 길을 우회할 방법이 줄어들어 재현율이 낮아질 수 있습니다.

Ef 구성은 그래프 자체를 개선하기 위해 더 많은 구축 작업을 사용합니다

그래프 품질은 벡터가 삽입되는 과정에서도 결정됩니다. `ef_construct`는 새 노드의 링크를 선택하기 전에 구축 과정에서 검토하는 후보 이웃의 범위를 제어합니다.

구축 품질 조절 수단으로 efConstruction을 사용하면 인덱스 구축 과정에서 간선을 선택하기 전에 더 넓은 후보 이웃을 검토할 수 있어, 구축 시간 작업량을 늘리는 대신 그래프 품질을 향상할 수 있습니다.

이 비용은 모든 쿼리마다가 아니라 구축 또는 재구축 중에 발생합니다. 자주 변경되지 않는 개인 데이터 모음이라면, 벡터 정밀도를 영구적으로 높이지 않고도 검색 품질을 개선할 수 있으므로 구축에 더 많은 시간을 투자하는 것이 허용될 수 있습니다.

그러나 그래프의 규모가 지나치게 작으면 구축 작업량을 무한정 늘려도 보완할 수 없습니다. `m`, 구축 범위, 데이터 분포, 삽입 이력은 서로 영향을 주고받습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Ef 검색은 영구적인 그래프 메모리 대신 쿼리 작업량을 사용합니다

쿼리 시점에 HNSW는 후보 프런티어를 유지하고 유망한 그래프 노드를 탐색합니다. 일반적으로 `ef`, `ef_search` 또는 `hnsw_ef`라고 부르는 매개변수는 해당 탐색 중 고려 대상으로 유지되는 후보 수를 제어합니다.

쿼리 탐색 범위를 늘리면 요청이 가장 가까운 결과를 확정하기 전에 더 많은 그래프 후보를 검사할 수 있어, 일반적으로 재현율이 높아지는 대신 쿼리 지연 시간이 증가합니다.

`m`과 달리 쿼리 `ef`를 높여도 저장된 모든 노드가 더 많은 영구 간선을 유지할 필요는 없습니다. 주요 비용은 해당 요청에서 추가 거리 계산, 메모리 액세스 및 지연 시간으로 나타납니다. 이 차이 덕분에 홈 서버에서는 두 가지 서로 다른 조절 장치를 사용할 수 있습니다. 그래프 연결성은 지속적인 인덱스 메모리 사용량을 결정하고, 쿼리 범위는 추가 작업이 필요한 어려운 검색에만 높일 수 있습니다.

벡터 압축으로 HNSW 그래프 비용이 사라지지는 않습니다

임베딩을 양자화하면 저장된 각 벡터의 크기를 크게 줄일 수 있지만, HNSW에는 여전히 이웃 관계가 필요합니다. 따라서 전체 인덱스에는 최소한 벡터 데이터와 그래프 토폴로지라는 두 가지 주요 메모리 구성 요소가 포함됩니다.

벡터 값이 압축되어도 양자화가 그래프 링크를 줄이지는 않습니다. HNSW는 이러한 벡터 주변의 토폴로지, ID 및 관련 구조를 여전히 필요로 합니다.

따라서 벡터 압축률이 4배 이상이어도 전체 HNSW 메모리가 같은 비율로 줄어든다고 자동으로 볼 수 없습니다. 그래프 간선, 객체 ID, 메타데이터, 메모리 할당자 오버헤드 및 캐시는 그대로 남습니다.

소형 홈 서버에서는 벡터 차원만으로 RAM을 추정하지 말고 컬렉션 전체의 실제 상주 메모리 사용량을 측정하세요.

재현율은 설정에서 추정하지 말고 정확한 이웃과 비교해 측정해야 합니다

높은 `m`과 `ef`는 일반적으로 시스템을 더 나은 재현율 쪽으로 이끌지만, 어떤 매개변수 값도 모든 임베딩 모델, 데이터 모음 크기 또는 문서 분포에서 일정한 정확도를 보장하지는 않습니다.

여러 RAG 컬렉션의 HNSW 그래프 메모리 비용은 여러 개인 컬렉션이 로컬 모델, 메타데이터 인덱스, 캐시 및 기타 홈 서버 서비스를 함께 활성 상태로 유지할 때 누적됩니다.

대표적인 쿼리 세트를 만들고, 관리 가능한 샘플에서 근사 검색 결과를 정확한 전체 검색 결과와 비교하세요. 재현율, 지연 시간, 인덱스 RAM, 구축 시간 및 동시 요청의 영향을 추적해야 합니다. 따라서 실제 HNSW 절충은 “RAM이 많을수록 항상 검색이 좋아진다”가 아닙니다. 측정된 재현율을 충족하면서 나머지 홈 AI 스택의 리소스를 잠식하지 않도록 충분한 그래프 연결성과 쿼리 탐색 범위를 선택하는 것이 핵심입니다.