Chat with Milvus #8 回顾: Milvus竞品&开源项目的常见商业模式
Chat with Milvus #8
| 部分Q&A文字实录
User A：
第一次看到你们这个项目，想要了解一下。
顾老师 @ Milvus：
好，没有关系，这不需要准备，我们也想了解一下，就是说你是希望把Milvus这样的一个向量搜索引擎应用到什么样子的一个AI的场景当中？
User A：
我觉得像视频搜索还有语音处理这方面对我现在的项目应该来讲是有用处的，所以我想了解一下。
顾老师 @ Milvus：
您这边的视频处理的话，一般您的视频当中也会提取一些关键帧，然后来做这个搜索是吗？
User A：
比如说*的项目，搜索视频的应用。
顾老师 @ Milvus：
明白了，我们现在在Milvus的项目下，它有一个Bootcamp就是在线教程的repo，在那个repo里面我们之前是有以图搜图的一个案例的，一套源码在那里边。当然它可能比较简单，它是给大家一个整体的概念说这个东西怎么去帮助大家实现这种以图搜图的某一个场景。当然因为以图搜索的场景其实很多，我们在那个里面集成的 VGG模型只是一种场景，这是一种比较通用的场景。
我们马上还会放上一个以图搜视频的一个demo，当然 demo当中因为我们比较难拿到那些视频数据，所以我们拿的是Tumblr上面下载的，大概是有10多万个gif，也是别人整理的一个公开的数据集。然后 gif 一般来说是三秒左右，然后我们就以那些gif作为一个样本，然后每一秒去抽帧，然后通过图片图像去搜索比较类似的那些视频，整个效果其实也还蛮有意思的。
这部分我们会稍后放到我们的网站上给大家去做一个分享。当然因为我们受限于自己能拿到的数据比较有限，可能不会像这种真实的大型的视频这种场景下（的效果），这只能说是给大家做一个参考。因为我们这些gif的话直接拿过来就可以抽帧，但我相信在你们实际生产的这种视频的场景下，你还是会先对视频做一些编解码的一些操作的是吧？
User A：
应该是。我想问一下，我们这像股票市场或期货市场有没有应用场景？
顾老师 @ Milvus：
目前为止可能对于金融市场的这些行情的数据，很多都还是处于这种自回归的模型去做分析。就是说比如说我要分析，比如说上证50指数的话，我只是拿上证50指数自己和自己做一个自回归，可能最多会引入一些其他的这种成交量、成交金额这些参数做一些分析，但是我觉得现在的金融市场的分析倒还没有说能够我分析这一段，比如说我觉得说今天这一个象征50指数的走势的曲线去搜它历史当中有哪一天和它很像，好像目前都还没有到达这个程度。
因为这个市场数据大家经常处理的时候，就一天就变成了一个类似于k线，它只有一个开始点，一个开盘价、一个收盘价、一个最高价、一个最低价，所以它其实忽略了当中的整个的变化的过程。然后那些非常短期的高频的交易，它可能更多的就是** （order book）上的那些东西，但其实要求的速度会非常的快，他就不会去做那些计算量特别大的东西，所以其实在目前来讲，其实我们也是非常想把我们这套东西能够在金融当中去找一些场景，但是在金融分析领域，其实我们目前还没能找到一个合适的场景，确实是我们一个在努力的方向。
User A：
我觉得经营者重要的数据，你能拿到10年20年前，二十几年的数据我放在一起分析，更有意义。当前两天给你一个两个礼拜，意义不大。
顾老师 @ Milvus：
是的，其实市场上确实有很多人在卖数据的，当然其实这数据的力度其实和你分析的需求可能有的时候不是那么能匹配的，有些人可能是需要半秒级的数据，需要take数据，但是其实很多数据服务商他可能卖到分钟级就完了。所以其实当中确实是存在很大的一个差异的。
User B：
我在用Milvus的时候遇到一个问题，我是做那种问答检索的，我在去Milvus做匹配的时候，相似排序跟我用余弦相似度这种计算的结果差很多。
顾老师 @ Milvus：
你的意思是说，你自己硬算了一套余弦相似度的结果，对吗？
User B：
对。
顾老师 @ Milvus：
然后你用索引的时候用的是IP 内积对吧。
User B：
用的是NSG。
顾老师 @ Milvus：
其实我们也是有一个问题，就是NSG这一块的话，是NSG的内机你觉得它的准确度不对是吗？行，我们可以去看一下，如果你有数据可以有共享的数据给我们的话，我们可以去研究一下这部分的问题。
但是我有一个问题就是，因为本身NSG图类的索引的话，它构建的速度和它内存的占用相对来说都会高一点。我们也是比较想了解，就是说在基于什么样的考虑你选择使用NSG这样的索引。
User B：
我也是在网上看资料。像这种检索可能更适合用 NSG。
顾老师 @ Milvus：
明白了，所以就看你问答系统，你的语料是不是需要经常的去更新的。如果你对更新比较频繁的话，这种IVF类的索引，它对于更新即使有数据进来，然后及时建索引，它会更友好一点。因为它本身的数据量大了之后，它的内存空间占用会相对小一点，就是用 ivfsq8这种压缩型的索引的话，它的内存占用会少。然后新进来的数据它构建索引的速度也会快一点，而且如果是你使用GPU的硬件的话，建索引的速度就会更快。
因为我们的算法工程师之前在群里面回答过大家，就是说 NSG 它构建索引的过程当中，就是说建索引完整分成了两个阶段，一个是先算一个完整的k，然后再去在 KNN的结果的基础上去建图。所以第1阶段KNN的构建是可以用GPU来加速的，但是第二阶段你在knn的基础上去建，它是没有办法通过GPU来加速的，所以就综合起来来讲的话， NSG相对慢一些。
User B：
速度，我感觉我可以我可以逐步考虑它。我主要是还想让它能匹配的准。
顾老师 @ Milvus：
你对于召回率是有要求是吧？好的，如果你觉得NSG的 IP的结果不如你的预期的话，你可以把你的测试的一些数据分享给我们，然后我们也去做一些测试。因为我们用了一些公开的数据直接做测试，但我不知道这个是你这边的数据可能不一样，也是有可能的。你可以GitHub 上开issue，然后提交那些东西给我们，我们可以去做一个验证的。
User B：
数据如果说提交的话，我是把我的原始语料...应该写什么？
顾老师 @ Milvus：
也不用原始语料，你可以只发向量给我们。这是因为原始语料可能也会重新确认一下。
User B：
我看现在应该是没有，咱们应该是没有导出功能。
顾老师 @ Milvus：
对，是的。你可以算一遍，取部分吧，是因为你知道某一个查询 top 10，比如说这某一个查询top 10现在是什么，然后预期的应该是什么？我觉得你发那二三十个给我们，我们应该也能够有初步的结果，我想。导出的功能的话，我们可以对我明天都想一下怎么去把这个数据提供出来比较好。
所以您这边的问答系统是一种类似于客服机器人这种这种场景？
User B：
对。
顾老师 @ Milvus：
好的，其实在我们的网站上也有一个示例，就是一个金融行业的一个问答机器人demo。
User B：
我看到了。
顾老师 @ Milvus：
所以，您觉得这种样式的效果如何？因为我们相对来说用的是一个比较通用的Bert模型，没有太多的二次训练的、加工的东西附加上去。
User B：
我们反正我们之前也用过Bert，用Bert形成的向量，但是后来发现向量还是有点问题，后来就换了。反正我们效果是能好一点的，但是发现它跟余弦计算出来的，效果还是差点。我现在就不知道是什么样的一个问题，我们那时候还在研究。
顾老师 @ Milvus：
好，就从这一部分的话，提供向量我们应该就能够做一个验证了。
User C：
我们这边是安防业的一些数据，有一些人脸特征，还有人员、机动车这种这种提取的特征的比对。
顾老师 @ Milvus：
明白，这部分是我们相对来说也是用户比较多的一个场景，因为这部分的场景下，其实它产生的图片和视频都很多，所以大家都用向量搜索的技术比较多一点。
User C：
而且这样的场景的数据实时的，它就相当于会实时插入很多向量进来。
顾老师 @ Milvus：
对，他会追加不同的不断的去追加写入一些新的数据文件，然后形成新的向量。然后它是一个持续不断的过程。
User C：
但是在这种如果比对的话，相对还有一个时间段的选择。我好像如果单独用milvus的话，好像不方便去做。我想搜近半个小时或者近一个小时的，或者昨天的某一个小时段，这样的就是反馈的结果。
顾老师 @ Milvus：
这个地方其实是相当于说需要结合一些标签，或者说这种结构化的属性，就是时间做一个结构化的数据进行检索。目前确实我们没有把向量检索和结构化的检索做的特别的紧密，但是其实我们也提供了一些数据，分片上可以附加一些标签属性，比如说日期可以是一个标签属性，然后你也可以把日期结合到时间去做一个标签属性，然后去选择日期，加时间段之后在那个里面去进行一个向量检索，也是可以做的，但是当中就会有一些问题就是说它是一个权衡，必须做一个权衡。
当你把数据按照时间段分的比较小的片段的之后，你每个时间段当中的数据是不是足够的多。因为如果说单照时间段分完片之后，变成说每一个时间段里的数据都不是那么多的话，那么相当于变相就是说同样大小的数据，你有更多的文件了。那么在做一个整体的搜索的时候，那么，更多的文件就代表更多的IO，还有更多的这种 quantization的计算的开销。那么他如果说你要搜索更长时间段的话，肯定是会有这样一个比较明显的系统的开销，如果说您能把数据加聚拢形成一些大的文件，那么这些IO的开销也好，这些量化的开销也好，都会都会相对小一点。
所以其实当然也有很多另一些方法可以去改善这个问题。你可以因为你导入到Milvus当中，它会给你向量ID，你可以把这ID再存在比如说一个postgres这样的数据库里面，每个ID你可以附加上它的时间戳，这样子的话就是可以一定程度上的去缓解这个问题。你比如说Top1000，查完之后再过滤一下属性，然后选出那个时间段的东西，也是可以这样去实现的。
User C：
这个方案我也想过，我插到Milvus里面的那个标签，假如说按天或者按两天，假如说我们用户假如说是说昨天一个小时，我用这边向量比对，我们就相当于直接取一个一天的数据全给它比出来，然后我再通过数据库那边把时间戳对应的一个小时去来给它过滤一遍，就取哪个时间的。通过N的数据给他返回，但是我感觉这样方法好像不太充分，也不太好。
顾老师 @ Milvus：
其实关键还是看你数据量。你有多少，就是说如果说数据量特别大，就是你汇总进来的向量每个小时都有很多的话，其实你每个小时新生成一个小小的分片，我觉得也是可以的。因为它毕竟是一个，它量足够的情况下，其实它的文件也比较大。其实还是他的开销会控制在比较小的范围里面。而且和你的搜索的场景也有关系，如果说在你的场景当中，你的用户大量的都是说我要指定一个时间段的搜索，他不太会说做一个搜索三天内所有的东西的。操作的话，其实分区分小一点的数据片影响到也不大，因为你永远都是搜索那些小的时间片上的东西，不会搜索整体的。那么文件过多带来的这种系统性的开销，就对你来说不会那么的明显了。
User C：
但是如果就相当于这种功能开发的用户的话，其实就不太好控制了。有些用户可能就习惯性搜这一天，或者近半天，有些用户可能发现他想看人的就相当于更大时间段范围的一个轨迹的话，那一点他也可能会选择7天，甚至更长一点，这个都有可能。
顾老师 @ Milvus：
对是。是，所以目前可能还是需要这种外挂的方式去实现这样的结合，我们也是在把结构化的属性结合到向量，在做融合搜索的这个过程当中，我们也在做研发的过程当中，目前还是在设计阶段，但以后的话我们是会允许用户同时指定向量的搜索和标签的搜索，那么现在如果你向量的有一个时间属性的话，我们可以先根据时间属性筛选一下，然后再去做向量的那部分的计算。
User C：
我想问一下你们后面会做成这种，就相当于你后面还是会支持结构化的信息，直接为自己做一个数据库，迁到你们的系统里面吗？
顾老师 @ Milvus：
它这个可能不是数据库了，就是说它是一个把结构化的信息和向量信息都放在一个数据文件当中，我们去支持结构化的查询的部分，也会是一个有限的支持。他不可能说我会支持一个drawing，这样的操作肯定是不可能的。那么如果只是单纯的过滤的话，那么结构化属性放在向量文件，一起就是做一个数据文件是放在一起的话，应该还是可以去实现的。
User C：
相当于你们就不会往结构化信息查询这个方向去做，是吧？
假如说我想直接通过数据库的语言，就是搜索某个时间段里面的，比方说都是男性的，这种数据反回不会去做的，是吧？就相当于结构化信息的检索会不会去做？
顾老师 @ Milvus：
但是你这个产品没有向量，就只是结构化的东西是吗？因为这种程度应该也其实没太大区别，应该也是能够支持到的。但是查询我们应该不会提供一个SQL类的这种接口，其实可能更多的还是像我们现在的这种Python的、Java的SDK调用型的、API型的这种这种查询的支持。
User C：
反正你们跟那种传统的标准数据库还是有差别的，是吧？就处理方法。
顾老师 @ Milvus：
对，是的，我们肯定不能给你做一个过滤，不是不能做一个drawing这种类型的操作，我们很多你可以认为是单表的属性过滤这样子的一种模式。你用这种标签，现在用这种数据分配的标签去结合那个的话，可以一定程度的缓解矛盾。
User C：
肯定是有方法解决，但是就比较绕口。其实我之前在接触，我会想你们会不会像发展成一个分析型数据库，发展成一个大、全的这么一个系统。
顾老师 @ Milvus：
它终归是会有一个边界在那里的，包括我们哪怕支持向量的结构化标签属性放在里面，我也不太可能给你无限制多的属性的数量，我们也会去限制一下属性的数量。通常来讲一个向量，比如说是512维的话，然后又用了一个压缩的话，512维下来就是512个字节。相对来说加一些小小的属性的话，可能加一个这种一个浮点的一个字符串的，可能也就加了十几二十个字符的特别的额外的高度。但是如果说我也不可能知道说你又加了100个属性在那里面，或者加了1000个属性，这一下子的话，整个IO的情况就完全变了。所以现场终究会是他擅长的领域的原因。不一样的。
User C：
还有一个Milvus这边可能也不太好实现，因为这边其实还是假设一个512维向量，那他作为一个整体来说就是512维向量它的一个群体去比对。然后其实现在有很多深度学习方面，它其实是一块一块的，就相当于我一个512维，我讲说给他分了10片，但是每一片又不太一样，但是我去比的话，每一片假如说某一片是没有的，都是000。我一个512，300，其实我去比的时候相当于是一个是10片，我重新说一下，某一512维特征，然后某一个假如说它分成10片，有一片假如说是变成一条向量就是第0片是缺失的，然后我只能比后面的9片。另外一个就是第1片是缺失的，我就会比0跟2后面的向量占比会有好像，你们这边有什么建议吗？
顾老师 @ Milvus：
这个说的话就是说从逻辑上来讲512维向量其实是由10个不同的部分组成的。是这个意思。他们每一个都是可以独立的。
其实是这样的，就是说我们以后会把整个向量的模型做成一种实体的模型，就是说实体它可以带有10个不同维度的向量属性，那么查询的时候呢你就可以输入一些不同，比如说我要查属性1、2、3这三个向量，那么根据这三个向量之间，它们之间权重是什么样给出的最终的答案。我们是想把它做成这样的一种多维度的模型，那么在他每一片...
User C：
每一片给它一个权重，然后最终输出的一个是比对的结果还是一个整体。
顾老师 @ Milvus：
对，是的，这个是我们未来想要把它做做成的一个功能。目前的话，如果你要做的时候...
User C：
有没有比如说是曲线，曲线的实现方式有没有？
顾老师 @ Milvus：
你可能就得把这512维的向量，比如说你就建10个向量表，512个就过来，你拆分了之后把它插入到这10个表里面，当然因为我们是可以设定向量ID的，所以你可以有一个统一的ID，然后设定在不同的时间表里面。你查的话，你就相当于去要分别的查这多个表，然后再去在自己的应用层再去做一次融合，根据这些未来的结果去做结果的融合。
User C：
我大致懂你的意思，就相当于我是一条向量进来我存到10个表里，然后反正每次比对的时候我都去比，然后通过ID，然后再去做一个融合是吧？
顾老师 @ Milvus：
对是的。
User C：
如果 ID支持 string 类型的，你们能不能就是提前一点。
顾老师 @ Milvus：
对，这个也我们还在设计阶段，因为现在确实功能比较多一点，要做的功能比较多一点。String类型的确实不止一个用户提到过，所以我们也是在想这个事情。
User C：
我感觉string可能会比较通用一点。
顾老师 @ Milvus：
我们现在可能优先在做的是 ID的去重，因为现在的话像一般的这种算法都是你可以给个ID，但是如果你有重复的ID的话，其实是不会侦测重复ID去重复这件事情的，所以我们现在是先想把 I D去重这件事情给做好。
User C：
就是说我发现的就是ID相同，你说的去重是相同的ID是插不进去还是？
顾老师 @ Milvus：
对，想把给用户说。你这个ID已经有了，然后就不能重复插入了。
User C：
我发现了相同的ID是可以插进去的。
顾老师 @ Milvus：
对，因为现在基本对所有的这些算法都是不去重的，就直接一定要一样的就插进去。这样一个模式，我们确实是在考虑这个东西怎么去实现它。
User D：
我想问一下：因为Milvus的话，就相当于是把一些底层的FAISS，SPTAG这样的一些库，把它在上面做了一个集成嘛。因为我以前有个朋友，他在一加，他们也有这种以图搜图的，就在淘宝上拍一张照片，然后你自己拍一张照片，然后他可以搜你这些衣服类似的，像这种。就感觉Milvus的这些很多的应用场景的话，其实现在是也很普遍的。
外面很多的现在的这些公司，他们是用底层的这些lib在做，还是也用像Milvus这样的一些解决方案，或者说是Milvus到现在，他在国内或者国外的一个竞争对手有哪些？
顾老师 @ Milvus：
怎么讲呢？就是说因为像向量搜索ANNS算法库的话，最出名的大家都知道的就是Faiss，它其实也是17年开始开源的，然后它开源以后很多人是用Faiss的，包括像很多这种过去的一些安防的企业也好，或者说互联网购物的这种以图搜商品的场景下，包括自然语言处理的这种向量化的处理的技术手段的这种平台上面，过去很多都是直接使用一些Faiss的，然后他们可能自己封装了一些Faiss的这种分布式场景下的这种。就是因为Faiss文件它做了一个分布式这样的保存这样的一些增强的这种场景，这个是我们听到比较多的，那么像Milvus这样的这种更加集成化的向量数据处理的这种平台，我感觉是从去年开始大家集中在做这一块的东西。
其实就有点像一个数据库一样。虽然在索引层面会用比加速，但是它外围的东西其实还是有很多东西要去做。包括数据管理，是为了搭配这些不同的向量的搜索算法，怎么样去组织自己的数据管理的机制会更好，其实都是有很多折中和权衡是要去做的。所以这部分其实也是我们去一直在想怎么样去把这个东西做好，一个重要的部分。
然后要说Milvus的竞品的话，包括参与到这个线上去讨论当中。也有一些人也有提到过，他们可能在某一些公司内部，它没有做一些适配自己应用场景下的内部系统，也是有的，当然他们可能没有跟我们分享他们公司的名字或者他们一些技术的细节，但是有跟我们讲过一些他们的场景的细节，相对来说像Milvus这样比较通用化的东西，目前来讲并不太多。
我们也陆陆续续看到Github上有一些比如说马来西亚的团队有一个团队，日本有一个团队，都想做类似的东西，但是他们做的相对来说比我们更晚一点，所以成熟度上面的相对也比我们可能更加早期一点吧。
因为一个开源项目的话，其实第1年的发展，他的不同的阶段，完全是不一样的。像我们项目现在的状态，和我们不要说12个月以前，哪怕我们3个月以前，或是刚刚开源了没多久时候的，然后6个月以前刚刚开始拿去给我们的外部用户做推广的时候的状态，其实都是完全不一样的。
其实像国内的互联网公司的话，你可以看到像阿里的话，还有做一套叫Zsearch的东西。他那套东西的话，在之前的那些科技媒体上也经常在分享，也讲过他的一些实现细节，他是外挂在Elastic Search上面做的这套的东西，包括他也经常会推的阿里云，自己有他阿里可能就会至少有两套。我的理解一个是就和原来Elastic Search做的，另外一个是阿里云上的叫什么Analytics DB，他做了一些这种外挂向量的搜索的一些东西，但是他们那套东西应该从这些众多的技术分享文章来看的话，似乎都是从阿里达摩院的一个团队做出来的一套ANNS的算法库吧。
他的设计应该还是会更加的基于自己现有的一个场景去做的一个设计，然后因为它提供在阿里云上或者说提供在阿里内部去用的话，其实它的场景的话也是，因为像有很多场景他可能不会去云上，但是我不知道他们具体使用的用户有多少，但是从他们公布的技术文章当中分享出来的用户都还是以集团内部的用户为主。因为它毕竟它不是开源的项目，它是只有在阿里云上才可以使用到的。其实我们之前也做过一些评估，我觉得其实怎么讲，就和我们可能还是不太一样。
然后像之前京东也有开源了一个这向量搜索的一个项目，但是他们的项目怎么说，他可能更加专注在一个他们的场景，或者说更加专注在他的以图搜商品的场景下面。因为他们现在一直以来对于所有类型的支持比较...适合于电商的那种精度要求不是特别高的这种场景.因为它是支持一个IVFPQ类型的索引，因为IVF结合PQ其实就是一个本质还是一个IVF的索引，但是结合了PQ之后，他在inverted list的当中，他通过pq的方法去降维去进行进一步的压缩，那么它的内存占用就会更小。
IVFPQ 在Milvus也有这个索引， PQ的意义就在于说它可以把内存占用压缩的更小。但是由此带来的代价就是说它的精度是也会受到很大的影响。但是就是不同的场景吧，因为像电商的场景的话，它可能对于商品的图片精度要求不那么高，因为他可以在他的PQ的基础上，可以在IVFPQ的基础上做一些设置，那么通过这样的方式去努力的提高它最终的一个匹配度。当然 ranking的方式在不同的场景下，其实适用的情况是会不太一样的。
如果你是在一个需要精度要求非常高的这种智慧城市的场景下，其实你搜索的频次就不高，而且你做ranking的这种机会可能也不一定会太多。怎么讲呢？反正他们会有他们比较特定的一个领域和场景。
那么对于Milvus来讲，当然我们其实都是属于我们整个和那些真正成熟的像那些spark、mysql这种发展了10几20多年的项目来讲，我们还是一个项目成熟度早期的项目。我们的一个小小的优点，就是我们确实能接触到更多的不同场景的用户。从我们现在的这些社区用户当中，像这种智慧城市、电商也好，包括自然语言处理的推荐系统的等等，什么样的人都有。然后对于大家包括医药，这个领域当中，就他们不同的场景下面，想要使用的对于你的索引类型、相似度的标准都不一样。
因为我们接触到了更多的人，所以我们也接触到了更多的需求，也涉及到了大家更多的想法。所以就是我们可能在通用化层面上来讲，目前做的还算是比较可以的，至少大家用起来，都能够从某种程度上帮助到自己的不同的业务场景。我觉得对我们来说，也是觉得一个挺神奇的事情，因为最初我们可能大家对这个项目追踪看比较久的话，可能我们最初也只是用智慧城市的用户，然后慢慢的就开始有了互联网电商、推荐系统、短视频，医药行业等等，这些我们原来都没有想过的这种这种不同的场景和不同的用户，所以怎么说呢？一个项目要做到成熟，其实是需要花很多时间的，也是需要持续的努力和投入的。这个也是我们一直在努力的，也是我们想要和大家多进行线上交流的一个很重要的原因。希望大家能够把你们的需求和你们的疑问都带到我们这里，这样的话大家才能够碰撞出一些新的想法，把这个项目能够做得更好。所以我相信你肯定也留意过很多一些类似的项目吧？也没有很多，但是确实有一些类似的项目，目前。
User D：
我有一个疑问，就是说像刚才你也聊到了像阿里、京东他们，他们一方面是不开源，他们有就是说实力、资金的各个资源去做这样的一个事情，因为他可以服务他自己本身的一些商品，希望在这里。ZILLIZ 公司的话把Milvus 开源出来，他以后的话会随着越来越多的用户做的越来越好，以后他会在商业化这一块会去走增强的版本？会不会会有分支？
顾老师 @ Milvus：
是这样的就是说其实阿里也好，从京东也好，他们是和我们和Milvus去比较的话，他们都是两个其实挺好的参照物，就说阿里是不开源，但是只有就在云上可以提供给用户用，然后京东的其实它是开源的。但是说，因为一个大的公司，它可能会有很多的开源项目，或者说他的团队也有自己本职的工作，也有自己本职的KPI，做一个开源项目可能并不是他最核心的职责和目标。所以其实从推广上来讲，从社区的活跃度来讲，你都能看到有很显著的差异。
其实从Milvus这部分来讲的话，因为我们觉得说在相对来说新的领域当中，我们希望能够在向量搜索这个AI数据处理的平台上做到能够做到一个占用率最高的一个目标。因为开源项目你要实现最终的盈利的话，一定是你先要有一个巨大的用户的基础的。
然后的话其实很多用户其实他想用Milvus，但是他可能因为现在我们接触到的社区用户都是大家想实际部署这个东西，然后自己搭建系统。但其实还有更多的用户，他们其实他只想你给我一个API就好了，我把东西丢下来，然后我可以我再给我一个API，让我丢东西下来，再给我一个API，我能去搜索就好了。
其实这样的用户，他其实需要你提供的是云服务，就他是愿意去为这些东西去付费的，但是他也没有精力，或者说他没有兴趣去维持这一套技术架构的平台。所以像那些的话，其实都是一个开源的项目去实现盈利的一个很好的机会，但是它的前提一定是说如果你也提供了云服务，他也提供了一个云服务，他一定会愿意去选择知名度相对最高的、使用的人最多的这个选择，所以不管怎么样，现在都是需要去把Milvus这个项目的知名度也好，用户基础也好，这是我们核心的目标。
User D：
好了解，就是说后面其实比我还是会走SAAS 这一块对吧？从产品角度来说。
顾老师 @ Milvus：
对，但是这可能会是一个相对比较长期的过程。因为它其实牵涉到的因素还是比较多的，我们肯定是先要把目前自己的产品先做好，然后才能够慢慢的往那个方向去发展，因为那个方向的挑战和要求，其实和单纯研发一个软件来讲，还是会不一样的。还是会有更多的要求在里面的。
User C：
我能再问你一个问题吗？假如说实时数据比较多的话，然后我里面又选的是一个量化的索引，这里量化的过程肯定会有精度损失。
我想说的就是假如说同一条向量，然后建索引和不建索引，然后我再去比对，返回的相似度其实是不一样的。但是他们假设都是同一条向量，我经过量化之后返回的相似度的值和没有量化返回来相似度的值，可能是就不太一样，这里就存在一个问题。然后如果我每次搜索前都要去建索引的话，因为时间比较长，这样相当于去search的时候，可能响应时间上就会比较长。
顾老师 @ Milvus：
索引是建一次就可以了，不用重复建了。然后的话，因为IVFPQ它可能精度达不到很高，但是其实我们在智慧城市当中，很多用户都是用的IVFSQ8这样的索引。它的索引是一种不降维的压缩，相对来说，在减少内存的同时还是可以提高，还是能保持精度的。会有一些损失，但从目前的情况来看，都还是在可以接受的范围，他还是IVFSQ8还是能到100%的。你调整搜索范围的话，它还是能够达到100%的。
| 欢迎加入 Milvus 社区
github.com/milvus-io/milvus | 源码
milvus.io | 官网
milvusio.slack.com | Slack 社区
zhihu.com/org/zilliz-11/columns | 知乎
zilliz.blog.****.net | **** 博客