基于ETL与LLM的自动化新闻生成系统：从爬虫到发布的完整实践

1. 项目概述与核心价值最近在折腾一个挺有意思的东西叫finaldie/auto-news。这名字听起来就挺直白的一个“自动新闻”项目。但别被名字骗了它可不是简单的RSS聚合器或者爬虫脚本。我花了点时间深入研究了一下发现它的核心思路是构建一个全自动化的新闻内容生产与分发管道。简单来说就是给定一个主题或关键词系统能自动完成从信息搜集、内容整合、文本生成到最终发布的整个流程全程无需人工干预。这玩意儿解决了一个什么痛点呢对于内容运营者、自媒体博主甚至是需要定期更新行业资讯的企业来说持续产出高质量、时效性强的内容是个体力活。每天盯着新闻源筛选、整理、改写、发布耗时耗力。auto-news瞄准的就是这个场景试图用技术手段将人从重复性的信息处理工作中解放出来实现“内容流水线”的自动化。它适合那些对技术有一定了解希望提升内容生产效率或者想探索AI在内容创作领域应用可能性的朋友。2. 核心架构与工作流拆解2.1 整体设计思路auto-news的设计遵循了典型的ETLExtract, Transform, Load数据流水线思想但将其应用在了新闻内容领域。整个系统可以抽象为四个核心阶段信息源抓取Extract从预设的、多样化的新闻源如新闻网站API、RSS订阅、社交媒体趋势中根据目标主题爬取原始数据。内容处理与清洗Transform这是最核心的一环。对抓取到的杂乱、冗余的原始文本进行清洗、去重、关键信息提取如实体识别、事件摘要并利用自然语言处理技术进行内容的重组与润色。内容生成Generate基于处理后的结构化信息利用大语言模型如GPT系列、Claude等生成符合特定风格如简讯、深度分析、社交媒体帖子的最终新闻稿件。发布与分发Load将生成的稿件自动发布到指定的平台如WordPress博客、微信公众号、Telegram频道、Twitter等。这个流程形成了一个闭环。系统的智能程度很大程度上取决于第二阶段和第三阶段的技术选型与实现。2.2 关键技术栈选型考量为什么是这些技术这里分享一下我的选型逻辑爬虫框架如 Scrapy, PlaywrightScrapy适合结构化程度高、反爬策略一般的新闻网站。它的异步处理能力和成熟的中间件、管道机制非常适合大规模、稳定的数据抓取任务。对于主要依赖API或静态页面的新闻源Scrapy是首选。Playwright当目标网站大量使用JavaScript动态渲染内容时传统的请求-解析模式就失效了。Playwright可以模拟真实浏览器行为完美解决动态加载问题。虽然资源消耗更大但对于现代前端框架构建的新闻站是必须的。实操心得在实际项目中我通常会采用混合模式。对主流新闻API和静态页用Scrapy对少数顽固的动态站用Playwright作为补充。同时严格遵守robots.txt并设置合理的请求间隔如3-5秒这是长期稳定运行的基本道德和技术保障。自然语言处理NLP工具链文本清洗BeautifulSoup,lxml用于HTML解析正则表达式处理特定噪音。关键信息提取这里会用到命名实体识别NER库如spaCy或StanfordNLP。它们能快速识别出文本中的人名、地名、组织名、时间、金额等这些是构成新闻要素的基石。文本摘要与去重对于多源报道同一事件的情况需要去重并生成摘要。TextRank或BERT等模型生成的嵌入向量可以用于计算文本相似度实现聚类和去重。摘要则可以使用transformers库中的预训练摘要模型如BART、T5。注意NLP处理环节非常吃数据质量。脏数据进去垃圾结果出来。因此前期的清洗必须足够细致。大语言模型LLM集成这是项目的“大脑”。目前主流选择是通过API调用云端大模型如OpenAI GPT-4/3.5-Turbo、Anthropic Claude、国内深度求索等。选型理由自建模型成本训练、算力和效果通用性、创造性在现阶段通常不如成熟的API。API提供了稳定、高效且持续更新的文本生成能力。关键技巧成本控制新闻生成是高频调用。需要精心设计System Prompt来固定输出格式和风格并利用Function Calling或结构化输出来确保生成内容如标题、正文、标签的格式稳定便于后续处理。同时对非时效性内容可以考虑使用缓存对长文本进行分块处理以节省Token。任务调度与管道管理Apache Airflow或Prefect是工业级选择。它们能可视化地编排复杂的工作流DAG处理任务依赖、失败重试、报警通知非常适合这种多步骤、定期执行的自动化流程。简易方案如果项目初期比较简单用Cron定时触发脚本结合 Python 的logging模块和邮件/钉钉机器人报警也能跑起来。但当任务复杂后迁移到 Airflow 几乎是必然。发布器Publisher这部分需要针对每个目标平台进行定制化开发。例如WordPress使用python-wordpress-xmlrpc库或 REST API。微信公众号使用官方API需要企业服务号或订阅号并开通接口权限。社交媒体使用tweepy(Twitter/X),python-telegram-bot等。避坑指南各平台的API限制频率、内容审核是主要挑战。必须实现健壮的错误处理和重试机制并且生成的内容必须经过严格自审确保符合平台规范避免封号风险。3. 核心模块实现细节与实操3.1 信息源抓取模块的稳健性设计抓取是流水线的源头源头不稳全盘皆输。1. 多源配置与优先级管理我通常会用YAML或JSON来管理新闻源配置一个基础的配置结构如下news_sources: - name: TechCrunch type: rss url: https://techcrunch.com/feed/ priority: 1 categories: [科技, 创业] enabled: true - name: Reuters API type: api endpoint: https://newsapi.org/v2/everything parameters: q: artificial intelligence apiKey: ${API_KEY} priority: 2 categories: [科技, AI] enabled: true - name: DynamicNewsSite type: playwright url: https://example-news.com wait_for_selector: .article-list priority: 3 categories: [综合] enabled: false # 暂时禁用priority字段用于在多个源报道同一事件时决定信源权重。enabled字段可以快速开关某个源便于维护。2. 反反爬策略与容错User-Agent轮换准备一个列表随机选择。IP代理池对于抓取量大的情况付费的代理服务如住宅代理是必要的投资。免费代理几乎不可用。请求重试与退避实现指数退避算法。第一次失败等2秒重试第二次等4秒以此类推通常设置最大重试次数为3-5次。结构化数据提取尽量利用网站的结构化数据标记如JSON-LD(常见于新闻文章)。这比解析HTML标签要稳定得多。可以先用BeautifulSoup查找script typeapplication/ldjson标签。3. 增量抓取与去重新闻是时序数据我们只关心新内容。最有效的方法是利用新闻的唯一标识符如文章ID、URL和发布时间。每次抓取后将文章ID和发布时间存入数据库如SQLite或PostgreSQL。下次抓取时先查询该源已抓取的最新ID或时间只请求此之后的内容。对于没有明确ID的源可以对URL或标题计算一个哈希值如MD5作为去重依据。3.2 内容处理与增强从数据到信息原始抓取到的文本是“数据”我们需要将其转化为结构化的“信息”。1. 文本清洗标准化流程import re from bs4 import BeautifulSoup import html def clean_article_html(raw_html): 清洗HTML文章内容 soup BeautifulSoup(raw_html, html.parser) # 移除无关标签 for tag in soup([script, style, nav, footer, aside, 广告]): tag.decompose() # 获取主内容常见策略找最大的article标签或包含最多p的div article_content soup.find(article) if not article_content: # 启发式方法寻找包含最多文本的div all_divs soup.find_all(div) article_content max(all_divs, keylambda d: len(d.text)) if all_divs else soup.body text article_content.get_text(separator\n, stripTrue) # 清理空白字符和特殊字符 text re.sub(r\s, , text) # 合并多个空白 text html.unescape(text) # 转换HTML实体 text re.sub(r[\x00-\x08\x0b\x0c\x0e-\x1f\x7f-\x9f], , text) # 移除控制字符 return text.strip()2. 关键信息提取实战使用spaCy进行NER是一个高效的选择import spacy nlp spacy.load(zh_core_web_sm) # 中文模型英文用 en_core_web_sm def extract_entities(text): doc nlp(text) entities { PERSON: [], ORG: [], GPE: [], # 地理政治实体国家、城市 DATE: [], MONEY: [], PRODUCT: [] } for ent in doc.ents: if ent.label_ in entities: entities[ent.label_].append(ent.text) # 去重 for key in entities: entities[key] list(set(entities[key])) return entities提取出的实体可以作为文章的标签、分类依据也是后续生成摘要和新闻稿的重要素材。3. 多源信息聚合与事件归并这是提升内容质量的关键。当多个信源报道同一事件时我们需要将其合并形成一个更全面、多视角的“事件条目”。相似度计算将每篇文章的标题和正文摘要转换为向量使用sentence-transformers库然后计算余弦相似度。聚类使用简单的聚类算法如DBSCAN或基于相似度阈值如0.7进行分组。生成事件摘要将同一事件下的多篇文章正文或摘要拼接送入摘要模型生成一个更权威、更全面的概述。这比单源摘要信息量更大。3.3 大语言模型驱动的内容生成策略有了结构化的“事件信息”现在需要LLM将其加工成最终稿件。1. Prompt工程是核心System Prompt 决定了LLM的角色和输出格式。一个针对新闻简讯的Prompt示例你是一个专业的新闻编辑助理。请根据提供的事件信息生成一篇简洁、客观、事实准确的新闻简讯。 要求 1. 标题不超过20字吸引人且概括核心。 2. 正文300字左右。采用倒金字塔结构第一段为导语包含5W1H何时、何地、何人、何事、为何、如何核心要素。后续段落补充细节和背景。 3. 结尾可以是一句总结或简要展望。 4. 风格语言正式、中立避免主观评价和情绪化词汇。 5. 输出格式严格的JSON格式包含title, body, tags三个字段。tags是基于内容提取的3-5个关键词。 请基于以下事件信息进行创作 {event_info}{event_info}是前面步骤生成的结构化数据包括事件概述、关键实体、时间、涉及公司/人物等。2. 成本优化与缓存模板化生成对于高度结构化的短讯如快讯、股价变动可以不用每次都调用LLM。设计好模板将提取的数据公司名、股价、涨跌幅直接填充即可。缓存对于非时效性或背景信息如公司介绍、技术概念解释可以将其生成结果缓存起来存数据库或Redis下次遇到相同实体时直接复用极大节省Token。流式处理与异步调用如果需要生成多篇稿件使用异步库如aiohttp并发调用API但务必注意平台的速率限制。3. 内容安全与审核这是红线绝对不能省。在调用LLM生成后和发布前必须加入审核环节。关键词过滤建立一套本地敏感词库对生成内容的标题和正文进行扫描。二次LLM审核可以用一个更小的、专门训练过的分类模型或者再次调用LLM以审核员角色让其判断内容是否涉及不当或敏感话题。虽然增加成本但对于自动化发布系统是必要的保险。人工审核队列对于置信度不高或模型标记为“需复核”的内容将其放入一个队列供人工最终审核。系统可以设置为“全自动”、“半自动需审核”、“手动”三种模式。3.4 自动化发布与监控闭环1. 发布适配器模式设计一个统一的Publisher接口然后为每个平台实现一个适配器。from abc import ABC, abstractmethod class Publisher(ABC): abstractmethod def publish(self, article_data): 发布文章article_data是包含title, content, tags等的字典 pass abstractmethod def test_connection(self): 测试平台连接和权限 pass class WordPressPublisher(Publisher): def __init__(self, url, username, password): from wordpress_xmlrpc import Client self.client Client(url, username, password) def publish(self, article_data): # 创建WordPress文章对象并发布 # ... 具体实现 pass class WeChatPublisher(Publisher): # 实现微信公众号API调用 pass这样主程序只需要调用publisher.publish(article)无需关心底层平台差异。2. 状态跟踪与日志每篇文章在流水线中的每个状态已抓取、已清洗、已生成、已发布、发布失败都应记录在数据库。这便于问题排查快速定位哪篇文章在哪个环节出错。数据统计分析各环节的成功率、耗时。重试机制对发布失败的文章可以根据错误类型如网络超时、内容审核失败决定是否重试、何时重试。3. 告警机制监控是自动化系统的“守夜人”。需要监控组件健康度爬虫是否持续收到数据LLM API调用是否正常业务指标每日成功发布文章数是否骤降内容相似度是否异常升高可能意味着信息源失效或LLM生成重复错误报警任何环节的失败都应触发报警方式可以是邮件、Slack、钉钉或企业微信机器人。4. 部署、优化与高级玩法4.1 系统部署架构建议对于个人或小团队一个高性价比的部署方案如下服务器一台境外的VPS如Linode, DigitalOcean2核4G配置起步用于运行爬虫和调度器避免国内网络对某些新闻源或LLM API的访问问题。数据库使用PostgreSQL或MySQL。SQLite适合原型但正式运行需要更健壮的关系数据库来管理文章、任务状态和配置。任务调度使用Docker容器化部署Airflow。Airflow的Web UI和日志管理非常方便。发布节点如果目标发布平台如微信公众号要求服务器IP在国内可能需要一台国内的轻量应用服务器或函数计算服务作为“发布网关”接收来自主流水线的任务并进行发布。两者之间通过带认证的API进行安全通信。4.2 性能优化与成本控制异步并发爬虫和LLM API调用是I/O密集型操作使用asyncioaiohttp可以大幅提升吞吐量减少总运行时间。数据库索引优化对文章URL哈希、发布时间、状态等字段建立索引加快查询速度。LLM Token精打细算在Prompt中明确要求“回答尽可能简洁”。对输入给LLM的原始文本如多篇聚合文章进行压缩摘要只保留核心信息。探索使用更便宜但性能足够的模型例如用gpt-3.5-turbo生成初稿再用gpt-4进行润色和优化而非全程使用GPT-4。利用免费额度多家LLM API提供商有新用户免费额度可以合理利用进行测试和小规模运行。4.3 内容质量提升的进阶思路风格化与多频道运营可以为不同平台生成不同风格的内容。例如给Twitter生成带话题标签的短评给LinkedIn生成偏行业深度的分析给公众号生成图文并茂的推文。这需要为不同风格定制不同的Prompt模板。数据反馈闭环收集发布内容的阅读量、点赞、评论等数据可通过平台API获取。利用这些数据微调Prompt或模型选择。例如发现某类话题的“问答式”标题打开率更高就可以在生成该类内容时倾向使用这种标题模式。引入事实核查在生成流程中加入一个“事实核查”步骤。让LLM根据提供的信源在生成的稿件中标注引述来源例如“据XX媒体报道”并可以尝试用另一个LLM调用搜索引擎API如Serper API对关键事实进行快速复核增加内容的可信度。4.4 常见问题与故障排查实录Q1: 爬虫突然抓不到数据了怎么办A1: 这是最常见的问题。排查顺序手动访问先用浏览器和curl命令测试目标网址确认网站本身可访问。检查反爬查看返回的HTTP状态码。如果是403/429说明被屏蔽了。检查请求头特别是User-Agent是否模拟得够像是否需要添加Referer、Cookie。考虑启用IP代理。检查页面结构网站改版了。用浏览器开发者工具查看新的HTML结构更新你的选择器XPath/CSS Selector。优先寻找JSON-LD等结构化数据。查看日志检查爬虫日志中的错误信息。Q2: LLM生成的内容质量不稳定有时跑题或胡言乱语。A2:温度Temperature参数这是控制随机性的关键。对于新闻生成需要稳定、客观建议设置为较低值如0.2-0.5。过高的温度会导致创造性过强事实错误增多。优化PromptPrompt指令必须清晰、无歧义。使用“必须”、“禁止”、“请以...格式输出”等强约束性词语。在System Prompt中明确其“新闻编辑”的角色。输入信息质量检查喂给LLM的event_info是否清晰、结构化。垃圾输入必然导致垃圾输出。确保信息提取环节足够干净。模型选择如果用的是gpt-3.5-turbo可以尝试切换到gpt-4后者在遵循复杂指令和保持逻辑一致性上通常表现更好当然成本也高。Q3: 发布到平台失败提示“内容违规”或“发布频繁”。A3:内容审核前置务必加强前文提到的本地敏感词过滤和LLM二次审核。了解各平台的社区规范将常见违规词加入过滤库。频率限制每个平台都有API调用频率限制。必须在发布器代码中实现“限流”和“队列”机制。例如为微信公众号发布设置“每篇文章间隔至少5分钟”的延迟。错误处理与重试对于网络超时等临时错误实现指数退避重试。对于明确的内容违规错误则不应重试而是将文章标记为“审核失败”转入人工处理队列。Q4: 系统运行一段时间后发现生成的文章越来越同质化。A4:信息源拓展定期评估和更新你的新闻源列表。加入一些观点独特、小众但高质量的博客或行业媒体。引入随机性在Prompt中可以偶尔加入一些创意性指令比如“请从投资者角度分析其影响”或者“用三个要点总结其意义”为内容增加多样性。人工干预与种子系统无法完全替代人的判断。定期人工输入一些热点话题或角度作为“种子”引导系统下一阶段的抓取和生成方向。构建auto-news这样的系统是一个典型的软件工程与AI应用结合的实践。它没有银弹核心在于对每个模块的精细打磨和对异常情况的充分预案。从技术上看它串联了爬虫、数据处理、NLP、大模型和系统部署等多个领域。从结果上看它确实能极大提升特定场景下的内容产出效率。但必须清醒认识到它目前是“辅助”而非“替代”人的监督、审核和创意引导仍然不可或缺。我的体会是把这个项目做下来最大的收获不是得到了一个自动发新闻的工具而是对如何将AI能力产品化、工程化有了更深刻的理解这套流水线思维可以复用到很多其他自动化场景中去。