目次

2026-11-03 09:09:18 Asia/Shanghai（2026-11-03T01:09:18.361Z）、Perplexityコミュニティの pplx-announcements が Announcements スレッド *Introducing pplx-embed-v2-context: open-weight vision-language embedding models in 9B and 0.6B* を公開した。短文では両サイズとも 文書あたり1本の int8 ベクトル、または 文書全体を見られるチャンクベクトルをチャンクごと1本 返せる、と述べ、論文 arXiv:2610.38854 へリンクし、執筆に turbopuffer が関わったと記す。

このコミュニティ時刻は系列の最古タイムスタンプではない。論文ページの citation_date は 2026/10/28、「Submitted on 28 Oct 2026」。Hugging Face では pplx-embed-v2-context-0.6b の createdAt が 2026-10-21 20:42:50 Asia/Shanghai、lastModified が 2026-10-30 18:00:18 Asia/Shanghai；pplx-embed-v2-context-9b の createdAt が 2026-10-28 20:38:45 Asia/Shanghai、lastModified が 2026-10-30 17:59:28 Asia/Shanghai。2026-11-03 はコミュニティ告知日——当日朝に系列全体が初登場したわけではない。

関連記事：OlmoEarth 1.3で土地の変化を見る — 大モデル訓練もGPUもいらない、Perplexity Computer を Mac でローカル実行する仕組みと Hybrid モードの役割、Atria Dawn 正式版ウェイト公開：Hugging Face で 512K コンテキスト、OpenAI Habitat：読み取りは約12倍速くても、回答は同じではない。これらは衛星埋め込み探索、Perplexity Computer の Mac 実行、正式オープンウェイト、ストレージ読み取りなど隣接線であり、マルチモーダル文脈検索埋め込みと同題ではない。

孤立チャンクが答えを落とす理由

検索拡張生成では、長い文書を独立に索引・採点するチャンクへ分割することが多い。賃料の数字、改訂記号、表のセルは、同じファイル内の見出し・定義・実体名に依存しがちだ。通常の密埋め込みは各チャンクを孤立して符号化するため、周囲文脈を要するクエリと一致しにくくなる。文書全体を1本のベクトルに潰すと、読者にまだ必要な細部が薄まる。

文脈埋め込みは、各チャンクを符号化するとき文書の周囲文脈を見ながら表現する。Perplexityのカードは同一モデル上で contextual（近傍が見える）と non-contextual（テキストを単独符号化）を説明する。コミュニティの一行——文書全体の int8、または全文を見られるチャンクベクトル——はこの分岐に対応する。

論文 *Contextual Embeddings Beyond the Gold Chunk* は、実運用の検索が単一の「金チャンク」答えだけで足りず、実体・期間・条件を裏付ける証拠チャンクも表に出す必要がある、と論じる。訓練は金チャンクラベルだけに頼らず、クエリ認識型の文脈圧縮モデルから段階的なチャンク関連度を蒸留する。研究の細部は arXiv 側；以下は告知・カード・論文ページから運用者が確認できる境界に留める。

Hugging Face上の2サイズ

両リポジトリは perplexity-ai 配下で、feature-extraction／contextual-embeddings、多言語タグ、custom_code を持ち、いずれも gated=false。ベースは late チャンク兄弟：perplexity-ai/pplx-embed-v2-late-0.6b と perplexity-ai/pplx-embed-v2-late-9b（カード上の finetune 関係）。

項目0.6B9B
リポperplexity-ai/pplx-embed-v2-context-0.6bperplexity-ai/pplx-embed-v2-context-9b
Safetensors total595370176（約 595M）8401083632（約 8.40B）
ライセンス（カード／API）cardData／README YAML に明確な license なし（API license=None）cardData に license: mit（tags に license:mit）
gatedfalsefalse
ネイティブ幅（カード例）10242048（Matryoshka は 1024 も）

ライセンス境界：9B カードは MIT。0.6B はカード・README・API に明確な license 欄がない——0.6B は MIT と書かれておらず、両サイズ同一ライセンスでもない。再配布前にはハブページの再確認が必要。

カード文面は各モデルを “state-of-the-art” と呼ぶ。これはモデルカードの自己申告。再現・nDCG・VRAM・スループット・多言語品質・視覚文書検索は未再測。

品質を静かに落とす符号化ルール

両 README の硬規則は同じ。どれか一つ欠けると、索引は「動いている」のに順位だけ悪くなる。

  1. クエリは encode_queries、文書チャンクは encode。 モデルは別々の query／document 接頭辞で学習される。クエリを encode で符号化すると静かに品質が劣化する——例外は出ず、順位だけ落ちる。
  2. 文脈モードの文書チャンクは非重複（non-overlapping）。 重複スパンは「境界が区切り」という学習前提と衝突する。
  3. ネイティブ出力は未正規化 int8。 コサイン類似度で比較するか、normalize_embeddings=True のあと内積を使う。
  4. 読み込みは trust_remote_code=True。 カスタムコード必須。依存は transformers>=5.4.0、torch、numpy、safetensors、tqdm、Pillow、torchvision。任意で flash-linear-attention と causal-conv1d が高速線形注意経路を有効にする。
  5. テキスト encode は切り詰めない。 長さ超過の文書は呼び出し前に分割または切り詰める。文書あたり1埋め込みにするなら、各文書を単一チャンクのリストとして渡す。

