AI 搜索与智能推荐：互联网行业成熟落地项目、技术架构与产品方案

目录

一、大模型重构“理解—检索—排序—生成—反馈”链路

（一）为什么这三类项目已经进入成熟落地阶段

1. 搜索与推荐的基础设施已经高度工业化

2. 大模型补上了传统系统的三个长期短板

3. 产品竞争已经从“结果质量”扩展到“决策效率”

（二）三类产品的定位、典型功能与业务指标

二、统一参考架构：一套底座支撑搜索、推荐与导购

（一）体验与产品层

（二）编排与安全层

（三）检索与排序层

（四）模型服务层

（五）数据与工程层

（六）横向治理与评估层

三、AI 搜索产品方案：从结果列表升级为“答案 + 证据 + 探索”

（一）推荐的产品界面结构

（二）生产级技术链路

第一步：查询理解与路由

第二步：Query Fan-out 与多路召回

第三步：模型重排

第四步：证据打包与生成

（三）AI 搜索的指标体系

（四）典型成熟案例启示

四、信息流 AI 推荐方案：实时兴趣、多阶段排序与多目标优化

（一）信息流推荐的本质是零查询检索

（二）多路召回设计

（三）多阶段排序漏斗

（四）大模型在推荐系统中的合理位置

（五）推荐系统的目标函数与护栏

五、电商智能导购方案：从对话问答走向决策与交易

（一）产品流程应围绕“约束收集”而不是“自由聊天”

（二）导购的五段式能力链

（三）商品知识底座

（四）导购的排序与解释

（五）智能导购的业务指标

六、用户行为数据链路：离线稳定能力与实时兴趣必须同时存在

（一）埋点事件设计

（二）实时链路

（三）离线链路

（四）训练样本与偏差

七、离线训练与模型体系

（一）搜索模型

（二）推荐模型

（三）导购模型

（四）训练流水线要求

八、在线推理架构：效果、延迟、吞吐和成本的联合优化

（一）端到端延迟预算

（二）模型分层与路由

（三）批处理和服务框架

（四）缓存与预计算

（五）降级与熔断

九、AB 实验平台：把离线提升转成可信业务结论

（一）实验平台的基本组成

（二）随机化与互斥

（三）指标体系

（四）AI 功能的特殊实验问题

十、质量评估体系：离线、在线与人工评测三线并行

（一）离线数据集

（二）自动评测

（三）人工评测

（四）在线行为与问卷

十一、风险治理与组织团队配置实施

（一）风险、治理与常见失败模式

1. 幻觉与错误引用

2. 时效与数据一致性

3. 过滤泡泡与内容同质化

4. 隐私与敏感画像

5. 反馈回路和模型污染

6. 成本失控

（二）组织与团队配置

（三）12 个月实施路线图

阶段一：0—3 个月，验证价值

阶段二：3—6 个月，打通数据与实验闭环

阶段三：6—12 个月，规模化与智能体

十二、方案选型建议：自研、平台化与模型采购如何组合

（一）选型考量

1. 建议自研的部分

2. 可采用成熟组件的部分

3. 模型策略

（二）最终落地检查清单

产品

数据

算法

工程

实验与治理

十三、结语

参考资料

干货分享，感谢您的阅读！

我们本次的目标是面向互联网产品负责人、技术负责人、算法团队与数据平台团队，给出一套可以直接用于方案评审、立项和架构设计的完整说明。重点覆盖 AI 搜索、信息流 AI 推荐、电商智能导购三类成熟场景，并把产品形态、数据链路、模型架构、在线推理、AB 实验和实施路线统一到一套参考框架中。

一、大模型重构“理解—检索—排序—生成—反馈”链路

互联网行业的搜索与推荐已经经历了规则、统计学习、深度学习和大模型四个阶段。成熟方案的共同点并不是“接入一个大模型”，而是保留传统检索与推荐系统在准确性、实时性、可解释性和成本上的优势，再让大模型承担更擅长的工作：理解复杂意图、拆解问题、重排候选、总结证据、解释推荐理由，以及在多轮会话中持续收集约束。

因此，AI 搜索、信息流推荐和智能导购可以被视为同一套基础设施在不同交互形态下的三种产品化表达：

• AI 搜索解决“用户明确提出问题后，如何找到可信证据并快速形成答案”。

• 信息流推荐解决“用户没有明确输入时，如何从海量内容中持续预测下一条最有价值的内容”。

