DGraph是得物自主研发的新一代推荐系统核心引擎，基于C++语言构建，自2021年启动以来，经过持续迭代已全面支撑得物社区内容分发、电商交易等核心业务的推荐场景。DGraph在推荐链路中主要承担数据海选和粗排序功能，为上层精排提供高质量候选集。
在模型轻量化领域，量化是一种用于减少神经网络模型大小和计算量的技术，将模型参数（权重）或中间变量（激励）从高精度类型（FP32, FP16, BF16等）转换为低精度类型（int8, int4, fp8等）。 而近年来随着Transformer，MoE等架构的提出和大模型的兴起，使得神经网络模型能轻松突破几十亿甚至上万亿的规模参数，因此，我们需要一些适应于大模型的压缩技术，来降低模型的部署成本，并提升模型的推理效率。 从最初的GPTQ、AWQ等weight-only的量化算法开始，到现在LLM从训练、推理、轻量化、Agent等所有赛道都卷到飞起的时代，基于大模型的特性，在两年多时间里业内已有很多新的量化算法。
随着ES在业务场景中的使用逐渐增多，平台对ES集群的稳定性、管理、运维的压力逐渐增大，通过日常的运维情况来看，发现用户对ES的了解熟悉程度参差不齐，经常性的遇到索引创建不规范，或者参考别人索引的创建脚本进行创建索引，对索引没有一个比较清晰的认知，对索引结构的规划也寥寥无几，为此，平台使用了一些列手段来帮助用户提前合理规划模板，比如索引、模板的创建接入飞书审批流，平台侧会逐一结合业务场景和ES集群情况详细沟通确定索引或者模板结构；又比如ES内核增加业务不停服的动态扩分片能力，旨在进行不合理索引的治理提升ES集群稳定性（索引一旦创建分片是不能修改的），我们内部改动ES源码实现了不停服动态扩分片。 因此有必要从ES的索引讲起，让大家对ES的索引从概念、原理到使用有一个清晰的认知，希望日常业务场景中用到ES的同学能够抽时间读一下。当然文章避免不了存在主观的分析，大家可以在文章底部进行评论或者私聊我们，一起探讨。好了废话不多说了，现在开始介绍。
DPP依赖于算法平台的引擎服务（FeatureServer，召回引擎, 精排打分），提供“开箱即用”的召回，粗排，精排服务。采用“热加载技术”解决算法平台的工程和算法同学策略迭代效率问题，支持策略随时发布，让他们可以专注于业务逻辑，即可拥有稳定的推荐在线服务。
很高兴与大家分享现阶段 Cursor 在我的工作中的使用体验。首先是预期管理，本篇文章不会分享 x 个你可能不知道的小技巧，也不会让你拥有无需自行编码的能力，同时不涉及 Cursor 工程化方面内容。仅仅是围绕个人开发流程中的已有问题，分享如何使用 Cursor 来提升这部分的开发体验，在工作中持续保持好的节奏和状态。
得物一直重视用户体验，尤其是启动时长这一重要指标。在近期的启动时长跟进中，我们发现了在BuildingClosure 阶段的一个优化方式，成功的帮助我们降低了 1/5 的 BuildingClosure 阶段的启动耗时。Building Closure 并非工程的编译阶段（虽然它有一个building），Building Closure 是应用初次启动时会经历的阶段，因此它会影响应用的启动时长。 单就BuildingClosure阶段而言，我们观察到该阶段其中一个函数从 480ms 暴增到 1200ms 左右（PC 电脑端运行 dyld 调试统计耗时数据），我们通过优化，将耗时从1200ms降低到110ms。即使相比最开始的情况，也相当于从480ms降低到了110ms，由此可见Building Closure 优化是应用进行启动优化必不可少的一个重要手段。因此在这里我们也和各位读者进行分享，期望能够对各自项目有所帮助。
在经典的CAP理论中一致性是指分布式或多副本系统中数据在任一时刻均保持逻辑与物理状态的统一，这是确保业务逻辑正确性和系统可靠性的核心要素。在单体应用单一数据库中可以直接通过本地事务(ACID)保证数据的强一致性。 然而随着微服务架构的普及和业务场景的复杂化，原来的原子性操作会随着系统拆分而无法保障原子性从而产生一致性问题，但业务实际又需要保障一致性，为此BASE理论提出了最终一致性来解决这类问题。那么如何在跨服务、跨数据库的事务中保证数据最终一致性。
从2022年12月份OpenAI发布ChatGPT产品至今已有2年多的时间，当大家已经习惯于在对话框中与AI交互，习惯于通过各种Prompt技巧让AI更好的理解并回答我们的问题，似乎默认这就是一种比较好与AI的交互方式了。 然而，这就是我们期盼的与AI交互的形式嘛？这是一种高效的方式嘛？ 显然，这是不够的。 我们期望的是：告诉AI我们想要的目标或者任务，AI能够理解深度理解并分析我们的意图、自动的进行任务的拆解、自动的寻找可以使用的工具、自动的进行结果数据的汇总过滤、自动的呈现符合任务的展示形式。同时在任务处理过程中，可以自己完成异常的检测和修改。就如同一位优秀的同学，我们告诉他任务的目标，他可以自己寻找飞书文档、搜索网络知识、使用内部系统、自己编码验证方案可行性，并最终给一份好的解决方案。
在得物技术生态的核心地带，算法作为核心技术力量的中流砥柱，承担着推荐系统、搜索算法、AI 查验鉴别和图像识别等多个前沿且关键领域的研发重任。随着业务的快速扩展和技术的不断迭代，项目管理的重要性日益凸显。如何高效地管理算法项目，确保团队在快速变化的环境中保持高产出和高创新力，成为了我们面临的核心挑战。本文将分享得物技术部算法团队在项目管理进阶过程中的经验与思考。
我们先来探讨一个核心概念：稳定性 。想象一下，一个系统、一个物体或一个过程在受到外部干扰或内部变化时，能否如一面坚实的墙壁，屹立不倒？在信息系统的世界里，稳定性的定义就如同这面的墙壁，它确保在各种干扰面前，我们服务依旧保持可用。 然而，尽管这个定义听上去很清晰，若要用它来推动我们的稳定性建设，却显得有些模糊。因此，我们需要深入探讨如何将这一概念转化为切实可行的方法论。 我们将方法论定义为影响结果的公式，并为稳定性写下了如下公式： 稳定性 = 全局风险可见性 * 风险转化概率 * 故障可感知 * 预案可靠性 但随着实践经验的增长，再对上述公式因子进行正交分析后，我发现稳定性其实可以简化为： 稳定性 = 系统风险(概率) * 风险应对能力
