新闻社上AI推荐系统，到底值不值？

我们是谁，以及为什么非要搞这个

我们是华东一家市级新闻社，规模不大不小，年营收几千万，员工一百多号人。主要收入来源是网站、客户端（App）的广告和少量付费内容。团队里年轻人不少，但核心编辑大多还是传统媒体出身。

前两年，我们就发现不对劲了。用户在我们App上停留的时间越来越短，点击量全靠几个编辑手动推的头条撑着。一到热点事件，各大平台流量猛增，我们这里却像一潭死水，用户来了看一眼就走。后台数据显示，超过70%的用户打开App只看首页前三屏，再往下翻的很少。

说实话，那会儿我们心里都清楚，靠编辑“拍脑袋”决定用户看什么，已经行不通了。年轻人都在刷抖音、今日头条，那玩意儿推什么都准。我们也想试试，但一直下不了决心，总觉得那是大厂才玩得转的东西。

折腾的开始：简单想法遇到了复杂现实

一开始，我们的想法很简单：买一套现成的推荐系统，接上我们的内容库，让用户能看到更多他们感兴趣的东西，把停留时长和点击率提上去。

我们先是找了几家做企业软件的供应商，他们给的方案都是“新闻行业解决方案”，听起来功能很全，但一聊到细节，比如怎么识别我们本地的政务新闻和民生新闻的区别，怎么处理我们特有的“通讯员来稿”这种非标准格式内容，对方就有点含糊其辞了。

我们也想过自己招人开发。找了个技术负责人聊了聊，他给我们算了一笔账：要搭建一个能用的推荐系统，至少需要一个算法工程师、一个后端开发、一个数据工程师，再加上服务器和标注数据的人力，一年没个百八十万下不来，而且至少得折腾大半年。我们一听就打了退堂鼓，成本太高，周期太长，风险太大。

第一段弯路：迷信“大而全”

后来，我们接触了一家名气很大的科技公司，他们给我们展示的案例都是服务省级媒体和门户网站的。方案做得非常漂亮，功能列了二三十项，从用户画像、内容理解到实时推荐、A/B测试，一应俱全。我们当时就被唬住了，觉得“贵有贵的道理”。

但真开始实施，问题就来了。他们的系统非常“重”，需要我们把历史几年的数据全部清洗、标注、导入，光数据准备工作就做了两个月。系统上线后，推荐结果却非常“飘”，经常给关注本地时政的用户推娱乐八卦，或者给年轻用户推很严肃的会议报道。我们反馈，对方就说“是数据量不够，模型需要训练”。可我们每天就生产几百条新闻，这个“训练”过程遥遥无期。

那段时间，编辑和运营的抱怨最多：“还不如我们自己推呢！”“这系统净添乱！”

第二段弯路：低估了“内容”的特殊性

我们意识到，通用的推荐算法，理解不了新闻的特殊性。比如，一条普通的火灾报道，和一条涉及重要领导的火灾通报，在算法眼里可能都是“社会-灾害”类新闻，权重一样。但在我们这里，后者必须优先、突出处理。

再比如，我们有很多本地化的内容，像“某小区管道改造”“某条公交线路调整”，这些内容流量不会高，但对特定区域的用户价值极大。通用算法很可能因为点击率低，直接把这些内容“埋”了。

找到方向：要“聪明帮手”，不要“全能大脑”

折腾了三四个月，钱花了一些，效果没看到，团队士气也挺低落。我们停下来开了个会，达成了一个共识：我们需要的不是一套取代编辑的“全能大脑”，而是一个能理解新闻业务、给编辑赋能的“聪明帮手”。

想清楚这一点，我们调整了找供应商的策略：不找最大的，要找最懂媒体业务的；不要功能最全的，要能解决我们核心痛点的。

我们最终选择了一家规模中等、但创始人团队有媒体背景的技术公司。吸引我们的有几点：

1. 他们懂业务：聊的时候，对方能准确说出我们这类新闻社在内容推送上的纠结，比如“时政新闻的强制曝光”与“个性化推荐”的平衡问题。

2. 方案很务实：他们不提“颠覆”，而是说“增强”。方案核心是“人机协同”：系统先根据算法生成推荐列表和理由，再由编辑进行审核和加权调整。编辑的调整动作，又会反过来训练模型。

3. 启动很快：他们不用我们清洗全部历史数据，而是从最近三个月的数据开始，结合一些规则（比如稿件来源、栏目、关键词）做冷启动，让我们能快速看到效果，边用边优化。

实施过程：小步快跑，聚焦核心

