AI面试相关之后端、LLM与向量库（JAVA）

段段之前的帖子，讲了RAG与Doris，这次我将结合后端与大模型、向量数据库里一些比较常见的知识讲一讲，为大家的全局概念做一个补充。

讲之前先叠个甲：

1.段段是做的AIGC项目，但是很多东西接触不到，而且很多东西用不了，比较老旧和粗暴

2.AI相关的，我最近在面试，也在学习，也在结合项目思考

3.本文是自己思考和学习的结果，欢迎大家讨论，有问题请合理发言

如果你、我因为不懂AI而丢人，那就对了，因为我就是这么一步步过来的。

一、架构视角——后端与大模型到底什么关系

千万不要神话大模型，在后端眼里，大模型不是什么无所不能的神仙，它本质上是一个耗时很长，极其昂贵，很容易返回乱码的API。本质上，后端并不懂LLM内部的东西，顶多能了解，因为那是算法工程师干的活，LLM就是个黑盒API，我们的任务就是调用它，并且让他合理返回。

1.后端是喂饭的：你问大模型：小队长什么订单？LLM：小队长是谁，不认识好吧。所以我们后端的任务就是，去数据库查出小队长的订单，去redis里面查历史聊天记录，甚至去ES和向量库里查相关的说明，然后整合这些信息，拼成prompt，喂到大模型嘴里。

2.后端是善后的：大模型的返回，千奇百怪，什么格式不对，乱码，语序不对。后端要拿到这段返回，然后去做后置校验，Jackson校验。如果解析失败，还要@Retrable正则校验，甚至触发降级话术（小助手开小差了，等会再来吧！），没有这些流程，前端早就崩溃了。

3.后端是跑腿的：大模型只是个文字处理器，他不能帮你发邮件、退款、开发票。你需要通过大模型的指令后，去调用退款、邮件。发票等流程。

4.后端是兜底的：那我问个问题，是不是谁都能调用大模型？谁都能来花token？高并发场景怎么办？所以后端要做权限校验，要做高并发，要做限流，要做本地缓存，保证简单问题不调用大模型。

二、向量数据库

1、为什么要用向量数据库？

传统的关系数据库或者es库，靠的是倒排索引和关键词精确匹配，如果你去搜苹果手机，他绝对搜不到iphone15，你去搜山海经手机，他指定不知道是华为，你去搜华为od他知道是啥，但是搜牛客od他就不知道了。但是向量数据库能让计算机理解什么叫语义相似度，它是赋予大模型长期记忆和合外部知识库唯一可行的存储方案。

2、向量数据库怎么工作？

本质上就是把文字变成数字，但是有对应关系，只是这个关系计算很复杂，所以引入了Embedding 模型，我们调用一个Embedding模型，他会把一句话，转为成百上千的浮点数组成的数据（这就是向量，下一节展开说），本质上就是计算数字距离的流水线。

3、相似度计算：

当用户提问时，也就是把问题变成一个坐标点，然后去数据库计算这个点和库里所有点的距离，目前最常用的事余弦相似度。

余弦相似度：cosine，最常用，两个向量夹角，越接近1越相似

欧氏距离：算两点之间绝对直线距离，越小越相似

内积：综合了夹角和长度

4、近似最近邻搜索（ANN索引）：如果数据太多，一条条暴力距离太慢了，所以向量库底层会用HNSW（分层导航小世界）或者IVF（倒排文件），等算法建立索引。

5、向量数据库：重量级：Milvus，pinecone，qdrant，轻量级：chroma，传统转型：pgvector、es、redis都已经支持向量检索

段段用的：doris，自2.x版本之后，引入了vector和hnsw等向量倒排索引，它不仅能处理百亿级关系数据库统计，还能计算向量余弦相似度

三、Embedding与向量库

先引入案例，比如将“小队长风韵犹存”转为向量数据库的向量，结果是

然后将“小队长徐娘半老”转为向量数据库的向量，结果是

最后查看cosin余弦相似度≈0.92（92%），强相关

通过这个案例，我想讲清楚一点，为什么向量库能做到传统关系型数据库做不到的事情——向量化和余弦值匹配。

向量库核心参数：

1、Deimension（维度）：重中之重，最关键的是，他必须和Embedding完全一致，Embedding是768，维度必须是768，才能入库，而且如果后续要改维度，那么整个向量库必须推倒重建，所以这块的选择一定要谨慎。

2、Metric Type（距离度量）：上个大点说的cosine余弦值，L2或者IP，余弦值是最常用的，一定要记住

3、Top-K：就是你要几条数据，把最相似的N条给我，一般3-5

4、Metadata（元数据/Payload）：这点非常重要，你光存向量是没有用的，必须还得存储对应的时间、用户等标签

四、向量库增删改查

1、关于增删改查：

增：这个简单，数据向量化之后将id+向量入库

查：先调用Embedding将查询参数向量化，然后去查询，注意这里是混合查询，先查询出这个人的数据，再计算相似度。

改：重新调用Embedding生成新向量，根据ID进行覆盖

删：和传统数据库一样，进行覆盖删除

2、性能消耗

看到这里有些同学有疑问了，这个改和删是不是太消耗性能了？没错！以前确实是这种方式，但是现在已经优化了。

曾经的向量库，你去修改或者删除，改变节点，相当于在地图路径上把途经点抠了，这导致查询速度断崖式下跌，现在的神经网络，执行的是软删除，将要删除的id对应的bit标记为1（软删除），查询的时候，如果是1，那就跳过。

3、墓碑机制与异步后台

update操作：在底层，update = delete + insert，也就是扔一个墓碑标记到旧数据上，进行软删除，然后将新向量追加到内存里，因为都是顺序操作，所以I/O非常快，根本不需要现场改底层图索引。

异步后台：但是都是软删除和新增，垃圾数据是不是越来越多？这些数据怎么解决？向量库会自己开几个线程，做数据合并，他会在业务低峰期，偷偷的把墓碑数据清除掉，重新生成HNSW图像，然后替换掉旧的，无缝衔接，业务零感知。

补充Doris场景：因为段段用的是Doris，Doris底层是有Unique key和Merge on write底层合并机制，Doris会在引擎层自动处理好新旧版本生效问题，而且他的向量索引是依附在列上的，自动跟着标量数据保持一致性，这对我们Java开发太有好了，像写sql一样顺滑，这段内容，重点记忆墓碑机制、Doris写时合并。

以上就是本期的全部内容了，写稿不易，学习更难，欢迎大家一起讨论。AI