前言

在开始文章之前，我先介绍一下导购。导购通常是指在购物过程中帮助消费者做出最佳决策的人或系统。在电商网站上，导购可以引导用户关注热销产品或促销活动等，帮助用户更好地购物。导购的目的是为了提高用户的购物体验，促进销售增长。

接下来我们先从正文说起，单词分发也是导购的一部分，主要提供下拉词、背景词、列表、提示、风向标等单词推荐相关的功能，单词分发平台致力于打造通用的单词推荐平台，避免重复开发维护成本，提高运营效率和业务灵活性，从而支撑公司各领域的业务发展和用户需求。

这个平台主要的作用是把各种算法和工具整合起来，并提供一些通用的服务和接口，让各个领域可以快速开展业务，实现自己的单词推荐功能。这样就不需要针对每个领域进行单独的开发和维护，节省了大量的时间和成本。同时这个平台的灵活性也很高，可以根据不同的业务需求和场景特点进行快速调整和修改，保证业务的顺利进行。

初始背景

在当今数字化时代，搜索引擎已经成为人们生活、工作中不可缺少的工具，通过搜索指定的关键词来获取有用的信息和数据已经成为人们的普遍需求，因此在搜索引擎优化过程中，关键词的选择和排名尤为关键。

在常规搜索引擎中，搜索结果通常基于全局搜索结果，而针对特定用户兴趣和需求的推荐服务往往缺失，这意味着用户在需要相关信息时，往往需要搜索大量的结果并进行筛选。通过个性化推荐词分发服务，用户可以得到更有针对性的关键词推荐，大大减少了用户自己搜索的时间和精力成本。因此，为用户提供个性化推荐的词分发服务是非常必要的。

总之，设计关键词服务并提供个性化的推荐关键词分布，可以针对不同类型的用户提供更精准、更快捷、更全面的关键词推荐服务，有利于企业吸引更多的潜在用户，提高品牌知名度和客户忠诚度，同时也能提升企业的市场竞争力和盈利能力。

服务建设

个性化推荐词分发服务核心技术主要包括：

针对不同的用户群体，个性化推荐词分发服务可以通过智能分析用户行为数据，精准刻画用户群体，针对不同用户群体提供针对性的推荐服务。例如，针对喜欢购买化妆品、服饰的女性用户，服务平台可以推荐相关的背景词、热词、下拉词；针对喜欢aj鞋、手表的男性用户，平台可以根据其搜索历史和行为数据，推荐与aj、手表相关的关键词和内容。

功能分析

由于后台词、热点词、下拉词的功能实现不同，需要提供具体的实现方案，以更好地满足不同场景的需求。后台词、热点词的实现逻辑类似，没有用户主动触发条件，主要依靠用户行为向用户推荐热点词。后台词、热点词的实现关键是分析用户的搜索行为和历史，通过用户历史条目点击、搜索召回i2q、q2q，从而向用户推荐个性化的热词。下拉词的实现方案与后台词、热点词不同，需要有用户主动触发条件，对用户实时输入的内容进行关键词匹配和召回，再通过个性化排序进行推荐。综上所述，后台词、热点词、下拉词的实现方案不同，需要根据场景和需求提供相应的实现方案。

功能

背景词/热词

背景词、热门词的实现主要依靠用户行为来向用户推荐热门词，在实现过程中需要分析用户的行为历史，利用算法对用户的历史行为进行分析处理，实现i2q、q2q的召回。

背景词和热词通过分析用户的搜索行为和历史数据，可以根据用户的兴趣和需求，推荐最热门的关键词。例如，对于经常浏览Nike相关产品的用户，系统可以推荐Nike系列最热门的背景词和热词。

背景词和热词的实现关键在于没有用户主动触发的条件，主要依靠服务内部对用户历史行为数据的细致分析和处理，通过对用户行为的深度挖掘，识别出用户兴趣和需求的热点区域和方向，从而精准推荐与用户需求相关的背景词和热词。同时，为了更好地提升背景词和热词的效果，需要不断优化算法，不断升级推荐策略，提升词的覆盖率和精准度，实现更加个性化和精准的推荐服务。

下拉单词

