云
公众号

云加社区

腾讯云官方社区公众号,汇聚技术开发者群体,分享技术干货,打造技术影响力交流社区.

962 篇已收录文章

这个来源的文章

按发布时间排序

微信社招三年,我想说\n \n\n\n\n \n核心就是一句话——做些业务需要的事儿。\n\n不同于互联网常见的一级接口人、二级接口人、开发、测试的纵深型开发团队,微信的开发团队大多层级简单,需求定位时传统团队两跳三跳的场景,微信可能一跳就能定位到。\n\n以平台开发为例,每个人都在自己的方向进行探索。在一个方向上,自己兼任产品、研发、测试、客服。这种情况下对人员要求也会高一点,使关注点不仅局限于 if else、代码结构、设计模式、逻辑划分、平台架构。还需要关注产品迭代的整个生命周期,以及规划后续的方向,为业务产生最大的价值。\n\n这种小团队模式,对业务的要求就是要聚焦。体现在每次的需求实现前,都需要仔细想清楚,是否真的需要这个功能,是否真的给业务会有提升。\n\n对于业务的变化要感知敏感,提前作出反应,更加具有预见性。从业务的角度去评估后续的发展,结合经验去判断在后续方向业务靠拢,提前布局。理想情况下应该是,当业务有需求的时候,我们能够提供相应的能力去覆盖。当然这个会比较依赖于个人的判断力,实践是检验真理的唯一方式,通过不断的迭代,提升判断力。\n\n对待自己做的事,要像对待一个产品一样去做。个人理解的产品思维就是——细节,通过打磨细节让使用者理解到开发者的心思。\n\n新技术的不断兴起,对开发人员提出了更高的技术敏感度要求。我们要能够更快地对新技术做出反应,并找出落地场景,最终实现——给业务带来新的增量。\n\n新人在团队内部开展工作时,对于内部的一个应用,抑或是一个框架,一段代码,能够做到熟练使用,可以通过文档、上下文进行了解。写好文档既体现了良好的工程规范,也是方便他人,减少不必要的额外沟通。\n\n走过新人这一阶段,你会发现整体的工作内容已经比较完整,而且能够串联起来,用最小的投入换取最大的收益。\n\n只聚焦在技术原理、工程实现,而忽视业务需求的工程师或团队,可能都无法在这个时代走得长久。

阅读全文 :微信社招三年,我想说\n \n\n\n\n \n核心就是一句话——做些业务需要的事儿。\n\n不同于互联网常见的一级接口人、二级接口人、开发、测试的纵深型开发团队,微信的开发团队大多层级简单,需求定位时传统团队两跳三跳的场景,微信可能一跳就能定位到。\n\n以平台开发为例,每个人都在自己的方向进行探索。在一个方向上,自己兼任产品、研发、测试、客服。这种情况下对人员要求也会高一点,使关注点不仅局限于 if else、代码结构、设计模式、逻辑划分、平台架构。还需要关注产品迭代的整个生命周期,以及规划后续的方向,为业务产生最大的价值。\n\n这种小团队模式,对业务的要求就是要聚焦。体现在每次的需求实现前,都需要仔细想清楚,是否真的需要这个功能,是否真的给业务会有提升。\n\n对于业务的变化要感知敏感,提前作出反应,更加具有预见性。从业务的角度去评估后续的发展,结合经验去判断在后续方向业务靠拢,提前布局。理想情况下应该是,当业务有需求的时候,我们能够提供相应的能力去覆盖。当然这个会比较依赖于个人的判断力,实践是检验真理的唯一方式,通过不断的迭代,提升判断力。\n\n对待自己做的事,要像对待一个产品一样去做。个人理解的产品思维就是——细节,通过打磨细节让使用者理解到开发者的心思。\n\n新技术的不断兴起,对开发人员提出了更高的技术敏感度要求。我们要能够更快地对新技术做出反应,并找出落地场景,最终实现——给业务带来新的增量。\n\n新人在团队内部开展工作时,对于内部的一个应用,抑或是一个框架,一段代码,能够做到熟练使用,可以通过文档、上下文进行了解。写好文档既体现了良好的工程规范,也是方便他人,减少不必要的额外沟通。\n\n走过新人这一阶段,你会发现整体的工作内容已经比较完整,而且能够串联起来,用最小的投入换取最大的收益。\n\n只聚焦在技术原理、工程实现,而忽视业务需求的工程师或团队,可能都无法在这个时代走得长久。

