项目背景

商业系统针对商业运营进行了多年深耕,形成了全方位的闭环运营,包括EAM系统(合同管理,租金结算),CDP系统(会员管理,积分结算),灵犀pos(收银系统),EMA系统(卡劵营销,储值卡),BI系统.以及深度接入客流识别系统.
在商业领域做单领域的任务型问答系统,具有得天独厚的条件.且商业体运营人员在某些维度的数据查询场景,是零散化的,需要一个即时方便的,随用随走的数字化助理,来响应这些临时且零散的查询需求.

实现目标

BPMC嵌入IM即时通讯系统、好友列表内置智能助理

目前看是两个功能方向：

  • 一.支持智能问答商业相关的数据指标，如：查询销售、客流、坪效、会员注册数、卡劵核销量、租金等。
    结果信息根据问题类型分别进行文本回复、图片回复、文件回复。

  • 二.支持操作类任务(自动化工作流)：分两种，一种为后台自动执行，如：租金结算、店铺状态变更、会员批处理、员工离职处理（帐号禁用）。
    另一种是针对敏感或复杂操作，将根据用户消息、分析用户目的，自动在portal页面打开相关系统并加载到目标菜单，让用户自行操作。

  • 智能助理项目第一阶段将针对问答指标进行设计实现,如:

    • Q: 优衣库今天的销售是多少?
    • Q: 今年全场客流有多少?
    • Q: 本月销售前三店铺是那些?

整体实现流程

IM系统内置助理帐号 -> 助理帐号接收消息-> 触发文本分析 -> 执行相关操作/查询 ->组装结果内容 -> 回复消息

相关问答系统调研

dialogue

目前主流问答系统分三种，一是检索式问答系统，二是生成式问答系统,三是任务型问答系统。

检索式问答系统

机器人的回答是预先设置好的，在聊天时机器人使用规则引擎、模型匹配或机器学习生成好的模型从知识库中挑选一个最佳答案给用户，需要在机器人引擎后台中建立一个知识库。优点在于回答质量比较高，缺点在于需要预先准备的知识库足够完整。

  • 简单流程：Query的简单理解——从知识库检索召回——相似度排序

  • 类似系统

生成式问答系统

生成式机器人不依赖于提前定义的回答，机器人接收到用户输入的自然语言后，将采用自然语言生成技术生成一段话作为应答。优点是可以涵盖任何话题，缺点是生成的句子质量可能存在问题，比如出现语法和语义问题。

  • 简单流程： Query的复杂理解（涵盖领域、意图）——对话管理（根据识别的领域进行知识模版/策略的构建）——自然语言生成（以文本形式将策略返还给用户）
  • 类似系统有微软小冰,以及最近爆火的ChatGPT.
    img_4.png
任务型问答系统

任务型对话系统面向垂直领域，目的是使用尽可能少的对话轮数帮助用户完成预定任务或动作，例如预定机票、酒店和餐馆等.大多数任务型对话系统对话数据规模较小，难以通过大量数据进行模型 训练，前期需用手工制定的规则解决冷启动问题，这使得对话系统的构建变得昂贵和耗时.
目前工业界有两种实现方式，一种是基于规则的实现方式，另一种则是基于End-to-End的实现方式。
基于End-to-End的实现方式试图训练一个从用户端自然语言输入到机器端自然语言输出的整体映射关系，从而提高系统的灵活性与可拓展性，但该模型对数据的质量和数量要求非常高，并且存在不可解释性，因此，目前工业界大多采用基于规则的实现方式。
任务型问答系统


  • 类似系统

自然语言转sql方式：

显然我们的需求绝不是生成式问答系统，也不完全是检索式问答系统。与我们后期计划实现的自动化操作的方向也不符,我们的产品需求其实属于任务型对话,但是任务型对话往往是多轮对话,针对一期需求,我们只需要简单的单轮对话即可,属于这么个流程:

Q: “优衣库今天的销售是多少”

提取关键词: “优衣库” “今天” “销售”

根据关键词生成并执行sql : “select sum(order_amount) from sale_data where shop = ‘优衣库’ and order_date = now()::date”,

返回结果,end;

于是进一步去查了下自然语言转sql的现有方案:Text to sql。

从本任务涉及的数据来看，用户输入为自然语言问题，可利用的数据有数据库、SQL关键词，输出为SQL查询语句，
本质上是一个符合语法、有逻辑结构的序列。所以，sql的构成来自三部分：

  • 自然语言问题：结合数据库，一般可以直接抽取出sql中需要的表名，列名，条件表达式，条件值
  • 数据库：结合自然语言问题，一般用于辅助识别sql中需要的表名，列名，条件表达式，条件值
  • SQL关键词：作为sql查询语句的候选token，用于生成sql.
    所有工作都在完成基于上述三部分数据来生成一个可在给定数据库中执行以获取正确结果的sql。

根据SQL执行的复杂程度，可以将其分为简单SQL和复杂SQL。
简单SQL只涉及少数的SQL关键字和组成部分，典型特征是可以拆分为“SELECT”和“WHERE”两个片段。
简单SQL语句都可以抽象成如下的模板：

img_6.png

  • SELECT描述选择哪些列，并对这些列分别做什么操作，决定了最终选择的结果
  • WHERE描述选择的方法或者条件，决定这些列哪些单元格能被选择出来
  • AGG表示聚合函数，如求max，计数count，求min
  • COLUMN表示需要查询的目标列
  • WOP表示多个条件之间的关联规则“与/或”
  • 三元组 [COLUMN, OP, VALUE] 构成了查询条件，分别代表条件列、条件操作符（>,=,<等）、条件值（从问题中抽取出的文本片段）
  • *表示目标列和查询条件不止一个！

调研结论

本次调研主要对问答系统做了初步了解,对Text to sql的简单sql分析的实现思路做了学习,获取很多新思路,因为本需求实现为单领域单轮对话系统,尚属初步阶段,所以实现起来复杂度要尽可能的低,所以不考虑直接引入机器学习等成本较高的方案,基于以上调研,结合需求的具体场景,设计了以下方案来评估可行性.

实现方案

概述

本方案主要针对语言解析实现,在标准词库的基础上,补充领域词库,如店铺名称,业务名词,业态名称等,通过对用户语句进行分词,来进行领域匹配,如果是业务查询域,进行槽位补充,得到可执行sql,进行返回.

整体流程图

在某些特定领域缺失判断时,可默认设置一个选项,比如:优衣库销售是多少? 缺失时间条件,可默认按照当日处理.(槽位补充)

整体流程图

领域分析模块词库匹配关系示意图

通过词库匹配关系,拿到一个sql所需要的元素,如查询目标表,查询字段,查询条件.
领域分析模块词库匹配关系示意图

结语

在动手做demo实验可行性.

参考资料及引用:

任务型对话系统研究综述
万字综述Text to SQL技术
NLP: 基于文本语义的智能问答系统

本文作者：Lee
本文地址： leeblog.icu/2023/01/28/
版权声明：本博客所有文章除特别声明外，均采用 CC 4.0 BY-NC-SA 许可协议。转载请注明出处！