背景
在chroma vector db的世界中，除了对query 的理解，另外就是需要深入理解 chroma的运行模式，chroma运行时，提供了 local模式，server-client 模式，这些在应用中固然重要，但从实现原理上说，其实就是通过http 服务，在固定端口如11344上请求数据。但是在这之前，需要深入了解并理解 collection以及chroma 是如何存储及获取他们的。这里的获取，我说的不是你在应用上调用 query 的主逻辑，当然，如果你读完了上一篇RAG与LLM原理及实践（5），你应该知道其实 query 包含了我这里说的 获取逻辑。只是在query主逻辑中，我一笔带过，根据collection_id, 如果cache中有，首先从cache加载，没有的话，从disk load。今天想把collection 与 chroma的物理存储结构 这两件事讲清楚。
collection 集合的目的
collection 是什么？为什么要用集合？实际上我们在关系型数据库中，基本是 db-table-column构成的关系型数据库。根据使用场景，我们可以很容易得看到，关系型数据库顾名思义，就是为定义各种不同错综复杂的关系应运而生的，在追求数据完整存储同时，从时间检索与消耗空间进行综合衡量，来完成数据库构建。正因为我们想表达大千世界中不同事物的各种不同关系，我们需要定义并记录不同事物的属性及通过table范式设计，primary key， foreign key 等关键字段，通过 trigger，transaction等手段描述表间关系与事务运作的行为。但作为在LLM中广泛应用的vector db，其场景是不一样的，table 对vector db 而言，不是不重要，但他应该是向量数据库设计者应该思考的问题，而不是使用者该去梳理的关系。使用场景很大程度上决定了设计，当然这不是唯一的决定性因素，但是你不得不承认，他起着举足轻重的作用。这个系列主要是focus 在RAG，我还是以RAG为例，词句嵌入后的N维向量作为存储在 vector db 中的一个主打功能之一，当然还有别的应用，其目的就是存储vector，可以有文本，图片，URL，当然未来可能还有视频，尽管现在chroma 并没有支持video标签，但使用url可以变相支持这一功能。作为使用者，或许只关心两件事：1）我的知识内容是否存入到vector db中 2）我是否能高效的查出我需要知道的相关内容。从使用场景出发，决定user并不关心你是用什么结构来存储数据。正因为这样，chroma将RAG中的知识，可能来自txt, pdf，word，ppt，URL，picture......需要一个稳定的存储，可能是按章节也可能是按照其他区分。所以 colle
标签：RAG,存储,Chroma,db,collection,vector,chroma From： https://blog.csdn.net/talentyiyy/article/details/140078134