RSSMonster：本地向量模型与小模型驱动的Agentic RSS阅读器

你是不是也有过这种经历：RSS 源越加越多，却越来越不想打开阅读器。上千条未读文章堆在列表里，标题既看不出质量，也分不清优先级；想找某篇以前看过的技术文章，只能靠模糊记忆一页页翻；真正重要的几篇更新，反而淹没在大量低质转载里。传统 RSS 阅读器的问题不在于“能不能拉取”，而在于“拉下来之后没有加工能力”。

如果有一个 RSS 阅读器，能在本地完成自动预取、去重、摘要、语义分类、图片识别和定向推送，那订阅信息的消费方式就会完全不一样。本文要实践的，正是这样一套基于本地向量模型和 small models 的 Agentic RSS 阅读器方案：RSSMonster。整篇文章会从核心概念讲起，逐步拆解数据流水线，再给出可运行的容器部署、检索配置、通知分发和排错思路。无论你是想搭建个人知识库，还是想给团队做一套隐私友好的信息聚合系统，都能从中找到可复用的方案。

1. RSSMonster 是什么？为什么需要 Agentic RSS 阅读器

1.1 传统 RSS 阅读器的痛点

传统 RSS 阅读器的工作方式大致可以概括为四个动作：定时抓取 Feed、解析 XML、保存文章、按时间倒序展示。对于订阅量少的用户来说，这套流程够用；但订阅源一旦增加到几十个甚至上百个，问题就非常明显。

第一，信息没有分层。所有来源的文章混在一起，你分不清哪一篇是高价值深度内容，哪一篇只是标题党。第二，检索能力弱。关键词搜索只能匹配字面内容，搜“向量数据库”搜不到标题写“embedding 存储”的同类文章。第三，缺少自动化。阅读器只会把内容摆在你面前，不会帮你摘要、不会自动分类、也不会根据文章类型把内容送到合适的下游系统。

这些痛点的共同根源是：传统 RSS 工具把“内容获取”和“内容理解”割裂开了。而 RSSMonster 的思路，正是把内容理解能力用本地模型补上。

1.2 Agentic RSS Reader 的核心变化

Agentic 这个词听起来很抽象，但放到 RSS 场景里其实很好理解。传统方案是“拉取 -> 展示”两步走；Agentic 方案则变成了一条可决策的任务链。

先看一个处理流程：

1. 预取阶段：先拉取 Feed，判断内容是否有变化，不急着全文入库。
2. 清洗阶段：抽取正文、去掉导航和广告噪声，提取发布时间、作者、封面图等元数据。
3. 语义理解阶段：用本地 embedding 模型把文章向量化，计算它与已有内容的相似度，实现去重和聚类。
4. 分类与摘要阶段：根据文章主题，路由给不同的本地小模型，生成摘要、打标签，或者做违规内容识别。
5. 分发阶段：把处理结果推送到 Web UI、Ntfy、Telegram、Signal 或 Paperless-ngx。

这个流程里，每一步都可能产生条件分支。也就是说，系统不是机械执行，而是根据中间结果做决策。这就是“Agentic”的含义：多个小模型被编排成一个闭环，围绕“帮助用户高效消费 RSS”这一个目标协同工作。

1.3 本文适合哪类读者

如果你属于以下任意一类，这篇文章会很有价值：

• 订阅大量 RSS 源，希望用本地模型自动摘要和分类的个人开发者。
• 团队内部需要搭建信息聚合看板，但对数据隐私有要求，不希望把内容送到外部 API。
• 正在研究 Agentic 工作流、RAG、本地小模型部署的开发者。
• 想用 SQLite、向量检索、OCR 和通知服务组合出一套自动化流水线的人。

阅读本文后，你将理解 RSSMonster 的整体架构，能搭建一套容器化环境，完成 RSS 预取、向量索引、摘要生成和通知分发，并掌握常见问题的排查方法。

2. 技术架构与环境准备

2.1 技术栈概览

RSSMonster 的特色是“尽量本地化，尽量小模型化”。它不是一个大而全的 AI 平台，而是很多轻量组件的组合。常用技术栈可以参考下表：

