Everything you care about in one place
Follow feeds: blogs, news, RSS and more. An effortless way to read and digest content of your choice.
Get Feedertech.youzan.com
有赞技术团队
Get the latest updates from 有赞技术团队 directly as they happen.
Follow now 98 followers
Latest posts
Last updated over 2 years ago
知识库检索匹配的服务化实践
over 2 years ago
一、背景 知识库是企业经营过程中的面向客户和内部员工的知识沉淀文档库，里面包含各类教程、问答、案例等，知识库的检索匹配是自然语言处理(NLP)中一个重要的基础问题，本质是进行文本语义的相似度计算，也就是语义匹配，我们很多领域的任务都可以抽象为文本匹配检索任务，例如检索引擎、智能客服、知识检索、信息推荐等领域。 知识库检索匹配可以概述为：给定一个query和大量候选知识库的文档，从这些文档中找出与用户输入query最匹配的TopK个文档。 二、架构流程 2.1、整体架构 2.2、请求链路 三、算法模型 3.1、DSL改写 检索优化第一步：DSL改写，接手前业务方自己已经对检索结果做过优化，调整不同字段的匹配权重，这一方法的已经难以继续优化。从知识运营的角度出发，在用户检索时，将运营认为重要的文档推到前面，由于文档之间互相有链接引用，可以使用PageRank算法给每个文档计算重要分(PR值)。 PageRank的核心思想是，被引用次数越多的文档越重要。算法原理如下，假设只有四个网页ABCD，以AB间的箭头为例，代表可以从B网页跳转到A网页，对B即一次引用（链出），对A则一次被引用（链入）。L(B) 表示B网页的链出数量，PR(B)表示B网页的PageRank分数。 假设所有文档的初始PR值是0.25，这里L(B)=2，L(C)=1，L(D)=3，计算出PR(A)=0.458，接下来计算所有其他被引用（有链入）的文档PR值，PageRank是个迭代算法，反复计算以后所有的PR值会收敛，那就是最终每个文档的PR值，也是用来改写DSL的关键信息：...
Spark App 血缘解析方案
over 2 years ago
一、背景 随着数据仓库的数据量的增长，数据血缘( Data Lineage or Data Provence ) 对于数据分析来说日益重要， 通过数据血缘可以追溯表-表，表-任务，任务-任务的上下游关系， 用来支撑问题数据溯源，孤岛数据下线的需求。 目前已经基于...
浅谈有赞搜索QP架构设计
over 2 years ago
一、有赞搜索平台整体设计 在介绍QP前先简单介绍一下搜索平台的整体结构，方便大家快速了解QP在搜索平台中的作用。下图简单展示了一个搜索请求开始到结束的全部流程。业务通过简洁的api接入los，管理员在搜索平台新建配置并下发，完成整个搜索接入，并通过abtest验证QP带来的优化效果。 二、QP的作用 在NLP中，QP被称作Query理解（QueryParser），简单来说就是从词法、句法、语义三个层面对query进行结构化解析。这里query从广义上来说涉及的任务比较多，最常见的就是搜索系统中输入的查询词，也可以是FAQ问答或阅读理解中的问句，又或者可以是人机对话中用户的聊天输入。 在有赞，QP系统专注对查询内容进行结构化解析，整合了有赞NLP能力，提供统一对外接口，与业务逻辑解耦。通过配置化快速满足业务接入需求，同时将算法能力插件化，并支持人工干预插件执行结果。 以精选搜索为例，当用户输入衣服时用户往往想要搜的是衣服类商品，而不是衣服架，衣服配饰等衣服周边用品。通过将衣服类目进行加权，将衣服类的商品排在靠前的位置，优化用户搜索体验。 QP目前应用在新零售，微商城、精选、爱逛买手店、分销市场、帮助中心知识库、官网搜索等场景，通过类目加权，产品词识别，搜索词纠错，同近义词召回提升用户搜索效果。 三、QP应用整体设计 上图完整描述了QP请求流程和配置流程的执行情况。当搜索请求到达QP时，根据请求体中的场景标记获取QP配置。QP配置中包含搜索词位置标记，插件列表，dsl改写脚本等内容。 QP根据配置，按序执行相应插件。插件在执行后，可通过干预配置以及超参数对结果进行人工干预。 QP在获取到算法插件执行结果后，根据改写配置，对搜索dsl进行改写。如将纠错词放置在搜索词同一层级，将dsl改写成fuction score结构进行类目加权。...
对比学习在有赞的应用
almost 3 years ago
1. 对比学习的引入 一般做算法任务时，都需要搜集大量标注的数据，假如我们要预测一个商品的产品词（中心词），下面是一个商品标题： 三亚亚龙湾玫瑰谷JESS玫瑰臻白颜透润花瓣 免洗面膜收缩毛孔 这个商品的产品词就是“面膜”，任务就是要把面膜识别出来，看起来是个标准的NER任务，我们也确实使用了CRF和指针网络之类的方法，对于上面这种标题效果还不错，但是由于SAAS商家的经营习惯不同于平台，很少依赖平台搜索流量，所以很多标题很简短甚至不会包含产品词，比如： 迪奥丝绒系列760 专属女团色 蓝调正红 可盐可甜 澳优能立多3段 对于这种问题，NER相关的算法就无解了，模型无法在商品标题中找到合适的产品词，当然也可以认为是标题中没有产品词。但是这种模型很多时候会从标题里预测出来奇奇怪怪的结果，导致产品词太发散，业务方很难基于产品词制定规则。...
有赞算法平台之模型部署演进
almost 3 years ago
一、 前言 模型部署作为算法工程落地的最后一公里，其天然对算法团队而言具有较高的复杂性，不仅要考虑如何高效地部署、管理不同框架模型，还需要考虑分布式服务的负载均衡、故障容错、可扩展性、资源隔离、限流、核心指标监控等问题。 这些都极大的依赖于工程团队的能力，不是算法团队的强项，如何解决这最后一公里，让焦点聚焦在模型开发上，是模型部署服务模块需要解决的问题。 二、 原有架构 2.1 架构设计 在有赞算法平台Sunfish包含算法训练和模型部署两部分， 模型部署的模块称为ABox（小盒子）。 ABox 主要提供将模型部署为在线服务的功能，...
特性团队中的 DoD 右移实践
about 3 years ago
作者：严梨炯 | 效能改进 一、背景 DoD（全称：Definition of Done）是特性团队内部，针对某个即将进入下一个迭代 backlog 的工作条目（一般指 story），约定其在该迭代结束时须完成到什么程度（比如：完成测试并等待演示，见图1）。尤其是当 story 颗粒度较大（须跨多个迭代）时，用该方式达成该团队共识，显得尤为重要。...
如何用「标准差」度量研发波动
about 3 years ago
作者：陈煜 | 效能改进 一、背景 技术中心的年度研发效能报告已于前不久发布，在吞吐的分析中，我们新增了一个指标「标准差」（计算公式见图1）。 图1. 标准差计算公式 标准差在概率统计中最常使用作为统计分布程度上的测量。它反映组内个体间的离散程度。标准差越大，表示大部分数值和其平均值之间差异较大，反之亦然。 上面的公式不用记，Excel 中有对应的计算函数：STDEVP（见图2）。 图2. Excel...
一则物理看板的演进实践
about 3 years ago
作者：林晔琛 | 效能改进 一、背景 看板（并非特指 Kanban，下同）作为一种目视化管理工具，能够将团队成员的工作过程透明出来，帮助团队更好地发现问题和瓶颈，尤其是在特性团队中，更是会秉承看板的理念，将其与站会形成良好的配合和互动，充分发挥其目视化的作用。 在笔者的工作场景中，特性团队尚处于敏捷转型初期，并未养成良好的工作习惯，其中就包括看板使用不到位的情况，导致了站会活动效果不佳。于是，笔者尝试从「改变看板的使用姿势」切入，唤醒团队的自管理意识，逐步改善团队的敏捷氛围。 二、物理看板演进 1. Scrum 板：从失焦到聚焦 现象...
「研发共建」提升中台效能初探
about 3 years ago
作者：徐钰菡 | 效能改进 一、背景 在互联网行业，大部分研发团队都会通过建设中台（有些公司叫平台），来提高系统的可复用性，降低重复功能的研发成本。随着有赞业务的快速发展，我们也逐渐走向了大中台道路，充分享受着中台所带来的红利，但与此同时，我们也陆陆续续遇到了不少问题，笔者希望借助本文，从效能改进的视角进行剖析，期待引发读者对「如何从组织层面协同中台」的思考和共鸣。 二、发现问题 有赞大大小小业务共有十几个（下称：业务域），在各业务域（一级）下，又细化出若干业务子域（二级），维护自己的需求优先级列表（backlog）。而中台，也并非以整体在运作，而是根据组件划分为商品、交易、营销等功能模块，各功能模块也有自己的需求优先级列表（中台没有整体的 backlog）。 1. 需求规划困难，阻碍业务发展 尽管业务域内部可以从容响应市场需求的快速变化，但因为功能托管而造成技术依赖，导致与中台的耦合度极高。当业务子域需要在中台通用能力基础上，快速叠加新场景时，就遇到跨团队协作壁垒、多个业务子域需求冲突、规划节奏不一致的问题。业务发展速度越快，对中台的诉求越频繁，问题的复杂度就越呈现出指数级上升的态势，则业务功能迭代的阻力越大。 如何在不同业务域下与各业务子域横向...
逻辑表在OLAP场景下的应用与实现
about 3 years ago
一.背景 数据中心为微商城和零售的商家后台分别建立了一套数据模型、 数据服务， 在此基础上分别建立了一套数据分析的产品体系，随着微商城和零售慢慢往连锁版本融合并伴随着新业务接入，目前的开发模式遇到了以下痛点： 两套数据服务有很多相同之处，重复烟囱式的开发，造成了人力资源浪费，而且开发效率低，从数据开发到最终交付数据服务，需要经历较长的周期； 两套数据模型在指标上存在大量重合，相同的指标的重复开发，增加了开发和维护成本，且存在口径不一致的风险，导致众多线上咨询，损害了商家对数据可靠性的信任。 基???上述痛点，数据应用团队搭建了统一的数据模型和数据服务。本文将介绍在搭建统一数据模型的过程中遇到的问题并给出相应的解决方案。 二.统一数据模型实现 上层的数据分析模型会在某个主题下，对多个主题域的数据指标进行分析，因此上层数据模型需要包含丰富的指标。 本文将以kylin作为在线存储的选型为例，分享统一数据模型建设中逻辑表的建设实践。 一.大宽表解决方案 图一...
效能指标「研发浓度」在项目度量中的应用
over 3 years ago
文 | 费解 on 效能改进 1. 背景 在研发管理领域，业界一直在试图寻找可以衡量研发交付效率的指标。常见的指标有：吞吐率（多）、研发周期（快）、资源利用率（省）。然而，在实践中，我们发现，上述三项无法直接作为指导改进的北极星指标： 1）吞吐率，在一段时间内交付项目的个数，是产品需求方关注的指标。若项目未交付，则不落入统计，也就无法发现问题和采取行动。而一旦交付，就错过了采取行动的时机。该指标是个滞后指标，它只关注项目的终点，犹如刻舟求剑，可参考性较差。见图1中，4月份吞吐率为0，但并不意味着生产是停滞的，5月份吞吐率为1，也不意味着持续了5个月的项目D是健康的。 图1. 多个项目上线后，被统计在不同月份的吞吐率中 2）研发周期，基于单个项目计划的起止时间，是由关键路径决定的，项目经理尤为关心。然而，在关键路径上的人员，除了计划内的研发工作之外，又受到项目外的精力牵扯（比如：处理临时突发的线上...
数据测试方法
over 3 years ago
有赞数据报表中心为商家提供了丰富的数据指标，包括30+页面，100+数据报表以及400+不同类型的数据指标，它们帮助商家更合理、科学地运营店铺，同时也直接提供分析决策方法供商家使用。并且，每天在跑的底层任务和涉及的数据表已经达到千级别。面对如此庞大的数据体系，作为测试如何制定质量保障策略呢？这篇文章将从：1、有赞数据链路 2、数据层测试 3、应用层测试 4、后续规划四个方面展开 一、有赞数据链路 1、数据链路介绍 首先介绍有赞的数据总体架构图： 自顶向下可以大致划分为应用服务层、数据网关层、应用存储层、数据仓库，并且作业开发、元数据管理等平台为数据计算、任务调度以及数据查询提供了基础能力 以上对整体架构做了初步的介绍，对于质量把控来说，最核心的两个部分是：数据仓库以及数据应用部分。因为这两部分属于数据链路中的核心环节，相对于其他层级而言，日常改动也更为频繁，出现问题的风险也比较大 二、数据层测试 1、整体概览 首先，针对数据层的质量保障，可以分成三个方面：数据及时性、完整性、准确性...