talentyiyy的专栏

中我们处理了外部并发的一致性问题，主要是反馈在多用户搜索的过程中，解决出现的查询混乱问题，从本质上来说，如果你只是想想，问题可能就不应该出现，因为web socket 在进行 b/s 交互时，你稍微懂点原理，都应该明白通道是独立的，数据不应该发生混乱的现象。但是发生前，如果query 比较多，将会使得 remove cache 的动作滞后，时间一长，造成系统资源在某时刻的飙升，这是你无法接受的。当cache 在此过程中发生删除时，query 单例，如果存在，稳住acquire ，不删除。

在实际应用中，Redis 用户可以根据具体的需求和场景选择适合的持久化方式，或者同时使用 RDB 和 AOF 两种方式来确保数据的安全性和可靠性。例如，可以使用 RDB 作为数据恢复的备份手段，同时开启 AOF 来保证数据的实时性和可靠性。

今天主要说的是与Flask 粘和度较高的另一个处理组件 Flask-socketIO。下面会说到他与RAG结合的地方，其实蛮有用的。用户在使用基于 RAG 系统的应用时，可能会产生实时的交互反馈（如点击、评论、评分等）。Flask-SocketIO 可以实时捕获这些反馈，并将其传递给后端进行处理，进而调整 RAG 系统的生成策略或优化生成结果。好了，通过上面的介绍，你对flask-socketIO的使用，应该有了比较全面的认识和理解。还是那句话，看完不顶用，只是第一步，要自己尝试下才是你的。

Flask 是一个使用 Python 编写的轻量级 Web 应用框架。它基于 Werkzeug WSGI 工具箱和 Jinja2 模板引擎。Flask 被设计用来快速开发 Web 应用，并且具有可扩展性和灵活性。它允许你使用 Python 编写 Web 应用，而不需要编写大量的样板代码。Flask 特点很多，我提取几个比较有代表性的特点，使你从功能层面对他有一定的大概了解。这种语法应该是比较简单，你只要写过代码，都是大同小异。

通过专栏前面文章的学习，你对milvus的设计理念，思路，运作流程及落地使用应该有比较深刻的领悟。当然这前提是前面的内容你都有自己step by step 做过，不经历亲身实践永远无法到达很高的层次。attu2.4x的理念及安装过程在已经详细叙述过，今天我们看下milvus2.4x 配套的 attu UI 如何使用。在使用过程中，你也能体会到milvus 从功能上做出的调整与改变，且能从中窥探到为适应这种改变Milvus 进行的数据结构调整。并结合之前的milvus设计理念再次系统的做下系统层面的讲解。

但是当数据量到大一定程度，可视化的统计工具就会有些帮助了。今天主要是从下载，安装，使用及注意点来详细阐述下Milvus 可视化工具 attu 的使用。网上有有些解决方案，但是其实都不是很完美，因为你总要付出一些额外的‘代价’，无论是时间，还是维护数据本身。本质上其实他不只是一种 UI 配置问题，其中也蕴含了软件的设计模式思想，以及对docker 网络模型的认知和理解。我一步一步用图解，根因分析，解决办法，带你透彻分析解决，用最小的代码换取最好的配置效果。

之后，kafka 会告诉你一个用于连接meta data 的 ip 与 port，其实就是告诉你，你想和我通信要数据，我已经把ip port 发给你了，你后面就用它和我联系吧。理论上是可行的，但是很不幸，因为可能没有做地址映射，虽然在同一网络中，我实践的结果还是不行。因为我没有使用 coker host 的模式创建网络，虽然理论上应该可以，但是实际测试我发现有问题，因为 host后，子网掩码与主机子网掩码 位数不统一，一个是 24，一个是16，导致最后肯定会失败。结合我上面讲的，你应该很清楚是为什么了。

你需要先下载 zookeeper，已支持Kafka 的集群功能，虽然你可能不会用到集群，但是Kafka 要能正常运作，离不开zookeeper的支撑。--link zookeeper:zookeeper: 连接到名为“zookeeper”的另一个Docker容器，并且在当前的容器中可以通过zookeeper这个别名来访问它。这个地方注意下，我们首先要保证 一个 zookeeper 名字的docker 是启动的，在上面，我已经启动了。其实最重要的也就是 broker kafka 的ip ，por，topic

