lishiying

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

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

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

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

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

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

我是菜鸟,看各位大神都说得很高深.问了一下claude。差不多就几个意思，1、需要更大的数据集。2、数据太少。3、数据精度不够。4、调教方法有问题。。。。。。感觉好有道理，和没说一样！！！！！

> 遗忘原来的内容这个问题没有解决，ptuning的意义就不大了。希望能解决。 这个问题恐怕解决不了，token长度问题，这和模型规模有关。就算可以增加，我看chatglm的说法，是增加之后，效率会急剧下降。唯一的解决方案就是大概特改，不是改模型的问题了，是改架构。也就是说，这个项目可以直接关了。不过在应用端，应该可以适量优化，就是使用向量技术，优化压缩token。但解决不了本质问题。除非是外挂知识库，并且修改架构

在这个地址上增加一个需求，可不可以不是一个输入框，而是指定硬盘上的一个文件。这样便于修改。比如第三方工具自动增删改查

可以考虑自动关联，比如指定自动读取某一个文件夹中的同名文件。这样可以在最小工作量下保持友好的用户体验。 当然更加的方案是直接打包大模型中。