作为一个拥有庞大年轻用户群体和多元化内容资源的视频平台，B站为广告主提供了丰富的投放场景。为了实现更精准的广告投放，B站商业化技术团队深入挖掘用户、物料、场景等多方面的数据特征，并构建精细化的目标受众画像。这些数据在经过特征计算后会成为模型训练所需的训练样本，通过模型训练得到能够对广告创意进行点击率、转化率预估的深度模型。当用户进行访问时，作为广告检索引擎的一部分，在线CTR预估服务会使用深度模型，对候选集内的广告创意逐个进行点击率、转化率预估，这些数值会在精选阶段用来挑选出价值最高的广告创意返回给用户。模型预估的准确性直接决定了广告检索引擎的效果，为了确保模型训练和模型推理阶段所使用的样本数据的一致性，提供一个全面、稳定、高效的广告特征平台显得尤为重要。
随着 IT 技术与大数据的不断发展，越来越多的企业开始意识到数据的价值，通过大数据分析，可以帮助企业更深入地了解用户需求、更好地洞察市场趋势。目前大数据分析在每个业务运营中都发挥着重要作用，成为企业提升市场竞争力的关键举措之一。通常企业会构建数据湖仓，将多个数据源通过数据集成技术，汇集一起进行数据分析。由此，数据集成成为了构建数据湖仓的必经之路，然而企业在数据集成过程中却面临很多棘手问题。
传统搜索系统基于关键字匹配，在面向：游戏攻略、技术图谱、知识库等业务场景时，缺少对用户问题理解和答案二次处理能力。本文探索使用大语言模型（Large Language Model, LLM），通过其对自然语言理解和生成的能力，揣摩用户意图，并对原始知识点进行汇总、整合，生成更贴切的答案。关于基本思路，验证效果和扩展方向，可以参考正文的介绍。
前台业务同学在业务承接过程中总是抱怨大部分业务无法通过设计模式来承接，写的代码是越来越没有追求，理由是我无法预测未来的业务的发展，且设计模式更多的是在框架或中间件中使用。然而设计模式是对能力抽象出的通用模式，从哲学的角度来看世间万物皆尘土，事物都是可以抽象出共同的本质的东西。所以，难道只有底层能力可以抽象，业务逻辑部分就不可以抽象了？必须可以才是啊。 在前台业务承接过程中除了能力可以抽象，还有可以抽象出业务流程，假设在有这样一些业务场景，品搜和图搜、直播间评论和点赞、公域直播会场和私域商详透直播等等，这些各领域内的业务流程“大同小异”，因此都可以抽象出通用的业务流程节点。 但是通常在一个主干流程需要承接的场景有很多，比如直播间互动这个主干流程包括了直播间评论、点赞、求讲解、看证书、进场等等场景，所以我们需要通过主要流程进行进行多场景承接。但是这样还不够，在面对多端型多场景的情况下需要处理返回不同的数据模型。 综上所述，我们如何通过一个主干业务流程承接多个业务场景并在数据上可适配到多端型多场景，实现在服务端高质量高效率的“包接口”，下面会详细介绍。
开源之初，我们给自己定下 star 数量超过 70 个就行的心态，却意外得到了 1600 多 star，很受鼓舞～ 那一刻起，我们知道，在前端框架“泛滥”的时代，还有一些人在追随原生技术，大道至简，平淡为归。 这也让我们想起了 kk 说的那句话：所有创新都发生在事物边缘，所有的颠覆都来自边缘。 今天，我们正式对外开源 Quark 生态 的又一成员，Quarkc（Quark core 缩写）。下面来做个简单介绍吧 ：）
今天，B站就要满14岁啦！我们哔哩哔哩技术从注册账号发表第一篇文章到现在也有一年有余的时间，感谢大家一直以来的支持。在这一年多里，我们一共发表了145篇原创技术分享文章。 为庆祝哔哩哔哩14周年，我们特别整合了2022-2023年度的文章，将其分类做成内容合集，涵盖了后端、前端、运维与安全、大数据、AI、测试、业务线和音视频图像多个技术领域，沉淀了B站在UGC、OGV、直播、会员购、游戏等多个业务的技术讲解和输出。 我们真诚地希望这份知识沉淀能为诸位小伙伴们带来帮助，强烈建议一键收藏！
在一年多前，我们对外正式开源了 btrace（AKA RheaTrace），它是基于 Systrace 的高性能 Trace 工具，目前字节跳动已经有接近 10+ 产品团队使用 btrace 做日常性能优化工作。在这一年期间，我们收到很多社区以及公司内部反馈，包括使用体验、性能体验、监控数据等上都收到众多反馈，我们汇总了大家反馈的内容，主要包括以下三类： 使用体验：Windows 有着大量用户群体，但 btrace 1.0 未支持；桌面脚本依赖 Systrace 和 Python 2.7 环境，导致环境搭建十分复杂，此外手机端还依赖外部存储访问权限，在初次使用时很容易导致打断。同时产物体积庞大，网页打开速度很慢。 性能体验：大型应用插桩数量达到百万级别，性能损耗接近 100%，对性能优化工作产生一定困扰。 监控数据：在 Trace 分析过程中，有些信息是缺失的，并不知道耗时原因，比如目前 Trace 中仅包含 synchronized 锁信息，缺少 ReentrantLock 等其他锁信息，同时渲染监控只有部分系统关键路径信息，缺少业务层信息。
早在 2012 年淘宝开始无线化探索时，店铺页面就作为一个重要的业务形态出现在「淘宝APP」之中。店铺是电商交易核心链路中的重要一环，也是商家运营私域流量的一个重要载体。通过店铺平台，商家可以个性化装修自己的店铺页面，运营自己的会员粉丝，与消费者之间创造更多的连接，挖掘更大的价值。因此，店铺的开放属性也一直是店铺业务的重要能力之一。伴随着店铺产品的迭代升级、运营策略的升级、二方业务的不断接入、以及开放能力的增强和店铺定制化程度的提升，店铺框架在技术侧也在不断的演进升级中。 最早起的无线店铺形态，页面结构比较简单，装修模块只支持官方定制，无法开放给外部开发者进行定制。 店铺装修能力探索。提供了一套模块开放的 JSON 协议，店铺装修模块具备了一定的开放能力。但是 JSON 协议为非标准化协议，可读性差，难以组件化，无法实现复杂交互。 店铺样式动态化。基于高性能动态化框架 Weex 进行开发，对接前端完善的工具链和研发模式，符合前端开发习惯，有助于提升 ISV 生产力，同时支持动画、支持轻量级的组件扩展和 API 扩展，交互体验和端侧能力得到巨大提升。
