평행이론을 검색한다면? HNSW(Hierarchical Navigable Small World) 완전 정복, AI 시대의 핵심 검색 엔진

평행이론을 검색한다면? HNSW(Hierarchical Navigable Small World) 완전 정복, AI 시대의 핵심 검색 엔진

벡터 데이터베이스가 1억 개 임베딩에서 0.001초 만에 답을 찾는 비밀

“알리바바가 HNSW를 쓴다는 이야기를 듣고 호기심에 공부를 시작했는데, 어느 순간 머릿속에서 영화 한 편이 펼쳐졌습니다. 한 사람이 여러 차원에 동시에 살고 있는 SF영화처럼, HNSW 그래프 위에서는 같은 데이터가 서로 다른 층에 동시에 존재하면서 검색을 도와주고 있었습니다. 평행이론이 가장 정확하게 구현된 자료구조라고 해도 과언이 아닐 것입니다.

이번 글에서는 HNSW(Hierarchical Navigable Small World)가 도대체 무엇이고, 왜 ChatGPT·Claude 같은 LLM 시대의 사실상 표준 검색 알고리즘이 되었는지를 차근차근 풀어보겠습니다. 탄생 배경부터 그래프 구성 방법, 검색 동작 원리, 그리고 같은 자리에서 경쟁하는 IVF·LSH·Annoy·ScaNN·DiskANN까지 한 번에 비교해 드리겠습니다.

01왜 지금 HNSW인가

2022년 ChatGPT 등장 이후 가장 폭발적으로 성장한 인프라가 무엇인지 묻는다면, 많은 엔지니어들이 벡터 데이터베이스(Vector Database)를 꼽을 것입니다. RAG(Retrieval-Augmented Generation), 시맨틱 검색, 추천 시스템, 이미지·음성 검색이 전부 벡터 검색을 기반으로 동작하기 때문입니다.

그런데 문제가 하나 있습니다. LLM이 만들어내는 임베딩 벡터는 보통 768차원에서 3,072차원에 달합니다. 차원이 이렇게 높으면 우리가 학교에서 배운 모든 검색 알고리즘이 사실상 무력화됩니다. 이른바 차원의 저주(Curse of Dimensionality)라는 현상입니다.

1,536

OpenAI 임베딩
차원 수(예시)

10⁸+

대규모 서비스의
벡터 개수

<10ms

서비스 요구
응답 시간

95%+

필요한 검색
정확도(Recall)

1억 개 벡터를 매번 전부 비교하는 완전 탐색(Brute-force)은 수 초가 걸립니다. 사용자는 그것을 기다려주지 않습니다. 그래서 등장한 것이 ANN(Approximate Nearest Neighbor, 근사 최근접 이웃)이라는 분야이고, 그 안에서 가장 보편적으로 채택된 알고리즘이 바로 HNSW입니다.

한 줄 정의 HNSW는 고차원 벡터 공간에서 “가장 비슷한 이웃”을 빠르게 찾기 위해, 데이터를 여러 층(Hierarchy)으로 쌓아 만든 그래프 자료구조입니다. 위층은 듬성듬성, 아래층은 빽빽하게 채워 두는 방식인데, 마치 고속도로(상위층)와 골목길(하위층)이 함께 있는 도로망처럼 동작합니다.

02핵심 직관: 6단계 분리 이론과 “작은 세상”

HNSW를 이해하려면 먼저 “Small World(작은 세상)” 현상을 알아야 합니다. 1967년 사회심리학자 스탠리 밀그램은 “지구상 임의의 두 사람은 평균 6명의 지인을 거쳐 연결된다”는 실험 결과를 발표했습니다. 이른바 6단계 분리 이론(Six Degrees of Separation)입니다.

여기서 한 가지 흥미로운 통찰이 나옵니다. 친구 관계 그래프를 보면, 대부분의 사람은 가까운 지역의 친구(짧은 링크)와 함께 아주 멀리 떨어진 곳의 친구(긴 링크) 몇 명을 가지고 있습니다. 짧은 링크는 “정밀 탐색”을, 긴 링크는 “먼 거리 점프”를 가능하게 합니다. 이 두 종류의 링크가 섞여 있을 때, 그래프는 놀라울 만큼 빠르게 임의의 노드에 도달할 수 있습니다.