• 智能导购解决“用户需求模糊、约束复杂且需要做选择时，如何完成澄清、比较、推荐和交易动作”。

真正可规模化的系统通常具备五个特征：多阶段检索与排序、离线训练和实时特征并存、生成结果有证据和降级机制、端到端成本与延迟可控、所有变化通过可信 AB 实验验证。

（一）为什么这三类项目已经进入成熟落地阶段

1. 搜索与推荐的基础设施已经高度工业化

传统搜索已经形成倒排索引、BM25、查询改写、实体识别、学习排序等成熟组件；推荐系统也形成多路召回、粗排、精排、重排和反馈学习的稳定范式。Google 公开的搜索排名系统说明中，BERT、神经匹配、RankBrain、段落理解和多种质量信号共同参与结果排序，说明大规模搜索从来不是单模型问题，而是多系统组合问题。[1]

YouTube 早期公开的工业推荐论文将系统拆为候选生成和排序两阶段；Instagram Explore 的工程实践进一步细化为召回、一级排序、二级排序和最终重排，并通过缓存与预计算让重模型可以进入更多排序阶段。[3][4] 这些实践构成了今天绝大多数内容平台和电商平台的推荐骨架。

2. 大模型补上了传统系统的三个长期短板

• 第一，传统系统对复杂自然语言意图的表达能力有限。例如“适合每天地铁通勤、戴眼镜不夹头、预算 1500 元、最好能连两台设备的耳机”，很难被一个关键词查询完整表达。大模型可以把需求拆成预算、场景、佩戴、连接和性能等约束，再生成多条子查询。
• 第二，传统结果页擅长“列出候选”，但不擅长“帮助用户理解”。大模型可以基于检索证据做摘要、对比、解释和下一步建议，降低用户在多个页面之间来回切换的成本。
• 第三，传统推荐很难自然地解释“为什么推荐给你”。大模型可以把用户画像、商品事实和内容特征转成自然语言理由，但必须避免暴露敏感画像或生成未经证据支持的结论。

3. 产品竞争已经从“结果质量”扩展到“决策效率”

Google 在 AI Mode 中公开介绍了 Query Fan-out 技术：系统会针对复杂问题并行发起多条相关检索，再把不同子主题和数据源汇总为易理解的回答。[2] Amazon Rufus 则把购物场景中的商品目录、评论、社区问答和外部信息纳入专用大模型与 RAG 系统，使产品从“搜索商品”升级为“协助做购买决策”。Amazon Science 公开说明，Rufus 使用了购物领域定制大模型、多源 RAG、强化学习、高性能推理和流式输出架构。[7]

这意味着成熟 AI 产品的核心价值不再只是提高一个排序指标，而是缩短从“产生需求”到“完成决策或交易”的路径。

（二）三类产品的定位、典型功能与业务指标

产品边界建议

AI 搜索不应被设计成一个“万能聊天框”。当用户只查订单号、商品编码、航班状态或精确事实时，传统检索和结构化查询更快、更准；当用户问题需要多源信息、比较、总结和推理时，才应进入生成式流程。

信息流推荐也不应把所有排序都交给大模型。大模型适合内容理解、冷启动标签生成、语义召回和解释生成，但主链路仍需要高吞吐的推荐模型承担数十万甚至数百万 QPS 的打分任务。

智能导购的目标不是“聊得久”，而是“更少轮次地识别关键约束并促成正确决策”。因此，对话轮数不能单独作为正向指标；过多追问可能意味着系统没有有效利用已有行为和商品数据。

二、统一参考架构：一套底座支撑搜索、推荐与导购

从工程视角看，三类产品可以共用六层能力。

（一）体验与产品层

这一层承载搜索结果页、信息流、商品详情页、导购对话框、运营后台和实验配置台。关键不是界面形式，而是把模型能力嵌入用户任务：搜索页需要答案与证据并存，信息流需要无感实时更新，导购需要边聊边展示可操作的商品卡片。

（二）编排与安全层

负责意图分类、查询改写、复杂问题拆解、模型路由、Prompt 模板、工具调用、会话状态和安全策略。生产系统通常不会把所有请求发送给同一个模型，而会根据任务复杂度、时效性和风险等级选择规则、小模型、检索增强模型或大模型。

（三）检索与排序层

