一、 背景
导购是指在购物过程中为消费者提供指引和帮助的人或系统，旨在协助用户做出更优的购买决策。在电商平台中，导购通过推荐热卖商品、促销活动或个性化内容，显著提升用户的购物体验，同时推动销售额的增长。其核心目标是通过精准的引导，满足用户需求并促进商业价值最大化。
词分发：导购的重要组成部分
在电商导购体系中，词分发作为关键环节，主要聚焦于与关键词推荐相关的功能。这些功能包括但不限于下拉词、底纹词、热搜榜单、锦囊词以及风向标等。这些推荐词能够帮助用户快速定位感兴趣的商品或服务，降低搜索门槛，提高购物效率。例如，下拉词可以在用户输入搜索内容时提供智能提示，而热搜榜单则能引导用户关注平台上的热门趋势。
词分发平台的价值与功能
为了进一步优化词推荐的效率与一致性，词分发平台应运而生。该平台致力于打造一个通用、高效的词推荐生态系统，通过集成多种算法、工具和通用服务接口，为公司内不同业务域提供灵活的词推荐支持。其主要优势包括以下几点：
- 统一开发，降低成本：词分发平台通过提供标准化的服务和接口，避免了各业务域重复开发和维护词推荐功能的成本。不同团队无需从零开始构建推荐系统，只需调用平台提供的接口即可快速实现定制化的词推荐功能，大幅节省开发时间和资源。
- 高灵活性，适应多场景：平台的模块化设计使其能够根据不同业务场景和需求进行快速调整。例如，针对促销活动、节假日特辑或特定品类推荐，平台可以动态调整推荐算法和词库，确保推荐内容的精准性和时效性。
- 支持业务扩展，提升效率：通过统一的词分发平台，各业务域能够更专注于核心业务逻辑的开发，而无需过多关注底层推荐系统的技术细节。这不仅提升了运营效率，还为业务的快速扩展提供了技术保障。
- 优化用户体验：词分发平台通过整合先进的推荐算法和数据分析能力，能够为用户提供更精准、更个性化的搜索建议。例如，基于用户历史行为和实时趋势生成的推荐词，可以帮助用户更快找到目标商品，从而提升整体购物体验。
二、已支持场景
已支持社区、交易、营销30+导购场景。
个别场景示例
三、整体架构
业务架构
平台架构
整体平台架构
平台+脚本化架构
脚本热部署功能在词分发搜索推荐引擎中发挥了重要作用，其主要目标是通过动态加载机制处理策略频繁变更的链路。实现这一功能的核心在于定义统一的抽象方法（具备相同出入参），将具体逻辑下放到 SDK 中，并通过后台打包、配置和推送流程，在线服务通过反射机制快速加载实现代码，再结合 AB 配置选择适用脚本。这种方法显著提升了策略调整的灵活性，同时减少了服务器重启的成本和时间。
在具体实施中，首先需要设计并实现统一的抽象方法，确保接口标准一致。随后，将具体的实现逻辑封装到 SDK 中，方便服务器端动态接收和加载。后台则负责提供打包、配置和推送功能，将实现代码整理为统一的包形式。当链路策略需要更新时，开发人员只需将新的实现代码上传至后台，完成打包、配置和推送操作。
在线服务在检测到新推送后，利用反射机制加载具体实现，并根据 AB 配置选择适用的脚本运行。这种动态加载方式无需重启服务，即可实现策略的即时切换和优化。整体而言，这一方法不仅提高了系统对策略变更的响应速度，还降低了维护成本，同时增强了系统的可靠性和稳定性，为词分发搜索推荐引擎的持续优化提供了有力支持。
主工程底座和脚本工程
在业务迭代的代码编写中，通常分为两种类型：主工程底座和脚本工程。
- 主工程底座主要负责实现抽象和通用层的代码逻辑，注重提供稳定的基础框架和通用功能，确保系统的整体架构和扩展性。
- 相比之下，脚本工程更贴近具体业务需求和定制化场景，专注于实现与业务逻辑密切相关的功能模块。通过这种分工，主工程提供通用的技术支持，而脚本工程则灵活应对多样化的业务需求，从而实现开发效率与业务适配性的平衡。
脚本热部署架构的存在原因
脚本热部署架构的存在主要出于以下原因：
- 灵活应对策略变更：通过动态加载脚本，系统能快速适应频繁更新的业务需求，无需重启服务。
- 降低维护成本：统一抽象方法和 SDK 实现减少重复开发，后台打包推送简化更新流程。
- 提升效率：反射机制和 AB 配置实现即时脚本切换，节省时间并优化资源使用。
- 增强稳定性：动态调整策略而不中断服务，确保系统持续稳定运行。
四、架构演进3.0之图化
串行架构
之前词分发业务一般都可以抽象为“预处理->召回->融合->粗排->精排->结果封装”等固定的几个阶段，每个阶段通常是有不同的算法或工程同学进行开发和维护。为了提升迭代效率，通过对推荐流程的抽象，将各阶段的逻辑抽象为“组件"+"配置”，整体的流程同样是一个配置，统一由“编排引擎”进行调度，同时提供统一的埋点/日志等。让工程或算法同学可以关注在自己的业务模块和对应的逻辑，而框架侧也可以做统一的优化和升级。
图化引擎架构演进
那为什么要去做“图化”/“DAG”呢？其实要真正要回答的是: 如何应对上面看到的挑战？如何解决目前发展碰到的问题？
从业界搜推领域可以看到不约而同地在推进“图化”/“DAG”。 从TensorFlow广泛采用之后，我们已经习惯把计算和数据通过采用算子（Operation）和数据（Tensor）的方式来表达，可以很好的表达搜索推荐的“召回/融合/粗排/精排/过滤”等逻辑，图化使得大家可以使用一套“模型”语言去描述业务逻辑。DAG引擎也可以在不同的系统有具体不同的实现，处理业务定制支持或者性能优化等。
通过图（DAG）来描述我们的业务逻辑，也带来这些好处：为算法的开发提供统一的接口，采用算子级别的复用，减少相似算子的重复开发；通过图化的架构，达到流程的灵活定制；算子执行的并行化和异步化可降低RT，提升性能。
图化是一种将业务逻辑抽象为有向无环图（DAG）的技术，其中节点代表算子，边表示数据流。不同的算子可以组合成子图，起到逻辑更高层封装的作用，子图的输出可供其他子图或算子引用。通过图化，策略同学的开发任务得以简化，转变为开发算子并抽象业务数据模型，而无需关注“并行化”或“异步化”等复杂逻辑，这些由 DAG 引擎负责调度。算子设计要求以较小粒度支持，通过数据流定义节点间的依赖关系。
图化引入了全新的业务编排框架，为策略同学提供了“新的开发模式”，可分为三部分：一是定义算子、图和子图的标准接口与协议，策略同学通过实现这些接口来构建业务逻辑图；二是 DAG 引擎，负责解析逻辑图、调度算子，确保系统的性能和稳定性；三是产品化支持，包括 DAG Debug 助手协助算子、图和子图的开发与调试，以及后台提供的可视化管理功能，用于管理算子、子图和图。整体架构可参考相关设计图。
图化核心设计和协议
节点‘算子’抽象封装——面向框架测
算子接口定义IDagTaskNodeExecutor<O>
/**
* dag 主节点注解
*/
@Inherited
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface DagNodeMetaProcessor {
/**
* 算子名字
* @return
*/
String name();
/**
* 算子描述
* @return
*/
String desc() default "";
}
/**
* 主工程节点任务-执行器
*
* @param <T>
*/
public interface IDagTaskNodeExecutor<T> {
T execute(DagStrategyContext dagStrategyContext);
图配置文件——面向框架测（使用者无需关心）
图分为图图，一个场景可以有多个图，可按实验制定不同的图；图定位为业务逻辑模版，可以将若干个独立算子组装为具有特定业务含义的“图”，图和算子一样可在场景大“图”中进行配置，即运行时可有多个“实例”，实现逻辑的复用和配置化。
面向业务使用者—如何配置
- 节点自动注册：面向使用者无需关心JSON复杂的配置化，完全可视化操作。节点有俩种类型分主节点和脚本节点（可视化区分），节点注册完成框架测实现。
- 业务关心编排关系：业务只需要关心节点之间编排关系即可。编排关系也是完全可视化拖拽实现。
- 线程池隔离：一个服务内，不同场景线程池是隔离的，一个场景内，不同并行节点线程池也可以做到隔离，来区分强弱依赖关系。
- 关联实验：一个场景有基础场景图，和实验图，实验图可以基于某个实验发布不同于场景的复杂实验图。
五、配套工具利器
脚本化开发&灰度发布CICD
自迭代流程图
去脚本化后台执行配置，首先选择对应环境的对应集群服务(先预发验证，验证没问题，提merge给工程cr，合并后操作线上集群)。
脚本配置
如果是新加的脚步，选择配置，然后在配置页面对应类型的脚步后面选择新增，然后添加对应脚本类型的配置（一定要按类型添加，否则加载会失败），然后点击添加。
脚本构建
- 配置完成后，选择cicd，进入cicd页面，首先选择新增cicd，然后会弹框，在弹框中选择你开发的分支，然后选择构建，这个时候构建记录会是打包中状态，然后等1到3分钟，刷新当前页面，查看状态是否为打包成功，如果为打包失败需要检查代码问题，如果是打包成功，操作栏会有同步操作；
- 此次新增：在构建页面新增了构建日志和操作人两列信息。
-
- 构建日志：点击详情会跳转到gitlab cicd日志详情（此次新增功能）
- 操作人：会记录此次操作的具体人员，有问题及时联系相应同学（此次新增功能）
脚本发布
一次性全量发布（已有能力）
- 当打包成功后，操作栏会有同步操作，点击同步，将当前打包的版本同步到集群。
- cicd同步成功后，回到集群管理页面，这时点击操作里的发布操作，发布成功后，发布会变成同步，然后点击同步，同步成功后，这是集群中就已经加载到集群中，这就需要去ab实验配置具体的脚本然后验证。
灰度发布
1. 通过cicd页面，构建完jar包后，点击右侧【灰度发布】按钮。
2. 跳转到灰度发布页面
- 基本信息如图显示，看图。
- 发布间隔：第一批次5%,二批次30%,三批次60%,四批次100%; 当前流量xxx%（白名单验证）
- 发布时，可以填写第一批次灰度IP机器，可选。
- 当发布到第几批的时候，页面显示高亮。
- 系统一共默认四批次，首次点击发布是第一批，默认第一批暂停，再次点击发布，后面三批自动发布（间隔30s）
- 如果发现异常变多或者RT变高，可马上回滚，点击回滚即可回滚上个版本。
- 如果一切正常，第四批就是全部推全操作，灰度jar包覆盖基础jar包。
- 发布过程中，灰度的流量可以进行观察相应的QPS、RT、ERROR、和各个阶段召回、排序、打散等核心模块的性能和调用量。
3. 灰度中的jar包，列表表格状态显示灰度流量。
4. 在集群维度，有俩个jar,一个是灰度中的jar, 另外一个是基础base的jar。 表格显示如下：
DIFF评估平台
社区搜索评测平台是面向于内部算法、产品、研发同学使用的评测系统，主要用于建设完善得物社区搜索badcase评估标准体系，致力于提升用户搜索体验和搜索算法问题发现及优化两方面，提供完善的评测解决方案。
核心功能包含：query数据抽取、快照数据抓取、评测数据导出和评测标注结果效果统计分析。
干预平台
搜索底纹词、猜搜词、下拉词在搜索链路的前置环节出现，在用户没有明确的搜索需求时，对激发用户搜索需求有较大的作用，因此，这些场景既是资源位也需要严格把控出词质量。本需求计划在上述场景支持干预能力，支持在高热事件时干预强插，也支持干预下线某些不合适的词。
召回配置平台
在现代的搜索引擎系统中，多路召回是一个非常重要的组件，其决定了搜索引擎的性能和准确性。因此，多路召回的配置和管理，对于搜索引擎系统的性能、稳定性和可维护性来说是至关重要的。
在以前的词分发系统中，多路召回的配置是以JSON字符串的形式存在的。每次修改配置都需要对这个JSON进行手动的编辑，该过程非常耗费时间，随着召回路的增多，配置效率也会越来越低，而且这种方式容易出错。因此，我们需要一种更加高效、可视化的方法来管理和配置多路召回。
为了提高多路召回的配置效率和准确性，我们需要一种可视化的后台工具来替代手动修改JSON字符串的方式。这样的后台工具可以将多路召回的配置以更加直观和可视化的方式展示出来，让配置人员能够直接在页面上进行配置和修改，从而减少手动编辑JSON字符串的错误和繁琐性。
通过使用可视化的后台工具，我们可以方便地管理和配置各种算法和策略，从而大大提高搜索引擎系统的性能和可维护性。可视化的后台工具对于提高搜索引擎的性能和可维护性非常重要，它可以大大简化配置人员的操作难度和减少错误，进一步提高搜索引擎系统的效率、可靠性和灵活性。
单路配置
多路配置
当然还有其他基建和配套工具和基建服务支撑，这里不一一展开了。
六、未来规划
词分发平台作为搜索引擎系统中的核心组成部分，负责管理和分配搜索词汇的处理与召回流程。其架构以灵活性和扩展性为核心，参考图示所示，平台通过模块化设计（如 Java 框架 Spring 容器、词分发平台主工程、依赖注入 Spring 容器、日志调试能力等）支持高效运行。为了适应市场需求的不断变化，未来词分发平台需从以下几个方面持续优化：
- 平台建设：进一步完善灵犀平台功能，包括继承监控大盘，监控维度扩展，召回配置和脚本cicd建设，发布流水线接入等等。
- 基座框架代码和工具完善：脚本框架改造2.0，无缝对接spring容器；构建可维护完善算字库。通过优化现有流程和算法，加速词汇处理与召回的速度，确保平台性能的持续提升。
- 扩展场景：快速接入更多新场景，如商详触达，小蓝词等等。
此外，未来平台将联合算法团队，打破词圈品与品圈词之间的数据孤岛，打通相关链路，从而全面提升词分发平台的智能化与功能性。这一战略将推动平台更好地服务多样化业务需求，为用户提供更精准、高效的搜索体验。
往期回顾
1. R8疑难杂症分析实战：外联优化设计缺陷引起的崩溃｜得物技术
2. 可扩展系统设计的黄金法则与Go语言实践｜得物技术
3. 得物新商品审核链路建设分享
4. 营销会场预览直通车实践｜得物技术
5. 基于TinyMce富文本编辑器的客服自研知识库的技术探索和实践｜得物技术
文 / 子房
关注得物技术，每周更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～
未经得物技术许可严禁转载，否则依法追究法律责任。