milvus hybrid search 确实效果还不错，但是有的场景，比如我们在分布式系统中由于需要较高的query 准确率，我们将TSO 相关的参数包括 guarantee_time, graceful_time 等设置比较长，而且 data consistency 有可能不是 Strong，nprobs 有可能也比较大，又比如说 ef 设置比较大，HNSW或者说是 ANN search 算法本身可能也比较耗时，整体来说，search 整体可能较慢。弄懂了这几个地方的处理，理论上源码精髓你就理解了。

RRF（Ranked Retrieval Fusion，排序检索融合），他实际上侧重的是最后搜索结果的排名。他的计算公式为：𝑁 代表不同召回路的数量，rank𝑖(𝑑) 是第 𝑖 个检索器对文档 𝑑 的排名位置，𝑘 是一个平滑参数，通常取 60。这里这个公式看不懂没关系，带入这个例子你就明白了。

这种漂移本质上和改动权重的效果是类似的，换句话说，因为相似度可能的不统一计算，会使得即使权重weights 分配准确，但最后得到的结果可能不符合预期。如果你能指明你要query 的是哪个partition当然是最好的，因为那样会使得search的scope 比较小，但是不知道也没关系，这个是optional的。output_fileds 就是查询后需要返回的哪几个字段，比如在上一篇文章实现的代码中，我们最终是需要返回 image 的path，供显示。通常这是在对返回query 效率有严格限制的条件下使用。

图片-文字交互式搜索应用非常广泛，实际上在本专栏前面的一篇文章中已经给出了一个代码的实现及思路。这种方式在文本图片搜索中有着广泛应用，它的本意是将图片与文本通过不同模型训练后，投射到相同维度的向量空间，然后将已配对的图片文本描述与图片二进制数据所形成的相同维度的向量，计算二者的相似度，使其他们的相似度尽可能的高。同时那些没有配对的图片文本描述与图片数据，其计算出的相似度尽可能偏低。这也是CLIP的根本逻辑所在。你如果还不是很明白，可以参看本专栏上一篇文章。

MinIO主要用于存储Milvus中的实际数据，特别是向量数据和索引文件。MinIO提供了可扩展的分布式对象存储解决方案，能够高效地处理大规模数据存储需求，确保数据的安全性和可靠性。看下面示例你会更加清楚。而rdb_data 更侧重于与milvus 内部之间的整合，这种整合是milvus 与 minio 之间的纽带，他更偏重milvus 的内部逻辑处理。看下示例你会更清楚。

通过这节加上前面的 local RAG 搭建，你完全可以自己实现一个local RAG 模型，而不借助任何外围组件，这样的实现对你加深RAG实现的全过程有直观重要的作用。还是那句话，真正的强者不能只是浮于表面，要知其然更要知其所以然。如果想要实现分布式的vector db 存储与query，那又回到了那个问题，你需要在query 正确率，效率，数据一致性之间做权衡。并且使用类似分布式数据，元数据管理工具，cache 策略等诸多手段进行维护。

另一个问题是，我们希望通过图片的搜索，能够反过来得到与之相关的或者直接能帮助我们求解的所有相关图片及对应的经验操作。当然如果你采用的是第一种思路，那没有问题，可以完成图搜图的过程，他的原理我在之前文章讲过了，就是训练 CLIP 模型得出的，将文本与图片信息放在同维度并通过训练使得配对文本与图片的similarity小，不配对的similarity大。实际上你一额可以将图搜图的过程变相的理解为：图经过反CLIP，得到他的文本信息，再通过文本信息搜索相关图片，也是可以的。本项目为保守起见，我用的是第一种思路。

MinIO是一个开源的对象存储服务器，提供了高度可扩展、高性能的存储解决方案，用于存放非结构化的数据，如图片、视频、日志文件等。兼容性：MinIO完全兼容Amazon S3 API，这意味着它可以无缝对接现有的S3生态系统工具、库和应用程序，无需修改代码即可迁移至MinIO或在两者之间切换。设计理念：以极简主义为设计理念，MinIO易于安装和配置，适合各种规模的部署，从开发环境到生产集群。

