蕭簫 發自 凹非寺
量子位 | 公眾號 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
參考鏈接：
[1]https://github.blog/2023-02-06-the-technology-behind-githubs-new-code-search/
[2]https://news.ycombinator.com/item?id=34680903
