一键式AI智能知识库-谈如何打造人性化的LLM RAG知识库的重要性

 RAG系统简介

在现代的LLM RAG（Retrieval-Augmented Generation）系统中，数据流的设计至关重要。让我们通过一个具体的例子来详细描述一个标准RAG系统的数据流。

首先，用户可以通过多种应用入口访问系统，包括PC应用、微信应用、小程序应用和企业微信等（如图中的1所示）。用户在这些平台上提出问题，例如“AKSO天御分代表什么意思？”。

接下来，问题被传送到企业私有模型引擎（图中的2），该引擎会使用NLP技术计算问题的余弦相似度。余弦相似度公式如下：

通过计算问题与知识库中各个答案的相似度，系统可以识别出最相关的答案。

然后，系统会将问题的向量表示传递给QDRANT向量数据库（图中的3）。QDRANT数据库会根据向量相似度返回一系列可能的答案及其对应的余弦值。

这些答案会通过API接口传递到微服务（图中的4），微服务会根据余弦值筛选出最符合用户问题的答案，并将其ID传递给缓存/ES/文本服务（图中的5）。缓存/ES/文本服务会根据ID查询具体的答案文本。

最终，系统会将精确的答案返回给用户（图中的6和7），用户可以在其使用的应用平台上看到答案。整个过程实现了从用户提问到系统返回答案的高效数据流。

在传统的RAG系统中，数据一般是进向量库的，这就需要使用向量数据库来存储和管理数据。目前市面上有一些开源和商业的向量数据库可供选择，例如：

1. Milvus：Milvus是一个开源的向量数据库，具有高性能、可扩展性好的特点。它支持多种相似度计算算法，可以满足不同场景的需求。但是，由于是比较新的项目，生态还不够完善，可能存在一些功能上的不足。

2. Faiss：Faiss是一个由Facebook开发的开源向量检索库，具有高效的相似度搜索能力。它支持GPU加速，适用于处理大规模的向量数据。但是，它的功能相对比较简单，不支持像Milvus那样的多种相似度计算算法。

3. Qdrant：Qdrant（读作 quadrant）是一款极具颠覆性的向量相似度搜索引擎和向量数据库，旨在为用户提供生产就绪的服务，并配备了便捷的API，可用于存储、搜索和管理带有额外负载的向量数据。其独特之处在于专为扩展过滤支持而设计，使其在各种基于神经网络或语义匹配、分面搜索等应用中得到广泛应用。

   Qdrant的出色性能归功于其使用Rust编写的特性，即使在高负载下，它也能够快速、可靠地工作。关于性能方面，基准测试结果显示其处于行业领先水平，堪称性能的典范。

   利用Qdrant，embeddings或神经网络编码器可以直接转化为完备的应用程序，无论是用于匹配、搜索、推荐等功能，都能得心应手。

   此外，Qdrant备受Github社区推崇，其每天以惊人的500 star的速度飙升。其良好的性能被认为是当今的技术先锋，可在内存、硬盘、Docker、Cloud等多种模式下灵活使用。

   Qdrant的特点不仅包括方便的增删查改功能，还支持多模态数据库和RAG（+Aleph Alpha embedding 技术），为用户提供了更广泛的应用场景和更高的灵活性。

4. Elasticsearch：虽然Elasticsearch主要是一个文档型数据库，但是它也可以用来存储和检索向量数据。它具有成熟的生态系统和强大的查询能力，适用于复杂的搜索场景。但是，由于不是专门针对向量数据设计的，可能在性能上有所欠缺。

 当前的RAG系统在企业落地时碰到的难点

在探讨LLM RAG系统中的知识库建设时，我们不得不面对一个核心问题：如何确保这一技术不仅强大，而且易于维护和操作，以实现真正的AI普惠。当前，大多数RAG系统依赖于向量数据库的维护，这些数据库支持基本的增、删、改、查操作。然而，这些操作往往要求使用者具备深厚的技术背景，包括对AI的理解和编程技能。在实际的商业应用中，尤其是当语料数据量巨大，如每周需要处理30-50万字时，这种技术门槛成为了一个巨大的障碍。

