大模型中的RAG，一点也不好用！！！

关注飞总聊IT，了解IT行业的方方面面。

最近因为一些工作上的事情，需要学习大语言模型。

大语言模型里面最著名的开发模式就是RAG：Retrieve，Augment，Generate。

说人话就是，先从知识库里面找相关的信息，然后把这些信息塞进prompt里面去Augment用户的问题，最后，去call LLM的API，让对方产生答案。

因为大语言模型的训练数据集有局限，不管是时间还是领域的限制，肯定有缺失的知识。

所以通过这种在prompt进行Augment的办法，可以让大模型产生更好的答案。

与之对应的成本更高的，就是fine-tune。用新的相关知识去fine-tune一个模型，然后去问这个模型相关的问题。

RAG和fine-tune也不完全是对立的两种方式，即使用了fine-tune，如果知识有时效性的话，还是需要RAG。

我最近因为工作需要学习了一下RAG。

RAG首先得有个文档库。里面文档有embedding的向量，这样当用户问题过来了，才能在库里做nearest neighbor search，来决定怎么去augment prompt。

大概是因为我自己是二把刀的缘故，总体来说，我的特定需求，RAG的效果并不好。

首先我发现那些流行的开源RAG向量数据库，比如说lanceDB，好像也没多好用。

我最后发现，PostgreSQL+pg_vector插件好像就足够了,既好用又容易部署。

我不知道是不是因为PostgreSQL更成熟呢？还是我本人比较菜鸟呢？

其次呢，Retrieve出来的相关文档的准确度，和问题相关性很大。

那种非常确定的，并且文档也有非常明确答案的问题，RAG倒是还是能够比较正确地给出答案的。

要是问题变一变，需要额外来点推理啥的，RAG就不好使了。

至少我试用了手头几个比较便宜的LLM包括gpt-3.5-turbo，怎么弄怎么都经常会让人啼笑皆非。

但是，如果我真的去fine-tune一下模型，用我现在手里有的一些文档，然后部署我自己fine-tune以后的模型。

当然我的fine-tune也是瞎猫凑上死耗子，我压根就看不懂很多东西到底怎么设置，反正用着套了一层我司内部壳的大模型，用我手里有的文档信息处理一下。

然后直接用这个fine-tune以后的模型，大模型回答起来，明显就从智障级别迅速提升到有智力的级别了。

所以RAG好像只能解决一些基于fact的东西，问题比较明确，文档里面有非常明确的答案，那么就行。

问题明确，但是需要根据现有文档里面的相关答案，再推理推理啥的，就傻逼了。有的时候，满口胡说八道。

写代码尤其是。

我试着让对方生成合适的SQL，我发现，这事情，还真的没办法通过RAG让LLM里面一些很重要的catalog的信息。

然后就没办法很好的生成可以让我满意的SQL了。

当然，我还是觉得PostgreSQL确实是无敌的。其他开源的vectordb，貌似也就这样了。

但是即使是用了PostgreSQL，我这有限的时间里，发现RAG没有现在很多人吹的那么牛逼。

很多问题RAG本身不解决问题，一点也不好用。

当然，有经验的人可以赖我本人水平不行，但我也只能基于我自己使用的结果，来这里抱怨几句，说说我自己的体验。

飞总职场宝典：

飞总知识星球：