Openai通用特定领域的智能语音小助手

无穷尽的Q&A

钉钉...钉钉... 双双同学刚到工位,报销答疑群的消息就万马纷沓而来。她只能咧嘴无奈的摇摇头。水都还没有喝一口就开始“人工智能”的去回复。原本很阳光心情开始蒙上一层薄薄阴影。在这无休无止的Q&A中，就算你对工作有磐石一般强硬，有芦苇一般坚韧... 也经不住如此水滴石穿般消磨。工作激情便如磨刀之石，不见其消，日有所损。

然则，不只双双有这样的困境，人事的同学也是每天为各种简单的咨询扰得不胜其烦，牢骚满腹；还有负责合同用章的coco同学同样不堪其扰... 更让人苦恼是无人值班的周末，问的同事在焦急的等待，而支持的同事可能无法及时响应...

“母婴护理”做为公司的核心业务，虽然每个护士同学上岗前都有过专业的训练，但是在实践过程中难免遇到各类问题，这时她们只有去问有经验的护士或者护士长...

所有种种问题，最后都是由一名“专家”完成了解答。这个“专家”在哪里，这成了我一直思考的问题。显然，我还不至于去搞一个真正的“专家系统”。

OpenAi Assistant 横空出世

面对上面的困境，我们也有尝试使用 openai 的 emebedding能力，但是效果不是太好，并且每次问答要花费50美分；也用闻达独立搭建过，就是不太稳定（可能是没部署好吧，老是要重启）。一直在想，为啥如雨后春笋般出现的各路大模型，没有一个可以非常方便的让我们导入领域知识呢。一筹莫展之时，OpenAi 11月7号的发布会给我带来了希望。其中新增的Assistant就如立于高山之巅远看东方已见光芒四射喷薄欲出的一轮朝日。发布会只有45分之短，但是其涵盖的内容却不短。鉴于英文听力能力欠缺，找了一个“AI同声中文版”发布会视频，有需要的可以点击「链接」观看，一定不虚此点。

一个简单的通用方案&问题

OpenAi 的assistant 已经具备了根据提供的领域知识检索（retrieve）特定问题的答案了。接下来就是接入企微自建应用，考虑到语音便利性，这次增加了对语音的支持，通过腾讯云asr接口识别语音，再通过文字调用Assistant。大致组件如下图。其中问答有个特别的地方就是在创建一个 “Run”后，需要轮询检查其是否是终态，如果是 “completed”再去检索消息，获取最终的回复。

实现一个Assistant的流程如下，为了偷懒，我就直接在平台创建了assistant及上传文件。

1.Create an Assistant in the API by defining its custom instructions and picking a model. If helpful, enable tools like Code Interpreter, Retrieval, and Function calling.

2.Create a Thread when a user starts a conversation.

3.Add Messages to the Thread as the user ask questions.

4.Run the Assistant on the Thread to trigger responses. This automatically calls the relevant tools.

有了想法，趁着大好的周末，早上带着两娃去学校踢球，贪婪的享受着冬日阳光，消耗完体力娃子们，吃过午饭便早早的开始了午睡。趁着着孩子们睡觉的光景，我又有大把的时间开始打代码实现想法了。有时真感觉自己不再年轻了，遛个娃，写个代码就觉得可以受用一个周末。

由于之前的一些准备工作，不到两小时demo就基本完成了。没有压力之下的代码，几乎不用调试就跑起来了，原来没有压力也可以动力十足，也许这就是专注的力量。基本用起来是没啥问题了，唯一的问题就是响应时间几乎在30秒左右。对于人事一类的问答尚可，一些需要快速响应的场景，这个时间稍微慢了些。

近些时间尝试过好几种方式，这里也简单做个对比,鉴于能力，这个对比不一定准确，仅供参考。

方式	响应速度	单次花费	稳定性	整体
Fine-tuning	20s	低	高	训练成本高，难度大。效果不好。
Embeddings	20s	高（50美分）	高	单次成本高，回答不全面
Assistant	30+s	低(数美分)	高	回答全面，响应速度稍差
闻达	20s	无	低	自备服务器，稳定性不太好。