这里要说明一点：本文只会展示可落地的配置思路，不会把每个模型的版本号写死。因为模型仓库更新很快，不同机器上的推理框架也不一样。实际部署时，请以你拉取的镜像和模型版本为准。

2.2 目录规划

建议在一个独立目录下完成全部分布署，方便迁移和备份。以下是一个比较清晰的项目结构：

rssmonster-demo/ ├── docker-compose.yml ├── .env ├── config/ │ ├── feeds.yaml │ ├── apprise.yml │ └── rules.yaml ├── data/ │ ├── rssmonster.db │ ├── embeddings/ │ └── images/ └── logs/

其中config目录保存订阅源和规则配置，data目录保存 SQLite 数据库、向量文件和图片缓存。把配置与数据分离，后续升级镜像时不容易丢数据。

2.3 Docker Compose 基础配置

下面的 Compose 文件是演示用最小版本。镜像名以 RSSMonster 官方发布的镜像名称为准，这里使用常见环境变量展示配置思路。

# 文件路径：rssmonster-demo/docker-compose.yml services: rssmonster: image: ghcr.io/unclemikeymike/rssmonster:latest container_name: rssmonster restart: unless-stopped ports: - "8080:8080" volumes: - ./config:/config - ./data:/data - ./logs:/logs environment: TZ: Asia/Shanghai RSSMONSTER_CONFIG_DIR: /config RSSMONSTER_DB_PATH: /data/rssmonster.db RSSMONSTER_EMBEDDING_MODEL: all-MiniLM-L6-v2 RSSMONSTER_VECTOR_DIR: /data/embeddings RSSMONSTER_IMAGE_DIR: /data/images RSSMONSTER_APP_EXTERNAL_URL: http://localhost:8080 ollama: image: ollama/ollama:latest restart: unless-stopped volumes: - ./data/ollama:/root/.ollama

如果你本机没有 GPU，Ollama 可以纯 CPU 运行，只是生成摘要的速度会慢一些。第一次启动后，需要手动拉取一个文本模型，例如：

docker exec -it ollama ollama pull qwen2.5:3b

再次强调：具体模型名称要以你安装的 Ollama 版本为准，也可以用其他兼容 OpenAI API 的本地推理服务。

3. 核心概念拆解：本地向量模型、Small Models 与 Agentic 编排

3.1 本地向量模型是什么

向量模型（Embedding Model）做的事情，是把一段文本转换成一个固定维度的浮点数组。比如把“Python 内存优化技巧”转换成 384 维或 768 维的向量。转换之后，语义相近的文章在向量空间里的距离会比较近，即使它们没有完全相同的关键词。

RSSMonster 使用本地向量模型，意味着文本不需要发给外部 API。整个过程可以在普通 CPU 上完成，对内容隐私很友好。对于中文场景，可以选择bge-small-zh-v1.5；对于英文或混合场景，all-MiniLM-L6-v2是常见选择。这些模型都不大，通常只有几十到几百 MB，适合作为 RSS 阅读器的语义层。

有了向量，系统就能做两件重要的事情：内容去重和语义检索。重复转载的文章即使标题被修改，只要正文足够相似，向量相似度依然会很高；搜索时输入“数据库连接池调优”，也能召回标题为“HikariCP 参数优化实践”的文章。

3.2 Small Models 为什么要用“小模型”

大语言模型能力很强，但部署成本也高。RSSMonster 面对的任务是摘要、标签、路由判断和轻量理解，这些任务用小模型就能完成，没必要启动一个几十 B 的大模型。

小模型的核心优势是：

• 资源占用低，几 GB 内存即可运行。
• 推理速度快，批量处理订阅文章时不会积压。
• 容易本地部署，不依赖外部 API，数据不出内网。
• 适合长期运行，作为后台常驻服务更稳定。

当然，小模型也有能力边界。如果文章专业性极强，或者需要跨语言复杂推理，摘要质量可能不如大模型。因此 RSSMonster 的设计一般会把模型能力放在“够用就好”的位置，把重点放在流程编排和规则约束上。

3.3 Agentic 编排与 RAG 的结合

RSSMonster 的 Agentic 流水线，本质上是一种面向“个人知识库”的轻量 RAG 方案。RAG 全称是 Retrieval-Augmented Generation，即检索增强生成。传统 RAG 是“问答系统根据向量检索结果生成回答”，RSSMonster 则把这一思路迁移到了 RSS 场景。

