知识库是企业经营过程中的面向客户和内部员工的知识沉淀文档库，里面包含各类教程、问答、案例等，知识库的检索匹配是自然语言处理(NLP)中一个重要的基础问题，本质是进行文本语义的相似度计算，也就是语义匹配，我们很多领域的任务都可以抽象为文本匹配检索任务，例如检索引擎、智能客服、知识检索、信息推荐等领域。
　　知识库检索匹配可以概述为：给定一个query和大量候选知识库的文档，从这些文档中找出与用户输入query最匹配的TopK个文档。

二、架构流程

2.1、整体架构

2.2、请求链路

三、算法模型

3.1、DSL改写

　　检索优化第一步：DSL改写，接手前业务方自己已经对检索结果做过优化，调整不同字段的匹配权重，这一方法的已经难以继续优化。从知识运营的角度出发，在用户检索时，将运营认为重要的文档推到前面，由于文档之间互相有链接引用，可以使用PageRank算法给每个文档计算重要分(PR值)。
　　PageRank的核心思想是，被引用次数越多的文档越重要。算法原理如下，假设只有四个网页ABCD，以AB间的箭头为例，代表可以从B网页跳转到A网页，对B即一次引用（

随着数据仓库的数据量的增长，数据血缘( Data Lineage or Data Provence ) 对于数据分析来说日益重要， 通过数据血缘可以追溯表-表，表-任务，任务-任务的上下游关系， 用来支撑问题数据溯源，孤岛数据下线的需求。

目前已经基于 ANTLR 语法解析支持了 SQL 任务的血缘解析， 而 Spark App 任务的血缘仍然是通过人工配置方式进行。 我们希望能够将 Spark App 任务的解析做个补充，完善血缘逻辑。

目前线上的 Spark App 任务支持 Spark 2.3、 Spark 3.1 两个版本， 并且支持 python2/3、 java、scala 类型， 运行平台各自支持 yarn 和 k8s,

  在介绍QP前先简单介绍一下搜索平台的整体结构，方便大家快速了解QP在搜索平台中的作用。下图简单展示了一个搜索请求开始到结束的全部流程。业务通过简洁的api接入los，管理员在搜索平台新建配置并下发，完成整个搜索接入，并通过abtest验证QP带来的优化效果。

二、QP的作用

   在NLP中，QP被称作Query理解（QueryParser），简单来说就是从词法、句法、语义三个层面对query进行结构化解析。这里query从广义上来说涉及的任务比较多，最常见的就是搜索系统中输入的查询词，也可以是FAQ问答或阅读理解中的问句，又或者可以是人机对话中用户的聊天输入。
  在有赞，QP系统专注对查询内容进行结构化解析，整合了有赞NLP能力，提供统一对外接口，与业务逻辑解耦。通过配置化快速满足业务接入需求，同时将算法能力插件化，并支持人工干预插件执行结果。
  以精选搜索为例，当用户输入衣服时用户往往想要搜的是衣服类商品，而不是衣服架，衣服配饰等衣服周边用品。通过将衣服类目进行加权，将衣服类的商品排在靠前的位置，优化用户搜索体验。   QP目前应用在新零售，微商城、精选、爱逛买手店、

一般做算法任务时，都需要搜集大量标注的数据，假如我们要预测一个商品的产品词（中心词），下面是一个商品标题：

三亚亚龙湾玫瑰谷JESS玫瑰臻白颜透润花瓣 免洗面膜收缩毛孔

这个商品的产品词就是“面膜”，任务就是要把面膜识别出来，看起来是个标准的NER任务，我们也确实使用了CRF和指针网络之类的方法，对于上面这种标题效果还不错，但是由于SaaS商家的经营习惯不同于平台，很少依赖平台搜索流量，所以很多标题很简短甚至不会包含产品词，比如：

迪奥丝绒系列760 专属女团色 蓝调正红 可盐可甜
澳优能立多3段

对于这种问题，NER相关的算法就无解了，模型无法在商品标题中找到合适的产品词，当然也可以认为是标题中没有产品词。但是这种模型很多时候会从标题里预测出来奇奇怪怪的结果，导致产品词太发散，业务方很难基于产品词制定规则。

去年我们接触到了对比学习，被OpenAI的CLIP: Connecting Text and Images惊艳到了，效果之好，方法之简单，令人兴奋。而且微软相似的模型Turing Bletchley: A Universal Image Language Representation

模型部署作为算法工程落地的最后一公里，其天然对算法团队而言具有较高的复杂性，不仅要考虑如何高效地部署、管理不同框架模型，还需要考虑分布式服务的负载均衡、故障容错、可扩展性、资源隔离、限流、核心指标监控等问题。 这些都极大的依赖于工程团队的能力，不是算法团队的强项，如何解决这最后一公里，让焦点聚焦在模型开发上，是模型部署服务模块需要解决的问题。

