커뮤니티 소식
5천개 문서에선 '무식한 검색'이 빠르다? HNSW 직접 구현한 개발자의 흥미로운 벤치마크
글 · 서아람
최근 레딧 머신러닝 커뮤니티에서 흥미로운 게시물이 화제가 됐습니다. 대규모 언어 모델(LLM)의 핵심 기술인 벡터 검색에 사용되는 HNSW(Hierarchical Navigable Small World) 알고리즘을 직접 구현해 본 한 개발자가 놀라운 벤치마크 결과를 공유했기 때문입니다. 개발자는 수천 개 단위의 비교적 작은 문서 세트에서는 최적화된 HNSW 구현체인 FAISS조차도 '무차별 대입(brute force)' 방식보다 느릴 수 있다는 실험 결과를 제시해 많은 이들의 이목을 집중시켰습니다. 마치 고급 슈퍼카가 좁은 골목길에서는 경차보다 효율이 떨어질 수 있다는 이야기와 비슷합니다.
이 개발자는 FAISS 같은 라이브러리를 블랙박스처럼 사용하지 않고 HNSW의 작동 원리를 깊이 이해하기 위해 처음부터 코드를 작성했다고 밝혔습니다. 그는 BM25와 직접 만든 역색인(inverted index)을 기반으로 검색 엔진을 구축하고, Malkov & Yashunin 논문에 기반한 HNSW를 구현한 뒤, RRF(Reciprocal Rank Fusion) 방식으로 이들을 융합했습니다. 그리고 NFCorpus(3,633개 문서)와 SciFact(5,183개 문서) 데이터셋에 대해 자신의 구현체와 FAISS, `bm25s`, `rank_bm25`를 비교 벤치마킹했습니다. 여기서 뜻밖의 결과가 나왔습니다. 문서 수가 5천 개 미만인 경우, HNSW를 포함한 여러 최신 벡터 검색 방식보다 단순한 무차별 대입 방식(혹은 이에 준하는 BM25)의 중앙값 지연 시간이 더 짧게 측정된 것입니다.
이는 '벡터 검색은 무조건 빠르다'는 일반적인 통념에 반하는 결과로, 많은 AI 개발자들에게 시사하는 바가 큽니다. HNSW와 같은 Approximate Nearest Neighbor(ANN) 검색 알고리즘은 방대한 데이터셋에서 고차원 벡터 간의 유사도를 효율적으로 찾기 위해 설계되었습니다. 이들은 복잡한 그래프 구조를 구축하고 유지하는 데 상당한 오버헤드를 가집니다. 데이터셋 규모가 충분히 크지 않으면, 이러한 인덱스 구축 및 탐색 과정의 오버헤드가 무차별 대입 방식의 직접적인 비교 효율성을 넘어서지 못하는 것입니다. 반면 무차별 대입 방식은 별도의 인덱스 구조 없이 모든 항목을 하나씩 비교하므로, 데이터가 적을 때는 그 단순성에서 오는 이점이 빛을 발합니다.
물론 이 결과가 HNSW나 FAISS의 효용성을 부정하는 것은 결코 아닙니다. 업계 전문가들은 HNSW가 수십만, 수백만 개 이상의 대규모 벡터 데이터셋에서 압도적인 성능을 발휘한다는 데 이견이 없습니다. 이번 벤치마킹 결과는 '어느 시점부터' 복잡한 알고리즘이 진정한 가치를 발휘하는지에 대한 중요한 단서를 제공합니다. 작은 규모의 데이터셋을 다루는 초기 스타트업이나 특정 소규모 서비스에서는 지나치게 복잡한 벡터 데이터베이스 솔루션 대신 더 단순하고 직관적인 접근 방식이 초기 개발 및 운영 효율성 측면에서 유리할 수 있음을 보여줍니다. 결국 어떤 기술이든 '만능'은 없으며, 실제 사용 환경과 데이터 규모에 맞춰 최적의 솔루션을 선택하는 것이 중요하다는 점을 다시금 일깨워줍니다.
- HNSW는 복잡한 인덱스 구축 및 유지보수 오버헤드를 가집니다.
- 작은 규모 데이터셋에서는 이 오버헤드가 탐색 이점을 상쇄할 수 있습니다.
- 무차별 대입 방식은 추가적인 자료구조 없이 직접 비교하므로 오버헤드가 적습니다.
- 효율적인 벡터 검색은 데이터셋 규모와 쿼리 특성에 따라 최적의 알고리즘이 달라집니다.
인사이트
데이터 규모가 작을 때는 HNSW와 같은 복잡한 벡터 검색 알고리즘의 오버헤드가 무차별 대입 방식보다 더 커서 오히려 성능이 저하될 수 있으며, 이는 기술 선택 시 데이터 규모와 사용 환경을 고려해야 함을 보여주는 중요한 통찰입니다.
자주 묻는 질문
- 아니, 벡터 검색은 항상 빨라야 하는 거 아니야?
- 벡터 검색 알고리즘은 대규모 데이터셋에서 효율적이지만, 인덱스 구축 및 관리 오버헤드가 있습니다. 데이터 규모가 작을 때는 이 오버헤드가 탐색 이점보다 커질 수 있어 무차별 대입 방식이 더 빠를 때도 있습니다.
- 그럼 무조건 무차별 대입 쓰면 되는 거야?
- 아닙니다. 무차별 대입은 데이터 규모가 커지면 계산 비용이 급증해 비효율적입니다. 수천 단위의 작은 데이터셋에서는 고려할 만하지만, 수만, 수십만 개 이상의 문서에서는 HNSW와 같은 ANN 알고리즘이 필수적입니다.
- 이걸 내가 개발하는 서비스에 어떻게 적용해야 해?
- 서비스의 데이터 규모와 성장 가능성을 고려해야 합니다. 초기 단계의 소규모 데이터셋이라면 간단한 BM25나 무차별 대입으로 시작하고, 데이터가 커짐에 따라 HNSW와 같은 효율적인 ANN 알고리즘으로 전환하는 전략을 고려할 수 있습니다.
이 기사 어땠어요?
피드백을 남겨주시면 더 나은 맞춤 추천을 만듭니다.