系统流程可以这样理解：

1. 新文章进来后，先向量化。
2. 在已有文章库里做相似度检索，如果和旧文章高度重复，则跳过或合并。
3. 把文章内容、相似文章、订阅源信息一起交给本地小模型。
4. 小模型根据指令输出摘要、分类结果和推荐标签。
5. 规则引擎再根据输出决定推送到哪个通知渠道。

这里的关键是“路由”：不是每篇文章都走同一套模型，而是先判断内容类型。技术文章可以走深度摘要，新闻简讯走短摘要，图像为主的内容则交给视觉模型处理。这种按需调用小模型的方式，就是 Agentic 编排的体现。

4. 实战一：分阶段预取与内容清洗

4.1 分阶段预取的设计

RSS 抓取最容易踩的坑是“一股脑全量下载”。有些订阅源文章很多，直接全量抓取不仅慢，还会给目标服务器造成压力，也容易把大量垃圾内容灌进数据库。

分阶段预取的核心是控制节奏。第一阶段，只抓取 Feed 列表，拿到条目标题、链接、更新时间；第二阶段，对比本地数据库，筛选出新增或更新的文章；第三阶段，才真正抓取正文内容。这样做有三个好处：节省流量、避免重复入库、降低被封风险。

配置订阅源时，可以用类似下面的 YAML：

# 文件路径：config/feeds.yaml feeds: - name: "示例技术博客" url: "https://example.com/feed.xml" fetch_interval: 30m enabled: true - name: "团队内部新闻" url: "https://internal.example.com/rss" fetch_interval: 5m enabled: true require_full_text: false

字段说明：

• fetch_interval表示抓取间隔，对更新频繁的源可以设短一些。
• require_full_text表示是否必须抓取正文。有些源只提供摘要，设为 false 可以只处理摘要内容。

4.2 内容清洗与元数据提取

抓回正文后，第一步不是直接入库，而是清洗。网页 HTML 里通常混着导航、广告、脚本和无关推荐，先经过正文抽取器，把核心内容提取出来。

清洗后的文章需要保留以下元数据：

• 作者与发布时间。
• 原始链接与站点名称。
• 封面图 URL 或本地图片路径。
• 正文纯文本。
• 原始 HTML 是否包含代码块、表格等特殊结构。

元数据越完整，后续分类和检索越准确。比如 Paperless-ngx 接收文档时，需要发布时间和来源；Telegram 推送时，需要标题和封面图；向量检索时，则主要依赖标题与正文。

这里给出一段思路性的 Python 片段，实际实现需要根据你选择的解析库调整：

# 伪代码：清洗与元数据提取 from bs4 import BeautifulSoup def clean_article(html: str, base_url: str): soup = BeautifulSoup(html, "html.parser") for tag in soup(["script", "style", "noscript"]): tag.decompose() title = soup.title.get_text(strip=True) if soup.title else "" content_node = soup.select_one("article") or soup.select_one(".post-content") or soup.body content_text = content_node.get_text("\n", strip=True) if content_node else "" image = soup.find("meta", property="og:image") cover = image["content"] if image and image.has_attr("content") else "" return { "title": title, "text": content_text, "cover_url": cover, "source_url": base_url, }

需要留意的是，用 BeautifulSoup 解析正文只适合普通 HTML 页面。如果遇到动态渲染页面，正文抽取结果可能不完整，这种情况建议放弃该源或接入无头浏览器方案。

4.3 去重策略

去重分为三个层次。第一层是 URL 去重，直接比对原始链接；第二层是哈希去重，对正文计算 SimHash 或 MinHash，适合内容完全相同但 URL 不同的文章；第三层是向量去重，适合标题被改写、段落部分调整的转载内容。

在 RSSMonster 中，URL 和哈希去重在预取阶段完成，向量去重在向量索引章节处理。不要只依赖 URL 去重，因为很多站点会通过utm参数生成不同的链接，指向同一篇文章。

