RetrievalOps ― 変化に耐えるProduction Retrievalの設計と運用

RetrievalOps 変化に耐える Production Retrievalの設計と運用 Yulan Yan / Founding Solutions Architect, Japan Zilliz | October 2026 https://www.linkedin.com/in/yulan-yan-0a899686 1 | © Copyright 2026 Zilliz

• https://www.linkedin.com/in/yulan-yan-0a899686

Why I am here 研究から実装まで、検索と言語を一貫して見てきた立場から 顔 玉蘭 Yan, Yulan Zilliz Founding Solutions Architect, Zilliz Milvus の開発元 NLP 研究員 NICT ・ 多言語の情報抽出・質問応答 Data & AI プラットフォームの SA Databricks ・ RAG ・ Agent ・ Vector Search ベクトル DBに専念 Zilliz ・ 検索基盤そのものを支援 POINT Milvus Zilliz Cloud 世界で最も広く採用されている オープンソースのベクトルDB Milvus のフルマネージド版（商用 SaaS） AWS ・ Google Cloud ・ Azure 10,000 の企業が利用 （Zilliz / Milvus） 今日は、本番に出た検索基盤に「その後」何が起きるかを、事例と一緒にお話しします 2 | © Copyright 2026 Zilliz

検索基盤の基本：「作る」流れと「探す」流れ 検索・RAG・推薦、どれもだいたいこの形 ① 作る 事前に・継続的に Source ETL / CDC Chunk Embedding Vector DB (今回の例Zilliz / Milvus) 文書・商品 画像 変更を 取り込む 分割する ベクトル化 ベクトルを保存 質問も同じ モデルで 似た順に取り出す ② 探す リクエストごと 本番で変わるところ（このあと 1つずつ見ていきます） 1 データ 2 規模 3 モデル 4 用途 POINT 作って終わりではない。本番では、この基盤のあちこちが変わり続ける 3 | © Copyright 2026 Zilliz Search・RAG 質問 → 結果 LLMに渡す

検索基盤が本番に出た後に、起きること 公開されている顧客事例から、よくある 4つの変化 1 データが変わる 広告が毎日入れ替わる。 1日1億件以上のベ クトルを更新 3 モデルが変わる 新しいEmbeddingモデルを試すたびに、全 件の作り直しに丸 1日 SmartNews Consensus 1 リリース 2 数ヶ月 3 2 規模が変わる データもアクセスも増え、今の構成のままで は遅くなる Shopee 出典：zilliz.com の顧客事例。会社ごとの事例を、典型的な順に並べたもの 4 | © Copyright 2026 Zilliz 4 1年 数年 4 用途が変わる 検索から広告、推薦、 RAGへ。同じ基盤に用 途が次々に乗る Cốc Cốc

毎日1億件以上が入れ替わっても、広告検索は止めない 1 データが変わる 1 データ 公開事例：SmartNews 2 規模 3 モデル 4 用途 SmartNews ニュースアプリ（東京） リアルタイム広告推薦 1億件+ 毎日更新されるベクトル 旧データセット ① 広告の候補を探す ユーザーに近い広告をベクトルで検索 広告 検索 ② データの入れ替え 別名 alias 新データセット 推薦を常に最新のデータで 裏で新しいデータを作り、別名の指す先を付け替える 10ms 未満 広告候補の検索（99%の検索で） エンジニアの声： 別名（Collection Alias）で、新旧のデータを「滑らかに」切り替えられる POINT 大きな入れ替えは「裏で作って、名前を付け替える」。アプリは同じ名前を見続ける 出典：zilliz.com/customers/smartnews 5 | © Copyright 2026 Zilliz

