▲

Hacker News 댓글 2,800만 건을 벡터 임베딩 검색 데이터세트로 제공

 (clickhouse.com)
1P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • Hacker News 데이터세트는 2,874만 개의 게시글과 댓글을 포함하며, 각 텍스트는 SentenceTransformers all-MiniLM-L6-v2 모델로 생성된 384차원 벡터 임베딩으로 구성
  • 데이터는 ClickHouse에서 제공하는 단일 Parquet 파일(S3 버킷) 형태로 공개되어, 대규모 벡터 검색 애플리케이션 설계 및 성능 평가에 활용 가능
  • 예시 SQL 코드로 테이블 생성, 데이터 로드, HNSW 기반 벡터 유사도 인덱스 구축 및 검색 쿼리 실행 과정을 단계별로 설명
  • Python 예제에서는 SentenceTransformers로 쿼리 임베딩을 생성하고, ClickHouse에서 cosineDistance() 함수를 이용해 의미 기반 검색 수행
  • 이어지는 요약 데모 애플리케이션은 LangChain과 OpenAI GPT-3.5-turbo를 활용해 검색된 게시글을 요약하며, 기업용 생성형 AI 활용 사례로 확장 가능성 제시

Hacker News 벡터 검색 데이터세트 개요

  • 데이터세트는 Hacker News의 2,874만 개 게시물과 댓글을 포함하며, 각 항목은 SentenceTransformers all-MiniLM-L6-v2 모델로 생성된 384차원 벡터 임베딩을 포함
    • 임베딩은 문장과 단락의 의미를 포착하기 위한 로컬 임베딩 모델을 사용
  • 이 데이터세트는 사용자 생성 텍스트 데이터 기반의 대규모 벡터 검색 애플리케이션 설계, 크기 산정, 성능 분석에 활용 가능

데이터세트 세부 정보

데이터 로드 및 인덱스 구축 절차

  • hackernews 테이블은 게시글 ID, 텍스트, 벡터, 작성자, 시간, 점수 등 다양한 속성을 포함하도록 생성
  • 데이터 로드는 다음 SQL 명령으로 수행 
    INSERT INTO hackernews SELECT * FROM s3('https://clickhouse-datasets.s3.amazonaws.com/hackernews-miniLM/…');
    • 약 2,874만 행 삽입에 몇 분 소요
  • 벡터 유사도 인덱스는 HNSW 알고리듬과 cosineDistance를 사용해 생성 
    ALTER TABLE hackernews ADD INDEX vector_index vector TYPE vector_similarity('hnsw', 'cosineDistance', 384, 'bf16', 64, 512);
ALTER TABLE hackernews MATERIALIZE INDEX vector_index SETTINGS mutations_sync = 2;
    • M=64, ef_construction=512로 설정되며, CPU 코어 수와 스토리지 대역폭에 따라 인덱스 구축에 수 분~수 시간 소요 가능
  • 인덱스 구축 후, 벡터 검색 쿼리는 자동으로 인덱스를 활용 
    SELECT id, title, text
FROM hackernews
ORDER BY cosineDistance(vector, <search vector>)
LIMIT 10
    • 인덱스 메모리 로드에는 수 초~수 분 소요 가능

Python 기반 의미 검색 예제

  • Python 스크립트는 SentenceTransformers로 입력 쿼리의 임베딩을 생성하고, ClickHouse Connect를 통해 쿼리를 실행
  • cosineDistance() 함수를 사용해 입력 벡터와 데이터세트 벡터 간의 유사도를 계산
  • 예시 실행에서는 “Are OLAP cubes useful” 쿼리에 대해 상위 20개 관련 게시글을 출력
    • 출력 결과는 각 게시글의 ID와 텍스트 일부(100자)로 구성

