得物大模型训练与推理平台上线几个月后，我们与公司内部超过 10 个业务领域展开了全面的合作。在一些关键业务指标方面，取得了显著的成效，例如： 效率相关部门的合作，多维度打标总正确率取得 2 倍以上提升。利用大模型开辟了新的业务，提升了效率部门的人力产出。 某业务订单 NPS 的识别准确率由 70% (PROMPT 方式)提升到 85% (平台训练大模型) 。 本文基于我们与业务合作的经验，将分享如何在大模型平台上实现业务效果指标提升。我们将以大模型平台上从训练到推理部署的全链路流程为基础，提供优化思路，最终达成业务效果指标的提升。这些流程包括大模型选择、数据准备、大模型训练、效果评估和推理部署。
由于多个域共建情况比较多，一方面应用随业务发展在不断扩展，各个应用代码复杂度会不断增加，如何准确、全面判定代码修改影响范围会越来越重要，另一方面共建过程中如果不能准确预估出各域共同改动所带来的影响面，就会存在测试遗漏；如果各域信息不对称可能会存在一方改动另外一方无感知，导致评估不到位带来一些影响。基于以上背景商家域引入精准测试平台实践，可以帮助QA扫描出每个版本开发改动的接口范围，并且可以有效地提高测试的覆盖率和可靠性。 基于第二季度在商家地址专项上探索实践了精准测试并取得了一定的收益；第三季度扩大规模化实践，因此根据商家核心业务需要，选择了核心的 4 个应用，并沉淀了持续几个迭代的过程和结果数据。以下是几个迭代下来使用精准测试平台的一些实践数据和心得。
得物效率前端所在的效率工程为提升企业协作效率而生，面临大量的 PC 侧的中后台应用场景。 在之前的微信公众号《得物效率前端微应用推进过程与思考》中详细介绍了效率前端推进微应用落地的思路和部分效果。 这篇文章将着重介绍得物效率前端微应用推进中，微前端的研发效率遇到的挑战和解决方案。
目前得物的商品分为三种类型，分别是：新品、商品、草稿。但是只有商品是可售卖的，新品和草稿都不是可售卖的。 新品有很多种创建的渠道，商品可以由新品选品通过后由系统自动生成，也可以由运营直接创建。而商品草稿是在商品被编辑后创建而来，草稿在更新审核通过后，会重新覆盖已有的商品信息。
在当今的软件开发领域，性能问题是一个永不过时的挑战。为了解决这一挑战，开发人员需要深入了解他们的应用程序运行时的性能，并快速定位高耗时问题。线程剖析是一种强大的工具，通过采集和计算运行时线程栈，可以帮助开发人员更好地理解和解决性能问题。本文将深入探讨线程剖析的基本思想和实现思路，以及客户端和服务端的设计。
知识抽取通常指从非结构化文本中挖掘结构化信息，如语义信息丰富的标签、短语等。在业界被广泛使用的场景包括内容理解、商品理解，从用户生产的文本信息中挖掘有价值的标签打在内容或商品上。 知识抽取通常伴随着对所抽取标签或短语的分类，通常被建模为命名实体识别任务，通用的命名实体识别任务就是识别命名实体成分并将成分划分到地名、人名、机构名等类型上；领域相关的标签词抽取将标签词识别并划分到领域自定义的类别上，如系列（空军一号、音速 9）、品牌（Nike、李宁）、类型（鞋、服装、数码）、风格（ins 风、复古风、北欧风）等。 为描述方便，下文将信息量丰富的标签或短语统称为标签词。
得物的服务端监控是比较全面和有效的，除了上报原始日志数据，还通过数据分析制定线上告警机制，调用链路分析，而针对前端项目这一块，还是不够全面的。对前端线上问题感应不及时，靠人肉发现，没有告警机制等问题，所以就有个前端监控这个项目。前端监控也确实很有必要，我们需要对线上的页面有个全面的把控，而至于怎么做监控，做数据上报，以及数据分析，如何针对监控数据分析出有用的核心链路的告警等也能有个全面的认识。本文主要是介绍得物针对监控做了哪些事情以及对前端底层监控手段做个总结。
一年前的《彩虹桥架构演进之路》侧重探讨了稳定性和功能性两个方向。在过去一年中，尽管业务需求不断增长且流量激增了数倍，彩虹桥仍保持着零故障的一个状态，算是不错的阶段性成果。而这次的架构演进，主要分享一下近期针对性能层面做的一些架构调整和优化。其中最大的调整就是 Proxy-DB 层的线程模式从 BIO 改造成了性能更好的 NIO。下面会详细介绍一下具体的改造细节以及做了哪些优化。
随着企业数据规模的增长，数据的价值变得越来越重要。然而，传统的数据库在承载大量数据时面临挑战，需要高效有序的维护。因此，建立高效的数据仓库成为了企业决策和管理的基石，但现代技术的背景下，数据管理和保护仍然存在着重要挑战。 为了解决这些挑战，数据分层成为了数仓建设中不可或缺的步骤之一。通过对数据的分层整理，不同的数据可以被合理地分类，方便企业快速进行数据分析和决策。 在实际应用中，数据分层需要进行灵活而有效的规划和设计，并结合相关的技术和工具进行管理和监控。只有这样，企业才能提高决策和管理的效率，增强市场竞争力。
