notes / saas / 搜索引擎选型

🔍 搜索引擎选型

Meilisearch · Typesense · Elasticsearch · OpenSearch · Vespa · pgvector · 向量搜索 · 混合搜索
从应用内搜索到 AI 驱动的语义检索，一文搞懂选什么

01 搜索引擎全景：2026 年的分叉路口

2018 年，"用什么搜索引擎"几乎只有一个答案：Elasticsearch。日志用它、站内搜索用它、推荐也勉强用它。

2026 年，同一个问题至少分裂成五个方向：

02 全文搜索基础：倒排索引与 BM25

倒排索引（Inverted Index）

搜索引擎的核心数据结构。不是"文档→词"，而是"词→文档列表"。

# 正排索引：文档 → 词
Doc1: ["搜索引擎", "选型", "SaaS"]
Doc2: ["Meilisearch", "搜索引擎", "Rust"]

# 倒排索引：词 → 文档列表
"搜索引擎" → [Doc1, Doc2]
"选型"      → [Doc1]
"SaaS"      → [Doc1]
"Meilisearch" → [Doc2]
"Rust"      → [Doc2]

倒排索引让查找包含某个词的文档变成 O(1) 的跳表查找，而不是遍历所有文档。

BM25 算法

全文搜索的默认排序算法。核心思想：一个词在文档中出现越多、在整个语料库中越罕见，这个文档的相关性越高。

BM25 的局限性

• ❌ 只能匹配精确词或前缀，无法理解语义：搜"笔记本"找不到"laptop"
• ❌ 拼写错误容忍有限：需要额外的模糊匹配或 typo tolerance
• ❌ 同义词需要手动配置：无法自动发现"手机"和"移动设备"的关联
• ✅ 精确匹配能力强：产品名、型号、SKU 等精确查询仍然首选 BM25
• ✅ 成熟、可解释、性能稳定

03 向量搜索：语义检索的崛起

Embedding：把文本变成数字

向量搜索的第一步是将文本通过嵌入模型转换为高维向量。语义相近的文本在向量空间中距离更近。

# 使用 OpenAI text-embedding-3-small
from openai import OpenAI
client = OpenAI()

response = client.embeddings.create(
    model="text-embedding-3-small",
    input="笔记本电脑推荐"
)
# → 1536 维向量 [0.0023, -0.0145, 0.0078, ...]

response2 = client.embeddings.create(
    model="text-embedding-3-small", 
    input="laptop recommendation"
)
# → 语义相似，向量距离很近！

HNSW 索引

目前最主流的向量索引算法（Hierarchical Navigable Small World）。几乎所有搜索引擎都用它。

向量搜索的局限

• ❌ 精确查询能力弱：搜特定产品名"iPhone 15 Pro Max 256GB"可能不如 BM25
• ❌ 嵌入成本：每次写入都需要调用嵌入模型，大规模数据很贵
• ❌ 向量维度占用空间：1536 维 × 4 bytes = 6KB/条，百万条 = 6GB 仅向量
• ✅ 语义理解强：跨语言、同义词、意图匹配

04 混合搜索：2026 年的标准答案

Reciprocal Rank Fusion (RRF)

最常用的多路召回合并算法。不需要归一化分数，直接用排名：

# RRF 公式
score(d) = Σ 1 / (k + rank_i(d))

# 示例：某文档在 BM25 排第 2，向量排第 5
# k = 60（默认值）
score = 1/(60+2) + 1/(60+5) = 0.0161 + 0.0154 = 0.0315

典型混合搜索架构

各引擎的混合搜索实现

05 Meilisearch — 极简主义的 Rust 之选

核心特性

• 单二进制文件：一个 Rust 静态二进制，无 JVM、无依赖，curl -L | ./meilisearch 即跑
• 近零配置：启动 → POST JSON 文档 → 立即搜索
• 内置 typo tolerance：拼错也能搜到，无需配置
• 前缀搜索、高亮、分面、同义词：应用内搜索需要的一切都内置
• 向量 + 混合搜索（v1.6+）：通过 semanticRatio 调配 BM25 与向量的权重

混合搜索代码示例