HNSW는 이 원리를 그대로 자료구조로 옮긴 것입니다. 가까운 이웃들끼리 빽빽하게 연결하면서, 동시에 일부 노드는 멀리까지 점프하는 “긴 다리”를 갖도록 그래프를 설계합니다. 여기에 한 가지 묘수가 더 추가되는데, 바로 계층(Hierarchy)입니다.

03탄생의 역사: NSW에서 HNSW로

2011~2014

NSW(Navigable Small World) 알고리즘 제안

러시아 출신 연구자 Yury Malkov 등이 “작은 세상 그래프”를 ANN 검색에 직접 적용한 논문을 발표하였습니다. 노드를 하나씩 추가할 때마다 가까운 이웃 M개와 연결하는 단순한 규칙이지만, 검색 성능이 기존 트리 기반 방식보다 크게 향상되어 학계의 주목을 받았습니다.

2016

HNSW 논문 공개 (Malkov & Yashunin)

arXiv에 “Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs” 논문이 공개되었습니다. NSW에 스킵 리스트(Skip List)의 계층 아이디어를 결합한 것이 핵심 혁신이었습니다. 이로써 검색 복잡도가 기대값 기준 로그 시간(O(log N))까지 떨어졌습니다.

2018~2019

FAISS·NMSLIB 등 라이브러리 통합

Meta(당시 Facebook)의 FAISS, 오픈소스 NMSLIB·hnswlib 등이 HNSW를 정식 지원하면서 산업계에 빠르게 확산되었습니다. 같은 시기 Elasticsearch·OpenSearch도 ANN 기능을 도입하기 시작합니다.

2020~현재

벡터 DB 시대의 사실상 표준

Milvus·Weaviate·Qdrant·Pinecone·pgvector·Redis 등 거의 모든 주요 벡터 데이터베이스가 HNSW를 기본 인덱스 옵션으로 채택하였습니다. 알리바바·텐센트 같은 대형 클라우드 사업자들의 검색·추천 인프라 내부에서도 광범위하게 사용되고 있습니다.

스킵 리스트와의 연결고리 스킵 리스트는 정렬된 데이터를 빠르게 검색하기 위해 William Pugh가 1989년에 고안한 자료구조입니다. 위층은 데이터를 듬성듬성, 아래층은 모두 포함하여 위에서 아래로 내려가며 점점 정밀하게 탐색합니다. HNSW는 이 아이디어를 “정렬된 키” 대신 “고차원 거리”에 적용한 변형이라고 볼 수 있습니다.

04HNSW의 구성: 어떻게 그래프를 쌓는가

HNSW의 구조를 한 그림으로 표현하면 다음과 같습니다. 위로 올라갈수록 노드가 적고, 맨 아래(Layer 0)에는 모든 데이터가 들어 있습니다. 같은 노드가 여러 층에 동시에 존재할 수 있다는 점이 “평행이론” 비유에 딱 맞아떨어집니다.

▼ HNSW 계층 구조 시각화

Layer 3

고속도로 · 매우 적음

Layer 2

국도 · 적음

Layer 1

도시 도로 · 보통

Layer 0

골목길 · 전체 데이터

노드를 어느 층까지 쌓을지 결정하는 법

새로운 벡터가 들어올 때, HNSW는 그 노드가 도달할 최상위 레이어 L을 다음 식으로 무작위 결정합니다.

// 새 노드의 최상위 레벨 계산
L = floor(-ln(rand(0,1)) * mL)

// mL은 레벨 분포를 조절하는 정규화 상수
// 보통 mL = 1 / ln(M) 으로 설정

이 공식은 지수 분포(exponential decay)를 따릅니다. 결과적으로 대부분의 노드는 Layer 0에만 머물고, 극히 일부만 위층까지 올라갑니다. 마치 도시 인구 분포처럼 “위로 갈수록 희박해지는” 자연스러운 피라미드가 만들어지는 것입니다.

핵심 파라미터 세 가지

M

M : 노드당 연결 이웃 수

각 노드가 같은 층에서 연결할 이웃의 최대 개수입니다. 보통 8~64 사이로 설정합니다. 값이 클수록 검색 품질은 올라가지만, 메모리 사용량과 인덱스 빌드 시간이 늘어납니다. 일반적인 권장값은 M=16~32입니다.

eC

ef_construction : 빌드 시 후보군 크기

인덱스를 만들 때, 새 노드의 “이웃 후보”를 얼마나 넓게 탐색할지 결정합니다. 값이 클수록 더 정확한 그래프가 만들어지지만 빌드 시간이 길어집니다. 보통 100~500 정도를 사용합니다.

ef

