5分鐘快速一覽Milvus v.0.9.0 新功能
Milvus 新版本 v0.9.0，只要 5 分鐘不到的時間就可以看完哦～
| Milvus Q&A 與文字實錄
Chat with Milvus #12 向量檢索線上問答
Attendee= 參會者
Attendee A：我現在只是屬於試用階段，還沒有經過一個比較完整的使用場景的考驗，所以現在主要就是說想學習一下，看看別人都是應用到什麼樣的場景。我們現在實際用的就是一個句子相似性的應用場景，只做了一個很小的測試，沒有遇到很明顯的問題。之前覺得檢索的準確率不是很高，但是有一個人建議說我做向量的歸一化，我還沒有做測試，所以還不知道結果，就是這麼一個情況。
顧老師@ Milvus：所以您那邊是一個自然語言處理的場景是吧？
Attendee A：對，第一步是自然語言處理，然後後面可能就是說會用句子來搜圖，然後圖搜句子的這樣的也會嘗試一下。
顧老師@ Milvus：句子來搜圖的話，您這邊圖片都是有標籤的嗎？
Attendee A：對，就是說就類似於那種表情圖。一開始會試一些表情圖。
顧老師@ Milvus：明白了，所以你們主要是現在還是在搜索，先幫助大家去搜索表情包是嗎？
Attendee A：對。
顧老師@ Milvus：然後給這些表情包打上一些文字的這種標籤，然後通過比如說用戶給個句子，然後互相提取語義，然後去做匹配的搜索，是這樣的一種效果是吧？
Attendee A：對。
顧老師@ Milvus：所以你們現在收集了多少個表情包呢？
Attendee A：這個就沒有，因爲只是做實驗的，驗證一下想法就行了，還沒有說很正式的來推進這個事情。
顧老師@ Milvus：你們是用什麼樣的模型去把句子或者說問答的自然語言轉換成向量的？
Attendee A：我們目前試過的最好的就是谷歌的 USE （Universal Sentence Encoder), 它比單獨的 BERT 都還要好一點。
顧老師@ Milvus：效果比 BERT 還要好一些。好的明白了，我們也學習到了，因爲我們原來之前的一個這個 QA 智能機器人，我們當中用的直接是用 BERT 的提取的句子的向量。感覺因爲我們數據集的關係，我們也是一個這種 GitHub 上找的數據集，然後銀行場景下的問答，然後試了一下就感覺還行，因爲沒有更多的數據可以去驗證，所以就感覺還是不錯，但如果有更特殊的數據的話，我想你說的 USE 可能會是會是一個更好的方式。所以你們大概這個想法最後會想去搜多少表情包呢？
Attendee A：表情包這一塊如果就是說從設想這個階段的話，會考慮的比較空泛一點，就比較大一點，說一開始是表情包，可能後面的有動作，現在做人體的動作識別其實也是比較準確的。然後還可以再加上一點動作，這樣就不斷的多嘗試一下，然後看看什麼樣的效果好。
顧老師@ Milvus：相當於就動作也是表情包的動作是嗎？
Attendee A：不是，就是動作的話，任何一個圖片裏面，然後他人就會有一個動作，比如說根據動作還可以判斷他的情緒什麼的。當然這就是說相當於是表情包的話，你就說你也可以通過句子來讀真實的人的照片，你比如說電影裏邊的截圖對吧？然後有的時間你搜到這一句話，電影的什麼出處，那麼就是說你同樣是根據動作，我再搜跟這個動作相似的結果這樣子就不是以圖搜圖，而是你搜到一個圖，然後把裏面的動作描述出來，然後搜到更多的類似的姿勢的東西。
顧老師@ Milvus：相當於有一個從圖片提取特徵，然後再走一些結構化的標籤的搜索這樣的一種過程是嗎？
Attendee A：對，就肯定要加一點結構化的東西在裏面。
顧老師@ Milvus：明白，所以其實對於特徵提取的豐富性還是要求比較高的，你們要不斷的增加一些新的東西，就是會要有新的模型，然後把所有的東西都再過一遍這樣。
Attendee A：對，因爲就是說覺得你用向量搜索就可以做很多事情了，我們現在說並沒有先把內容定下來，而是先把這種方式定下來，然後再試一下都在什麼內容上纔是有效果。
顧老師@ Milvus：好的，我覺得你們這個想法非常有趣。因爲我們有可能會有一些這種把這種 pipeline，就是一些模型推理的這種預處理的 pipeline 結合到向量搜索當中的一些打算，其實可以爲大家提供一些完整度更高的一些方案，因爲我們現在的 demo 的話相對比較簡單一點，就以圖搜圖的 demo 相對都是做的比較簡單一點，就是他們你說有關聯也有關聯，但是也沒有特別的這種完善的這種流程和機制。所以這方面我覺得以後大家都必須得去探討，我覺得這是一個挺有意思的東西。從非結構化數據搜非結構化數據，然後從非結構化數據去做結構化的數據，再搜非結構化數據，這些流程都是挺有意思的。
Attendee B：我是大概半個月以前接觸代碼庫的，我之前也是做開發的，但主要是 windows 平臺 .net 那些的，Linux 這些都不太會。看你們只能在 Linux上，就學了好多東西。然後後來發現是 CPU 那個就不行了，因爲我電腦是五六年以前的家裏的電腦。我先說一下我要做什麼東西吧，我是一個想參加一個創業公司，然後他們是做知識產權的，他們是給別人註冊商標的。
他們想做的事就是說提交過來一個圖片以後，他根據圖片的信息，還有一些文字的信息看他註冊成功率，所以圖片相似度這塊可以作爲一個參考點。所以我研究了一下這些技術，然後向量搜索這一塊我現在不太清楚，因爲我之前看還有一種方案是把向量存到 PostgreSQL 數據庫裏面，然後它實現向量的索引，但是我不知道它是怎麼實現的，效率的話不知跟你這個引擎相比是怎麼樣的。
然後我現在的情況就是我家裏機器不支持，今天我剛上來我就聽見你們又說現在可以了，有點懵逼，因爲我剛買了一個電腦，2萬多塊錢準備就買回來，然後再測試這樣的，實際上我還沒有開始測試，只是在詢問一下這些框架的東西。
顧老師@ Milvus：我覺得首先你買的電腦肯定不會浪費了，因爲現在的尤其是你牽涉到圖片的這些東西的話，其實 Milvus 只是一部分，因爲你現在的圖片那部分你還需要 GPU 去做推理什麼的。
Attendee B：GPU 的話其實我買了一個 2080TI，應該測試的話夠用了，然後內存的話是先買了個 32G 的。CPU 好像我聽說要求不是很高，所以就用了 i7-9700。硬盤的話就 m20 那種硬盤，我覺得應該可以。
顧老師@ Milvus：對。
Attendee B：所以就準備裝 Ubuntu 的系統，然後具體學一下，我現在真還沒有開始用你們系統，所以現在也不好提什麼問題，今天來看開會就進來看一下。
顧老師@ Milvus：好的，沒有問題，其實因爲怎麼講，因爲過去的電腦的話它確實 CUDA 的，因爲英偉達的顯卡的版本的升級，各種各樣事情其實都也挺麻煩的。所以如果你有一個稍微新一點的硬件的話，你去裝 CUDA 的驅動，你去裝那些 Tensorflow 什麼的，我覺得都會相對容易一些。尤其對你如果不是特別熟悉 Linux 的話，那方面肯定可以幫你減省很多時間。
商標搜索其實我們的用戶羣當中也有一些做企業大數據，做企業徵信的一些公司，他們也也在搞類似的東西，因爲確實大家都有個訴求，就是一個公司要想一個好名字，想一個商標真的是不容易的事情，所以這確實是能幫助到很多人的一個方式。
然後你剛纔說向量存 Postgres 裏面，確實之前有人寫了一些這種 PG 的插件去做這些向量搜索功能，但是怎麼講，因爲在向量這一塊的話，其實和 PG 這樣針對傳統的結構化數據的這種數據管理模式，它其實是挺不一樣的。其實爲 PG 去寫這樣一個插件，主要就是你能複用到 PG 的部分很有限，但是核心的向量計算的部分 PG 的框架也並幫不到太多，但當然還是取決於你的數據量有多少。因爲像中國的話，可能最多的那一家，我聽到蒐集到的用這種企業的商標數量可能是在千萬級的圖片。
Attendee B：對，現在有 3400 萬好像是。
顧老師@ Milvus：所以像 3400 萬這樣級別的話，你放在 PG 當中的插件去搞可能是會比較痛苦。
Attendee B：但是他有一個優點，他可以存其他的業務的字段。可能比這種你們這種引擎用起來可能稍微方便，但是我們不知道我還都沒試過，他們也是號稱什麼幾千萬上億的數據可以秒搜什麼的，我只是看一些網頁上的說明。
然後我這塊還有一個問題，現在我準備先試一下 VGG 的模型，但是不知道就說圖片向量生成這一塊應該怎麼去學，就是什麼類型的圖片適合一個什麼算法這種東西？
顧老師@ Milvus：
這是個很好的問題，基本上你需要花一些時間一個一個場景去學。因爲我感覺現在人工智能這個角度來講，機器視覺其實大的領域當中通用性的算法並不是那麼的多，因爲比如說你做人臉的提取人臉的，就有人臉那個算法，然後就對象識別的就有專門的對象識別的算法，然後 VGG 相對來說是一個通用性相對高一點的，但是如果你要特別的一個領域的話，它可能就不是那麼的突出。
Attendee B：我現在這方面也不是很在行，我想的是可能需要把這些圖片做一個分類，或者是把它自己先預處理一部分，他們都大概是輪廓什麼都給他弄出來，然後然後再套用現成這些算法，因爲自己寫那個算法好像也不是很現實。
顧老師@ Milvus：對，一般都是基於現有的模型這樣去調整。其實這部分的話確實會需要花一些時間去進行相應的研究的。
Attendee B：因爲現在我看阿里雲上有商標，還有各種不同行業使用的一些服務，但是這個數據量倒進去，它價格就太高了，所以只能自己想辦法弄。
顧老師@ Milvus：是的。
Attendee B：這塊你們也有了解過是吧？阿里雲上面有大數據的服務嘛。
顧老師@ Milvus：是的，我不知道你是哪一個服務的，因爲他現在各種服務也挺多的。
Attendee B：有比如說商品，像什麼商鋪的那些圖片搜索，還有也有商標這一類的。可能到時候就說我自己先做一個方案，然後在他那邊再試一下，然後比較一下看他們能做到什麼程度，然後儘量選一個比較好的方案。
顧老師@ Milvus：因爲他圖片搜索在阿里雲上各種，他那邊可能有不同的方案，所以你看到那個可能和我之前關注的可能不太一樣，所以我還真的沒概念說。
Attendee B：對他好像是好像是新出的，我現在打開看一下，它這個產品服務裏面有一個有一個圖相識別，就在大數據這一塊。 他們用的我不知道後臺是技術是什麼，但感覺你家的好像合作的大廠挺多的，應該挺靠譜的，我覺得。
顧老師@ Milvus：我們之前有關注過阿里雲上它有專門的人工智能方向的什麼圖像搜索。確實它價格可能也確實不是一個很小的數字，這也是真的。
Attendee B：他家是按你存入多少圖片的量作爲作爲一個收費的依據，然後就以圖搜圖。還有一個是國外的什麼引擎來着，好像也是就說多少圖片，然後按週期收費的這種服務。騰訊我也看了一下，好像他家每天只能導入 1 千個還是 1 萬個圖片，我算了一下要把我那圖片導進去的話要 70 多年，如果免費想導進去的話。他是不按照你最終導進去，它是限額每天導多少圖片這種。反正我覺得還是自己弄好一點，因爲他們服務實在是價格太高。
顧老師@ Milvus：我知道你說的模式就是他每天會有比如說 1000 張的免費額度，然後需要搞更多的圖片的話，是要買他的資源包之類的。我覺得雲廠商的服務肯定是有他們的優勢和好處的，當然確實他們的成本也是在那邊，門檻也是在那邊，這也是沒有辦法的事情。
Attendee B：因爲商標的庫現在還沒給我發過來，他們說是要企業的業務端什麼的，然後應該成功發過來以後我要看一下，就說如果他是分好類的，比如說每個類裏面，因爲他搜索的時候是按行業，不同的行業可能下面就沒有這麼大的量了，量比較小。所以說可能機器配置或者是庫的就是那些性能要求就會低一點，不需要直接從那麼多，就是幾千萬的向量裏面。所反正我現在跟你隨便聊，我現在沒有實際做過這個東西，大概瞭解一下。
顧老師@ Milvus：好的。等你開始之後，如果有什麼問題的話，都可以在羣裏問問。
Attendee B：好的，謝謝了，你們挺專業的，有什麼問題都知道。就是說如果你們現在圖片搜索是 VGG16 的話，他向量生成出來是多少維的？
顧老師@ Milvus：512
Attendee B：512 就是說我的 3000 萬圖片的話，如果都存在內存裏大概需要多大？
顧老師@ Milvus：因爲壓縮索引的話應該是一條就是 512 個字節，然後你再乘以 3000 萬，給你估算一下，應該是在 10 幾 G 內存的樣子。
Attendee B： 其實配置要求也不是很高。
顧老師@ Milvus：當然這個只是向量的部分，你可能還有推理的部分，這個是沒有算進去的。
Attendee B：推理是什麼意思？
顧老師@ Milvus：你要把圖片轉成向量，這部分當然不會花太多的內存，但是它會有會花一些 CPU 之類的。
Attendee B：我可以本地就是說把這些東西都處理好，然後比如說我上線的時候再把數據庫直接放出去，就不需要在線計算了，因爲它商標更新的頻率很低的，你大概幾個月才進一批數據。
顧老師@ Milvus：對是的。
Attendee B：對，還有一個想問的，搜索的時候，有一些業務的字段必須要再建一個庫，等它做出來以後有一個結果集，然後再用這個結果集跟庫進行對比，在篩選這樣？
顧老師@ Milvus：對是的，現在需要一些外掛 PG 這樣的方式去做一些後續的過濾。
Attendee B：我覺得你們要是搜索引擎可以實現，比如我導入數據的時候，給你提供一份一個結構的，比如說每一張圖片對應的一個業務數據，然後你可以查詢的時候根據這些字段篩選，這樣的話我感覺效率應該挺高，也比較有使用價值。
顧老師@ Milvus：對，我們會在未來版本當中加入這樣的支持。
Attendee B：那行吧，我現在也說不出什麼東西，以後有問題再交流。我其實這方面還真的是外行，機器學習什麼的，我以前其實只是看看，然後平時上班都用不上的，最近纔開始研究這個東西。
顧老師@ Milvus：好的，有問題都可以大家在一起討論。
Attendee C：我們現在實際上還是以一個向量檢索的中間件爲主，對吧？然後其實所有我們插入向量，包括搜索的時候都要求我們先要生成向量，然後才能做這樣的插入？
顧老師@ Milvus：對是的。
Attendee C：然後我想問的話，你們後面會不會內置一些針對不同領域的，就直接我只需要提供語料集，然後你可以自己去選擇，然後生成向量的這種方式？
顧老師@ Milvus：這個是把模型接進來，這個是可以做的，會考慮給大家做一個更容易使用的東西。因爲其實這部分的話，除非是做到一個雲服務的程度，如果是私有部署的話，其實對用戶來講的話，都是需要去關心這些推理的模型，模型怎麼去推理，然後怎麼插入向量等等。如果你是希望特別簡單去用這些東西的話，我可能到那天我們提供了一個雲服務，對你來說就會特別的簡單。
Attendee C：因爲是這樣，現在我本身的場景是做文本匹配的，就相當於這個拿去做召回了，然後實際上我是 query 生成的句向量，然句向量的話，我如果查的話，其實我本身自己是做了一套服務，是基於 annoy 的去做的搜索服務，然後我後來看見你們，所以就用了一下感覺還不錯，但是其實有個問題是這樣的，因爲一般拿 query 去做的話，其實我都是用詞向量去求平均的，這個時候我其實只能把就求平均之後的句向量放到咱們裏面，但是我在前置的一步的時候還是需要就每次 query 進來，我先要轉化成詞向量，然後直接這樣，這兩步是割裂開的。然後我也沒有想到什麼很統一的方案，因爲對詞向量的查找而言，我是一個精確解，然後對於句向量搜索而言，它是一個近似解。
顧老師@ Milvus：你的詞向量轉句向量是怎麼轉的來着？能不能再給我們詳細的描述一下？
Attendee C：就是我先拿出詞向量，然後簡單的根據句長去求一下平均。
顧老師@ Milvus：因爲我確實沒有做過這方面的東西，所以我可能需要問一些問題。你說這句話當中有 5 個詞，你這 5 個詞是怎麼平均成一個句向量的呢？
Attendee C：5 個詞的話實際上就是我先去詞相應的模型裏面拿到這 5 個詞對應的詞向量，然後把它相加起來，然後除以它的長度。
顧老師@ Milvus：長度就是 5 嘛。
Attendee C：對，但是他詞向量的維度可能是種256或者是128這種。
顧老師@ Milvus：我大概知道你想說的意思了。這個確實是可以考慮的一個東西，就是說我們有一個用戶在說做視頻去重的時候，其實比如說這 120 個向量的話，其實你就不需要去做 120 次的搜索，你可以把這 120 個向量融合成視頻，然後再用融合的向量去進行搜索，去判斷，去進行去重的判斷的依據。其實在這個過程當中就有點像你說的這種情況，必須要把多個向量融合成一個向量，然後再去做一個搜索。所以確實原來我們是沒有太多的考慮這方面的因素的，但是既然有兩個人都提到這個問題的話，我覺得我們就可以去研究一下，看看這是不是一個非常共同的需求，然後是不是可以把他做的一個更簡單，更讓大家無感的去融合這種向量，然後去進行搜索，確實這個也可以考慮去嘗試的一個方向。
Attendee C：Ok，然後這是一個點，另外一個點的話，其實我還想問一下，實際上我們的向量都是動態更新的，但是對於我們情況而言的話，我實際上創建一個分區是一個 collection，然後我在 collection 裏面創建我的 partition 或者說其他的東西。然後假設我現在有一個就是關於服務 A 的向量，然後我創建一個Collection A，但實際上在這一段時間內，我可能只是有一部分的增加或者刪除，然後可能在一週之內我向量的模型是不會變化的，但是一週之後我的向量更新了，然後又相當於我需要重新把這部分新的相關數據同步到 Milvus，舊的 collection 和我的新 collection，對於實際結果而言，它是一個新的 collection，但是由於我們不能創建同名的 collection，所以就需要我重新建一個 collection，然後在建完之後再把它覆蓋掉。我覺得這個過程看起來不是特別友好。
顧老師@ Milvus：我想一下，所以你們向量有多大？
Attendee C：我向量其實不大，我現在是百萬的數據集。因爲我們是 B2B 的對話系統，現在數據集都不是很大。
顧老師@ Milvus：我覺得也許可以做一些 partition，collection 裏面可以建 partition，我覺得也許是可以把 partition 的標識屬性作爲一個這個數據的版本號去對應到的模型的，我相信你的模型應該也有一個版本號，當你每次變的時候，你也會給他一個新版本，所以我覺得你可以把舊模型的版本號作爲 partition 的版本號放在裏面，這樣的話就比較容易去看說這是版本 12345 的模型改成的向量都放在 partition 12345 裏，後面你再有 abcd 的版本的模型，就放在 abcd 分區裏面，partition 裏面我覺得可能是一個可行的方式。
Attendee C：Ok，這裏就有一個問題，現在我模型更新了，但是實際上如果我不去手動 drop 的話，我在 collection A 裏面，我 partition A 可能沒有去刪除，但是我這裏有 B 了，我後面的相當於我模型越來越多，然後我的 partition 越來越多，我的 collection 越來越大，需要我手動去管理那些舊的 partition 對吧？
顧老師@ Milvus：對是的。
Attendee C：然後我原來的方案實際上是這樣的，我會相當於給我的索引建兩份，就是一個向量索引一，一個向量索引二，我第一次初始化的時候我只會初始化向量索引一，然後我搜的時候也是會去搜索向量索引一，但是每次我模型更新之後，我只會把新數據放到索引二里面，然後當我新的模型新的數據有了索引建完之後，我直接把 ab 互換一下，然後把這個清空，然後這樣的話其實就是完成了原子操作了，不需要再去做太多的手動管理，不知道這個對你們有沒有用。
顧老師@ Milvus：你這方式是一個比較常見的一個 A/B 的這種雙份的日誌也好，什麼也好的一種切換的思路，是比較常見的操作。確實在版本的上面，我們其實現在是沒有自動 drop 這種這種機制的，因爲確實數據的話，一般的數據庫裏也很難去做自動的 drop，因爲這個東西他比較難以判斷他不發展機制，所以我們只能是提供命令給用戶，然後你可以手動去觸發，其實對你來說會比較自由一點。我主要是想問一下您平時的檢索的併發度會大概是在什麼量級上？QPS 之類的這種？
Attendee C：QPS 大概在幾百左右，高峯的時候是 300 多。
顧老師@ Milvus：對於一個企業的獨立的這種場景的話，應該還算是比較高的吧。
Attendee C：對，相對來說比較高。就是高峯其實際上每個月統計下來可能峯值也就 100 多，他們只有在企業活動的時候會有這個量級。
顧老師@ Milvus：好的，您剛纔問的問題是什麼？
Attendee C：我們現在其實所有的數據存儲像這樣，它一個是向量索引會落盤，另外的是向量的元數據也會落盤。對吧？其實我有一個問題是這樣的，然後我們向量數據它實際上對某些企業或者某些產品它的變更比較頻繁。實際上我就想問一下你們當初設計的時候，爲什麼會考慮把它就落盤？
顧老師@ Milvus：這個也是考慮到後續再要去修改索引的這種便利性，用戶不需要再去重導。
Attendee C：但是我從實際上來看的話，大部分情況下你的索引的新加的頻率不會很高，因爲你太高的話，實際上是會影響你整個向量分佈的。你到了一定程度的時候，你相應的模型一定是重新訓練的，包括你導入數據，你的向量數據也一定要是重導的，否則你的結果會變得不是那麼好。
顧老師@ Milvus：我覺得這個是要看場景的，有一些場景下可能在你的場景下他是這樣的情況，但是在其他的用戶那邊確實它是只需要去我們提供向量召回的，我們是可以通過 ID 去獲取向量的數據的，他會非常頻繁的去做這個事情，而且他會覺得說他是要更快的速度去從 ID 拿到向量本身，所以確實在不同的用戶場景下，它的需求是不太一樣。
Attendee C：Ok，能理解，因爲我看你們的設計有點像 LevelDB，存儲的時候。
顧老師@ Milvus：對，都有一些參照。
Attendee C：其他的沒有什麼問題，再補充一個後續的發展是 roadmap 是怎麼樣的，是會盡量雲化，還是說在一段時間內是以中間件形式存在的？然後包括分佈式的解決方案，你們有沒有做過實際測試和一些場景報告？
顧老師@ Milvus：首先從項目本身來講的話，因爲這是一個已經是一個基金會項目，所以他作爲核心向量組件的形態，它會一直保留下去的其實。當然去做雲化服務也好，這些當然是我們也是會陸陸續續做一些這樣的嘗試吧。然後還有一個問題是什麼來着？對分佈式的的，網站上是有 ann-benchmarks 的測試，當然那是針對單節點的， 那分佈式的的部署我們的用戶當中有一些，但是我們確實自己沒有測過一些的信任的報告，這可能要等我們看看後續有沒有。因爲這個測試它還是需要配合一些環境去搞，我們可能得看一下後續看看怎麼組織一個這樣的環境，因爲對我們來講比較大的挑戰是說如果要 ann-benchmarks 這些去測，它可能更多看重檢索的性能，他整個的測試框架當中它沒有併發度的概念，而且我們也沒有一些這種這種業務的應用可以去做這種模擬去接進來。
所以這種端到端的這種更加在真實場景中的測試，確實是對我們來說是一個挑戰。所以我們也是希望我們的用戶再部署完之後可以給我們一些反饋，告訴我們他們的硬件的配置是什麼樣子的，他們是怎麼部置的，然後他們的場景下大概是一個什麼樣的併發度，然後目前大概檢索的時延可以達到什麼一個程度。
因爲其實整個搜索的速度它會受到很多因素的影響，在有的用戶那邊的話，因爲場景不一樣，它其實真的會差異挺大的。在如果我們是一個比較靜態的場景下去搜索的話，他其實都可以把數據，就是搜索速度都很快，但是因爲每個人的應用場景不一樣，限制條件也不一樣，他其實未必能發揮到理論的極限速度，所以也比較好奇問你看看你們這邊的話，你現在搜索的速度大概是在這種百萬量級大概是在什麼樣的速度上面？毫秒級嗎？還是幾十毫秒級呢？
Attendee C：我沒有單獨測過速度，我們整體的流程下來大概控制在 200 毫秒以內，其中包括向量檢索，然後後續的前期的業務數據處理和後續的業務處理，是在這個級別裏面，然後我們機器的話大概是現在的硬件配置應該是 16 套 48G 的。我們是雙節點部署的。
然後我還有一個問題就是想問一下我們這邊的那就是分佈式的解決方案，實際上是提供了一個 proxy，對吧？然後中間 proxy 那一層做了一個數據的分發，然後比如說我可能有幾千萬個數據，然後我使用上哈希分片錄入到不同機器上去存的，對吧？應該是這樣的。然後我查的時候實際上也是到不同機器去查，然後最後在 proxy 裏面再做個排序，然後取出 topK 是這樣的對吧？
顧老師@ Milvus：現在應該是可以把文件均勻的分佈到那些節點上面，然後你去搜的時候，其實你會搜這些節點上所有的數據，因爲這就是每個文件中取出 topK，最後再做一次歸併得到一個最終的答案，是這樣的一個模式。
Attendee C：那我在 proxy 那層就不做了嗎？
顧老師@ Milvus：不做什麼？
Attendee C：我理解是這樣的，比如說我現在是有 6 個節點，我有 300 萬數據，如果是均勻分發的話，對於每個節點實際上是 50 萬的數據。如果我要選 100 條的話，按照您剛纔的意思，實際上是在 6 個節點裏面分別選擇 100 條。
顧老師@ Milvus：對，最後再做一次合併。
Attendee C：最終的結果可能到我中間代理的 proxy 裏面就變成 600 條，但實際上我只需要 100 條。
顧老師@ Milvus：對，他會做一次合併。我說的合併就是說 600 條當中選出最終的 100 條。
Attendee C：ok 明白你的意思，懂了。其他沒有問題了。
Attendee D：其實我關注這個 Milvus 很久了，從最開始可能 17 年 、18 年左右其實就有這樣的需求，就有一個特徵檢索的需求特徵，按相似度排序，然後那時候找遍了互聯網也沒有這樣的一個解決方案，我們也自己想了一些辦法，一些 GPU 的矩陣運算，但是這個問題帶來的問題就是它是靜態數據，在動態的更新上面，可能問題也比較大。在上面如果想解決這個問題，我們可能要在上面做一系列的分裝，這個工作量相對來說還是比較大的，也沒有說去做這一塊。然後其實在去年年底差不多，我們關注到 Facebook 的 Faiss 那種系統，它在介紹裏面其實也提到了這個系統，但這個系統的問題是其實學習成本挺高的。我大概看了一眼，它裏面一些包括語言，其實語言這一塊其實可能就卡了很多人，他就是一個底層的對接這一塊，對外暴露可能也是 C 或 C++，然後其實也暫時擱置了。
然後在前一段時間應該是在機器之心還是哪推薦你們的 Milvus，我突然就看到了，後來發現跟我們的需求非常的符合，然後就深入研究了一下，目前的情況，我們算是在我們的線上，就是生產環境上面已經用上了，主要是在人臉的檢索和視頻，也是您剛纔提到的視頻的重複視頻的一個去重，但我們這個可能也不是一個去重，去找相似的視頻，目前來說運行的情況還是不錯的。也有一些問題想跟你們請教一下。
顧老師@ Milvus：你請說。
Attendee D：我一直有一個疑惑，然後剛纔我翻了一下你們的英文的文檔，之前一直看中文文檔其中有一個 IVF，就是索引 IVF_SQ8 中文文檔那地方寫對特徵向量有一定的壓縮，就把索引壓縮成 2 字節，然後我當時看到這塊一直很疑惑。我想正常來說應該是 4 個字節，然後看一下說壓縮變成 8 個字節，這裏非常疑惑。
顧老師@ Milvus：這個我們會去改一下。（會後文檔已更新）
Attendee D：然後還有一個兩個名稱的問題，我也是比較好奇的。Milvus 它是有全稱嗎？
顧老師@ Milvus：全稱您指的是什麼？因爲我們這個項目的名字就叫 Milvus。然後全稱您指的是什麼意思呢？
Attendee D：我想了解就是 Milvus 是某一個一長串的一個單詞的首字母的縮寫，還是說...?
顧老師@ Milvus：不是不是，它就是一種鳥的名字。
Attendee D：然後還有一個問題， FLAT 這也是一個名稱的縮寫？我在網上查的，包括 Faiss 裏面我看了一眼也沒有看到它的一個全稱。
顧老師@ Milvus：你可以認爲他啥都沒有，就是沒有索引，暴力檢索這樣子。
Attendee D：這個是有全稱嗎？我比較想了解他這個字面背後的意思。
顧老師@ Milvus：其實這個 FLAT 就是就是一個單詞。英文當中我們一般講 flat file，就是說這是一個很平的文件，就一個文本文件，就是沒有做任何什麼花式的這種索引，這種技術處理他就是非常平直的一個文本文件這樣的這種感覺。
Attendee D：明白，那第二種索引方式 IVF？
顧老師@ Milvus：應該這樣講，IV 這個詞的意思是 inverted。但爲什麼要叫 inverted 呢？其實這個東西是和 inverted list，這是一種倒排索引，它爲什麼叫倒排索引？就是它和索引本身是什麼很有關係。因爲其實最早的話，其實可以引用像 ElasticSearch 當中解釋，倒排索引就是從值去找對象，其實最早的所以都是從對象去找值，其實最早的所以都是來自於一個比較古老的學科叫做圖書管理學，就是你有好多書，你怎麼去分配他們，你就會把他們分配成比如說文學，然後這個都是文學裏面的書一排，然後那邊是什麼農業的一堆書。
但是其實你真正可能用戶現在你去圖書館去檢索的時候，你都是給了一些關鍵字，然後再從關鍵字鏈接到那些書，那關鍵字鏈接到書它可能在不同的分類裏面，所以它其實相當於來說相對傳統的索引來說它是一種倒過來的索引， 所以 inverted 其實主要就是這個意思。
Attendee D：明白了，在咱們的系統當中那個值就是不同的 ID。
顧老師@ Milvus：應該來講就是說 inverted 在索引當中稱爲 inverted 的話，我個人認爲它的個人含義應該是指我通過內容去獲取對象，那麼其實你在做向量搜索的時候，你搜索的向量其實就是你提取的圖片當中的特徵的內容，所以你也是通過內容去找對象，所以也是稱之爲這種 inverted 這種索引。
因爲這個名詞其實最早出現在 03 年的一篇論文，就是一個所謂他做的一件事情就是content base image retrieval，就是基於內容的圖像獲取。這些基於內容所謂的內容最終都被提取成了特徵向量，所以向量本身就是圖片的內容。所以從這個角度去理解的話，我覺得就是他爲什麼要把它叫做 invited list，倒排索引的原因。因爲它也是基於內容去獲取對象。
Attendee D：明白了。
顧老師@ Milvus：然後您剛纔也提到了 Faiss，其實從 Milvus 最開始的時候，我們也是受到 Faiss 啓發，然後基於 Faiss 來做整個向量搜索引擎，當然 Milvus 在這個 Faiss 當中也做了很多的改動，因爲要引入數據管理的這個概念，改動了以後會越來越多。源於 Faiss，但是希望能做的比 Faiss 更加能幫到大家一點，能不能做的更好，但是希望能做的更容易被大家使用。所以我不知道您開發軟件是用的 Java 嗎？因爲我們是做了一個 Java 的 SDK，也是因爲很多人說 Faiss 沒有 Java 的 SDK，然後我們就做了一個 Java 的 SDK。
Attendee D：沒有，我們倒沒有用 Java，用的全都是 Python。然後我們在實際使用的過程中用的是 IVFLAT，我當時選的是用索引在 400 萬的一個特徵庫上面做的一個檢索，大概需要 6 秒。你們覺得這個時間正常嗎？
顧老師@ Milvus：這個肯定是不正常的。這個和你的其他的參數有關係我覺得。我記得之前時不時會有人來問關於性能的東西，確實我們應該給出一些更好的東西，去跟大家解釋一個性能。因爲首先分類聚類的 nlist 就不應該設的太大，然後文件每個文件的大小也儘量能夠設得大一些，其實都會對於性能會有幫助。當然因爲這個也跟你具體的場景有關係，因爲有的人場景沒有辦法，流式進來的數據特別多，所以他沒有辦法等到太大的文件纔去建索引，所以他文件就設的比如說 256 這樣比較小，這確實因爲文件數多了，他是會影響性能，但也不可能說 400 萬需要 6 秒的這種級別，因爲如果你去看我們的 ann-benchmarks 測試的話，但是那是一個比較理想的狀態的測試，100 萬的向量的檢索差不多也就是在兩三個毫秒這樣的一個量級上。
Attendee D：對，所以這是一塊比較奇怪。
顧老師@ Milvus：對，所以你可以看一下你的這些參數的設置，然後索引是不是建好了之類的，都可以先檢查一下，包括內存的緩衝區的大小的設定等等。
Attendee D：目前來說我用的都是默認的除了 nlist。
顧老師@ Milvus：這個的話可能可能後續的看一下一些參數的配置，因爲它這個時間是一個不太正常的時間。
Attendee D：因爲我看到你們這個文檔裏面寫的都是 IVF_SQ8 這個索引，IVFLAT 的速度能比 IVF_SQ8 慢大概幾倍？
顧老師@ Milvus：幾倍是不至於，但確實會慢一些。因爲它的原理在於說，雖然 SQ8 的壓縮，它會帶來一些額外的操作，就是當你要把一個 8 bit 的整型展開成一個 32 維的浮點數，它會有一些額外的操作。但是在整個過程當中的話，其實去做向量搜索過程當中是 CPU 計算是一部分時間，然後你還有 I/O 傳輸，讀取內存也是另一部分時間。其實當中最大的矛盾還是在讀取那幾個速度上面，但是當你對他進行壓縮之後，雖然你有額外的計算量，但是你的 I/O 效率是大大的提高了。所以其實整體的它還是會快那麼一點點的，但這個比例不太好講，也不會說到達幾倍這種狀態。
Attendee D：明白了，我看了一下我們的線上的 nlist 用的是 16,000 多，這個數字是爲什麼？
顧老師@ Milvus：你可以調小一點，我覺得你可以試試 1024，2048 這些數字。
Attendee D：好的，我回頭試一下。然後我還有一個問題是咱們在批量查詢的時候，它的速度是比單個的查詢速度是有提升的。
顧老師@ Milvus：這是因爲它是一個批量的過程，所以他會節省一些開銷，他可以併發的去做一些計算。
Attendee D：主要是在計算的時候做一個併發，明白了。因爲我們的數據量比較大，然後每天都會有將近幾十萬的一個特徵插入，然後而且查詢的業務的產品的需求是需要按照時間來查，比如說幾月幾號到幾月幾號，然後我這邊的一個實踐方案是通過 partition，怎麼叫分庫，按照日期，按照每一天建 partition。
顧老師@ Milvus：給數據對做一些時間的標籤，對是的。很多人都這樣搞。
Attendee D：Ok 好的，在查詢的時候，比如說按照近三天，我就把近三天的 collection name 給指定上，然後這麼下去。然後一個是硬件的搭配問題，一個 CPU 和 GPU，然後我仔細看一下你們的文檔，我自己得出的結論是不是最佳的方案，是在硬件允許的條件下， CPU 和 GPU 搭配着來使用，能夠達到一個性能最好的一個結果？
顧老師@ Milvus：對是。因爲你要建索引的話肯定是 GPU 會快一些，搜索的時候你可能會更多的用到 CPU，如果你兩部分的資源都有的話，你動態鍵索引的時候就不太會影響搜索了。
Attendee D：明白，然後還有一個在查詢量，因爲我看到有個參數叫閾值，小於這個閾值的話，它就用 CPU 來檢索，大於一個閾值的時候他就用 GPU這個是...
顧老師@ Milvus：這個其實是結合你自己的實際的情況來看的，因爲 GPU 的話內存存顯存的速度會比較慢一點，所以你一定要量足夠大，它的優勢才能體現。所以給大家一個機會可以去選擇，要不然的話 CPU 佔用時間也會變得非常的長。
Attendee D：那單用 GPU 來檢索的話，他在不同的查詢量上面，他的時間幾乎是恆定的。這塊主要原因是什麼？
顧老師@ Milvus：因爲 I/O 時間遠遠高於計算的時間，所以你去做大規模計算的話，你得先把數據傳進去，傳輸的時間其實是佔了 99.9%，可能就只有千分之1的時間是計算的。所以 GPU 算再快，其實你感覺不到的。
Attendee D：明白。IO 的時間是從內存...
顧老師@ Milvus：內存到顯存
Attendee D：那有沒有從磁盤到內存？
顧老師@ Milvus：沒有。我們一般會我們目前都是常駐內存，但是用 GPU 的時候會在從內存裏面進入到顯存裏面，所以傳輸時間是一個硬傷，對 GPU 來說是它現在最大的短板。
Attendee D：對，確實是我們在做有一些模型的推理，需要比如說這張圖片需要從內存存到顯存裏面 ，這塊其實是個挺長時間耗時比較久的。
顧老師@ Milvus：是的，這個就是英偉達最大的挑戰。
Attendee D：還有兩個問題，我的問題比較多，不好意思。然後還有一個我看到你們有一個 Milvus Admin 這個可視化的工具我覺得還是很好用的。但最近我在用的時候，可能是不知道是不是因爲數據量過大，他在查詢一些 collection 或者是 partition的時候，就直接沒有響應了。顯示超時。
顧老師@ Milvus：你可以把你的問題開在 GitHub 上，我們可以看一下。因爲確實這部分可能是會因爲可視化的組件的話，它確實測試是有一定的挑戰的，因爲我們可能測試環境當中並沒有那麼大的數據量，我不知道您在查看一個多大的 collection 的時候，碰到這類似的問題，你可以在給我們開的 issue 當中都描述一下嗎？
Attendee D：好的。最後一個問題，在 arm 上面適配嗎？
顧老師@ Milvus：Arm 上面的話，我們原來適配過一個英偉達的 Jetson Nano 那樣的 Arm 芯片， 那是一個早期的版本可以跑的。後來其實對他們的需求似乎不是特別的明顯，所以我們就沒有再往後面去做了。當然如果說大家有需要 Arm 的，或者說需要 Arm 定製版的話， 都可以單獨再聯繫我們。
Attendee D：好的，我們現在因爲涉及到一些硬件國產化的問題，我們可以傾向於選用華爲， 那華爲的話服務器都是 Arm 的。我們就在上面做了一個編輯嘗試，然後他沒有通過。缺少一些應該是指令集一些相關的文件，所以就失敗了。
顧老師@ Milvus：是的，他工具鏈、程式庫、指定集可能都會不一樣，所以這個是需要額外的適配工作的。
Attendee D：好的，我們有需求在羣裏邊再跟你們請教。
Attendee C：我們現在的 SDK 包括 Python 版本的實際上都是 gRPC 的，我們這邊會提供 restful 的嗎？
顧老師@ Milvus：有，我們本身就有 HTTP 的接口。
Attendee C：沒有，但是我看代碼裏只有 gRPC 的啊？所有的查詢的操作其實都是 gRPC 的。
顧老師@ Milvus：可能我們的文檔是不是..回頭我們把文章鏈接發給您看一下。
Attendee C：第二個問題是我看代碼裏有個 web server， web server 應該就是 Admin 的 server 對吧？就是可視化工具的。
老金@ Milvus：這個問題我來回答，是這樣的，首先 restful 接口的話，http 就已經提供了，就是你看到那個 web server 的東西。
Attendee C：但是我看 py 的 SDK 裏沒注意到，我再看一下。我再補充一點就是能不能根據一個是不同數量級，另外一個根據當前的測試配置，然後推薦一些建索引的時候的配置的參數，就推薦參數這種。
顧老師@ Milvus：確實我們是想做這個事情的，後續我們看看怎麼把這個東西弄得更好一點，更友好一點給大家。因爲我發現其實大家在這種性能問題，其實有很大的原因在這當中的。所以我們會去看一下怎麼給大家一個更好的方式去理解這些東西吧。我們會補充在 http://Milvus.io 官網有一個叫 sizing 的頁面，我們會補充在頁面上。
Attendee C：好的，謝謝。
下週一樣是週二晚上 8 點線上開聊～走過路過不要再錯過咯！
|歡迎加入 Milvus 社區
http://github.com/milvus-io/milvus | 源碼
http://milvus.io | 官網
http://milvusio.slack.com | Slack 社區
http://zhihu.com/org/zilliz-11/columns | 知乎
http://zilliz.blog.csdn.net | CSDN 博客
http://space.bilibili.com/478166626 | Bilibili