包括关键词检索、向量检索、图检索、协同过滤召回、双塔召回、粗排、精排和最终重排。Azure AI Search 的官方文档将混合搜索定义为在同一请求中并行执行全文与向量查询，再使用 RRF 融合结果；这种架构可以兼顾关键词精确匹配和语义召回。[8]

（四）模型服务层

承载 Embedding、推荐模型、Cross-Encoder Reranker、LLM、多模态模型和内容安全模型。模型服务需要统一版本管理、灰度发布、资源隔离、批处理、超时和回滚能力。

（五）数据与工程层

包含埋点、事件流、湖仓、特征平台、训练样本、模型流水线、在线特征库、缓存和可观测系统。Kafka 最初的重要用途之一就是把网页浏览、搜索等用户活动发布到实时主题，供实时计算、监控和离线仓库消费；这与搜索和推荐的数据链路天然匹配。[9]

（六）横向治理与评估层

包括 AB 实验、离线评测、内容安全、隐私合规、成本治理和模型可观测。成熟 AI 项目必须能回答三个问题：效果是否真实提升、风险是否可控、单位业务收益对应的推理成本是否合理。

三、AI 搜索产品方案：从结果列表升级为“答案 + 证据 + 探索”

（一）推荐的产品界面结构

一个成熟的 AI 搜索结果页通常包含四个区域：

对于电商搜索，还应把价格、库存、规格和配送等结构化字段置于大模型生成之前。大模型可以总结“更适合通勤”，但价格和库存必须来自实时系统，不应依赖模型记忆。

（二）生产级技术链路

第一步：查询理解与路由

系统先判断查询类型：导航型、精确事实型、开放研究型、比较型、交易型或高风险型。简单查询走传统检索；复杂查询进入生成式搜索；医疗、金融和法律等高风险问题需要更严格的来源白名单和答案模板。

查询理解层还要完成实体识别、拼写纠错、同义词扩展、时间和地域约束提取。对多轮会话，需要把省略的上下文改写成独立查询，例如把“那续航呢？”改写为“对比上一轮两款耳机的官方续航和实测续航”。

第二步：Query Fan-out 与多路召回

复杂问题拆成多个子主题后并行检索。例如“适合暑假带孩子去的海岛，飞行不超过 5 小时，预算 2 万”可以拆成目的地、飞行时长、季节气候、亲子设施、签证和预算六类查询。

召回层建议至少保留两路：

• 稀疏检索：BM25 或倒排索引，适合型号、专有名词、数字、代码、日期和精确短语。

• 稠密检索：向量检索，适合语义近似、长问题和表达不一致的内容。

可进一步增加知识图谱、数据库查询、实时搜索和用户历史召回。多路结果使用 RRF、学习融合或业务规则合并，并进行权限、地域、时效、库存和内容安全过滤。

第三步：模型重排

召回目标是“不漏掉”，重排目标是“把最有用的证据放到前面”。Cross-Encoder 可以联合编码查询和候选文本，通常比单独向量相似度更准确，但成本更高，因此只对几十到几百个候选使用。

重排特征可以包括：语义相关性、内容质量、时效性、来源权威性、用户偏好、页面可用性、商品库存、商业规则和去重信息。搜索和推荐不应把商业目标直接覆盖相关性，而应在最终重排中以透明、可控的方式引入。

第四步：证据打包与生成

把高质量片段去重、分块、排序，并记录来源 ID、段落位置和时间戳。生成模型只接收有限的证据窗口，Prompt 明确要求“证据不足时说明不足，不得补写”。

生成后再做一次逐句核验：关键结论是否能被证据支持、引用是否指向正确片段、数字和时间是否一致。对于低置信度答案，应回退为传统搜索结果或提示用户进一步限定问题。

（三）AI 搜索的指标体系

需要注意，追问率既可能表示用户愿意继续探索，也可能表示首轮答案不完整，因此应结合任务完成率和满意度解释。

（四）典型成熟案例启示

Google 的实践说明，生成式搜索不是脱离既有搜索系统重新构建，而是把高级模型能力与实时信息系统、知识图谱、购物数据和 Web 结果结合，并通过 Query Fan-out 扩展检索深度。[2]

对于企业和垂直平台，最现实的路径不是复制通用搜索引擎，而是选择一个高价值知识域，先完成“有权限的内容接入、混合召回、重排、引用式回答、离线集和 AB 实验”六件事。

四、信息流 AI 推荐方案：实时兴趣、多阶段排序与多目标优化

（一）信息流推荐的本质是零查询检索

