七层架构
一次「打开 App 或在搜索框敲字」穿过七个平面。上面四层决定小红书不像抖音，下面三层决定搜推双引擎能否共用同一套笔记工厂。
打开发现页 / 上滑
要一批笔记卡片
鉴权后进召回排序
几十条 meta
拉封面和正文图
曝光点击点赞异步上报
| 层 | 英文 | 这一跳解决什么 |
|---|---|---|
| L0 客户端 | Client | 双列发现页，本地先决定搜还是逛 |
| L1 接入与边缘 | Edge & Gateway | 图文走 CDN，查询走网关 |
| L2 社区业务 | Community Services | 笔记、关系、评论、电商与商业化 |
| L3 搜索与推荐 | Search & Recommend | 两套漏斗，共用内容理解 |
| L4 内容理解与媒体 | Media & Understanding | 把一篇笔记压成可检索的向量和标签 |
| L5 数据平面 | Data Plane | 打点进 Kafka，Flink 做归因和样本 |
| L6 存储与调度 | Storage & Scheduling | 按云和访问模式拆，而不是一个大库 |
L0 客户端
小红书的主交互不是全屏上滑一条视频，而是双列瀑布流里点进一篇笔记。客户端要同时服务「逛」（发现页预取卡片）和「搜」（输入框、建议词、结果页），并把曝光、点击、点赞、收藏、评论、分享、关注、隐藏等行为打点带走。
- 发现页先拉笔记卡片（封面、标题、作者、互动数），点进详情再拉正文、图片集或视频。
- 搜索有独立入口：查询建议、结果页、近年的「问一问」生成式答案，和发现页不是同一条 RPC。
- 图文为主、视频为辅，播放器预加载策略比抖音轻，但多图笔记的带宽和首屏仍要在端上做。
- 行为埋点覆盖 click / hide / like / fav / comment / share / follow，后续实时链路靠这些事件归因。
为何这样拆：产品同时有「随便逛」和「我要找」两种意图。端上必须把两条入口拆开，不能合成一个 Feed 接口。
L1 接入与边缘
笔记图片和视频走对象存储加 CDN；发现页和搜索 API 走网关做鉴权、限流和路由。公开资料里，小红书计算和存储分布在多家云上，接入层要能把用户就近送到对应集群。
- 封面和图片是发现页的带宽大头，边缘缓存命中直接决定首屏。
- 搜索 Query 和推荐请求都是小包低延迟，和媒体字节拆开。
- Flink Forward Asia 2021 分享提到业务数据分散在阿里云、腾讯云、华为云，对象存储对应 OSS / COS / OBS。
- 网关后面，推荐和搜索是两套在线服务，广告再作为第三条混排输入。
为何这样拆：双列卡片对图片延迟极敏感；搜索对 Query 理解的延迟极敏感。两者都经不起和媒体文件抢同一条通道。
L2 社区业务
笔记是核心对象：标题、正文、标签、地点、商品卡。外围是用户、关注、评论、私信、直播入口和交易。推荐和搜索都消费这张业务网，但不替代它。
- 笔记元数据要支持详情页、作者页、话题页和商品页的多种读取。
- 关注关系影响社交召回，但不构成发现页的骨架——发现页是模型驱动。
- 评论、收藏是强互动，爆款笔记会在短时间写放大。
- 电商与广告以笔记或搜索结果为载体插入，受相关性和频控约束。
为何这样拆：小红书卖的是「可检索的社区经验」，不是纯娱乐滑卡。业务对象必须同时对搜索和推荐可计算。
L3 搜索与推荐
没有 Query 时，发现页（Explore Feed）跑多阶段推荐，论文 Towards Large-scale Generative Ranking 写明这套系统服务数亿用户。有 Query 时，搜索走查询理解、召回、相关性、排序；QP-OneModel 已全量服务搜索结果页。笔记表征上，NoteLLM / NoteLLM-2 用大模型做 I2I 召回。
- 推荐漏斗：多路召回 → 粗排 → 精排 → 重排（多样性、打散、插广告）。
- 搜索漏斗：QP → 召回（稀疏 / 密集 / 生成式）→ 相关性 → 排序 → 结果页或「问一问」。
- I2I 内容召回用笔记自身的图文，而不是后验互动，用来缓解新笔记冷启动。
- 生成式排序（GenRank）和生成式相关性（RL + SAM）是 2025–2026 年公开的升级路径。
为何这样拆：用户有时来逛、有时来查。只做推荐会丢掉「我想找油皮美白」这种明确意图；只做搜索会丢掉打开 App 时的漫游。
L4 内容理解与媒体
NoteLLM 把一篇笔记压成特殊 token 的表征，并用生成话题/类目的任务强化压缩质量；NoteLLM-2 补上视觉，用 mICL 和 late fusion 避免模型只看字不看图。过审、封面和视频转码是入池的前置工厂。
- 图文笔记：封面、多图、OCR/文本、标签、类目都是特征。
- 视频笔记走转码和多码率，再进入同一套可分发池。
- 机审与人审挡住违规内容；未过审的笔记不应进入召回索引。
- I2I 表征既服务推荐相似笔记，也服务搜索语义召回。
为何这样拆：社区冷启动比关注流更狠：新笔记没有互动。必须先看懂图和文，才能和新笔记公平比较。
L5 数据平面
公开的推荐数据架构：前端打点进 Kafka，Flink 做实时归因和标签汇总，FeatureJoiner 把标签和笔记特征拼成训练样本；离线落 Hive，分析进 ClickHouse / Hologres。流计算平台对内叫百川（Baichuan），训练平台叫 Firefly，稀疏训练框架叫 LarC。
- 有效点击等复杂标签希望批流共用一份逻辑，避免两个定义打架。
- 实时样本更新用户/笔记画像，再反馈到在线推荐。
- 搜索侧的曝光与点击同样进入训练，和推荐可以交换信号（Volcano 分享提到搜推样本互通）。
- 作业跑在 Kubernetes 上，用 Volcano 做批流与训练调度。
为何这样拆：发现页和搜索都要追兴趣漂移。没有统一归因，CES 一类多目标只是口头公式。
L6 存储与调度
对象存储按云厂商拆（OSS/COS/OBS），既存业务数据也存 Flink checkpoint。在线特征走 KV；训练样本走 Hive；分析走 OLAP。机器学习作业经 Firefly 调度到 GPU/CPU 集群。
- 多云是既成事实：同一套 Flink 引擎要能在三家云上跑。
- SQL 化是公开方向：2021 年分享称 SQL 与 JAR 任务比约 9:1。
- 推荐、搜索、广告的大规模稀疏模型用 TensorFlow + LarC。
- 索引包括倒排（关键词）和向量（笔记 embedding / Query embedding）。
为何这样拆：搜推双引擎会把同一篇笔记写成多种索引。存储要按「点查 / 扫描 / 近邻 / 对象」分开，而不是按部门各买一套库。