
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s tech blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, distributed training, and data engineering.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Thu, 16 Jul 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/ann-index/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/2026-07-16-elasticsearch-bbq-disk-hnsw-default</guid>
    <title>벡터 인덱스의 기본값이 HNSW에서 디스크로 바뀐 이유 — Elasticsearch bbq_disk의 트레이드오프</title>
    <link>https://www.youngju.dev/blog/2026-07-16-elasticsearch-bbq-disk-hnsw-default</link>
    <description>Elasticsearch 9.4(2026-05-05)부터 float 벡터의 기본 인덱스 타입이 bbq_disk, 즉 디스크 기반 IVF로 바뀌었습니다. 1년 사이에 기본값이 int8_hnsw에서 bbq_hnsw로, 다시 그래프가 아닌 디스크 인덱스로 옮겨간 것인데, 이 이동은 벡터 검색의 진짜 비용이 계산이 아니라 RAM에 있다는 판단을 담고 있습니다. 이 글은 HNSW의 메모리 절벽이 벤더 벤치마크에서 어떤 숫자로 나타나는지, BBQ가 원 논문 RaBitQ에서 무엇을 가져오고 이론적 오차 한계를 어떻게 버렸는지(그리고 9.4에서 어떻게 일부 되돌렸는지), DiskBBQ가 recall 95% 언저리에서 멈추는 이유를 정리합니다. 또 2026년 6~7월 Elastic과 Qdrant 사이에 오간 벤치마크 공방을 뜯어봅니다 — 디스크 읽기를 헤드라인으로 내건 벤치마크에서 정작 디스크는 0 IOPS로 잠들어 있었고, 숫자를 실제로 움직인 것은 세그먼트 개수였습니다. 기본값이 Enterprise 라이선스에 묶여 있다는 점을 포함해, 언제 쓰지 말아야 하는지까지 다룹니다.</description>
    <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>vector-database</category><category>elasticsearch</category><category>ann-index</category><category>quantization</category><category>hnsw</category>
  </item>

    </channel>
  </rss>
