构建一个基于Embeddings和GPT技术的聊天机器人

clean

摘要：
In this article, we learn how to craft a customer support chatbot using the latest GPT techniques from simple to complex. We will introduce you to techniques such as embeddings, “few-shot” prompting, vector database, paraphrasing, and intent classification. The article also details the process of scaling the chatbot and supporting contextual answering, appeasing customers, and calling external APIs.

Tags：GPT, Embeddings, Vector Database, Few-shot Prompting, Software Engineering

阅读时长：10mins

链接：Crafting GPT-Based Customer Support Chatbot From 0 to 1 — Algorithm Portion

cxy

两个月前也弄过一个chatglm(gpt)+langchain(embedding)的问答机器人，外接知识晚华的知识库，向量库用的是faiss，检索用text2vec。
langchain的生态位很好，这种实现感觉还是玩具形式为主。因为小模型的能力终究是打不过gpt-4或者gpt3.5这种背后100B+的大模型，搞垂直领域也很多人在弄，也没见到几个能拿得出手的。
最近大模型和GPT的浪潮冷却了一点，可以多去看看目前存在的问题。个人觉得主要是卡在数据获取和处理这第一步了，后面可能就是一些计算资源的问题，技术上不是难题。 :

clean

cxy

个人认为这种实现模式不是”小模型“，因为用到的embedding和gpt都是大模型，embedding生成向量数据库之后就没有所谓模型的概念了。

用gpt做fine-tuning生成所谓”大模型“在某些方面可能要比embedding好，但是会乱答。更加适合开放性的场景。

至于是否为玩具，据我所知，目前大部分客服机器人都是使用传统的bert模型（蔽司）做向量化，bert需要比较多的label人力，并且效果不见得比openai的embedding模型好。

目前比较大的问题是数据隐私问题。OpenAI的数据保护做得并不好，所以大公司都在自研大模型，想要用自己的模型来做这些事。

cxy

clean
大模型根据参数量分好几个档次，我说的小模型是指7b 13b参数量的，30b 60b 或者100b（openai）是相对来说的大模型。参数量简单理解就是模型的脑容量，大模型是通用领域的多面手。

大模型在垂直领域的落地也有很多了，但是垂直领域会面临微调数据不足（首要问题）其次是计算资源，其实归到底就是钱够不够的问题，不是所有企业都像openai，大模型每到一个阶段都劝退一批人，但是也给很多人带来希望。

大模型和垂直领域扯远了，说一下向量化。向量化核心就是算相似度，在高纬向量空间中可区分，就是embedding空间的概念，然后就是向量存储，用的时候就是靠向量检索。

而且向量化不是只能走openai的embedding模型（达芬奇或者其他），研究文本相似度那批人做的simbert，m3e 等基于Bert或者sentenceBert做改进的，其实都可以用在这个embedding或者检索上，因为向量数据库的存储会涉及到构造高效的数据结构，也拿上面提到的faiss，是基于堆构造的。

我也对大模型研究了一段时间，也有一些垂直领域的落地经验，对大模型或者NLP技术感兴趣的可以多交流交流 ;-)

aukocharlie

最近在落地类似的产品，目前在向量检索后会走搜索引擎作为旁路补充，再合并排序。我有一个想法是在排序的时候根据向量的源文本的一些属性（如阅读数）来计算最终分数，但不知道该怎么设置这些属性的权重，看看大家有没有好的想法

Elpis

aukocharlie 可以让model自己去学习权重，把这些附加属性通过一个MLP得到一个embedding，然后和文本的embedding add或者concat起来，在把这个新的文本向量送进原来的model里面训练就可以了

aukocharlie

Elpis 我现在 embedding 完没用来训练，现在就直接写到向量数据库了，向量检索完就直接用了。我一开始的想法也是把附加属性当做一维或多维 concat 到 embedding 结果上，相似度匹配的时候，用一个很高的数字来替代 query 中对应附加属性位置的维度，以此来实现 distance 可以受到附加属性的影响。但想来有些 hack。。。

而且现阶段也不太方便引入模型，因为我也不知道这些附加属性对于最终到 LLM 返回的回答到底有没有用，所以也不知道该怎么标注数据 😑