新しいデータ・消すデータ・版をどう扱うか 1 データが変わる 1 1 データ 押さえるポイント Ground Truthはソース DB、検索側 は 写し 2 消すもの・残すものを分ける 3 2 規模 3 モデル 4 用途 書いた直後、どこまで待つか 非同期 ソースDB（正） 1件ごとに記録する • データの版 • 検索側に反映すべき版 • 反映できたか・失敗の回数 定期的に見回って直す 反映漏れ・消し忘れ・版のずれ POINT Milvus（写し） ソースで削除 検索側でも削除（削除も連携） 期限切れ 行ごとの有効期限で自動で外す 改定前の版 残す。有効期間で時点を選ぶ 下書き 承認状態で絞り込み、出さない 最新まで 確実だが遅い 少しだけ 既定。わずかな遅れを許す 自分の分 自分が書いたものは見える 待たない 最速 検索ごとに選べる（consistency level）。 「保存してすぐ確認」する画面だけ「自分の分」に 検索側はずれる前提。版・状態・消える理由をデータに持たせ、除外は DBに任せる 参考：Milvus Docs「Consistency Level」「Upsert Entities」「Set Collection TTL」 6 | © Copyright 2026 Zilliz

データもアクセスも増え、 Shopeeは構成を乗り換えた 2 規模が変わる 1 データ 公開事例：Shopee Shopee 短尺動画サービスの マルチメディア理解チーム 2 規模 3 モデル 4 用途 最初の構成 回避策 分散アーキテクチャへ データとリクエストが増える。 遅くなる クラスタを複数並べて運用 → 運用コストが大きい。 推薦用は上位の結果をキャッ シュし、裏で更新 分散で伸ばせる。複製 （Replica）で性能も向上。 キャッシュなしで直接検索 1億件超 ベクトル 3つ 同じ検索基盤に乗る本番システム 本番システムが依存 動画の推薦 POINT 著作権の照合 規模が変わると、構成を乗り換える日が来る。乗り換えられる設計にしておく 出典：zilliz.com/customers/shopee 7 | © Copyright 2026 Zilliz 動画の重複検出

増やすのか、乗り換えるのか 2 規模が変わる 1 1 データ 押さえるポイント 増やす：何が増えたかで決める 2 データ量 ↑ 計算ユニット（ CU）を増やす SLA 99.99%・マルチリージョン アクセス ↑ 複製（Replica）を増やす 2 規模 Business Critical 使われないデータ POINT 止めずに移る（ Zero-Downtime Migration） 新クラスタに 全量コピー メモリから外しておく 止めずに、その場で増減できる 差分を同期 遅れを監視 書き込み停止 → 切替（約10秒） Private Preview。同じか上位のプランへ。旧クラスタは残して確認 増やすだけなら止めずにその場で。乗り換えるなら新旧を並走させてから切り替える 出典：Zilliz Cloud Docs「Scale Cluster」「Select the Right CU」「Service Plans」「Zero Downtime Migration」 8 | © Copyright 2026 Zilliz BYOC Serverless 負荷が不定期・小さく始めたい 予測できない波は自動スケール、予測できる 波（平日の昼・バッチ）は時間指定 4 用途 乗り換える：要件が変わったら データを自社のクラウド環境から出せない 負荷が波打つ 3 モデル

毎日作り直して切り替える。新しいモデルもそのまま試せる 3 モデルが変わる 1 データ 公開事例：Consensus Consensus 研究者向けのAI学術検索 4億件超の学術文献 約1時間 2 規模 3 モデル Collectionを2つ持ち、毎日入れ替える Day 1 Collection A Collection B 本番 作成 Day 2 作成 本番 待機 Day 3 本番 待機 切替 全件の作り直し（以前は24時間超） 作成 切替 • 差分は管理しない。毎日、待機側を全件作り直して本番と入れ替える 27% 次元を4倍にして検索の質（社内評価） POINT • 以前は新しいモデルを 1つ試すのに丸 1日。今は同じ作り直しを別のベクトルで回すだけ • 次元を4倍（2561,024）にしても、必要なクラスタは約 2.5倍 作り直しが速くて安いなら、毎日作り直して切り替えるのが一番シンプル 出典：zilliz.com/customers/consensus（数値は事例に記載の本番値・社内評価） 9 | © Copyright 2026 Zilliz 4 用途 待機