# 伪代码：URL 规范化与指纹去重 import hashlib from urllib.parse import urlparse, parse_qsl, urlencode, urlunparse def normalize_url(url: str) -> str: parts = urlparse(url) clean_query = [(k, v) for k, v in parse_qsl(parts.query) if k not in ("utm_source", "utm_medium", "utm_campaign")] return urlunparse(parts._replace(query=urlencode(clean_query))) def content_fingerprint(text: str) -> str: return hashlib.sha256(text.strip()[:2048].encode("utf-8")).hexdigest()

规范化 URL 后再比对数据库，可以明显减少重复文章。

5. 实战二：向量索引与本地语义检索

5.1 向量入库流程

清洗后的文章会进入向量化环节。每篇文章生成一个向量，向量与文章的 ID、标题、正文摘要一起存储。入库流程可以拆成这些步骤：

1. 读取待处理文章。
2. 将标题和正文前 N 个字符拼接成向量化输入。
3. 调用本地 embedding 模型得到向量。
4. 计算与已有文章的最大相似度。
5. 如果最大相似度高于阈值，标记为疑似重复；否则写入向量索引。

向量相似度通常使用余弦相似度（Cosine Similarity）。它只关心方向不关心模长，适合文本语义比较。一个简单的计算例子如下：

import numpy as np def cosine_similarity(vec_a, vec_b): a = np.asarray(vec_a, dtype=np.float32) b = np.asarray(vec_b, dtype=np.float32) dot = float(np.dot(a, b)) norm_a = float(np.linalg.norm(a)) norm_b = float(np.linalg.norm(b)) return dot / (norm_a * norm_b + 1e-9) similarity = cosine_similarity( [0.1, 0.3, 0.5], [0.2, 0.1, 0.6] ) print(similarity) # 一个 [0, 1] 之间的值

实际项目中不建议把所有向量放在 Python 列表里遍历，因为文章多了以后性能会下降。通常做法是借助 SQLite 的向量扩展或者独立的向量索引文件。

5.2 基于 SQLite 的存储方案

SQLite 是 RSSMonster 的主要存储选型，它轻量、文件化、便于备份。配合 FTS5 扩展，可以实现不错的全文检索。

建立 FTS5 虚拟表的 SQL 示例如下：

-- 建表：文章表 CREATE TABLE IF NOT EXISTS articles ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, summary TEXT, content TEXT, source_url TEXT UNIQUE, author TEXT, published_at DATETIME, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 建表：FTS 全文索引 CREATE VIRTUAL TABLE IF NOT EXISTS articles_fts USING fts5( title, summary, content, content='articles', content_rowid='id' ); -- 同步索引 INSERT INTO articles_fts(rowid, title, summary, content) SELECT id, title, summary, content FROM articles; -- 关键词检索，按相关性排序 SELECT id, title, bm25(articles_fts) AS rank FROM articles_fts WHERE articles_fts MATCH '本地 OR 向量 OR 模型' ORDER BY rank;

bm25()是 FTS5 内置的相关性评分函数。搜索结果会优先展示更相关、更匹配的文章。

5.3 语义检索与关键词检索如何协同

关键词检索适合精确匹配，语义检索适合模糊匹配。实际推荐的做法是“两种检索并行，再融合排序”。

比如用户输入“数据库连接池优化”：

• FTS 检索可能匹配到标题完全包含“数据库连接池”的文章。
• 向量检索可能匹配到标题是“HikariCP 参数调优记录”的文章。
• 两路结果分别打分，再按权重合并。

这样既能保证精确词不丢，也能挖掘出同义表达的内容。RSSMonster 的搜索界面通常同时展示这两种结果，并标注结果的检索来源。

如果你在本地用 Python 做两路检索，核心逻辑类似：

def hybrid_search(query: str, top_k: int = 20): # 1. FTS 关键词检索 fts_results = run_fts_query(query, top_k) # 2. 向量语义检索 query_vec = embed_model.encode(query) vector_results = vector_store.search(query_vec, top_k) # 3. 简单融合：分数归一化后相加 merged = {} for row in fts_results: merged[row["id"]] = merged.get(row["id"], 0) + row["rank"] * 0.5 for row in vector_results: merged[row["id"]] = merged.get(row["id"], 0) + row["score"] * 0.5 return sorted(merged.items(), key=lambda x: x[1], reverse=True)[:top_k]

