[THUDM/ChatGLM-6B][Feature] 斗胆和大佬们讨论一个知识库相关的技术方案是否可行

2024-05-20 55 views
0
基于向量化和大型语言模型的知识库与交互系统

各位见笑。我就是一菜鸡,下文如果说得不对的地方请指正,莫要见怪。 就目前而言,各类开源大语言模型最大的使用方向就是知识库、问答系统等垂直领域。 目前的解决方案有二:

1、模型外挂知识库,比如【闻达】。

优点:技术比较简单,实用性比较强。 缺点:受模型token限制,自然语言文本信息承载量也比较低,能处理的信息有限,难以整合大量信息。

2、模型微调

优点:专业,准确,受限制小。 缺点:我看了charglm的lssues,貌似成功的是凤翎毛角。绝大部分都把模型搞爆了。要求太专业。

我有一个不成熟的想法,供大家探讨! 自然语言直接与模型对话,只适合人机交互。其实并不适合信息存储和大语言模型运算。 效率相对比较高的方案是知识图谱、或直接向量交互。但这种方案对于人类极不友好。 现在的可行的解决方案是使用Milvus作为知识库的检索引擎。

1、预处理阶段: 1.1 首先用text2vec或其他技术转换为向量,存入Milvus,作为知识库。 2、询问阶段: 2.1 预处理
   用户交互时,先用text2vec转换问题为向量,在 Milvus中查询,并将结果的文本内容转换为自然语言。
2.2 模型运算
   携带查询结果将和用户问题,覆盖特定引导词交给模型运算。
3、输出阶段 3.1 模型输出自然语言

如果是目前的知识系统。这里就结束了。如果要增强系统功能或者不是问题系统,系统要求长期记忆。还有接下来的步骤。

4、数据保存阶段 4.1 清洗数据,将没用的格式转换为需要的格式。
   每个模型都有自己的脾气,总爱带上自己的小脾气。如果系统也有要求,可能需要清洗没有用的特定格式。
4.2 存储数据
  使用先用text2vec转换问题为向量,存入Milvus,作为知识库或其他后续运算的长期记忆的一部分。

表面看上去没问题。其实问题很严重的。

目前,大语言模型最大的问题就是token长度限制造成的失忆问题。这使得大语言模型难以做大型任务(当然也可以通过反复提示解决,不过你不觉得累吗,也是遭罪)。AutoGPT在某中意义上最大的贡献就是解决了记忆问题。(当然,装上了手脚也很重要,不过不再本次的讨论范围内,所以用词偏颇了一点应该可以理解吧),然而,前边说过,自然语言对人类友好,但信息携带并不高。嗯,就是传说中的信息熵不高。虽然昨天才看到有大佬说AI的时代中,中文由于信息桑较高,所以占优,不过对于机器来说,其实还是没有任何优势。只能都只能是低劣。知识图谱,向量对于大语言模型来说才是最优解。 所以问题还是比较多的。 1、向量的频繁转换造成信息的丢失。当然了,方案中一直都在使用text2vec同一个模型做转换的话,问题也不大,效果如何取决于text2vec的能力。无非就是,准确性好坏的问题,但多少还是有的。而且完全可能是多余的。(没做测试,构建这类测试数据有些难,有些费功夫。) 2、如果是知识库问题还不大,输出知识一次性的。但是如果是增强系统,需要存储结果,多出来的那个过程,自然语言又转换为向量,使用时有转换回来,这一步损失就比较严重了。

我有个想法。如果模型支持向量的输入、输出、这一切的问题都不存在了(好不容易有一个可以任性用极限词的地方不罚款的地方,就让我放飞一下!)。用词夸张了,这种方案不能解决根本问题,但理论上可以在一定时间内大幅度提高模型能力和效率,并节约token空间。

1、预处理阶段:

【原流程】 1.1 _首先用text2vec或其他技术转换为向量,存入Milvus,作为知识库。

1.1【新】 变为将知识库的文本内容交给模型,让模型转化为向量,并存入Milvus,作为知识库。 2、询问阶段: 2.1 预处理

【原流程】用户交互时,先用text2vec转换问题为向量,在 Milvus中查询,并将结果的文本内容转换为自然语言。 【新】用户交互时,先让模型自己将问题转换为向量,并在 Milvus中查询,无需对结果做任何处理。

2.2 模型运算
  【原流程】 携带查询结果将和用户问题,覆盖特定引导词交给模型运算。
  【新】将结果的向量结果 与用户提问一起交给模型。无需特定引导词。
3、输出阶段

【原流程】3.1 模型输出自然语言

【新】 3.1 模型输出自然语言及向量。 4、数据保存阶段

【原流程】 4.1 清洗数据,将没用的格式转换为需要的格式。

【新】 4.1 清洗数据,将没用的格式转换为需要的格式。看实现的方案,有可能完全不需要。
   每个模型都有自己的脾气,总爱带上自己的风格。如果系统也有要求,可能需要清洗没有用的特定格式。
4.2 存储数据
  【原流程】使用先用text2vec转换问题为向量,存入Milvus,作为知识库或其他后续运算的长期记忆的一部分。
    【新】无需转换,直接存入Milvus,作为知识库或其他后续运算的长期记忆的一部分。
总结:

