信息来源通过 RSS 等信息抓取手段
用 chat 模型理解用户的行为画像
用 Embedding 模型对文章进行嵌入和检索
用 ranker 模型对文章在其所在分类质量进行打分
思路是这样,rss 抓来的内容=>用 chat 模型进行分类、标签和总结=> ranker 模型对该文章在其所在分类的内容质量进行评级=> 评级高的进行 Embedding 嵌入
后面根据用户的互动行为用 chat 模型进行建用户画像 根据用户画像通过 U2I 去检索文章混合 TF-IDF 关键字匹配兜底,对内容进行推荐分发
为了方便理解,我让 ai 根据刚才的描述画了一个文字版架构流程图
内容处理
┌──────────────┐
│ RSS / 抓取 │
│ (Feed / Web) │
└──────┬───────┘
│ 原始文章
▼
┌────────────────────┐
│ 内容预处理 Pipeline │
│ - 去噪 / 去重 │
│ - 正文抽取 │
│ - 语言检测 │
└──────┬─────────────┘
│ 清洗后文本
▼
┌───────────────────────────────┐
│ Chat Model (内容理解) │
│ - 分类( Category ) │
│ - 标签( Tags ) │
│ - 摘要( Summary ) │
│ - 关键词 / 主题(可选) │
└──────┬────────────────────────┘
│ 结构化内容
▼
┌─────────────────────────────────────┐
│ Ranker Model (分类内质量评估) │
│ - 输入:文章 + 分类 + 标签 │
│ - 输出:质量分数 / 等级( A/B/C/D ) │
└──────┬──────────────────────────────┘
│
├───────────────┐
│ 高质量内容 │ 低质量内容
│ (>= 阈值) │ (< 阈值)
▼ ▼
┌──────────────────┐ ┌────────────────────┐
│ Embedding Pipeline│ │ 冷存 / 低频曝光 │
│ - 向量化 │ │ - 搜索兜底 │
│ - 向量索引 │ │ - 长尾内容池 │
└─────────┬────────┘ └────────────────────┘
│
▼
┌──────────────────────┐
│ 向量库 / 检索索引 │
│ (ANN / pgvector 等) │
└──────────────────────┘
用户侧画像与推荐流程
┌──────────────┐
│ 用户行为采集 │
│ - 点击 │
│ - 阅读时长 │
│ - 收藏 / 分享│
│ - 跳过 │
└──────┬───────┘
│ 行为序列
▼
┌──────────────────────────────┐
│ Chat Model (用户画像理解) │
│ - 兴趣主题 │
│ - 偏好分类 │
│ - 阅读深度 / 新鲜度偏好 │
│ - 显式 + 隐式偏好 │
└──────┬───────────────────────┘
│ 用户画像(结构化)
▼
┌─────────────────────────────────────┐
│ User → Item 召回( Recall ) │
│ │
│ ① 向量召回( U2I Embedding ) │
│ - 用户画像向量 │
│ - 文章向量 │
│ │
│ ② 关键词召回(兜底) │
│ - TF-IDF / BM25 │
│ - 用户兴趣关键词 │
└──────┬──────────────────────────────┘
│ 候选文章集合
▼
┌──────────────────────────────┐
│ 排序 / 混排(可扩展) │
│ - 质量分( Ranker ) │
│ - 相似度分 │
│ - 新鲜度 / 多样性 │
└──────┬───────────────────────┘
▼
┌──────────────┐
│ 内容分发展示 │
└──────────────┘
花了两个月的时间改进与验证,结论是本地自建推荐系统已经在技术上具备可行性了
感兴趣的可以自行验证,或在这个https://github.com/weekend-project-space/ifeed 的基础上进行验证
内容分法这块除了信息流的用户主动获取(pull)之外,还有一个系统主动推(push)的机制可以当xx出现时,通过webhook的钩子进行主动通知,这个钩子就可以有很多种了,可以是聊天软件或邮箱,或其它
[内容分发webhook钩子]
- 是否命中条件 xx?
· 分类命中
· 质量阈值
· 关键词 / 实体
· 用户订阅规则
│
┌─────┴────────────────────┐
│ │
▼ ▼
[普通内容流] [事件内容流]
│ │
│ ▼
│ [Webhook 事件生成]
│ │
│ ▼
│ [Webhook 分发器]
│ │
│ (是否需要 LLM 概要?)
│ │
│ ┌───────────┴───────────┐
│ │ │
│ ▼ ▼
│ [直接分发] [LLM 概要增强流程]
│ │ │
│ │ - 精炼概要总结
│ │ - 关键信息提取
│ │ - 引用原文 URL
│ │ │
│ └───────────┬───────────┘
│ ▼
│ [通知内容构建]
│ │
│ ┌─────────┼─────────┐
│ ▼ ▼ ▼
│ [聊天通知] [邮件通知] [其它系统]
│ IM / Bot Email 搜索 / BI
│
▼
[内容存储 / Embedding]
- 向量化
- 推荐 / 搜索
1
summerLast OP 假设是:时间有限,内容很多,但大多数内容质量很低,不值的花时间阅读,用 ai 去过滤掉这部分信息
|
2
nevin47 2 天前
完全可行,我自己之前就 vibe 了一个,通过 RSS 订阅和 Google 最新信息抓取,定时给我推送我感兴趣的内容。
|
4
Hydsiun 2 天前
很棒的 idea 啊
|
5
Muniesa 2 天前
不错不错,而且感觉这个流程里的模型都不需要特别大,本地部署也没问题
|
6
yuanyuan11 2 天前 via Android
rss 抓不了全文怎么办?
|
7
ronyin 2 天前
直接 rss 订阅不就完事了。。每天都都是看自己订阅的内容
|
8
marquina 2 天前
我对推荐算法了解不多,但看到的观点更多是:基于 LLM 的生成式推荐在顶尖团队手里确实能发挥很大价值,但也有不少局限。中小公司因为数据/技术能力有限,最好不要轻易尝试。
[生成式推荐!推荐系统新范式还是新噱头? - 知乎]( https://zhuanlan.zhihu.com/p/1931701983313630556) [[笔记] 从 Tokenization 视角看生成式推荐( GR )近几年的发展( 2025 )]( https://arthurchiao.art/blog/large-generative-recommendation-tokenization-perspective-notes-zh/) 回到 OP 这个帖子,给我一种强烈的大炮打蚊子的感觉…… |
9
marquina 2 天前
另外,llm 打分+向量数据库的方案疑似有点太简陋了。
既然是为用户服务的,llm 的打分就需要和用户(不停变化的)偏好对齐,不然用户想看的是低分、不想看的打高分,那就玩不转了。 向量数据库也只能解决最基本的相关性问题,现实世界要复杂的多,要想做的好的话需要考虑图数据库,包括实体(时间/地点/人物/事件)、实体属性、实体之间的关联,不然就永远只见树木不见森林,没法形成一个好的内容框架。 |
10
jackkkie 2 天前
|
11
SeanKK 2 天前
@marquina 看 OP 这里的表达 LLM 应该是 for 用户意图理解的,抽取用户兴趣( LLM )->召回对应兴趣下的内容(传统搜推流程),这样的做法在大厂也比较流行... 能充分发挥 LLM 的 reasoning 的能力,同时 given 兴趣点进行传统召回排序成本和效果又比较可控
|
13
summerLast OP @dustookk #3 在这个的基础上采取 webhook 的机制,通过相关度匹配触发调用接口
|
14
zero2me 2 天前
不用 AI ,我自己做了一个 https://www.fiflynote.com/news , 但是现在国内好的 RSS 源太难找了
|
15
BeautifulSoup 2 天前 via Android
@marquina 生成式推荐大概率是个伪命题,落地的没有几家。楼主这种用例直接向量匹配就足够了,主要问题是历史数据太少,需要训练的模型学不出来什么信号
|
16
summerLast OP @BeautifulSoup #15 不是直接大模型预测用户会看的内容 id 有哪些,是通过对用户做画像,用画像去做最近邻检索,这里面没有训练任何的模型
|
17
BeautifulSoup 1 天前 via Android
@summerLast 我觉得做到 embedding 匹配一步就可以了,faiss 或者向量数据库都可以实现。大模型做画像的问题是要强行用离散文字表述一个连续隐含特征,信息损失太大,边际收益太低。
|
18
BeautifulSoup 1 天前
@marquina
> 要想做的好的话需要考虑图数据库,包括实体(时间/地点/人物/事件)、实体属性、实体之间的关联,不然就永远只见树木不见森林 想法很好,但首先从无结构文本中抽取实体误差就不小,还涉及到实体标准化对齐等等一整个 pipeline (比如川普、特朗普、Trump 都指向一个实体)。这类想法学术界研究很多,但我的体会是落地很难,最主要原因是:1.既然要从文本中抽取这些片段,那为什么不直接用原始文本; 2.维护图数据库(也就是知识图谱)代价太高,更新困难。 |