在文本处理任务中，这通常用于截断过长的输入序列，以确保它们适合模型的输入要求。这里设置为77，意味着任何超过77个token的序列都将被截断。指定了一个预定义的数据集时，这个参数用于进一步指定该数据集的配置（如版本、特定子集等）。: 这两个参数通常用于图像预处理，特别是在处理图像-文本任务（如图像描述生成）时。注意这里我使用的 hf-mirror，直接访问 hf 你懂的，访问不上。: 这是一个字符串，用于指定要加载的预定义数据集的名称。已经明确指定了文件的完整路径，则此参数通常不需要设置（或设置为。

etcd是一个高可用的分布式键值存储系统，它使用Go语言编写，并通过Raft一致性算法确保数据的分布式一致性。在etcd中，数据以键值对（Key-Value Pair）的形式存储，其中Key是唯一的标识符，而Value是与该Key相关联的数据。

首先解释下 hyper-v 是什么。Hyper-V是Microsoft提供的一种硬件虚拟化产品，它是基于虚拟机监控程序（hypervisor）的虚拟化技术。适用于 Linux 的 Windows 子系统 (WSL) 是 Windows 的一项功能，可用于在 Windows 计算机上运行 Linux 环境，而无需单独的虚拟机或双引导。WSL 旨在为希望同时使用 Windows 和 Linux 的开发人员提供无缝高效的体验。安装 Linux 发行版时，WSL 2 是默认发行版类型。

向量相似性搜索过程中，Milvus 使用了属性过滤条件（expr）来扫描每个数据段（segment），并将过滤结果（bitset，一种位集合，用于高效表示哪些元素满足条件）与查询向量（data）一起应用于相似性搜索中。这种方式可以极大地提高搜索效率，因为它允许Milvus在执行耗时的相似性计算之前，先通过简单的属性过滤快速排除掉大量不满足条件的数据点。

定义：Binary embeddings是指将原始数据（如文本、图像等）通过某种算法转换成固定长度的二进制向量（即只包含0和1的向量）的过程。特点高效存储：二进制向量比浮点数向量占用更少的存储空间，有利于大规模数据的存储和处理。快速计算：二进制向量的计算（如汉明距离计算）通常比浮点数向量的计算更快，有利于提升算法的效率。简化模型：二进制嵌入可以简化机器学习模型的复杂度，使得模型更加易于理解和实现。Sparse embeddings是指向量中大部分元素为零，只有少数元素非零的嵌入表示。

作为向量数据库的重要核心概念，引入与适用场景匹配的相似度，在search 或 query 时至关重要。在前面讲述 Chroma 的相似度计算时，已经说清楚了 Cosine，IP, l2 三种相似度计算的不用及适用场景。Milvus 在相似度的匹配中，也包含了这些核心概念，但应该说 Milvus 在这方面考虑得更加充分一些， 下面看下Milvus 在这方面的使用。

Milvus 在设计上突出了分布式的设计，虽然Chroma 也支持分布式的store 与 query。但是相对Milvus来说，不算非常突出。正因为Milvus 在设计上对分布式store 与 query 非常重视，所以引入了TSO机制。也就是timestamp oracle mechanism。

这很好理解，因为在多节点的case 下，你需要同步完所有节点的数据，以确保 insert，delete或者 update 对所有partition的所有 segment都生效了，还不理解collection，partition以及 segment，field的看下上面的文章，这里不再熬述。然而，在许多情况下，一定程度的数据不可见性或陈旧性对整体召回率（即系统识别相关项目以进行推荐的能力）的影响很小，但可以显著提高推荐系统的性能，因为它通过不等待所有数据更新在系统中传播来更快地提供推荐。

上一篇其实已经说过 standalone 模式，其实集群模式大同小异，只是在不同机子间使用Kafka或者其他消息中间件保证数据及逻辑的一致性。Log Broker，如Pulsar这样的系统，是专门设计来处理和管理日志数据的中间件。它主要关注于最近发生的变更操作的日志记录，提供日志的流式处理、发布（publish）和订阅（subscribe）服务。

