• Projects
  • Service
  • About
  • branding.bz
  • Podcast
  • Tips
  • FAQ
  • Recruit
  • Download
  • Contact
  • branding.bz(ブランド構築SaaS)
  • DESIGN NOW(デザインメディア)
  • X
  • LinkedIn
  • Spotify
  • Facebook

213-0011 神奈川県川崎市高津区久本3-6-7-303

© 2026 ID INC. All rights reserved

claude-skills/スキル
SKILLOfficialdatabase

redis-search

プラグイン
redis-development
ライセンス
MIT
ソース
GitHub で見る ↗
説明

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.

ユースケース
  • 検索インデックスを定義するとき
  • フィルタリングやソート機能を実装するとき
  • ベクトル類似度検索を行うとき
  • RAG検索パイプラインを構築するとき
  • 検索パフォーマンスをトラブルシューティングするとき
本文(日本語訳)

Redis Search

Redis Searchの総合ガイド — テキスト検索、数値検索、地理情報検索、JSONパス検索、ベクトル検索など、さまざまな種類の検索に対応した検索機能です。ベクトルフィールドはTEXT/TAG/NUMERICフィールドと同じFT.CREATEの仕組みで扱われ、FT.HYBRIDはテキスト検索とベクトル検索のスコアを1つのコマンドで組み合わせるため、このスキルではこれらをまとめて説明します。

使用する場合

  • Redis Searchのインデックス(検索用の索引)を作成、変更、見直すとき(FT.CREATE、FT.ALTER)
  • FT.SEARCH、FT.AGGREGATE、またはFT.HYBRIDのクエリ(問い合わせ)を書いたり最適化したりするとき
  • TEXT、TAG、NUMERIC、GEO、GEOSHAPE、VECTOR、JSONパスフィールドから適切なものを選ぶとき
  • VECTORフィールドを定義したり、HSNWと FLATのどちらかを選んだり、HSNWのパラメータを調整したりするとき
  • RAG(検索拡張生成・質問に答える際に、データベースから関連情報を取得して活用する技術)パイプラインを構築するとき
  • インデックススキーマ(データ構造の定義)をシステム停止なしでデプロイするとき
  • FT.EXPLAIN、FT.PROFILE、FT.INFOを使って、空の結果、遅いクエリ、トークン化(テキストの分割)の問題をトラブルシューティングするとき

1. 適切なコマンドを選ぶ

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 を参照してください。

2. スキーマの基本 — FT.CREATE

FT.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 を参照してください。

3. 一般的なクエリ

フィルタで絞り込み、必要なものだけを返します。

# タグフィルタ + 数値範囲、価格でソート
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 を参照してください。

4. ベクトル検索の基本

ベクトルの3つの設定は、使用する埋め込みモデル(テキストを数値に変換するモデル)と正確に一致している必要があります:

  • DIM — 出力の次元数(例:OpenAIのtext-embedding-3-smallなら1536)。不一致だと無言で無意味な結果が返る
  • DISTANCE_METRIC — 正規化されたテキスト埋め込みにはCOSINE(一般的)、正規化されていない内積にはIP、ユークリッド距離にはL2
  • TYPE — 通常は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 を参照してください。

5. ハイブリッド検索

「ハイブリッド」と呼ばれるパターンは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 を参照してください。

6. 集約と結果の整形

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 を参照してください。

7. RAGパターン

標準的なパイプライン:クエリを埋め込み表現に変換 → Redis でベクトル検索 → 上位K件の内容をLLM(大規模言語モデル)に渡す。

実践的なヒント:

  • メトリックはモデルに合わせる — ほぼすべての場合、正規化されたテキストモデルにはCOSINE
  • 長いドキュメントをチャンク化 — 200~500トークンのチャンク(分割片)が通常、ページ全体より効果的
  • バッチ挿入 — 1レコードずつの呼び出しではなくまとめて挿入
  • ベクトル検索の前に属性でフィルタ — テナント、最新性、ドキュメント型(第5項参照)
  • 精度が再現率より重要な場合は再ランク付け — ファネルの最初で実施

references/rag-pattern.md を参照してください。

8. 運用管理

システム停止

原文(English)を表示

Redis Search

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.

When to apply

  • Creating, modifying, or reviewing a Redis Search index (FT.CREATE, FT.ALTER).
  • Writing or optimizing FT.SEARCH, FT.AGGREGATE, or FT.HYBRID queries.
  • Picking between TEXT, TAG, NUMERIC, GEO, GEOSHAPE, VECTOR, or JSON-path fields.
  • Defining a VECTOR field, choosing HNSW vs FLAT, tuning HNSW parameters.
  • Building a retrieval-augmented generation (RAG) pipeline.
  • Rolling out a new index schema without downtime.
  • Troubleshooting empty results, slow queries, or tokenization issues with FT.EXPLAIN, FT.PROFILE, FT.INFO.

1. Pick the right command

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.

2. Schema basics — FT.CREATE

FT.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.

3. Common queries

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.

4. Vector basics

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.

5. Hybrid retrieval

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.

6. Aggregations and shaping

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.

7. RAG pattern

Standard pipeline: embed the query, vector-search Redis, pass top-K context to the LLM.

Practical tips:

  • Match the metric to the embedding model (almost always COSINE for normalized text models).
  • Chunk long documents (200–500-token chunks usually beat indexing whole pages).
  • Batch inserts rather than one call per record.
  • Pre-filter with attributes (tenant, recency, document type) before the vector search — see §5.
  • Re-rank at the top of the funnel if precision matters more than recall.

See references/rag-pattern.md.

8. Operations

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.

9. Client examples

Inline examples in this SKILL.md are CLI / RESP form — the wire protocol every client serializes to. For idiomatic snippets in a specific client:

  • redis-py (Python, raw client): references/clients/python-redis-py.md
  • Jedis (Java): references/clients/java-jedis.md
  • RedisVL (Python, higher-level SDK on top of redis-py): references/clients/python-redisvl.md

Other clients (Lettuce, node-redis, go-redis, NRedisStack, .NET) translate the same CLI form; coverage is tracked as a follow-up.

References

  • Redis: Search and query
  • Redis: Vectors
  • Redis: Query syntax
  • Redis: Query dialects
  • Redis: RAG quickstart
  • FT.CREATE · FT.SEARCH · FT.AGGREGATE · FT.HYBRID
  • RedisVL documentation

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。