// Meilisearch 1.x — 混合搜索
const results = await client.index('products').search('蓝色跑鞋', {
  hybrid: {
    embedder: 'openai',        // 使用已配置的 OpenAI embedder
    semanticRatio: 0.7,        // 70% 向量，30% BM25
  },
  limit: 20,
  attributesToHighlight: ['name', 'description'],
})

// 配置 embedder（一次性设置）
await client.index('products').updateSettings({
  embedders: {
    openai: {
      source: 'openAi',
      model: 'text-embedding-3-small',
      apiKey: process.env.OPENAI_API_KEY,
      documentTemplate: '{{doc.name}} {{doc.description}}',
    }
  }
})

性能数据

✅ 优势

• 运维最简单的搜索引擎：单进程、自动索引、无需调分片
• 前端 SDK 极其友好：InstantMeiliSearch 5 分钟接入 React/Vue
• typo tolerance 算法优秀（基于前缀 + 拼写距离）
• Edge/Self-host 友好，适合小团队和独立开发者
• 混合搜索开箱即用，semanticRatio 一个参数搞定

❌ 劣势

• 分布式和分片不如 Elasticsearch 成熟（多节点集群仍是实验特性）
• 不适合日志/OLAP 场景
• 单索引超过数亿文档时稳定性不如 ES
• 没有 SQL 风格的聚合查询
• 嵌入模型需要外部 API（OpenAI 等），或自建嵌入服务

何时选 Meilisearch

06 Typesense — 开发者友好的 C++ 快马

核心特性

• Raft 共识集群：内置高可用，多节点自动选主、数据复制
• 低内存占用：相比 Elasticsearch 降低 62%（< 10M 文档场景）
• 内存映射索引：索引存在磁盘但通过 mmap 按需加载，内存友好
• 向量搜索（v0.24+）：支持 HNSW 向量字段和多路召回
• 94% 召回率对齐：与 Elasticsearch 在 < 10M 文档量级上召回相当

代码示例

# Typesense — 创建集合并启用向量搜索
curl -X POST 'http://localhost:8108/collections' \
  -H 'X-TYPESENSE-API-KEY: xyz' \
  -d '{
    "name": "products",
    "fields": [
      {"name": "name", "type": "string"},
      {"name": "description", "type": "string"},
      {"name": "price", "type": "float"},
      {"name": "embedding", "type": "float[]", "num_dim": 1536}
    ]
  }'

# 混合搜索：全文 + 向量
curl 'http://localhost:8108/multi_search' \
  -H 'X-TYPESENSE-API-KEY: xyz' \
  -d '{
    "searches": [
      {"collection": "products", "q": "蓝色跑鞋", "query_by": "name,description"},
      {"collection": "products", "q": "*", "vector_query": "embedding:([0.01,-0.02,...]),k:50"}
    ]
  }'

✅ 优势

• Raft 集群开箱即用，高可用比 Meilisearch 成熟
• 内存占用低（mmap 磁盘索引），适合 VPS 部署
• API 简洁直观，学习成本低
• 社区活跃，2026 年被多个博主评为"最佳甜蜜点"

❌ 劣势

• GPL v3 许可证对企业有顾虑（Meilisearch 是 MIT）
• 混合搜索不如 Meilisearch 顺滑（需要 multi_search 手动合并）
• 生态和插件不如 Elasticsearch 丰富
• 大规模（>10M 文档）性能还需要更多生产验证
• 无内置 Reranker

Meilisearch vs Typesense 关键差异

07 Elasticsearch — 巨人仍在

2024-2026 关键变化

许可证回归开源

2024 年底，Elastic 将 Elasticsearch 和 Kibana 重新以 AGPL v3 开源（同时保留 Elastic License v2 二选一）。这直接回应了 OpenSearch 阵营，激活了自托管和第三方云服务的信心。

ESQL — 管道式 SQL 查询语言

-- ESQL：ES 8.11+ 的管道式查询
FROM logs-*
| WHERE @timestamp > NOW() - 1 hour AND http.status >= 500
| STATS count(*) BY service.name
| SORT count DESC
| LIMIT 10