下拉词是指搜索框下方的词条提示，需要用户主动提供触发条件，当用户在搜索框输入关键词时，搜索引擎会根据用户实时输入的内容进行关键词匹配召回，然后通过个性化排序进行推荐。不同于背景词、热词，下拉词的推荐更贴近当前用户的实际需求和搜索意图。

在实现下拉词的过程中，搜索引擎需要通过算法对用户的历史搜索记录和行为数据进行统计和分析，从而了解用户的兴趣和搜索习惯，识别用户的搜索需求并提前预测可能的搜索意图。在召回阶段，用户输入搜索词后，搜索引擎会根据匹配规则召回并排序相关关键词，并推荐与用户需求最相关的下拉词。在排序阶段，搜索引擎会根据个性化的排序算法，结合用户的行为特征和搜索历史数据，对召回的关键词进行排序，让用户看到最相关、最实用的下拉词提示。

综上所述，下拉词的实现需要根据用户的搜索历史数据和行为特征进行分析处理，结合相关算法下拉词软件平台，实现个性化、实用性的推荐服务。下拉词的推荐与用户的搜索需求、搜索意图联系更为紧密，因此下拉词的质量和推荐的准确率对用户的搜索体验和满意度有着重要的影响。

平台问题

随着公司的发展，对已有场景、产品服务、算法的迭代需求越来越多，比如词汇的迭代开发、政策的变更、业务的迭代等等。针对新的场景，越来越多的业务领域需要前置引导功能，比如客服智能提示、海外业务导购、营销导购、推荐指标、主搜索提示、排名等。基于已有服务，主要存在以下问题

（1）研发与时间成本：通过增删召回循环、改变策略、部署资源等方式迭代现有场景，需要投入大量工程、算法方面的研发资源，迭代周期长。同时PMO、各类团队及PM、项目联调、测试资源、线上CR变更等间接投入也会不断积累。

（2）多场景接入问题：不同场景重复建设也会增加成本，这也需要研发和时间成本，不再细说。

目标

综上所述，目前的服务存在迭代成本高、周期长、多场景重复建设等问题。为了优化现状，构建通用平台，避免重复开发维护成本，提高运营效率和业务灵活性，从而支撑公司业务发展和用户需求。平台能力主要从以下几点进行提升：

分阶段开发

构建通用平台是优化现状的有效途径之一，但具体实施仍需深入思考和细化。首先，需要明确业务流程中各个场景的特点和需求，以及它们之间的相同点和不同点，确定哪些部分可以抽象和共享，哪些部分需要定制。其次，需要通过技术手段将通用组件抽象分离，构建通用平台，加强平台的可定制性和可扩展性，以满足不同场景的需求。这个过程需要制定完整的流程，构建完整的监控报警体系等，保证平台的可靠性和稳定性。最后，需要不断优化和完善平台，同时加强对平台的安全性、可维护性、可扩展性等的管控，保证平台能够适应不同场景的变化和需求。

经过深入研究，具体业务框架如下

潜伏期

首先，在明确各业务场景特点和需求的基础上，对流程进行抽象和分离，通过标准化流程实现统一管理和执行。这样不仅降低了维护成本，还提高了流程的可重复性和可扩展性，为后续通用平台的建设奠定了基础。其次，在构建通用平台时，考虑到不同的业务场景和需求，通过技术手段对通用组件进行抽象和分离，提高代码的可重用性和可维护性，同时加强平台的可定制性和可扩展性，让不同的业务场景都能方便地接入和使用平台，也能快速适应业务的更新和变化。具体功能拆分模块如下图所示：

通过对各个模块进行抽象和拆分，赋予不同模块各自特定的功能，主要模块及其功能如下：

预处理

预处理的主要功能有：

用户画像调用（可选功能）：对用于后续模型的召回条件进行排序和调用（例如用户点击行为的i2q召回、搜索行为的q2q召回等）

曝光过滤（可选功能）：这里的曝光过滤指的是误曝光，就是在回调时用后处理返回的数据作为过滤条件，排除曝光的内容

获取qp分词（可选功能）：比如客服回电时，根据用户输入的词进行分词，这里就需要用qp对输入的词进行分词。

缓存数据（可选功能）：这个主要用在单词表轮播的场景，主要用于记录上次访问的位置（跟用户画像相关的内容会缓存在这里，如果用户画像没有变化，那么当前访问会先看上次的位置，用户画像如果变化了一般会放弃，主要原因是用户画像变化之后，召回和排序都会变化，列表就不一样了）