カード上の最小テキスト形（ID／フラグは文書どおり）：

python
from transformers import AutoModel

model = AutoModel.from_pretrained(
    "perplexity-ai/pplx-embed-v2-context-0.6b",  # または ...-9b
    trust_remote_code=True,
).to("cuda")

documents = [
    ["文書1のチャンクA。", "文書1のチャンクB。"],
    ["文書2の唯一チャンク。"],
]
chunk_embeddings = model.encode(documents, normalize_embeddings=True)
query_embeddings = model.encode_queries(
    [["チャンクAに合う質問は？"]],
    normalize_embeddings=True,
)

非文脈モードはカード上、各チャンクを単要素リストへ平坦化してから encode する。文脈モードは文書単位でチャンクをまとめ、近傍を同一フォワードで見えるようにする。

9B と 0.6B の混在インデックス

カードは 9B の 1024 次元 MRL 接頭辞が 0.6B と埋め込み空間を共有すると述べる。一方のサイズで索引し、他方でクエリできる——次元合わせが正しい場合に限る。

9B カードは Matryoshka を 1024 と 2048 で訓練したと記す。0.6B と揃える手順：

  1. encode／encode_queries／encode_images をまず未正規化で取る（ネイティブ int8）。
  2. 各 9B ベクトルの先頭 1024 次元だけ残す。
  3. その後 L2 正規化する。
  4. クエリと画像埋め込みも混在時は同じ「切ってから正規化」経路を使う。

他の切り詰め幅はこの整合用に訓練されていない。正規化してから切ると、別種の静かな不一致になる。

画像と視覚文書：水平バンド

両カードはページや画像を文脈チャンクにする encode_images を公開する。各画像は1回の文脈フォワードで符号化され、結合された視覚トークンは行単位の水平バンドに分割される。それらのページへのクエリは引き続き encode_queries。

文書上の画像引数は chunks（既定で 8 バンド要求）、min_pixels（16384）、max_pixels（1800000）、batch_size（1）。実際のバンド数は結合画像行数で上限される。カードのページ採点例は、正規化行列積のあとチャンクスコアの最大を取る。画像チャンクで性能が大きく上がる、という文言はカード申告であり DigIntoAI の実測ではない。

通常チャンクと文脈チャンク

軸通常（非文脈）文脈（pplx-embed-v2-context）
符号化器が見るものチャンク単独チャンク＋周囲文脈
カード上の典型呼び出し[[chunk], …] へ平坦化して encode文書ごとに [[c1, c2, …], …] を保って encode
クエリ経路依然 encode_queries依然 encode_queries
重複古典 RAG ではよくあるカードは文脈モードで非重複を要求
文書全体ベクトル孤立した文書文字列文書を単一チャンクリストとして渡す

チャンク自体が自己完結（FAQ行、短い見出し）なら非文脈で足りる。答えが見出し・代名詞・表ヘッダ・改訂注記に依存するなら文脈——論文とカードが想定する失敗モードだ。

運用チェックリスト

  1. 時刻。 コミュニティ投稿 2026-11-03 09:09:18 Asia/Shanghai、pplx-announcements；論文提出 2026-10-28；HF リポは告知より前——今日初出ではない。
  2. サイズ。 オープンウェイト 9B（約 8.40B）と 0.6B（約 595M）、いずれも gated=false、カスタムコード、テキスト／画像／視覚文書の検索向け。
  3. ライセンス。 9B＝MIT（cardData）；0.6B＝明確な license なし——ライセンスは分けて記す。
  4. API分岐。 文書 → encode；クエリ → encode_queries。取り違えると静かに劣化する。
  5. チャンク。 文脈モード → 非重複；任意で単一チャンクリストにより文書1ベクトル。
  6. ベクトル。 ネイティブ未正規化 int8；コサイン、または正規化後の内積。
  7. 読み込み。 trust_remote_code=True；依存はカードどおり transformers>=5.4.0 など。
  8. サイズ混在。 共有 1024 次元 MRL 接頭辞：未正規化 9B を1024へ切ってから正規化し、0.6B と比較。
  9. 視覚。 encode_images は水平バンド；クエリは encode_queries。
  10. スコア。 カード／論文の「SOTA」＝自己申告。再現・VRAM・多言語・視覚検索は未再測。

まとめ

2026-11-03 のコミュニティ告知は、オープンウェイト pplx-embed-v2-context の 9B と 0.6B を指し示す。文脈チャンクベクトルは文書の残りを見られ、共有 1024 次元空間で混在索引も可能だ。論文と HF リポは 2026年10月下旬から記録がある。落とし穴は宣伝ではなく運用側：クエリの encode 取り違え、文脈チャンクの重複、MRL 切り詰め前の正規化、カード SOTA を第三者実測と扱うこと。これらのウェイトの端到端検索とハード計測は未実施——現場メモはフッターのサイト運営者連絡先から送れる。