컴팩션 후 벡터 데이터베이스가 서로 다른 이웃을 반환하는 이유는 무엇인가요?

벡터 데이터베이스는 컴팩션 후 서로 다른 이웃을 반환할 수 있습니다. 동일한 임베딩이 새로 구축된 근사 검색 구조로 재구성될 수 있기 때문입니다.

로컬 RAG 서버에서는 이 변화가 종종 의심스럽게 보입니다. 의도적으로 문서를 다시 임베딩하지 않았는데도 유지 관리 후 익숙한 쿼리의 상위 k개 목록이 약간 달라지기 때문입니다. 여기서 핵심은 벡터 값과 해당 벡터를 검색하는 ANN 인덱스를 구분하는 것입니다. 컴팩션은 전자를 유지하면서 후자를 다시 구축할 수 있습니다.

컴팩션은 여러 검색 세그먼트를 새 인덱스로 교체할 수 있습니다

벡터 데이터베이스에는 문서가 삽입, 업데이트, 삭제될 때 별도의 세그먼트가 누적되는 경우가 많습니다. 컴팩션은 이러한 조각을 통합하여 시스템이 검색해야 할 구조의 수를 줄이고, 더 이상 사용되지 않는 데이터를 적게 유지하도록 합니다.

Qdrant는 컬렉션을 영구적으로 고정된 하나의 그래프로 취급하기보다 세그먼트의 개수와 크기를 대상으로 하는 옵티마이저를 제공합니다. 컴팩션으로 더 크고 최적화된 세그먼트가 생성되면 논리적 벡터가 변경되지 않았더라도 물리적 검색 구조가 다시 구축될 수 있습니다.

이 구분은 개인용 RAG 인덱스에서 중요합니다. 유지 관리 전후의 임베딩이 수치상 완전히 동일하더라도 임베딩을 연결하는 근사 검색 그래프는 달라질 수 있습니다.

근사 최근접 이웃 검색은 그래프 위상에 좌우됩니다

HNSW는 쿼리를 모든 벡터와 비교하지 않습니다. 계층형 그래프를 탐색하며 유망한 연결을 제한적으로 따라가므로 그래프를 통과하는 경로에 따라 검사되는 후보가 달라집니다.

Elasticsearch는 세그먼트 병합 시 HNSW 그래프를 다시 계산해야 할 수 있다고 설명합니다. 구축 순서, 삭제 상태, 그래프 휴리스틱이 간선에 영향을 주기 때문에 그래프를 다시 구축하면 동일한 벡터가 서로 다르게 연결될 수 있습니다.

두 후보의 거리가 매우 비슷한 경우, 위상의 작은 변화만으로도 한 후보는 후보 집합에 들어가고 다른 후보는 아예 방문되지 않을 수 있습니다. 임베딩 모델이 변경되지 않았는데도 근사 이웃이 달라지는 이유입니다.

검색 매개변수에 따라 새 그래프를 얼마나 탐색할지가 결정됩니다

컴팩션 후 데이터베이스는 여러 개의 작은 그래프 대신 하나의 더 큰 그래프를 검색할 수 있습니다. 따라서 구성된 검색 예산이 동일해 보이더라도 같은 상위 k개 요청이 전혀 다른 후보 공간을 탐색할 수 있습니다.

Weaviate는 HNSW의 ef 검색 품질 절충을 설명합니다. 후보 목록을 크게 설정하면 일반적으로 재현율이 향상되지만 처리량은 증가합니다. 순위 경계 부근에서는 검색 노력이 적을수록 그래프 구축 방식에 따라 결과가 더 민감하게 달라집니다.

유용한 진단 방법은 소규모 테스트 세트에서 근사 검색 결과를 높은 ef 값 또는 정확한 검색 결과와 비교하는 것입니다. 정확한 이웃은 안정적인데 ANN 이웃만 바뀐다면 컴팩션이 벡터가 아니라 검색 경로를 변경한 것입니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

삭제와 업데이트는 재구축 후 어떤 노드가 남는지를 바꿉니다

컴팩션 전에는 삭제되거나 교체된 레코드가 삭제 표시나 세그먼트 수준의 관리 정보와 함께 물리적으로 남아 있을 수 있습니다. 검색 시에는 이들을 제외하지만, 과거에 해당 레코드가 존재했다는 사실이 이전에 구축된 그래프에 영향을 줄 수 있습니다.

