一 机器人应用

机器人，或智能客服，已经广泛存在于各系统中。例如 IM（钉钉、入流等）中的群机器人，可以实现关键词回复、基于 webhook 的自定义服务挂载等等；也有智能客服，用于解答用户的常见问题，节省人工成本；还有智能语音机器人，能够接收语音识别语义。

机器人的实现方案，也从固定的问题列表，到关键词回复，再到 NLP+深度学习，都有比较成熟的技术方案。大模型出现后，我们可以使用 RAG 快速搭建机器人应用，在常规机器人业务场景，可以在无需投入大量经历到模型调优的前提下，达到较好的问答准确率和召回率。

二 常见机器人功能

以典型的问答类机器人为例，首先有知识库，典型场景是覆盖常见问题的问答对数据（即问题->回答），例如下面的 Q&A 就是一个典型的问答对：

Q：xx 型号的电视维保期是多长？

A：您好，xx 型号的电视维保期是一年。

其次是输入，最简单的机器人可能会固定问题，让用户选择场景、商品型号等方式缩小问题返回，让用户点选预置的固定问题。这种情况只需要做 key-value 存储和查找就可以了，比较简单，但体验不好。所以允许用户自行输入，尤其是移动端能够语音输入，会更接近真实的客服场景，用户体验更好。

在接收到用户输入后，需要进行语义理解并到知识库中查找匹配的资料，如果找到匹配问题，那么取出回答返回；如果用户的问题模糊，还需要给出相关的推荐问题；例如问电视价格，需要追问品牌、型号、尺寸；考虑到更加真实的场景，不能只是一问一答的模式，在回答完用户的一个问题之后还可以给出相关的下一轮问题，便于用户追问。例如其他用户在询问某个型号的电器参数后，倾向于继续问价格、或类似的产品信息，那么这些问题就可以作为下一轮的推荐问题，引导用户继续提问。

三 实现技术方案

3.1 语音识别

接收用户语音输入并转成文字，可以使用百度/阿里钉钉的 js api。

3.2 意图识别与分发

很适合大模型实现，对相对简单的意图识别场景，也可以用 NLP 结合槽位配置来实现。

3.3 问答对存储

对于简单 key-value 式问答可以只采用关系数据库存储，维护问题和回答关系。但前面已经分析过，这种实用性并不强。用户会根据表达习惯输入问题，这样只存储原始问题就不够了。尤其是当问题数量很多时，我们不可能每次都把问题拿来跟库中的问题逐个判断是否相同，效率太低。所以一种常见的解决方法就是将文本向量化，然后每次提问把问题也向量化，通过计算向量距离得到相似问题；也恰好就是 RAG 做参考资料/上下文召回的环节。

通过前面的系列文章，我们可以使用《大模型 RAG：基于 PgSql 的向量检索》中提到的 Milvus 或 PgSQL 等数据库，文本向量化可以用大模型提供的 embeddings API，也可以选择经过训练后的 word2vec。

3.4 单轮问答和多轮问答/任务式问答

典型的一问一答是比较简单的模式，通过相似度匹配找到最接近的一个问题就好，不需要综合考虑上下文。但多轮问答 或 任务式问答就要复杂很多。

TaskQA-任务式问答，识别用户话术意图，并根据话术中所包含的关键参数执行指定任务的能力。其中，关键参数在智能对话领域称之为词槽。任务式对话适用于需要根据用户对话，执行具体任务的场景。比如，智能客服场景中，下单购买、退货办理等任务；智能办公场景中，差旅申请、会议室预定等任务；消费电子场景中，听音乐、订外卖等任务。

在任务式问答的多轮询问中，某一轮的输入可能很简单，如果只用一轮输入来查找相似问题就很可能因为信息过少而导致判定为意图不明确，也可能错误地匹配到其他问题，那么回答自然也就是错的。

为了解决这个问题，有几张解决方式/场景。一种是构建独立的任务式问答库，当用户提问命中这类问答时，就给后续问题打上标记，直到某一轮用户的输入完全不在库中为止。另一种常见方案是对用户本轮问题，和历史问题（一般会限定近 3-5 轮）整合后进行改写，改写成一个问题。这就要求改写的准确率要足够高，否则也会直接影响问题召回的准确率。这两种方案我们会在后续文章中展开详细描述。