条件处理（可选功能）：在封装回调DSL之前，增加一些引擎查询条件和过滤条件，这些参数可以是上游输入、用户配置文件、ab实验配置等。

ab：获取 ab 分割

记起

主要封装了召回 DSL，提供不同字段索引查询（前缀、BM25、精度、数组等）和过滤（等于、不等于、大于、小于等）功能，支持单字段多条件拼接（and、or）和多字段拼接（and、or），这些操作在召回配置中配置，框架根据不同需求配置，灵活封装 DSL 获取数据和处理流程。

目前，支持多种引擎：c引擎、es引擎。在调用引擎时，提供多种调用模式，包括并行、串行、串并模式。可根据不同需求调整引擎调用模式，提高调用过程的性能和效率。

召回主要分为混合词和资源词两种，混合词召回主要用于后续的排序和最终的返回列表；资源词召回用于资源分配，提供给运营进行一些活动或者产品的推广，数据放在排序好的混合词列表中。

召回融合

召回融合就是将多次召回的结果进行融合，以提高召回率和召回质量。在这个过程中，主要是对多次召回的混合词进行融合。用户可以根据自己的需求选择融合策略，也可以使用默认的融合策略。

默认的融合策略是按照优先级对多条召回结果进行融合。如果配置了 路径，则会优先对非 路径的结果进行融合，如果非 路径中没有数据，则以 路径融合后的数据列表作为最终的融合结果，如果非 路径中有数据，则会丢弃 路径的结果。如果没有配置 路径，则会对所有路径的结果进行融合。在融合过程中，还可以设置一些权重和相关参数，来调整不同召回结果的占比和优先级。这样可以更好地满足不同场景和需求的要求。

排序

目前召回结果排序支持SDK模型、RS，这些模型可以对每条召回结果进行打分，得到CTR、CVR等指标。通过脚本可以将模型得到的指标进行加权融合，得到最终的综合评分。在融合过程中，可以使用不同的权重配置对CTR、CVR进行数学计算，以达到最佳排序效果。

为了保证最终排序结果的相关性和质量，通常需要对得分进行筛选和限制，去除得分低于一定阈值的召回结果，以减少不相关或低相关结果及垃圾结果的干扰。

接下来会对融合筛选后的结果进行排序，根据不同的需求和场景，可以采用不同的算法进行排序。最后得到一个从相关度高到低的列表，通过综合得分计算出各个召回结果的相关度和排序。最后这个列表中的召回结果就是最终的排序结果，可以返回给用户展示。这样可以快速对召回结果进行排序和筛选，提高结果的相关性和质量。

重新排列

重排序是对排序结果进行后处理的技术，主要目的是进一步提高排序结果的相关性和质量。重排序方法包括同义词打散和无价过滤。

同义词破除是对搜索结果的一种优化，其目的是通过从召回结果列表中移除语义相同的结果，保证搜索结果的多样性和覆盖率。这可以帮助我们提升搜索结果质量和用户体验，避免结果重复和在某一特定领域的过度集中。例如，当用户在搜索引擎中输入关键词“巧克力”时，通过同义词破除技术，搜索引擎可以展示与“巧克力”相关的多种结果，如“巧克力蛋糕”、“巧克力口味”等，以满足不同用户的需求。

无价过滤也是对搜索结果的一种优化，其目的是通过从召回结果列表中移除无价或无法出售的商品，保证搜索结果的准确性和有效性。这可以帮助我们提升搜索结果的质量和用户体验，避免用户浪费时间浏览无效的产品或服务。例如，在平台上搜索商品时，无价过滤技术可以快速识别并移除“售罄”、“无价”等无效商品，确保用户获取有效的商品信息，提高搜索效率。

总之，重排序可以对排序结果进行优化和后处理，使其更加高效、准确、相关，并通过适当的同义词破译、无价过滤等技术手段，进一步提升排序算法的效果和性能，提升平台的竞争力和用户体验。

资源状况

资源位置是指将资源位置词按照一定的规则放置在重新排列的召回结果列表中。

