ELIZA诞生于1966年，开发者为MIT的Joseph Weizenbaum。它是一个模拟罗杰斯心理治疗的BASIC程序，是自然语言处理方面的先驱者。
A.L.I.C.E，起源于美国国防部DARPA的一个项目，它诞生于符号AI鼎盛时期，基于规则和模板来处理问句理解和回复逻辑。他对Chatbots的后续发展起到了非常深远的影响。它的一个贡献是定义了AIML，一种类XML的声明式语言，可以用来编写各种问答对，甚至多轮对话的对话逻辑。这种做法对于数据规模小，且领域知识相对充足的情况下，非常利于解决冷启动并提供表现不错的对话体验，同时也是对当前基于机器学习尤其是深度学习方法的一种补充。不仅可用来积累数据，也可以提供可解释性更强，且能针对个别用例做针对性地在线干预和修正。所以，到目前为止，大部分商用聊天机器人尤其是特定领域的对话应用沿用了这一思路。
图灵测试是指测试者在与被测试者（一个人和一台机器）隔开的情况下，通过一些装置（如键盘）向被测试者随意提问。进行一系列时长为5分钟的测试后，如果有超过30%的测试者不能确定出被测试者是人还是机器，那么这台机器就通过了测试，并被认为具有人类智能
对聊天机器人按照功能和交互方式等二个维度可以进一步细分为四类。交互方式可以分为主动交互或被动交互。目前大家接触到的大部分聊天机器人都属于被动交互的范畴，即由用户发起对话，机器理解对话并作出相应的响应。而主动交互能更好体现机器人和用户之间的对等关系，即通过共享或推荐用户感兴趣或热点事件等由机器人首先发起。目前主动交互更多作为传统交互方式的一种补充，作为辅助手段，并未大规模得到广泛使用。从功能角度来看，聊天机器人可以细分为以闲聊为主的聊天，问答和面向任务或目标的对话。其中，若根据场景切分，闲聊可以进一步分为情感交流和针对客观话题的讨论。问答系统需要不仅考虑如What、Who、Which、Where和When等事实型问答（Factoid QA），也需要考虑如How和Why等非事实型问答。如：小冰是一个基于搜索的回复检索系统。通过各种基于深度学习的语义匹配算法，从海量的问答对语料中返回最佳的回复（Message response而非Answer）
在主动交互性的聊天机器人有可做之处！
知识图谱也被广泛用于各种问答交互场景中 Watson背后依托DBpedia和Yago等百科知识库和WordNet等语言学知识。类似地，Alexa也依托其早年收购的True Knowledge公司所积累的知识库；Siri则利用DBpedia和可计算的知识服务引擎WolframAlpha；狗尾草公司推出的虚拟美少女机器人琥珀虚颜则用到了首个中文链接知识库Zhishi.me。伴随着机器人和IoT设备的智能化浪潮，智能厨房、智能驾驶和智能家居等应用层出不穷。无独有偶，百度推出的Duer OS和Siri的进化版Viv背后也都有海量知识库的支撑。
KG也越来越多地被用于辅助决策。这里无外乎是通过对文本、多媒体和各种传感器产生的原始数据流建立更加规范的数据表达，通过语义抽取、数据链接形成更多机器可理解的语义知识，从而将原本异构分散的各种数据转变为机器可计算的大数据。通过可计算机的大数据，人们更容易发现领域或行业内原先不为人知的规律或一些有趣的模式，从而更好地做出决策。Plantir就是这方面的成功应用典范，而ImageNet及Visual Genome等数据项目则极大地推进了图像语义理解和推理的进程。在构建用于辅助决策的知识图谱形成可计算大数据的过程中，如何将符号推理与统计学习有机结合起来，即碎片化的知识图谱上的推理和深度学习决策模型结合起来，形成所谓的Local Knowledge Powered Global Learning是非常有趣而富有挑战的研究课题。
KG也可辅助通用人工智能（Artificial General Intelligence，AGI），即在常识推理方面起到作用。过去人们常用图灵测试对机器的智能进行评估，近年来，Winograd Schema Challenge逐渐进入大家的视线。这里举一个指代消解的例子。指代消解是一个经典NLP任务，旨在将代词指向具名实体。例如，Thetrophy would not fit in the brown suitcase because itwas too big (small).What was too big(small)? 当我们描述it是big时，人们很容易理解这时候是在说奖杯（trophy）；而当it与small搭配时，我们也很容易识别出在抱怨suitcase太小。这个看似非常容易的问题，却难倒了机器，这是因为人具有非常庞大的世界知识（world knowledge）和常识知识（common-sense knowledge）。当我们仅采用NLP技术来努力理解并给出答案时，正确率仅50%；当结合知识时，正确率提升到了60%，而及格线是90%。因此，我们离真正的通用智能还有很漫长的路要走，需要更多的技术突破和数据积累才能完成这项挑战。
首先，Chatbot需要更加个性化的知识图谱。除了前面提到的实体KG和兴趣KG等开放领域的稀疏大图，我们也需要构建机器人KG和用户KG等个性化稠密小图。机器人或Agent需要图谱来建模和展示它的自我认知能力，而用户图谱则可被看作是更精细化的用户画像的知识表现。例如，机器人如“琥珀.虚颜”，有情感状态，喜好，技能等知识维度。同理，用户则需要表达其职业状态和生活轨迹等信息。需要强调的是，无论是个性化小图还是开放域大图，都不是独立存在的，需要将它们融合在一起，才能发挥更大 的价值。机器人喜欢吃的食物则需要和实体KG中的食谱图谱关联，而与用户形成经纪人、好友等社会关系，同时爱好方面则和兴趣图谱又关联在一起，可以实现机器人社交、机器人-用户社交和用户社交网络的统一连接。
其次，我们的世界不仅仅是静态的，而是动态地反映各种事物在时空上的变化。因此，我们不仅仅需要刚刚谈到的静态图谱，而是需要思考如何表示和应用动态图谱。对于一个机器人，它从早到晚会做不同的事情，也就是有自己的生活规则。我们该如何刻画生活轨迹呢？这就需要我们在图谱中体现时态知识。另一个例子，用户行程，即对于用户图谱，需要记住用户各种已经发生、正在星星或即将发生的事件。图谱中的行程不仅仅是一个关系或属性，而是一个由多元（N-ary）组成的事件。我们需要定义多种事件类型，并刻画时间和空间两个维度。
第三，机器人不能只是冷冰冰的回答用户的问题或帮助用户完成特定功能。它需要感知用户的情感并在输出答案回复的同时伴随着相应的情感，这样才更加拟人化。我们发现，之前构建的知识图谱大多是客观的，即描述一些客观的事实。如何在结合个性化图谱时，能包括一些主观知识，进而刻画机器人或用户的情感元素。例如，用户说：“我心情不好”。这属于闲聊中的情感表达范畴。这时需要将用户当前的心情状态更新到用户图谱的对应维度数值中。相应地，机器人也会有自己的心情、体力，甚至和用户之间的好感度关联。当此时，机器人心情不错，同时和用户很亲密时，它就会主动关心用户。这样结合机器人和用户情感因素的动态回复会更加温馨和贴合场景。当在多轮对话时，用户进一步说：“来一首快乐的歌吧”。需要进一步结合音乐知识KG（快乐作为歌曲的曲风或风格标签）和用户KG中的音乐偏好，推荐用户喜好的欢快的歌。
第四，我们发现聊天机器人为了完成很多功能需要对接外部服务或开放API。此时，图谱就需要从传统的关系型知识图谱（刻画二元关系）扩展到支持动态服务的动态图谱（刻画多元关系，事件属于服务图谱的一个特例）。另一方面，如何刻画服务之间的各种关系（如因果、时序依赖等）也是图谱扩展过程中需要考虑的。例如，当完成了订餐，会有很多Follow-up的服务（订花或预约车等）可作为后续服务被消费。建立这些服务之间的关联对于进行精准的多轮对话过程中的场景切换是非常有必要的。
总而言之，我们需要基于不同来源异构的数据来构建包含多类别且体现动态和个性化的知识图谱。这其中包括来自互联网的数据来刻画世界知识，用户数据来刻画画像知识，以及针对机器人的各种基本属性、社会关系、情感状态、兴趣爱好、以及日常生活等静态和动态知识。而我们得到的融合图谱是时空坐标中针对特定交互场景和时间节点的一个镜像。
从更技术的角度来说，我们需要考虑知识图谱将如何构建。这里不仅包含如何结合文本、多媒体、半结构化、结构化知识、服务或API，以及时态知识等的统一知识表示。在此基础上，需要进一步考虑如何结合结构化（如关系型数据库）、半结构化（HTML或XML）和非结构化（文本、图像等）多源异质数据源来分别构建通用事实类（各种领域相关实体知识）、常识类、用户个人记忆类、机器人自我认知类和服务任务类知识库等。针对不同类型的数据和不同种类的知识构建，有相应的构建技术，如针对结构化数据的知识映射、针对半结构化知识的包装器（Wrapper），以及针对非结构化知识的文本挖掘和自然语言处理。文本挖掘充分利用Web或大规模语料库的冗余信息来发现隐含的模式；而自然语言处理更多是做各种知识抽取（开放或确定schema的）。为了得到融合的图谱，我们除了离线的多源异构的知识融合，还需要额外考虑服务任务类动态知识的对象绑定，这块工作往往是在线完成的，相当于根据不同的交互，在线动态扩充知识图谱并实例化的过程
所构建的知识图谱既包括事实类和常识类的静态全局大图、服务任务类动态图谱，也有对于每个用户不同的用户图谱和机器人KG。随着用户数量的增加，用户图谱的数量也随之增加。这些图互相隔离，但每个均与全局图谱关联来提供个性化的聊天机器人的对话问答服务。每个用户图谱+机器人KG又随着交互不断填充和更新其中的节点和边，导致此类图谱的读写频度均非常高。面对这样的图谱，我们该如何选择存储方案呢？从工程应用的角度，我们更愿意站在巨人的肩膀上，选择一个现有数据库或几个数据库的组合来形成高效的图谱存储。
注意：这里所谓的存储，不仅仅是将知识存放的问题，而是考虑存储之后是否可以根据图谱的规模、读写特点和查询推理等基础在线操作的效率等多个因素来考量。
MongoDB，作为面向文档（Document Oriented）的NoSQL代表，他支持无模式（Schemaless）的数据建模方式，即不要求一开始就将Schema都确定，而可以按需进行添加或修改。这对于需求经常变更或一开始对领域不是完全了解的情况下，支持自底向上方式的知识管理。不过MongoDB仅支持数据库级别的锁，写入速度受限。对于读并发的提高，可以使用基于数据分片（Data Sharding）的分布式版本。
关系型数据库MySQL应用广泛，也被用于Apache Jena（HP开源的RDF数据库）中TDB的存储引擎。而Elasticsearch支持图谱上的简单模式（如单关系或链式）查询，适合如Facebook Graph Search或聊天机器人中大部分口语对话，因此也是面向聊天对话的知识图谱存储方案之一；
Neo4j是知名的图数据库，不同于RDF数据库，它的数据模型是属性图（property graph），基于图遍历（graph traversal）来实现各种查询功能，对于大部分熟悉面向对象编程的工程师来说非常容易上手。基于上述任何一个数据库或多个数据库的组合来满足知识图谱的管理都是工程做法。从研究的角度来说，希望做一个统一的存储和查询引擎，需要支持多租户（multi-tenant）环境下的海量个人和机器人知识图谱管理，以及融合个人图谱和全局知识上的查询分解、分布式环境下的查询路由和子查询执行，以及结果融合等操作。
第一个应用叫实体识别和链接。实体识别称为Named Entity Recognition，简称为NER。在传统NLP任务中，仅能识别PERSON（人物）、LOCATION（地点）、ORGANIZATION（组织机构）、DATE（时间日期）等有限类别。在实际应用中，NER的主要挑战在于识别大量细粒度实体类型，比如以Schema.org作为实体类别的分类体系，这里有很多标注数据充足的大类，也有很多缺乏标注数据的小类，如何保证在小类上的识别准确率。此外，分类体系是有层次结构的，如何保证底层的细粒度类别上有令人满足的识别率。例句“我想听一首海阔天空”中的“海阔天空”通过NER任务可以识别为是一个音乐作品。仅仅这样是无法执行对话意图“音乐点播”的，我们需要进一步将候选链接到知识图谱中的给定实体，这一过程称为Entity Linking。这里的核心在于歧义消解，一般借助于候选周围的其他实体或用语作为上下位来帮助去歧义。如果如例子所示，仍然无法明确是哪个实体，可通过反问来引导用户来给出更明确的实体指引。在实体链接过程中，我们所面临的挑战在于如何应对新兴实体（Emerging Entity）和实体的新兴说法（各种新说法和别名）。
聊天机器人依赖于NLP，而大量NLP任务可转换为有监督的分类或序列标注问题。我们往往会为特定任务下标注数据的缺乏或不充足而发愁，这一点在利用深度学习时尤为严重。这时，也将推出知识图谱的第二个典型应用，叫做数据增强，也就是说 Data Augmentation。具体来说，通过将知识图谱与文本语料库关联，形成大量弱标注数据。这在关系抽取或事件抽取等任务上应用广泛。例如，对于三元组<琥珀，喜欢吃，葡萄>，通过一定的泛化，我们将琥珀转换为PERSON，即在Web上收集PERSON和葡萄共现的描述片段，这些描述片段可能代表人物喜欢吃葡萄的特定模式（蓝色例句），也可能代表噪声（红色）。如何通过聚类分析中的异常点检测或噪声建模等方式将弱标注语料中的噪声识别并剔除。当然，包含一定比例的随机噪声，对于模型训练是一定帮助的，可以保证模型具有一定的泛化能力和鲁棒性。使用Web作为关联的语料库，主要看中Web上描述比较多样化，且信息具有冗余性，可以在保证覆盖率的同时确保数据的分布贴近真实情况。然而对于以语音作为主要交互方式的口语化聊天对话场景，我们仍然需要考虑从Web语料上学习到的模式或训练得到的模型如何进一步迁移适配。
第三个应用就是知识问答（KB-QA）。其中句理解的难点在于NLU，而候选答案生成则与检索过程关联，至于答案融合和排序，则重点考虑各种基于证据的收集和学习排序算法。这里我们看一个真实的例子，比如说“你觉得胡海泉这个人怎么样？”，这是一个意见询问类查询（opinion query），此时可以有很多回答，为了使得答案的多样化，除了利用摘要技术（summarization）从百科站点中得到“胡海泉是个歌坛巨星呀”之外，通过机器人KG中的经纪人关系，可以显式表明琥珀和他的关系。更进一步，可以通过琥珀记忆和技能关联，主动推荐“海泉给琥珀写的歌”。当用户给予明确的回复时，将表演自己的才艺，即唱自己的歌。在我们所描述的知识图谱下支持问答，需要额外考虑：
1）如何统一对实体、问句、图像、上下文进行统一的表示，映射到同构的语义空间中？ 2）知识库永远不可能是完备的，如何从KB-QA扩展到支持知识库和Web的混合QA场景下，并提供精准的数据源选择和语义解析？ 3）如何评估问句的复杂程度，并从单一知识库查询扩展到多知识库查询？
知识问答中非常有挑战的是Multi-KB环境下的问答。这对问句分解和知识源选择等都提出了更高的要求。更有挑战的是：不仅仅一句很复杂的话会涉及多个KB，即使对于很简单的话，往往在聊天的多轮交互中，会逐步涉及不同方面的KB，甚至需要在某个看似不经意的回复中用到某个KB。在研制小白的多轮对话中，需要考虑属性询问、反问、记忆、反馈、基于跨库属性比对后的评论，基于上下文的问答、事实类知识图谱查询、对复杂问题的导流、推理联想，调教以及用户类知识图谱的查询等。例子“我靠，居然比姚明还高”就是一个多知识库问答之后的回复生成。其中，姚明身高属于事实类知识库、“我靠”等惊讶的回复，是通过常识知识库了解到很少有人身高超过2.26米，而通过用户个人知识，其身高数值比姚明还高，而返回“比姚明还高”的回复片段，最后通过融合，得到最终的返回。
第四个KG的应用就是联想和推理。这里我列举了三种推理，但实际情况下不局限于这三种。第一种是空间推理，比如说“桌子上面有电脑，电脑旁边有水杯”，然后问，“桌子上面有什么”，正确的回答是电脑和水杯。
桌子上有水杯是通过空间位置的判断得到的。空间推理在地理类问答和智能家居控制等应用中有非常广泛的应用。第二种是答案类型推理。答案类型（Answer Type）作为一种很重要的证据，对问答的准确性有很大的作用。这里的推理包括实例推理（如例子中乒乓球是一种运动）、上下位推理（白色家电是一种家电）和互斥推理（空调和电视没有交集）等。第三种是场景推理，即结合场景业务规则和相关常识知识进行一些联想。例如空调需要一定时间之后才能制冷，而用户在这段时间感到热时可以吃一些冷饮。除了这三类，冲突检测对于聊天机器人尤其是用户记忆很有价值。这里不仅包括前面提及的类别之间的互斥定义，还可以包括关系单值或数量约束，甚至形成很多由推理得到的事实和显式定义的事实组成的冲突关系链。这些对推理机的表达能力提出了更高的要求。