想象一下，如果每次向量库的维护都需要专业的程序员或架构师介入，这对于企业而言无疑是一项巨大的成本负担。这不仅包括直接的人力成本，还包括时间成本和潜在的错误风险。在AI项目中，知识库的维护是至关重要的，它是所有数据和语料的核心。如果知识库的维护复杂且成本高昂，那么这个项目的通用性和可扩展性将大打折扣，难以实现广泛的应用和普及。

当前大都知识库操作时对操作人员在技术上要求太高企业负担不起

譬如说，某商超有20万SKU、每个SKU有自己的Master Data，一次维护入库达100万字（这只能算中型规模的项目，我们碰到过有一次亿级别的文字入库）。

通常来说，我们不可能一次进入就宣告知识库训练成功的，总会这边补补、那边补补，对吧？

错误重试、断点上传的操作

有时因为网络抖动、模型一下反应不过来会伴有：错误重试、断点续传还掺杂着各种索引？对不对？

那么知识条目从明文进入知识库后是向量化存储的，两者的“primary key“还要建立mapping关系。一旦当一个知识条目要维护时比如说：更新，我们都知道embedding那可没有update操作，一般来说我们要删除该条目后再做上传。

误操作、数据弄脏了

有时一个误操作或者把一批好的数据弄坏了，那么就要重新上传，甚至还要重新打标签。有时一个错别字产生了，也是删除原有的再重新上传（或者是覆盖式上传）。

索引

一系列的反反复复操作，索引会失效，那么需要重新索引。而数据量的大小又决定着索引时引用的策略不同。

对于企业来说运营成本太高

以上这一系列的操作对于一个业务型企业来说，领导是听不懂这些的。而我们日常又经常发生着：

小张，这3条数据修一下；

小李，这一批服帽的标签要增加XXX属性；

小王，能否把这一批数据导出成Excel我让业务做些补充你再上传；

一旦上了RAG系统，企业每天都会发生这样的事，试想每一次都是动用3-5个具备AI开发资质（可能还不够，我看到过天天动用20个程序员来做RAG系统中数据的各种运营操作）

连着修6个月数据你可以试试，算一笔帐就知道这是什么成本了。

且不说把程序员做废了，是否真的人家愿意陪着你做这个事连续几个月呢？

而且还有一点，这种我们称为运营上的操作是需要本身是那些天天接触第一线的业务运营人员去操作才更显得有效率，这是因为一线业务运营人员熟悉这方面业务知识，这个知识库条目或者说这样话术、描述这一条知识点客户是否“埋单”、是否接受度更高是他们说了算的。

而现在。。。。。。

为了天天维护这个知识库还要给每个程序员配一个业务运营，没事解释业务、开业务沟通会、understanding会、next action。。。oh my。。。大公司病了。。。这等于是产生了用了原来两倍的精力去做一件很简单的事。

关键点还在于，向量世界的知识库运营这个概念还不为太多人所知。

怎么来看待向量世界的知识库运营这个概念

我们知道一个线上零售公司，有一个团队是直接影响着企业的收入的，这个团队叫“运营”。他们干的事主要包括但不限此范围：

1. 货品的上下架（全渠道的）；
2. 商品文描、图片；
3. 爆文、软文引流；
4. 社团、KOL的组织；
5. 促销的维护和发起；
6. 售前售后的维持；
7. CRM的分析；
8. 等等等。。。

这是一个数字化零售企业的核心团队。

那么换成AI型的业务公司，你的RAG系统中的向量即知识库（包括商品SKU、参考文档、客户资料等等等），只要进入向量的我们把它统称为“知识库”，那么对于这个“知识库”的维护就等于以前我们的运营人员做的事是同等的重要。

对于线上零售企业来说一支运营团队的工作不是成本，而是真金白银的来钱的。现在你有了AI，AI是用来普惠的，这下好！

人家真金白银的来钱！

你是真金白银的付出钱！而中是为了维护这么一套“高技术含量的知识库”！

如果真的这样做那么一切将事与愿违！

这边多说一句，一大半或者说70%以上的AI项目、公司在知识库的维护上没有做好。

这也就是我在我之前的博客中提到的那个点：即“技术不是用来炫的而是用来真的做到降本和担效的”。

