RAG与LLM原理及实践（8）--- Chroma 应用场景及限制

前言

通过前面几节的介绍，你应该对Chroma的运作原理有相当透彻的理解。Chroma的设计正如之前描述的：

Chroma提供的工具：

存储文档数据和它们的元数据：store embeddings and their metadata
嵌入：embed documents and queries
搜索： search embeddings
Chroma在设计上优先考虑：

足够简单并且提升开发者效率：simplicity and developer productivity
搜索之上再分析：analysis on top of search
追求快（性能）： it also happens to be very quick

它非常适合在属于自己的垂直LLM RAG库上运行。当你的应用主要集中在LLM领域，且要求最好能本地快速部署，又需要兼顾查询效率时，Chroma 绝对是你的local LLM RAG首选。但不得不说，任何事物都有他的限制。说直白点，还是应用场景。如果你的应用或存储信息维度超过了文本，元数据，url 这些内容，逐步向图片，甚至影音过渡时，Chroma 就显得有些力不从心。我会从代码逻辑及整体思路上给出分析。但熟悉Chroma 的朋友都知道，他有user 交互模块并不断update，毕竟Chroma vector DB 的API 接口适配了目前所有vector DB 共同遵循的接口，未来根据适用场景，包含client 模式，server模式，local 模式，同样会衍生出其他功能的版本。只是当下判断，如果你的应用聚焦在图片或是影音应用，Chroma不是很好的选择。

Chroma场景及限制

机制层

LLM处理的核心，query的语义相似度查询。你如果非常熟悉我前面的几篇文章，Chroma采用了暴力+HNSW 结合的方式，或者你说是KNN query 也对，进行query 分析。底层采用了 consine，l2，ip 丈量distance方式。

需要指出的是 cosine 方式并不适合做picture，甚至 audio，video 的相似度处理查询处理。提到检测相似度，你可能第一反应就是 cosine 比较，这本身没有问题，但问题是被比较的事物是否可以很好的被向量化，或者说在比较事物向量化的过程中，他们是否丢失了很多信息。LLM与audio ， video 的最大不同，前者在于语义相关，后者在于大量信息的存储相关。语义相关的问题，被高维向量表达后，依然能保持其语义的基本特征。虽然这种特征是面向计算机的，就像LLM中的 encoder，attention，decoder 一样。但你如果把audio，video用高维向量进行编码压缩，丢失的信息可能太多，这也是为什么LLM model 与 pictures，audio，video model 中使用的手段不同的原因。在LLM中你很少看到大量 CNN 卷积网络被使用，而在视频相关领域，为了捕获图片，视频等信息，需要多个 filter对甚至一张 picture进行轮番迭代，以求计算机能很好的把握住他的特征。比如相关的yolo 识别物体的训练，无论是v几版本，你可以看到神经网络路径都比较长，且经过多步卷积，池化等操作。所以这也就能说明为什么Chroma 可能在图像方面并不合适的原因。毕竟实现原理及思路限制了他的用途，当然你也可以反过来说，压根我Chroma 就不是为图而生的，我的目标在LLM领域。但另一个vector db， milvus 似乎支持了图片，甚至是audio，video，有时间我再写写他们。但是这里依旧是聚焦在 chroma 上。

但从另一个维度讲，你可能想到了另一个思路，如果说我的embedding后，内容足够好，也是可以的。确实，如果只是做图片比较，的确可以通过使用ResNet-50 等model 对图片进行编码。最后形成类似2048 维的 dim 存到Chroma中。这是另一种可能的解决思路。