Redis®*: ベクトル検索とRAG

Redisによるセマンティック検索、レコメンデーション、リトリーバル拡張生成(RAG)

👋 Stackhero ドキュメントへようこそ!

Stackhero では、すぐに使える Redis cloud ソリューションをご提供しています。主な特長は以下の通りです:

  • Redis Commander Web UI を標準搭載。
  • メッセージサイズ・転送量が無制限
  • ワンクリックで簡単にアップデート可能。
  • プライベートかつ専用インフラによる最適なパフォーマンスと強固なセキュリティ

時間を節約し、運用をシンプルに:Stackhero の Redis cloud hosting ソリューションは、わずか5分でお試しいただけます!

セマンティック検索、レコメンデーションエンジン、またはリトリーバル拡張生成(RAG)パイプラインを構築する場合、埋め込み(embedding)を保存し、クエリに最も近いマッチを高速に検索できる信頼性の高い仕組みが必要です。Stackhero上のRedisインスタンスはこれをネイティブに提供します。クエリエンジンがベクトルをインデックスし、類似検索にミリ秒単位で応答します。Redisの横に別のベクトルデータベースを追加する必要はありません。すべてが1つの場所で動作します。

このアプローチは、次の2つの主要な機能により生産的かつ効率的です:

  • ハイブリッドクエリ。 ベクトル類似度検索と、数値範囲・タグ・全文検索などの標準的なフィルタを1つのリクエストで組み合わせることができます。たとえば「この質問に最も近い5つのチャンク、ただしこのユーザーが閲覧可能で1月以降に公開されたドキュメントのみ」といった条件も、複数回のクエリではなく1回で取得できます。
  • シンプルなアーキテクチャ。 Embedding、キャッシュ、セッションが同じ場所に共存し、認証情報、バックアップ、モニタリングも共有します。これによりシステムの複雑さとオーバーヘッドが削減されます。

サービス設定のModulesセクションでSearchモジュール(ドキュメントをJSON形式で保存する場合はJSONも)を有効化してください。設定はStackheroダッシュボードから行えます。詳細な手順はSearchとJSONガイドをご参照ください。

ベクトルフィールドを宣言するには、その次元数(dimension)と距離メトリック(distance metric)を指定します。次元数はご利用のembeddingモデルに合わせてください。例:OpenAIのtext-embedding-3-smallなら1536、オープンソースモデルの多くは768など。

FT.CREATE chunksIndex
  ON HASH
  PREFIX 1 chunk:
  SCHEMA
    content TEXT
    documentId TAG
    publishedAt NUMERIC
    embedding VECTOR HNSW 6
      TYPE FLOAT32
      DIM 1536
      DISTANCE_METRIC COSINE

HNSWはグラフインデックスを作成し、コレクションが増えても高速なクエリを維持します。数千ベクトルを超える場合に推奨されます。小規模コレクションで厳密な一致が重要な場合は、FLATによる全探索も選択できます。

COSINEは多くのテキストembeddingモデルで推奨される距離メトリックです。用途に応じてL2IPも選択可能です。

K近傍(KNN)クエリは以下のように記述します。ベクトルはリトルエンディアンのfloat32バイト列として渡します:

FT.SEARCH chunksIndex "*=>[KNN 5 @embedding $queryVector AS score]"
  PARAMS 2 queryVector "<rawBytes>"
  SORTBY score
  RETURN 2 content score
  DIALECT 2

類似度検索とフィルタを組み合わせる場合は、*をフィルタ式に置き換えるだけです:

FT.SEARCH chunksIndex "(@documentId:{doc42} @publishedAt:[1735689600 +inf])=>[KNN 5 @embedding $queryVector AS score]"
  PARAMS 2 queryVector "<rawBytes>"
  SORTBY score
  DIALECT 2

ベクトルクエリにはDIALECT 2が必須です。省略すると旧構文となり、エラーが返されます。

import { createClient, SCHEMA_FIELD_TYPE, SCHEMA_VECTOR_FIELD_ALGORITHM } from 'redis';

const client = createClient({ url: process.env.STACKHERO_REDIS_URL_TLS });
await client.connect();

const DIMENSIONS = 1536;
const toBytes = embedding => Buffer.from(new Float32Array(embedding).buffer);

// 1. 起動時に一度だけインデックスを作成
try {
  await client.ft.create(
    'chunksIndex',
    {
      content: SCHEMA_FIELD_TYPE.TEXT,
      documentId: SCHEMA_FIELD_TYPE.TAG,
      embedding: {
        type: SCHEMA_FIELD_TYPE.VECTOR,
        ALGORITHM: SCHEMA_VECTOR_FIELD_ALGORITHM.HNSW,
        TYPE: 'FLOAT32',
        DIM: DIMENSIONS,
        DISTANCE_METRIC: 'COSINE'
      }
    },
    { ON: 'HASH', PREFIX: 'chunk:' }
  );
}
catch (error) {
  if (!error.message.includes('Index already exists')) {
    throw error;
  }
}