我们划定了一个试点范围：只在我们App的“推荐”频道和网站的文章详情页“相关阅读”模块使用。首页头条、要闻区这些关键位置，还是由编辑把控。

实施分了三步：

第一步，用了一个月，把系统基础框架搭好，接入了我们的用户点击、浏览时长数据和内容标签体系。

第二步，又用了一个月，在“相关阅读”模块跑起来。这个场景相对简单，就是根据当前文章，推荐相似内容。效果立竿见影，这个模块的点击率提升了差不多30%，编辑们觉得“确实有用”。

第三步，才切入到App的“推荐”信息流。我们设置了一个“编辑干预后台”，编辑可以看到系统推荐的列表，如果觉得某条新闻非常重要但排名靠后，可以手动提升权重；如果觉得某条推荐不合适，可以一键屏蔽。这个后台成了我们编辑的新工具。

现在效果怎么样？钱花得值吗？

系统稳定运行大半年了，说几个大家最关心的数字：

• 关键指标：App用户人均停留时长从原来的不到3分钟，提升到了接近5分钟。“推荐”频道的整体点击率提升了约25%。

• 内容分发：过去80%的流量集中在20%的头部内容，现在这个比例变成了70%的流量由30%的内容贡献，中长尾内容（比如很多优质的本地深度报道）被阅读的机会明显增加了。编辑们感觉“好稿子不埋没了”。

• 效率变化：负责运营推荐频道的编辑，从原来需要花大量时间手动挑稿、排布，到现在每天花半小时左右在干预后台做校准和微调就行，工作量减轻了不少。

• 成本方面：这套系统的年服务费，大概相当于我们两个资深编辑的年薪。但从带来的流量提升和释放的编辑人力来看，我们内部算账觉得是划算的。回本周期，我们预计在一年到一年半左右。

当然，问题还有不少

1. 冷启动问题还在：对于新注册的用户，或者用户突然看了一个他从不关注的领域，系统的推荐还是有点懵，需要几次点击后才能校准过来。

2. “信息茧房”的担忧：我们也怕一直给用户推他喜欢看的，会不会让他视野变窄。所以我们强制规定，在推荐流里必须穿插一定比例的“本地要闻”和“泛知识类”内容，不管用户爱不爱看。这个平衡点还在摸索。

3. 算法解释性：有时候系统推了一条看似不相关的文章，点击率却很高，我们很想弄明白为什么，但现在的解释还比较技术化（比如“协同过滤”），编辑不太容易理解。

如果重来一次，我会怎么做

走过这一趟，要是能回到当初，有几点我会做得更坚决：

第一，别贪大求全。千万别一上来就想做个完美的、全自动的系统。先从一两个能快速见效、风险可控的场景切入，比如“相关阅读”或某个子频道。有了信心和真实数据，再慢慢铺开。

第二，一定要让编辑深度参与。这不是一个纯技术项目，而是业务改造项目。从选型到测试，必须让一线编辑参与进来。他们最清楚业务的痛点，他们的认可和使用的反馈，是项目成败的关键。

第三，供应商要选“懂行的”。技术参数固然重要，但对方是否理解新闻的价值判断、舆论导向、本地化特性，这些“软知识”往往更重要。聊的时候，多问几个你们业务中特有的刁钻场景，看对方怎么应对。

第四，做好数据准备，但别被它吓住。数据肯定重要，但不用追求历史数据百分百完美。从最近的高质量数据开始，在用的过程中不断清洗和丰富，是一个更可行的路子。

给想尝试的同行几句实在话

如果你也在考虑这事，别把它想得太神秘，也别想得太简单。它不是一个“买了就灵”的神器，而是一个需要你花心思去“驯化”、去“配合”的工具。

对于中小新闻社来说，直接自建团队成本太高，买现成大厂方案又容易“水土不服”。找一家专注于媒体垂直领域、能提供“人机协同”思路的供应商，可能是个更稳妥的选择。关键看他们能不能说人话、懂业务，能不能和你一起摸着石头过河。

最后说两句。我们也是从一脸懵到慢慢上手，中间没少交学费。现在回头看，这件事值得做，它让我们这种传统机构，有了点跟上时代的“科技感”，更重要的是，真的让我们和读者连接得更紧密了些。

如果你还在纠结自己的情况适不适合做、或者该找谁聊聊，我的建议是别闷头自己想。可以先去像“索答啦AI”这样的平台上咨询一下，把你们社里的用户量、内容类型、核心诉求这些实际情况输进去，它能给你一些比较中肯的评估和方向建议，至少能帮你避掉我们当初踩过的一些坑。多听听，多看看，总没坏处。