バックエンド面接：Redis Vector Setsを用いた制御可能なハイブリッド類似度検索をどのように設計しますか？

質問

テナント、年、在庫フィルターを備えた商品セマンティック検索にRedis Vector Setsが必要です。書き込み、VSIMクエリ、キャパシティ、および品質検証をどのように設計しますか？

コンテキストと制約条件

各要素は文字列ID、固定次元のベクトル、およびオプションのJSON属性を持ちます。Redis Vector Setsは類似度検索にHNSWを使用し、FILTERによるシンプルな数学的フィルターをサポートしています。更新、削除、コールドスタート、メモリ制限、クロスプラットフォームのFP32エンコーディング、および検索フォールバックを網羅してください。この機能を、ビジネスレベルで厳密な再現率を保証するブラックボックスとして説明しないでください。

面接官がテストしていること

面接官は、ベクトル検索、構造化された制約、データライフサイクル、およびキャパシティに関する1つのサービスコントラクトを求めています。Redisのドキュメントには、要素の追加または更新のためのVADD、ベクトル類似度クエリのためのVSIM、およびどの候補を残すかを決定する属性フィルターが記載されています。FP32 blobにはリトルエンディアンのバイト順序が必要ですが、VALUESを使用するとプラットフォーム固有のblobエンコーディングを回避できます。

まず以下の点を確認してください：

ベクトルの次元数、距離メトリック、テナント規模、および更新頻度はどのくらいか？
フィルターはハードな制約か、それともアプリケーション側で拡張された候補セットを再フィルタリングすることが許容されるか？
結果にはtop-k、類似度スコア、属性、または説明可能なフィルター理由が必要か？
メモリ、永続化、リカバリ、およびクロスゾーンレプリケーションの要件は何か？

30秒の回答

キー、要素ID、ベクトル次元数、および属性スキーマを定義します。冪等なVADD/VSETATTR書き込み、VSIMのtop-kとフィルタリングについて説明します。最後に、キャパシティ見積もり、品質ベースライン、およびRedisが利用できない場合のキーワード検索や旧インデックスへのフォールバックで締めくくります。

ステップごとの詳細解説

データコントラクト：次元数とモデルバージョンを固定します。IDはグローバルにするかテナントごとにキーを設定し、フィルター対象のフィールドのみを属性として保存します。
書き込みパス：次元数とモデルバージョンを検証し、VADDでベクトルを冪等に更新し、VSETATTRで属性を更新し、VREMで削除します。
クエリパス：サービス側でテナント境界とフィルター式を検証し、VSIMから最終的なkよりわずかに多くの候補を要求し、監査用にスコアと属性を返します。
キャパシティ：ベクトル、HNSWリンク、および属性のメモリを見積もります。テナントごとの制限、エビクション（追い出し）ポリシー、およびシャーディングを設定し、無駄に大きなJSON属性を避けます。
整合性とリカバリ：モデルバージョンと書き込みイベントを記録します。スナップショット復元後は次元数、要素数、およびサンプリングされた再現率を検証します。更新が失敗した際に中途半端な属性状態が残らないようにする必要があります。
品質とフォールバック：ラベル付けされたデータ上でRecall@k、フィルタリング後のヒット率、およびp95レイテンシを測定します。Redisやフィルタリングが利用できない場合は、キーワード検索または古いスナップショットに切り替えます。

模範回答

テナントとモデルバージョンごとにセットのキーを設定し、要素IDを不変に保ち、ベクトルの次元数を固定します。書き込み時には次元数とモデルバージョンを検証し、VADDでベクトルを冪等に更新した上で、VSETATTRで年、在庫、テナントの属性を保存します。削除にはVREMを使用します。サービスは、k個よりわずかに多い候補を要求する前にテナントの制約を検証します：

text

VSIM products:{tenant}:{model} VALUES 3 0.12 0.08 0.44 COUNT 50 WITHSCORES FILTER ".year >= 2024 && .stock > 0"

次元数、要素数、HNSW情報、および属性メモリをテナントごとの制限とともに追跡します。ベンチマークでは、厳密な全探索（ブルートフォース）を品質ベースラインとして使用し、Recall@k、フィルタリング後ヒット率、p95/p99レイテンシ、読み取り/書き込みスループット、およびリカバリ時間を測定します。FP32の転送にはリトルエンディアンエンコーディングを使用するか、blobのエンディアン差異を避けるためにVALUESを使用します。Redis、フィルタリング、またはモデルバージョンの互換性に問題が発生した場合は、キーワード検索または以前のスナップショットにフォールバックし、結果のソースを記録します。

よくあるミス

次元数、k、フィルター、または品質指標に触れずに「HNSWは高速である」とだけ述べること。
属性フィルターを任意のSQLのように扱い、式の制限やテナントの分離を無視すること。
任意の次元数のモデル出力を1つのVector Setに書き込むこと。
FP32のエンディアン、JSON属性のサイズ、およびHNSWのメモリコストを無視すること。
古いインデックス、キーワード、またはスナップショットリカバリへのフォールバックを用意していないこと。

優れた回答は、書き込み、クエリ、キャパシティ、整合性、および品質検証を結びつけ、Redisコマンドの境界を明確にし、測定可能なフォールバック動作を提示します。不十分な回答は、データコントラクトや運用指標を示さずに「ベクトルデータベースにフィルターを追加する」とだけ述べます。

フォローアップの質問と回答

なぜすべてのビジネスフィールドを属性として保存しないのですか？

属性はフィルタリングに関与し、メモリを消費します。インデックスの肥大化とプライバシー情報の拡散を防ぐため、候補のフィルタリングに必要なフィールドのみを保持し、詳細はプライマリデータストアからID経由で取得します。

モデルのアップグレードによって次元数が変更された場合はどうしますか？

新しいモデル用に独立したキーまたはバージョン空間を作成し、デュアルライト（二重書き込み）を実施して評価します。Recall@k、レイテンシ、およびコストの基準をクリアした後に切り替えます。1つのセット内で次元数を混在させてはなりません。

厳格なフィルターによって結果が0件になった場合はどうしますか？

明示的な0件の理由とメトリックを返します。プロダクトで承認された順序に従って条件を緩和するか、キーワード検索に切り替えます。テナントや在庫の制約に違反する結果を黙って返してはなりません。

面接チェックリスト

1文でのまとめ

Vector Setを明確な次元数、属性、およびキャパシティコントラクトを持つ検索コンポーネントとして扱い、品質ベースラインと安全なフォールバックを用いて制御可能な検索を実現します。