历时一个星期，我做出来了这个RAG知识库管理系统。

榨干了2个20刀的cursor账号，实在是太不容易了。

相比之前我直接做RAG检索的Demo，一个完整的系统，对于复杂度和扩展性的要求会更高。

这是个什么样的RAG系统

先说说当前我实现了什么吧。

如果是我是一个知识库系统的使用者，我需要一个什么样的RAG知识库呢？

我认为，通过聊天的方式，向知识库提问，知识库系统能够理解我提的问题，并且结合知识库有的资料，梳理后给出答案，并且答案能够追溯参考资料的来源。

这样子，基本上就满足用户对于知识库的检索需求。

问有所答，查有所得，言之有据。

智能问答界面

我们上界面，看效果。

首先是对话这一块，我们默认会进入到这个主页，主页可以看到侧边，有之前的对话历史。（核心能力：会话隔离，历史记录存档）

然后当我们想要了解新的主题时，可以点击【新对话】，这样就会打开新的对话窗口，可以进行交互。

当我们对知识库提问之后，可以看到从知识库找到了答案。（核心能力：语言大模型基于知识库检索的内容块，整理出回答内容）

并且在侧边，附带了参考来源，很严谨，证明不是在瞎说。（核心能力：追溯源文档）

当第一次提问没能得到很好的解释时，或者说知识库给的答案，太“专业”了。

没关系，我们可以让他以能让我们听得懂的方式，讲给我们听。（核心能力：上下文记忆）

当我们怀疑知识库的回答，到底是真的从资料里面来，还是可能是它瞎编的这件事存在疑问。点击源文档，可以看到我们检索到的多个相关文本块的内容。（核心能力：向量相似度查询，BM25关键字查找，重排序，综合评分）

从用的角度，其实功能就差不多了。

为什么做了一星期？

为什么这个系统我做了一个星期呢？因为它还有另外的重要模块——后台维护。

后台维护我做了三个板块：数据管道、向量数据库管理、检索验证。

以往我做RAG的Demo样例项目，更多的是把重心放到上面提到的，用户使用界面上。

数据这块都是在开发期处理好，也就是通过命令行执行python脚本跑进去的。缺点在于，流程不连贯，有新资料加入的时候很麻烦。

大有一种顾头不顾腚的尴尬和无奈。

而将这个管理流程系统化后，就丝滑地解决了这个问题。

管道管理功能

当我们需要增加新的文档内容的时候，进入到这个管道管理界面。

点击【新建新批次】，创建批次后，点击【运行完整管道】，就能够把下面这个流程跑起来了。

文件转换(格式转换等)——文件预处理（移除噪音内容，文本规范化）——文本分块——向量化——存储到向量数据库。

运行完成后，可以看到进度条整个都是100%，这时候说明，数据已经成功导入到向量数据库，可以用于我们的知识库检索了。

但过程，真的有这么简单吗？

——1. 文件转换(格式转换等)
——2. 文件预处理（移除噪音内容，文本规范化）
——3. 文本分块
——4. 向量化
——5. 存储到向量数据库

这个过程里面，特别是前三个，都存在很多的行业痛点。

不同的文档有不同的处理策略，有的也许很简单，有的可能非常复杂，这次就暂时不细说了。

当我们数据存储之后，得确认是不是真的存进去了。

我们先从数据库查询的角度，来看看这块是怎么检查的。

数据库管理功能

进入数据库管理界面，可以看到，支持多种方式查询。

1. 选择文档查询。
2. 关键字查询。

新入库的内容，在这里能够查得出来，说明稳了。

除去数据库查询验证之外，另一个验证的办法，就是来到检索主页面，继续检索。

这个页面是提供给开发人员和运维人员用的，所以参数会比较专业化。

维护人员检索功能

支持多个检索方法检索文本块，类似于文本块召回测试吧。

这样子我们在开发期，就能找出，最适合某些文档的检索方式，以及整个库的检索方式是否存在明显不准确的问题。也可以根据查询情况，发现性能方面的缺陷，后续进行针对性的优化。

还可以选择智能问答模式功能，这个功能内容和前台的用户使用的智能问答，几乎是一样的。

这样开发人员和维护人员在这个页面就能够完成问答效果的测试。

做个简单的Demo和做一个完整的系统，工作量不是一个级别的，差得太多了.
真正做出来的那一刻，贼有成就感。

只有把维护的功能做好了，才能放心地去放开前台界面，提供给用户进行智能检索。

在这个社群，你将获得：

• 9次价值千元的AI编程死磕实战训练营

• 超级大佬的实战经验分享，商业化思路，前沿AI工具和技巧

• 和一群积极的AI编程同行者共舞