今天开始写下Milvus，为了方便，我直接使用的是 milvus-lite 版本，default 情况下，你可能不知道他到底将 db 存储到什么位置了。启动 default-server，看下Milvus 的start及存储逻辑。

通过前面几节的介绍，你应该对Chroma的运作原理有相当透彻的理解。Chroma的设计正如之前描述的：Chroma提供的工具：存储文档数据和它们的元数据：store embeddings and their metadata嵌入：embed documents and queries搜索： search embeddingsChroma在设计上优先考虑：足够简单并且提升开发者效率：simplicity and developer productivity。

Chroma query 底层查询的 query 思想是相同的，甚至在vector db 的世界中，都大同小异。如果你有看前面写的应该比较清楚query的运作原理，说直白就是在memory或是disk中通过暴力查询比较与HNSW算法（NSW算法的变种，分层可导航小世界）进行分析得到。其中向量比较的几种方式，如果你看了前面写的应该也比较清楚，就是cosine，l2，ip 几种比较方式。这是底层运作的基本思想。但是站在应用层的角度，query可以有所不同。

在chroma vector db的世界中，除了对query 的理解，另外就是需要深入理解 chroma的运行模式，chroma运行时，提供了 local模式，server-client 模式，这些在应用中固然重要，但从实现原理上说，其实就是通过http 服务，在固定端口如11344上请求数据。但是在这之前，需要深入了解并理解 collection以及chroma 是如何存储及获取他们的。

揭开 Chroma query 的实现内幕，如果你之前没有自己看过，读完后，你的内功将得到增强。做到以不变应万变，力求万事成竹于胸。 Chroma query 读完后，你将对 vector db 的 query 逻辑有深刻的认识。世间万物本质大都大同小异，你或许有一种 独上高楼，望尽天涯路 的感觉

说直白点，可以举个例子，假设你是一个学生，我们需要定义一个M维向量来表示你对所有学科知识的掌握度，假设这3维向量分别是[English, Math, Physical],一个小学生的3维向量可能是[0.13, 0.16, 0.05], 一个大学生他的3维向量可能是[0.63, 0.84, 0.45]， 虽然在绝对值的投影上，他们差别很大，毕竟大学生掌握的知识比小学生多很多。它基于余弦相似度的概念，后者计算两个向量之间的夹角的余弦值，用于度量两个向量在方向上的相似度。因为我们看的是方向，不是绝对值权重。

在这两者结合的过程中，你要知道一件事，那就是LLM大模型必须知道你所提出的问题，在什么时候需要 LLM来回答， 什么时候需要 RAG 来回答，才是比较好的结果，prompt 起着至关重要的作用。一方面，RAG的专家知识库上因为加入了LLM，而使得RAG对应更自然，不再是生硬的回答，借助LLM，可以帮助RAG的回答润色。我们可以看到我们自己定义了专业的函数，这就相当于是 RAG，他的 "description": "当你想知道现在的时间时非常有用。" "一个小时后几点" "北京天气如何？

其实RAG本质上可以脱离LLM，在最早的时候，其实你很容易想到他的解决方案就是create 一个 database，create 几张table，最简单 create 一个table，然后最简单的table 就是 id，question，answer，三列。其实，如果你的知识库非常小，这么做，是可行的。如果我输入的问题是 ‘创建数据库索引’，你的专业知识库可能会很快检索到他，检索的过程其实就是 RAG 中的 retrieve，但如果我的问题换了，变成：‘如何提高数据库查询性能？

其实LLM结合RAG的方式可以有很多种，但是原理都是上一节介绍的，其实本质上就是要LLM知道，哪一类问题‘我’的回答是满足提问者要求的，哪一类问题‘我’可能回答的没有RAG好，‘我’可以借助‘RAG’，并将答案修饰形成提问者需要的风格进行予以转述，并回答。下面直接上 python 代码完整实现本地的RAG+LLM，并解释其实现。