二开信源管道跑了半个月，聊聊用 pgvector 语义降噪和防重推送踩的几个深坑

可乐🥤ID258 · 昨天 22:38

平时转型做独立开发与出海调研，最大的痛点就是每天被垃圾信息淹没：刷推特、Product Hunt 和各大社区，充斥着大量套壳工具互吹与营销号焦虑小作文。想找点真正有落地参考价值的技术选型、开源轮子，每天在信息堆里淘金太累。
半个月前基于开源底座二开了一套垂直情报过滤管道，单机部署跑在吃灰的 Linux VPS 上。跑顺了之后每天只推 2~3 条高信噪比卡片，省心很多。但回顾这半个月的二开踩坑，有几个工程层面的细节值得复盘：
1. 语义向量去重的边界与阈值陷阱

最开始想用 pgvector 解决「不同媒体在 48 小时内反复报道同一件事」的冗余。直接用文本做 embedding ，发现余弦相似度阈值如果设在 0.85 ，很多同赛道但不同技术方案的独立项目会被误杀；如果放宽到 0.92 ，换个标题的通稿又漏了进来。最终的解法：先做实体与依赖层提取（ GitHub Repo 归一化、顶级域名折叠），实体命中直接折叠；实体不命中才走 5 轴语义打分（落地可行性、商业闭环、代码成熟度），把纯公关稿在打分层直接干掉。
2. Prepared Statement 的异步双写灾难

这是最隐蔽的一个线上坑。异步队列消费时，外部消息（如推到频道）成功发送，但数据库记账由于连续拼接了两段 SQL 语句撞了底层 Prepared Statement 解析报错。结果事务回滚，队列引擎误判该任务未完成，进入指数退避重试，直接引发同一条消息向外部端点死循环狂推。教训就是：跨外部网络调用的 side-effect 必须与本地数据库状态做原子防重设计，外部调用前显式插入 pending 占位锁。
3. 极度克制的推送纪律

做聚合最容易犯的错误是“觉得什么都好，不停往群里塞”。真正自用下来发现，单日超过 4 条人就会麻木。后来在后端代码里把推送频率写死成了物理门禁：

单日封顶 ≤4 条，两次推送硬间隔 ≥2.5 小时；
夜间（ 23:00 - 08:30 ）绝对静默，任务直接推迟到次日早晨。

4. 开源与自用归档

整套流水线目前全自动跑，每天晚上会自动抓取 Top 信号并同步生成 Markdown 归档推送到 GitHub 。
大家平时自己搭信息流、做数据清洗或向量搜索时，有没有遇到过更优雅的降噪去重思路？欢迎交流指正。

GitHub 每日归档仓库： https://github.com/louis-cai/daily-indie-radar
TG 点滴频道：Telegram 搜索 @IndieRadarPro

⚠️内容来自互联网，如有侵权请点击反馈！侵权投诉

二开信源管道跑了半个月，聊聊用 pgvector 语义降噪和防重推送踩的几个深坑

回复

有头有脸

快捷访问

附加功能

关于我们

关注我们