二、 原有架构

2.1 架构设计

在有赞算法平台Sunfish包含算法训练和模型部署两部分， 模型部署的模块称为ABox（小盒子）。

ABox 主要提供将模型部署为在线服务的功能， 主要包含以下功能：
1. 提供 tensorflow 模型的服务加载和版本管理、弹性部署
2. 提供 tensorflow 模型和其他模型服务（自己部署在额外服务器上）的路由管理
3. 提供模型输入和输出的自定义处理逻辑执行
4. 提供服务主机的负载均衡管理
5. 收集的 Metric 写入上报到 kafka，通过 druid

作者：严梨炯 | 效能改进

一、背景

DoD（全称：Definition of Done）是特性团队内部，针对某个即将进入下一个迭代 backlog 的工作条目（一般指 story），约定其在该迭代结束时须完成到什么程度（比如：完成测试并等待演示，见图1）。尤其是当 story 颗粒度较大（须跨多个迭代）时，用该方式达成该团队共识，显得尤为重要。

众所周知，即便在敏捷模式中，研发过程依然由若干道工序所组成，故 DoD 的设计，完全可以基于工序来划定。笔者在敏捷转型的实践过程中，完成了特性团队从无到有创建 DoD 活动，并推动其逐渐右移，以帮助团队养成「聚焦目标」的习惯。

二、问题现状

既然定义了 DoD，

作者：陈煜 | 效能改进

一、背景

技术中心的年度研发效能报告已于前不久发布，在吞吐的分析中，我们新增了一个指标「标准差」（计算公式见图1）。

标准差在概率统计中最常使用作为统计分布程度上的测量。它反映组内个体间的离散程度。标准差越大，表示大部分数值和其平均值之间差异较大，反之亦然。

上面的公式不用记，Excel 中有对应的计算函数：STDEVP（见图2）。

二、指标的产生历程

常见的数据分析方法包括：趋势分析、指标下钻分析、关联影响分析。而标准差，就是下钻分析维度的产物。我们的目标是提升吞吐量（即：单位周期交付的需求数量），所以重点关注在「吐」的情况。

然而，利特尔法则指出，过高的在制品数量会影响需求的交付周期，进而影响需求交付效率。故在吞吐量的分析中，我们加上了在制品的分析，引入了对「吞」的观察（即：单位周期规划的需求数）

作者：林晔琛 | 效能改进

一、背景

看板（并非特指 Kanban，下同）作为一种目视化管理工具，能够将团队成员的工作过程透明出来，帮助团队更好地发现问题和瓶颈，尤其是在特性团队中，更是会秉承看板的理念，将其与站会形成良好的配合和互动，充分发挥其目视化的作用。

在笔者的工作场景中，特性团队尚处于敏捷转型初期，并未养成良好的工作习惯，其中就包括看板使用不到位的情况，导致了站会活动效果不佳。于是，笔者尝试从「改变看板的使用姿势」切入，唤醒团队的自管理意识，逐步改善团队的敏捷氛围。

二、物理看板演进

1. Scrum 板：从失焦到聚焦

现象

每日站会是技术负责人发起的，没有固定的聚会场所，而且形式比较随意：团队成员围坐在办公室休息区的沙发上，抑或茶水间的吧台前，每个人端着电脑，在技术负责人的主持下被挨个儿点名，然后大家轮流在自己电脑上更新维护同一份在线表格中所负责的任务条目的状态（石墨、Confluence 之类的），站会过程中的其他时间就处理与会议无关的事务。

分析

• 责任失焦。作为技术负责人角色，主持人天然带有权威性，

作者：徐钰菡 | 效能改进

一、背景

在互联网行业，大部分研发团队都会通过建设中台（有些公司叫平台），来提高系统的可复用性，降低重复功能的研发成本。随着有赞业务的快速发展，我们也逐渐走向了大中台道路，充分享受着中台所带来的红利，但与此同时，我们也陆陆续续遇到了不少问题，笔者希望借助本文，从效能改进的视角进行剖析，期待引发读者对「如何从组织层面协同中台」的思考和共鸣。

二、发现问题

有赞大大小小业务共有十几个（下称：业务域），在各业务域（一级）下，又细化出若干业务子域（二级），维护自己的需求优先级列表（backlog）。而中台，也并非以整体在运作，而是根据组件划分为商品、交易、营销等功能模块，各功能模块也有自己的需求优先级列表（中台没有整体的 backlog）。

