幹壞事是進步最大的原動力
在 Hacker News Daily 上的整理看到的：「Google Cache Is Fully Dead」。
這樣的話變成只有 Internet Archive 與 archive.today 可以用了。
Google Cache 之所以重要是因為 Google 搜尋更新的速度很快，尤其是針對比較大的站台，另外因為搜尋引擎拉資料是自動化的，在文章剛被刪除的當下可能連 Internet Archive 或是 archive.today 都還沒有人去存，這時候至少還可以去 Google Cache 上面拉一份出來。
但拔功能已經是 Google 的常態了，現在只是列表上面多了一項...
前陣子從日本買的電器附的線是兩孔加地線，與 IEC 60320 C5 的頭：
雖然我手上剛好有 Panasonic WH 2881P 可以把地線硬接起來：
但想了想既然是標準接頭，弄一條新的線好像比較好，所以就在網路上找，結果發現都找不到... 本來想說是不是台灣沒在用這種頭，但後來想到很多筆電好像就是用這種頭？
多花了一些時間找資料，後來看到維基百科上面這樣寫：
許多用於筆記本電腦的小型開關模式電源。由於其形狀，通常稱為「三葉草」或「米老鼠」連接器。
改用「米老鼠 電源線」就出現一堆，苦啊...
在「Reddit's Robots.txt Changed (reddit.com)」這邊看到的，可以看到現在 https://www.reddit.com/robots.txt 的內容變成 (刪掉註解的部分)：
User-agent: * Disallow: /
這個改變倒是沒預料到的... 來觀察看看 HN 上後續的討論？
前幾天很熱門的「An Anonymous Source Shared Thousands of Leaked Google Search API Documents with Me; Everyone in SEO Should See Them」消息，裡面提到有拿到一份疑似 Google 搜尋引擎的內部 API 文件， 可以證實有很多 Google 搜尋引擎的運作與 Google 對外宣稱的不符。
作者找了業內人士幫忙分析 (他自己說他先前也在碰 SEO 這塊，但是已經離開這個行業六年了)：
Next, I needed help analyzing and deciphering the naming conventions and more technical aspects of the documentation. I’ve worked with APIs a bit, but it’s been 20 years since I wrote code and 6 years since I practiced SEO professionally.
包括作者的一些 Google 朋友，或是 ex-Googler 都確認這份文件符合 Google 內部的文件規範要求，另外裡面的元素編排也都很像是 Google 的文件。
本來以為事情大概就這樣，後續應該就是會有很多人從這份文件分析 Google 有哪些 SEO 的偏好，找出哪些東西與 Google 宣稱的不符。
不過事情突然有個意外的轉折，Google 本來一直是「拒絕評論」的態度，但突然承認這份文件的確是他們內部文件：「Google confirms the leaked Search documents are real」。
"We would caution against making inaccurate assumptions about Search based on out-of-context, outdated, or incomplete information," Google spokesperson Davis Thompson told The Verge in an email. "We’ve shared extensive information about how Search works and the types of factors that our systems weigh, while also working to protect the integrity of our results from manipulation."
反正也沒有人會相信 outdated 了，但可以預想的是 Google 的搜尋結果應該又會變差，因為會有更多 SEO 垃圾開始想辦法衝排名上去...
在「&udm=14 | the disenshittification Konami code」這邊看到的，裡面有提到「How I Made Google’s “Web” View My Default Search」這篇說明。
我測了一下「how many people in the earth」這個搜尋條件，結果是這樣 (w/ uBlock Origin)：
加上 &udm=14 後會拿掉很多「輔助」的區塊：
有些人可能偏好前者，但有些人偏好後者，可以自己選擇... (不過我應該會繼續用 Kagi)
在 Hacker News 上看到的討論，裡面剛好有 Reddit 第一個雇用的工程師，Jeremy Edberg 的留言：「Reddit is taking over Google (businessinsider.com)」。
在 id=40068381 這邊提到了不少東西，首先是把 title 放進 url 裡面的作法：
To this day, my most public contribution to reddit is that I wrote the code to put the title of the post in the URL. That was done specifically for SEO purposes.
這個在 Google Webmasters (現在叫做 Google Search Console) 也針對 Reddit 處理，將速率強制設為 Custom，不讓 Reddit 的人改：
It was pretty much the only SEO optimization we ever did (along with a few DOM changes), because shortly after that, Google basically dedicated engineering effort specifically to crawling reddit. So much so that we lost the "crawl rate" button in our SEO admin page on Google, it was just set to "Custom".
後續還要針對 Google 的抓取在 load balancer 上把流量拆開處理，不然 crawling pattern 與一般使用情境很不一樣，會造成 cache 的效率極度低落：
I had to stand up a fleet of app servers and caches and databases, and change the load balancers so that Google basically had their own infrastructure (although we would shunt all crawlers there). Crawler traffic was very different than regular traffic -- it looked at pages more than two days old, something humans rarely did at the time. It would blow out every cache (memory, database, disk, etc.). So we put them on their own infra to keep them from killing the rest of the site.
這些算是頗有趣的經驗？
tf–idf 與 BM25 是兩個在資訊檢索 (IR) 裡面的經典演算法，也常被用在搜尋引擎技術上。
前陣子在練 Go，剛好找個主題來練，tf-idf 已經很熟了，但 BM25 沒有實際寫過，而自己的 blog 也累積了七千多篇，這個數量還算好用，不用自己另外 dump 維基百科的文章跑... (而且量太大)
第一步是拆成 token，我這邊就拿 bigram 拆了，但英文的部分把一整個詞當作一個單位，而非一個字母一個字母拆。
btw，這邊 tf-idf 與 BM25 的公式就請大家自己去維基百科上翻了...
tf-idf 概念上很簡單，而也沒有什麼 magic number 在公式裡面。
如果把 tf-idf 當一個 function 來看的話會是 score = tfidf(w, d, D)，表示一個字 w 在一份文件 d 裡面的分數 (而 D 是所有文件)。
而 tf 只跟文件本身有關，可以預先算好放著，df 在後續文件新增刪除時都可以 incremental update，不需要重頭算，是個對於平行化運算很友善的演算法。
接著是看 BM25，如果把 BM25 當作一個 function 來看的話，會是 array = bm25(Q, D)，針對 query words Q 與所有文章 D 傳回一個排序結果 array，裡面會是排序過的 document id，通常會包括分數。
而從公式可以看到 BM25 其實就是把 Q 裡面的每個字丟進 tf-idf 後加起來的變形，只是多考慮到文件大小對分數的影響，另外裡面引入了一些花招，像是 k1 與 b 這兩個常數項。
所以我就寫了兩個版本，一個是單純用 tf-idf 相加 (這樣長文章分數應該會比較高)，另外一個是用 BM25 的公式跑... 算是趣味趣味的寫法。
算是清掉了之前一直放著的項目...
看到 Kagi 公佈了訂閱數量破兩萬的新聞：「Celebrating our first 20,000 members」，翻了一下先前的文章，九月的時候才接近 9k：「Kagi 又恢復 $10/mo 的 Unlimited Search Plan 了」。
目前的目標看起來是訂在 50k (至少圖表上面的是 50k)：
從 Internet Archive 上面查，可以看到九月到十月那波是漲最多的，差不多 22%：(出自 https://web.archive.org/web/20231011042040/https://kagi.com/stats 這邊)
依照 2022 年當時在「Kagi status update: First three months」這篇的說法，要 25k users 才能打平所有的開銷，雖然後來產品線改變蠻多的，但 25k 應該還是會算個重要的 milestone？
We are planning to reach sustainability at around 25,000 users mark, by further improving the product, introducing new offerings and pricing changes. With the product metrics being as good as they are, we should be able to reach this as our visibility increases.
現在看起來應該再給幾個月就會達到了，看起來會證明這塊小眾市場還是能做的？
在 Hacker News 上看到「Lessons from building GitHub code search (youtube.com)」這篇在講 GitHub 的 Code Search (今年九月在 Strange Loop 上的演講)，同時演講者 Luke Francl (帳號是 100k) 也有在 Hacker News 上留言回答一些問題：
影片裡面有不少資訊，挑我自己覺得有趣的地方整理一下。(不是依照影片的順序)
首先是現成的 search engine (Elasticsearch) 會濾掉太多資訊，其中一種例子就是在程式語言中，各種 token 像是 <、= 以及 > 這些，都算是有用的資訊。
另外一方面是 Elasticsearch 的架構下沒有辦法利用 fork 的性質 (以及 Git 的 branch 性質)，所以在處理 fork 類的 repository 會造成大量重複的資料，但 fork 的資料會有 99% 以上是與原來的 repository 相同。
舊的系統有 312 servers，包括了 24960 cores 與 20TB RAM，直接平均下來，每一台機器是 80 cores 與 65GB RAM，而跑一次 reindex 會需要幾個月的時間。
新的系統則降到了 130 servers，包括了 8320 cores，但記憶體加到了 65TB RAM，直接平均下來，每一台機器是 64 cores 與 512GB RAM，後面有列出來是 Azure 的 L64s v3，剛好就是 64 cores 與 512GB RAM，然後帶有 640GB temp disk 與 8*1.92TB 的 NVMe disk。
另外有提到這套新的系統雖然比較小 (除了記憶體)，但卻是 3 clusters，這也剛好解釋記憶體變成原來三倍的原因。
而更重要的是，因為有多個系統，所以他們可以在上面對 production 等級資料量進行測試，而且不用害怕炸掉東西。
而且新的系統從零 rebuild 一次只需要幾天，不像之前需要好幾個月。這些改變使得 engineer 更容易進行個重嘗試與改善，而不用把精神花在要怎麼維持相容性。
回到 CPU 數量的下降，這邊沒有直接提到原因，但演講裡有提到有不少東西改用 Rust 寫，等於是從 JVM 換到原生程式碼，對於會有大量時間花在 CPU 運算的服務來說是個明顯的加分。
中間有兩個提到演算法的事情也蠻有趣的。
第一個是在 Delta compression 的地方，把 fork 後的差異當作是 delta，要最小化整個 fork tree 的成本，剛好把這個東西轉換成圖論的問題，就可以套用 Minimum spanning tree 這個經典的演算法，而且 MST 太經典，有很多變形也都有人研究過，有限成的演算法可以用。
另外一個提到的是 Alexander Neubeck，從 LinkedIn 上的資料可以看到他在 Google 的時候就是負責 Code Search，後來到 GitHub 看起來剛好加入對應的團隊，他開發了一個新的資料結構 Geometrics XOR filter 來解決 Delta compression 遇到的問題。
在 Hacekr News 上的討論可以看到有人抱怨還是缺了重要的功能，不過這畢竟是砍掉重練開始搞，而且是配合 Git 與 GitHub 的特性設計的，可以預期會缺東西，但就像演講裡提到的，新的架構可以讓整個團隊更快的迭代進行各種嘗試，後續就比較會是官方要取捨實作哪些功能了...
Kagi 公告 $10/mo 的 Unlimited Search Plan：「Unlimited Kagi searches for $10 per month」。
今天公告以後可以看到有個比較抖一點的成長，但要再觀察看看是不是持續的：
翻了一下文章，還是沒看到為什麼要這樣做，尤其是財務上的理由... 最早從 $10/mo 漲到 $25/mo 就是成本問題，我的猜測是現在有量了所以 discount 比較好談 (從 9/6 的「Kagi Search Stats」的 8034 與現在的相比，的確可以看到一直在成長)，然後談完 discount 後重算成本結構，發現有機會衝一波？
也有可能是 VC 那邊有進展？像是找到比較願意放手讓 Kagi 執行這樣的理念的 VC？
Anyway，$10/mo 又回來了...