ef (또는 ef_search) : 검색 시 후보군 크기

실제 검색 단계에서 동시에 추적하는 후보 노드의 개수입니다. 이 값을 키우면 정확도가 올라가고, 줄이면 속도가 올라갑니다. 서비스 운영자가 가장 자주 튜닝하는 파라미터입니다. 보통 50~400 사이에서 결정합니다.

인덱스 빌드 절차 요약

1. 새 노드의 최상위 레벨 L을 위 공식으로 계산합니다.
2. 최상위층(top layer)의 진입점(entry point)에서부터 탐욕적 탐색(Greedy Search)을 시작합니다.
3. L+1층까지는 한 노드만 추적하며 가장 가까운 이웃까지 내려갑니다.
4. L층부터는 ef_construction 크기의 후보군을 유지하면서 그래프를 따라 내려가며 가장 가까운 M개를 골라 양방향 연결을 만듭니다.
5. 이 과정을 Layer 0까지 반복하면 노드 삽입이 완료됩니다.

05HNSW의 검색: 위에서 아래로 내려가는 여정

실제 질의 벡터(query vector)가 들어왔을 때 HNSW가 어떻게 동작하는지 단계별로 살펴보겠습니다. 큰 그림은 의외로 단순합니다. “상위층에서 대략적인 방향을 잡고, 하위층에서 정밀하게 좁힌다”가 전부입니다.

1

최상위층 진입점에서 출발

미리 지정된 entry point에서부터 검색이 시작됩니다. 이 노드는 그래프 빌드 과정에서 가장 높은 레벨에 도달했던 노드입니다.

2

탐욕적 점프 (Greedy Routing)

현재 노드의 이웃들을 살펴보고, 그중 질의 벡터에 가장 가까운 이웃으로 이동합니다. 더 이상 가까워지는 이웃이 없으면 그 층의 “지역 최소점”에 도달한 것입니다.

3

한 층 내려가기

바로 아래층의 같은 노드로 이동하여 다시 탐욕적 점프를 시작합니다. 위층에서는 듬성듬성한 “고속도로”를 따라 빠르게 이동했고, 내려갈수록 점점 더 세밀한 도로망을 따라가게 됩니다.

4

Layer 0에서 정밀 탐색

맨 아래층에 도착하면 ef 크기의 후보군을 유지하면서 폭넓게 이웃을 탐색합니다. 이때부터는 단순 탐욕이 아니라, 우선순위 큐를 사용하여 가장 가까운 ef개의 후보를 항상 추적합니다.

5

상위 K개 결과 반환

최종 후보군에서 거리 순으로 정렬하여 top-K(예: 10개)를 반환합니다. 이 결과가 RAG 파이프라인이라면 LLM에게 컨텍스트로 전달되고, 추천 시스템이라면 사용자에게 노출됩니다.

왜 빠른가 상위층의 노드는 보통 전체의 1% 미만이기 때문에 “먼 거리 점프”를 단숨에 해낼 수 있습니다. 일단 정답 근처까지 빠르게 도달한 뒤, Layer 0에서 정밀하게 좁혀나가는 2단계 전략이 HNSW의 속도 비결입니다. 이론적으로는 데이터 개수 N에 대해 O(log N)의 기대 복잡도를 가집니다.

06왜 AI/LLM과 잘 어울리는가

HNSW가 AI 시대에 폭발적으로 채택된 이유는 단순히 “빠르기 때문”만이 아닙니다. 임베딩 기반 AI 시스템과 궁합이 잘 맞는 구체적인 이유가 있습니다.

1) 차원 수에 비교적 둔감합니다

고전적인 KD-Tree, R-Tree 같은 공간 분할 자료구조는 차원이 20만 넘어가도 성능이 급격히 무너집니다. 반면 HNSW는 그래프 구조이기 때문에 1,536차원, 3,072차원에서도 안정적으로 동작합니다.

2) 동적 추가에 강합니다

RAG 시스템은 사용자 문서가 계속 추가되는 환경입니다. HNSW는 노드 단위 삽입이 자연스럽게 지원되어, 인덱스를 처음부터 다시 만들 필요가 없습니다. 반면 IVF 계열은 클러스터 학습이 필요하여 대량 추가 후 주기적인 재학습이 필요합니다.

3) 코사인 거리·내적 거리와 잘 맞습니다

대부분의 임베딩 모델은 코사인 유사도(cosine similarity)를 전제로 설계됩니다. HNSW는 거리 함수에 종속적이지 않아서 L2(유클리드), 코사인, 내적, 해밍 거리 등 무엇이든 끼워 넣을 수 있습니다.

