本文經AI新媒體量子位（公眾號ID:QbitAI）授權轉載，轉載請聯系出處。

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

經過一番測試優化后，GitHub現在公開了背后的技術原理。

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

網友們看完技術原理后感到驚喜：

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

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

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

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

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

基于Rust語言的搜索引擎

GitHub新版代碼搜索引擎名叫Blackbird，它的關鍵在于重新構建了一個索引。

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

簡單來說，正向索引指先給數據庫中的各種內容編號（ID），然后通過這些內容ID來搜索對應的具體內容：

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

反向索引即通過內容中關鍵詞，直接搜到對應的內容ID，從而立刻定位到對應的內容。

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

這種方法怎么理解？

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

這時候搜索任意一個字符串，都能找到對應的內容ID，從而定位到想要搜索的內容。

但GitHub的程序員們也意識到，這樣構建的索引太大了，要真這樣搜索的話會導致服務器不夠用，因此還需要對這種方法進行優化。

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

以這類方法為基礎建立的系統如下：

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

測試版體驗如何？

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

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

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

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

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

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

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

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

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

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

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

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

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