从后端开发视角认识向量数据库

以ChatGPT为代表的大语言模型应用自问世以来已经火了好几年。在这期间国内外类似产品层出不穷，甚至公司内部团队都开发了好几个AI小助手。刚好最近看了几篇关于大语言模型应用开发的文章，借此了解了一下应用层面的基本知识，也算是接触到了大语言模型领域的一点点边。

写在开头

作为一名纯粹的后端开发，平时的工作内容基本都是面向业务写代码，常常自嘲是CRUD Boy。 在ChatGPT等产品出现后，使用最多的场景就是把它当成搜索引擎，查一些不常用语言的语法和示例代码。

从个人体验来说，此类需求的查询质量比Google要好一些。起码很多示例代码稍作修改都能用，起码不用像某些网站，复制代码还要先登录(说的就是你CSDN)。

选择“向量数据库”作为第一篇大语言模型(后面统称LLM)相关的文章，是因为对于后端开发者来说，数据库平时接触的会多一些，拥有一定的基础，学习和理解起来也会更容易。

LLM的缺陷

在写向量数据库之前，还得从实际使用的角度出发，聊一聊LLM的一些缺陷。

1、文本长度限制

如果大家使用过ChatGPT这类产品，肯定遇到过此类提示"输入内容长度超过限制"。顾名思义，文本太长了，但提示背后的原因还是值得深究下。尤其是有些时候，明明每次输入的文本就没几个字，怎么就超过限制了呢？

这个问题的源头，当然是LLM在作祟。首先LLM不是以单词个数来确定长度，而是以 token 来计算。不同标记方法(tokenization method)，得到的结果也不一样。举个简单例子，文本"ChatGPT"，可能被拆分成"Chat", “GPT” 2个token，换个算法可能就是另一个结果。

另外不同的LLM， token长度限制也不一样。GPT-3.5 限制大约是4096，GPT-4 限制约是32K。不同的文本长度限制，涉及LLM对算力、理解能力的权衡。这属于更深层次的范畴，这里只要知道有这么个逻辑即可。

不过有的时候我们输入的文本明明很短，肉眼估算还远远没达到最大限制，ChatGPT为啥还会提示超过限制呢？

要解释这个问题，就得从LLM应用开发的角度出发。在ChatGPT这类应用中，新建一个聊天窗口，并与之一问一答的过程中。其背后的执行程序，并非是每次将输入的文本，原模原样的发给LLM。而是将上下文进行了组合，再添加最新的输入信息，一同发送给LLM。

这也就解答了上面这个问题，毕竟问答的次数越多，组合在一起的文本(token)就约接近上限。

2、内容更新滞后

训练LLM的数据集，是取自于当时已有的数据（静态数据集），因此无法保证数据集的实时性。ChatGPT刚刚出来的时候，就有提到只能查询21年之前的信息。这就导致了一部分依赖最新数据的业务无法直接使用LLM。

毕竟重新训练一个LLM的时间成本和金钱成本都是很庞大，否则各种LLM也不会只局限在"大厂"之间竞争。

3、效率与准确性

除了上面2点外，LLM也存在产生与客观事实不符的回答(幻觉)；以及处理长文本时效率低的情况。这里也不做展开，有兴趣的同学可以自行搜索相关文章。

站在巨人的肩膀

为了解决上面提到的这些问题，业界有两种主流的方式：微调(Finetune) 和 检索增强生成(RAG)。