有点离谱\n \n\n \n \n \n人工智能正在经历又一轮“骗子来了”曲线周期,业界、从业者、资本对大模型的追捧已经到了非理性的热度,泡沫越吹越大,在 AGI 拐点到来之前,更可能出现的拐点是大模型泡沫在阳光下炸裂,空中划过一道美丽的彩虹,留下一地鸡毛。\n\n年初信誓旦旦的 AI 工程师会砸程序员饭碗,随着新闻造假、 OpenAI 、谷歌新模型表现不及预期,在2024的年底,或许可以直接给出结论——AI的进展,就还好,没有长到大部分人的心趴上。\n\n更务实的结论是:在可预见的未来,AI做不到替代程序员,它只能当 Copilot,连主驾驶都上不去。当前及未来将要被取代的程序员,反而是那些不能熟练使用 AI 工具的古法程序员。\n\n腾讯内部有一款 AI代码助手应用,已经在业务中广泛使用,比如腾讯医疗健康团队经过一年的应用,实现了100%覆盖率且保持活跃使用。目前,代码补全周生成率达39.81%,周采纳率 31.63%,周活跃率 96.82%,团队近四成代码由腾讯云 AI 代码助手编写。\n\n与去年同期对比,团队人均交付需求个数提升了18.18%,人均编码行数提升了41.34%,人均缺陷数降低31.50%。\n\n在使用中程序员们还发现,那些导致低效的用法往往是:函数、变量命名不规范;代码缺少注释、注释不清晰;代码实现逻辑复杂;复制大块重复代码。而这些低效用法背后,恰恰也是因部分技术同学代码规范、工程能力方面的短板所导致的连锁反应。\n\n这说明什么?说明哪怕是在应用层面已经功能完备的 AI 产品,仍旧被最为经典的计算机原理、工程规范这些最硬核的底层逻辑所制约。\n\n在腾讯内部,AI代码助手不论是针对用户反馈的 Bad Case 的模型迭代研发到正式上线发布,或者基于需求的产品功能迭代开发到正式上线发布均控制在双周时间内完成一个迭代开发周期。\n\n目前,这款产品也已经对外发布,企业、个人均可免费使用,地址:腾讯云 AI 代码助手(https://copilot.tencent.com/)\n\n与其焦虑AI对我们带来的威胁,不如大胆地拥抱它,如果在当前的技术状态下发现自己真的将被 AI 轻易给替代了,那反而才是一个值得我们深度思考自我规划,并抓紧提升自我能力的时刻。

阅读全文 :有点离谱\n \n\n \n \n \n人工智能正在经历又一轮“骗子来了”曲线周期,业界、从业者、资本对大模型的追捧已经到了非理性的热度,泡沫越吹越大,在 AGI 拐点到来之前,更可能出现的拐点是大模型泡沫在阳光下炸裂,空中划过一道美丽的彩虹,留下一地鸡毛。\n\n年初信誓旦旦的 AI 工程师会砸程序员饭碗,随着新闻造假、 OpenAI 、谷歌新模型表现不及预期,在2024的年底,或许可以直接给出结论——AI的进展,就还好,没有长到大部分人的心趴上。\n\n更务实的结论是:在可预见的未来,AI做不到替代程序员,它只能当 Copilot,连主驾驶都上不去。当前及未来将要被取代的程序员,反而是那些不能熟练使用 AI 工具的古法程序员。\n\n腾讯内部有一款 AI代码助手应用,已经在业务中广泛使用,比如腾讯医疗健康团队经过一年的应用,实现了100%覆盖率且保持活跃使用。目前,代码补全周生成率达39.81%,周采纳率 31.63%,周活跃率 96.82%,团队近四成代码由腾讯云 AI 代码助手编写。\n\n与去年同期对比,团队人均交付需求个数提升了18.18%,人均编码行数提升了41.34%,人均缺陷数降低31.50%。\n\n在使用中程序员们还发现,那些导致低效的用法往往是:函数、变量命名不规范;代码缺少注释、注释不清晰;代码实现逻辑复杂;复制大块重复代码。而这些低效用法背后,恰恰也是因部分技术同学代码规范、工程能力方面的短板所导致的连锁反应。\n\n这说明什么?说明哪怕是在应用层面已经功能完备的 AI 产品,仍旧被最为经典的计算机原理、工程规范这些最硬核的底层逻辑所制约。\n\n在腾讯内部,AI代码助手不论是针对用户反馈的 Bad Case 的模型迭代研发到正式上线发布,或者基于需求的产品功能迭代开发到正式上线发布均控制在双周时间内完成一个迭代开发周期。\n\n目前,这款产品也已经对外发布,企业、个人均可免费使用,地址:腾讯云 AI 代码助手(https://copilot.tencent.com/)\n\n与其焦虑AI对我们带来的威胁,不如大胆地拥抱它,如果在当前的技术状态下发现自己真的将被 AI 轻易给替代了,那反而才是一个值得我们深度思考自我规划,并抓紧提升自我能力的时刻。

说个暴论\n \n \n \n\n这个暴论需要叠加很多 buff,但我还是想说:建议个人和小团队不要碰大模型训练!\n\n1 、哪些人是例外?\n\n如果你为了发论文尽快毕业,那该练还是得练,还要变着花样练。\n\n如果你是全栈的超级个体,能解决数据、模型、推理和资金等全链路,那么请勇敢冲。\n\n本文基本只讨论 LLM 和 VLM。除此之外,我想象不到个人和小团队还有什么理由去训练大模型。\n\n 2 、不训练大模型怎么办?\n\n企业私有数据,不能调用外部 API,不训练怎么办?\n\n做好开源 LLM+RAG 的部署。在没有触及 RAG 的性能边界之前,不要微调模型。\n\n常见方案是对一些图片 or PDF 文件做好 OCR,转为 Markdown,在每次问答前,将需要的上下文塞给 LLM,拿到的结果就不会太有问题。\n\nRAG 自带在线持续学习的特性,非常适合业务场景。\n\n开源LLM对一些特定领域的效果非常差,怎么办?\n\n还是得先试试 RAG,不行就试试 In-context Learning,在上下文中,教 LLM一些领域知识。\n\n128K 的上下文长度非常关键! 这个可以降低你 RAG 的门槛,以及提高 LLM 对领域知识的掌握。\n\n我真的很难想象,现在还有什么特殊的领域,LLM 一点办法都没有。\n\n有推荐的方案么?\n\n如果你能调用外部 API,那么就根据业务要求,选择性价比最高的一款。\n\n能不自己部署模型,就不自己部署。硬件成本和维护成本,对于小团队来说可能是压垮骆驼的一座大山。\n\n选择调用 API 的时候,你会发现,全世界最聪明的人和最听话的 AI,都在抢着为你服务。你完全不用管有几台服务器,你可以在任意时间,随便拉高并发量。随心切换更强的模型,或者更便宜的模型。\n\n这里给腾讯云混元大模型做个推荐,它的性价比和能力就很不错。\n\n大厂基座模型团队之外的 AI 人,需要先了解现有 LLM 的性能边界,敏锐地分辨出现有模型能力和过去方案的差异,能否给当前的业务带来新的变化,然后快速解决现有业务的难题。\n\n不要在低收益的赛道上无意义地投入,错位竞争,降维打击,也许更有效。\n\n本文授权自知乎答主强化学徒,原文见:https://zhuanlan.zhihu.com/p/5851457581

阅读全文 :说个暴论\n \n \n \n\n这个暴论需要叠加很多 buff,但我还是想说:建议个人和小团队不要碰大模型训练!\n\n1 、哪些人是例外?\n\n如果你为了发论文尽快毕业,那该练还是得练,还要变着花样练。\n\n如果你是全栈的超级个体,能解决数据、模型、推理和资金等全链路,那么请勇敢冲。\n\n本文基本只讨论 LLM 和 VLM。除此之外,我想象不到个人和小团队还有什么理由去训练大模型。\n\n 2 、不训练大模型怎么办?\n\n企业私有数据,不能调用外部 API,不训练怎么办?\n\n做好开源 LLM+RAG 的部署。在没有触及 RAG 的性能边界之前,不要微调模型。\n\n常见方案是对一些图片 or PDF 文件做好 OCR,转为 Markdown,在每次问答前,将需要的上下文塞给 LLM,拿到的结果就不会太有问题。\n\nRAG 自带在线持续学习的特性,非常适合业务场景。\n\n开源LLM对一些特定领域的效果非常差,怎么办?\n\n还是得先试试 RAG,不行就试试 In-context Learning,在上下文中,教 LLM一些领域知识。\n\n128K 的上下文长度非常关键! 这个可以降低你 RAG 的门槛,以及提高 LLM 对领域知识的掌握。\n\n我真的很难想象,现在还有什么特殊的领域,LLM 一点办法都没有。\n\n有推荐的方案么?\n\n如果你能调用外部 API,那么就根据业务要求,选择性价比最高的一款。\n\n能不自己部署模型,就不自己部署。硬件成本和维护成本,对于小团队来说可能是压垮骆驼的一座大山。\n\n选择调用 API 的时候,你会发现,全世界最聪明的人和最听话的 AI,都在抢着为你服务。你完全不用管有几台服务器,你可以在任意时间,随便拉高并发量。随心切换更强的模型,或者更便宜的模型。\n\n这里给腾讯云混元大模型做个推荐,它的性价比和能力就很不错。\n\n大厂基座模型团队之外的 AI 人,需要先了解现有 LLM 的性能边界,敏锐地分辨出现有模型能力和过去方案的差异,能否给当前的业务带来新的变化,然后快速解决现有业务的难题。\n\n不要在低收益的赛道上无意义地投入,错位竞争,降维打击,也许更有效。\n\n本文授权自知乎答主强化学徒,原文见:https://zhuanlan.zhihu.com/p/5851457581