1. 需求规划困难，阻碍业务发展

尽管业务域内部可以从容响应市场需求的快速变化，但因为功能托管而造成技术依赖，导致与中台的耦合度极高。当业务子域需要在中台通用能力基础上，快速叠加新场景时，就遇到跨团队协作壁垒、多个业务子域需求冲突、

文 | 费解 on 效能改进

1. 背景

在研发管理领域，业界一直在试图寻找可以衡量研发交付效率的指标。常见的指标有：吞吐率（多）、研发周期（快）、资源利用率（省）。然而，在实践中，我们发现，上述三项无法直接作为指导改进的北极星指标：

1）吞吐率，在一段时间内交付项目的个数，是产品需求方关注的指标。若项目未交付，则不落入统计，也就无法发现问题和采取行动。而一旦交付，就错过了采取行动的时机。该指标是个滞后指标，它只关注项目的终点，犹如刻舟求剑，可参考性较差。见图1中，4月份吞吐率为0，但并不意味着生产是停滞的，5月份吞吐率为1，也不意味着持续了5个月的项目D是健康的。

2）研发周期，基于单个项目计划的起止时间，是由关键路径决定的，项目经理尤为关心。然而，在关键路径上的人员，除了计划内的研发工作之外，又受到项目外的精力牵扯（比如：

一、有赞数据链路

1、数据链路介绍

首先介绍有赞的数据总体架构图：

自顶向下可以大致划分为应用服务层、数据网关层、应用存储层、数据仓库，并且作业开发、元数据管理等平台为数据计算、任务调度以及数据查询提供了基础能力

以上对整体架构做了初步的介绍，对于质量把控来说，最核心的两个部分是：数据仓库以及数据应用部分。因为这两部分属于数据链路中的核心环节，相对于其他层级而言，日常改动也更为频繁，出现问题的风险也比较大

二、数据层测试

1、整体概览

首先，针对数据层的质量保障，可以分成三个方面：数据及时性、

作为后端开发，redis是工作中最绕不开的中间件之一，在工作中通常有以下几个常用用途

1.缓存，可以抗十万级别的qps
2.计数器，如点赞数，pv等
3.分布式锁
4.限流

另外丰富的redis数据类型支持了一些扩展功能，如排行榜，消息队列，布隆过滤器，位图等等。而redis的底层实现是十分简单的，核心源码也仅有几万行。本文就带大家来领略，小小的redis是如何实现这些复杂功能的~

*注:本文介绍的源码为redis 5.0.14版本 *

二、字符串

C语言存储字符串的问题

1.二进制安全

C语言中表示字符串结尾的符号是'\0',如果字符串本身就具有'\0'字符，就会被截断，即非二进制安全。

2.计算字符串的长度性能低

C语言中有一个计算字符串长度的函数strlen，但这个函数与Java的不一样，需要遍历整个字符串来计算长度，时间复杂度是O（n），如果需要在循环中计算，性能将十分低下

一.引言

引言：“操作系统的线程状态和java的线程状态有什么关系？”这是校招时被问到的一个问题。当时只顾着看博文、面经等零散的资料，没有形成系统的知识体系，一时语塞，答的不是很对。在网上也没找到足够细致的讲解博文，于是整理出了这篇内容。

Java的线程状态牵扯到了同步语义，要探讨Java的线程状态的，必不可免要回顾其锁机制。因此本文的主要分为两大块：一是Synchronized源码粗析，分析了各类锁的进入、释放、升级过程，并大致说明了monitor原理；二是介绍了线程的实现方式和Java线程状态转换的部分细节。

P.S. 本文内容较啰嗦，时间不充裕的同学可以直接看2.6小结及3.3小结。

二. Synchronized锁

Java采用synchronized关键字、以互斥同步的方式的解决线程安全问题，那么什么是线程安全呢？这里引用《Java并发编程实战》

​ 随着有赞实时计算业务场景全部以 Flink SQL 的方式接入，对有赞现有的引擎版本——Flink 1.10 的 SQL 能力提出了越来越多无法满足的需求以及可以优化的功能点。目前有赞的 Flink SQL 是在 Yarn 上运行，但是在公司应用容器化的背景下，可以统一使用公司 K8S 资源池，同时考虑到任务之间的隔离性以及任务的弹性调度，Flink SQL 任务 K8S 化是必须进行的，所以我们也希望通过这次升级直接利社区的 on K8S 能力，直接将Flink SQL 集群迁移到 K8S 上。特别是社区在 Flink 1.13 中 on Native K8S 能力的支持完善，为了紧跟社区同时提升有赞实时计算引擎的能力，经过一些列调研，我们决定将有赞实时计算引擎由