特征比较	RAG	微调
知识更新	直接更新检索知识库，无需重新训练。信息更新成本低，适合动态变化的数据。	通常需要重新训练来保持知识和数据的更新。更新成本高，适合静态数据。
外部知识	擅长利用外部资源，特别适合处理文档或其他结构化/非结构化数据库。	将外部知识学习到 LLM 内部。
数据处理	对数据的处理和操作要求极低。	依赖于构建高质量的数据集，有限的数据集可能无法显著提高性能。
模型定制	侧重于信息检索和融合外部知识，但可能无法充分定制模型行为或写作风格。	可以根据特定风格或术语调整 LLM 行为、写作风格或特定领域知识。
可解释性	可以追溯到具体的数据来源，有较好的可解释性和可追踪性。	黑盒子，可解释性相对较低。
计算资源	需要额外的资源来支持检索机制和数据库的维护。	依赖高质量的训练数据集和微调目标，对计算资源的要求较高。
推理延迟	增加了检索步骤的耗时	单纯 LLM 生成的耗时
降低幻觉	通过检索到的真实信息生成回答，降低了产生幻觉的概率。	模型学习特定领域的数据有助于减少幻觉，但面对未见过的输入时仍可能出现幻觉。
伦理隐私	检索和使用外部数据可能引发伦理和隐私方面的问题。	训练数据中的敏感信息需要妥善处理，以防泄露。

微调可以简单理解成重新训练模型；RAG则被称为LLM的外挂，与微调相比在成本上有着明显的优势。此外RAG技术已经在问答系统、文档检索等领域都取得了成功。

LangChain

LangChain 是一个开发框架，能够方便开发者快速构建RAG应用。类比成java中的springboot可能会好理解一些。

下图蓝框部分就是LangChain的核心链路，同时也是RAG解决LLM缺陷的实现链路。接下来要讲的“向量数据库”，就是其中的核心组成部分，在下图中以红框标注。

向量数据库

前面铺垫了这么多，终于来到了重头戏。向量数据库与我们常用的传统数据库，如MySQL、Redis等最大的区别在于它存储数据的方式，以及提供的查询能力。

传统数据库的局限