分数融合的权重没有标准答案，建议根据你的使用场景调整。如果你的阅读资料偏技术术语，关键词权重可以高一些；如果偏资讯类，向量权重可以高一些。

6. 实战三：摘要、OCR 与图像识别

6.1 递归摘要生成

大型文章直接丢给本地小模型时，往往超出上下文窗口，或者导致摘要遗漏重点。RSSMonster 通常会采用“递归摘要”策略。

递归摘要的核心思路是分而治之：

1. 把正文按标题或段落切块。
2. 每个块生成一个短摘要。
3. 把多个短摘要合并，再一次生成整体摘要。

这样做的好处是，无论文章多长，最终都能压缩成一段结构化摘要。对本地小模型来说，每次处理的输入都很短，不容易丢失信息。

下面是一个流程示意图：

长文章 └── 块1 摘要 └── 块2 摘要 └── 块3 摘要 └── 合并后的长摘要 └── 最终摘要

如果文章只有几百字，直接生成摘要即可，不需要递归。设置一个阈值，超过阈值才启用递归，可以兼顾效果和性能。

6.2 接入 OCR 模型

很多 RSS 文章内容以图片为主，比如产品截图、数据报表、思维导图。没有 OCR 时，这些文字信息无法进入搜索索引。接入本地 OCR 模型后，可以把图片中的文字提取出来，作为文章的补充内容。

常见选择包括 Tesseract 和 PaddleOCR。PaddleOCR 对中文支持较好，Tesseract 更轻量。RSSMonster 一般会把 OCR 结果作为附件文本存在文章表里，与正文一起参与向量化和全文检索。

需要注意，OCR 不是每张图都做，否则 CPU 会一直处于高负载。建议只处理预设数量的图片，并且优先处理封面图和正文中的前几张图。

# 伪代码：OCR 处理流程 def ocr_image(image_path: str) -> str: image = load_image(image_path) if image.width < 300 or image.height < 300: return "" text = ocr_engine.recognize(image) return normalize_text(text)

小尺寸图片通常没有识别价值，直接跳过可以省掉大量无效计算。

6.3 图像分类与 YOLO World / CLIP

除了 OCR，RSSMonster 还会对封面图做分类。不同订阅源的文章可能共用一张封面图，或者图片内容与文章主题无关。视觉模型可以帮助系统判断这张图到底该不该作为封面。

YOLO World 可以检测图片里的对象类别，比如人、车、代码截图、商品图等。CLIP 则可以把图片和一段文字描述做匹配，比如判断“这张图是否像技术架构图”。“架构图”“代码截图”“封面配图”这些标签主要用于后续的 Web UI 展示和分类筛选。

思路代码如下：

# 伪代码：视觉模型判断图片类型 image_tags = vision_model.predict_tags("cover.png") if "code_screenshot" in image_tags: article.card_style = "code" elif "architecture_diagram" in image_tags: article.card_style = "diagram" else: article.card_style = "default"

这类视觉能力不一定要在 RSSMonster 主进程里做，可以拆成独立的视觉服务，通过消息队列接收任务。这样即使模型推理慢，也不会阻塞 RSS 抓取主流程。

6.4 资源估算建议

本地模型的资源占用是很多人关心的点。以 CPU 环境为例，一个 3B 参数的文本模型做摘要，大概会占用 4~6 GB 内存；MiniLM 类 embedding 模型只有几百 MB；OCR 和 YOLO 模型根据输入图片大小，占用 1~2 GB 不等。

如果你的机器只有 8 GB 内存，建议先关闭 OCR 和视觉模型，只保留 embedding + 文本摘要。先把主流程跑通，再按需加入图片处理能力。如果使用 Docker Compose，建议给不同服务设置内存限制，避免 OOM 影响整个宿主机。

7. 实战四：通知分发与内容安全检测

7.1 用 Apprise 统一通知出口

RSSMonster 的自动化价值，很大程度体现在通知分发上。同一篇文章，按照分类结果可以推送到不同终端。例如：

• 技术文章推送到 Ntfy，方便快速扫读。
• 重要公告推送到 Telegram。
• 需要归档的 PDF 或文档推送到 Paperless-ngx。
• 团队内部信息推送到 Signal。

Apprise 是一个统一通知库，支持多种通知渠道。在 RSSMonster 中配置 Apprise，可以避免为每个渠道单独写对接代码。