理论上任何模型都可以改造。而且改动幅度小,只需要给任何模型增加向量输入输出接口功能。输入输出上搞搞就行。 这样一来,只需要模型自己的向量的直接表达和交互功能+任何向量数据库不需要大规模改造模型就可以大幅度提高其工作效率及能力。 那意味着,信息0损失,配合知识库后形成长期记忆,在有限token下将大幅度提高工作能力和准确性。 当然,从此思路延伸,还有其他的方案可以优化效率和准确性。不过,不在此次本文的讨论范围内。 最后,不知道是否有研究者写过此类论文,如果没有,喜欢的可以拿去随便用,我没有相关需求,也不在乎。如果用得上的话,就拿走,给我发个消息,让我也高兴高兴!!

回答

1

其实,最佳方案是模拟人脑运作机制,让外挂知识库的向量数据的数据直接参与模型生成过程。不过,貌似需要突破的难点还很多。至少我不知道应该用什么方案。把外挂知识库加载到输入时,是目前最简单的,也最可能实现的解决方案。

0

听起来有点像Langchain的的VectorDBQA或者retrieveQA

4

听起来有点像Langchain的的VectorDBQA或者retrieveQA

不了解,明天看看。不过,已知的几个项目都是用第三方工具转换为向量,就是第一个方案。有信息损失问题。因为我提出的第二个方案要模型支持,必须改模型,模型不支持啥也做不了,貌似目前没有任何开源模型支持。

8

我觉得现在向量仅用于检索,外部知识仍然与prompt一起输入,是为了保证外部知识的语义空间和已经训练好的模型一致,才能让模型理解。直接去与第三方向量交互,不可能不涉及重新训练,而且压缩后的文本向量可能确实信息有限。

5

我觉得现在向量仅用于检索,外部知识仍然与prompt一起输入,是为了保证外部知识的语义空间和已经训练好的模型一致,才能让模型理解。直接去与第三方向量交互,不可能不涉及重新训练,而且压缩后的文本向量可能确实信息有限。

的确会有这个问题。 实际上,如果算上消费比和未来潜力,这个方案可能才是难度最小,效益最高的。 其实,这个方案是模拟人脑的工作原理,给只读的大脑机器,增加了记忆功能!实际上,造成的“后果”比你想象严重。本质上如果处理“得当”,它可能会。。。。期望是我想多了。这个方案其实实际上和搜索方案是本质的区别。和基于文本的存储方案不同。向量库成为了大脑的一部分,而不是记载记事本上的上课笔记。在某种意义上,你可以看成,向量就是运行中的电脑内存数据,我下一次运行到这里,也不会有任何损失,可以看成运行是持续的,从未终端。而用自然存储,有转换,信息是有损失的,就好像高清图片,压缩存储后,再怎么厉害也是丢失了信息的。当然,最佳的方案是让外挂库成为运算中一部分。但目前貌似做不到。但改变输入输出层的方案,倒是有一定的可行度

3

主要是向量匹配的精度达不到预期,导致获取了错误的知识输入到模型

9

主要是向量匹配的精度达不到预期,导致获取了错误的知识输入到模型

嗯,这就是信息损失的原因之一。我上文并没提到。这也是为何我说用大语言模型自己来处理加工数据的原因,也是在避免信息损失。第三方工具来做转换,损失更大,而且几乎不可消除。其他的精度问题都是开发实践问题问题了。开发过程中理论上可以各种算法降低或减少。没必要一会儿中文,一会儿英文一会儿俄文的转来转去,大家都说中文就ok了。当然和人的交互转换自然语言是没办法了。然而,这种改动,除非改模型,改应用是没用的。 其实,使用知识库的方式问题不止这一点,很多的 1、你刚才说的精度问题。 2、信息量问题。 3、取多少合适。 …… 不管怎么样具体多少条,总结之后其实就是帖子中说的,自然语言信息熵太低,模型token限制问题,语言转换信息丢失问题,三大问题。

1

听起来有点像Langchain的的VectorDBQA或者retrieveQA

刚才看了看 像Langchain的VectorDBQA 没看太明白,感觉有点像是,不同的是 VectorDBQA是使用ULMFiT模型产生的句子向量来构建知识库的。ULMFiT我不很了解。感觉应该是用这个方法替代了替代文中说的text2vec,其他流程和第一的方案没太大区别。如果没理解错的话。不过,如果真的我理解这样的话,在某种意义上,可以认为是模型自己做的转换,损失没那么大,还不懂具体的原理和细节。但毕竟人家是实验过的方案比我提出的靠谱

6

支持向量输入输出相当于给语言模型减层了,感觉没有实际意义

6

支持向量输入输出相当于给语言模型减层了,感觉没有实际意义

不是减层,这说明兄弟对大语言模型理解有问题。刚开始,我也错误的这样认为,后来发现理解错了。模型内部的向量和这个向量不是一码事。这个知识库的向量其实是句子向量,或者是段落向量啥的。而且,必须聚类压缩,否者难以存储和管理,也不利于输入输出。另外,模型输出是按字,而存储作为知识库是按句、段落,或者叫知识点。

2

支持向量输入输出相当于给语言模型减层了,感觉没有实际意义

不是减层,这说明兄弟对大语言模型理解有问题。刚开始,我也错误的这样认为,后来发现理解错了。模型内部的向量和这个向量不是一码事。这个知识库的向量其实是句子向量,或者是段落向量啥的。而且,必须聚类压缩,否者难以存储和管理,也不利于输入输出。另外,模型输出是按字,而存储作为知识库是按句、段落,或者叫知识点。

这个知识库小了没有意义,大了就不受控了,还是伦理问题。

4

上面说的思路是不是就是langchain-ChatGLM 实现的?