我为什么离开新浪微博部门

最近我因为离职的事情而弄得很揪心。

从新浪离职对于我而言是个痛苦的决定。这意味着,我半年来在新浪微博项目上所付出的努力全部白费,而且我还担心,此举动会给别人留下心浮气躁的印象。

还记得刚进新浪的时候,我是一名开发工程师。当时,我给自己定的计划是:先从开发着手熟悉业务,接下来的目标是做公司的底层系统研发。

后来有一天,我去朋友的一家小公司看了一圈,结果被他们的一名人力资源部门负责人一眼看中,一定要拉我过去做服务部门的技术人员。这让我有一点心动。但就在此时,新浪微博被独立出来成立一个新部门,我被安排做系统研发,这似乎又与我当初设想相符。两条岔道在我面前铺开,等着我的抉择。最后我再三考虑的结果是,离开新浪。

对薪水的不满意,是我离开的首要原因。我觉得自己在新浪的项目组中已经有了足够的分量,并不是冒然向上级漫天开价。但是我先后两次提薪的请求都被回绝。后面一次拒绝我的理由是,“你是很出色,没错,但是公司有薪资制度约束”.

但是,我不喜欢继续呆在新浪还有别的原因。新浪微博项目在公司内部非常受重视,对技术人员来说,产品需求自上而下层出不穷,还要频繁应对来自客户的突发事件。让我感觉很累。

产品需求一般是由微博项目总监S和微博项目产品经理M确定的,用户、底层开发人员基本没有发言权。于是,这中间就产生了一个问题--确定需求的S和M基本不关心技术架构,他们都是在需求确定之后才讨论实现方案。所以,项目按照上级拍脑袋定下的时间表再往前推进。底层开发人员忙于新需求开发、现有的错误修正,基本是没时间去考虑整体架构和流程的改进。在这样一个以结果为导向的工作环境中,原本是做在前面的“重构”工作,现在往往因为代码改不下去了才开工,以至于平时代码维护都有点困难。

2009年4月,公司高层拍板搞社区,最初设计了“SNS+微博”的组合构架,新浪总裁曹国伟试用以后认为“这么复杂,我都不会用,怎么能让用户接受”,最终只保留了微博这一项。年前的时候,产品部的P总貌似还说过,微博上不会做“偷菜”,不会做游戏平台,不过现在这些内容都已经上线了。对此,公司内部人员都在议论,新浪微博最后还是会演变成社区平台。现在微博功能已经相当繁杂,后台技术支持也混乱一团,很难想象以这种方式做到社区平台会是什么样子。

当然,上面说的问题,是可以改进的。比如大家一起头脑风暴,讨论产品需求。尽量在项目前期明确一个大家都没有任何意见的方案。虽说Facebook的产品人员是技术出身,但我觉得新浪还是应该加大一线技术人员在产品设计中的分量。

但我又觉得,新浪原本就不是一家做技术的公司。据我在前段时间得知,新浪两年前还在用Windows系统的服务器,这显然不太专业。新浪网是靠新闻起家的,公司有个很神秘的人物,微博上名叫“老沉”,真名是陈T,看互动百科上对他的介绍就知道新浪网是如何起家的,擅长做什么,习惯怎么做。新浪的运营部门权力相当大,博客项目改版之前,其运营页面由运营部门开发维护,跟个人微博页面完全是两套模式。现在两者页面统一了,新浪微博难以保证它在产品需求上的独立性。这对技术支持而言是一个难点。

而且,互联网公司都得面对有关部门的审核问题。微博上信息传递性强,所以公司对后台审核系统的要求很高。我喜欢带着自己的感情去工作,我喜欢做自己觉得很好、有必要的功能;而对于不喜欢做的功能,我下意识地把时间往后排或者跟产品人员讨论。从职业道德上讲,这是不敬业的行为。但是,新浪微博的审核功能确实加大了开发的工作量,甚至在设计系统架构时需要考虑审核需求。我很不喜欢这样。

从去年8月开始内测到现在,将近1年的时间都过去了,尽管人气迅速攀升,但新浪微博至今还不是一款正式上线的产品。听说,公测将会无限期延长下去。2009年夏天,曾有某部门提出“微博产品的上线也应实行审批准入机制”.在相关管理办法未出台前,后台审核只能摸着石子过河,没有参照标准,但一旦越界就会受到处罚。2009年10月开始,为了保护刚刚萌芽的微博产品,公司不惜采取最严厉的监管等级,技术人员的压力非常大。

在新浪工作的半年,我最深刻的感触是,技术完全为产品需求服务。很大程度上,这个现实熄灭了我对技术的追求,有悖我从事IT技术行业的初衷。所以我最终放弃了新浪。

资源下载链接为: https://pan.quark.cn/s/140386800631 通用大模型文本分类实践的基本原理是,借助大模型自身较强的理解和推理能力,在使用时需在prompt中明确分类任务目标,并详细解释每个类目概念,尤其要突出类目间的差别。 结合in-context learning思想,有效的prompt应包含分类任务介绍及细节、类目概念解释、每个类目对应的例子和待分类文本。但实际应用中,类目和样本较多易导致prompt过长,影响大模型推理效果,因此可先通过向量检索缩小范围,再由大模型做最终决策。 具体方案为:离线时提前配置好每个类目的概念及对应样本;在线时先对给定query进行向量召回,再将召回结果交给大模型决策。 该方法不更新任何模型参数,直接使用开源模型参数。其架构参考GPT-RE并结合相关实践改写,加入上下文学习以提高准确度,还使用BGE作为向量模型,K-BERT提取文本关键词,拼接召回的相似例子作为上下文输入大模型。 代码实现上,大模型用Qwen2-7B-Instruct,Embedding采用bge-base-zh-v1.5,向量库选择milvus。分类主函数的作用是在向量库中召回相似案例,拼接prompt后输入大模型。 结果方面,使用ICL时accuracy达0.94,比bert文本分类的0.98低0.04,错误类别6个,处理时添加“家居”类别,影响不大;不使用ICL时accuracy为0.88,错误58项,可能与未修改prompt有关。 优点是无需训练即可有较好结果,例子优质、类目界限清晰时效果更佳,适合围绕通用大模型api打造工具;缺点是上限不高,仅针对一个分类任务部署大模型不划算,推理速度慢,icl的token使用多,用收费api会有额外开销。 后续可优化的点是利用key-bert提取的关键词,因为核心词语有时比语意更重要。 参考资料包括
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值