# 文件路径：config/apprise.yml apprise: ntfy: - url: "ntfy://ntfy.example.com/rssmonster" tag: tech telegram: - url: "tgram://123456789:abcdefg@rss_monster_channel" tag: important signal: - url: "signal://+15551234567@signal.example.com" tag: team

配置要注意：不要把真实 Token 提交到 Git 仓库。建议通过环境变量注入，或者把apprise.yml加入.gitignore。

7.2 内容安全检测与合法合规处理

自动化通知意味着“机器会把内容直接推给用户”，所以内容安全检测不能省。RSSMonster 在接入外部源和推送前，会做几层检查：

• 检测标题和正文是否包含垃圾信息、低质量营销模板。
• 检测链接是否为可疑钓鱼地址。
• 检测图片是否包含不适合在工作群展示的内容。
• 对无法判断的内容，标记为“待人工确认”，不自动推送。

这部分能力可以用本地规则完成，也可以调用本地视觉模型做粗筛。无论如何，生产环境使用此类自动化系统时，都必须遵守当地法律法规和网站的使用条款，只处理你有权处理的订阅源。涉及生产数据变更时，提前在测试环境验证，并保持数据备份，遵循最小权限原则。

7.3 推送策略与去重

推送不等于“每篇文章都推送”。如果每篇都推，用户很快就会把通知关掉。推荐策略是：

• 白名单源直接推送。
• 分类为“重要”的文章推送。
• 非重要文章只在 Web UI 中展示。
• 同主题文章合并推送，例如“今天有 5 篇 Kubernetes 相关文章”。

每个用户的具体规则可以写在rules.yaml中：

# 文件路径：config/rules.yaml rules: - name: "重要技术文章" match: category: ["kubernetes", "database", "ai"] action: notify channel: telegram priority: high - name: "普通资讯" match: category: ["news", "entertainment"] action: store_only - name: "归档到 Paperless" match: category: ["finance", "contract"] action: dispatch target: paperless-ngx

规则引擎的好处是逻辑透明，方便调试。你可以先观察模型分类结果，再逐步调整规则，不需要改代码。

8. Web UI 与对外服务入口

8.1 Web UI 的功能定位

RSSMonster 自带一个 Web UI，用于阅读、搜索和管理订阅源。它不应该只是一个列表页，而是一个“处理结果展示台”。主要功能可以包括：

• 按分类、标签、订阅源筛选文章。
• 查看模型生成的摘要和标签。
• 混合搜索：关键词配语义结果。
• 查看图片识别结果。
• 管理订阅源和查看抓取日志。

在实现上，Web UI 通常会拆成前端和 BFF（Backend For Frontend）两层。BFF 负责聚合数据库、向量检索、模型服务的数据，返回给前端友好的 JSON 结构。这样前端不用关心底层存储细节，后端也能统一处理鉴权和流量控制。

8.2 用 Caddy 作为统一入口

如果只想在本机访问，直接映射端口即可。如果想让团队内网访问，建议在前面加一层 Caddy，承担 TLS 终止和转发。Caddy 配置比较简单：

rss.example.com { encode gzip reverse_proxy rssmonster:8080 }

需要注意：不要把 RSSMonster 的 8080 端口直接暴露到公网，除非你已经配置好身份认证。内网访问也建议开启基本认证或接入企业 SSO。数据安全永远比方便访问更重要。

8.3 身份认证与访问控制

自托管 RSS 系统保存了大量个人阅读记录，这些数据足以推断一个人的兴趣偏好，所以访问控制不能忽视。通常的做法是：

• 在 Caddy 层开启 Basic Auth。
• 或者在 RSSMonster 应用内开启登录。
• 如果对接企业系统，可以接入 OIDC / SSO。

不同部署方式的安全要求不一样，但至少要做到“系统不能默认无密码开放”。考虑到这类工具很多时候运行在 NAS 或家庭服务器上，建议开启 Docker 的端口映射时，只绑定内网 IP，而不是0.0.0.0。

9. 常见问题与排查思路

9.1 订阅抓取失败

遇到抓取失败的源，不要反复重试。直接记录日志并标记为失败，等下一个抓取周期再处理，可以避免把自己服务器的 IP 封掉。