用户没有输入查询时，系统需要根据长期兴趣、当前 Session、时间、位置、设备、社交关系和内容上下文，构造一个隐式查询，再从海量内容中选出下一批候选。

YouTube 公开的经典架构使用候选生成模型从大规模语料中取回少量视频，再使用独立排序模型精细打分。[3] Instagram Explore 的工程实践则明确列出召回、一级排序、二级排序和最终重排四个阶段，并强调缓存、预计算和多类候选源的重要性。[4]

（二）多路召回设计

一个成熟信息流通常同时维护以下召回源：

• 长期兴趣召回：基于数周或数月行为构建用户 embedding。

• 实时 Session 召回：基于最近几分钟或几十次行为快速更新。

• 内容相似召回：根据刚看过的内容召回语义相近内容。

• 协同过滤召回：相似用户看过但当前用户没看过的内容。

• 社交或关系召回：关注的人、朋友互动或组织关系。

• 热门与趋势召回：地域、时间段或垂类的热点内容。

• 探索与冷启动召回：给新内容和新创作者保留曝光机会。

• 运营与商业召回：活动池、广告池、公共服务信息等。

不同召回源先做配额和权重控制，再进入统一排序。这样既能保证相关性，也能避免单一算法让内容越来越同质化。

（三）多阶段排序漏斗

召回阶段通常处理百万到十亿级内容池，目标是高覆盖和低延迟。粗排使用较轻模型，把数千候选缩小到数百；精排使用更复杂的多任务模型，同时预测点击、播放时长、点赞、评论、转发、关注、负反馈和长期价值；最终重排处理多样性、新鲜度、重复、内容安全、商业配额和创作者生态。

阿里巴巴的 DIN 通过针对当前候选商品动态激活用户历史兴趣，解决固定长度用户表示难以表达多样兴趣的问题；论文披露该模型使用超过 20 亿样本并部署于线上主流量。[5] 后续 DIEN 对兴趣演化过程建模，公开结果显示在淘宝展示广告系统中取得 CTR 提升。[6] 这类实践说明：用户兴趣不是一个静态向量，而是与候选、时间和行为序列相关的动态状态。

（四）大模型在推荐系统中的合理位置

大模型最适合进入以下环节：

不建议让通用大模型直接承担全量实时排序。一方面成本和延迟不可控，另一方面推荐目标需要大量隐式反馈、校准和多目标约束，专用推荐模型更适合主链路。

（五）推荐系统的目标函数与护栏

成熟系统通常不会只优化 CTR。点击可能被夸张标题和低质内容轻易提升，因此需要同时关注有效消费、长期留存、负反馈、内容生态和商业价值。

推荐的指标分层如下：

• 主指标：有效阅读/播放时长、任务完成、转化或长期留存。

• 辅助指标：点击、互动、关注、收藏、分享。

• 负向指标：快速跳出、不感兴趣、举报、隐藏、退订。

• 生态指标：内容覆盖度、作者覆盖度、新内容存活率、头部集中度。

• 工程护栏：延迟、错误率、GPU/CPU 成本、特征缺失率。

五、电商智能导购方案：从对话问答走向决策与交易

（一）产品流程应围绕“约束收集”而不是“自由聊天”

电商需求经常具有模糊性和主观性，例如“给经常出差的爸爸买一个体面的礼物”“小户型适合什么洗烘方案”。智能导购需要把自然语言转成结构化约束，包括预算、使用人、场景、规格、品牌偏好、时间、风险和可接受的取舍。

在产品交互上，系统应优先利用已有信息，只有影响候选集的关键约束缺失时才追问。每一轮对话都应让候选数量明显缩小，或者让比较维度更清晰。

（二）导购的五段式能力链

Amazon 对 Rufus 的公开说明显示，其购物助手以 Amazon 商品目录、评论和社区问答为核心数据，并结合多源 RAG、专用购物大模型、强化学习和流式推理。[7] 这类产品的关键不是模型回答了多少知识，而是商品事实是否准确、推荐是否符合当前用户的具体约束，以及最终动作是否可执行。

（三）商品知识底座

智能导购至少需要四类知识：

• 商品事实：SPU/SKU、类目、属性、规格、价格、库存、配送、售后。

• 用户证据：浏览、搜索、收藏、购买、退货、预算和会话上下文。

• 体验证据：评论、问答、客服工单、退货原因、质量反馈。

