RAG 语义补全与推荐系统

搜索返回空结果，并不一定代表平台没有相关商品。用户可能输入了生僻词、错别字、非标准表达，或者搜索了尚未积累行为数据的新概念。传统关键词规则无法建立这些表达与商品之间的联系，于是形成 zero-hit 查询，也就是“有潜在答案，却没有可展示结果”。

这个预研项目为传统搜索增加一层语义兜底：先利用商品文本知识索引理解查询并扩展候选词，再为合适的场景提供推荐内容。系统并不取代原搜索链路，而是在原链路无法给出有效结果时补充能力。

职责与关键工作

我独立完成预研阶段的方案设计、开发和部署，主要工作包括：

• 将商品标题、类目、属性、营销文案和评论等文本整理为可检索的知识索引；
• 使用向量表示寻找语义相近的商品与表达，补充关键词规则无法覆盖的候选；
• 设计分级响应策略，根据置信度决定直接使用语义候选、返回保守建议，还是保持原有结果；
• 使用 Redis 缓存高频补全结果，降低重复计算与外部模型调用；
• 通过异步任务生成和更新推荐文案，使 LLM 不直接阻塞用户的主搜索请求；
• 将阈值、策略和回退条件配置化，便于小范围验证和快速停用。

为什么把 LLM 放在主链路之外

直接让大模型实时决定每一次搜索结果，会引入不可预测的延迟、成本和内容风险。这个项目把实时查询与内容生成拆开：在线请求优先使用已经构建的语义索引和缓存结果，LLM 负责在后台生成可复用的推荐文案，再经过策略控制进入线上响应。

这种分层设计保证了主搜索仍然可以独立运行。模型服务变慢或不可用时，系统可以回退到语义候选或传统搜索，不会把生成式能力的故障扩大为整个搜索入口的故障。

如何判断补全是否可信

系统不会因为“语义相近”就直接替用户改写查询。补全策略需要同时考虑相似度、候选商品数量、类目一致性和历史反馈。置信度不足时，系统可以展示建议而不替换原查询；完全无法确认时，则保持原行为。

线上观察重点包括补全响应时间、zero-hit 查询召回率、推荐点击反馈、错误扩展比例和缓存命中情况。这些指标让预研结果可以被验证，而不是只展示几个成功示例。

项目结果

• 补全响应时间控制在 250ms 以下；
• zero-hit 查询召回率提升约 35%；
• 通过缓存、异步执行和策略配置，将生成式能力与主搜索链路隔离，形成可独立关闭和回退的接入方式。

该项目验证了 RAG 与 LLM 可以用于生产搜索的补充场景，但前提是把它们放入具有延迟边界、证据判断和故障隔离的工程架构中。