Redis Search(全文検索・ベクトル検索機能)に関するガイダンスです。以下の内容をカバーしています: - FT.CREATE によるスキーマ設計 - フィールド型の選択(TEXT、TAG、NUMERIC、GEO、GEOSHAPE、VECTOR、JSON パス) - DIALECT 2 クエリー構文 - FT.SEARCH / FT.AGGREGATE / FT.HYBRID コマンドの選び分け - HNSW または FLAT を用いたベクトル類似度検索 - 字句検索とベクトル検索を組み合わせたハイブリッド検索 - RAG パイプライン(生成AIの検索・抽出工程) - エイリアスを使った検索インデックスの無停止更新 - FT.PROFILE と FT.EXPLAIN によるデバッグ 次のような場合に使用: - Hash ドキュメントまたは JSON ドキュメントに対して検索インデックスを定義する - フィルター、ソート、集計、またはベクトル近傍探索を含む FT.SEARCH クエリーを書く - HNSW パラメーターをチューニング(最適化)する - RAG 検索パイプラインを構築する - 検索結果が遅い、または結果が返らない場合のトラブルシューティングを行う
Redis Search guidance covering FT.CREATE schema design, field type selection (TEXT, TAG, NUMERIC, GEO, GEOSHAPE, VECTOR, JSON path), DIALECT 2 query syntax, FT.SEARCH / FT.AGGREGATE / FT.HYBRID command selection, vector similarity with HNSW or FLAT, hybrid retrieval combining lexical and vector ranking, RAG pipelines, zero-downtime index updates via aliases, and debugging with FT.PROFILE and FT.EXPLAIN. Use when defining a search index on Hash or JSON documents, writing FT.SEARCH queries with filters, sorting, aggregation, or vector KNN, tuning HNSW parameters, building a RAG retrieval pipeline, or troubleshooting slow or empty search results.
Redis Searchの総合ガイド — テキスト検索、数値検索、地理情報検索、JSONパス検索、ベクトル検索など、さまざまな種類の検索に対応した検索機能です。ベクトルフィールドはTEXT/TAG/NUMERICフィールドと同じFT.CREATEの仕組みで扱われ、FT.HYBRIDはテキスト検索とベクトル検索のスコアを1つのコマンドで組み合わせるため、このスキルではこれらをまとめて説明します。
FT.CREATE、FT.ALTER)FT.SEARCH、FT.AGGREGATE、またはFT.HYBRIDのクエリ(問い合わせ)を書いたり最適化したりするときTEXT、TAG、NUMERIC、GEO、GEOSHAPE、VECTOR、JSONパスフィールドから適切なものを選ぶときVECTORフィールドを定義したり、HSNWと FLATのどちらかを選んだり、HSNWのパラメータを調整したりするときFT.EXPLAIN、FT.PROFILE、FT.INFOを使って、空の結果、遅いクエリ、トークン化(テキストの分割)の問題をトラブルシューティングするとき3つのクエリコマンドがあります。必要な用途に最も限定的に合致するものを選びます。
| コマンド | 使用場面 | 意味合い | 必要な最小Redisバージョン |
|---|---|---|---|
| FT.SEARCH | ドキュメント検索、スコアリングまたはソート | マッチしたドキュメントを直接返す。通常の第一選択肢 | 2.0(モジュール)/ 8.0(組み込み) |
| FT.AGGREGATE | ファセット検索、計算フィールド、カスタム出力形式、分析 | 宣言的パイプライン:LOAD、APPLY、GROUPBY、REDUCE、SORTBY |
2.0 / 8.0 |
| FT.HYBRID | テキスト検索(BM25)とベクトル類似度を組み合わせる、融合方法は指定可能 | パイプライン形式で明示的なSEARCHレグ(処理段階)とVSIMレグ、およびCOMBINE融合段階 |
8.4.0 |
# FT.SEARCH — 最も一般的
FT.SEARCH idx:products "@category:{electronics} @price:[100 500]" LIMIT 0 20 RETURN 3 name price category
# FT.AGGREGATE — カテゴリ別の平均価格を集計
FT.AGGREGATE idx:products "*" GROUPBY 1 @category REDUCE AVG 1 @price AS avg_price SORTBY 2 @avg_price DESC
# FT.HYBRID (Redis ≥ 8.4) — テキスト検索とベクトル検索を融合
FT.HYBRID idx:docs
SEARCH "@title:transformers" SCORER BM25 YIELD_SCORE_AS lexscore
VSIM embedding $vec KNN count 1 K 50 YIELD_SCORE_AS vecscore
COMBINE RRF 2 CONSTANT 60
PARAMS 2 vec "..."
DIALECT 2
Redis 8.4未満の場合、テキスト検索とベクトル検索の融合はFT.SEARCH事前フィルタリング + =>[KNN ...]で近似できます。references/command-selection.md および references/hybrid-search.md を参照してください。
FT.CREATEFT.CREATEは、PREFIXにマッチするHashまたはJSONドキュメントにインデックスを設定します。必ずPREFIXを設定してください。DIALECT 2を使用してください(Redis 8以降のデフォルト、ベクトルクエリには必須)。
FT.CREATE idx:products ON HASH PREFIX 1 product:
SCHEMA
name TEXT WEIGHT 2.0
category TAG SORTABLE
price NUMERIC SORTABLE
location GEO
embedding VECTOR HNSW 6
TYPE FLOAT32
DIM 1536
DISTANCE_METRIC COSINE
アクセスパターンに対応した最も限定的なフィールド型を選びます:
| フィールド型 | 使用場面 | 注記 |
|---|---|---|
TEXT |
全文検索 | トークン化+語幹抽出される。完全一致検索ではない |
TAG |
完全一致 / フィルタリング | SORTABLE UNFを追加すればタグクエリが最速になる |
NUMERIC |
範囲クエリ、ソート | 価格、カウント、タイムスタンプ |
GEO |
緯度経度のポイント | 店舗、ユーザーの位置情報 |
GEOSHAPE |
ポリゴン / エリア検索 | 配送エリア、地域 |
VECTOR |
類似度検索 | HSNWまたはFLAT;第4項を参照 |
JSON $.path AS alias |
ネストされたJSONフィールド | ON JSON;references/json-indexing.mdを参照 |
よくある間違いは、「文字列だから」という理由でカテゴリやステータスフィールドにTEXTを使うことです — TAGは完全一致フィルタリングでおよそ10倍高速です。
references/index-creation.md、references/field-types.md、references/dialect.md、references/ft-create-options.md、references/json-indexing.md を参照してください。
フィルタで絞り込み、必要なものだけを返します。
# タグフィルタ + 数値範囲、価格でソート
FT.SEARCH idx:products "@category:{electronics} @price:[100 500]"
SORTBY price ASC
LIMIT 0 20
RETURN 3 name price category
# テキスト + タグフィルタ
FT.SEARCH idx:products "wireless headphones @category:{audio}"
# 否定とOR
FT.SEARCH idx:products "@category:{audio} -@brand:{generic} (@price:[0 100] | @on_sale:{true})"
よく使う演算子:スペース = AND、| = OR、- = NOT、~ = オプション(スコア向上)、=>{$weight: N} = スコア調整。タグ値内のハイフンと特殊文字はエスケープしてください(@sku:{ABC\\-123})。クエリ言語の詳細は references/query-syntax.md と references/search-syntax-primitives.md を参照してください。
トークン化の注意点(語幹抽出、ストップワード、言語)は references/text-tokenization.md を参照。結果の整形(SORTBY、RETURN、HIGHLIGHT、SUMMARIZE、NOCONTENT)は references/result-shaping.md を参照。パフォーマンス調整(事前フィルタリング、SORTABLEフィールド、限定的なRETURN、FT.PROFILE)は references/query-optimization.md を参照してください。
ベクトルの3つの設定は、使用する埋め込みモデル(テキストを数値に変換するモデル)と正確に一致している必要があります:
DIM — 出力の次元数(例:OpenAIのtext-embedding-3-smallなら1536)。不一致だと無言で無意味な結果が返るDISTANCE_METRIC — 正規化されたテキスト埋め込みにはCOSINE(一般的)、正規化されていない内積にはIP、ユークリッド距離にはL2TYPE — 通常はFLOAT32。メモリが極めて逼迫している場合のみFLOAT16や量子化(精度を落とす)変種を使用# インデックス
FT.CREATE idx:docs ON HASH PREFIX 1 doc:
SCHEMA
content TEXT
embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 1536 DISTANCE_METRIC COSINE
# 純粋なKNN(K近傍法・最近傍検索)クエリ(コサイン類似度上位5件)
FT.SEARCH idx:docs "*=>[KNN 5 @embedding $vec AS score]"
PARAMS 2 vec "..."
SORTBY score
DIALECT 2
| アルゴリズム | 速度 | 精度 | メモリ | 用途 |
|---|---|---|---|---|
| HNSW | 高速(近似) | ~95%以上の再現率(調整可能) | 多い | 本番環境:1万ベクトル以上、低レイテンシが重要 |
| FLAT | 低速(完全) | 100% | 少ない | 小規模コーパス(1万未満)、完全一致が必須 |
HNSW調整のレバー:M(16~64、ノードあたりの接続数)、EF_CONSTRUCTION(100~500、構築品質)、EF_RUNTIME(クエリ時の候補リスト)。
references/vector-query.md と references/algorithm-choice.md を参照してください。
「ハイブリッド」と呼ばれるパターンは2つあります。目的で選び分けてください。
フィルタ後ベクトル検索(すべてのRedisバージョン) — 属性フィルタを適用し、ベクトル比較の前に検索空間を絞ります。
FT.SEARCH idx:docs "(@category:{tech} @date:[2024 +inf])=>[KNN 10 @embedding $vec AS score]"
PARAMS 2 vec "..."
SORTBY score
DIALECT 2
テキスト検索とベクトル検索の融合(Redis ≥ 8.4) — BM25テキストスコアとベクトル類似度を組み合わせ、RRFまたはLINEARで融合します。FT.HYBRIDを使用してください(第1項参照)。
広い範囲の無フィルタ結果を取得してクライアント側でフィルタしないでください — 遅く、精度も低下します。references/hybrid-search.md を参照してください。
FT.AGGREGATEは宣言的な結果整形コマンドです。段階のパイプラインを構築します。
# 売上合計上位5カテゴリ
FT.AGGREGATE idx:orders "@status:{shipped}"
LOAD 2 @category @amount
GROUPBY 1 @category
REDUCE SUM 1 @amount AS revenue
SORTBY 2 @revenue DESC
LIMIT 0 5
一般的な段階:LOAD、APPLY(計算フィールド)、FILTER(クエリ後)、GROUPBY + REDUCE(SUM、COUNT、AVG、FIRST_VALUE、TOLIST)、SORTBY、LIMIT。
長時間実行される結果セットの場合は、WITHCURSOR + FT.CURSOR READでサーバー側ページネーションを使用してください。references/aggregate-pipeline.md と references/aggregate-cursors.md を参照してください。
標準的なパイプライン:クエリを埋め込み表現に変換 → Redis でベクトル検索 → 上位K件の内容をLLM(大規模言語モデル)に渡す。
実践的なヒント:
COSINEreferences/rag-pattern.md を参照してください。
システム停止
Single source of guidance for Redis Search — the retrieval surface that spans lexical, numeric, geo, JSON-path, and vector queries. Vector fields are part of the same FT.CREATE machinery as TEXT/TAG/NUMERIC fields, and FT.HYBRID blends lexical and vector ranking in one command, so this skill covers them together.
FT.CREATE, FT.ALTER).FT.SEARCH, FT.AGGREGATE, or FT.HYBRID queries.TEXT, TAG, NUMERIC, GEO, GEOSHAPE, VECTOR, or JSON-path fields.VECTOR field, choosing HNSW vs FLAT, tuning HNSW parameters.FT.EXPLAIN, FT.PROFILE, FT.INFO.Three query commands. Reach for the narrowest one that fits.
| Command | When to use | Mental model | Minimum Redis |
|---|---|---|---|
| FT.SEARCH | Document retrieval, ranked or sorted. Best default. | Returns matching docs directly. | 2.0 (module) / 8.0 (built-in) |
| FT.AGGREGATE | Faceting, computed fields, custom output shape, analytics. | Declarative pipeline: LOAD, APPLY, GROUPBY, REDUCE, SORTBY. |
2.0 / 8.0 |
| FT.HYBRID | Blend lexical (BM25) with vector similarity, with configurable fusion. | Pipeline with explicit SEARCH + VSIM legs and a COMBINE fusion stage. |
8.4.0 |
# FT.SEARCH — most common
FT.SEARCH idx:products "@category:{electronics} @price:[100 500]" LIMIT 0 20 RETURN 3 name price category
# FT.AGGREGATE — top categories by avg price
FT.AGGREGATE idx:products "*" GROUPBY 1 @category REDUCE AVG 1 @price AS avg_price SORTBY 2 @avg_price DESC
# FT.HYBRID (Redis ≥ 8.4) — lexical + vector fusion
FT.HYBRID idx:docs
SEARCH "@title:transformers" SCORER BM25 YIELD_SCORE_AS lexscore
VSIM embedding $vec KNN count 1 K 50 YIELD_SCORE_AS vecscore
COMBINE RRF 2 CONSTANT 60
PARAMS 2 vec "..."
DIALECT 2
For Redis < 8.4 the lexical+vector blend is approximated with FT.SEARCH pre-filter + =>[KNN ...]. See references/command-selection.md and references/hybrid-search.md.
FT.CREATEFT.CREATE indexes Hash or JSON documents matching a PREFIX. Always set PREFIX. Use DIALECT 2 (the default since Redis 8; required for vector queries).
FT.CREATE idx:products ON HASH PREFIX 1 product:
SCHEMA
name TEXT WEIGHT 2.0
category TAG SORTABLE
price NUMERIC SORTABLE
location GEO
embedding VECTOR HNSW 6
TYPE FLOAT32
DIM 1536
DISTANCE_METRIC COSINE
Pick the narrowest field type that supports your access pattern:
| Field type | Use when | Notes |
|---|---|---|
TEXT |
Full-text search | Tokenized + stemmed; not for exact match |
TAG |
Exact match / filtering | Add SORTABLE UNF for fastest tag queries |
NUMERIC |
Range queries, sorting | Prices, counts, timestamps |
GEO |
Lat/long points | Stores, users |
GEOSHAPE |
Polygon / area queries | Delivery zones, regions |
VECTOR |
Similarity search | HNSW or FLAT; see §4 |
JSON $.path AS alias |
Nested JSON fields | ON JSON; see references/json-indexing.md |
The classic mistake is TEXT for a category or status field "because it's a string" — TAG is roughly 10× faster for exact-match filtering.
See references/index-creation.md, references/field-types.md, references/dialect.md, references/ft-create-options.md, references/json-indexing.md.
Narrow with filters; return only what you need.
# Tag filter + numeric range, sorted by price
FT.SEARCH idx:products "@category:{electronics} @price:[100 500]"
SORTBY price ASC
LIMIT 0 20
RETURN 3 name price category
# Text + tag filter
FT.SEARCH idx:products "wireless headphones @category:{audio}"
# Negation and OR
FT.SEARCH idx:products "@category:{audio} -@brand:{generic} (@price:[0 100] | @on_sale:{true})"
Operators worth remembering: space = AND, | = OR, - = NOT, ~ = optional (scoring boost), =>{$weight: N} = boost. Escape hyphens and special characters inside TAG values (@sku:{ABC\\-123}). See references/query-syntax.md and references/search-syntax-primitives.md for the DSL vocabulary.
For tokenization gotchas (stemming, stopwords, language) see references/text-tokenization.md. For result shaping (SORTBY, RETURN, HIGHLIGHT, SUMMARIZE, NOCONTENT) see references/result-shaping.md. For performance levers (pre-filters, SORTABLE fields, tight RETURN, FT.PROFILE) see references/query-optimization.md.
Three vector settings have to match the embedding model exactly:
DIM — output dimensionality (e.g. 1536 for OpenAI text-embedding-3-small). Mismatch produces silent garbage.DISTANCE_METRIC — COSINE for normalized text embeddings (common case), IP for unnormalized inner-product, L2 for raw Euclidean.TYPE — usually FLOAT32. Use FLOAT16 or quantized variants only when memory is the binding constraint.# Index
FT.CREATE idx:docs ON HASH PREFIX 1 doc:
SCHEMA
content TEXT
embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 1536 DISTANCE_METRIC COSINE
# Pure KNN query (top 5 by cosine similarity)
FT.SEARCH idx:docs "*=>[KNN 5 @embedding $vec AS score]"
PARAMS 2 vec "..."
SORTBY score
DIALECT 2
| Algorithm | Speed | Accuracy | Memory | Use for |
|---|---|---|---|---|
| HNSW | Fast (approximate) | ~95%+ recall (tunable) | Higher | Production: >10k vectors, latency-sensitive |
| FLAT | Slow (exact) | 100% | Lower | Small corpora (<10k), exact-match required |
HNSW tuning levers: M (16–64, connections per node), EF_CONSTRUCTION (100–500, build quality), EF_RUNTIME (query-time candidate list).
See references/vector-query.md, references/algorithm-choice.md.
Two distinct patterns get called "hybrid." Pick by intent.
Filter-then-vector (any Redis version) — apply attribute filters so the engine narrows the search space before the vector comparison.
FT.SEARCH idx:docs "(@category:{tech} @date:[2024 +inf])=>[KNN 10 @embedding $vec AS score]"
PARAMS 2 vec "..."
SORTBY score
DIALECT 2
Lexical + vector fusion (Redis ≥ 8.4) — blend BM25 text scoring with vector similarity, fuse with RRF or LINEAR. Use FT.HYBRID (see §1).
Don't fetch a wide unfiltered result and filter client-side — slower and less accurate. See references/hybrid-search.md.
FT.AGGREGATE is the declarative result-shaping command. Build a pipeline of stages.
# Top 5 categories by total revenue
FT.AGGREGATE idx:orders "@status:{shipped}"
LOAD 2 @category @amount
GROUPBY 1 @category
REDUCE SUM 1 @amount AS revenue
SORTBY 2 @revenue DESC
LIMIT 0 5
Common stages: LOAD, APPLY (computed fields), FILTER (post-query), GROUPBY + REDUCE (SUM, COUNT, AVG, FIRST_VALUE, TOLIST), SORTBY, LIMIT.
For long-running result sets use WITHCURSOR + FT.CURSOR READ to page server-side. See references/aggregate-pipeline.md and references/aggregate-cursors.md.
Standard pipeline: embed the query, vector-search Redis, pass top-K context to the LLM.
Practical tips:
COSINE for normalized text models).See references/rag-pattern.md.
Zero-downtime schema changes: keep app queries pointed at an alias and swap the underlying index.
FT.CREATE idx:products_v2 ON HASH PREFIX 1 product: SCHEMA ...
FT.ALIASUPDATE products idx:products_v2
# App queries are stable:
FT.SEARCH products "@category:{electronics}"
Useful management commands: FT.INFO, FT.DROPINDEX, FT._LIST, FT.ALIASADD/UPDATE/DEL. See references/index-management.md.
Debug empty or slow queries with FT.EXPLAIN (shows how the query was parsed) and FT.PROFILE (shows execution stats). See references/debugging.md.
Inline examples in this SKILL.md are CLI / RESP form — the wire protocol every client serializes to. For idiomatic snippets in a specific client:
Other clients (Lettuce, node-redis, go-redis, NRedisStack, .NET) translate the same CLI form; coverage is tracked as a follow-up.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。