一旦偏移了这个点，要么整体企业、项目做事会低效亦或者是成本急剧上升。。。更甚者为又低效、成本又高，于是这个事就不会长久了。

成功RAG的三个核心因素

1. 省

以最经济但要最有效的来回Token数、硬件费在最大程度上满足企业的需求。并不是最贵的就一定是最好的。“做贵不是件技术活，真正的技术活就是要用算盘算也要造出原子弹”。这才是技术。

2. 快

会话速度要快、响应要快

性能要高、单次会话不能像很多市面上的LLM什么一秒只能出15-20Token，1,400-1,600Token的来回对话类要在3-4秒完成、批跑控制在一条2,000Token在5-7秒内。

运营维护上要便捷和快速且有效

同时还要便于扩展，此处便于扩展就有一条即：运营快、修数快、具备大规模商业运营的条件。它不能是在实际运行环节中说：万事都找程序员这么一种状态。

如果这个系统真的这么“金贵”那么AI没有起到普惠人类的目的而是变成了消耗人类为目的了，这偏移了AI发展的宗旨了。这种项目也就没有存在的意义了。

3. 准

几乎0幻觉、有幻觉也可以快速发觉有效解决和热更新解决而不用事事去做Lora、FineTune。这边还是多说一句，一个要商用的RAG如果动不动要Lora、FineTune（2，3次也算了-在上线初），如果经常要做那说这个系统“太金贵”了。太金贵不代表好只能说这个系统无法普及和商用。

我们是如何设计我们的知识库的

为了解决“快”字决中的“可以快速铺开、普及、便于企业大规模运营”这一问题，我和我的团队的知识库设计理念是追求极致的用户友好性和操作简便性。我们采用了QDRANT这一强大的向量库，并在此基础上，特别强调了用户界面的直观性和易用性。通过一键式操作和傻瓜式操作的设计，我们确保即使是非技术背景的用户也能轻松管理和维护知识库。这种设计不仅降低了企业的运营成本，也使得AI技术更加亲民，真正实现了技术的普及和普惠。

高度友好的图形化界面，把那些复杂的、需要具备RAG、Embedding的知识全部封装成了一个个业务的点击、操作动作。

 让技术“透明化”、普惠化，使得让业务在操作向量库内的知识条目时和操作Word一样简单而掩藏那些技术底层所在的复杂性，以做到技术真正的为业务去赋能。

追求“快速、高效、高质”是我们这个团队一直以来坚持的目标。如何把高深的技术普及到大众是我们一直在思考的课题。为此我们还在知识库内植入了一系列的AI工具：

这些工具能够自动处理大量的数据维护任务，如自动化的数据清洗、分类和优化、自动打标签、翻译、扩充甚至AI帮写。

这不仅大大减轻了用户的负担，也提高了数据处理的效率和准确性。通过这种方式，我们的知识库不仅技术先进，而且实用性强，能够适应各种规模和类型的商业环境，推动AI技术在更广泛领域的应用。

结尾

在构建LLM RAG系统中的知识库时，我们必须认识到，这不仅仅是技术层面的挑战，更是一个需要综合考量人性化和用户体验的复杂任务。强大的Embedding技术固然是基础，但若不能与友好的用户界面和智能化的辅助工具相结合，那么这一切的努力可能会付诸东流。

这一切的背后，是我们对于AI技术的追求，不仅仅是为了技术的发展，更是为了让更多的人能够受益于AI的力量。我们相信，只有将技术融入到人们的日常生活中，让它变得易于理解、易于操作，才能真正实现AI的普惠。正如我们所说，技术的最终目标应该是为人类的生活带来便利和改善，而不仅仅是停留在繁琐的操作和高深的算法之上。

因此，我们将继续努力，不断优化我们的知识库系统，使其更加智能、更加易用，让每一个人都能轻松地享受到AI带来的种种便利。在未来的道路上，我们将不断追求技术与人性的完美融合，为实现AI的普惠贡献我们的力量。

最后还是提一句：我和我现在这支团队的信念就是让AI不再是遥不可及的概念，而是每个人生活中的必备伙伴，让我们一起迎接这个美好的未来吧！