首先，为了保证资源投放的效果，资源位需要进行优先级排序，保留高优先级的资源位，高优先级的资源位可以覆盖低优先级的资源位。例如对于下拉词第五位，品牌直接跳转优先级最高，其次是内容导购和IP直接跳转，优先级依次降低。

然后需要去除混合词中与资源位置冲突的单词，避免资源位置和对应的搜索结果出现重复。

最后根据资源位置类型，将资源位置置于混合词列表的前列、后列或者靠后位置，增加资源位置的曝光度和点击率，这样可以有效增加用户对搜索结果的关注度和点击率，提升搜索引擎的收益和用户体验。

预

坑

邮政

邮政

后处理是指在返回结果之前对返回结果进行一系列定制化处理，以满足不同场景的需求，包括但不限于以下几个方面：高亮：为了突出下拉词中的关键词，方便用户找到需要的信息，我们可以通过后处理实现下拉词高亮功能，将下拉词中的关键词进行标记，以便客户端能够轻松识别。

统一跟踪点处理：为了更好地监控结果，我们可以通过后处理实现统一跟踪点处理，记录搜索到的实验、场景等信息，以便后续分析和运行优化。

监控功能：为保证系统的平稳运行，我们通过事后处理实现监控功能，实时监控搜索结果，对异常情况及时报警及处理，保证服务的可靠性和稳定性。

返回结构化封装：为了方便客户端处理返回结果，我们可以通过后处理对搜索结果进行结构化封装，以满足不同场景的特定需求。

通过这些定制化处理，可以满足客户特定的搜索需求，提高搜索服务的准确性、速度和用户体验。

生长

随着各个业务领域的需求增多，场景也随之增多，所有场景都集中在一个集群中，业务耦合在一起，各个场景统一加载模型、共享资源，相互影响，服务不稳定，也不利于各个场景独立迭代，一旦某个业务出现问题，可能会拖累其他场景，所以现阶段最重要的是集群隔离。

服务集群隔离

由于分词服务与其他服务不同，我们与外界通信的方式有两种，一种是通过 http+域名 URL 直接调用网关到 App 端，再由网关转发到分词集群；另一种是通过 rpc 来调用。针对这两种方式，我们开始将其隔离成两种情况：

解决方案 1

解决方案 2

方式

http接口转为RPC，提供接口2，现有的接口经过业务网关，业务网关根据路径调用不同的服务标签进行路由。

1. 同一套代码部署不同的应用名 2. 网关通过应用名做精准接口路由

优势

应用监控一并完成，新增集群跟踪点无需额外处理

无需任何接口。2.流量直达服务，无需业务网关介入。

缺点

单独提供接口2.流量和服务之间多一层业务网关，对业务网关依赖性强，性能上，多加一个业务网关进程

不同应用分别监控，当增加新的应用时，需要增加采集点。

建筑学

但是方案一无法通过与网关通信来实现，所以最终采用了方法二来实现集群隔离。

迁移 c 引擎

在分词平台中，不同场景使用不同的存储库会带来很多问题，包括维护难度大、扩展性差等。为了解决这些问题，我们需要一个统一的存储库来管理所有的应用，从而提高整体系统的性能和稳定性。另外，随着公司C++引擎的快速发展，以及C++引擎整个相关链路的成熟，我们决定将各个分词场景的数据迁移到C++引擎上。

首先，C++引擎拥有完善的数据结构和内存管理机制，通过前缀树等高效的数据结构来组织数据，可以快速查询和操作数据。同时，C++引擎的内存管理机制可以更高效地管理内存，提高系统性能。此外，C++引擎还拥有完善成熟的调度机制，可以高效地调度任务、管理线程池，保证平台的稳定性和可扩展性。C++还提供了快照恢​​复链接，也就是说，即使系统出现异常，我们仍然可以通过快照恢复机制将系统恢复到之前的状态。这种机制不仅提高了系统的可靠性，也保证了数据的安全。此外，C++引擎还拥有转储链接，可以在发生错误时输出相应的日志和错误信息，方便快速排查错误和修复问题。

总之，将词业务数据迁移至C++引擎，不仅可以统一算法平台上各类应用的存储基础，提高系统整体的稳定性和可扩展性，还可以通过C++引擎成熟的调度、dump链路、快照恢复链路功能，提高平台的可靠性和数据安全性。

