搜广推到底是什么？一个Java工程师的业务入门指南

"The best way to predict the future is to invent it." —— Alan Kay

2026年，AI大模型正在重塑各行各业，但搜广推（搜索、推荐、广告）系统依然是互联网公司的核心竞争力。你每天刷抖音看到的视频、淘宝首页的商品推荐、百度搜索结果的排序，背后都是搜广推系统在运作。

作为Java后端工程师，你可能听说过搜广推这个领域，但对它的具体内容和技术栈并不清楚。这篇文章用工程师的视角，带你系统了解搜广推是什么，以及Java工程师在其中扮演什么角色。

01 搜广推的本质：都是在做"匹配"

1.1 推荐：猜你喜欢什么

打开抖音，系统自动推送你可能感兴趣的视频；打开淘宝首页，商品推荐精准得让人怀疑手机在偷听。这就是推荐系统。

核心问题： 用户没有明确需求，系统需要主动推荐内容。

技术关键：

• 用户画像： 根据历史行为、人口属性、兴趣标签构建用户特征
• 物品画像： 提取商品、视频、文章的内容特征和统计特征
• 匹配算法： 协同过滤、深度学习模型（DeepFM、DIN等）预测用户对物品的兴趣

典型场景：

• 短视频推荐（抖音、快手）
• 电商首页推荐（淘宝、京东）
• 音乐推荐（网易云音乐、QQ音乐）
• 资讯推荐（今日头条、微信看一看）

1.2 搜索：找你想要的

当你在百度搜索"Java高并发"，或在淘宝搜索"跑步鞋"，搜索引擎需要从海量数据中快速找到最相关的结果。

核心问题： 用户有明确需求（Query），系统需要精准召回并排序。

技术关键：

• 倒排索引： 快速定位包含关键词的文档
• 相关性排序： BM25、TF-IDF等算法计算文档与Query的相关性
• 语义理解： 基于BERT等模型理解用户意图，支持语义搜索

典型场景：

• 通用搜索引擎（百度、Google）
• 电商搜索（淘宝、京东站内搜索）
• 垂直搜索（知乎搜索、B站搜索）

1.3 广告：平衡用户体验和商业价值

你在刷信息流时看到的"广告"标签内容，或在搜索结果顶部看到的推广链接，这就是广告系统。

核心问题： 在不伤害用户体验的前提下，最大化平台收益。

技术关键：

• CTR预估： 预测用户点击广告的概率
• 竞价机制： 广告主出价 × 预估CTR = 广告排序分数
• 归因分析： 追踪用户从看到广告到最终转化的全链路

典型场景：

• 信息流广告（抖音、微博）
• 搜索广告（百度、Google Ads）
• 开屏广告、Banner广告

1.4 三者的关系

虽然搜索、推荐、广告看起来是三个独立的系统，但它们的底层技术高度相似：

在实际工程中，很多公司会把搜广推团队合并，因为它们共享大量基础设施：特征平台、模型训练平台、在线服务框架等。

02 从Java工程师视角看搜广推

2.1 这是一个什么样的系统？

如果你之前做传统Java后端开发（比如订单系统、支付系统），搜广推系统会给你带来完全不同的挑战：

高并发： 百万QPS起步

• 淘宝首页推荐每秒需要处理数百万次请求
• 每个请求需要在100ms内返回结果
• 需要精通Java并发编程、线程池调优、异步化改造

低延迟： 毫秒级响应

• 推荐系统的P99延迟通常要求在50ms以内
• 需要深入理解JVM性能调优、GC调优
• 缓存设计（Redis、Caffeine）至关重要

大数据： TB级用户行为数据

• 每天产生数十亿条用户行为日志
• 需要掌握Kafka、Flink、Spark等大数据技术
• 离线数据处理和实时数据处理并存

复杂业务： 算法 + 工程的结合

• 不仅要写业务代码，还要理解推荐算法
• 需要和算法工程师紧密配合
• 特征工程、模型服务化是核心工作

2.2 技术栈对比

2.3 Java工程师在搜广推中的角色

不是算法工程师，但要懂算法

• 你不需要从头训练一个深度学习模型
• 但你需要理解DeepFM、DIN等模型的原理
• 能够把算法同学训练好的模型部署到线上

不是数据工程师，但要懂数据

• 你不需要设计整个数据仓库
• 但你需要知道如何从Hive取数、如何用Flink做实时特征
• 能够为算法模型提供高质量的特征数据

核心价值：把算法落地成高性能、高可用的工程系统

• 设计召回、排序的服务架构
• 优化推荐系统的性能（QPS、延迟）
• 搭建特征平台、模型服务平台
• 保障系统稳定性（监控、降级、限流）