对于传统数据库，搜索功能都是基于不同的索引方式(B\B+ Tree、倒排索引等）加上精确匹配和排序算法等实现的。本质还是基于文本的精确匹配，这种索引和搜索算法对于关键字的搜索功能非常合适，但对于语义搜索功能就非常弱。

比如搜索“狗”，传统数据库里只能查到关键词带有“狗”的相关结果，无法查询到“柯基”、“泰迪”这些字段里不包含有“狗”的数据。这样的查询结果其实是不准确的。

如果要解决这个问题，常见的办法就是引入新字段作为“特征”。下次查询就可以通过“特征”字段的值进行筛选，得到所有“狗”的数据。

生成和挑选特征这个过程，有个专门的领域：特征工程(feature engineering)。特征工程是一个过程，这个过程将数据转换为能更好的表示业务逻辑的特征，从而提高机器学习的性能。

如果将特征提取扩展到非结构化的数据，比如图片、音频、视频。它们包含的特征数量会非常庞大，提取特征的时间、金钱成本也会几何倍的上升。

Vector Embedding

embedding(嵌入)技术，能够以自动化的方式提取数据的特征(包括结构化数据和非结构化数据)。embedding的具体实现依赖不同的算法，将原始数据转换为向量数据。

如上图所示每只狗对应一个二维坐标点，有些狗狗之间的差异很大(最简单的判断方式：点之间的距离)，因此能轻易的区分开来，比如金毛和柴犬。

同样有些狗狗之间的距离就很近，说明在[毛长,体型]的维度上，它们很相似。如果要提升区分度，只要添加新的维度，从其它的特征区分，比如鼻子的长短，然后得到一个三维的坐标系和每只狗在三维坐标系中的位置。

理论上只要特征/维度足够多，就能够将所有的狗区分开来，最后就能得到一个高维的坐标系，虽然我们想象不出高维坐标系长什么样，但是在数组中我们只需要一直向数组中追加数字就可以了。

事实上，世间万物都可以用一个多维坐标系来表示，它们都在一个高维的特征空间中对应着一个坐标点。当然这些坐标点的准确性，非常依赖embedding技术。

市面上有很多厂商提供了商用的embedding api，例如OpenAI、文言千帆、讯飞星火等等。甚至同一个厂商还会提供不同版本的api，根据底层模型、算法不同，收费标准也不一样。

相似度搜索（Similarity Search）

借助embedding技术，我们可以将世间万物抽象成一组组向量数据，并存放到向量数据库中。有了数据，下一步就是如何使用了？这就不得不提相似度搜索了。

其实上面已经提到过了，判断2个向量之间的相似度的方式，就是计算2个向量之间的距离。这只是计算相似度方法的其中一种。

用最简单的二维坐标系作为示例；

1、欧几里得距离

欧几里得距离是向量之间的绝对距离，两个向量之间距离越小，就表示越相似。 这种计算方式看似最简单，但计算结果很容易产生偏差。比如当2个维度的单位不同时，结果可能会失效。

2、余弦相似度

余弦相似度是通过计算向量之间的夹角，两个向量的夹角越小，就表示越相似。 这种计算方式对向量长度不敏感，只关注方向的相似性，所以也很容易在一些场景下产生偏差。

3、点积相似度

点积相似度则是计算向量之间的点积，点积越大，就越相似。 点积则兼顾了向量的长度与方向。

这些计算相似度的方法，本身并无法定义有优劣之分，只能说它们有各自适用的领域。毕竟AI应用范围如此广泛，没有最好的，只有最合适的。

过滤(Filter)

实际查询时，肯定不希望每次对全量的数据进行搜索，这样效率就太低了。向量数据库也有这方面的考虑，它一般会维护2个索引：向量索引 、元数据索引。

元数据索引有点类似MySQL上的唯一索引\普通索引。在真正执行时，不论是前置过滤，还是后置过滤，都是借助元数据索引来减少查询范围，达到提升查询效率的目的。

回到RAG

到这里向量数据库的基本知识点写的差不多了，回过头来，还剩下向量数据库在LLM中是如何发挥作用的？ 其实LangChain的那张流程图已经回答了这个问题。这里又重新画了一个更加简单的流程图。

在没有引入向量数据库前，和LLM交互的流程如上图红色剪头所示，输入的查询文本会直接结合上下文构造出Prompt(可以简单理解是LLM的request格式)。

而引入了向量数据库后，查询链路就多了蓝框中的这些步骤。输入的查询数据 会经过embedding先处理成向量数据，再请求向量数据库查询得到最匹配的文本(TopN)，最终组合最初的问题构成Prompt。

这样做的好处就是，减少了上下文的大小，可以用更准确且精简的文本构造prompt，从而提升LLM回答的质量与效率。 另一方面因为数据源的外置化，可以很方便的更新向量数据库里的数据，实现LLM应用的快速迭代。

如何学习AI大模型？

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

第一阶段： 从大模型系统设计入手，讲解大模型的主要方法；

第二阶段： 在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用；

第三阶段： 大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统；

第四阶段： 大模型知识库应用开发以LangChain框架为例，构建物流行业咨询智能问答系统；

第五阶段： 大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型；

第六阶段： 以SD多模态大模型为主，搭建了文生图小程序案例；

第七阶段： 以大模型平台应用与开发为主，通过星火大模型，文心大模型等成熟大模型构建大模型行业应用。

👉学会后的收获：👈
• 基于大模型全栈工程实现（前端、后端、产品经理、设计、数据分析等），通过这门课可获得不同能力；

• 能够利用大模型解决相关实际项目需求： 大数据时代，越来越多的企业和机构需要处理海量数据，利用大模型技术可以更好地处理这些数据，提高数据分析和决策的准确性。因此，掌握大模型应用开发技能，可以让程序员更好地应对实际项目需求；

• 基于大模型和企业数据AI应用开发，实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能， 学会Fine-tuning垂直训练大模型（数据准备、数据蒸馏、大模型部署）一站式掌握；

• 能够完成时下热门大模型垂直领域模型训练能力，提高程序员的编码能力： 大模型应用开发需要掌握机器学习算法、深度学习框架等技术，这些技术的掌握可以提高程序员的编码能力和分析能力，让程序员更加熟练地编写高质量的代码。

1.AI大模型学习路线图
2.100套AI大模型商业化落地方案
3.100集大模型视频教程
4.200本大模型PDF书籍
5.LLM面试题合集
6.AI产品经理资源合集

👉获取方式：
😝有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