モデルを替えると、ベクトルの意味ごと変わる 3 モデルが変わる 1 データ 押さえるポイント 2 規模 3 モデル 4 用途 新しいCollectionを裏で作って移行する ベクトルを作る条件 セットで管理し、書き込みと検索で 毎回そろっているか確認する v1（現行） • モデルと版 ・ 次元 ・ 正規化 • 文書・質問に付ける定型文 • 文書の切り方 • 類似度の計算方法 v2（新） 1つでも変われば、 新しく作り直す POINT 本番 ① 作成 ② 過去分を投入 残す（戻す用） ③ 確認 ④ 試す 切替 ① 新しい条件で、別のCollectionを作る ② 過去分を少しずつ投入（途中から再開可） ③ 件数・漏れ・検索結果を確認 ④ 一部の検索だけで試す ⑤ 別名の指す先を切り替える ⑥ 古いCollectionはしばらく残す モデル・次元・切り方はセットで管理。変えるなら上書きせず、裏で作って切り替える 参考：Zilliz Cloud Docs「Migrate to a New Embedding Model」、Milvus Docs「Manage Aliases」 10 | © Copyright 2026 Zilliz ⑤ 本番

長い文書は薄まり、断片は上位を埋めてしまう 3 モデルが変わる 1 データ 長い文書の問題 A. 文書全体を1つの単位にすると 2 規模 3 モデル StructArray：1文書を1行に、チャンクはその中に 報告書 R031（例） ・ 地域 ・ 文書全体のベクトル ▦ vector 1 細かい情報が、文書全体の意味に埋も れる B. 文書を切った断片（チャンク）を 1行ずつにすると 上位20件のうち6件が 同じ報告書の断片 0 概要 ベクトル ▦ 1 地質 ベクトル ▦ 2 鉱化帯の記述 ベクトル ▦ 3 ボーリング結果 ベクトル ▦ 結果：報告書 R031 の3番目（前後のチャンクも一緒に取れる） 20件の結果が、十数件の資料にしかならない。 アプリ側でまとめ直す処理が必要になる POINT • チャンク単位で探して、文書単位で返す • キーワード検索との併用や、文書ごとのまとめにも対応 長い文書は、文書とチャンクを 1行にまとめて持つ（ StructArray） 参考：Milvus Docs「StructArray」（一部 Preview）。報告書の例は説明用 11 | © Copyright 2026 Zilliz 4 用途

新旧の並べ方は 2つ：Collectionごと、列ごと 3 モデルが変わる 1 データ 押さえるポイント A. Collection ごと並べる Consensus Collection v1 App 別名 Collection v2 • 裏で作る → 確認 → 別名を切替 • Consensus：毎日全件を作り直し（約1時間）、入れ替え ◎ 完全に分離できてシンプル △ 一時的に容量が2倍。全件を作り直す時間が要る POINT 3 モデル B. 列ごと並べる id 本文 v1ベクトル v2ベクトル … … ▦ ▦ … … ▦ ▦ 列を追加 両方に書く 過去分投入 同じCollectionに 新しいベクトル列を足す 検索を切替 ◎ 作り直さない。他の列やデータの分け方はそのまま △ 比較的新しい機能（一部 Preview） 出典：zilliz.com/customers/consensus、Zilliz Cloud Docs「Migrate to a New Embedding Model」。詳細は Appendix 4 用途 Zilliz / Milvus 再構築が速くて安いなら A、作り直したくないなら B。どちらも旧版は残す 12 | © Copyright 2026 Zilliz 2 規模 旧列を削除