03 推荐系统的技术架构（以推荐为例）

推荐系统是搜广推中最复杂的一个，我们以它为例，深入了解技术架构。

3.1 四层漏斗模型

推荐系统采用"召回→粗排→精排→重排"的级联架构，像一个漏斗一样逐层筛选：

用户请求 ↓ 召回层：从百万商品中筛选出1万个候选（10ms） ↓ 粗排层：用轻量模型筛选出1000个（20ms） ↓ 精排层：用复杂模型排序出100个（50ms） ↓ 重排层：考虑多样性、业务规则，最终展示10-20个（10ms） ↓ 返回给用户 </pre>

为什么要分这么多层？

性能和效果的矛盾。如果对百万商品都用复杂的深度学习模型打分，延迟会达到几秒甚至几十秒，用户根本等不了。所以要用"粗筛选 + 精打分"的策略，在性能和效果之间找平衡。

3.2 每一层在做什么？

召回层：快速筛选候选集

从百万级商品库中快速筛选出1万个候选。这一层强调速度和覆盖面。

常用召回策略：

• 协同过滤召回： 基于"看过A的用户也看过B"的逻辑
• 向量召回： 用户向量和物品向量做ANN（近似最近邻）检索
• 热门召回： 当天/当周的热门商品
• 规则召回： 用户浏览过的类目、品牌

