得物的发布采用固定的双周迭代，在此基础上如有紧急的需求可以申请中间插入单周迭代版本，在以往的迭代发布过程中从开始准备灰度发布事宜到主要应用市场上架时间跨度较长，站在业务的角度像AB、埋点、新特性反馈的时间太长。 最近我们针对发布流程做了整个链路的优化，通过调整发布节奏、提升双端发布系统自动化能力等措施，帮助业务触达用户效率(每版本提前1天)，下文将详细讲述此过程。
大模型的上下文长度是指我们在使用大模型的时候，给大模型的输入加上输出的字符（Token）总数，这个数字会被限制，如果超过这个长度的字符会被大模型丢弃。目前开源的大模型上下文长度一般不长，比如 Llama 2 只有 4K，Code-Llama 系列因为需要输入代码，扩展到了 16K。闭源系列模型的提供了更长的上下文长度，比如 OpenAI 在其最新模型 GPT-4 Turbo 中提供了 128K 的上下文长度，Anthropic 的 Claude 2.1 模型提供了 200K 上下文长度。 一些场景需要较长上下文，比如，文档翻译需要将整篇文档输入给大模型进行翻译，长文档内容抽取需要大模型读取整篇长文档进行内容抽取，会议内容总结则需要给大模型输入会议聊天记录进行总结等。 想要得到一个长上下文的大模型，一般有两种途径。一种是大模型在初始阶段被设置为长上下文，然后经过预训练，指令微调，对齐训练等方式得到一个长上下文大模型。另外一种方式是选择已经训练好的大模型，通过技术改造扩展其上下文长度，然后再进行微调训练得到长上下文模型。
OpenAI 发布的视频生成模型 Sora(https://openai.com/sora)，能根据文本生成长达一分钟的高质量视频，理论上支持任意分辨率，如 1920x1080 、1080x1920 ，生成能力远超此前只能生成 25 帧 576x1024 图像的顶尖视频生成模型 Stable Video Diffusion。 一起公布的，还有一篇非常简短的技术报告，报告大致介绍了 Sora 的架构及应用场景，并未对模型的原理做过多的介绍。技术报告链接：https://openai.com/research/video-generation-models-as-world-simulators 笔者参考了大量的资料，试着深入理解 Sora 的技术原理，最终将 Sora 生成视频的原理总结
在数字产品的数据分析实践中，手动代码埋点方式因其精确性和定制化的优势长期被许多组织采用，但随着业务快速发展和迭代需求的增加，传统手动埋点方法的时间消耗、一定的技术门槛和较高的维护成本成为研发角色的负担。另外，全埋点的埋点方式提供了全面数据捕捉的解决方案，但其带来的海量数据处理难题和潜在的隐私风险也不容忽视。 原有商家后台通过手动埋点方式实现业务埋点的收集。
当谈到移动应用程序的体验时，页面启动速度是其中至关重要的一点，更快的页面展示速度确保应用程序可以迅速加载并响应用户的操作, 从而提高用户使用 App 时的满意度。在页面启动的整个流程中，随着 UI 复杂度的上升，布局的 Inflate 耗时占据了相当一部分关键的比例，本文分享得物自身在页面布局构建耗时优化方案上的探索历程。
2023 年 12 月 28 日，为期两天的顶级技术盛会 QCon 全球软件开发大会暨十五周年大会在上海顺利开幕。本次大会以“启航·AIGC 软件工程变革”为主题，策划了 LLM 时代的性能优化、加速声称是 AI 落地的最佳实践、GenAI 和通用大模型应用探索等 20 余个演讲专题。 我分享点 Java 相关内容。在得物，使用 Java 的同事们占据了相当大的比例，他们是我们业务线的中坚力量。我希望今天所分享的内容能对大家有所帮助，助力于公司价值的创造。 参加 QCon 大会时有幸遇见 Azul 技术总监。他曾任职甲骨文 OFM 中间件团队，担任 CGBU 技术负责人，在 Java 界非常有分量。与大佬针对 ZingJDK 以及 JVM 进行了深入交流后，今天把交流所得分享给大家。
在 Monorepo 大仓模式中，我们把组件放在共享目录下，就能通过源码引入的方式实现组件共享。越来越多的应用愿意走进大仓，正是为了享受这种组件复用模式带来的开发便利。这种方式可以满足大部分代码复用的诉求，但对于复杂业务组件而言，无论是功能的完整性，还是质量的稳定性都有着更高的要求。源码引入的组件提供方一旦发生变更，其所有使用方都需要重新拉取 master 代码，然后构建发布才能使用新功能，这一特性对物料组件、工具组件以及那些对新功能敏感度较低的业务组件来说是可以接受的，但对于新功能敏感度高的复杂业务组件来说，功能更新的不及时会直接面临着资损风险。这类复杂组件也往往面临着频繁且快速的迭代发布，这样一来对于组件使用方而言不光需要订阅组件更新，而且需要做到及时发布升级才能规避风险，因此只用源码引入的方式来共享复杂业务组件是耗费精力且不合适的。
在日常的技术支持过程中，经常会遇到如下玄学问题的咨询： 从监控上看，进程资源占用正常。 从监控上看，服务流量平稳，没有流量突增。 从监控上看，线程池状态正常，没有瓶颈。 但是，在上述条件下，上游调用方还是时不时反馈偶现 Thread pool is EXHAUSTED！ 接下来笔者来把这个问题系统梳理下，帮助大家厘清这个问题的本质。
在 B 端研发过程中，产品原型在产品需求文档中起着重要的作用。然而，在实际的开发过程中，我们发现了一些问题。首先，在需求评审阶段，有些产品需求文档可能缺少原型或者原型与研发团队的规范不一致，这需要研发同学与产品同学沟通补充原型图或者按照研发团队的规范进行绘制，这增加了产品同学和研发团队之间的沟通成本以及增加了产品同学的学习成本。其次，在业务验收阶段，开发的页面或效果可能不符合业务侧的期望，这又需要产品和研发团队反复沟通，导致业务侧对效果的感知链路过长。此外，产品同学还需要花费大量时间来根据需求文档描述输出样式固定的原型文档。 为了解决这些问题，我们想到了利用产品在『市场需求文档（MRD）——产品需求文档（PRD）——页面（Page）』沟通过程中沉淀的『共识』，即产品需求文档中的页面描述。我们可以利用大语言模型强大的推理能力，将这些共识『翻译』成符合研发团队规范的页面，从而减少沟通成本并缩短业务侧对效果的感知链路。另外，为了减少产品在不同界面切换频次，可以让产品利用浏览器插件在 PRD 文档页面进行文字选择，然后唤起原型生成工具生成页面原型和修改原型。本文主要介绍了我们利用大模型辅助产品