4) 양자화(Quantization)와 결합 가능합니다

메모리가 부족할 때는 HNSW + Product Quantization, HNSW + Scalar Quantization을 함께 써서 사용량을 1/4 ~ 1/16까지 줄일 수 있습니다. Faiss·Milvus 등이 이 조합을 적극 지원합니다.

07경쟁 기술 비교: HNSW vs IVF vs LSH vs Annoy vs ScaNN vs DiskANN

HNSW가 만능은 아닙니다. 데이터 규모, 메모리 제약, 갱신 빈도에 따라 더 좋은 선택지가 있을 수 있습니다. 같은 ANN 영역에서 자주 비교되는 주요 알고리즘을 정리해 드리겠습니다.

IVF (Inverted File Index)

Faiss · 클러스터 기반

전체 벡터를 K개의 클러스터(셀)로 미리 나누어 두고, 질의 벡터와 가까운 몇 개의 클러스터 안에서만 검색합니다. 보통 Product Quantization과 결합되어 IVFPQ로 사용되며, 메모리 효율이 매우 뛰어나 수십억 단위 벡터에 강합니다.

대용량 친화 메모리 효율 사전 학습 필요

LSH (Locality-Sensitive Hashing)

고전 학술 알고리즘

비슷한 벡터끼리는 같은 해시 버킷에 들어가도록 설계된 해시 함수를 사용합니다. 이론적 보장이 깔끔하고 분산 환경에 친화적이지만, 실제 고차원 데이터에서는 HNSW보다 정확도-속도 트레이드오프가 떨어지는 경우가 많습니다.

분산 친화 이론적 보장 고차원 약함

Annoy (Approximate Nearest Neighbors Oh Yeah)

Spotify 오픈소스 · 트리 기반

랜덤 프로젝션을 사용한 이진 트리 여러 개로 구성되는 포레스트입니다. 인덱스를 메모리 매핑(mmap) 파일로 저장할 수 있어 읽기 전용 대용량 추천 시스템에 강점이 있습니다. 단점은 인덱스 빌드 후 추가가 어렵다는 점입니다.

mmap 친화 읽기 전용 강함 동적 추가 약함

ScaNN (Scalable Nearest Neighbors)

Google 연구 · 양자화 중심

Anisotropic Vector Quantization이라는 새로운 양자화 기법을 도입하여, 유사도 보존이 우수한 ANN을 구현했습니다. CPU 단일 노드 기준 벤치마크에서 매우 좋은 성능을 보이며, Google 자체 검색·광고 시스템 일부에 활용된 것으로 알려져 있습니다.

고성능 벤치마크 양자화 최적화 생태계 작음

DiskANN

Microsoft 연구 · SSD 기반

HNSW의 그래프 아이디어를 차용하되, SSD 위에 저장된 인덱스를 효율적으로 탐색하도록 설계되었습니다. 단일 노드에서 수십억 벡터를 다룰 수 있어 메모리 비용을 극적으로 줄이는 것이 강점입니다.

SSD 활용 초대용량 구현 복잡

FAISS (라이브러리)

Meta 오픈소스 · 통합 도구

엄밀히 말하면 알고리즘이 아니라 라이브러리입니다. Flat(완전탐색)·IVF·IVFPQ·HNSW·HNSW+PQ 등 거의 모든 ANN 옵션을 한 곳에서 제공합니다. 산업계의 사실상 표준 ANN 툴킷이며, 많은 벡터 DB가 내부적으로 FAISS를 채택하거나 호환됩니다.

옵션 풍부 GPU 지원 생태계 거대

한눈에 보는 비교표

알고리즘	구조	강점	약점	적합한 상황
HNSW	계층 그래프	고차원 정확도/속도 균형, 동적 삽입	메모리 사용량 큼	RAG, 시맨틱 검색 일반
IVF / IVFPQ	클러스터 + 양자화	메모리 효율, 초대용량	사전 학습, 정확도 손실	10억+ 벡터 검색
LSH	해시 버킷	분산·이론 단순	고차원 품질 저하	분산 시스템, 학술
Annoy	랜덤 트리 포레스트	mmap, 읽기 전용 빠름	동적 추가 곤란	음악·콘텐츠 추천
ScaNN	양자화 + 트리	최신 양자화 기법	생태계 작음	CPU 단일 노드 최적화
DiskANN	SSD 기반 그래프	메모리 비용 절감	구현·튜닝 복잡	예산 제약 대규모 시스템