技术实现：
public class RecallService { public List<Item> recall(User user) { List<Item> candidates = new ArrayList<>(); // 多路召回并行执行 CompletableFuture<List<Item>> cf = cfRecall.recall(user); CompletableFuture<List<Item>> vector = vectorRecall.recall(user); CompletableFuture<List<Item>> hot = hotRecall.recall(user); // 合并结果，去重 candidates.addAll(cf.join()); candidates.addAll(vector.join()); candidates.addAll(hot.join()); return dedup(candidates); // 返回1万个候选 } } </pre>

粗排层：轻量模型快速过滤

用简单的模型（如LR、小规模GBDT）对1万个候选打分，筛选出1000个。

特点：

• 特征数量少（几十到几百维）
• 模型简单，推理速度快
• 主要过滤掉明显不相关的物品

精排层：复杂模型精准打分

这是推荐系统的核心，用深度学习模型对1000个候选进行精准打分。

常用模型：

• DeepFM： 结合FM和DNN，同时捕捉低阶和高阶特征交互
• DIN（Deep Interest Network）： 引入注意力机制，根据候选物品激活用户历史行为中的相关兴趣
• 多目标模型： 同时预测点击率、转化率、停留时长等多个指标

特点：

• 特征数量多（数千维）
• 模型复杂，但只对1000个候选打分，延迟可控
• 这一层的效果直接决定推荐质量

重排层：业务规则和多样性

精排给出的是"最可能被点击"的排序，但直接展示可能会有问题：

• 推荐结果太单一（全是同一类商品）
• 违反业务规则（比如同一商家的商品扎堆）
• 没有考虑长期价值（只推热门，冷门商品没机会）

重排层要做的事：

• 打散： 同类商品不要连续出现
• 多样性： 保证不同类目、品牌的商品都有展示机会
• 业务规则： 新品扶持、品牌合作等
• 探索与利用： 在推荐准确的商品（利用）和尝试新商品（探索）之间平衡

3.3 一个真实的推荐请求流程

让我们用代码串联整个流程：

@Service public class RecommendService { @Autowired private RecallService recallService; @Autowired private CoarseRankService coarseRankService; @Autowired private FineRankService fineRankService; @Autowired private ReRankService reRankService; public List<Item> recommend(Long userId) { // 1\. 获取用户信息 User user = userService.getUser(userId); // 2\. 召回：从百万商品中召回1万个候选 List<Item> recallItems = recallService.recall(user); // 耗时：10ms // 3\. 粗排：用轻量模型筛选出1000个 List<Item> coarseRankItems = coarseRankService.rank(user, recallItems); // 耗时：20ms // 4\. 精排：用深度模型打分排序，选出100个 List<Item> fineRankItems = fineRankService.rank(user, coarseRankItems); // 耗时：50ms // 5\. 重排：考虑多样性、业务规则，最终返回20个 List<Item> finalItems = reRankService.reRank(user, fineRankItems); // 耗时：10ms // 总耗时：约90ms return finalItems; } } </pre>

这就是一个完整的推荐请求流程。每次你刷新淘宝首页，背后都在执行这样的流程。

04 搜广推工程师的日常工作

很多人以为搜广推工程师就是"调调参数、改改算法"，实际工作内容远比这复杂。

4.1 特征工程（40%时间）

特征是推荐系统的核心。一个好的特征，效果提升可能超过换一个更复杂的模型。

用户特征：

• 人口属性：年龄、性别、地域、职业
• 行为特征：点击历史、购买历史、浏览时长
• 兴趣标签：从行为中提取的兴趣偏好

物品特征：

• 内容特征：标题、类目、品牌、价格
• 统计特征：点击率、转化率、销量
• 质量特征：评分、评论数、退货率

交叉特征：

• 用户年龄 × 商品类目
• 用户历史类目 × 候选商品类目
• 用户活跃时段 × 当前时段

工程师的工作：

• 设计新特征：和算法同学讨论哪些特征可能有效
• 特征计算：用Flink做实时特征，用Spark做离线特征
• 特征存储：把特征存到Redis、HBase，保证低延迟读取
• 特征监控：特征缺失率、特征分布是否正常

4.2 性能优化（30%时间）

推荐系统对性能要求极高，性能优化是永恒主题。

召回优化：

• 向量检索加速：用Faiss、Milvus等向量数据库
• 缓存策略：热门商品缓存、用户画像缓存
• 并行召回：多路召回策略并行执行

排序优化：

• 模型推理加速：模型量化、TensorRT加速
• 批量预测：把多个请求batch在一起预测
• 特征预计算：把不变的特征提前算好

系统优化：

• 线程池调优：合理设置线程数、队列长度
• GC调优：选择合适的GC算法，减少STW时间
• 异步化：用CompletableFuture实现异步调用

4.3 实验迭代（20%时间）

推荐系统的优化是数据驱动的，每个改动都要通过A/B测试验证。

A/B测试流程：

1. 提出假设：比如"加入用户实时行为特征能提升点击率"
2. 设计实验：对照组用旧策略，实验组用新策略
3. 分流：把用户随机分配到对照组和实验组
4. 收集数据：记录点击率、转化率等指标
5. 分析结果：实验组是否显著优于对照组
6. 决策：效果好就全量上线，效果不好就回滚

工程师的工作：

• 搭建实验平台：支持灵活的分流、指标统计
• 配合算法同学上线新模型
• 分析实验数据，定位问题

4.4 故障排查（10%时间）

推荐系统是7×24小时运行的，出问题要快速定位和修复。

常见问题：

• QPS突然下降：可能是上游服务挂了
• 延迟突然上升：可能是GC频繁、缓存失效
• 推荐效果下降：可能是特征数据异常、模型加载失败
• 推荐结果重复：可能是去重逻辑有bug

排查手段：

• 监控大盘：Grafana看QPS、延迟、错误率
• 日志分析：ELK查看错误日志
• 链路追踪：Jaeger追踪慢请求
• 特征诊断：检查特征是否正常

05 如何入门搜广推？

如果你是Java后端工程师，想转型做搜广推，需要补充哪些知识？

5.1 必备知识

已经掌握的（Java后端基础）：

• ✅ Java基础：并发、集合、IO
• ✅ Spring Boot：微服务开发
• ✅ MySQL：关系型数据库
• ✅ Redis：缓存
• ✅ 分布式系统：RPC、消息队列

需要补充的：

机器学习基础（⭐⭐⭐⭐⭐）

• 逻辑回归（LR）：最基础的CTR预估模型
• GBDT：树模型，特征工程利器
• 神经网络：理解前向传播、反向传播
• 推荐算法：协同过滤、矩阵分解、深度学习推荐模型

不需要从头训练模型，但要理解模型原理，能看懂算法同学的代码。

大数据技术（⭐⭐⭐⭐）

• Kafka：消息队列，日志采集
• Flink：实时计算，实时特征
• Spark：离线计算，特征工程
• Hive：数据仓库，取数分析
• HBase/Elasticsearch：NoSQL存储

这些是搜广推系统的基础设施，必须掌握。

向量检索（⭐⭐⭐）

• Embedding原理：把用户、物品映射到向量空间
• ANN算法：HNSW、IVF等近似最近邻算法
• 向量数据库：Faiss、Milvus

向量召回是当前主流的召回方式。

性能优化（⭐⭐⭐⭐）

• JVM调优：GC算法、内存分配
• 并发编程：线程池、异步化
• 缓存设计：多级缓存、缓存更新策略

搜广推对性能要求极高，这是核心竞争力。

5.2 学习路径

第一阶段：理解业务（1-2个月）

1. 了解推荐、搜索、广告的业务逻辑
2. 理解召回、排序、重排的架构
3. 知道特征工程是什么

推荐资源：

• 书籍：《推荐系统实践》（项亮）
• 课程：王喆《推荐系统实战》
• 博客：美团技术博客、阿里技术博客

第二阶段：动手实践（2-3个月）

1. 用Java实现一个简单的推荐系统
2. 实现协同过滤、向量召回
3. 搭建召回→排序的完整链路

推荐项目：

• 开源推荐系统：Mahout、Surprise
• 自己实现：从0到1搭建一个电影推荐系统

第三阶段：深入算法（3-6个月）

1. 学习深度学习基础
2. 理解DeepFM、DIN等推荐模型
3. 了解模型训练、部署流程

推荐资源：

• 书籍：《深度学习推荐系统》（王喆）
• 论文：DeepFM、DIN、DIEN
• 开源项目：DeepCTR、RecBole

第四阶段：关注前沿（持续）

1. 大模型在推荐系统中的应用
2. 生成式推荐（如快手OneSug）
3. 多模态推荐

推荐关注：

• 顶会论文：RecSys、KDD、WWW
• 技术博客：美团、阿里、字节的技术博客
• 社区：知乎推荐系统话题、Reddit r/MachineLearning

5.3 转型建议

从哪里开始？

• 如果你在大厂：申请内部转岗，从推荐系统的工程岗做起
• 如果你在小公司：可以尝试搭建公司的推荐系统
• 如果你在找工作：准备推荐系统的面试题，投递相关岗位

需要多久？

• 理解业务：1-2个月
• 能上手干活：3-6个月
• 成为熟手：1-2年

难点在哪？

• 算法理解：需要补充机器学习知识
• 大数据技术：Flink、Spark学习曲线陡
• 性能优化：需要深入理解JVM、并发

这些都可以通过学习克服。

06 搜广推的未来：大模型时代

2026年，大模型正在改变搜广推系统。

6.1 大模型带来的变化

召回层：从向量召回到语义召回

传统向量召回基于Embedding相似度，但Embedding是固定的，无法理解复杂语义。

大模型带来的改变：

• 用LLM理解用户意图，生成更精准的召回Query
• 多模态召回：文本、图片、视频统一表征
• 生成式召回：直接生成推荐结果，而不是从候选集中选择

排序层：从特征工程到端到端学习

传统推荐系统需要大量人工特征工程，大模型可以端到端学习特征。

快手在AAAI 2026发表的OneSug框架，将召回、粗排、精排统一在一个生成模型中，这是推荐系统架构的重大变革。

交互层：从被动推荐到对话式推荐

传统推荐是单向的：系统推荐，用户点击或跳过。

大模型支持对话式推荐：

• 用户："我想看一部轻松的喜剧电影"
• 系统："根据你的观影历史，推荐《XXX》，豆瓣评分8.5，讲述..."
• 用户："太老了，有没有最近的？"
• 系统："那推荐2025年的《YYY》..."

这种交互方式更自然，推荐更精准。

6.2 Java工程师的新机会

大模型推理优化

• 模型量化、剪枝，降低推理延迟
• 分布式推理，支持大规模并发
• 这需要深入理解模型结构和系统优化

RAG系统搭建

• 检索增强生成（RAG）是大模型落地的关键
• 需要搭建向量数据库、检索系统、生成系统
• 这和推荐系统的召回、排序高度相似

Agent系统开发

• AI Agent需要调用推荐、搜索等能力
• 需要设计Agent的决策流程、工具调用
• 这是推荐系统和大模型的结合点

6.3 不变的核心

技术在变，但搜广推的核心没变：

• 理解用户需求：无论是协同过滤还是大模型，都在理解用户想要什么
• 高性能工程：百万QPS、毫秒级延迟的要求不会变
• 数据驱动迭代：A/B测试、指标优化依然是核心方法论

大模型是工具，不是替代。搜广推工程师要学会用新工具，但工程能力依然是核心竞争力。

07 结语

搜广推是一个技术密度极高的领域，结合了算法、工程、数据、业务。作为Java工程师，你不需要成为算法专家，但要理解算法原理，能把算法落地成高性能、高可用的系统。

这篇文章只是开始。后续我会继续分享：

• 推荐系统的算法演进（从协同过滤到深度学习）
• 推荐系统的工程实践（如何实现一个推荐系统）
• Java高并发技术在搜广推中的应用
• 用Claude Code重构推荐系统

如果你对搜广推、AI、Java高并发感兴趣，欢迎关注。我会持续分享技术实践和思考。

关于作者： 某厂搜广推Java工程师，日常搬砖，偶尔思考。 这个号会持续分享搜广推技术、AI工具实践、Java高并发。 欢迎关注，一起成长。

参考资料：

• 《推荐系统实践》- 项亮
• 《深度学习推荐系统》- 王喆
• 美团技术博客、阿里技术博客
• RecSys、KDD等顶会论文