1. 站内搜索为什么需要一次“AI 重构”做过内容平台或者电商中台的人都有一个共同体会站内搜索是个“看着简单、做起来要命”的模块。早期大家用LIKE %关键词%就能糊弄过去数据量一上来查询慢、结果乱、相关性差的问题就全暴露了。后来上了 Elasticsearch倒排索引解决了性能问题但新的麻烦又来了——用户搜“适合夏天穿的透气跑鞋”倒排索引会把“夏天”“透气”“跑鞋”拆成三个词分别匹配返回一堆标题里带“夏天”的短袖、带“透气”的凉席真正想要的那双鞋反而排在第三页。这就是传统站内搜索的根本瓶颈它匹配的是词不是意图。用户脑子里想的是一个完整的语义场景而搜索引擎看到的是一堆离散的 token。通智云智能搜索要解决的核心问题就是把这个“词匹配”升级成“意图匹配”用 AI 把用户query背后的真实需求还原出来再去做召回和排序。这篇文章我会从架构设计、语义召回、排序策略、工程落地几个角度把一套 AI 驱动的站内搜索方案拆开讲清楚。适合正在做搜索中台的后端工程师、负责内容平台的产品经理以及想了解 AI 如何落地到具体业务场景的技术负责人。文中涉及的技术选型和参数配置都是基于常见工程实践给出的参考方案你可以根据自己的数据规模和业务特点做调整。先说结论AI 驱动的站内搜索不是把 Elasticsearch 换掉而是在它前面加一层“语义理解”在后面加一层“智能排序”。检索的底座还是倒排索引和向量索引的混合但用户的每一次搜索都会经过意图识别、query 改写、多路召回、语义重排这几个环节。下面逐层拆解。2. 通智云智能搜索的整体架构分层2.1 从 query 到结果的四层处理链路一套完整的 AI 站内搜索从用户敲下回车到结果渲染中间要经过四层处理。我用一个具体的例子来串用户输入“有没有适合送长辈的养生壶预算三百以内”。第一层是query 理解层。这一层要做三件事意图分类这是购物意图还是信息查询意图、实体抽取“养生壶”是品类“三百以内”是价格约束“送长辈”是场景标签、query 改写把口语化的表达转成结构化检索条件。传统搜索在这一层基本是空白的直接拿原始 query 去匹配效果自然差。第二层是多路召回层。改写后的 query 会同时走三条召回通道关键词召回走倒排索引负责精确匹配向量召回走语义索引负责模糊匹配规则召回走业务配置负责处理“预算三百以内”这种硬性过滤条件。三路结果合并去重后进入下一层。第三层是语义重排层。召回阶段追求的是“不漏”重排阶段追求的是“排得准”。这里通常用一个交叉编码器Cross-Encoder模型把 query 和每个候选文档拼在一起打分比向量召回用的双塔模型精度高很多但计算量大所以只对 Top 100 左右的候选做重排。第四层是业务规则层。重排后的结果还要经过业务干预比如把缺货商品降权、把广告位插到指定位置、把新上架内容做冷启动加权。这一层是纯工程逻辑和 AI 无关但决定了最终结果的商业合理性。注意这四层的顺序不能乱。我见过有团队把业务规则放在重排之前结果规则把语义高分的结果过滤掉了重排模型拿到的候选集质量很差整体效果反而下降。2.2 为什么是“混合检索”而不是“纯向量检索”这两年向量数据库很火很多团队一上来就想用纯向量检索替代倒排索引。我的建议是别急。纯向量检索有三个绕不过去的问题。第一是精确匹配能力弱。用户搜一个具体的商品型号“XYZ-2024A”向量模型很可能把它编码成一个泛化的“电子产品”语义反而匹配不到精确包含这个型号的文档。倒排索引在这种场景下是碾压性的优势。第二是冷启动和长尾问题。向量模型对训练数据里没见过的领域词汇表征能力很差而倒排索引只要文档里有这个词就能召回。对于垂直领域的站内搜索长尾 query 占比往往超过 40%纯向量方案在这部分会大面积失效。第三是可解释性和可调试性。倒排索引的召回结果可以明确告诉你是哪个词命中的出了问题好排查。向量召回是个黑盒分数低了你都不知道是模型问题还是数据问题。所以通智云智能搜索采用的是混合检索架构倒排索引负责精确召回和长尾兜底向量索引负责语义泛化两路结果通过加权融合通常用 RRF 倒数排名融合算法合并。实测下来混合检索的召回率比单走向量方案高出 15 到 20 个百分点比单走倒排高出 25 个百分点以上。2.3 数据流转与索引更新机制搜索系统的另一个工程难点是索引更新。内容平台每天新增和修改的文档可能上万条如果每次都全量重建索引成本高且延迟大。通智云的做法是双通道索引更新增量通道处理实时性要求高的文档比如新发布的商品、刚编辑的文章通过消息队列推送到索引服务秒级生效全量通道每天凌晨跑一次重建整个向量索引保证索引质量和一致性。这里有个容易踩的坑向量索引的重建比倒排索引慢得多。一个百万级文档的向量索引用 GPU 重建可能要几个小时。所以全量通道必须做分片并行把文档按 ID 哈希分成 N 片多台机器同时建最后合并。分片数建议按“单机 2 小时内能建完”来倒推一般 8 到 16 片比较合适。3. Query 理解层把用户的话翻译成机器能懂的条件3.1 意图分类与实体抽取的落地方式Query 理解是整个链路的第一环也是最容易被低估的一环。很多团队觉得“用户搜什么就匹配什么”天经地义但实际上用户的表达和系统的索引之间隔着一道巨大的语义鸿沟。意图分类解决的是“用户想干什么”。站内搜索的意图通常分几类导航型用户知道要什么直接搜品牌名或型号、信息型用户想了解某个话题、交易型用户有明确的购买意向、对比型用户在几个选项之间犹豫。不同意图对应的召回策略完全不同——导航型应该优先精确匹配交易型应该加权价格和库存字段对比型应该返回结构化的对比内容。实体抽取解决的是“用户提到了什么”。还是用“适合送长辈的养生壶预算三百以内”这个例子抽取结果应该是品类养生壶价格上限300场景送礼人群长辈。这些实体一部分用于构造过滤条件一部分用于 query 改写。落地方式上小团队可以用规则加词典的方式起步维护一个品类词典、品牌词典、场景词典用 AC 自动机做匹配。数据量大了之后再上 BERT 类的序列标注模型做实体识别。我的经验是规则和模型不是替代关系而是互补关系。规则负责高频、确定的实体模型负责长尾、模糊的表达两者结果合并后再做冲突消解。3.2 Query 改写同义词、纠错与口语化转换Query 改写是提升召回率最直接的手段。用户输入“笔记本电脑”索引里可能存的是“便携式计算机”用户输入“苹果手机”索引里是“iPhone”。不改写这些文档永远召不回来。改写分三个层次。同义词扩展是最基础的维护一个同义词词典把 query 里的词替换成多个等价表达分别去召回。拼写纠错处理用户打错字的情况比如“养生胡”纠正成“养生壶”常用编辑距离加拼音相似度来做。口语化转换是最难也最有价值的把“有没有那种能保温的杯子”转成“保温杯”这需要模型对口语表达有理解能力。这里分享一个实操技巧同义词词典不要人工硬编而是从用户点击日志里挖。具体做法是统计那些“搜了 A 但点击了标题含 B 的文档”的 query-doc 对如果 A 和 B 的共现频率超过阈值就把它们加进同义词候选。这个方法挖出来的同义词质量比人工编的高得多而且能持续更新。3.3 意图识别模型选型小模型够用就别上大模型很多团队一提到 AI 就想着上大模型但在 query 理解这个环节小模型往往更合适。原因有三延迟低站内搜索要求端到端 200ms 以内大模型根本来不及、成本低每天千万级 query大模型推理成本扛不住、可控性强小模型可以蒸馏、量化部署灵活。具体选型上意图分类用 TextCNN 或者 BERT-base 就够了实体抽取用 BiLSTM-CRF 或者 BERT-CRF参数量控制在 1 亿以内。如果效果不够优先考虑加数据、调特征而不是换更大的模型。大模型在这个环节的正确用法是离线数据增强用大模型生成训练数据或者对 query 做离线改写把结果存成词典供线上使用。这样既享受了大模型的能力又避开了线上推理的成本和延迟问题。4. 多路召回倒排、向量与规则如何协同4.1 倒排索引的召回策略与参数调优倒排索引是搜索的基石但在 AI 搜索架构里它的角色从“唯一召回源”变成了“精确召回源”。这意味着它的配置策略也要相应调整。传统搜索追求高召回会把分词粒度调得很细用 OR 逻辑匹配。但在混合架构下倒排索引应该偏向精确用 AND 逻辑或者短语匹配把泛化召回的任务交给向量通道。这样两路各司其职融合后的效果最好。具体参数上minimum_should_match建议设成 70% 到 80%而不是默认的 0。分词器选择上中文场景用 IK 分词器加自定义词典把品类词、品牌词、型号词都加进词典避免被切碎。比如“养生壶”如果不加词典可能被切成“养生”和“壶”召回结果就会混进一堆养生文章。还有一个容易被忽略的点字段权重。标题命中的权重应该远高于正文命中品类字段的权重应该高于描述字段。这个权重不是拍脑袋定的而是用点击日志做 LR 或者 GBDT 训练出来的。我见过有团队把标题和正文字段权重设成一样结果搜“养生壶”返回的第一条是一篇正文里提了一句养生壶的长文而不是真正的商品页。4.2 向量召回的模型选择与索引构建向量召回的核心是 embedding 模型。模型选得好不好直接决定语义匹配的上限。选型上中文场景推荐用BGE 系列或者M3E 系列的开源模型这些模型在中文语义相似度任务上表现稳定而且有不同尺寸可选base、large可以根据延迟要求灵活选择。如果业务有垂直领域特点比如医疗、法律建议在开源模型基础上做领域微调用业务数据构造正负样本对跑几个 epoch 就能有明显提升。索引构建上主流方案是Faiss或者HNSW。Faiss 适合离线批量构建HNSW 适合在线增量更新。通智云用的是 HNSW因为站内搜索的文档更新频繁需要支持实时插入。HNSW 的关键参数是M每个节点的连接数和efConstruction构建时的搜索宽度M一般设 16 到 32efConstruction设 100 到 200在召回率和构建速度之间取平衡。提示向量维度不是越高越好。768 维和 1024 维在大多数站内搜索场景下效果差异很小但索引体积和检索延迟差了一大截。建议先用 768 维跑 baseline效果不够再考虑升维。4.3 规则召回处理价格、库存、时间等硬约束规则召回听起来不“AI”但在实际系统里不可或缺。用户说“三百以内”这就是个硬约束向量模型再强也不能保证召回结果都满足这个条件。规则召回的作用就是把这些结构化条件翻译成过滤表达式在召回阶段就把不符合的文档排除掉。规则召回的实现通常有两种一种是前置过滤在倒排和向量检索之前就加上 filter 条件减少候选集规模另一种是后置过滤先召回再筛掉不符合的。前置过滤效率高但可能因为过滤太狠导致召回不足后置过滤召回全但计算浪费。我的建议是强约束用前置弱约束用后置。价格上限、库存状态这种硬条件前置评分、销量这种软条件后置。规则引擎的配置建议做成可视化的让运营同学能自己配。我见过太多团队把规则写死在代码里运营想调个价格区间都要发版效率极低。用 Drools 或者自研的规则引擎把规则配置化运营改完实时生效能省掉大量沟通成本。5. 语义重排让最相关的结果排到最前面5.1 双塔模型与交叉编码器的分工召回和重排用的是两类不同的模型理解它们的区别很关键。双塔模型也叫 bi-encoder把 query 和文档分别编码成向量然后算余弦相似度。优点是文档向量可以离线算好存起来线上只需要编码 query速度快。缺点是 query 和文档没有交互精度有上限。交叉编码器cross-encoder把 query 和文档拼成一个序列一起送进模型让模型在内部做充分的注意力交互。精度比双塔高很多但每个 query-doc 对都要跑一次推理没法预计算速度慢。所以标准做法是召回用双塔重排用交叉编码器。召回阶段从百万级文档里快速筛出几百个候选重排阶段用交叉编码器对这几百个精细打分。这样既保证了速度又保证了精度。通智云的配置是召回阶段每路取 Top 200融合后取 Top 100 进重排重排后取 Top 20 返回给用户。这个数字不是固定的要根据延迟预算调整。如果端到端要求 200ms重排模型就不能太大或者用蒸馏后的小模型。5.2 重排模型的训练数据从哪来重排模型的效果七分靠数据三分靠模型。但很多团队卡在“没有标注数据”这一步。其实站内搜索有个天然的优势点击日志就是弱标注数据。用户搜了 query点击了某个文档说明这个文档和 query 是相关的。虽然点击有噪声用户可能点错、可能被标题党骗但量大足够训练一个可用的重排模型。具体做法是构造三元组query、正样本被点击的文档、负样本同一 query 下没被点击的文档或者随机采样的文档。用 pairwise 的损失函数训练让模型学会给正样本打高分、负样本打低分。这里有个细节要注意负样本的采样策略很关键。随机采样的负样本太容易区分模型学不到东西。应该用“难负样本”也就是那些被召回但没被点击的文档这些才是模型真正需要学会区分的。我试过用难负样本训练出来的模型NDCG 比随机负样本高出 8 到 10 个点。5.3 重排延迟与效果的平衡技巧重排是整条链路里最耗时的环节。一个 BERT-base 的交叉编码器在 GPU 上处理 100 个候选大概要 50 到 80ms在 CPU 上可能要 500ms 以上。如果延迟预算紧张有几个优化方向。模型蒸馏是最有效的。用大模型比如 BERT-large当 teacher小模型比如 6 层甚至 4 层的 Transformer当 student让小模型去拟合大模型的输出分布。蒸馏后的小模型精度能保留 95% 以上但推理速度快 3 到 5 倍。候选集裁剪也很实用。不是所有召回的候选都值得重排可以用一个轻量级的打分先粗筛一遍只把最有希望的 Top 50 送进重排。粗筛可以用双塔的相似度分数或者简单的特征工程模型。批处理是工程层面的优化。把多个 query 的重排请求攒成一批一起推理能充分利用 GPU 的并行能力。当然这会增加单次请求的延迟适合对实时性要求不那么极致的场景。6. 工程落地中的性能与成本控制6.1 索引分片与查询并发的设计搜索系统的性能瓶颈通常不在单次查询的计算量而在并发量。一个日活百万的内容平台搜索 QPS 峰值可能到几千。单机扛不住必须做分布式。索引分片的策略有两种按文档分片和按查询分片。按文档分片是把文档集切成 N 份每份建一个索引查询时并行查所有分片再合并。按查询分片是把查询请求分发到多台机器每台机器都有全量索引。前者适合文档量大的场景后者适合 QPS 高的场景。通智云用的是混合分片文档按哈希分成 8 片每片部署 3 个副本查询请求通过负载均衡打到副本上。这样既解决了文档量问题又解决了并发问题。8 片是这么算出来的单机内存 64G向量索引每百万文档占 8G 左右单片控制在 500 万文档以内总文档量 4000 万所以 8 片刚好。查询并发上每个查询请求会 fan-out 到所有分片所以分片数不能太多否则网络开销和合并开销会吃掉收益。一般控制在 16 片以内比较合适。6.2 缓存策略哪些结果可以缓存哪些不能搜索结果的缓存是个技术活。缓存命中率高能大幅降低后端压力但缓存策略不当会导致结果不新鲜、个性化失效。可以缓存的有热门 query 的召回结果。比如“手机”“连衣裙”这种高频词召回结果相对稳定缓存 5 到 10 分钟没问题。向量索引的 embedding也可以缓存同一个文档的向量不需要重复计算。不能缓存的有带个性化特征的排序结果。如果排序用到了用户的历史行为那每个用户的结果都不一样缓存了也没用。带实时库存和价格的过滤结果也不能缓存否则用户看到的价格可能是过期的。我的做法是分层缓存召回层缓存热门 query 的候选集重排层不缓存业务规则层缓存过滤条件但不缓存最终结果。这样既拿到了缓存的性能收益又保证了结果的实时性和个性化。6.3 成本估算GPU 与 CPU 的配比经验AI 搜索的成本主要花在 GPU 上。embedding 模型和重排模型都需要 GPU 推理如果全用 GPU成本会很高。实际部署中不是所有环节都需要 GPU。query 理解用的小模型TextCNN、BiLSTM在 CPU 上跑就够了延迟也就几毫秒。embedding 编码如果做了批处理CPU 也能扛只是延迟高一些。真正需要 GPU 的是重排阶段的交叉编码器因为它是逐对计算的计算量大。通智云的配比是每 1000 QPS 配 2 张 GPU 卡用于重排推理embedding 和 query 理解用 CPU 集群大概 10 台 16 核的机器。这个配比不是绝对的取决于模型大小和延迟要求。如果重排模型蒸馏得足够小GPU 需求还能再降。成本优化的另一个方向是模型量化。把 FP32 的模型量化成 INT8推理速度能提升 2 到 3 倍精度损失通常在 1% 以内。这个投入产出比很高建议优先做。7. 效果评估与持续迭代7.1 离线指标与在线指标怎么配合看搜索效果评估分离线 and 在线两套指标两者缺一不可。离线指标主要看召回率和NDCG。召回率衡量的是“该召回的有没有召回来”NDCG 衡量的是“排序对不对”。这两个指标用标注数据算适合做模型迭代的快速验证。但离线指标有个问题它基于历史数据反映不了新 query 和新文档的效果。在线指标主要看点击率、转化率和无结果率。点击率反映结果的相关性转化率反映商业价值无结果率反映召回覆盖度。在线指标是最终标准但它的反馈周期长而且受很多因素干扰比如 UI 改版、促销活动。我的经验是离线指标用于快速迭代在线指标用于最终决策。每次模型更新先看离线指标有没有提升提升了再上 AB 测试看在线指标。如果离线涨了在线没涨说明离线评估集和真实分布有偏差需要重新构造评估集。7.2 Bad Case 收集与归因分析流程搜索效果的提升很大程度上靠 Bad Case 驱动。但很多团队不知道怎么系统地收集和分析 Bad Case。通智云的流程是这样的第一步自动收集。在搜索结果页加一个“结果不满意”的反馈按钮用户点了就记录下来。同时监控无结果 query 和低点击 query自动进 Bad Case 池。第二步人工归因。每周抽一批 Bad Case人工判断问题出在哪一层——是 query 理解错了还是召回没召回来还是排序排错了。第三步分类修复。query 理解问题就补词典或调模型召回问题就调召回策略排序问题就补训练数据。这个流程听起来简单但坚持做下来效果非常明显。我见过一个团队坚持做了三个月 Bad Case 归因搜索点击率提升了 30% 以上比换模型的效果还好。7.3 从规则驱动到模型驱动的渐进路径最后说说迭代路径。很多团队一上来就想做全模型驱动结果数据不够、工程能力跟不上项目烂尾。更稳妥的路径是从规则驱动起步逐步过渡到模型驱动。第一阶段用规则加词典把基础搜索跑通保证能用。第二阶段引入向量召回提升语义匹配能力。第三阶段上重排模型优化排序效果。第四阶段做 query 理解和个性化进一步提升。每个阶段都要有明确的效果指标和上线验证不要跳步。我见过有团队第一阶段还没跑稳就上大模型结果线上延迟爆炸只能回滚浪费了几个月时间。搜索是个系统工程稳扎稳打比激进创新更重要。提示每个阶段上线前一定要做灰度发布。先放 5% 的流量观察延迟、错误率、点击率没问题再逐步放量。搜索是核心功能一旦出问题影响面很大灰度是必须的安全垫。这套方案在通智云的实践中把站内搜索的点击率从 18% 提升到了 34%无结果率从 12% 降到了 3% 以下。当然每个业务的数据特点和用户习惯不同具体参数需要根据实际情况调优。核心思路是不变的用 AI 补上传统搜索缺失的语义理解能力同时保留倒排索引的精确性和工程可控性两者结合才能做出真正好用的站内搜索。