9.2 向量检索结果不准确

向量检索不准确，最常见原因是文章本身太短，或者向量化输入被截断。建议把标题和开头的 500~1000 字拼接后再向量化。另一个原因是阈值设置不合理。

你可以先统计一批已知相似文章的平均相似度，再设置阈值。通常相似度低于 0.6 的不算重复，高于 0.75 的才高度疑似重复。实际值会随模型和语言变化，需要在自己的数据上验证。

9.3 本地模型推理慢

如果你的机器没有 GPU，文本摘要速度会很慢。建议：

• 选用量化版本的模型，比如 Q4 量化。
• 限制并发推理数量，避免多个模型同时争抢 CPU。
• 将摘要任务放到低优先级队列，后台慢慢处理。
• 对短文章直接跳过摘要，只生成标签。

你可以在 RSSMonster 里设置摘要模式为fast或balanced，具体参数以安装版本为准。不要用生产服务器的全部 CPU 跑模型，否则会影响 RSS 抓取和其他业务。

9.4 SQLite 数据损坏或备份恢复

SQLite 很可靠，但频繁断电或容器被强杀时，可能出现数据库损坏。建议以 WAL 模式运行，并定期备份数据库文件。

# 备份示例 sqlite3 /data/rssmonster.db ".backup '/backup/rssmonster-$(date +%F).db'"

需要删除旧文章或重建索引时，先备份，再在测试环境验证 SQL 语句。尤其执行DELETE或DROP操作前，务必确认影响范围。

10. 最佳实践与隐私安全建议

10.1 配置管理规范

RSSMonster 的配置会随着订阅源增加而膨胀，建议把所有配置纳入 Git 管理，但敏感信息除外。feeds.yaml和rules.yaml可以提交到仓库；apprise.yml、.env和数据库文件必须排除。

# .gitignore 示例 .data/ *.db .env **/apprise.yml data/ollama/ logs/

配置变更走 Git 提交，回滚时也方便。自托管项目最怕“人走了，配置没了”，版本化配置可以降低维护风险。

10.2 数据备份策略

对 RSS 阅读器来说，数据主要包括三部分：

• SQLite 数据库：保存文章元数据、订阅源和分类。
• 向量索引：可能是独立文件或 SQLite 扩展。
• 图片缓存：本地已下载的封面图和正文图片。

备份时至少要覆盖前两类。图片缓存可以按需重建，但数据库和向量索引重建成本较高。建议使用定时任务对数据目录做快照，并把备份文件复制到另一台机器或对象存储。

10.3 安全边界与最小权限

在容器部署中，尽量遵循最小权限原则：

• 容器只挂载必要的目录，不要挂载整个宿主机文件系统。
• RSSMonster 服务使用专用用户运行，不要以 root 运行。
• 数据库目录权限设置为仅容器内用户可读写。
• 如果 RSSMonster 需要访问本地模型服务，只在 Docker 内网访问，不暴露到宿主机端口。
• 通知服务所需的 Token 通过环境变量或 Docker Secret 注入。

有些用户会允许 RSSMonster 执行下载脚本或调用外部命令，这类功能风险很高，建议默认关闭。自动化系统一旦被入侵，能做的破坏和你赋予它的权限成正比。

10.4 模型服务与隐私边界

RSSMonster 强调本地模型，目的就是让数据停留在自己的设备上。但要注意，本地模型只代表推理过程不出网，不代表一定安全。你需要自己负责模型文件的完整性校验，避免下载来源不明的模型。

我个人的建议是：先跑通一条最小链路，再逐步增加模型能力。第一步只做 RSS 预取 + SQLite 存储 + FTS 搜索；第二步加入 embedding 模型做语义去重和检索；第三步加入小模型做摘要；最后才考虑 OCR 和视觉分类。这个顺序可以把变量控制在最小范围，每一步出现问题都容易定位。

如果你的机器只有 4GB 内存，我建议先关闭 YOLO World 和 OCR 模型，不要一开始就追求“全家桶”。RSSMonster 的架构决定了它是一个可以按需启停的流水线，而不是一个必须全部组件同时运行的单体应用。先把核心阅读体验做好，后续再根据订阅源特点补上视觉能力，维护起来会轻松很多。