요약 데모 애플리케이션

  • ClickHouse를 이용한 의미 검색 및 문서 검색 예시 이후, 생성형 AI 기반 요약 애플리케이션을 소개
  • 주요 단계
    1. 사용자로부터 주제 입력
    2. SentenceTransformers all-MiniLM-L6-v2로 주제 임베딩 생성
    3. ClickHouse에서 벡터 유사도 검색으로 관련 게시글/댓글 조회
    4. LangChain과 OpenAI gpt-3.5-turbo를 이용해 검색 결과 요약
  • 실행 예시에서는 “ClickHouse performance experiences” 주제로 검색 후 GPT-3.5가 요약 생성
    • 요약 내용은 ClickHouse의 성능, 단순성, 효율성, 대규모 분석 적합성을 강조하며, 일부 DML 및 백업 어려움도 언급
  • 이 애플리케이션은 고객 감정 분석, 기술 지원 자동화, 회의록 요약, 금융 문서 분석 등 다양한 기업용 생성형 AI 활용 사례로 확장 가능

요약 애플리케이션 코드 구성

  • Python 코드에서 SentenceTransformer, clickhouse_connect, LangChain, ChatOpenAI 등을 사용
  • 검색 결과를 결합해 GPT-3.5 모델에 입력하고, 최대 10문장 이내의 요약문을 생성
  • 입력 텍스트의 토큰 수에 따라 stuff 또는 map_reduce 체인을 선택해 처리
  • 결과는 “Summary from chatgpt-3.5:” 형식으로 출력됨
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 새로운 벡터 임베딩 데이터셋에는 all-MiniLM-L6-v2를 사용하지 말 것을 권장함
    이 모델은 초창기 튜토리얼에서 자주 쓰이던 sentence-transformers 기반의 실용적 모델이었지만, 이제는 오래되어 최신 아키텍처와 학습 파이프라인을 반영하지 못함
    컨텍스트 길이도 512로 짧음. 대신 EmbeddingGemma를 추천함. 2k 컨텍스트 윈도우를 지원하고 벤치마크 성능이 매우 좋음
    속도는 느리지만 가치가 있음. 절충안으로는 bge-base-en-v1.5나 nomic-embed-text-v1.5도 괜찮음

    • 요즘은 Qwen3-Embedding-0.6B를 선호함
      오픈 웨이트, 다국어 지원, 32k 컨텍스트를 제공함
    • 그래도 all-Mini의 장점은 클라이언트 사이드에서 실행 가능하다는 점임
      약 70MB로 작아서 다운로드가 쉬움. EmbeddingGemma는 300MB 이상이라 부담됨
      혹시 100MB 이하로 쓸만한 모델이 있을까 궁금함
    • EmbeddingGemma의 라이선스 문제가 아쉬움
      ‘Gemma 라이선스’가 모호해서 법적 검토가 필요할 수도 있음
      Google이 “제한된 사용” 목록을 바꾸면 언제든 사용 금지될 위험이 있음
    • 상용 임베딩 모델들 간의 비교가 궁금함
      예를 들어 Cohere vs OpenAI small vs OpenAI large 같은 비교 자료가 부족함
      어떤 기준으로 벤치마크해야 할지 모르겠음
    • 몇 주 전 EmbeddingGemma와 nomic-embed-text-v1를 AB 테스트했는데, nomic 쪽이 훨씬 좋은 결과를 냈음
      CPU에서도 잘 동작함

  • 2023년부터 모든 HN 댓글을 BigQuery에서 임베딩해 hn.fiodorov.es에 호스팅 중임
    소스 코드는 GitHub에 공개되어 있음

    • 직접 사용해봤는데 꽤 괜찮은 답변을 줬음
      “Who’s Gary Marcus”를 검색했더니 Google보다 부정적인 결과가 나왔음
      운영 비용이 얼마나 드는지 궁금함
    • GitHub 레포의 아키텍처 설명이 인상적이었음. 멋진 프로젝트임
    • 어떤 하드웨어로 임베딩을 생성했고, 얼마나 걸렸는지 궁금함
    • 사용자들이 자신의 데이터 삭제를 요청할 수 있는 이슈 제출 기능이 있는지 알고 싶음

  • HN의 Privacy 및 Data Policy에 따르면 댓글의 상업적 이용이 금지되어 있음
    벡터 표현도 기술적으로는 파생 저작물에 해당함

    • Y Combinator 이용 약관에 따르면
      사이트 콘텐츠를 상업적으로 복제, 배포, 수정, 파생물 생성 등을 금지함
      또한 데이터 마이닝, 스크래핑 등의 행위도 금지되어 있음
    • 물론 벡터는 파생물이지만, 내 기억도 마찬가지로 파생물임
      나는 내 기억의 외부 보조 장치로 벡터 데이터베이스를 만드는 것이 권리라고 생각함
    • 농담이지만, 내 댓글 전부 삭제 요청하려던 참이었음. 이제 그럴 필요가 없겠음
    • 그럼 OpenAI에도 누가 알려줘야겠음

  • HN에 “비슷한 문장 보기” 같은 우클릭 메뉴가 있으면 좋겠음
    이전에 같은 제안이 있었는지도 알 수 있을 듯함

    • 댓글과 스레드를 의미 기반으로 연결하면 정말 흥미로울 것 같음
      같은 논의가 다른 글에서 얼마나 반복되는지도 볼 수 있고,
      내가 쓰려는 말에 대한 과거 반응을 미리 확인할 수도 있음
      일종의 semantic thread 개념이 될 수 있음
    • 그 기능을 쓰면 아마 “tangential, orthogonal, anecdata, enshittification, razor…” 같은 단어들이 잔뜩 나올 듯함
    • 예전에 누군가 HN의 부계정 식별 도구를 만들었는데, 글쓰기 스타일만으로 거의 완벽히 찾아내서 무서웠음

  • 혹시 벡터 검색 vs 일반 텍스트 검색을 비교한 논문이 있는지 궁금함
    벡터 검색이 정말 그만한 가치가 있는지 고민됨

    • 일반 검색은 보통 bm25로 불림. 대부분의 검색 관련 논문에서 bm25를 기준선으로 사용함
    • 특정 논문은 모르지만, Bluesky의 reachsumit.com 계정이 RAG와 정보 검색 관련 자료를 자주 다룸
    • 어떤 측면에서 비교하느냐가 중요함 — 서버 부하인지, 사용자 경험인지에 따라 다름

  • HN 포스트와 임베딩 메타데이터가 합쳐서 55GB라는데, Parquet 파일이라면 그게 맞는지 궁금함

    • 대부분이 임베딩 데이터일 것 같음. 내 DB는 전체 HN 게시글과 댓글을 포함하는데, 압축 전 17.68GB, 압축 후 5.67GB 정도임
    • 놀라울 정도로 압축 효율이 좋음. Brotli 압축을 쓰면 수백만 페이지도 1~2GB로 줄어듦
    • 표를 보면 그 수치가 맞는 듯함. 나도 내 업보트 데이터를 임베딩해서 취향 분석을 해보고 싶음
    • 압축된 상태라면 충분히 그럴듯한 크기임

  • 댓글이 상업용 모델 학습에 쓰이는 게 유일한 목적이라면 좀 씁쓸함
    이런 상황이 앞으로 내 참여 의욕에 영향을 줄 수도 있을 것 같음

    • LLM의 등장 이후 인터넷에 유용한 글을 쓰고 싶은 마음이 줄었음
      예전엔 낯선 사람을 돕는 기분이었는데, 이제는 내가 좋아하지 않는 사람을 돕는 느낌임
    • 나는 오히려 내 괴짜 같은 댓글이 LLM의 잠재 공간에 흔적으로 남는다는 생각이 재미있음
      미래의 거대한 모델 속 어딘가에서 내 말이 미세하게 울릴지도 모름
    • 분위기 너무 진지함. 그냥 즐기자고 말하고 싶음

  • 계정/댓글 삭제 기능이 있었으면 좋겠음

    • 우리가 남긴 말은 이미 전 세계 수많은 장치에 복제되어 있음
      사실상 영구적 데이터가 되었고, 언젠가 내 댓글은 고대의 지혜처럼 남을지도 모름
    • HN 데이터셋은 이미 여러 곳에 복제되어 있으니, 여기에 쓰는 글은 공개 콘텐츠로 생각해야 함

  • 할 일 목록에서 하나를 지웠음 (이 프로젝트 덕분에)

  • 친구가 묻는다고 치자면… 여기 댓글을 달면 그게 벡터로 변환되는 것임?

답변달기