本文經(jīng)AI新媒體量子位（公眾號ID:QbitAI）授權(quán)轉(zhuǎn)載，轉(zhuǎn)載請聯(lián)系出處。

還記得GitHub發(fā)布的新版代碼搜索引擎嗎？

經(jīng)過一番測試優(yōu)化后，GitHub現(xiàn)在公開了背后的技術(shù)原理。

最新版搜索引擎，不僅解決了之前搜代碼時“驢唇不對馬嘴”的情況，還可以直接用正則表達式搜索；此外也解決了部分項目上傳后搜不到等問題……

網(wǎng)友們看完技術(shù)原理后感到驚喜：

這真不錯！我看到了谷歌代碼搜索引擎的影子。

其實我知道，很少有做代碼搜索引擎的人愿意去GitHub，但很高興能看到這一功能將變得更好用。

要知道，此前GitHub的代碼搜索引擎，一度被用戶吐槽“形同虛設(shè)”。

有不少用戶直接自己找了更好用的代碼搜索引擎，專門搜索想要的代碼：

在這種情況下，新版GitHub代碼搜索引擎究竟采用了什么技術(shù)，做出了哪些改進？

基于Rust語言的搜索引擎

GitHub新版代碼搜索引擎名叫Blackbird，它的關(guān)鍵在于重新構(gòu)建了一個索引。

這里主要實現(xiàn)兩類索引，包括正向索引（Forward index）和反向索引（Inverted index）。

簡單來說，正向索引指先給數(shù)據(jù)庫中的各種內(nèi)容編號（ID），然后通過這些內(nèi)容ID來搜索對應(yīng)的具體內(nèi)容：

這種搜索方法雖然比較直觀，也容易理解，但搜索量太大了。如果我們只想通過關(guān)鍵字搜索對應(yīng)內(nèi)容，就需要用到反向索引。

反向索引即通過內(nèi)容中關(guān)鍵詞，直接搜到對應(yīng)的內(nèi)容ID，從而立刻定位到對應(yīng)的內(nèi)容。

具體到反向索引實現(xiàn)方法上，GitHub采用了一種名叫ngram索引的方法，可以很方便地查找內(nèi)容的子字符串。

這種方法怎么理解？

以limits這個字符串為例，如果ngram中的n=3，那么我們就可以將它分為lim、imi、mit、its四個子字符串。

這時候搜索任意一個字符串，都能找到對應(yīng)的內(nèi)容ID，從而定位到想要搜索的內(nèi)容。

但GitHub的程序員們也意識到，這樣構(gòu)建的索引太大了，要真這樣搜索的話會導(dǎo)致服務(wù)器不夠用，因此還需要對這種方法進行優(yōu)化。

在Hacker News中有一位GitHub程序員對此做出了解釋，即采用一種叫做覆蓋稀疏ngrams（covering sparse ngrams）的方法生成候選集，并搜索對應(yīng)內(nèi)容，其中9代表ch、6代表he、3表示es，以此類推：

以這類方法為基礎(chǔ)建立的系統(tǒng)如下：

所以，新版搜索引擎是否真的比之前更好用了？

測試版體驗如何？

目前GitHub中有大約4500萬個存儲庫、115TB代碼和155億個文檔。

據(jù)GitHub官方表示，原本在改進之前，處理155億個文檔需要大約36個小時。

然而在重寫代碼之后，需要抓取的文檔數(shù)量降低了50%以上，因此只需要18個小時左右就可以重新給整個語料庫創(chuàng)建索引。

除此之外，需要搜索的內(nèi)容量也降低了不少。

原本需要搜索的內(nèi)容在115TB左右，現(xiàn)在將重復(fù)內(nèi)容和數(shù)據(jù)刪除之后，包括索引和內(nèi)容壓縮副本加起來只有25TB大小，縮減到之前的25%左右。

目前測試版依舊在開放申請中，有不少GitHub用戶已經(jīng)試用了一波。

雖然有不少用戶對新搜索引擎測試版反響不錯，但也有人提出了一些建議。

例如目前這個代碼搜索引擎還沒辦法過濾fork項目，有時候用代碼搜索引擎，搜出來全是同一個項目。

對此GitHub程序員也給出了反饋，表示他們之前一直在調(diào)整索引這一塊，以后會考慮這樣的附加功能。

除此之外，也有用戶表示，GitHub新版搜索引擎依舊不好用，它從來不區(qū)分符號的定義和使用，有時候搜出來的結(jié)果，往往需要往后翻5頁左右，才能找到想要的結(jié)果。

對此，還有網(wǎng)友推薦了自己常用的代碼搜索引擎，如Sourcegraph。

你試用過GitHub的新代碼搜索引擎了嗎？或是還有什么其他好工具推薦？

新版代碼搜索引擎申請試用：https://github.com/features/code-search