還記得 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
