├── .gitignore ├── README.md ├── 什么是我所说的ConversationalRobot ├── PrincipalComponentsOfASpokenDialogSystem.png ├── README.md ├── ThePrincipalDialogueActsUsedByTheHISSystem.png ├── TraditionalPipelineForTask-orientedSystems.png ├── 从人机交互的角度看ConversationalRobot.graphml ├── 从人机交互的角度看ConversationalRobot.png ├── 从机器人的角度来看ConversationalRobot.graphml └── 从机器人的角度来看ConversationalRobot.png ├── 从手动到自动发展的对话系统 └── README.md ├── 各种机器人平台调研.md ├── 对话机器人技术简介：问答系统、对话系统与聊天机器人 └── README.md ├── 对话机器人设计简述.md ├── 对话系统：自然语言生成 └── README.md ├── 流程细节.md └── 聊天机器人：神经对话模型的实现与技巧 └── README.md /.gitignore: -------------------------------------------------------------------------------- 1 | papers 2 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | **Table of Contents** _generated with [DocToc](https://github.com/thlorenz/doctoc)_ 5 | 6 | - [Conversational Robot](#conversational-robot) 7 | - [名词解释（非专业，非官方，非权威）](#%E5%90%8D%E8%AF%8D%E8%A7%A3%E9%87%8A%E9%9D%9E%E4%B8%93%E4%B8%9A%E9%9D%9E%E5%AE%98%E6%96%B9%E9%9D%9E%E6%9D%83%E5%A8%81) 8 | - [对话系统(dialogue system / dialog system)](#%E5%AF%B9%E8%AF%9D%E7%B3%BB%E7%BB%9Fdialogue-system--dialog-system) 9 | - [问答系统(question answering system)](#%E9%97%AE%E7%AD%94%E7%B3%BB%E7%BB%9Fquestion-answering-system) 10 | - [问答对(QA pairs)](#%E9%97%AE%E7%AD%94%E5%AF%B9qa-pairs) 11 | - [基于知识的问答(knowledge based QA)](#%E5%9F%BA%E4%BA%8E%E7%9F%A5%E8%AF%86%E7%9A%84%E9%97%AE%E7%AD%94knowledge-based-qa) 12 | - [基于检索的问答（Retrival-based QA）](#%E5%9F%BA%E4%BA%8E%E6%A3%80%E7%B4%A2%E7%9A%84%E9%97%AE%E7%AD%94retrival-based-qa) 13 | - [一个简单搜索回答的流程](#%E4%B8%80%E4%B8%AA%E7%AE%80%E5%8D%95%E6%90%9C%E7%B4%A2%E5%9B%9E%E7%AD%94%E7%9A%84%E6%B5%81%E7%A8%8B) 14 | - [其他类型问答](#%E5%85%B6%E4%BB%96%E7%B1%BB%E5%9E%8B%E9%97%AE%E7%AD%94) 15 | - [聊天机器人（chatbot）](#%E8%81%8A%E5%A4%A9%E6%9C%BA%E5%99%A8%E4%BA%BAchatbot) 16 | - [DeepQA](#deepqa) 17 | - [人工智能标记语言，AIML](#%E4%BA%BA%E5%B7%A5%E6%99%BA%E8%83%BD%E6%A0%87%E8%AE%B0%E8%AF%AD%E8%A8%80aiml) 18 | - [基于深度学习 Sequence to Sequence 的聊天机器人](#%E5%9F%BA%E4%BA%8E%E6%B7%B1%E5%BA%A6%E5%AD%A6%E4%B9%A0sequence-to-sequence%E7%9A%84%E8%81%8A%E5%A4%A9%E6%9C%BA%E5%99%A8%E4%BA%BA) 19 | - [一个完整的 Conversational UI（平台）需要的东西](#%E4%B8%80%E4%B8%AA%E5%AE%8C%E6%95%B4%E7%9A%84conversational-ui%E5%B9%B3%E5%8F%B0%E9%9C%80%E8%A6%81%E7%9A%84%E4%B8%9C%E8%A5%BF) 20 | - [Dialogue System / Conversational UI 可能的资料](#dialogue-system--conversational-ui-%E5%8F%AF%E8%83%BD%E7%9A%84%E8%B5%84%E6%96%99) 21 | - [平台](#%E5%B9%B3%E5%8F%B0) 22 | - [国外](#%E5%9B%BD%E5%A4%96) 23 | - [国内](#%E5%9B%BD%E5%86%85) 24 | - [开源实现（机器人相关）：](#%E5%BC%80%E6%BA%90%E5%AE%9E%E7%8E%B0%E6%9C%BA%E5%99%A8%E4%BA%BA%E7%9B%B8%E5%85%B3) 25 | - [厂家](#%E5%8E%82%E5%AE%B6) 26 | - [微软](#%E5%BE%AE%E8%BD%AF) 27 | - [亚马逊](#%E4%BA%9A%E9%A9%AC%E9%80%8A) 28 | - [剑桥大学](#%E5%89%91%E6%A1%A5%E5%A4%A7%E5%AD%A6) 29 | - [脸书](#%E8%84%B8%E4%B9%A6) 30 | - [Linkdin](#linkdin) 31 | - [作者的其他相关链接](#%E4%BD%9C%E8%80%85%E7%9A%84%E5%85%B6%E4%BB%96%E7%9B%B8%E5%85%B3%E9%93%BE%E6%8E%A5) 32 | 33 | 34 | 35 | # Conversational Robot 36 | 37 | 作者不保证任何此 repo 内容的权威性， 38 | 对权威性又苛求，又对内容抱有兴趣的人， 39 | 您可以先参考斯坦福的[这本书 28~30 章](http://web.stanford.edu/~jurafsky/slp3/) 40 | 41 | 这个 repo 会记录我对 Conversational Robot 的理解、学习、研究、设计、实现的相关内容 42 | 43 | 如果有疑问、质疑、讨论需求： 44 | 45 | mail (a) qhduan.com 46 | 47 | 微信 longinusd 48 | 49 | 文章列表： 50 | 51 | [对话机器人技术简介：问答系统、对话系统与聊天机器人](/对话机器人技术简介：问答系统、对话系统与聊天机器人) 52 | 53 | [聊天机器人：神经对话模型的实现与技巧](/聊天机器人：神经对话模型的实现与技巧) 54 | 55 | 施工中，有生之年系列： 56 | 57 | 对话系统：~~自然~~语言理解 58 | 59 | 对话系统：对话策略管理 60 | 61 | 对话系统：自然语言生成 62 | 63 | 对话系统：完整对话系统构建 64 | 65 | 聊天机器人：模板模型与 AIML 简介 66 | 67 | 问答系统：文本检索模型 68 | 69 | 问答系统：知识模型 70 | 71 | 完整机器人实现 72 | 73 | # 名词解释（非专业，非官方，非权威） 74 | 75 | ## 对话系统(dialogue system / dialog system) 76 | 77 | 特指 Task-oriented dialogue system ，也就是为了完成一种任务而发明的系统。 78 | 这种任务的特征往往有： 79 | 80 | - 结果唯一，例如买一张机票，订一场电影，买一杯咖啡 81 | - 任务需要多项要素，例如机票需要时间、起始地、到达地；电影需要名称、电影院、场次时间；咖啡需要时间、大杯小杯、口味 82 | - 任务需要通过多轮对话、多轮反复确认达成，例如：你要大杯的咖啡还是小杯的？你需要几点送？你确定要 9 点送？ 83 | 84 | 主流对话系统研究集中在 GUS-style frame-based 类型的对话系统 85 | 86 | GUS对话系统，是 Genial Understander System 的缩写，可以追溯到1977年的论文(Daniel G. Bobrow, GUS, A Frame-Driven Dialog System, 1977) 87 | 88 | ## 问答系统(question answering system) 89 | 90 | ### 问答对(QA pairs) 91 | 92 | 也就是问题是一句话，回答是确定的一个词、一句话。 93 | 94 | 训练数据是纯粹的一问一答，类似各种 FAQ。 95 | 96 | 此类也被称为 Answer selection，Answer ranking，Answer sentence selection 97 | 98 | 这种绝对不叫做“Knowledge based QA”，因为一问一答的数据， 99 | 不构成知识，知识必须是有结构的、有属性的、互相有关联的数据。 100 | 101 | Answer sentence selection is the task of identifying sentences that contain the answer to a given question. This is an important problem in its own right as well as in the larger context of open domain question answering.(Lei Yu, Deep Learning for Answer Sentence Selection, 2014) 102 | 103 | We present a question answering (QA) system which learns how to detect and rank answer passages by analyzing questions and their answers (QA pairs) provided as training data.(Ganesh Ramakrishnan, Is Question Answering an Acquired Skill?, 2004) 104 | 105 | ### 基于知识的问答(knowledge based QA) 106 | 107 | 学术上基本不区分基于知识的，还是基于知识图谱的（knowledge graph），因为知识图谱是谷歌提出的一个较商业概念。知识在传统上就是三元组，或类似的图结构，而知识图谱也是如此。 108 | 109 | 这种方式，需要你提供一个知识库，例如一堆有关联的三元组（Triples），它们可以存储于普通数据库或者专门的图数据库（graph database），或者语义网相关的 RDF 数据库。 110 | [Wikipedia Triplestore](https://en.wikipedia.org/wiki/Triplestore) 111 | 112 | 输入是自然语言，上下文是知识库，结果往往是知识库中的一个关系或者一个实体。 113 | 114 | 例如有知识库（三元组）： 115 | 116 | (中国，有首都，北京) 117 | (北京，是某国的首都，中国) 118 | 119 | 三元组的结构是（主，谓，宾）， 120 | 实际上是（实体，属性，属性值）， 121 | 或者（实体，关系，实体）结构。 122 | 代表了一种两个节点，一个有属性的边的有向图结构。 123 | 124 | 那么就可以解答用户输入“中国的首都是哪”，“北京是哪个国家的首都”，“中国与北京的关系”，这样的问题。 125 | 这三个问题分别相当于查询(中国，有首都，？)，(北京，是某国首都，？)，(中国，？，北京)， 126 | 其中问号“？”代指一种我们暂时不知道的变量，这种查询思想就是 SPARQL 的思想之一。 127 | 128 | 为什么这是图结构，例如： 129 | 130 | (何云伟，师傅，郭德纲) 131 | (曹云金，师傅，郭德纲) 132 | (何云伟，师兄弟，曹云金) 133 | 134 | （师傅代表“有师傅”，或者 has 师傅，师兄弟类似） 135 | 136 | 上面三个实体，2 种关系，构成了一个三角形的图。 137 | 所以这并不是简单的二维表模式（关系数据库模式）， 138 | 也不是树模式，因为兄弟节点有连接。 139 | 140 | （严格来说应该是有向图模式；图模式依然可以用传统数据库，如 SQL、KV 数据库来保存） 141 | 142 | ### 基于检索的问答（Retrival-based QA） 143 | 144 | 也可以说是 Text-based 的 145 | 146 | 问答输入是用户的一个问题，而上下文是一个或多个文字信息碎片。 147 | 148 | 例如我们有百度百科关于“北京”的文章，假设我们并没有将这个文章知识化（三元组化）， 149 | 但是我们可以通过用户提问的关键字，预测用户可能期望的结果，从这个文章中找到答案。 150 | 151 | #### 一个简单搜索回答的流程 152 | 153 | 假设用户问“北京的面积”。 154 | 155 | 首先我们把这个问题进行一定变形，例如重点词是“北京”和“面积”。 156 | 我们也可以对词进行同义词扩展，例如扩展成：北京，中国首都，面积，大小 157 | 158 | 然后我们推理结果是，用户所需的回答类型应该是某个数字（代表面积的数字）。 159 | 160 | 之后我们可以检索已有数据中和“北京”、“面积”相关的文章（这部分也可以利用搜索引擎，或者百科类网站）。 161 | 162 | 有了这个文章作为上下文，我们就从文章中找到最接近问题的段落， 163 | 并在段落中根据语义、答案类型等信息，提取出真正的答案，可能是一个实体、一个属性、或者一个短句。 164 | 165 | ### 其他类型问答 166 | 167 | 例如输入一个图片，一个用户问题，用户询问“图上有什么”，“图里有谁”，“图里有苹果吗”。 168 | 也就是系统要根据图片内容和用户提问，做出一定程度的描述或推理。 169 | 170 | 例如输入一段文章，一个用户问题，就好像做语文、英语的阅读理解那样的问答， 171 | 用户的问题就好像是阅读理解的选择题或者填空题。 172 | 这也算是机器阅读理解的课题。 173 | 174 | 学术上，问答也可以分为 Factoid QA 和 Non-factoid QA。 175 | Factoid 就是答案往往是某个事实实体、简单的属性、关系的。 176 | 例如地球到月亮有多远，中国有大面积，美国有多少人口这样。 177 | 178 | Non-factoid 可以包含 Factoid 问题，答案可以更发散。 179 | 例如描述下这辆车，计算这道数学题，给我你针对这件事儿的见解，给我提意见等等， 180 | 这样答案并不明确或者并不是一个明确事实实体、关系的问答。 181 | 182 | 一般基于知识（库）的问答都是说 Factoid QA。 183 | 184 | ## 聊天机器人（chatbot） 185 | 186 | 也可以被成为 Non-task-oriented dialogue system，或者 General dialogue system。 187 | 188 | 此类系统不需要完成一个明确任务（和上面的对话系统相反），它的存在目的往往只是为了尽可能的延长对话，并且完成一些的模糊的目标。例如排解用户无聊，打发时间，一些隐含的心理状况分析，鼓励用户，讨好用户。 189 | 190 | 著名的 Alice 机器人中的一个模板，很好的描述了它的设计目的（bot.aiml)： 191 | 192 | 问："what do you need" 193 | 答："I would like to have a longer conversation with you." 194 | 195 | 翻译（东北）： 196 | 197 | 问：你要干哈啊？ 198 | 答：我想跟你多唠会儿磕。 199 | 200 | ## DeepQA 201 | 202 | DeepQA 一般指 IBM 开发的问答系统，它跟 deep learning 半分钱关系都没有。如果你觉得它跟 deep learning 有关系，可以想想 deep blue，就是那个 IBM 造出来下国际象棋的那个。 203 | 204 | 既然是 QA 系统，也就是说它既不能帮你买咖啡也不能帮你订机票，它就只是一个问答系统。 205 | 206 | 它应用了很多问答系统的技术、技巧、工程方法，和海量的数据，DeepQA 并不是一个你能简单用得到的系统，它既不免费，也不开源。 207 | 208 | ## 人工智能标记语言，AIML 209 | 210 | 它的最简单的例子是这样的： 211 | 212 | ```xml 213 | 214 | YOU CAN DO BETTER 215 | 216 | 217 | ``` 218 | 219 | 问题是“you can do better”，机器人会回答“ok, i will try”。 220 | 221 | 当然实际上这个模板语言可以完成很多复杂的功能，包括而不限于：计算（例如 1+1=？），数据库查询（通过调用其他接口），一些简单的嵌套等等。 222 | 223 | 我可以很明确的说，这套系统基本上没什么用处，因为书写成本高，语法复杂，XML 并不人类可读，优化少，相关资源很少，几乎很少的工业界支援，几乎已经被学术界放弃。 224 | 225 | 注意我说的是 AIML 没用，没说模板方法没用，模板方法依然是现在构建一切 bot 最重要最重要最重要没有之一的手段。 226 | 227 | 这里列出几个你应该看看的 AIML 的代替品： 228 | 229 | [RiveScript](https://www.rivescript.com/) 230 | 231 | [SuperScript](https://github.com/superscriptjs/superscript) 232 | 233 | [ChatScript](https://github.com/bwilcox-1234/ChatScript) 234 | 235 | ### 基于深度学习 Sequence to Sequence 的聊天机器人 236 | 237 | 它本质是脱胎于神经机器翻译技术（Neural Machine Translation），也就是说本质是把机器翻译的一种语言的一句话到另一种语言的一句话的生成，改为聊天中上一句话到下一句话的生成。 238 | 239 | 它几乎没什么用，甚至说都建议你先去看 AIML 是什么，都比在这耽误时间可能来的要好。 240 | 241 | 因为它：结果不可靠、质量不可控，高质量数据集少，trick 多，对系统能补足的程度小，工程时间成本高，太过独立很难与其他部分契合，人格不一致，结果发散性低…… 242 | 243 | 并不是嘛玩意儿沾点深度学习就是好。 244 | 245 | # 一个完整的 Conversational UI（平台）需要的东西 246 | 247 | 非官方、非权威、非专业！！！ 248 | 249 | - ！ 易用、易学的 QA Pairs 管理与查询引擎 250 | - 用于机器人管理者简单定义类似 FAQ 的问答，例如“怎么退货”这种有一个固定回答问题 251 | - ！ 易用、易学的对话模板生成管理方法（用于生成可能的用户说的话） 252 | - 机器人管理者用于生成针对对话系统（任务）的对话 253 | - ！ 足够使用的 NLU 部件 254 | - 内部需要包括其他各种基本组件，例如 intent classification，entity recognization 255 | - ！ 当机器人不准确、失效时，人工代替解决方案 256 | - 最好能即时接入人工，给用户接入人工的手段，即时评价当前对话质量，最低要求是提供其他人工渠道：电话、邮箱、IM 257 | - 足够使用的对话状态跟踪部件与对话策略部件 258 | - dialogue state tracker & dialogue policy 259 | - 易用、易学的自然语言生成模板方法（用于生成机器人的回复） 260 | - 根据当前状态，生成对应回复所需要的模板系统 261 | - 用户行为模拟程序与系统评价程序 262 | - 行为模拟可以用于强化学习，就算不用强化学习，这套系统也是一套标准的集成测试系统 263 | - 良好的自动用户反馈、评价机制 264 | - 用户评价机器人好坏、反馈结果、与用户沟通联系 265 | - 一个良好的、易懂的面向开发人员文档 266 | - 用于帮助专业人员构建更详细、自定义的机器人 267 | - 一个良好的、易懂的面向非专业人员培训文档 268 | - 用户普及知识，做简单的非专业训练，让他能够很好的管理基本问答、知识库 269 | - ～ 基于某种 UI（例如 web）的高级图形管理界面 270 | - 方便非专业人员使用 271 | - ～ 自动的训练程序，例如基于强化学习的 272 | - 未测试 273 | - ～ 足够覆盖基本问答的 chatbot 引擎 274 | - 回答一些非常基本机器人，你是谁，你从哪来，你到哪去，用于最基本的调戏、使用帮助目的 275 | - ～ 高效的 Knowledge-based QA 问答引擎 276 | - 用于更方便的回答例如，这个东西保修几年，这双鞋有多大码的，这种更细节的知识问题 277 | - ～ 一个简易的知识库构建与对接系统（如果需要 Knowledge-based QA 问答引擎的话） 278 | - ～ 较准确的 Retrival-based QA 问答引擎 279 | - 例如用于一些百科知识问答，某些特定领域的文档问答 280 | - ～～ 人类情绪分析部件（NLU 中） 281 | - ～～ 一个基于 Seq2Seq 的 chatbot 引擎 282 | - ～～ 语音识别 283 | - ～～ 人工语言合成 284 | 285 | ！：必须 286 | ～：部分场景可有可无 287 | ～～：可能需要忽略的 288 | 289 | # Dialogue System / Conversational UI 可能的资料 290 | 291 | 下列**不完全** 292 | 293 | ## 平台 294 | 295 | ### 国外 296 | 297 | - wit.ai 298 | - api.ai 299 | - luis.ai 300 | - [Ada Support](https://ada.support/) 301 | - [AIHelp](https://aihelp.net/) 302 | 303 | ### 国内 304 | 305 | - [Chatopera](https://bot.chatopera.com) 306 | - [ruyi.ai](http://ruyi.ai/) 307 | - UNIT 308 | - dueros 309 | - 思必驰 dui 开放平台 310 | 311 | ### 开源实现（机器人相关）： 312 | 313 | - 剑桥的开源 DS [PyDial](http://www.camdial.org/pydial/) 314 | - 一个开源的 DS [deepmipt/DeepPavlov](https://github.com/deepmipt/DeepPavlov) 315 | - 一个商业但开源的 DS [Rasa Core](https://rasa.com) 316 | - 比较简单的机器人[ChatterBot](https://github.com/gunthercox/ChatterBot) 317 | - 一个开源的 QA 系统，里面那个论文列表不错 [castorini/BuboQA](https://github.com/castorini/BuboQA) 318 | - AIML 的公司 [pandorabots](https://home.pandorabots.com/en/) 319 | 320 | ## 厂家 321 | 322 | ### 微软 323 | 324 | 微软的 cortana 应该使用了很多相关技术 325 | 326 | 比较新的论文如 327 | 328 | (Xiujun Li, End-to-End Task-Completion Neural Dialogue Systems, 2018) 329 | 330 | (Jason D. Williams, Hybrid Code Networks: practical and efficient end-to-end dialog control 331 | with supervised and reinforcement learning, 2017) 332 | 333 | 还有数据和比赛： 334 | 335 | [https://github.com/xiul-msr/e2e_dialog_challenge](https://github.com/xiul-msr/e2e_dialog_challenge) 336 | [https://www.microsoft.com/en-us/research/event/dialog-state-tracking-challenge/](https://www.microsoft.com/en-us/research/event/dialog-state-tracking-challenge/) 337 | 338 | ### 亚马逊 339 | 340 | Alexa Prize 相关的有一堆论文，例如下面这篇 341 | 342 | 亚马逊的这些，我觉得更偏从 QA 角度设计 DS 343 | 344 | (Huiting Liu, RubyStar: A Non-Task-Oriented Mixture Model Dialog System, 2017) 345 | 346 | ### 剑桥大学 347 | 348 | 剑桥大学有一个 [Dialogue Systems Group](http://dialogue.mi.eng.cam.ac.uk/) ，里面包括一些这个组发的会议论文 349 | 350 | 他们还有一个项目叫 [PyDial](http://www.camdial.org/pydial/) 2017 下半年的产物 351 | 352 | [还有这些课件](http://mi.eng.cam.ac.uk/~mg436/LectureSlides/) 353 | 354 | ### 脸书 355 | 356 | [BABI 数据集，很多论文使用](https://research.fb.com/downloads/babi/) 357 | 358 | ### Linkdin 359 | 360 | [Linkdin 在 KDD2018 上做的 tutorial 是我认为现在对话系统、QA 最好的一个 tutorial、简单 survey，没有之一（截止 18 年）](https://weibo.com/1402400261/Gw5DIykjj?type=repost#_rnd1535135595967) 361 | 362 | ### 作者的其他相关链接 363 | 364 | [Sequence-to-Sequence 模型的一个实现](https://github.com/qhduan/just_another_seq2seq) 365 | 366 | --- 367 | 368 | graphml 与一些图片文件是使用[yEd Live](https://www.yworks.com/yed-live/)制作 369 | -------------------------------------------------------------------------------- /什么是我所说的ConversationalRobot/PrincipalComponentsOfASpokenDialogSystem.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/qhduan/ConversationalRobotDesign/5bb69d0592228b4a9eeedb9a15b24d35c17d1e69/什么是我所说的ConversationalRobot/PrincipalComponentsOfASpokenDialogSystem.png -------------------------------------------------------------------------------- /什么是我所说的ConversationalRobot/README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | **Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* 4 | 5 | - [导论：什么是我所说的 Conversational Robot](#%E5%AF%BC%E8%AE%BA%E4%BB%80%E4%B9%88%E6%98%AF%E6%88%91%E6%89%80%E8%AF%B4%E7%9A%84-conversational-robot) 6 | - [Conversational Robot 的来历](#conversational-robot-%E7%9A%84%E6%9D%A5%E5%8E%86) 7 | - [简单的来说](#%E7%AE%80%E5%8D%95%E7%9A%84%E6%9D%A5%E8%AF%B4) 8 | - [从人机交互的角度看Conversational Robot](#%E4%BB%8E%E4%BA%BA%E6%9C%BA%E4%BA%A4%E4%BA%92%E7%9A%84%E8%A7%92%E5%BA%A6%E7%9C%8Bconversational-robot) 9 | - [从机器人的角度来看Conversational Robot](#%E4%BB%8E%E6%9C%BA%E5%99%A8%E4%BA%BA%E7%9A%84%E8%A7%92%E5%BA%A6%E6%9D%A5%E7%9C%8Bconversational-robot) 10 | - [内部组件，从Dialogue System的主要骨架说起](#%E5%86%85%E9%83%A8%E7%BB%84%E4%BB%B6%E4%BB%8Edialogue-system%E7%9A%84%E4%B8%BB%E8%A6%81%E9%AA%A8%E6%9E%B6%E8%AF%B4%E8%B5%B7) 11 | - [语音识别（ASR）](#%E8%AF%AD%E9%9F%B3%E8%AF%86%E5%88%ABasr) 12 | - [自然语言理解（NLU or SLU or LU）](#%E8%87%AA%E7%84%B6%E8%AF%AD%E8%A8%80%E7%90%86%E8%A7%A3nlu-or-slu-or-lu) 13 | - [Dialogue State Tracker & Dialogue Policy](#dialogue-state-tracker--dialogue-policy) 14 | - [自然语言生成 NLG](#%E8%87%AA%E7%84%B6%E8%AF%AD%E8%A8%80%E7%94%9F%E6%88%90-nlg) 15 | - [语音合成 TTS](#%E8%AF%AD%E9%9F%B3%E5%90%88%E6%88%90-tts) 16 | - [问答系统 QA System](#%E9%97%AE%E7%AD%94%E7%B3%BB%E7%BB%9F-qa-system) 17 | - [问答匹配 Question & Answer Selection/Matching/Searching](#%E9%97%AE%E7%AD%94%E5%8C%B9%E9%85%8D-question--answer-selectionmatchingsearching) 18 | - [IR-based](#ir-based) 19 | - [Knowledge-based](#knowledge-based) 20 | - [Chatbot](#chatbot) 21 | - [template-based](#template-based) 22 | - [neural-based](#neural-based) 23 | 24 | 25 | 26 | 27 | 28 | # 导论：什么是我所说的 Conversational Robot 29 | 30 | 包括 Dialogue System, QA System, Chatbot 简述。 31 | 下面大部分文字是整体的介绍，当然要完全把这三个部分都详细说完，可能就够一本书了，没几百篇论文的阅读出不来。 32 | 主要是因为每个系统的每个实现方法经常都是独立的一个领域，而很少有介绍完整成品的东西，也几乎没有完整的书籍。 33 | 34 | ## Conversational Robot 的来历 35 | 36 | 主要是为了避免dialogue和chat这两个词。 37 | 38 | Dialogue System 和 Chatbot 都有其比较特定的含义，这里避开他们。 39 | 然后使用了 Conversational 这个词。 40 | 41 | 42 | ## 简单的来说 43 | 44 | 我所定义的 45 | 46 | Conversational Robot = Dialogue System + QA System + Chabot + Other Needed Support Components 47 | 48 | 其中Dialogue System是骨架，其他部分是血肉 49 | 50 | 其实单独来说，每个系统都可以独立存在。 51 | 例如一般的百科全书，如果不严格的讨论，我们可以认为它是一个QA System。 52 | 它本身是很有用的，也可以独立存在。 53 | 54 | 甚至说Chatbot本身，如果应用在心理辅导、婴幼儿陪伴等领域，也可以单独的作为一个应用。 55 | 56 | 而我之所以把Dialogue System作为主要部分，主要是因为我认为机器人存在的目标最主要是完成任务，我认为传统意义上的Dialogue System，本质就是一个Task-Oriented System。这符合我对于 Robot 的哲学理解，即执行任务是第一要务。 57 | 58 | ## 从人机交互的角度看Conversational Robot 59 | 60 | ![从人机交互的角度看ConversationalRobot](从人机交互的角度看ConversationalRobot.png) 61 | 62 | 人与机器有很多交互方式，而语音、语言交互是一项重要的交互方式。 63 | 64 | 自然语言理解（NLP）包括了语音识别，语音合成，文本理解，文本生成等等范畴，可以说从人机交互的角度来说，Conversational Robot 在这里特指语言的理解、生成这一过程的相关部件。 65 | 66 | ## 从机器人的角度来看Conversational Robot 67 | 68 | ![从机器人的角度来看ConversationalRobot](从机器人的角度来看ConversationalRobot.png) 69 | 70 | 从机器人的角度来讲，一个智能体（Intelligent Agent），从外界环境接受信息，这个信息主要的一个信息来源就是人。 71 | 而人能提供例如语音（说话），语言（微信打字），视频（机器视觉），动作（动作、手势识别）等信息。 72 | 73 | Conversational Robot 特指接受语言，或者经过转换的语音数据，根据对文本的理解，产生一些执行操作。 74 | 执行操作可以由其他部件完成。最终把执行结果返回给人的这一个过程的相关部件。 75 | 76 | 77 | ## 内部组件，从Dialogue System的主要骨架说起 78 | 79 | 一个传统的Dialogue System如下图所示 80 | 81 | ![Principal components of a spoken dialog system](PrincipalComponentsOfASpokenDialogSystem.png) 82 | 83 | (Jason D. Williams, The Dialog State Tracking Challenge Series: A Review, 2016) 84 | 85 | 一个更简单的图例如： 86 | 87 | ![Traditional Pipeline for Task-oriented Systems](TraditionalPipelineForTask-orientedSystems.png) 88 | 89 | (Hongshen Chen, A Survey on Dialogue Systems:Recent Advances and New Frontiers, 2017) 90 | 91 | 92 | ### 语音识别（ASR） 93 | 94 | 图中ASR负责识别语音，对于一条用户的语音输入可能有多个结果 95 | 96 | 例如不同识别到的文本和对应的可信度 97 | 98 | 例如用户说（注意是语音）：“我要去上海” 99 | 100 | 结果可能是 101 | 102 | ``` 103 | [ 104 | { 105 | "sentence": "我要去上海", 106 | "score": 0.4 107 | }, 108 | { 109 | "sentence": "我要去商海", 110 | "score": 0.3 111 | }, 112 | { 113 | "sentence": "我要去伤害", 114 | "score": 0.1 115 | } 116 | ] 117 | ``` 118 | 119 | 实际上很多关于对话系统的文章都没有仔细说这部分，这也是显而易见的，因为语音识别有更专门的领域专家去研究。绝大部分系统的假设都是能拿到比较准确的识别结果，至少是像上面那样的的结果列表，之后的工作。类似的，图中的TTS也是一般被忽略。 120 | 121 | ### 自然语言理解（NLU or SLU or LU） 122 | 123 | 这部分在有些资料被称为`SLU`(Spoken Language Understanding)， 124 | 有的资料也称为`NLU`(Natual Language Understanding)，甚至`LU`(Language Understanding)。 125 | 也有一些文献称之为`Semantic Decoding`，因为它的结果也被称为`Semantic Frame`， 126 | 也就是把用户输入的句子（utterance）转换为了一种Semantic Frame，即抽象出了用户所期望行为的语义。 127 | 128 | 这部分主要根据语音输入的结果，判断用户意图。 129 | 130 | 从含义角度来说，输出的是，三个部分内容： 131 | 132 | SLOT(S): 问题所需要的数据参数 133 | 134 | INTENT: 用户意图 135 | 136 | DOMAIN: 问题领域 137 | 138 | 如(Yun-Nung Chen, SYNTAX OR SEMANTICS? KNOWLEDGE-GUIDED JOINT SEMANTIC FRAME PARSING)的例子： 139 | 140 | ``` 141 | W: tell vivian to be quiet 142 | S: contact=vivian, message=be quiet 143 | D: communication 144 | I: send_text 145 | ``` 146 | 147 | 也就是用户输入了`tell vivian to be quiet`之后， 148 | 或者这句话的DOMAIN（D）是`communication`， 149 | INTENT是`send_text`， 150 | 有两个slot， 151 | 分别是联系人`contact=vivian`还有信息内容`message=be quiet` 152 | 153 | 这些内容会被后续的部件处理。 154 | 155 | 156 | --- 157 | 158 | 从一些实际应用的角度来说，这部分LU在一些系统里也被描述为会产生潜在的`user-action`列表。也就是“用户想做什么”的行为列表和每种行为的可能性 159 | 160 | 例如用户输入：“明天晚上的电影”，结果可能是 161 | 162 | ``` 163 | [ 164 | { 165 | "user_action": "request(movie_name, date=tomorrow_night)", 166 | "score": 0.5 167 | }, 168 | { 169 | "user_action": "request(movie_name, date=tomorrow)", 170 | "score": 0.3 171 | }, 172 | { 173 | "user_action": "inform(date=tomorrow_night)", 174 | "score": 0.1 175 | } 176 | ] 177 | ``` 178 | 179 | 这些列表可能类似下面的行为，其中`Usr`列打对号的就是用户可能产生的行为列表，我们以后会在单独的`NLU`相关章节详细探讨这部分内容。 180 | (Steve Young, The Hidden Information State model: A practical framework for POMDP-based spoken dialogue management, 2010) 181 | 182 | ![The principal dialogue acts used by the HIS System](ThePrincipalDialogueActsUsedByTheHISSystem.png) 183 | 184 | 关于这个列表的详细意义与探讨，会在后续的章节进行。 185 | 186 | ### Dialogue State Tracker & Dialogue Policy 187 | 188 | 在某些系统上，这两部分是分离的，在而在很多系统上，实际就是一个部分。也有一些资料把这部分称为Dialogue Management。这部分也被称为Belief Tracking & Policy Optimization / Policy Learning。 189 | 190 | 需要状态管理是因为对话并不仅仅是单轮的，而是需要多轮进行，或者说完成一个任务很可能需要跟用户反复交互。用户很可能修改之前的意图、提供的参数等等内容。如果对话只是一问一答，即当前问题和以前的问题、回答都没关系的话，那实际上就不算Dialogue System，而是QA System了（Question & Answer） 191 | 192 | 系统需要保存之前用户的问题，也要保存自己回答的结果，例如： 193 | 194 | request的格式：`request(a, b=x, c=y,...)` 195 | 即请求参数`a`，并且提供（可选的）参数`b=x`等。 196 | 197 | inform的格式：`inform(a=x, b=y)` 198 | 即提供信息，用户可以向系统提供信息，系统也可以向用户提供信息（答案或查询结果）。 199 | 200 | 举例如下： 201 | 202 | ``` 203 | 用户：我想找北京去上海的火车 204 | 205 | -> user_action: request(车票列表, 起始地=北京, 目的地=上海) 206 | -> sys_action: inform(车票列表=执行部件的答案, 起始地=北京, 目的地=上海) 207 | 208 | 系统回答实例：从北京去上海的车票有xx趟，如下：xxxxx 209 | 210 | 用户：从杭州去的呢？ 211 | 212 | -> user_action: request(车票列表, 起始地=杭州) 213 | -> sys_action: inform(车票列表=执行部件的答案, 起始地=杭州, 目的地=上海) 214 | 215 | 系统回答示例：从杭州去上海的车票有yy趟，如下：yyyyy 216 | ``` 217 | 218 | 假设上面两条是连续的问题，那么系统在回答第二条的时候，用户是没直接提示目的地的（这里是符合自然语言习惯的），那么目的地这个状态，就应该由DST部件存储下来（相当于机器的短期记忆），在一定假设下，补全并猜测到用户的完整意图。 219 | 220 | 在第二次回答中，如果系统并不确定目的地是上海（例如根据某个概率值），那么可能就会产生下面的情况： 221 | 222 | 223 | ``` 224 | 用户：我想找北京去上海的火车 225 | 226 | -> user_action: request(车票列表, 起始地=北京, 目的地=上海) 227 | -> sys_action: inform(车票列表=执行部件的答案, 起始地=北京, 目的地=上海) 228 | 229 | 系统回答实例：从北京去上海的车票有xx趟，如下：xxxxx 230 | 231 | ## 以上部分和上面的例子一样 232 | 233 | 用户：从杭州去的呢？ 234 | 235 | -> user_action: request(车票列表, 起始地=杭州) 236 | -> sys_action: confirm(起始地=杭州，目的地=上海) 237 | 238 | ## confirm是确认操作，期待用户回答诸如是/否，yes/no的回答 239 | 240 | 系统回答示例：您是说从杭州去上海的车票吗？ 241 | 242 | 用户：是的 243 | 244 | -> user_action: confirm() 245 | -> sys_action: inform(车票列表=执行部件的答案, 起始地=杭州, 目的地=上海) 246 | 247 | 系统回答示例：从杭州去上海的车票有yy趟，如下：yyyyy 248 | ``` 249 | 250 | 或者如果系统实在不确定，或者比较愚蠢，甚至可能是： 251 | 252 | 253 | ``` 254 | 用户：我想找北京去上海的火车 255 | 256 | -> user_action: request(车票列表, 起始地=北京, 目的地=上海) 257 | -> sys_action: inform(车票列表=执行部件的答案, 起始地=北京, 目的地=上海) 258 | 259 | 系统回答实例：从北京去上海的车票有xx趟，如下：xxxxx 260 | 261 | ## 以上部分和上面的例子一样 262 | 263 | 用户：从杭州去的呢？ 264 | 265 | -> user_action: request(车票列表, 起始地=杭州) 266 | -> sys_action: request(目的地=上海) 267 | 268 | ## 上面最后一行代表，机器也可以向用户请求信息 269 | 270 | 系统回答示例：请告诉我目的地是哪里？ 271 | 272 | 用户：是上海 273 | 274 | -> user_action: inform(目的地=上海) 275 | -> sys_action: inform(车票列表=执行部件的答案, 起始地=杭州, 目的地=上海) 276 | 277 | 系统回答示例：从杭州去上海的车票有yy趟，如下：yyyyy 278 | ``` 279 | 280 | 这些不同的操作，最终都成功引导到了结果。当然理论上第一次最好，因为用户操作最少，但是如果ASR部件、NLU部件甚至DST部件产生了错误（例如听错了、理解错误、管理失误等等），那么是有可能产生后两次的对话。 281 | 282 | 所以DST和DP部件，主要是管理历史状态，并且根据状态生成一个`sys_action`，系统所要应对的行为。 283 | 284 | ### 自然语言生成 NLG 285 | 286 | 自然语言生成部件的主要目的是根据系统的相应类型，生成自然语言回答。 287 | 288 | 一般来说这部分主要是套模板。 289 | 290 | 当然现在也有一些使用如seq2seq模型等等产生的NLG方法。这些方法的出现一来是为了提高系统的鲁棒性，另一方面是希望系统说话更接近人类说话方式，最终提高用户体验。 291 | 292 | ### 语音合成 TTS 293 | 294 | 这部分是指从文字到语音合成的部分，并不在我所定义的Conversational Robot的范畴内。绝大部分Dialogue System或其他相关文献也都会忽略，因为模块本身可以独立运作，并且有比较成熟的解决方案。 295 | 296 | ## 问答系统 QA System 297 | 298 | 这里简单探讨QA系统的几种形式 299 | 300 | ### 问答匹配 Question & Answer Selection/Matching/Searching 301 | 302 | 假设我们有一堆问答对`(q_1, a_1, q_2, a_2, ..., q_n, a_n)` 303 | 304 | 如果这个时候新来了一个问题，最朴素的想法就是去这些问答对里面搜索，找到答案（假设有的话）。 305 | 306 | 问题是，问题本身的形式可能多种多样，例如： 307 | 308 | - 你从哪来？ 309 | - 你哪来的？ 310 | - 你从哪里来？ 311 | - 你来自哪里？ 312 | 313 | 这些问题本身都代表一样的含义，或者说他们有相似的语义（Semantic)。 314 | 315 | 那么问题来了，如何确定答案？ 316 | 317 | 假设我们有一个函数`f(x, y)`，当两个问题相似的时候`f(q_1, q_2)`趋近于1，当两个问题不相似的时候`f(q_1, q_3)`趋近于0。 318 | 319 | 那么用户只要输入一个新问题`q_user`，那么我们只要从数据库里面计算`argmax{q_i} f(q_i, q_user)`就好了。也就是从数据库中找到与问题`q_user`最相似的问题。 320 | 321 | 当然还有另一种类似的做法，假设一个函数`g(x, y)`，当一个问题`q`和答案`a`是一对的时候（也就是`a`是`q`的正确答案），那么`g(q, a)`趋近于1，如果不是一对，则趋近于0。 322 | 323 | 当用户来了新问题`q_user`，那么我们只要遍历数据库里面的所有答案寻找`argmax{a_i} g(q_user, a_i)`，则可以找到，最符合用户问题的答案 324 | 325 | --- 326 | 327 | 当然实际应用的时候，我们不可能真的遍历数据库的所有问题（可能有几百万条数据，时间性能不允许），这个时候我们可以通过其他手段。 328 | 329 | 例如我们有一个函数`vec(x)`，它可以把一个问题或者答案转换成一个有限长度的实数向量。然后我们还有一个函数`similarity(x, y)`，用来判断两个向量是否相似。那么当用户来了一个问题`q_user`的时候，我们可以先把它向量化得到`vec(q_user)`，然后再去匹配我们已经`预先`向量化好的其他问题。 330 | 即`argmax{vec(q_i)} similarity(vec(q_user), vec(q_i))` 331 | 332 | 因为向量相似匹配的算法，可能远快于遍历所有问题（或答案）。（例如用K-neighbour相关算法如BallTree等) 333 | 334 | 用深度学习解决此类问题的论文比较多，例如： 335 | 336 | (Ming Tan, LSTM-BASED DEEPLEARNING MODELS FOR NON-FACTOID ANSWER SELECTION, 2016) 337 | 338 | ### IR-based 339 | 340 | 利用搜索引擎，或者类似搜索引擎的技术 341 | 342 | 假设我们问“爱因斯坦出生于哪一年？” 343 | 344 | 然后把这个问题直接丢给搜索引擎，或者经过某种转换到某个形式（例如把问题修改为文本“爱因斯坦 出生 年份”） 345 | 346 | 假设去搜索，第一条结果可能如下： 347 | 348 | ``` 349 | 阿尔伯特·爱因斯坦- 维基百科，自由的百科全书 350 | https://zh.wikipedia.org/zh-hant/阿尔伯特·爱因斯坦 351 | 阿尔伯特·爱因斯坦，或譯亞伯特·爱因斯坦（德語：Albert Einstein，1879年3月14日－1955年4月18日），猶太裔理論物理學家，创立了現代物理學的兩大支柱之一的相对论 :274，也是質能等價公式（E = mc2）的發現者。他在科學哲學領域頗具影響力。因為“對理論物理的貢獻，特別是發現了光電效應的原理”，他榮獲1921年諾貝爾物理學獎 ... 352 | ``` 353 | 354 | 而我们根据问题可以判断用户的意图是希望结果是“哪一年”，也就是问题答案很可能是(18xx年, 19xx年, 18xx-xx-xx, 19xx-xx-xx)之类的形式。 355 | 356 | 我们获得了潜在的答案类型，和潜在包含答案的数据条目。我们再从中搜索我们的答案。 357 | 358 | 这个方法的方法与条件： 359 | 360 | - 答案比较短（一个词或一个短语）的时候 361 | - 把问题转换为可能更容易搜索到答案的形式 362 | - 猜测用户所希望的答案类型（是人？地点？时间？其他？） 363 | 364 | 365 | ### Knowledge-based 366 | 367 | 当然也可以说语义网、知识图谱等based 368 | 369 | 这个角度解决QA问题首先我们需要有一堆数据库，常见使用三元组（triples）的形式保存，例如： 370 | 371 | - (爱因斯坦，出生于，1879) 372 | - (爱因斯坦，职业，物理学家) 373 | - (爱因斯坦，死于，1955) 374 | - (中国，首都，北京) 375 | - (美国，首都，华盛顿) 376 | 377 | 类似这样，一般来说三元组中间那是一个关系（relation），而两边是两个实体（entity），我们也可以写作`出生于(爱因斯坦，1879)`，`出生于(这篇文章的作者，2020)`，类似这样的形式 378 | 379 | 假设我们有很多这样的三元组数据，那么我们解决：“爱因斯坦出生在哪年”这样的问题方法，是把问题转换为一种逻辑形式，例如： 380 | 381 | ``` 382 | 爱因斯坦出生在哪年 => 出生于(爱因斯坦, ?x) 383 | 中国的首都 => 首都(中国, ?y) 384 | ``` 385 | 386 | 其中`出生于`和`首都`都是关系，而`中国`和`爱因斯坦`都是实体，而`?x`和`?y`都是自由变量，这里代指我们想要寻求的答案。 387 | 388 | 从这个角度解决QA问题有一套比较完整的方法论，如RDF，Semantic Web，SPARQL等技术和方法 389 | 390 | 也有一些文献使用了结合deep learning与sequence-to-sequence等技术的的Knowledge-based解决方案，具体内容我们后续会讨论。 391 | 392 | 393 | ## Chatbot 394 | 395 | 这里Chatbot特指中文的闲聊机器人 396 | 397 | 闲聊机器人是带有一定“娱乐”意味的机器人。当然也可以用作例如心理辅导，心理帮助，婴幼儿教育，儿童陪伴等等内容。 398 | 399 | 这部分就不是完成一个任务，不是需要答案，而更多的是陪伴、娱乐、放松。一个Chatbot最简单的成功指标就是，本质是鼓励用户多和Chatbot交流，用户使用时长和用户下次继续使用的意愿，如果用户愿意一直陪着Chatbot聊天，那就成功了。 400 | 401 | 一般来说Chatbot只有两种技术，template-based和neural-based 402 | 403 | ### template-based 404 | 405 | 也就是根据模板来选择回答 406 | 407 | 最简单的模板例如： 408 | 409 | ``` 410 | 用户：你喜欢 * 吗？ 411 | 系统：我喜欢 * 啊，你喜欢吗？ 412 | 系统：我喜欢 * 啊，你还喜欢什么别的吗？ 413 | 414 | 用户：你吃过 * 吗？ 415 | 系统：我是机器人，不吃 * 416 | 系统：* 好吃吗？你告诉我呗 417 | 418 | 用户：你觉得 * 怎么样？ 419 | 系统：这取决于你对 * 的理解，我不好回答啊 420 | 系统：我觉得 * 还不错吧，你怎么看？ 421 | ``` 422 | 423 | 可以看出，上面模板的`*`可以代指很多东西 424 | 425 | 当然实际应用上，模板可能比上面复杂的多，可以解决更多问题，设置算术题，计算，递归等等 426 | 427 | 这方面比较完整的研究是AIML语言，即 Artificial Intelligence Markup Language 语言。 428 | 429 | 是一种XML格式的标记语言，这部分方法也曾经是试图解决图灵测试的主力研究方法。 430 | 431 | 更多内容可以参考： 432 | 433 | [Wikipedia AIML](https://en.wikipedia.org/wiki/AIML) 434 | 435 | [AIML tutorial](https://www.tutorialspoint.com/aiml/index.htm) 436 | 437 | ### neural-based 438 | 439 | 是以神经机器翻译模型为参考，用来生成对话的模型。即基于深度学习的 sequence-to-sequence 模型（或变种），来生成对话。 440 | 441 | 这类模型直接训练对话，得到端到端的结果。训练数据大部分来自于电影字幕、社交媒体，或者其他已有的对话数据。 442 | 443 | 这方便比较前沿的研究如 444 | 445 | (Jiwei Li, Adversarial Learning for Neural Dialogue Generation, 2017) 446 | 447 | (Jiwei Li, Deep Reinforcement Learning for Dialogue Generation, 2016) 448 | 449 | 更多 Template-based 和 Neural-Based 的实现，我们后续张章节会讨论。 450 | -------------------------------------------------------------------------------- /什么是我所说的ConversationalRobot/ThePrincipalDialogueActsUsedByTheHISSystem.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/qhduan/ConversationalRobotDesign/5bb69d0592228b4a9eeedb9a15b24d35c17d1e69/什么是我所说的ConversationalRobot/ThePrincipalDialogueActsUsedByTheHISSystem.png -------------------------------------------------------------------------------- /什么是我所说的ConversationalRobot/TraditionalPipelineForTask-orientedSystems.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/qhduan/ConversationalRobotDesign/5bb69d0592228b4a9eeedb9a15b24d35c17d1e69/什么是我所说的ConversationalRobot/TraditionalPipelineForTask-orientedSystems.png -------------------------------------------------------------------------------- /什么是我所说的ConversationalRobot/从人机交互的角度看ConversationalRobot.graphml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | true 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 人机交互/机器与人的交互/机器人与人的交互 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 视频识别 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 动作识别与交互 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 其他交互行为 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 语言交互/自然语言处理 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 语音交互 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 语音识别 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 语音合成 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | -------------------------------------------------------------------------------- /什么是我所说的ConversationalRobot/从人机交互的角度看ConversationalRobot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/qhduan/ConversationalRobotDesign/5bb69d0592228b4a9eeedb9a15b24d35c17d1e69/什么是我所说的ConversationalRobot/从人机交互的角度看ConversationalRobot.png -------------------------------------------------------------------------------- /什么是我所说的ConversationalRobot/从机器人的角度来看ConversationalRobot.graphml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | true 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 机器人 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 语音/语言输入 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 视频输入 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 其他输入 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 执行部件 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 理解部件 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 输出部件 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | 225 | 226 | 语音/语言理解 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | 242 | 243 | 244 | 语音/语言输出 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 人类 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | 298 | 299 | 300 | 301 | 302 | 303 | 304 | 305 | 306 | 307 | 308 | 309 | 310 | 311 | 312 | 313 | 314 | 315 | 316 | 317 | 318 | 319 | 320 | 321 | 322 | 323 | 324 | 325 | 326 | 327 | 328 | 329 | 330 | 331 | 332 | 333 | 334 | 335 | 336 | 337 | 338 | 339 | 340 | 341 | 342 | 343 | 344 | 345 | 346 | 347 | 348 | 349 | 350 | 351 | -------------------------------------------------------------------------------- /什么是我所说的ConversationalRobot/从机器人的角度来看ConversationalRobot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/qhduan/ConversationalRobotDesign/5bb69d0592228b4a9eeedb9a15b24d35c17d1e69/什么是我所说的ConversationalRobot/从机器人的角度来看ConversationalRobot.png -------------------------------------------------------------------------------- /从手动到自动发展的对话系统/README.md: -------------------------------------------------------------------------------- 1 | 2 | 现代对话系统，至少可以追溯到1977年的 3 | (Xerox Palo, GUS, A Frame-Driven Dialog System, 1977) 4 | ，这篇论文提出了，以帧（Frame）为驱动的对话系统。 5 | 通过不断的填满帧内的槽（Slot），和更新其中的槽，来不断的推进对话。 6 | 7 | 工具也在不断更新[OpenDial, 2011](https://github.com/plison/opendial) 8 | 到[Microsoft Bot Framework, 2016](https://blog.botframework.com/2016/03/30/botframework/) 9 | -------------------------------------------------------------------------------- /各种机器人平台调研.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | **Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* 4 | 5 | - [市场上的机器人平台](#%E5%B8%82%E5%9C%BA%E4%B8%8A%E7%9A%84%E6%9C%BA%E5%99%A8%E4%BA%BA%E5%B9%B3%E5%8F%B0) 6 | - [国外 wit.ai](#%E5%9B%BD%E5%A4%96-witai) 7 | - [国外 Pandorabots (chatbots.io)](#%E5%9B%BD%E5%A4%96-pandorabots-chatbotsio) 8 | - [Chatfuel.com](#chatfuelcom) 9 | - [Smooch](#smooch) 10 | - [Motion.ai](#motionai) 11 | - [api.ai](#apiai) 12 | 13 | 14 | 15 | # 市场上的机器人平台 16 | 17 | ## 国外 wit.ai 18 | 19 | [Web](http://wit.ai) 20 | 21 | 支持Story模式来设置对话，所谓一个Story就是一个一句话无法完成的，可能多条对话组成的一个“故事”。例如，买电影票： 22 | 23 | Q：我要买电影票？ 24 | 25 | A：好的，你要买哪部电影？ 26 | 27 | Q：南方公园 28 | 29 | A：好的，您希望在哪个电影院？ 30 | 31 | 这样多条对话可能才能完成一个Story，而不是简单的QA pair。 32 | 33 | wit.ai有丰富的实体抽取类型，应该也可以根据抽取类型进行语义匹配。 34 | 35 | ## 国外 Pandorabots (chatbots.io) 36 | 37 | [web](http://chatbots.io) 38 | 39 | 支持多种语言，号称AIaaS，支持包括给Java，Node.js，Python，Ruby，PHP，Go等语言。 40 | 41 | 支持AIML的解析，上传，提供平台服务，根据机器人的访问次数和数量计费。 42 | 43 | 使用AIML 2.0作为语言，这东西竟然是2014年才发布的一份规范！ 44 | 这个时间竟然有人还在用XML！ 45 | 然后这群人竟然希望用户去自己写XML！ 46 | 简直太可怕了！！！ 47 | (☉д⊙)！ 48 | (☉д⊙)！ 49 | (☉д⊙)！ 50 | 51 | 如果要对AIML有一个基本了解可以看[这里](https://playground.pandorabots.com/en/tutorial/) 52 | 53 | ## Chatfuel.com 54 | 55 | 简单的语义匹配机器人，主要面向FaceBook，功能相对较弱。 56 | 57 | ## Smooch 58 | 59 | [Web](http://smooch.io) 60 | 61 | 机器人平台，可以整合其他机器人服务商资源，例如Motion AI，init.ai，Meya，converse.ai，Dialog Analytic Gupshup。 62 | 63 | 界面好看。 64 | 65 | ## Motion.ai 66 | 67 | [Web](http://motion.ai) 68 | 69 | 机器人平台，功能比较齐全，里面是有module的概念，类似wit.ai的story。功能相对比较强大，有各种抽取实体的module。 70 | 71 | ## api.ai 72 | 73 | [Web](http://api.ai) 74 | 75 | 这里面包括定义实体，定义intent，测试等几个步骤 76 | 77 | 定义实体就是可以抽取的实体，例如一个披萨，披萨的类型，大小，配料，这些都可以定义为单独可抽取的实体。 78 | 79 | intent的意图识别分为模板和机器学习两类，或者两类综合，可以自己设置threshold。不同的intents之间可以设置优先级。 80 | 81 | 机器人设置可以导入导出，甚至导入导出完整的一个机器人（它称作agents）的所有内容。然后可以链接其他应用，包括Facebook，微软Cortana等。 82 | 83 | 整体来说实体编辑，句子模板的部分有点类似wit.ai，号称的机器学习部分不知道用什么实现的，真的有train过程。 84 | 85 | ##　yige.ai 86 | 87 | [世纪佳缘做的哈哈哈](http://www.yige.ai) 88 | 89 | 恩，抄袭的api.ai，抄袭的好像好像，好像好像好像，好像好像和你在一起哦哦～～ 90 | 91 | 细节里面还是有点不一样的～～ 92 | 93 | 调试的时候会给出一些额外信息。 94 | 从结果上看，他们至少做了： 95 | 96 | - 分词（segmentation） 97 | - 意图识别（闲聊）（intent prediction） 98 | - 情感分析(sentiment analysis) 99 | 100 | 当用户进入一个场景之后，会一定程度上根据上下文来判断用户意图，应该相当于降低了问题阈值。例如： 101 | 102 | - Q 我想要吃饭 103 | - A 饭配红烧肉吗 104 | - Q 我不想买鞋 105 | - A 好的，您是什么脚型呢？（这是机器人放弃治疗了是吗？） 106 | - Q 我想要吃饭 107 | - A 您可以通过这个图来确认你的脚型哦。[图片链接] 108 | 109 | 不过api.ai还有一个机器学习识别模式，似乎还没抄袭出来 110 | 111 | ``` 112 | { 113 | "id": "43283078-778E-BA5F-EF6D-BD5F7D8CDDE1", 114 | "session_id": "64182", 115 | "time": "2016-11-20 23:17:31", 116 | "query": "购买链接", 117 | "agent_id": "BA22FB5E-EF6D-B7DE-BA64-DF242134E21E", 118 | "emotion": { 119 | "positive": 0.0064815573227318, 120 | "neutral": 0.98559873739357, 121 | "negative": 0.007919705283701 122 | }, 123 | "segmented_query": [ 124 | "购买", 125 | "链接" 126 | ], 127 | "state": [ ], 128 | "answer": "想,但是没钱怎么办", 129 | "status": { 130 | "code": 201, 131 | "error_type": "闲聊回复成功" 132 | } 133 | } 134 | ``` 135 | 136 | ``` 137 | { 138 | "id": "A80798F0-69AE-50B4-C5B0-9291DB8199DF", 139 | "session_id": "28721", 140 | "time": "2016-11-20 23:23:07", 141 | "query": "买鞋嘤嘤嘤嘤", 142 | "agent_id": "BA22FB5E-EF6D-B7DE-BA64-DF242134E21E", 143 | "emotion": { 144 | "positive": 0.0064815573227318, 145 | "neutral": 0.98559873739357, 146 | "negative": 0.007919705283701 147 | }, 148 | "segmented_query": [ 149 | "买鞋", 150 | "嘤", 151 | "嘤", 152 | "嘤", 153 | "嘤" 154 | ], 155 | "intent_id": "E93DE654-214D-54AD-9F57-A014F218F4F7", 156 | "intent_name": "0-跑鞋推荐", 157 | "confidence": 0.74032078852106, 158 | "action": { 159 | "name": "", 160 | "complete": true, 161 | "parameters": [ 162 | { 163 | "type": "yige.address", 164 | "name": "address", 165 | "value": "北京", 166 | "original": "北京" 167 | } 168 | ] 169 | }, 170 | "state": [ 171 | { 172 | "parameters": [ 173 | { 174 | "type": "yige.address", 175 | "name": "address", 176 | "value": "北京", 177 | "original": "北京" 178 | } 179 | ], 180 | "name": "shoe_first", 181 | "life_count": 5 182 | } 183 | ], 184 | "answer": "好的，您是什么脚型呢？", 185 | "parameter_recognize": [ 186 | { 187 | "text": "买鞋嘤嘤嘤嘤" 188 | } 189 | ], 190 | "status": { 191 | "code": "200", 192 | "error_type": "场景识别成功" 193 | } 194 | } 195 | ``` 196 | -------------------------------------------------------------------------------- /对话机器人技术简介：问答系统、对话系统与聊天机器人/README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | **Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* 4 | 5 | - [文章问题](#%E6%96%87%E7%AB%A0%E9%97%AE%E9%A2%98) 6 | - [对话机器人技术简介](#%E5%AF%B9%E8%AF%9D%E6%9C%BA%E5%99%A8%E4%BA%BA%E6%8A%80%E6%9C%AF%E7%AE%80%E4%BB%8B) 7 | - [机器人的作用之一是回答问题（Question Answering)](#%E6%9C%BA%E5%99%A8%E4%BA%BA%E7%9A%84%E4%BD%9C%E7%94%A8%E4%B9%8B%E4%B8%80%E6%98%AF%E5%9B%9E%E7%AD%94%E9%97%AE%E9%A2%98question-answering) 8 | - [一个最简单的问答系统](#%E4%B8%80%E4%B8%AA%E6%9C%80%E7%AE%80%E5%8D%95%E7%9A%84%E9%97%AE%E7%AD%94%E7%B3%BB%E7%BB%9F) 9 | - [更好的回答问题，怎么回答“中国的首都？”](#%E6%9B%B4%E5%A5%BD%E7%9A%84%E5%9B%9E%E7%AD%94%E9%97%AE%E9%A2%98%E6%80%8E%E4%B9%88%E5%9B%9E%E7%AD%94%E4%B8%AD%E5%9B%BD%E7%9A%84%E9%A6%96%E9%83%BD) 10 | - [知识图谱建模与查询](#%E7%9F%A5%E8%AF%86%E5%9B%BE%E8%B0%B1%E5%BB%BA%E6%A8%A1%E4%B8%8E%E6%9F%A5%E8%AF%A2) 11 | - [没数据的问答系统](#%E6%B2%A1%E6%95%B0%E6%8D%AE%E7%9A%84%E9%97%AE%E7%AD%94%E7%B3%BB%E7%BB%9F) 12 | - [怎么让机器人帮我买咖啡（Dialogue System）](#%E6%80%8E%E4%B9%88%E8%AE%A9%E6%9C%BA%E5%99%A8%E4%BA%BA%E5%B8%AE%E6%88%91%E4%B9%B0%E5%92%96%E5%95%A1dialogue-system) 13 | - [让机器人陪我，聊天，闲聊（Chit Chat、Chatbot)](#%E8%AE%A9%E6%9C%BA%E5%99%A8%E4%BA%BA%E9%99%AA%E6%88%91%E8%81%8A%E5%A4%A9%E9%97%B2%E8%81%8Achit-chatchatbot) 14 | 15 | 16 | 17 | 18 | ## 文章问题 19 | 20 | - 一些地方论文格式写的是(作者, 论文标题, 年份) 21 | - 部分地方的说法和示例可能还有待推敲 22 | 23 | # 对话机器人技术简介 24 | 25 | 自从iPhone 4S开始内置Siri，到现在各种智能音箱，或者扎克伯格说自己做的智能管家， 26 | 我认为都算是对话机器人的一类。 27 | 28 | 以苹果的Siri和亚马逊的Echo为例，它实际上是一套非常复杂的智能系统，而对话机器人是其中一个界面。 29 | 有些文献或者商业机构把这部分称为Conversational UI（对话界面），也就是说我们通过对话来与机器沟通。 30 | 31 | 遗憾的是，本文和本文的后续文章，都不可能说清楚怎么完整的做出一个Siri或者Echo， 32 | 它们的背后都是由成百数千名工程师、学者，在无数的各种资源支持下，动用几十个、上百个很多不同的工程技术的叠加组合而成的。 33 | 34 | 本文会探讨各种简单的对话机器人技术，而这些技术，每个往往只能完成一个及其特定的功能。 35 | 36 | 岔开话题的话，在科学上，“怎么实现一个机器人”，是一个太宽泛的问题，往往此类问题都会被分解为若干个小问题。 37 | 例如：怎么让实现让机器人能回答单个问题？怎么实现让机器人能回答连续的问题？怎么让机器人帮我买咖啡？ 38 | 而一个学术领域往往是一个子问题的最新、最优解，而工程上我们往往需要结合不同领域的成果构建一个可用系统。 39 | 40 | ## 机器人的作用之一是回答问题（Question Answering) 41 | 42 | ### 一个最简单的问答系统 43 | 44 | 最简单的问答系统就是当我们有足够多的问答数据，例如： 45 | 46 | 中国的首都是哪？ 47 | 北京。 48 | 49 | 当数据足够多的时候，一个最简单的问答实现，就是去匹配问题的相似度。 50 | 51 | 例如用户问：中国的首都 52 | 53 | 假设我们在python中计算编辑距离的话，会发现“中国的首都”这个问题和 54 | 我们数据库中已有的问题“中国的首都在哪”很相似（距离只有2，可以粗暴理解为只差两个字）。 55 | 56 | ``` 57 | >>> from nltk.metrics import distance 58 | >>> distance.edit_distance('中国的首都', '中国的首都在哪') 59 | 2 60 | ``` 61 | 62 | 那么我们直接给用户这个问题的答案就好了，就可能有足够高的成功率。 63 | 64 | 当然这个看上去很简单粗暴的解决方案有很多问题，例如： 65 | 66 | 1、准确率取决于相似度算法； 67 | 2、很难设置相似度算法的阈值； 68 | 3、数据库要求比较大； 69 | 4、扩展性比较差； 70 | 71 | 但是实际上在真实世界中，往往必须有一部分上这个算法，因为这个算法同样有优势： 72 | 73 | 1、不需要训练，假设你的领导要你给线上产品添加一个问答的时候，他并不喜欢：“我的深度学习模型训练5个小时之后，这个答案就上线了”，这样的回答； 74 | 2、自定义问题成本低； 75 | 3、非常容易解释； 76 | 4、对于完全匹配的问题可以绝对准确，如果是其他的概率模型的话，就必然有可能不准确，而简单的模型不会出错； 77 | 78 | ### 更好的回答问题，怎么回答“中国的首都？” 79 | 80 | 简单的来说，可以分为“有数据”的问答系统，和“没数据的问答系统”。 81 | 82 | 有数据的是指，我们已经有一些已经结构化的数据，或者说知识。 83 | 例如我们的问答系统就想回答关于国家与城市的问题， 84 | 那么我们可以假设自己已经有了很多关于国家、城市、国家与城市之间关系的知识。 85 | 86 | ## 知识图谱建模与查询 87 | 88 | “有数据”的问答系统是指，例如你有一堆可以查询的知识。 89 | 一种常见的知识存储方法，就是三元组： 90 | 91 | (中国，有首都，北京) 92 | (北京，是某国的首都，中国) 93 | 94 | (英国，有首都，伦敦) 95 | (伦敦，是某国的首都，英国) 96 | 97 | 在上面的前两个三元组中出现了两个实体（entity），分别是北京和中国。 98 | 总过出现了两个关系，分别是“由首都”和“是某国的首都”。 99 | 100 | 从字面意义上来讲，他们可以解决“中国的首都是哪？”和“北京是哪个国家的首都？”这两个问题， 101 | 也就是根据一个关系和一个实体，查询另一个实体。 102 | 当然也可以解决“北京和中国的关系”这样的问题，也就是根据已知的两个实体，查询他们的关系。 103 | 104 | 从学术上来讲，这个领域叫做 Knowledge-Based Question Answering 也就是我们有了知识， 105 | 需要在上面构建一个问答系统。 106 | 107 | 题外话，上哪能弄到这些知识呢？ 108 | 一般来说很多问题是在其他领域工作中，已经有了类似数据的积累。 109 | 或者是利用别人收集的数据，例如一些开放的中文知识图谱，例如英文世界的freebase。 110 | 还有或者就自己尝试制造这样的数据，例如从维基百科、从百度百科中获取。 111 | 或者……发挥想象力。 112 | 113 | 114 | 在知识图谱建模的领域，有一种称为SPARQL的语言，类似关系数据库查询的SQL语言， 115 | 例如我们要查询(中国，有首都，北京) 中的北京，则SPARQL可以写为： 116 | 117 | Select ?x where { 118 | 中国, 有首都, ?x 119 | } 120 | 121 | 也就是问题转换为，如何把一句自然语言“中国的首都是哪？”，转换为上面的SPARQL语句？ 122 | 123 | 例如现在的一些方向是利用统计机器学习的翻译任务，完成从“自然语言”到“SPARQL”语言的机器翻译任务，就如同中英翻译等自然语言之间的翻译一样，同样也可以做到的。但是根据语料数据、SPARQL复杂度等等问题，也会有其他各种问题。 124 | 125 | 当然也有不依赖SPARQL作为中间件的查询系统，例如有的文献设计了一套在知识图谱中逐渐搜索（探索）的系统； 126 | 以这个问题为例，起始点可以是实体“中国”，中国这个实体可能有很多关系，例如有首都、有文化、有省份、有xxx，然后搜索下一步最合理的关系“有首都”； 127 | 最后探索到答案“北京”，判读任务完成。 128 | 129 | 更多细节本文不再讨论。 130 | 131 | ### 没数据的问答系统 132 | 133 | IR-based 问答系统 (IR: Information Retrieval) 134 | 135 | 此类问答系统不需要提前构建知识，而是根据问题去检索答案（例如从搜索引擎上）。 136 | 137 | 此类问答系统从某种意义上类似人的搜索方式，例如我们想知道“中国的首都是哪”， 138 | 可能会去搜索引擎中搜索这个问题，而答案很可能会出现在搜索结果中， 139 | 我们知道这个答案的类型很可能是“某个城市”，所以我们会在搜索引擎给我们的结果中， 140 | 寻找一个城市名。 141 | 142 | 而机器也可以完成类似过程，首先根据问题来尝试判断答案类型，这里同样也可以判断结果类型为城市。 143 | 然后机器可能需要对问题进行重构，也就是寻找一个搜索问句，能找到答案的几率最大， 144 | 例如这个问题可能被重构为：“中国 首都 城市”。（最后添加了这个词城市，是因为我们假设可以准确判断出答案类型） 145 | 146 | 然后机器去自有的非结构化文档（没有知识图谱化的文档，例如各种纯文本文章），从中寻找最接近我们重构后问题的段落。 147 | 或者去搜索引擎、百科网站等等，搜索答案、或者检索问题相关的段落。 148 | 149 | 定位到这个段落后，根据答案类型（这里是城市），尝试从这个段落中筛出答案。例如我们去搜索引擎搜索“中国的首都”，很可能第一个答案段落中的第一个出现的城市名就是我们所需要的答案。 150 | 151 | 152 | # 怎么让机器人帮我买咖啡（Dialogue System） 153 | 154 | 这里的对话系统特指 Task-Oriented Dialogue System， 155 | 也就是让机器人帮助实现一种特定任务的系统， 156 | 有一文献提到的 General Dialogue System 的系统，往往指类似 Chit Chat 的系统。 157 | 158 | 一般此类对话系统的研究都基于如何让机器人在有限步骤内完成可以完成的任务的系统，并且结果往往定位到一个单一实体。此类系统的一个隐含假设往往是通过电话、文字、语音来进行人机交互，也就是没有什么“点击按钮”，“从多个选项选择”，之类的交互方式。当然在一些类似对话系统演变的工程实践中，是有类似的实现的。 159 | 160 | 因为这个关于“必须文字交互”的假设，所以实际上有些问题并不适合基于这种假设的对话系统完成。例如你在一些手机软件中搜索餐厅，结果可能会返回多家餐厅（餐厅本身即实体），他们都有名称、地址、电话等等信息（这些也可以称为餐厅这个实体的属性，当然也可以是与餐厅这个实体有关的其他实体）。而你想要通过语音、朗读的文字来获得这个列表，就显得很愚蠢了，不会有人想听机器人读5分钟搜索结果的20家餐厅然后决策吧？所以此类系统往往最后是推荐单一实体，例如结果排名最高的餐厅，如果你需要更换，可以跟系统说换一下餐厅。 161 | 162 | 一个典型的对话系统的交互过程是这样的： 163 | 164 | 用户：你好（User Dialog Act：greeting） 165 | 机器：你好，我可以帮助你搜索并预订餐厅（Sys Dialog Act：greeting） 166 | 用户：我想要找一家在中央公园2.0附近的意大利餐厅（User Dialog Act：inform(地址=中央公园2.0，口味=意大利)） 167 | 机器：请问你想要在中央公园2.0附近什么价位的意大利餐厅？（Sys Dialog Act：request(价位)） 168 | 用户：普通的就好（User Dialog Act：inform(价位=普通)） 169 | 机器：我知道那里有一家柯南家的老意大利料理餐厅（Sys Dialog Act：inform(名称=柯南家的老意大利料理)） 170 | 用户：换一个（User Dialog Act：alter()） 171 | 机器：我知道那里有一家意大利油泼面餐厅（Sys Dialog Act：inform(名称=意大利油泼面)） 172 | 用户：它家的价格怎么样？（User Dialog Act：request(价位)） 173 | 机器：意大利油泼面的价位是普通（Sys Dialog Act：inform(价位=普通)） 174 | 用户：就这家吧，帮我预订（User Dialog Act：order()） 175 | 机器：请问有几个人？（Sys Dialog Act：request(人数)） 176 | 用户：单身狗（User Dialog Act：inform(人数=1)） 177 | 机器：真的就1个人吗？（Sys Dialog Act：confirm(人数=1)） 178 | 用户：是的（User Dialog Act：confirm()） 179 | 机器：已经预定成功（Sys Dialog Act：order_success()） 180 | 用户：好的，再见（User Dialog Act：bye()） 181 | 机器：再见，欢迎下次使用（Sys Dialog Act：bye()） 182 | 183 | Dialog Acts 如果是用户发起的（User Dialog Act）， 184 | 那么它是一种处理后的用户意图的抽象表达，是一种形式化的意图描述。 185 | 186 | The dialog act expresses an important component of the intention of the speaker (or writer) in saying what they said 187 | 188 | 系统发起的行为（Sys Dialog Act），是根据用户行为，上下文信息等等综合得出的， 189 | 下一步所要进行的操作的抽象表达，这个抽象表达后续会送入NLG部件，生成自然语言。 190 | 191 | Asking questions, giving orders, or making informational statements are things that people do in conversation, yet dealing with these kind of actions in dialogue what we will call dialog acts is something that the GUS-style frame-based dialog systems 192 | 193 | GUS对话系统，是 Genial Understander System 的缩写，可以追溯到1977年的论文(Daniel G. Bobrow, GUS, A Frame-Driven Dialog System, 1977) 194 | 195 | 196 | 常见的不同意图有： 197 | 198 | 用户的greeting：问好 199 | 用户的inform：用户提供一个信息，例如想要的餐厅的地址 200 | 用户的request：询问一个信息，例如当前结果餐厅的电话 201 | 用户的confirm：确认信息正确（例如上一条是机器问你对不对） 202 | 用户的bye：结束对话 203 | 204 | 机器的greeting：问好，也可以是自我介绍 205 | 机器的inform：提供机器知道的信息，例如当前结果餐厅的信息 206 | 机器的request：机器必须有足够的信息才能完成任务，如果欠缺一些必须信息，例如餐厅地址、口味，则会向用户询问 207 | 机器的confirm：根用户确认信息是否正确 208 | 机器的bye：结束对话 209 | 210 | 上文还出现了一些可能的特殊意图，例如： 211 | 212 | 用户的order：确认订餐 213 | 用户的alter：更换检索结果 214 | 系统的order_success：反馈订餐成功 215 | 216 | 217 | 整个对话系统，就是为了完成某个特定任务，这个任务所需要的特定条件需需要由用户提供（例如帮助买咖啡需要咖啡品种，热或冷等信息），当信息足够的时候，机器就能完成相应任务。 218 | 219 | 这个过程总结就是： 220 | 221 | 用户说了什么 =》 222 | 分析用户意图 =》 223 | 生成系统的对应意图（操作）=》 224 | 用户听到了系统的反馈 =》 225 | 用户说了什么（第二轮）=》 226 | ………… 227 | 228 | 当然根据任务复杂度、和其他系统结合等等问题， 229 | 对话系统本身也有各种的不同准确度与实现方式。 230 | 231 | # 让机器人陪我，聊天，闲聊（Chit Chat、Chatbot) 232 | 233 | 聊天机器人往往是没有一个明确目的，或者目的比较模糊的系统。有别于问答系统和对话系统，前两者的一个期望是用户尽可能得到信息后离开，快速找到想要的回答或者快速完成任务，是尽可能在减少与用户的交流时间。而聊天机器人往往设计上需要尽可能的占用用户时间，尽可能的延长与用户聊天、陪伴的时间，或者尽可能的再次让用户使用。 234 | 235 | 聊天机器人本身也可以是有一定目的的，不过是比较宽泛的目的。例如最近融资成功的woebot，它的目的是可以一定程度上跟踪用户心理状态、帮助用户调整自己的心理状态等等，有一定程度的心理医学性质。 236 | 237 | 最开始的希望通过图灵测试的机器人系统都有类似闲聊机器人的特征，例如Eliza(1964)，或者Alicebot(1995)。 238 | 它们主要通过模板特征实现，也就是人工定义对话模板，产生类似智能的效果。 239 | 240 | 这样的机器人模板其实可以很多，例如Alicebot有超过六万条AIML模板来覆盖绝大部分日常对话。 241 | AIML，即人工智能标记语言，是用来通过定义模板实现机器人(闲聊)的一种方法。 242 | 243 | 模板方法是机器人相关实现的最重要的方法（没有之一），实际上在绝大多数的对话系统中都依然存在（Siri，小冰），并且在一些学术文献上被证明与其他系统相比依然拥有更好的效果（例如与 Neural Conversation 模型相比）。 244 | 245 | 与模板方法相对的，是基于深度学习的 Neural Conversation 模型，是一种基于神经机器翻译技术演变而来的对话生成模型。类似机器翻译，例如一句英文翻译为一句中文，对话中，上一句对话也可以“翻译”到下一句对话；类似的还有作诗机，上一句诗“翻译”出下一句诗。 246 | 247 | 本质是根据统计学方法进行的一种文本生成，这种文本生成往往会生成语法正确的句子。 248 | 但语义、逻辑、一致话、发散性等地方会有问题。例如： 249 | 250 | 人格不一致： 251 | 252 | ``` 253 | Q：你今年几岁 254 | A：我5岁了 255 | 256 | Q：你今年多大？ 257 | A：我马上就满18了 258 | ``` 259 | 260 | 语法正确但语义有问题： 261 | 262 | ``` 263 | Q：你想做我的女朋友吗 264 | A：我是我的女朋友 265 | ``` 266 | 267 | 发散性差，本质机器倾向于回答简单又不容易出错的回答，相当于机器学会了一种投机取巧的方法： 268 | 269 | ``` 270 | Q：你喜欢我吗 271 | A：我不知道 272 | 273 | Q：今天天气不错 274 | A：我不知道 275 | 276 | Q：你是谁啊？ 277 | A：我不知道 278 | ``` 279 | -------------------------------------------------------------------------------- /对话机器人设计简述.md: -------------------------------------------------------------------------------- 1 | 2 | # 对话机器人设计简述 3 | 4 | ## 什么是对话机器人 5 | 6 | ### 对话机器人简介 7 | 8 | ### 对话机器人历史 9 | 10 | ### 对话机器人的任务和目标 11 | 12 | ### 对话机器人的产品形态 13 | 14 | ### 对话机器人的技术简要 15 | 16 | ## 对话机器人的产品设计 17 | 18 | ### 对话机器人的形式 19 | 20 | ### 构建对话机器人组成 21 | 22 | ## 对话机器人技术 23 | 24 | ### 问答系统 25 | 26 | ### 对话系统 27 | 28 | ### 闲聊系统 29 | 30 | ### 对话机器人整合 31 | -------------------------------------------------------------------------------- /对话系统：自然语言生成/README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | **Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* 4 | 5 | - [自然语言生成的主要目标](#%E8%87%AA%E7%84%B6%E8%AF%AD%E8%A8%80%E7%94%9F%E6%88%90%E7%9A%84%E4%B8%BB%E8%A6%81%E7%9B%AE%E6%A0%87) 6 | - [尽可能让机器说话更自然](#%E5%B0%BD%E5%8F%AF%E8%83%BD%E8%AE%A9%E6%9C%BA%E5%99%A8%E8%AF%B4%E8%AF%9D%E6%9B%B4%E8%87%AA%E7%84%B6) 7 | 8 | 9 | 10 | 11 | 12 | # 自然语言生成的主要目标 13 | 14 | - 尽可能让机器说话更自然（更接近人类） 15 | - 尽可能在书写模板所占用的时间和书写规则（代码）的时间平衡，降低总体工作成本 16 | 17 | ## 尽可能让机器说话更自然 18 | 19 | 假设机器人需要提供某航班的起飞时间，它可以这么说： 20 | 21 | 111号航班的起飞时间07:00。 22 | 23 | 这样好像也没什么太大，问题。 24 | 但是如果机器人需要同时提供某航班的起飞和降落时间，它可以这么说： 25 | 26 | 111号航班的起飞时间07:00，#111航班的降落时间17:00 27 | 28 | 这样是生硬的把两条信息放到了一起。而人类说它可能会这样： 29 | 30 | 111号航班于上午7点起飞并于下午5点降落 31 | 32 | 如何生成更自然的人类语言，则是自然语言生成的研究目标之一。 33 | -------------------------------------------------------------------------------- /流程细节.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | **Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* 4 | 5 | - [用户输入](#%E7%94%A8%E6%88%B7%E8%BE%93%E5%85%A5) 6 | - [文字](#%E6%96%87%E5%AD%97) 7 | - [语音](#%E8%AF%AD%E9%9F%B3) 8 | - [其他](#%E5%85%B6%E4%BB%96) 9 | - [文字处理](#%E6%96%87%E5%AD%97%E5%A4%84%E7%90%86) 10 | - [中文分词 Chinese Word segmentation](#%E4%B8%AD%E6%96%87%E5%88%86%E8%AF%8D-chinese-word-segmentation) 11 | - [实体识别 Named Entity Recognition](#%E5%AE%9E%E4%BD%93%E8%AF%86%E5%88%AB-named-entity-recognition) 12 | - [意图判断 Intent Detection / Prediction](#%E6%84%8F%E5%9B%BE%E5%88%A4%E6%96%AD-intent-detection--prediction) 13 | - [编辑距离](#%E7%BC%96%E8%BE%91%E8%B7%9D%E7%A6%BB) 14 | - [基于wordnet](#%E5%9F%BA%E4%BA%8Ewordnet) 15 | - [基于2vec](#%E5%9F%BA%E4%BA%8E2vec) 16 | - [其他](#%E5%85%B6%E4%BB%96-1) 17 | 18 | 19 | 20 | 21 | 22 | ## 用户输入 23 | 24 | 来源可以是web、微信、微博、等等一切类似平台 25 | 26 | 用户输入类型应该以文字为主 27 | 28 | ### 文字 29 | 30 | ### 语音 31 | 32 | 语音可以通过API识别为文字。在不同平台可能有不同的语音识别解决方案，例如在微信中可以考虑使用腾讯的服务。 33 | 34 | 或者使用其他第三方服务，下面列出的可能服务来自于[Uberi](https://github.com/Uberi/speech_recognition) 35 | 36 | * [CMU Sphinx](http://cmusphinx.sourceforge.net/wiki/) 37 | * [Google Speech Recognition](https://cloud.google.com/speech/) 38 | * [Wit.ai](https://wit.ai/) 39 | * [Microsoft Bing Voice Recognition](https://www.microsoft.com/cognitive-services/en-us/speech-api) 40 | * [api.ai](https://api.ai/) 41 | * [Houndify API](https://houndify.com/) 42 | * [IBM Speech to Text](http://www.ibm.com/smarterplanet/us/en/ibmwatson/developercloud/speech-to-text.html) 43 | 44 | ### 其他 45 | 46 | 其他可能用户输入包括但不限于，图片，地点（坐标），文件，视频，URL（文本的一种） 47 | 48 | ## 文字处理 49 | 50 | 文字处理的基本流程是 51 | 52 | - 中文分词 53 | - 实体识别 54 | - 意图判断 55 | 56 | ### 中文分词 Chinese Word segmentation 57 | 58 | 因为要做实体识别，中文分词可能是比较必要的部分 59 | 60 | 可以考虑的服务有jieba，stanford segmenter，pullword，或者其他免费、收费服务 61 | 62 | ### 实体识别 Named Entity Recognition 63 | 64 | stanford ner对于中文只有三种类型实体的判断，人物，地点，时间 65 | 66 | 为了精确，考虑自己添加其他实体识别类型，例如： 67 | 68 | - 电话号码，手机，固话，400/800 69 | - 价格，例如xx元 70 | - 电子邮件 71 | - 网址 72 | - 年龄 73 | - 数字 74 | 75 | *可以参考wit.ai和api.ai的实体类型* 76 | 77 | 还有其他更模糊的实体，例如 78 | 79 | - 要搜索的条目 80 | - 要翻译的英文单词 81 | 82 | ### 意图判断 Intent Detection / Prediction 83 | 84 | 我想吐槽一下，这两年虽然关于Dialogue和QA的论文不少，但是很多都太“学术化”的感觉。 85 | 如果用那些文章的方法搭建起来，别说用，我觉得可能想达到wit.ai或者api.ai的水平都不行。 86 | 87 | 这一部分可能是整个流程最难的部分，倒是也不是说真的最难，关键是没有很好的现成的工具可以用～～ 88 | 89 | 如果我们暂且把意图分解为两部分：命令，非命令 90 | 91 | 一般来说，目的就是尽可能的提高命令的recall，而不是precision，这也是大部分机器人的做法。 92 | 93 | 简单来说，就是用户问“我想要看天气”，我们返回天气，如果用户说“我讨厌天气预报”，我们可能还是会返回天气。 94 | 即便这句话的语义完全不应该返回天气，但是为了高recall，而且因为语义分析（相似度）完全没有好办法。 95 | 96 | 这个precision和recall的问题是一个难点，还有工程上考虑上下文是一个难点 97 | 98 | 一个朴素的想法是，像wit.ai那样把一个场景（story）分开，如果在这个场景中， 99 | 所有场景的关键词匹配阈值都改变（在某个场景中，则增加这个场景的匹配可能性）。 100 | 如果没在场景中，则所有的匹配关键词阈值还是原来那样。 101 | 102 | 流程类似： 103 | 104 | - 用户输入语句S 105 | - S是否Exactly Match某条命令？ 106 | * S是否Prefectly Match某条命令 107 | * S是否Regex Match某条命令 108 | * 如果是，则确定是这条命令 109 | - 在所有的命令库中计算所有命令和S的距离（语义相似度）并排序 110 | * 如果用户的上下文在某个场景（story）中，则相关场景的得分提高 111 | * 如果距离得分最高的命令大于某个阈值，则确定是这条命令 112 | - 如果现在依然没匹配到某条命令，则闲聊（chichat） 113 | 114 | 在不考虑命令的语义相似度是否准确的情况下，还有其他工程上的难点。 115 | 考虑是否构造一个类似于AIML的语言，能尽可能的提高效率。 116 | 这款语言应该定义好Exactly match，包括Regexp match，应该能定义好Story、Enity。 117 | 考虑XML或者JSON实现，当然你们都知道我不喜欢XML。 118 | 119 | 例如： 120 | 121 | 1、模糊匹配如“北京的天气怎么样？”这种命令 122 | 123 | 如果系统判断用户在weather这个story中，那么匹配“深圳呢？”这个命令的可能性也将大幅提高 124 | 125 | ``` 126 | [ 127 | { 128 | "pattern": [ 129 | "{sys.location}{sys.date}天气怎么样？", 130 | "{sys.location}的温度" 131 | ], 132 | "mode": "normal", 133 | "story": "weather", 134 | "must_have": [ 135 | "sys.location" 136 | ], 137 | "action": "get_weather({sys.location}, {sys.date || today})" 138 | }, 139 | { 140 | "pattern": [ 141 | "{sys.location}呢？" 142 | ], 143 | "mode": "normal", 144 | "story": "weather",, 145 | "must_have": [ 146 | "sys.location" 147 | ], 148 | "action": "get_weather({sys.location}, {today})" 149 | }, 150 | { 151 | "pattern": [ 152 | "{sys.date}呢？" 153 | ], 154 | "mode": "normal", 155 | "story": "weather",, 156 | "must_have": [ 157 | "story.sys.location" 158 | ], 159 | "action": "get_weather({story.sys.location}, {sys.date})" 160 | } 161 | ] 162 | ``` 163 | 164 | 运行如下： 165 | 166 | - Q 北京今天天气怎么样？ 167 | - A 匹配出sys.location是北京，sys.date是今天 168 | - Q 深圳的温度 169 | - A 匹配出sys.location是深圳，sys.date没有，默认是今天 170 | - Q 广州呢？ 171 | - A 匹配到了sys.location，当前的story是weather，返回温度查询 172 | - Q 明天呢？ 173 | - A 匹配到了sys.date，查询当前的story是weather，当前story下存在sys.location（广州），返回温度 174 | 175 | 2、命令式，不模糊的翻译英文，任何以“翻译：”，“翻译 ”等开头的就将被匹配 176 | 177 | ``` 178 | [ 179 | { 180 | "pattern": [ 181 | "翻译(\s+|，|：|:)([a-zA-Z0-9-\s]+)" 182 | ], 183 | "mode": "regex", 184 | "story": "translate_english", 185 | action: "translate_english({$2})" 186 | } 187 | ] 188 | ``` 189 | 190 | 命令的语义相似度判断： 191 | 192 | #### 编辑距离 193 | 194 | Levenshtein Distance 195 | 196 | #### 基于wordnet 197 | 198 | Synets Similarity 199 | 200 | Jaccard Similarity 201 | 202 | #### 基于2vec 203 | 204 | Mean of Word2Vec 205 | 206 | Doc2Vec 207 | 208 | #### 其他 209 | 210 | TreeLSTM 211 | 212 | 然而上面这些语义相似度判断基本上都一个鸟样，实际用起来其实和编辑距离没太大区别，蠢死了～～ 213 | -------------------------------------------------------------------------------- /聊天机器人：神经对话模型的实现与技巧/README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | **Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* 4 | 5 | - [Sequence-to-Sequence 模型](#sequence-to-sequence-%E6%A8%A1%E5%9E%8B) 6 | - [模型流程](#%E6%A8%A1%E5%9E%8B%E6%B5%81%E7%A8%8B) 7 | - [Seq2Seq模型流程伪代码（python）](#seq2seq%E6%A8%A1%E5%9E%8B%E6%B5%81%E7%A8%8B%E4%BC%AA%E4%BB%A3%E7%A0%81python) 8 | - [预测时](#%E9%A2%84%E6%B5%8B%E6%97%B6) 9 | - [另一种解释](#%E5%8F%A6%E4%B8%80%E7%A7%8D%E8%A7%A3%E9%87%8A) 10 | - [与神经机器翻译的异同](#%E4%B8%8E%E7%A5%9E%E7%BB%8F%E6%9C%BA%E5%99%A8%E7%BF%BB%E8%AF%91%E7%9A%84%E5%BC%82%E5%90%8C) 11 | - [embedding不同](#embedding%E4%B8%8D%E5%90%8C) 12 | - [结果重复性不同](#%E7%BB%93%E6%9E%9C%E9%87%8D%E5%A4%8D%E6%80%A7%E4%B8%8D%E5%90%8C) 13 | - [对称性不同](#%E5%AF%B9%E7%A7%B0%E6%80%A7%E4%B8%8D%E5%90%8C) 14 | - [语料不同，与所产生的问题](#%E8%AF%AD%E6%96%99%E4%B8%8D%E5%90%8C%E4%B8%8E%E6%89%80%E4%BA%A7%E7%94%9F%E7%9A%84%E9%97%AE%E9%A2%98) 15 | - [评价标准问题](#%E8%AF%84%E4%BB%B7%E6%A0%87%E5%87%86%E9%97%AE%E9%A2%98) 16 | - [技巧与提高（trick）](#%E6%8A%80%E5%B7%A7%E4%B8%8E%E6%8F%90%E9%AB%98trick) 17 | - [抗语言模型与互信息模型](#%E6%8A%97%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8B%E4%B8%8E%E4%BA%92%E4%BF%A1%E6%81%AF%E6%A8%A1%E5%9E%8B) 18 | - [抗语言(anti-language)损失函数](#%E6%8A%97%E8%AF%AD%E8%A8%80anti-language%E6%8D%9F%E5%A4%B1%E5%87%BD%E6%95%B0) 19 | - [互信息损失函数](#%E4%BA%92%E4%BF%A1%E6%81%AF%E6%8D%9F%E5%A4%B1%E5%87%BD%E6%95%B0) 20 | - [反转技巧](#%E5%8F%8D%E8%BD%AC%E6%8A%80%E5%B7%A7) 21 | - [强化学习](#%E5%BC%BA%E5%8C%96%E5%AD%A6%E4%B9%A0) 22 | - [对抗学习](#%E5%AF%B9%E6%8A%97%E5%AD%A6%E4%B9%A0) 23 | - [TFIDF技巧](#tfidf%E6%8A%80%E5%B7%A7) 24 | - [上下文相似技巧](#%E4%B8%8A%E4%B8%8B%E6%96%87%E7%9B%B8%E4%BC%BC%E6%8A%80%E5%B7%A7) 25 | - [分组技巧（buckets）](#%E5%88%86%E7%BB%84%E6%8A%80%E5%B7%A7buckets) 26 | - [工程级实战参考与提高](#%E5%B7%A5%E7%A8%8B%E7%BA%A7%E5%AE%9E%E6%88%98%E5%8F%82%E8%80%83%E4%B8%8E%E6%8F%90%E9%AB%98) 27 | - [训练不同情绪的bot](#%E8%AE%AD%E7%BB%83%E4%B8%8D%E5%90%8C%E6%83%85%E7%BB%AA%E7%9A%84bot) 28 | - [训练不同人格特征的bot](#%E8%AE%AD%E7%BB%83%E4%B8%8D%E5%90%8C%E4%BA%BA%E6%A0%BC%E7%89%B9%E5%BE%81%E7%9A%84bot) 29 | - [语料处理](#%E8%AF%AD%E6%96%99%E5%A4%84%E7%90%86) 30 | - [将语料分类，训练多个模型](#%E5%B0%86%E8%AF%AD%E6%96%99%E5%88%86%E7%B1%BB%E8%AE%AD%E7%BB%83%E5%A4%9A%E4%B8%AA%E6%A8%A1%E5%9E%8B) 31 | - [如果可能的话，避免（现在）使用神经对话模型](#%E5%A6%82%E6%9E%9C%E5%8F%AF%E8%83%BD%E7%9A%84%E8%AF%9D%E9%81%BF%E5%85%8D%E7%8E%B0%E5%9C%A8%E4%BD%BF%E7%94%A8%E7%A5%9E%E7%BB%8F%E5%AF%B9%E8%AF%9D%E6%A8%A1%E5%9E%8B) 32 | 33 | 34 | 35 | 36 | # Sequence-to-Sequence 模型 37 | 38 | ### 模型流程 39 | 40 | input_text => 41 | encoder => 42 | decoder => 43 | target_text 44 | 45 | ### Seq2Seq模型流程伪代码（python） 46 | 47 | 训练时： 48 | 49 | ```python 50 | 51 | # 这两条是训练数据 52 | input_text = ['A', 'B', 'C'] 53 | output_text = ['D', 'E', 'F'] 54 | 55 | # 计算encoder的状态 56 | encoder_state = encoder(input_text) 57 | 58 | output_text_with_start = [''] + output_text 59 | output_text_with_end = output_text + [''] 60 | 61 | output = [] 62 | decoder_state = 0 63 | for decoder_input, decoder_target in zip( 64 | output_text_with_start, output_text_with_end): 65 | # decoder_state 相当于每轮都会更新 66 | # 根据不同策略，最开始可以是 0 (例如是一个全 0 向量的状态) 67 | # 然后每轮结束后，decoder_state 也会更新 68 | decoder_output, decoder_state = decoder( 69 | encoder_state, decoder_state, decoder_input) 70 | output.append(decoder_output) 71 | 72 | # 收集loss 73 | loss = loss_function(decoder_output, decoder_target) 74 | # 第一个 loss 实际上相当于概率 P('D'|'') 的损失函数 75 | # 也就是给decoder输入最开始字符'SOS'，给出句子的第一个词'D'的概率，依次还有： 76 | # P('E'|'D') 77 | # P('F'|'E') 78 | # P(''|'F') 79 | # 也即是我们分别喂给decoder： '', 'D', 'E', 'F' 80 | # 我们希望它的输出是： 'D', 'E', 'F', '' 81 | 82 | """ 83 | decoder(encoder_state, decoder_state, '') -> 'D' 84 | decoder(encoder_state, decoder_state, 'D') -> 'E' 85 | decoder(encoder_state, decoder_state, 'E') -> 'F' 86 | decoder(encoder_state, decoder_state, 'F') -> '' 87 | output == ['D', 'E', 'F', ''] 88 | """ 89 | ``` 90 | 91 | ### 预测时 92 | 93 | ```python 94 | 95 | # 这是用户输入数据 96 | input_text = ['床', '前', '明', '月', '光'] 97 | 98 | # 计算encoder的状态 99 | encoder_state = encoder(input_text) 100 | 101 | # 第一个输入到decoder的字，是我们预设的'' 102 | # 而后续输入到decoder的字，是上一轮decoder的输出 103 | last_decoder_output = '' 104 | output = [] 105 | decoder_state = 0 106 | # 如果句子太长了，就是说预测句子结尾可能已经失败了 107 | # 则退出预测 108 | # 也就是循环最长也就是output_length_limit 109 | for _ in range(output_length_limit): 110 | # decoder_state 相当于每轮都会更新 111 | decoder_output, decoder_state = decoder( 112 | encoder_state, decoder_state, last_decoder_output) 113 | output.append(decoder_output) 114 | # 更新 last_decoder_output 115 | last_decoder_output = decoder_output 116 | 117 | # 如果察觉到句子结尾，则直接退出预测 118 | if decoder_output == '': 119 | break 120 | 121 | ``` 122 | 123 | ### 另一种解释 124 | 125 | `['床', '前', '明', '月', '光']`这个输入，构成了encoder_state， 126 | decoder相当于是构建一个函数关系： 127 | 128 | 下文`=>`是指左侧到右侧的单向函数映射 129 | 130 | encoder(`['床', '前', '明', '月', '光']`) => encoder_state 131 | 132 | decoder(encoder_state, `['']`) => `'疑'` 133 | decoder(encoder_state, `['', '疑']`) => `'是'` 134 | decoder(encoder_state, `['', '疑', '是']`) => `'地'` 135 | decoder(encoder_state, `['', '疑', '是', '地']`) => `'上'` 136 | decoder(encoder_state, `['', '疑', '是', '地', '上']`) => `'霜'` 137 | decoder(encoder_state, `['', '疑', '是', '地', '上', '霜']`) => `''` 138 | 139 | # 与神经机器翻译的异同 140 | 141 | 神经对话模型最开始就来源于对神经翻译模型的思考，但是他们有很多不同之处。 142 | 143 | ### embedding不同 144 | 145 | 神经翻译模型因为是从一个语种到另一个语种的翻译， 146 | 所以encoder和decoder的embedding往往是不同的。 147 | 148 | 例如翻译数据中，英文我们取10万个词，法文取10万个词， 149 | 我们需要建立的是两个10万的embedding， 150 | 或者一个20万的embedding。 151 | 152 | 而神经对话模型里，因为输入和输出都是一个语种， 153 | 也就是只有英文到英文、法文到法文，所以encoder和docoder 154 | 可以共用一个10万个词的embedding。 155 | 156 | ### 结果重复性不同 157 | 158 | 神经机器翻译往往是一对一的映射，一句话对应一句话，例如： 159 | 160 | hello <> 你好 161 | bye <> 再见 162 | 163 | 也就是说输入与输出都是唯一对应的输出，或者近似对应的输出，虽然也可能一句话、或者一个词有多个翻译： 164 | 165 | hi <> 你好 166 | hello <> 你好 167 | 168 | 但是这种情况并不会太多，而对话模型这种问题更普及，例如可以： 169 | 170 | 你好吗？ > 烦着呢别理我 171 | 今天我们去哪玩？ > 烦着呢别理我 172 | 我们去吃牛排吧 > 烦着呢别理我 173 | 你知道qhduan吗 > 不知道 174 | 你知道qhduan是帅哥吗 > 不知道 175 | 你知道龙傲天吗 > 不知道 176 | 177 | 上面的情况实际上在统计意义上是出现的。 178 | 这也导致对话模型更容易出现“I don't know”问题， 179 | 也就是模型更容易学会更好回答而不犯错的答案，任何问题都回答“我不知道”就行了，或者类似的简单回复。 180 | 181 | 所以后续的一些文献更看重神经对话模型的diversity，也就是结果多样。 182 | 183 | ### 对称性不同 184 | 185 | 神经翻译模型有对称性，例如 186 | 187 | en_zh(hello) = 你好 188 | 189 | zh_en(你好) = hello 190 | 191 | 即有： 192 | 193 | zh_en(en_zh(hello)) = hello 194 | 195 | 也就是平行语料之间有对称性，但是聊天的上一句下一句是没有的： 196 | 197 | 假设我们有： 198 | 199 | chat(你是谁) = 我是你哥哥 200 | 201 | 但我们不能说： 202 | 203 | chat(chat(你是谁)) == 你是谁 204 | 205 | chat(我是你哥哥) == 你是谁 206 | 207 | ### 语料不同，与所产生的问题 208 | 209 | 神经机器翻译依赖平行语聊，即统一意思的一句话。 210 | 例如代表某个意思的一句话，有中文表示也有英文表示，那么这两句话的意义是平行的。 211 | 212 | 神经对话的模型的来源不是平行预料， 213 | 早期研究的大部分语料是来自电影字幕。 214 | （例如来自OpenSubtitles） 215 | 216 | 后续的来源也有：ubuntu系统的系统客服的语料、来自社交媒体的语料，等等。 217 | 218 | 神经机器翻译的语料，往往可靠性更容易控制，因为一句“hello”，不太可能有多种翻译。而神经对话模型，有人开头一句“你好”之后，很大概率之后的回答，并不是回一句“你好”，因为很正式的回答语料很少。 219 | 而社交媒体之类的，更容易产生很发散的语料，这导致神经机器对话的语料质量普遍不高。 220 | 221 | 另一方面，电影字幕语料有天然的缺陷， 222 | 例如不好确定发言人，例如连续两句话很可能是同一人连续说的，因为长度问题分割为两句； 223 | 话题转换导致上下文没有相关性； 224 | 或者是两个不相干的场景说导致上下文相关性判断错误（即便在时间上接近）。 225 | 这些问题同样也导致了语料质量不高的问题。 226 | 227 | ### 评价标准问题 228 | 229 | 神经机器翻译的主要评价标准可以分为机器评价和人工评价。 230 | 机器评价普遍使用BLEU值进行估算。人工评价则是人工打分。 231 | BLEU是一种自动机器评价算法，一些文献表示，BLEU分数与人类对翻译质量的判断高度相关，即BLEU高，翻译质量越高(在一定统计意义上)。 232 | 233 | 虽然对于神经机器翻译模型，BLEU也不是一个完美的解决方案，可总体来说效果还是可以接受的。 234 | 但是针对神经对话模型，BLEU就更加不是一个好的评价模型了， 235 | 后续一些文献反而针对Diversity等其他指标评价模型好坏。 236 | 237 | 有大量的对话机器人文献，都采用了人工评价， 238 | 当然这也显著提高了成本。 239 | 很多文献彻底放弃了机器评价。 240 | 241 | # 技巧与提高（trick） 242 | 243 | 一些模型的普遍技巧，例如： 244 | Attention机制， 245 | Residual RNN 机制， 246 | Dropout 机制， 247 | 在此不介绍。 248 | 249 | ### 抗语言模型与互信息模型 250 | 251 | 在文献 252 | [Li et al., 2015](https://arxiv.org/pdf/1510.03055v3.pdf) 253 | 中提到，可以通过加入抗语言信息或者互信息来提高结果的BLEU和Diversity。 254 | 255 | 假设我们训练语料的第一句话是S，而其他人的回复是T，例如： 256 | 257 | S：你今年几岁了？ 258 | T：野原新之助，5岁！ 259 | 260 | 一般来说我们所训练提高的概率就是P(T|S)，损失函数log(P(T|S)) 261 | 262 | ##### 抗语言(anti-language)损失函数 263 | 264 | log(P(T|S)) - log(P(T)) 265 | 266 | 也就是我们在提高P(T|S)的同时，需要抑制P(T) 267 | 268 | 解释是：如果T是经常出现的句子，例如“我不知道”， 269 | 那么P(T)就会很高。 270 | 所以我们需要人为降低P(T)出现的概率。 271 | 272 | ##### 互信息损失函数 273 | 274 | log(P(T|S)) + log(P(S|T)) 275 | 276 | 解释是：提高S与T的相关性。如果T是与S完全无关的回复，例如“我不知道”，那么P(S|T)的概率就会很低，即相关性很低。 277 | 我们的目的是奖励S与T相关性（互信息高）的训练数据。 278 | 279 | BTW：文献中结论为，抗语言模型比互信息模型的diversity高，而互信息模型的BLEU更高。 280 | 281 | ### 反转技巧 282 | 283 | 有很多文献指出，把输入语句反转， 284 | 可以提高Seq2Seq模型的准确度。 285 | 286 | 即不再按“床前明月光”这个顺序喂给encoder， 287 | 而是按照“光月明前床”这个顺序。 288 | 289 | 理由一般认为是，一句话的开头的信息量更高，而反向输出会让RNN模型更重视开头。 290 | 因为RNN，尤其是门模型，先输入的信息会经过数次遗忘门的迭代，所以越后面的输入反而遗留信息越多。 291 | 292 | ### 强化学习 293 | 294 | 我们设计一些特征可以计算出某种Reward， 295 | 例如：T与S相似度太高，则Reward低； 296 | T与S的互信息太少，则Reward低。 297 | 298 | 然后通过log likelihood trick， 299 | 使用Reward修正每次更新loss时的权重， 300 | 则可以提高模型效果。 301 | 302 | 也就是高Reward的训练loss更高，让模型更倾向于学习高Reward的训练语料。 303 | 304 | 参考[Li et al., 2016](https://arxiv.org/abs/1606.01541) 305 | 306 | ### 对抗学习 307 | 308 | 假设我们设计一个分类器，可以分出哪些是机器的回复、 309 | 哪些是人的回复。 310 | 例如分类器学习到，机器更倾向于老回答“我不知道”， 311 | 所以会给类似“我不知道”这样的回答以较低概率是人说的。 312 | 313 | 然后就可以计算出一个对于问句质量的近似打分， 314 | 越接近人的回复则Reward越高，越接近机器的回复则Reward越低。 315 | 通过log likelihood trick对loss进行修正， 316 | 则可以提高训练效果。 317 | 318 | 参考[Li et al., 2017](https://arxiv.org/abs/1701.06547) 319 | 320 | ### TFIDF技巧 321 | 322 | 如果S中TFIDF相对整个batch来说的信息量较低， 323 | 则降低这些S的权重 324 | 325 | ### 上下文相似技巧 326 | 327 | 降低T与S太相似的训练集权重。 328 | 329 | 例如我们可以计算embedding之后的T与S的cosine距离。 330 | 331 | ### 分组技巧（buckets） 332 | 333 | 把要输入decoder的数据，根据不同长度分组。 334 | 例如1~5个字长的一组，6~10长度的一组，11~15长度一组。 335 | 336 | 这样的好处至少有： 337 | decoder时的RNN解码长度在每个batch中是差不多的， 338 | 提高整体运算效率。 339 | 340 | decoder的RNN是可以并行运行的， 341 | 如果batch数据中的解码长度不一致， 342 | 那么解码时间必然以最长的解码长度为准， 343 | batch中长度很短的数据会很快解码完， 344 | 但是从系统运行效率上，还是要等待长的数据解码完才能完成整个batch的decoder解码运算， 345 | 这样无形的消耗了一定效率。 346 | 347 | # 工程级实战参考与提高 348 | 349 | ### 训练不同情绪的bot 350 | 351 | 假设我们有了一个语料的情绪分类器（sentiment classifier） 352 | 353 | 那么我们可以把语料分为不同的情绪， 354 | 然后结合一些trick， 355 | 例如给训练数据添加一些标签，例如： 356 | 357 | S: [happy] 你 好 358 | T: 你好啊！偶好开心！ 359 | 360 | S: [sad] 你 好 361 | T: 哦……你来啦 362 | 363 | S: [angry] 你 好 364 | T: 你滚啦！ 365 | 366 | 这样把标签后的数据输入一个模型训练， 367 | 使用时只要给用户的输入加入不同的标签， 368 | 则可以得到不同情绪的机器返回结果。 369 | 370 | 当然了，你也可以直接根据不同情感训练多个模型， 371 | 具体怎么做好需要实际测试。 372 | 373 | ### 训练不同人格特征的bot 374 | 375 | 其实和上面不同情绪的差不多，只是首先你要有不同人格的训练语料。 376 | 377 | 原文献中的是使用美国电视剧的剧本，已经标清楚了说话人是谁。 378 | 379 | 参考[Nguyen et al., 2017](http://web.stanford.edu/class/cs224n/reports/2761115.pdf) 380 | 381 | ### 语料处理 382 | 383 | - 去除重复语料 384 | - 去除非目标文字语料 385 | - 例如中文训练集去掉句子中包含英文的语料 386 | - 去除太短的语料 387 | - 去除太长的语料 388 | - 去除特殊符号太多的语料 389 | - 尝试从更多资源获取语料：电影、小说、社交媒体、剧本，请使用合法来源……嘿嘿 390 | - 去除特定实体太多的语料，例如包含人名的语料可能不适合 391 | 392 | ### 将语料分类，训练多个模型 393 | 394 | 把语料根据来源或者语料本身， 395 | 使用某种无监督聚类机制来把语料分类。 396 | 397 | 例如你的语料来自电影字幕， 398 | 可以根据这个电影的所有字幕来把语料无监督分类。 399 | 如使用简单的TFIDF算法，然后使用K-Means之类算法进行分类。 400 | 这样结果就是例如可以分为：动作片字幕、爱情片字幕、动作爱情片字幕……等等不同语料组。 401 | 402 | 然后用不同语料组内的语料来训练多个模型， 403 | 使用前预判哪个模型更优秀， 404 | 或者根据不同场景使用不同模型（使用某种Ensemble算法）。 405 | 406 | ### 如果可能的话，避免（现在）使用神经对话模型 407 | 408 | 如题 :) 409 | 410 | 请考虑传统技术，如AIML等技术。 411 | --------------------------------------------------------------------------------