長文ドキュメントのためのより良いベクトル検索：Manticore Search内のチャンキング

長文ドキュメントのためのより良いベクトル検索：Manticore Search内のチャンキング 著者：Dmitrii Kuzmenkov 公開日：2026年9月15日 - 33分で読める マークダウンで表示 チームの内部ドキュメント（ガイド、ランブック、ポストモーテム）を検索するシステムを構築しているとします。自動埋め込み機能を持つテーブルがあり、テキストを挿入するとManticoreがモデルを実行してベクトル列を埋めてくれます。（まだご存知ない場合は、Manticoreでのベクトル検索から始めてください。）4,000語のドキュメントをロードします。挿入は成功し、検索も機能します。すべて順調に見えます。 ただし、選択したモデルの入力ウィンドウは512トークンであり、そのドキュメントは約5,000トークン長です。モデルは最初の380語を読み込み、残りの3,600語は破棄しました。それ以降のドキュメントの内容は一切取得できず、そのことを知らせるものもありませんでした。また、埋め込みがドキュメント全体を代表していない可能性もあります。 これまでは、通常、ドキュメントを自分でいくつかの断片に分割し、それぞれの埋め込みを作成し、ドキュメント検索ではなくチャンク検索を行いたい場合に結果をどのように組み合わせるかを考える必要がありました。Manticoreは現在、これをテーブル定義で処理します。CREATE TABLEでベクトル列に`chunk_strategy`を追加するだけで、Manticoreは各ドキュメントをチャンクに分割し、各チャンクを埋め込み、それらすべてを検索します。 DROP TABLE IF EXISTS docs; CREATE TABLE docs ( title text, content text, chunks float_vector_array knn_type='hnsw' hnsw_similarity='cosine' model_name='Xenova/all-MiniLM-L6-v2' from='title,content' chunk_strategy='sentence' max_tokens='256' overlap_tokens='32' ); これがその機能全体です。インジェストパイプラインも、スプリッターライブラリも、チャンク用の2番目のテーブルも、チャンクヒットをドキュメントに折りたたむためのGROUP BYも必要ありません。 TL;DR 5つの戦略：truncate（旧デフォルト）、mean、fixed、recursive、sentence。モデルバックのベクトル列の`chunk_strategy`で設定します。 truncateとmeanはドキュメントごとに1つのベクトルを生成し、float_vector列で機能します。fixed、recursive、sentenceは多数を生成するため、float_vector_array列が必要です。 ドキュメントは依然として1つの検索結果です。チャンクは個別に競合し、Manticoreはドキュメントを1回だけ返します。knn_dist()は最も近いチャンクへの距離を報告します。kはチャンクではなくドキュメント数をカウントします。 チューニングノブ：max_tokens（チャンクサイズ）、overlap_tokens（隣接するチャンク間の共有トークン）、max_chunks（ドキュメントあたりの上限）。 Manticoreのマニュアル（189ページ、約298k語）で測定した結果：モデルのウィンドウを過ぎたコンテンツについては、recall@5が55.1%から83.3%に、MRRが0.44から0.70に向上しました。RAMは約2.5倍、インジェスト時間は約4倍になりました。 クエリはチャンク化されません。クエリは全体として埋め込むのに十分短いため、保存されているドキュメントのみが分割されます。 小さな例で示す問題 4つのドキュメントがあるとします。 バックアップと復旧のランブック — 約700語、約900トークン。バックアップスケジュール、保持期間、復旧ドリル、認証情報、容量計画。最後のセクションでは、レプリケーションポートで使用されるTLS証明書をローテーションする方法を説明しています。 監視とアラートガイド — 無関係です。 CLIの開始方法 — 無関係です。 HTTP APIのTLSと証明書 — 証明書に関する短いページで、ローテーションやレプリケーションについては一切言及していません。 以下のコマンドを使用してテーブルを作成し、ドキュメントを追加できます。 さて、ここでは1つのテーブル、同じソーステキストを持つ3つのベクトル列があります。戦略ごとに1つの列です。単一のINSERTですべて3つが埋め込まれるため、比較条件は同一です。 DROP TABLE IF EXISTS docs; CREATE TABLE docs ( title text, body text, v_truncate float_vector knn_type='hnsw' hnsw_similarity='cosine' model_name='Xenova/all-MiniLM-L6-v2' from='title,body', v_mean float_vector knn_type='hnsw' hnsw_similarity='cosine' model_name='Xenova/all-MiniLM-L6-v2' from='title,body' chunk_strategy='mean', v_sentence float_vector_array knn_type='hnsw' hnsw_similarity='cosine' model_name='Xenova/all-MiniLM-L6-v2' from='title,body' chunk_strategy='sentence' max_tokens='128' overlap_tokens='32' ); 4つのドキュメントを挿入します。 INSERT INTO docs (id, title, body) VALUES (1, 'Backup and restore runbook', 'Nightly backups run at 02:00 UTC from the standby node. The job snapshots every table directory, writes a manifest, and uploads the result to object storage. Retention is thirty daily copies, twelve monthly copies, and one yearly copy. A restore drill runs on the first Monday of each month against a scratch cluster. The drill counts as passed only when a full-text search over the restored data returns the same document count as production. Anything less is treated as a failed drill and investigated the same week. Before a restore, freeze the target cluster so that no writes land while files are being replaced. Copy the manifest first and verify its checksum. If the checksum does not match, stop: a partial restore is worse than no restore, because the cluster will start and silently serve half the corpus. After the files are in place, unfreeze and let replication catch up. Watch the queue depth. If it does not drain within ten minutes, the node is probably still reading from cold storage and needs a warm-up pass before it can serve traffic. Backup failures page the on-call engineer. The three most common causes are an expired object storage credential, a disk that filled up while the snapshot was being written, and a table left frozen by a previous failed run. All three are recoverable without data loss. Check the job log first, then the disk, then the freeze state of every table. Capacity planning for backups is boring but it matters. A daily copy of the search cluster is roughly the size of the data directory plus fifteen percent for the manifest and metadata. Multiply by the retention count, add the transfer cost, and you have the monthly bill. Most teams discover too late that the yearly copies dominate the storage line. Object storage lifecycle rules do most of the retention work. Daily copies move to infrequent access after seven days and expire after thirty. Monthly copies move to archive after sixty days. Yearly copies never expire automatically; deleting one is a manual action that requires a second approver. Credentials for the backup job live in the secret manager and are issued to a role, not to a person. The role can write new objects and list the bucket. It cannot delete, and it cannot read objects older than the current day. That last restriction is the cheapest defence against a compromised backup runner turning into a data exfiltration path. Documentation for each table lives next to its schema: what the table is for, who owns it, how large it is expected to get, and whether it can be rebuilt from an upstream source. A table that can be rebuilt does not need thirty daily copies. Roughly half of most clusters turns out to be derived data that nobody had marked as derived. Verification is not the same as the job exiting zero. The job can succeed while producing an unusable copy: an empty table, a truncated upload, a manifest that references a file that was never written. The verification step reads the manifest back, checks every referenced object exists and matches its recorded size, and compares row counts on three sampled tables against production. Rotating the replication TLS certificate is a separate procedure and the step people most often get wrong. The certificate that secures the replication port is not the same as the one the HTTP API uses, and replacing one does not replace the other. Generate the new key and signing request on the node that will be rotated first, sign them with the cluster certificate authority, and place the files next to the existing ones rather than on top of them. Then update the node configuration to point at the new paths and reload. Do one node at a time and confirm that the cluster reports every peer as synced before moving on. A half-rotated cluster where two nodes trust different authorities will keep accepting writes on both sides and diverge quietly. When every node has been rotated, remove the old key material and revoke the retired certificate at the a')