ESQL 让 Elasticsearch 在日志/指标场景更接近 OLAP，可直接与 ClickHouse/Apache Doris 竞争。

向量搜索一等公民

8.x 后期版本：dense_vector 字段 + HNSW 索引 + BM25 + kNN 混合搜索已标准化。ELSER（Elastic 训练的稀疏嵌入模型）和学习排序（learning_to_rank）让 RAG 管线可以完全在 ES 内闭环。

代码示例：混合搜索

# Elasticsearch 8.x — 混合搜索
POST products/_search
{
  "query": {
    "bool": {
      "should": [
        {
          "match": {
            "name": {
              "query": "蓝色跑鞋",
              "boost": 0.3
            }
          }
        }
      ]
    }
  },
  "knn": {
    "field": "embedding",
    "query_vector": [0.01, -0.02, ...],
    "k": 50,
    "num_candidates": 200,
    "boost": 0.7
  },
  "rank": {
    "rrf": {
      "window_size": 100,
      "rank_constant": 60
    }
  },
  "size": 10
}

✅ 优势

• 最全能：搜索、日志、指标、分析、AI 一站式
• 生态最丰富：Kibana、Logstash、Beats、Fleet、APM
• 8.x 混合搜索 + ESQL + RRF 开箱
• 10 亿级文档的生产验证最多

❌ 劣势

• 运维复杂：JVM 调优、分片策略、副本管理、冷热分层
• 成本高：同等数据量资源消耗是 Meilisearch/Typesense 的 3-5 倍
• 冷数据存储成本惊人（热层存日志越来越贵）
• 查询 DSL 复杂，学习曲线陡峭
• 对于简单搜索场景，严重过度工程

08 OpenSearch — AWS 生态的自然选择

关键变化

• 治理独立：2024 年 9 月移至 Linux 基金会下的 OpenSearch Software Foundation，SAP、Uber、Atlassian 加入
• 向量搜索：opensearch-knn 插件，HNSW/IVF，Faiss 和 Lucene 双后端可选
• ML 插件：内置模型服务，支持在集群内运行嵌入模型
• PPL（Piped Processing Language）：ESQL 的 OpenSearch 对应物

✅ 何时选 OpenSearch

• 你完全在 AWS 上运行，需要托管搜索服务
• 需要避免 Elastic License v2 的 SaaS 转售限制
• Apache 2.0 许可证最宽松

❌ 何时避开

• 功能迭代略落后于 Elasticsearch（尤其 ESQL vs PPL）
• 非 AWS 环境下，与 Elasticsearch 无显著优势
• 社区和文档规模不如 Elasticsearch

09 Vespa — 实时 AI 服务引擎

Vespa 的独特定位

其他搜索引擎是"存好索引 → 查询时检索"的离线模式。Vespa 可以在查询时实时执行 ML 模型——这意味着每个用户的搜索结果可以是实时个性化排序的。

代码示例：Vespa 排序表达式

  
    expression: 0.3 * bm25(name) + 0.7 * closeness(field, embedding)
  
  
    expression: onnx(model_name) { ... }  
  

✅ 优势

• 唯一支持查询时实时运行 ML 模型的搜索引擎
• 原生多路召回 + ranking profiles，混合搜索最优雅
• 推荐系统 + 搜索 + RAG 三合一
• 生产级大规模验证（Spotify 亿级用户）

❌ 劣势

• 学习曲线最陡：ranking expression、services.xml、application package
• 运维复杂度高，不适合小项目
• 社区和文档规模小于 Elasticsearch
• 简单搜索场景是杀鸡用牛刀

10 PostgreSQL + pgvector — 不加新组件的搜索方案

PostgreSQL 全文搜索

-- PostgreSQL 内置全文搜索
-- 创建 tsvector 索引
CREATE INDEX idx_products_search ON products 
  USING GIN (to_tsvector('simple', name || ' ' || description));

-- 全文搜索查询
SELECT name, ts_rank(search_vector, query) AS rank
FROM products, plainto_tsquery('simple', '蓝色跑鞋') query
WHERE search_vector @@ query
ORDER BY rank DESC
LIMIT 20;

pgvector 向量搜索