08HNSW의 장점과 한계

▲ 강점

• 고차원 임베딩에서도 뛰어난 정확도 / 속도 균형
• 로그 시간 기대 복잡도(O(log N))
• 실시간 노드 추가가 자연스러움
• 거리 함수에 독립적(L2·코사인·내적 자유)
• 양자화·필터링과 결합 용이
• 거의 모든 주요 벡터 DB가 표준 지원

▼ 한계

• 그래프 자체가 메모리에 상주해야 하여 RAM 사용량이 큼
• 인덱스 빌드 시간이 IVF 대비 긴 편
• 대규모 일괄 삭제 시 그래프 품질 저하 가능
• 파라미터(M, ef) 튜닝에 경험이 필요함
• 최악의 경우(quasi-uniform 분포)에는 이론적 보장이 약함

09실제 어디에서 쓰이고 있는가

HNSW는 학술 알고리즘에서 출발하였지만, 지금은 거의 모든 산업계 벡터 검색 인프라의 기본 옵션이 되었습니다.

• 벡터 DB : Milvus, Weaviate, Qdrant, Vespa, Pinecone(내부 알고리즘 중 하나), pgvector(PostgreSQL 확장), Redis Vector Search
• 검색 엔진 : Elasticsearch, OpenSearch, Solr 등이 ANN 인덱스 옵션으로 HNSW를 채택
• 추천 시스템 : 사용자 임베딩과 콘텐츠 임베딩 사이의 ANN 매칭에 폭넓게 사용
• RAG / LLM 애플리케이션 : LangChain·LlamaIndex 등 프레임워크가 기본 백엔드로 HNSW 지원 DB를 권장
• 대형 클라우드 벤더 : 알리바바, 텐센트, AWS, Azure, GCP 등이 자사 매니지드 벡터 검색 서비스에 HNSW 또는 그 변형을 활용

10운영 관점의 실전 팁

파라미터 튜닝 가이드

• M = 16에서 시작하여, 정확도가 부족하면 24·32까지 올려보시기 바랍니다.
• ef_construction = 200이 일반적인 기본값입니다. 인덱스 빌드 시간이 충분하다면 400~500까지 올리면 품질이 좋아집니다.
• ef는 운영 단계에서 트래픽에 따라 동적으로 조절하는 것이 유리합니다. 평소 100, 피크 시간대 50, 정확도 우선 시 300 같은 식입니다.

메모리 산정 공식

대략적으로 HNSW의 그래프 메모리는 다음과 같이 추정할 수 있습니다.

// 매우 단순화한 추정식
graph_memory ≈ N × M × 2 × (4 bytes for int32 ID)
vector_memory ≈ N × dim × (4 bytes for float32)

// 예시: 1,000만 × 768차원, M=32
// 그래프 = 10M × 32 × 2 × 4 = 약 2.4 GB
// 벡터 = 10M × 768 × 4 = 약 28.6 GB
// 합계 = 약 31 GB

벡터 자체가 차지하는 비중이 압도적으로 큽니다. 그래서 대규모 운영에서는 HNSW + Scalar Quantization이나 HNSW + Product Quantization 조합으로 벡터 부분을 1/4 ~ 1/16까지 줄이는 것이 일반적입니다.

언제 HNSW를 쓰지 말아야 하는가

• 벡터가 100만 개 미만이면서 응답 시간 요구가 느슨한 경우 → 단순 Brute-force가 더 단순하고 정확합니다.
• 10억 개 이상의 초대용량 + 메모리 예산이 빠듯한 경우 → IVFPQ 또는 DiskANN을 검토해 보시기 바랍니다.
• 인덱스를 한 번 빌드한 뒤 거의 갱신되지 않는 읽기 전용 대용량 추천 → Annoy도 좋은 선택지입니다.

마치며, 평행이론과 “좋은 자료구조”의 의미

처음 HNSW를 공부하면서 떠올린 평행이론 비유는, 단지 재미있는 상상에 그치지 않는다는 점이 가장 흥미로웠습니다. 같은 데이터가 여러 층에 동시에 “존재”하면서 다른 역할을 수행한다는 발상은, 사실 컴퓨터 과학에서 오랫동안 좋은 성과를 내어 온 패턴이기도 합니다. 스킵 리스트, B-Tree, LSM Tree 같은 구조들이 모두 비슷한 철학을 공유합니다.

