随着大模型应用持续火热,应用门槛也越来越低,去年底开始我们利用少部分精力做了一些 AI 探索和实践,并完成了业务所在垂直领域答疑机器人产品的上线。这里主要从普通使用者的视角,把一边学习一边实践的过程记录下来,和大家一起学习交流。 本文定位无门槛。本文受众主要是入门玩家,但对大模型感兴趣想做一些小工具,或者在平常的业务工作中希望使用大模型来提效的读者。
线上问题的定位与优化是程序员进阶的必经之路,常见的问题定位手段有日志排查、分布式链路追踪和性能分析等,其中日志排查主要用来定位业务逻辑问题,分布式链路主要用来定位请求链路中具体是哪个环节出了问题,而如果服务本身的性能出了问题,如一段时间复杂度高的代码引发了CPU占比飙升、内存泄漏等,则需要依赖性能分析工具来帮我们定位此类问题。
随着互联网业务的快速发展,系统架构日益复杂,对下游资源(如数据库)的保护成为系统稳定性的重要环节。传统的限流方式往往依赖于人为设定的固定阈值,难以应对动态变化的业务需求,容易造成资源浪费或系统过载。为此,本文介绍了KLimiter自适应限流器,它可以基于下游资源(如db)水位,对多个不同优先级的上游入口进行自适应调流。
截至 2023 年底,字节跳动内部微服务的数量超过了 30 万,而且这个数字还在快速的增长当中,每个季度仍然会新增上万个微服务。伴随着海量的微服务,微服务过微带来的编解码、序列化、网络和服务治理开销过大问题也愈加凸显,在一些性能敏感、QPS 大的的服务上急需优化,于是极致的微服务合并方案合并编译应运而生。 目前公司内采用合并编译方式合并的服务超过 300 万 core,取得的 CPU Quota 收益超过 40 万 core,接口时延根据包大小有 2-15 ms 不等的优化。
程序员工作的终极意义,就是干掉复杂度,用一套通用的方法解决大部分问题。在大模型时代,这个通用的方法就是——Prompt 工程。作为用好大模型最重要的武器,Prompt 的好坏对模型效果有着决定性的影响。 然而,网络上大量相关文章多是罗列“Prompt 工程” 中的若干技巧,少有体系化的总结,让人看完依然不知道该如何入手。本文希望结合腾讯工程师在 “Prompt 工程” 中的实践经验,更加体系化地对 “Prompt 工程” 进行梳理,希望可以一步步地帮助大家用好大模型,人人都是 Prompt 工程师。
视频业务作为B站内容生态的心脏,承载了海量的视频内容和用户互动。它不仅是用户获取信息、享受娱乐的窗口,更是UP主展示创意、分享知识的舞台。在设计和实现视频系统时,我们致力于平衡用户体验、内容分发的效率,同时确保平台的稳定性和可扩展性。 在这个过程中,稿件生产扮演着至关重要的角色。我们通过提供强大的视频上传、编辑和管理工具,满足创作者的需求,让他们能够轻松地制作和分享内容。同时,我们实施严格的内容审查和版权管理措施,以保障社区生态的健康发展。我们向创作者提供更好的服务,向B站内容生态供给更多的内容。