• 外部知识：使用场景、搭配关系、兼容性、季节和最新政策。

商品知识应优先结构化。对评论和问答，可以通过主题聚类和观点抽取形成“续航”“噪音”“尺码偏差”等体验维度，再由大模型进行总结。这样比直接把大量评论塞进上下文更稳定、成本更低。

Amazon Science 还公开介绍了通过常识知识图谱编码商品与功能、受众、地点等关系，以增强推荐中的场景推断。[10] 对电商平台而言，商品图谱可以连接“商品—属性—场景—人群—搭配—替代—互补”关系，是智能导购区别于通用聊天机器人的重要资产。

（四）导购的排序与解释

候选排序可以拆成三部分：

• 硬约束过滤：预算、库存、配送时间、尺寸、兼容性、禁忌条件。

• 个性化匹配：用户长期偏好、当前会话意图、历史购买和价格敏感度。

• 综合价值排序：商品质量、评价可信度、售后、退货风险、利润和商业规则。

解释生成必须绑定排序特征。例如“推荐 A 款，因为它在你的预算内、支持双设备连接、重量更轻，并且近期评论中对通勤降噪评价较高”。如果“评价较高”来自评论摘要，就应允许用户查看原始评论证据。

（五）智能导购的业务指标

重点关注：搜索到商品点击率、商品点击到加购率、导购会话转化率、客单价、退货率、价格敏感用户转化、导购后搜索次数、人工客服转接率和用户满意度。

“回答轮数”“平均会话时长”只能作为诊断指标，不能直接视为成功。对购物任务而言，用户更快完成正确购买通常优于长时间聊天。

六、用户行为数据链路：离线稳定能力与实时兴趣必须同时存在

（一）埋点事件设计

建议统一搜索、推荐和导购的事件模型。每条事件至少包含：用户或匿名设备 ID、会话 ID、请求 ID、实验 ID、页面与位置、候选集、曝光结果、点击/停留/购买行为、内容或商品 ID、时间戳、模型版本和策略版本。

只有记录“当时给用户展示了哪些候选，以及为什么展示”，后续才能构建无偏训练样本、定位线上问题和复现实验结果。

（二）实时链路

实时链路通常为：客户端/服务端埋点 → 消息队列 → 流式计算 → 在线特征库与实时指标。典型实时特征包括最近 N 次行为、最近 5/30/120 分钟兴趣分布、Session 主题、短期价格敏感度、内容热度、库存变化和异常风险。

实时特征强调低延迟和最新状态，但不能无限堆积。系统应明确每个特征的时间窗口、更新频率、过期策略和缺失值处理。

（三）离线链路

离线链路负责长期用户画像、内容 embedding、商品特征、训练样本、标签生成和模型评估。需要保留时间快照，避免训练时使用了预测发生之后的数据，造成数据泄漏。

特征平台的价值是让训练和在线服务使用同一套定义。Feast 等特征库把离线存储用于构建训练数据和物化特征，把在线存储用于低延迟读取最新特征，这正是解决训练—推理一致性的典型模式。[11]

（四）训练样本与偏差

搜索和推荐日志天然带有展示偏差：用户只能点击被展示的内容，未展示内容并不等于不喜欢。训练时需要记录曝光位置、旧模型分数和流量来源，必要时使用负采样校正、逆倾向加权或探索流量降低偏差。

对于导购对话，还要把“用户修改约束”“接受推荐”“加入购物车”“退货”纳入长期反馈。最终成交不是唯一标签；推荐后高退货或高投诉说明系统只优化了短期转化。

七、离线训练与模型体系

（一）搜索模型

• Query 分类与意图识别模型。

• 拼写纠错、同义词、实体识别和查询改写模型。

• Embedding 双塔或对比学习模型。

• Cross-Encoder 重排模型。

• 答案生成、引用核验和安全模型。

（二）推荐模型

• 双塔召回、协同过滤、图模型和序列召回。

• Wide & Deep、DeepFM、DIN/DIEN、Transformer 序列模型。

• 多任务学习模型，同时预测点击、时长、互动和负反馈。

• 校准模型，把分数转成可比较概率。

• 多样性和长期价值重排模型。

（三）导购模型

• 意图与槽位抽取模型。

• 商品和评论多模态 Embedding。

• 商品匹配与排序模型。

• 对比解释和对话生成模型。

• Agent 规划与工具调用模型。

（四）训练流水线要求