用途は増え続ける： 1つの検索から、広告・推薦・ RAGへ 4 用途が変わる 1 データ 公開事例：Cốc Cốc Cốc Cốc Web検索の順位付け ベトナムの検索エンジン・ブラウザ 3,000万人以上が利用 検索・ショッピング広告 Zilliz / Milvus 関連検索の提案 約7億ベクトル 約7億 似たユーザーへの広告配信 ベクトル（15億まで計画） 5つ 本番システムが同じ基盤に POINT RAGチャットボット 以前：ライブラリ（FAISS など）で個別に作っていた 「インデックスであって、システムではない」 今：書き込みやデータ整理は裏で。重い処理は深夜2〜4時に 検索基盤は最初の1用途で終わらない。複数の用途に共有される前提で作る 出典：zilliz.com/customers/coccoc。5つのシステムは「同じ基盤」の上にあり、同一 Collectionとは限らない 13 | © Copyright 2026 Zilliz 2 規模 3 モデル 4 用途

同じ基盤を複数の用途で使うときに、決める 3つのこと 4 用途が変わる 1 見え方：検索ごとに変える 検索画面 1 データ 押さえるポイント 意味検索＋キーワード検索 2 負荷：ぶつからないように分ける 複製 読み取りの負荷を分散（Replica） 評価・バッチ 本番のコピー（Snapshot）で回す 3 2 規模 3 モデル 4 用途 権限：境界を先に決める Cluster Database RAG 自部署の文書・本文だけ・上位5件 Collection 推薦 文書ごとにまとめて上位50件 絞り込み・返す項目・待ち方は検索ごとに指定できる。ア プリからは別名（alias）で参照する POINT 時間帯 重い書き込みは夜間に 用途ごとにコピーを作ると、更新・削除の問題がコピーの 数だけ増える データは1つに。見え方・負荷・権限を用途ごとに分ける 参考：Milvus Docs「Consistency Level」「Manage Aliases」「RBAC」、Zilliz Cloud Docs「Implement Multi-tenancy」 14 | © Copyright 2026 Zilliz 権限はこの3階層で設定。行ごとの権限はない 厳密に分ける（法務・人事・顧客）→ DB / Collection を 分ける ゆるく分ける（部署・テナント）→ API側で絞り込みを必ず 付ける

4つの変化を 1枚に 最初に見たパイプラインの上で、変化ごとに「どこで・何を」するか Source 1 データ 2 規模 3 モデル 4 用途 SmartNews ETL / CDC Chunk Embedding Cốc Cốc CU・複製・自動スケール プラン変更は並走 →切替 切り方 StructArray 条件の版 v1 / v2 Collection か 列で並べ 確認してから切替 質問側も 同じモデルに 権限（ DB / Collection） 複製・時間帯を分ける 検索ごとに API側で強制 評価・監視 反映の速さ ・ 反映漏れ ・ 版のずれ ・ 取りこぼし ・ 応答時間 ・ コスト ・ 見せてはいけない結果＝ 0 15 | © Copyright 2026 Zilliz Search・RAG 別名で入れ替え 有効期限・有効期間・待ち方 正はソース・版と状態を記録・定期的に直す Shopee Consensus Zilliz / Milvus

持ち帰ってほしい 4つのこと 1 データ： Ground Truthはソース、検索側はその写し 版・状態・消える理由をデータに持たせ、ずれは定期的に直す（ SmartNews） 2 規模：増やすだけならその場で、乗り換えるなら並走 3 モデル：モデル・次元・切り方はセットで管理 4 用途：基盤は 1つ、見え方・負荷・権限は用途ごとに 量とアクセスに合わせて増やす。構成を変えるときは新旧を並べて切り替える（ Shopee） 変えるなら上書きせず、裏で作って確認してから切替。旧版は残す（ Consensus） 最初の1用途で終わらない前提で作る（Cốc Cốc） 初期の検索性能ではなく、変化への追従性を設計する 9/6/23Zilliz Zilliz 16 | © Copyright 2026

ありがとうございました 17 | © Copyright 2026 Zilliz