Milvus는 HNSW가 원시 벡터와 함께 명시적인 그래프 구조를 저장한다고 설명합니다. 더 이상 사용되지 않는 레코드를 제거한 후 다시 구축하면 살아남은 벡터 집합을 기반으로 그래프가 생성됩니다.

이로 인해 해당 문서 자체를 편집하지 않았더라도 가정용 문서 주변의 연결성이 달라질 수 있습니다. 특정 메모리에 가까운 브리지 노드가 새로 생기거나 사라지면서 ANN 탐색이 처음 도달하는 영역이 바뀔 수 있습니다.

거리가 변하지 않아도 동점과 근접 동점의 순서는 뒤바뀔 수 있습니다

많은 개인 문서 모음에는 서로 거의 중복되는 자료가 포함되어 있습니다. 예를 들어 반복된 매뉴얼, 버전별 파일, 사진 설명, 복사한 메모리, 동일한 상용구가 있는 청크 등이 그렇습니다. 이들의 코사인 또는 내적 점수는 거의 구분되지 않을 수 있습니다.

Pinecone의 HNSW 설명은 그래프 탐색이 검사되는 벡터를 제한하는 방식을 보여줍니다. 두 항목이 결과 경계 부근에 있을 때 후보 경로 또는 동점 처리 순서가 달라지면 의미상 큰 차이가 없는데도 반환되는 상위 k개가 달라질 수 있습니다.

따라서 애플리케이션은 이웃 순위 7위와 8위의 차이를 지속적인 식별 정보로 취급해서는 안 됩니다. 결정론적 동작이 중요하다면 안정적인 문서 ID를 저장하고 실제 거리를 비교해야 합니다.

정확한 검색은 데이터 변동과 ANN 변동을 구분하는 기준입니다

가장 명확한 방법은 재현 가능한 소규모 쿼리 세트를 유지하고, 유지 관리 전후의 임베딩, 거리 측정 방식, 정확한 상위 k개, 근사 상위 k개, 인덱스 설정, 데이터베이스 버전을 기록하는 것입니다.

ZimaSpace의 개인용 검색에서 임베딩 도메인이 변화하는 현상에 대한 설명은 다른 종류의 장애를 다룹니다. 즉 벡터 공간 자체가 변하는 경우입니다. 컴팩션은 그 공간을 그대로 유지하면서 근사 검색 결과를 바꿀 수 있으므로 별도로 진단해야 합니다.

ZimaSpace의 문서 검색 및 RAG 워크플로 가이드는 애플리케이션 측면의 맥락을 제공합니다. ANN 계층이 근사 검색을 허용하더라도 안정적인 문서 식별과 평가는 중요합니다.

정확한 검색 결과도 달라진다면 벡터, 필터, 정규화, 거리 측정 방식 또는 데이터 버전을 점검해야 합니다. 정확한 결과는 그대로인데 ANN 결과만 달라진다면 원인은 인덱스 재구축, 검색 노력, 동점 처리 또는 세그먼트 배치에 있습니다.

따라서 컴팩션이 근사 인덱스에서 이웃 순서를 바이트 단위로 완전히 동일하게 보장할 것이라고 기대해서는 안 됩니다. 결정론적 순위를 원한다면 더 엄격한 검색 방식이나 애플리케이션 수준의 동점 처리 규칙이 필요합니다.

FAQ

컴팩션이 임베딩 벡터를 변경하나요?

컴팩션 자체로는 변경하지 않습니다. 일반적인 컴팩션 또는 세그먼트 병합은 저장소와 인덱스를 재구성합니다. 애플리케이션이 벡터 값을 다시 임베딩하거나, 재양자화하거나, 재정규화하거나, 그 밖의 방식으로 다시 작성하는 경우에만 임베딩이 변경됩니다.

컴팩션 후 정확한 최근접 이웃도 달라져야 하나요?

남아 있는 벡터, 거리 측정 방식, 수치 표현이 변경되지 않았다면 실제 점수 동점이나 부동소수점 구현상의 세부 차이를 제외하고는 동일하게 유지되어야 합니다.

HNSW를 다시 구축하면 이전 순위를 정확히 재현할 수 있나요?

항상 가능한 것은 아닙니다. HNSW는 근사 검색 방식이며 그래프 구축은 삽입 순서, 무작위화, 삭제, 구현 세부 사항에 민감할 수 있습니다. 정확한 순위를 얻으려면 모든 항목을 탐색하거나 그에 준하는 결정론적 비교가 필요합니다.