成熟训练平台需要支持数据版本、特征版本、代码版本、模型版本、可复现环境、自动评测、模型注册、灰度发布和回滚。训练任务完成不等于可以上线；只有离线指标、业务规则、安全评测和推理性能同时通过门槛，模型才能进入线上实验。

八、在线推理架构：效果、延迟、吞吐和成本的联合优化

（一）端到端延迟预算

用户感知的是整个请求，而不是单个模型耗时。AI 搜索链路可能包含网关、鉴权、特征读取、多路召回、重排、LLM 首 Token、流式输出和后处理。应把端到端 P95 预算分配给每个环节，并为超时设置明确回退。

信息流推荐一般要求更低延迟，因此需要大量预计算、缓存和轻模型；导购对话允许稍高延迟，但首 Token 必须尽快返回，后续内容可以流式生成。

（二）模型分层与路由

推荐的模型路由策略：

• 精确事实与结构化查询：不调用大模型。

• 短文本理解：小语言模型或分类模型。

• 召回：双塔、ANN、图索引。

• 精排：专用 DNN 或 Cross-Encoder。

• 复杂总结与比较：大模型。

• 高风险场景：白名单模型、模板答案或人工审核。

（三）批处理和服务框架

GPU 推理需要提高批量利用率。NVIDIA Triton 的架构通过模型仓库、每模型调度器和可配置批处理把请求路由到不同后端，并提供健康检查、吞吐和延迟指标；动态批处理可以把多个请求组合成批次，提高吞吐。[12]

推荐系统的精排和重排天然适合批量打分；生成模型则要平衡首 Token 延迟和吞吐。可以按请求长度、模型和优先级分队列，避免长请求阻塞短请求。

（四）缓存与预计算

可缓存的内容包括：热门查询结果、标准问题答案、文档 embedding、用户长期 embedding、商品特征、候选池和模型中间结果。缓存必须带数据版本和过期时间，涉及价格、库存、新闻和政策的内容不能长期缓存。

（五）降级与熔断

生产系统至少需要四级降级：大模型超时回退小模型、小模型超时回退模板、生成式答案失败回退传统结果、核心检索失败返回可解释错误。所有生成式功能都应有实验开关和快速止损能力。

九、AB 实验平台：把离线提升转成可信业务结论

（一）实验平台的基本组成

Microsoft 对大规模实验平台 ExP 的公开总结包含实验门户、实验执行服务、日志处理服务和分析服务四个核心组件，并强调可信和可扩展是平台设计的两大原则。[13] 对 AI 搜索和推荐而言，实验系统还需要记录模型版本、Prompt 版本、索引版本和特征版本。

（二）随机化与互斥

实验必须明确随机化单位：用户、设备、会话、请求或地域。长期推荐实验通常按用户分流，避免同一用户在不同策略之间跳动；搜索 UI 的短期实验可以按请求，但要防止学习效应和跨请求污染。

多个实验同时运行时，需要互斥层或正交层，避免两个高影响实验互相干扰。搜索、推荐、广告和支付等核心域最好分别管理实验层。

（三）指标体系

每个实验应提前定义：

• 主指标：直接代表业务目标，只保留一到两个。

• 诊断指标：解释主指标为什么变化。

• 护栏指标：延迟、错误、投诉、内容安全、成本、生态。

• 长期指标：留存、复购、退货、创作者供给等。

不要只看 CTR。更高点击可能来自更激进的标题、更靠前的商业内容或更重复的候选，未必提升满意度。

（四）AI 功能的特殊实验问题

生成模型输出具有随机性，同一请求可能得到不同回答。实验中应固定或记录采样参数，保留原始输出和证据，便于复现。对于低频但高风险错误，平均指标不敏感，需要增加人工抽检、红队集和异常告警。

大模型版本更新、索引更新和 Prompt 更新不应混在一次实验中，否则无法判断提升来源。建议采用组件化实验和分阶段灰度。

十、质量评估体系：离线、在线与人工评测三线并行

（一）离线数据集

建立真实查询和真实场景数据集，覆盖头部、高频、长尾、模糊、时效、对比、多轮和高风险问题。每条样本应包含标准证据、可接受答案要点、禁止输出和业务约束。

推荐系统需要时间切分的训练、验证和测试集，避免未来行为泄漏。导购评测应覆盖不同预算、人群和品类，尤其关注错误过滤、虚构参数和不合适推荐。

（二）自动评测