-- 安装 pgvector 扩展
CREATE EXTENSION IF NOT EXISTS vector;

-- 添加向量列
ALTER TABLE products ADD COLUMN embedding vector(1536);

-- 创建 HNSW 索引
CREATE INDEX idx_products_embedding ON products 
  USING hnsw (embedding vector_cosine_ops);

-- 向量搜索
SELECT name, 1 - (embedding <=> '[0.01,-0.02,...]'::vector) AS similarity
FROM products
ORDER BY embedding <=> '[0.01,-0.02,...]'::vector
LIMIT 20;

混合搜索：SQL 联合

-- PostgreSQL 混合搜索：BM25 + 向量
WITH bm25_results AS (
  SELECT id, ts_rank(search_vector, query) AS bm25_score
  FROM products, plainto_tsquery('simple', '蓝色跑鞋') query
  WHERE search_vector @@ query
  LIMIT 100
),
vector_results AS (
  SELECT id, 1 - (embedding <=> '[0.01,...]'::vector) AS vec_score
  FROM products
  ORDER BY embedding <=> '[0.01,...]'::vector
  LIMIT 100
)
SELECT 
  COALESCE(b.id, v.id) AS id,
  COALESCE(b.bm25_score, 0) * 0.3 + COALESCE(v.vec_score, 0) * 0.7
    AS combined_score
FROM bm25_results b
FULL OUTER JOIN vector_results v ON b.id = v.id
ORDER BY combined_score DESC
LIMIT 20;

✅ 优势

• 零额外基础设施：已有 PostgreSQL 就能搜
• 事务一致性：搜索索引与数据在同一事务中
• 运维成本最低：不需要管第二个系统
• pgvector 0.7+ 的 HNSW 索引性能已相当可用

❌ 劣势

• 全文搜索分词器对中文支持弱（需 jieba/sudachi 扩展）
• 无内置 typo tolerance、同义词扩展
• 大规模（>10M 文档）性能不如专用搜索引擎
• 混合搜索需要手写 SQL，无内置 RRF
• 无分面、无高亮、无自动补全等搜索 UI 特性

11 全面对比表

12 决策框架：我该选什么？

13 实战代码示例

场景：SaaS 产品搜索 API（Node.js + Meilisearch）

// products-search.js — 完整的搜索 API
import { MeiliSearch } from 'meilisearch'

const client = new MeiliSearch({ host: 'http://localhost:7700', apiKey: 'masterKey' })
const index = client.index('products')

// 初始化索引设置
await index.updateSettings({
  searchableAttributes: ['name', 'description', 'category', 'brand'],
  filterableAttributes: ['price', 'category', 'brand', 'inStock'],
  sortableAttributes: ['price', 'createdAt', 'rating'],
  displayedAttributes: ['id', 'name', 'price', 'category', 'brand', 'image', 'rating'],
  rankingRules: [
    'words', 'typo', 'proximity', 'attribute', 'sort', 'exactness'
  ],
  synonyms: {
    '手机': ['移动设备', 'cellphone'],
    '笔记本': ['laptop', '笔记本电脑'],
  },
  typoTolerance: {
    enabled: true,
    minWordSizeForTypos: { oneTypo: 4, twoTypos: 8 },
    disableOnAttributes: ['id'],  // ID 字段不允许模糊
  },
  embedders: {
    openai: {
      source: 'openAi',
      model: 'text-embedding-3-small',
      apiKey: process.env.OPENAI_API_KEY,
      documentTemplate: '{{doc.name}} {{doc.category}} {{doc.description}}',
    }
  }
})

// 搜索 API
export async function searchProducts(query, filters = {}) {
  const { category, minPrice, maxPrice, hybrid = true } = filters

  const searchParams = {
    q: query,
    limit: 20,
    attributesToHighlight: ['name', 'description'],
    filter: buildFilter(category, minPrice, maxPrice),
    sort: filters.sortBy ? [`${filters.sortBy}:${filters.sortOrder || 'desc'}`] : undefined,
  }

  // 混合搜索：语义 + 全文
  if (hybrid) {
    searchParams.hybrid = {
      embedder: 'openai',
      semanticRatio: 0.6,  // 60% 语义，40% 关键词
    }
  }

  const results = await index.search(query, searchParams)
  
  return {
    hits: results.hits.map(formatHit),
    total: results.estimatedTotalHits,
    processingTime: results.processingTimeMs,
  }
}