// 2. チャンクをインデックス化(embeddingはモデルプロバイダーから取得)
async function indexChunk({ id, documentId, content, embedding }) {
  await client.hSet(`chunk:${id}`, {
    content,
    documentId,
    embedding: toBytes(embedding)
  });
}

// 3. 質問に最も近いチャンクを、特定ドキュメントに限定して取得
async function retrieve({ questionEmbedding, documentId, count = 5 }) {
  const results = await client.ft.search(
    'chunksIndex',
    `(@documentId:{${documentId}})=>[KNN ${count} @embedding $queryVector AS score]`,
    {
      PARAMS: { queryVector: toBytes(questionEmbedding) },
      SORTBY: 'score',
      RETURN: [ 'content', 'score' ],
      DIALECT: 2
    }
  );

  return results.documents.map(({ value }) => value.content);
}

// 4. モデルへのコンテキストとして渡す
const context = await retrieve({ questionEmbedding, documentId: 'doc42' });
const prompt = `Answer using only this context:\n\n${context.join('\n\n')}\n\nQuestion: ${question}`;
import os
import numpy as np
import redis
from redis.commands.search.field import TextField, TagField, VectorField
from redis.commands.search.index_definition import IndexDefinition, IndexType
from redis.commands.search.query import Query

DIMENSIONS = 1536

r = redis.from_url(os.environ['STACKHERO_REDIS_URL_TLS'])

# 起動時に一度だけインデックスを作成
try:
    r.ft('chunksIndex').create_index(
        (
            TextField('content'),
            TagField('documentId'),
            VectorField(
                'embedding',
                'HNSW',
                {'TYPE': 'FLOAT32', 'DIM': DIMENSIONS, 'DISTANCE_METRIC': 'COSINE'},
            ),
        ),
        definition=IndexDefinition(prefix=['chunk:'], index_type=IndexType.HASH),
    )
except redis.ResponseError as error:
    if 'Index already exists' not in str(error):
        raise


def index_chunk(chunk_id, document_id, content, embedding):
    r.hset(
        f'chunk:{chunk_id}',
        mapping={
            'content': content,
            'documentId': document_id,
            'embedding': np.array(embedding, dtype=np.float32).tobytes(),
        },
    )


def retrieve(question_embedding, document_id, count=5):
    query = (
        Query(f'(@documentId:{{{document_id}}})=>[KNN {count} @embedding $queryVector AS score]')
        .sort_by('score')
        .return_fields('content', 'score')
        .dialect(2)
    )
    results = r.ft('chunksIndex').search(
        query,
        query_params={'queryVector': np.array(question_embedding, dtype=np.float32).tobytes()},
    )
    return [document.content for document in results.docs]

ベクトルはメモリ上に保存されます。必要なメモリ容量は次の式で見積もれます:

numberOfVectors x dimensions x 4 bytes に加え、HNSWグラフ用に約30~50%の追加メモリが必要です。

例えば、1536次元のベクトルが100万件の場合、生データだけで約6GBを消費します。この規模なら20GBプランが快適なスタートポイントです。メモリ使用量を抑えるには:

  • より小さいモデルを使う。 例えば768次元モデルなら、1536次元モデルの半分のメモリで済みます。
  • モデルが対応していればFLOAT32の代わりにFLOAT16で保存することで、さらに半分に削減できます。

実際の使用量はFT.INFO chunksIndexや、Prometheusモニタリングused_memoryメトリクスで確認できます。利用量が増えた場合も、ダッシュボードから簡単にプランアップグレードが可能です。

  • ベクトルインデックスはデータベース0でのみ動作します。 これはRedisの全検索インデックス共通の仕様です。
  • ベクトルセットはセットアップ不要のシンプルな代替手段です。 VADDVSIMコマンドはRedisに組み込まれており、モジュール有効化なしですぐに類似検索が利用できます。単一セットでのシンプルなレコメンデーション用途に便利です。フィルタやページネーション、複数フィールドが必要な場合はクエリエンジンの利用を推奨します。
  • 既存キーへのインデックス構築はバックグラウンドで実行されます。 進捗はFT.INFOで確認できます。インデックス作成中は検索結果が部分的になる場合があります。

Redisのベクトル検索についてさらに詳しく知りたい場合は、公式Redis vector searchドキュメントをご覧ください。