AI 赋能电商搜索的架构进阶：从关键词匹配到语义理解的全链路优化

AI 赋能电商搜索的架构进阶从关键词匹配到语义理解的全链路优化一、电商搜索的演进痛点传统电商搜索基于倒排索引 TF-IDF/BM25 评分。核心问题是词不达意用户搜索白色连衣裙适合夏天穿的分词后变成[白色, 连衣裙, 适合, 夏天, 穿]BM25 对每个词做 OR/AND 匹配结果排序依赖词频和逆文档频率。但用户真正想要的是透气轻薄面料的白色连衣裙——隐含语义被完全丢失。语义搜索的引入不是替代倒排索引而是补充。倒排索引保证精确匹配品牌名、型号、SKU语义搜索解决模糊意图生日礼物送女朋友、适合露营的装备。graph TD A[用户查询] -- B[查询分析] B -- C[意图分类] C --|精确 SKU 搜索| D[倒排索引 BM25] C --|模糊语义搜索| E[向量检索] C --|混合搜索| F[并行双路检索] D -- G[召回候选集 Top-200] E -- G F -- G G -- H[粗排层] H -- I[精排层br/CTR/CVR 预估] I -- J[重排层br/多样性、打散] J -- K[返回 Top-20 结果] style E fill:#9cf,stroke:#333二、离线 Embedding 生成的工程优化商品库通常有百万级 SKU每个 SKU 需要生成 Embedding。按 1536 维 float32 计算百万商品的 Embedding 矩阵约 6GB。生成和存储都有优化空间。批量生成优化import asyncio from openai import AsyncOpenAI async def generate_embeddings_batch(texts: list[str], batch_size: int 100) - list[list[float]]: client AsyncOpenAI() embeddings [] for i in range(0, len(texts), batch_size): batch texts[i:i batch_size] resp await client.embeddings.create( modeltext-embedding-3-small, # 512 维即可电商不需要 3072 维 inputbatch, ) embeddings.extend([d.embedding for d in resp.data]) return embeddings # 商品文本拼接标题 类目 属性标签权重通过重复调整 def build_product_text(product: dict) - str: parts [ product[title], # 白色连衣裙夏季新款 product[title], # 标题权重 ×2 .join(product[category]), # 女装 连衣裙 .join(product[attributes]), # 纯棉 V领 短袖 ] return .join(parts)向量存储选择方案QPS (Top-100)P99 延迟内存占用 (百万条)适用场景FAISS IVF100020ms3GB离线批量检索Milvus50010ms8GB在线低延迟pgvector20050ms6GB与业务库同源Redis Vector8005ms12GB超高并发三、在线推理的延迟优化在线搜索的延迟预算通常只有 200ms向量检索必须在 50ms 内完成。三招优化1. 查询向量缓存import hashlib import redis cache redis.Redis() def get_query_embedding(query: str) - list[float]: cache_key femb:{hashlib.md5(query.encode()).hexdigest()} cached cache.get(cache_key) if cached: import json return json.loads(cached) embedding call_embedding_api(query) cache.setex(cache_key, 3600, json.dumps(embedding)) return embedding2. 分层检索先粗排再精排def two_stage_retrieval(query_embedding, query_text): # 第一层向量检索召回 Top-200 vec_candidates vector_index.search(query_embedding, k200) # 第二层倒排索引 BM25 再排序 text_candidates inverted_index.search(query_text, k100) # 合并去重 all_ids set(vec_candidates) | set(text_candidates) # 精排调用轻量级排序模型 candidates [product_store[id] for id in all_ids] scored cross_encoder.rank(query_text, candidates) return scored[:20]3. 结果预计算对于高频查询Top 1000 query离线预计算检索结果并缓存。查询时直接返回缓存结果延迟降至 5ms 以内。-- 高频查询的预计算表 CREATE TABLE query_cache ( query_text VARCHAR(200) PRIMARY KEY, result_ids INT[] NOT NULL, updated_at TIMESTAMP DEFAULT NOW() ); -- 每天凌晨更新 INSERT INTO query_cache (query_text, result_ids) SELECT q.query_text, array_agg(p.id ORDER BY score DESC) FROM top_queries q CROSS JOIN LATERAL semantic_search(q.query_embedding, 20) p ON CONFLICT (query_text) DO UPDATE SET result_ids EXCLUDED.result_ids;四、质量评估与迭代闭环语义搜索的核心风险是相关性不可解释。需要建立从线上数据到离线评估的闭环def evaluate_search_quality(): # 收集线上行为数据 # 点击率 (CTR) 点击数 / 曝光数 # 加购率 加购数 / 点击数 # 离线 NDCG 评估 ground_truth load_human_labeled_queries() # 人工标注的相关性 for query, expected in ground_truth: result search(query) ndcg compute_ndcg(result, expected) log_metric(fndcg_{query}, ndcg) # A/B 测试 # 对照组纯 BM25 # 实验组BM25 语义搜索 # 指标CTR、加购率、转化率、零结果率五、总结电商搜索从关键词匹配进阶到语义理解核心不是替代倒排索引而是补充语义检索能力。全链路分为离线阶段批量生成商品 Embedding 并建立向量索引在线阶段并行检索 融合排序高频查询预计算缓存降低延迟。关键权衡向量维度从 1536 降到 512 损失 2% 召回率但内存减半检索层数从单层到两层增加 20ms 延迟但召回率提升 15%。用 A/B 测试和 NDCG 评估持续验证搜索质量。