AI 시대가 “계산을 누가 더 잘하느냐”의 시대처럼 보이지만, 그 밑단에는 결국 “데이터를 어떻게 잘 정리해 두느냐”라는 고전적인 질문이 있습니다. HNSW가 그 답 중 하나로 자리 잡은 과정은, 좋은 자료구조 한 줄이 어떻게 산업의 인프라가 되는지를 보여주는 좋은 사례라고 생각합니다.

중국에서 일하면서 알리바바·텐센트 같은 회사들이 같은 알고리즘을 활용하고 있다는 사실을 접하다 보면, 좋은 알고리즘은 국경과 무관하게 빠르게 표준이 된다는 점을 다시 한번 실감하게 됩니다. HNSW 한 가지만 깊게 알아도, 그 주변으로 가지를 뻗는 흥미로운 주제가 정말 많습니다.

NEXT POST CANDIDATES

다음 글에서 다뤄볼 만한 이야기들

HNSW 한 가지를 깊게 파다 보면 곁가지로 떠오르는 흥미로운 주제가 의외로 많습니다. 다음 글의 후보로 고민 중인 다섯 가지를 메모처럼 남겨 둡니다.

CANDIDATE 01

Product Quantization (PQ): 1억 개 벡터를 메모리 1/16로 압축하는 양자화의 마법

HNSW의 약점이 메모리라면, PQ는 그 약점을 가장 우아하게 가려주는 짝꿍입니다. 768차원 float32 벡터를 단 8바이트 코드로 줄여도 검색 품질이 유지되는 이유, 그리고 IVFPQ가 어떻게 수십억 단위 벡터를 단일 서버에서 처리하는지를 풀어보고 싶습니다.

반도체 관점에서 보면, 결국 DRAM 비용 절감 이야기로도 연결됩니다.

CANDIDATE 02

벡터 DB 5종 실전 비교: Milvus vs Qdrant vs Weaviate vs Pinecone vs pgvector

다섯 DB 모두 HNSW를 지원하지만 운영 특성은 전혀 다릅니다. 어느 것이 한국 스타트업에게 합리적이고, 어느 것이 대규모 엔터프라이즈에 적합한지, 그리고 PostgreSQL 안에 그냥 얹는 pgvector가 어디까지 버틸 수 있는지를 표로 정리해 보고 싶습니다.

실제 RAG 도입을 고민하는 분들이 가장 자주 묻는 질문이기도 합니다.

CANDIDATE 03

Hybrid Search: BM25 + 벡터 검색, 왜 둘을 섞어야 하는가

시맨틱 검색이 만능처럼 보이지만, 제품명·고유명사·숫자 같은 “정확히 일치해야 하는” 검색에서는 의외로 약합니다. BM25(키워드 검색)와 HNSW(벡터 검색)를 RRF(Reciprocal Rank Fusion) 한 줄 공식으로 합치면 무엇이 달라지는지 실험과 함께 다뤄볼 만합니다.

Elasticsearch·OpenSearch가 최근 가장 힘을 쏟는 영역이기도 합니다.

CANDIDATE 04

중국 임베딩 모델 BGE 시리즈: OpenAI ada보다 작고 빠른 오픈소스 도전자

베이징의 BAAI(智源研究院)가 공개한 BGE 시리즈는 한국·중국·영어 다국어 벤치마크에서 OpenAI text-embedding 모델을 흔드는 중입니다. 같은 HNSW 인덱스 위에서 임베딩 모델만 바꾸어도 RAG 품질이 어떻게 달라지는지, 중국 현지에서 어떤 분위기로 받아들여지는지를 정리하고 싶습니다.

중국 AI 인프라를 가장 잘 보여줄 수 있는 소재 중 하나입니다.

CANDIDATE 05

DiskANN: SSD가 만든 HNSW의 다음 세대

Microsoft가 제시한 DiskANN은 “비싼 DRAM 대신 NVMe SSD에 그래프를 올려도 충분히 빠르게 검색할 수 있다”는 발상의 전환입니다. 반도체·스토리지 시장 입장에서 보면, AI 인프라 비용 구조 자체를 흔드는 시도라는 점에서 의미가 큽니다.

반도체 현장에서 일하는 입장에서 가장 흥미로운 후보이기도 합니다.

▼ TAGS

#HNSW #벡터검색 #벡터데이터베이스 #ANN알고리즘 #임베딩 #RAG #FAISS #Milvus #AI인프라 #시맨틱검색