function buildFilter(category, minPrice, maxPrice) {
  const parts = []
  if (category) parts.push(`category = "${category}"`)
  if (minPrice) parts.push(`price >= ${minPrice}`)
  if (maxPrice) parts.push(`price <= ${maxPrice}`)
  return parts.length ? parts.join(' AND ') : undefined
}

function formatHit(hit) {
  return {
    ...hit,
    _highlight: hit._formatted,  // 高亮版本
  }
}

场景：RAG 混合检索（Python + pgvector）

# rag_search.py — RAG 混合检索
import asyncpg
from openai import AsyncOpenAI

openai = AsyncOpenAI()

class RAGSearch:
    def __init__(self, db_url: str):
        self.db_url = db_url
        self.pool = None

    async def init(self):
        self.pool = await asyncpg.create_pool(self.db_url)

    async def embed(self, text: str) -> list[float]:
        resp = await openai.embeddings.create(
            model="text-embedding-3-small",
            input=text,
        )
        return resp.data[0].embedding

    async def hybrid_search(self, query: str, limit: int = 10):
        """混合搜索：全文 + 向量，RRF 合并"""
        query_vec = await self.embed(query)
        vec_str = str(query_vec).replace("[", "").replace("]", "")

        async with self.pool.acquire() as conn:
            rows = await conn.fetch("""
                WITH bm25 AS (
                    SELECT id, ts_rank(
                        fts, plainto_tsquery('simple', $1)
                    ) AS score
                    FROM documents
                    WHERE fts @@ plainto_tsquery('simple', $1)
                    LIMIT 100
                ),
                vec AS (
                    SELECT id, 1 - (embedding <=> $2::vector) AS score
                    FROM documents
                    ORDER BY embedding <=> $2::vector
                    LIMIT 100
                )
                SELECT 
                    COALESCE(b.id, v.id) AS id,
                    COALESCE(1.0/(60 + ROW_NUMBER() OVER (
                        ORDER BY b.score DESC
                    )), 0) * 0.3 +
                    COALESCE(1.0/(60 + ROW_NUMBER() OVER (
                        ORDER BY v.score DESC
                    )), 0) * 0.7
                    AS rrf_score
                FROM bm25 b
                FULL OUTER JOIN vec v ON b.id = v.id
                ORDER BY rrf_score DESC
                LIMIT $3
            """, query, f"[{vec_str}]", limit)

            # 获取完整文档
            ids = [r["id"] for r in rows]
            if not ids:
                return []
            
            docs = await conn.fetch(
                "SELECT * FROM documents WHERE id = ANY($1)", ids
            )
            return docs

14 进阶主题

中文搜索的特殊挑战

搜索结果缓存策略

# Redis 缓存热门搜索结果
import redis
import json
import hashlib

r = redis.Redis()

async def cached_search(query: str, filters: dict, ttl: int = 300):
    """搜索结果缓存：热门查询 5 分钟"""
    cache_key = f"search:{hashlib.md5(f'{query}:{filters}'.encode()).hexdigest()}"
    
    # 命中缓存
    cached = r.get(cache_key)
    if cached:
        return json.loads(cached)
    
    # 未命中：执行搜索
    results = await search_products(query, filters)
    
    # 写入缓存
    r.setex(cache_key, ttl, json.dumps(results))
    return results

搜索分析：追踪用户行为

# 记录搜索行为 → 后续优化排序
search_events = [
    {"query": "蓝色跑鞋", "results_count": 42, "clicked_pos": 2, "timestamp": "..."},
    {"query": "蓝色跑鞋", "results_count": 42, "clicked_pos": null, "timestamp": "..."},
    # null = 没有点击任何结果 → 可能排序不好
]

# 计算点击率 (CTR) 和 平均点击位置
# 用于：1. 发现零结果查询 2. 发现低 CTR 查询 3. A/B 测试排序策略

搜索迁移路径

替代方案速览

15 关联模块