4 ポイント 投稿者 GN⁺ 2025-11-29 | 1件のコメント | WhatsAppで共有
  • 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次元ベクトル埋め込みを含む
    • 埋め込みは文と段落の意味を捉えるためのローカル埋め込みモデルを使用
  • このデータセットはユーザー生成テキストデータを用いた大規模ベクトル検索アプリケーションの設計、規模算定、性能分析に利用できる

データセットの詳細

  • 全データは ClickHouse が提供する 単一 Parquet ファイルで、S3 バケット(https://clickhouse-datasets.s3.amazonaws.com/hackernews-miniLM/…)からダウンロード可能
  • ユーザーはデータ保存量とメモリ要件を見積もるために、ClickHouse ドキュメントの ANN インデックスガイドを参照することが推奨される

データロードとインデックス構築手順

  • 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=64ef_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 コードで SentenceTransformerclickhouse_connectLangChainChatOpenAI などを使用
  • 検索結果を結合して GPT-3.5 モデルに入力し、最大10文の要約文を生成
  • 入力テキストのトークン数に応じて stuff または map_reduce チェーンを選択して処理
  • 結果は「Summary from chatgpt-3.5:」形式で出力される

1件のコメント

 
GN⁺ 2025-11-29
Hacker Newsの意見
  • 新しいベクトル埋め込みデータセットでは all-MiniLM-L6-v2 を使わないことを勧めている
    このモデルは初期のチュートリアルでよく使われていた sentence-transformers ベースの実用的なモデルだったが、今では古く、最新の アーキテクチャと学習パイプライン を反映できていない
    コンテキスト長も 512 と短い。代わりに EmbeddingGemma を推奨する。2k コンテキストウィンドウをサポートし、ベンチマーク性能も非常に高い
    速度は遅いが、その価値はある。妥協案としては bge-base-en-v1.5nomic-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 のような比較資料が不足している
      どんな基準でベンチマークすべきか分からない
    • 数週間前に EmbeddingGemmanomic-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 データセットはすでにあちこちに複製されているので、ここに書くものは 公開コンテンツ だと考えるべきだ
  • やることリストから1つ消えた(このプロジェクトのおかげで)

  • 友人に聞かれたとしたら……ここにコメントすると、それが ベクトルに変換 されるってこと?