自动评测可以覆盖召回、排序、事实一致性、引用准确率、格式和安全规则。LLM-as-a-Judge 可用于大规模初筛，但不能作为唯一评判，需用人工标注校准偏差。

（三）人工评测

人工评测建议采用多维量表：相关性、完整性、事实性、可读性、证据质量、推荐合理性、风险和整体满意度。高风险场景由领域专家评审。

（四）在线行为与问卷

在线行为反映真实选择，问卷反映主观感受，两者需要结合。用户可能点击一个答案但并不满意，也可能不点击来源却已从摘要中解决问题。

十一、风险治理与组织团队配置实施

（一）风险、治理与常见失败模式

1. 幻觉与错误引用

问题通常不只来自生成模型，也可能来自召回错误、旧数据、分块错误和引用映射错误。治理应按链路定位：查询是否理解正确、证据是否完整、重排是否把低质来源提前、答案是否超出证据。

2. 时效与数据一致性

价格、库存、政策、新闻和活动信息必须来自实时系统，并显示更新时间。生成文本不能覆盖结构化系统的事实字段。

3. 过滤泡泡与内容同质化

推荐系统过度优化短期点击会缩窄用户视野。需要保留探索流量、多样性约束、作者覆盖和主题覆盖，并监控长期集中度。

4. 隐私与敏感画像

用户画像遵循最小化原则，敏感属性不得用于不当差别待遇。推荐解释不能直接暴露“因为你收入较低”“因为你可能患有某种疾病”等推断。

5. 反馈回路和模型污染

如果 AI 生成内容再次进入索引和训练数据，可能导致内容同质化和错误放大。需要标识生成内容、控制训练数据来源并建立质量门槛。

6. 成本失控

常见原因包括所有请求都调用最大模型、上下文过长、重复检索、没有缓存、生成字数无限制和缺少按场景成本核算。成本治理要落到“每千次请求成本、每次成功任务成本、每单位业务提升成本”。

（二）组织与团队配置

一个完整项目通常需要以下角色协同：

• 产品负责人：定义用户任务、业务指标、产品边界和实验计划。

• 搜索/推荐算法：召回、排序、特征、训练和离线评估。

• 大模型算法：Query 改写、RAG、生成、评测和安全。

• 数据工程：埋点、实时流、湖仓、特征平台和数据质量。

• 后端与平台工程：索引、模型服务、缓存、路由、灰度和可观测。

• 前端/客户端：流式交互、结果卡片、证据展示和反馈入口。

• 运营与领域专家：数据标注、规则、内容池、风险审核和知识维护。

• 实验与数据分析：指标口径、AB 分析、异常诊断和决策沉淀。

团队不宜按“传统搜索”和“大模型”完全割裂。最佳组织方式是围绕完整用户任务建立跨职能小组，同时由平台团队提供检索、特征、推理、实验和治理的公共能力。

（三）12 个月实施路线图

阶段一：0—3 个月，验证价值

选择一个高频、数据可得、风险可控的场景。AI 搜索可从内部知识或一个垂直品类开始；推荐可从某个频道或新用户场景开始；导购可从参数清晰、退货风险可控的品类开始。

交付物包括：产品原型、基线检索/推荐、RAG 或解释模块、1000—5000 条离线评测集、基础埋点、模型路由、缓存、错误降级和小流量 AB。

阶段目标不是追求全场景覆盖，而是证明用户任务完成率和业务指标存在可重复提升。

阶段二：3—6 个月，打通数据与实验闭环

建设混合召回、模型重排、实时事件流、在线特征、训练流水线、推理服务、监控和实验平台。统一用户、内容、商品和实验标识，保证训练、推理和分析口径一致。

这一阶段开始沉淀共享平台能力，让搜索、推荐和导购不再各自维护一套埋点、模型服务和评估逻辑。

阶段三：6—12 个月，规模化与智能体

扩展到多品类、多内容形态和多入口。引入多模态理解、长期会话记忆、个性化生成、复杂任务规划和工具调用。导购可以执行加购、降价提醒、补货订阅和售后查询，但所有高风险动作需二次确认和权限控制。

同时建立成本预算、红队评测、模型升级 SOP、事故响应和数据治理制度，使 AI 能力成为长期基础设施，而不是一次性功能。

十二、方案选型建议：自研、平台化与模型采购如何组合

（一）选型考量

1. 建议自研的部分