高级阶段

现有功能上存在很多产品业务及算法迭代的需求，例如词库迭代、策略变更等。为了让算法使用平台更加便捷、快捷，我们进行了新一轮的效率提升项目。针对算法召回、策略变更等频繁的操作点，效率提升项目进行了针对性的迭代。项目组通过深入分析和理解用户需求，优化了平台上的召回策略和变更策略，并结合业务流程的特点和需求，开发了更加友好、高效的算法调用流程和界面，全面升级优化算法系统的用户界面、交互设计和性能，帮助用户更快速地完成任务。

脚本热部署

该功能主要是为了方便处理策略经常变化的链路，通过定义输入输出参数相同的抽象方法，将具体的逻辑委托给SDK，然后通过后台进行打包、配置、推送，这样线上服务就可以通过反射机制快速加载具体的实现，并通过ab配置选择应用的脚本。

在具体实现方面，我们需要先定义并实现相同输入输出参数的抽象方法，然后将具体实现推送到SDK中，以便在服务端进行动态推送和加载。在后台方面，我们需要提供打包、配置、推送功能，这样实现代码就可以预先打包配置成统一的包。这样当需要更改链接时，只需要将新的实现代码上传到后台，进行打包、配置、推送即可。

在线服务检测到有新的推送后，通过反射加载具体的实现，通过ab的配置选择对应的脚本进行应用。这种方式不仅节省了重启服务器的时间和成本，还可以更灵活的应用不同的脚本，实现策略的动态调整和优化。

综上所述，这种方式可以提供更加灵活、高效、可靠的链路策略处理，同时节省时间和成本，提高系统整体的性能和稳定性。

脚本执行流程如下：

集群管理

配置

持续性循环疾病

召回可视化工具

在现代搜索引擎系统中，多路召回是决定搜索引擎性能和准确率的一个非常重要的组件，因此多路召回的配置和管理对于搜索引擎系统的性能、稳定性和可维护性至关重要。

在之前的单词分发系统中，多路召回的配置都是以 JSON 字符串的形式存在的，每次修改配置都需要手动编辑 JSON，非常耗时。随着召回路径的增多，配置效率会越来越低，而且这种方式容易出错。因此我们需要一种更加高效、可视化的方法来管理和配置多路召回。

为了提高多路召回的配置效率和准确性，我们需要一个可视化的后台工具来代替手动修改JSON字符串。这样的后台工具可以更直观、可视化的展示多路召回的配置，让配置人员直接在页面上进行配置和修改，从而减少手动编辑JSON字符串的错误和繁琐。

通过使用可视化的后台工具，我们可以轻松管理和配置各种算法和策略，从而大大提高搜索引擎系统的性能和可维护性。

总之，可视化后台工具对于提高搜索引擎的性能和可维护性非常重要，可以大大简化配置人员的操作难度、减少错误，进一步提高搜索引擎系统的效率、可靠性和灵活性。

单通道配置

多路配置

差异工具

“ diff”是“ diff”的缩写，这意味着两个词平台中的差异或区别。

该工具可以比较策略的两个不同版本，并找出它们之间的差异，例如不同的权重，不同的过滤和排序规则等。通过diff工具，您可以快速获得不同策略的结果，帮助分析策略变化对搜索结果的影响，找出问题，并以目标方式解决问题。

简而言之，DIFF工具在搜索引擎中起着非常重要的作用。

干涉

干扰是搜索引擎优化的常见技术手段之一。

干预技术是通过以精致和详细的方式优化搜索结果来手动干预，调整和扩展搜索结果，以便获得更准确和令人满意的结果。

还有一些小场景，例如：标识下拉，迷你程序下拉列表等。

总结

通过架构转换和稳定性升级，单词分布平台具有灵活的可扩展场景访问解决方案，这有助于企业实现个性化的自定义，并在更广泛的场景和稳定性方面为平台的应用程序提供了全面的优势。可以准确，快速地发现和解决，以确保平台的稳定性。

将来，该平台将结合算法和法规平台，以打开单词圈与产品之间以及产品圈和单词之间的链接，以及不同类型的召回和权利法规等，以改善单词分配平台的功能，并使平台能够提供更好的服务。

*text/zhen.lee

本文是DEWU 的原始文章。