58商业搜索场景中的算法实践
导 读
随着产业化的深入,商业搜索场景需要更深入理解业务,与业务结合。本文将介绍商业搜索场景中,围绕用户体验和商业收入提升,所做的技术迭代和升级。第一部分重点介绍业务场景和业务中的问题;第二部分介绍知识图谱的挖掘和应用;第三部分介绍大模型如何在知识图谱场景中进行应用和落地。
商业搜索场景介绍
2.1 用户入口
-
• 生活服务:搬家、开锁、空调维修、管道疏通
-
• 租房买房:看小区租金、查房源房价
-
• 找工作:普工、电工、保洁员、外卖员
对应不同的用户需求,商家提供什么?
-
• 生活服务:到家到店服务 -
• 房产:房源信息
-
• 招聘:招聘岗位、招聘要求
平台提供什么?
-
• 链接用户和商家,满足用户需求,保障用户与商家的权益
-
• 通过链接用户与商家,向商家收取广告费用
2.3 行业搜索场景
行业内不同搜索场景有不同业务特性,下图为百度搜索,美团搜索,淘宝搜索场景的示例。对于网页搜索偏向于泛搜索,内容无结构化信息。对于餐饮和商品搜索,则偏向垂类搜索,其内容有结构化信息。
图2: 百度搜索,美团搜索,淘宝搜索场景的示例
图3: 不同业务在58商业搜索场景上的差异
2.5 黄页搜索场景中的问题
下文主要针对黄页搜索业务进行展开:
图4: 商家信息未结构化示例
2. 相关性不足
2.6 解法:业务知识结构化
知识图谱赋能
3.1 知识图谱介绍
分类层:抽象实体类别;包括服务实体、工种实体、服务对象实体、服务承诺
原子实体层:服务的最细粒度拆分
复合实体层:原子实体聚合后的实体
用户需求层:用户原始搜索需求
图5: 知识图谱结构
3.2 知识图谱挖掘
问题定义:NER(命名实体识别)。与传统 NER 不同的是,我们需要自定义一个实体类别,即服务实体
服务实体定义:商家所提供服务,一般为动名词组合;如冰箱维修,开锁,搬家,管道疏通
服务实体的挖掘,经历4个版本的迭代
图6: 服务实体挖掘的4个迭代
-
• 挖掘来源:热门搜索词
-
• 方案:传统机器学习模型 CRF
-
• 问题:挖掘准确率较低;75%+
第一阶段,使用传统模型 CRF 进行实体识别,使用语料来源于热门搜索词,其准确率相对较低(75%),因此经过人工审核。上线后头部相关性提高,通过提高用户体验带来了商业收入提升。本阶段通过快速上线,验证了结构化信息的作用。
-
• 挖掘来源:商家描述中的标题,文本长度较短 -
• 方案:Electra+CRF;其中 Electra 为 Bert 变种,挖掘性能更好一些 -
• 问题:序列标注方案无法识别非连续实体
通过 Electra + CRF 的方案,大幅提高准确率(90%),并将实体库数量扩充到 10w+;此时,文本中的大部分实体可通过直接匹配的方式进行识别。
经过数据分析,实体召回能覆盖70%曝光,但依然有30%曝光未被覆盖。分析这部分曝光内容,发现序列标注方案无法覆盖非连续实体。例如【本公司提供空调、冰箱、洗衣机等家电维修服务】,直接匹配只能匹配到【家电维修】实体,而【空调维修】、【冰箱维修】、【洗衣机维修】这些实体,需要通过语义进行挖掘。
3. 第三阶段:大模型实体挖掘
-
• 挖掘来源:商家描述中的详情;文本长度比较长
-
• 方案:GLM3微调;使用该场景实体数据构造 Prompt 进行微调
相对于传统模型,大模型的语义理解能力更强,且生成范式可以解决非连续实体挖掘的问题。通过构造业务 prompt 数据微调,准确率可以达到 92%;经过第三阶段,实体召回曝光占比得到进一步提高。
-
• 挖掘来源:商家相册中服务实体
-
• 方案:PaddleOCR;通过 OCR 提取图片中文本,然后再进行实体识别
总结:
经过 4 个版本的迭代,我们通过完善图谱,将服务数据结构化,从而提高了搜索结果的相关性,对用户体验有很大的提升,因此带来了商业收入与链接的提升。
3.2.2 同义实体挖掘
方案:训练时,人工标注的同义对作为正样本,随机抽样实体对作为负样本,通过 Bert 模型同义对分类模型;推理时,先从实体库中用 fasttext 粗筛一批候选同义对,再经过训练好的 Bert 模型,根据阈值取 TopN
图7: 同义实体挖掘架构
3.3 知识图谱应用
挖掘出的服务实体和实体同义落地于搜索场景的召回、排序、相关性过滤、创意、投放各个链路中
图8: 知识图谱应用流程
大模型助力知识图谱升级
随着大模型时代的到来,NLP领域迎来新的升级。
-
• 语义理解能力更强 -
• 少样本学习能力更强
-
• 生成范式可以适配各种 NLP 任务
-
• 开源大模型能力不断升级
可以考虑升级大模型的业务场景:
-
• 需要大量数据标注 NLP 任务 -
• 复杂 NLP 任务
我们在知识图谱中对应2个场景适合进行升级:
-
• 服务实体挖掘场景,NER任务需要较多标注数据,借助大模型可以减少标注成本 -
• 服务承诺挖掘场景,该场景需要更强的语义理解能力,大模型可以更好的完成任务
4.1 服务实体挖掘
图9: 服务实体挖掘示例
针对此类问题,我们通过大模型对详情文案中实体进行挖掘。考虑到微调需求以及算力性价比因素,大模型选择 GLM3 的 6B 模型,一张3090显卡即可进行微调实验。微调方式使用了开源方案中默认的 ptunningv2。
-
• 根据对话的 badcase,提供一些约束规则。例如商家描述中有时会携带地名,可以在规则中禁止返回地名 -
• 在 prompt 中提供一个挖掘的示例
我们最终的提示词如下:
prompt:
你是一个出色的文本关键词提炼工具,我是一个寻找本地生活服务的用户,正在从商家描述中寻找商家可提供的服务项目。商家服务项目是商家可提供的服务内容,可以解决我遇到的生活难题,如"同城搬家"、"附近开锁";商家服务项目不是商家提供服务项目时提供的服务承诺或者商家的服务特色。请你根据上述我对商家服务项目的定义,帮助我从商家文本提取商家服务项目关键词。
要求:
1)充分理解商家的描述内容,遵从商家描述原文描述;
2)禁止输出重复的商家服务项目关键词;
3)禁止输出商家的服务承诺,如"上门服务"、"安全承诺";
4)输出的词是由动宾结构组成的复合短语,每个短语都描述了一种具体的服务或行为,如"维修自动门"、"同城搬家"、"道路救援";
5)输出格式要求:输出的服务项目使用","分割,并以"关键词"开头输出;
6)禁止输出地名的词,如"成都"。
回答后,不需要输出你回答内容的原因。
以下是一个示例,以便你更好地理解我的诉求:
示例:
以下是一个商家描述:
高价回收黄金首饰、铂金钯金、足金回收千足金、金条项链手镯耳环戒指、钻戒。支持上门回收丨黄金免费上门无上门费 免费鉴定 不压价国际行情价黄金、金银首饰回收【黄金】1、黄金回收:千足金、足金、24k、22k金、20k金、18k金、万足金、14k金、金条、金砖等所有黄金。
关键词:
回收黄金首饰、回收铂金、回收钯金、回收千足金、回收金条、回收项链、回收手镯、回收耳环、回收戒指、回收钻戒、回收黄金、回收金银首饰、足金回收、金条回收、金砖回收
以下是一个商家描述:{商家描述}
response:{人工标注服务实体}
可以看到随着训练样本数增加,准确率可以线性增长。但有一定天花板,这跟大模型容量有关。
最终离在线训练推理流程如下图:
-
• 离线构造微调样本后,微调大模型
-
• 推理侧定时获取每日新增商家内容信息,进行推理,输出帖子与服务实体关系
4.2 服务承诺挖掘
背景:挖掘商家服务实体过程中,发现商家描述信息中有一些承诺信息未结构化,希望将其挖掘后在列表页露出展示给用户,一方面可以展示商家的优点,另一方面方便用户筛选商家。
图13: 服务承诺定义示例
该场景面临的挑战:
-
• 相对于服务实体,承诺挖掘无明显规则,更偏语义理解
-
• 小数据量下微调,准确率不足
大模型挖掘方案:
-
• 分段式抽取;对于复杂任务,思维链模式下效果更好;因此先生成摘要,再抽取承诺;与服务实体相同,进行 1shot 提示
-
• 分类目挖掘;因为不同类目下商家描述格式有所不同,模型学习不够全面,因此准确率只能到80%+;分类目微调,每个类目300个样本进行微调后,准确率可收敛到90%+;因为黄页类目有200+,我们只选取 Top 类目进行微调
该项目推全后,带来的业务收益为Cash/UV+10%;APP展示效果如下:
总结:
在大模型落地的2个场景中,通过优化用户体验,带来10w+/日的商业收益。但大模型升级中依然面临一些技术挑战。大模型落地过程中,优先考虑将准确率提升到90%+,但长文本下有召回率不足的问题,未来需要通过加强大模型对长文本的理解进行优化,对此我们将结合业务场景,持续进行探索。
参考文献:
[1] BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding
[2] ELECTRA: Pre-training Text Encoders as Discriminators Rather Than Generators
[3] NER进展:https://samhe666.github.io/NLP-NER%E8%BF%9B%E5%B1%95/
[4] GLM3:https://github.com/THUDM/ChatGLM3
作者简介:
杨崇,用户价值中心-内容算法部负责人,主要负责业务知识图谱建设和落地工作
本文分享自微信公众号 - 58技术(architects_58)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
eBPF 零侵扰分布式追踪 3 分钟锁定 Java 程序 I/O 线程阻塞
摘要: I/O 线程阻塞是Java 程序经常出现的问题之一,此类故障发生时 Java 程序的请求、响应在 I/O 线程向操作系统 Socket Buffer 读/写过程中发生阻塞,由于在业务代码插桩无法观测到 I/O 线程的工作情况和性能表现,因而导致故障非常隐蔽和难以诊断定位。通过本篇案例您将了解到,某银行的开发工程师如何使用 eBPF 技术带来的零侵扰追踪能力,在某次分布式核心交易系统上线信创平台的非功能测试(性能压测)故障诊断中,用 3 分钟时间锁定 Java 程序 I/O 线程阻塞。 0x0: 故障背景 近期,某银行 的分布式核心交易系统 XX 中心业务按计划即将上线华为信创云 ,但在上线前的非功能测试(性能压测)过程中,业务响应时延不定时劣化,原因不明。 XX 中心的业务程序使用 Java 语言开发(SOFARPC 框架),采用 Netty 作为网络框架,该业务流程涉及 Client、Gateway、App-1、App-2,端到端业务访问路径如下: 1)Client 使用 SOFARPC 协议访问 Gateway 的接口; 2)Gateway 经过七层负载均衡将 SOFARP...
- 下一篇
查询 ps.data_locks 导致 MySQL hang 住
官方在 8.0.37 中修复了这个 bug,可升级到 8.0.37 解决。 作者:胡呈清,爱可生 DBA 团队成员,擅长故障分析、性能优化,个人博客:[简书 | 轻松的鱼],欢迎讨论。 爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 本文约 1500 字,预计阅读需要 8 分钟。 问题描述 MySQL 版本:8.0.26 跑批执行到 insert into t1 select * from t2 时,有一个定时任务运行 MySQL 巡检脚本,巡检脚本执行到 select * from performance_schema.data_locks、select * from performance_schema.data_lock_waits 会导致 MySQL hang,一开始只是某些 SQL 执行无响应,最终 MySQL 无法登录。 分析过程 1. 开始 hang 时的线程状态 下图标记的两个线程中: 第一个线程完整的 SQL 是 insert into t1 select * from t2 第二个线程完整的 SQL 是 select * from pe...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- 2048小游戏-低调大师作品
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- Hadoop3单机部署,实现最简伪集群