用户行为数据、业务特征、排序目标、商品/内容知识、实验指标和产品交互属于核心竞争力，应由内部团队掌握。搜索和推荐效果高度依赖业务数据，仅采购通用模型很难形成长期壁垒。

2. 可采用成熟组件的部分

消息队列、向量数据库、特征库、模型服务、训练编排、监控和基础大模型可以采用开源或云服务。关键是通过标准接口和数据治理减少绑定风险。

3. 模型策略

可采用“大模型 API + 自部署小模型 + 专用排序模型”的组合：大模型负责复杂生成，小模型负责高频理解和分类，专用模型负责召回与排序。随着调用规模增长，再评估蒸馏、量化和自部署的收益。

（二）最终落地检查清单

产品

• 是否定义了明确用户任务，而不是泛化聊天入口？

• 是否保留传统结果和证据入口？

• 是否有低置信度、无结果和错误状态的交互？

• 是否把关键结构化事实置于生成之前？

数据

• 是否能记录候选集、曝光、模型版本和实验版本？

• 训练和在线特征是否同源？

• 是否有数据时间快照、血缘和回放能力？

• 是否最小化采集和使用敏感数据？

算法

• 是否建立召回、排序、生成分层指标？

• 是否有长尾、时效、高风险和对抗样本？

• 是否监控偏差、重复、过滤泡泡和冷启动？

• 是否能对模型和 Prompt 单独灰度？

工程

• 是否有端到端 P95 延迟预算？

• 是否有缓存、批处理、超时、熔断和降级？

• 是否能快速回滚模型、索引和策略？

• 是否按场景核算单位成功任务成本？

实验与治理

• 是否提前定义主指标、诊断指标和护栏？

• 是否保证随机化、互斥和指标口径可信？

• 是否保留输出、证据和配置以便复现？

• 是否有人工抽检、红队和事故响应机制？

十三、结语

AI 搜索、信息流推荐和智能导购代表了互联网产品从“提供候选”向“帮助用户完成决策”的升级。但决定项目成败的并不是模型参数量，而是能否把传统检索、专用推荐模型、实时数据、大模型生成和 AB 实验组合成稳定闭环。

最值得优先建设的不是一个孤立的 AI 功能，而是可复用的五项基础能力：统一行为数据、混合检索与多阶段排序、可路由的模型服务、可信实验平台、贯穿全链路的质量与成本治理。具备这些能力后，搜索可以自然升级为答案与探索，推荐可以从静态画像升级为实时意图，导购可以从问答升级为可执行的购物智能体。

参考资料

[1] Google Search Central, A Guide to Google Search Ranking Systems. https://developers.google.com/search/docs/appearance/ranking-systems-guide

[2] Google, Expanding AI Overviews and introducing AI Mode. Expanding AI Overviews and introducing AI Mode

[3] Google Research, Deep Neural Networks for YouTube Recommendations. https://research.google/pubs/deep-neural-networks-for-youtube-recommendations/

[4] Meta Engineering, Scaling the Instagram Explore recommendations system. Scaling the Instagram Explore recommendations system – Engineering at Meta

[5] Zhou et al., Deep Interest Network for Click-Through Rate Prediction. [1706.06978] Deep Interest Network for Click-Through Rate Prediction

[6] Zhou et al., Deep Interest Evolution Network for Click-Through Rate Prediction. [1809.03672] Deep Interest Evolution Network for Click-Through Rate Prediction

[7] Amazon Science, The technology behind Amazon’s GenAI-powered shopping assistant, Rufus. The technology behind Amazon’s GenAI-powered shopping assistant, Rufus – Amazon Science

[8] Microsoft Learn, Hybrid Search Overview – Azure AI Search. Hybrid Search Overview – Azure AI Search | Microsoft Learn

[9] Apache Kafka, Uses: Website Activity Tracking and Stream Processing. Uses | Apache Kafka

[10] Amazon Science, Building commonsense knowledge graphs to aid product recommendation. Building commonsense knowledge graphs to aid product recommendation – Amazon Science

[11] Feast Documentation, Offline Store / Online Store. Offline store | Feast: the Open Source Feature Store

[12] NVIDIA Documentation, Triton Inference Server Architecture. Triton Architecture — NVIDIA Triton Inference Server

[13] Microsoft Research, The Anatomy of a Large-Scale Experimentation Platform. The Anatomy of a Large-Scale Experimentation Platform – Microsoft Research