说起机器人或智能客服，如今几乎随处可见。像钉钉、飞书这类IM工具中的群机器人，不仅能进行关键词自动回复，还可以挂载各类webhook自定义服务；此外，还有专门用于企业场景的智能客服系统，高效解答重复性高的常见问题，效率远超人工；再加上能接收语音指令、识别语义的智能语音机器人，整个技术体系已经相当完善。

从最初固定的问题列表，到关键词匹配，再到NLP加深度学习，机器人的底层实现方案也在持续演进。大模型出现后，行业普遍认为：利用RAG（检索增强生成）可以快速搭建这类应用。在常规问答场景中，几乎不需要投入大量精力去微调模型，就能获得不错的准确率和召回率。

一 机器人应用

从技术演进的角度看，RAG的介入大幅降低了机器人的开发门槛。你不再需要把所有问答对硬编码成规则库，也无需针对某个垂直场景反复训练模型。只需一个通用大模型加上一个向量数据库，就能承担大多数知识问答任务。

二 常见机器人功能

以典型的问答机器人为例，核心就是拥有一个知识库。通常由大量问答对数据组成，比如：

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

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

接下来是输入方式。最简单的做法是给用户提供几个固定问题供其点选，比如选择场景、型号，然后系统返回对应的答案。这种方案只需key-value存储加字符串查找即可实现，开发虽然容易，但用户体验较为一般。因此，当前主流方案都支持自由输入，尤其是移动端的语音输入，让体验更接近真实客服场景。

用户输入内容后，系统需要执行语义理解，到知识库中匹配最相似的资料。如果能找到高度匹配的问题，就直接提取答案并返回；如果用户问题比较模糊，还需给出相关的推荐问题，例如用户询问电视价格，系统就要进一步追问品牌、型号、尺寸。更贴近真实场景的做法是，在回答完一个问题后，主动推荐用户可能追问的下一个问题——比如其他用户在查询某个电器参数后，往往倾向于继续询问价格或类似产品的信息，系统便可以将这些作为下一轮的引导问题，推动对话持续进行。

三 实现技术方案

3.1 语音识别

接收用户语音并转换为文字，常见的方案是直接使用百度或阿里云提供的JS API。

3.2 意图识别与分发

这部分非常适合用大模型来完成。当然，如果场景相对简单，利用NLP结合槽位配置也能实现。

3.3 问答对存储

如果只是简单的单轮一问一答，直接用关系数据库存储问题与答案的对应关系就足够了。但如前所述，这种方式的实用性非常有限——用户提问的方式千差万别，仅存储原始问题往往难以满足需求。尤其是问题数量增多时，总不能每次都把用户输入与库中每个问题逐一比对相似度。所以常见的做法是：先对文本进行向量化，再将用户的问题也向量化，通过计算向量距离来找到相似问题。这正是RAG技术中“参考资料/上下文召回”的核心环节。

参考之前的系列文章，可以使用Milvus或PgSQL这类数据库进行向量检索（详见《大模型 RAG：基于 PgSql 的向量检索》）。文本向量化可以通过大模型提供的embeddings API完成，也可以使用训练好的word2vec模型。

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

单轮问答比较简单——通过相似度匹配，找到最接近的一个问题即可，无需考虑历史上下文。但多轮问答或任务式问答就要复杂得多。

任务式问答（TaskQA）的核心在于：识别用户话术中的意图，并根据话术中包含的关键参数执行指定任务。这些关键参数在智能对话领域被称为“词槽”。任务式对话主要用于需要根据用户语言执行具体操作的场景，比如客服场景中的下单、退货、退款，办公场景里的差旅申请、会议室预订，以及消费电子产品中的播放音乐、订外卖等。

在任务式问答中，某一轮的输入可能非常简短。如果仅依赖单轮输入去匹配相似问题，很可能因为信息不足而被判定为意图不明确，或错误匹配到其他问题，导致答案完全偏离。

针对这一问题，目前主要有几种解决思路。一种是构建独立的任务式问答库，当用户提问命中这类问答时，系统给后续问题打上标记，直到某一轮的输入完全不在这个库中为止。另一种常见方案是：将用户当前的问题与近3-5轮的历史问题整合起来进行改写，然后再执行检索。这个方案对改写准确率的要求很高，准确率不足会直接影响问题召回的准确度。这两种方案，后续会专门展开讨论。