5 puan yazan GN⁺ 2025-05-02 | 1 yorum | WhatsApp'ta paylaş
  • hn.unlurker.com’u geliştirirken yazdığım HN API istemcisine, tüm item’ları sırayla alan bir scan özelliği ekledim ve Hacker News’ün tüm verilerini yerele indirdim
  • hn scan --no-cache --asc -c- -o full.json çalışırken indirme birkaç kez durdu, ancak devam ettirilebilir scan sayesinde birkaç saat sonra 20 GiB’lık bir JSON dosyası elde ettim
  • DuckDB’nin read_json_auto özelliğiyle JSON’u tabloya dönüştürdükten sonra, text ILIKE ve 12 haftalık hareketli ortalama SQL’iyle Python, JavaScript, Java, Ruby ve Rust’tan bahsedilme oranlarını hesapladım
  • Sadece basit bir grep ile bile “correct horse battery staple” ifadesinin Hacker News’te 231 kez geçtiğini doğruladım; DuckDB bu ölçekteki tek seferlik analizler için oldukça uygun görünüyor
  • Tüm veri yerelde olduğunda Hacker News’ün geçmiş içerikleri birçok şekilde analiz edilebilir, ancak bu proje burada tamamlanıyor ve sonraki adımı başka birinin devralmasına bırakıyor

Hacker News’teki tüm item’ları indirme

  • hn.unlurker.com’u oluşturmak için bir HN API istemcisi yazdım
    • Zaten birçok istemci vardı, ancak yeni bir projede güncel Go özelliklerini ve linter’ları denemek istedim
    • HN API’de yorumlar ve hikâyeler item olarak adlandırılıyor
  • İstemci, etkin item’ları ve item listelerini getirebiliyor
    • Asıl projede yalnızca son item’lar gerekiyordu, ancak tamamlanmışlık adına scan özelliğini ekledim
    • scan, item’ları 0’dan en güncele kadar ya da ters yönde sırayla indiriyor
  • Tüm indirme işleminin on binlerce GiB değil, onlarca GiB JSON civarında olacağını tahmin ettiğim için denedim
hn scan --no-cache --asc -c- -o full.json
  • İndirme birkaç kez durduğu için CTRL-C ile kestim, ancak scan devam ettirilebilir olduğundan birkaç saat sonra tamamlandı
  • Ortaya çıkan sonuç, Hacker News’te gerçekleşmiş her şeyi içeren 20 GiB’lık bir JSON dosyası
  • Aynı komut yeniden çalıştırıldığında en güncel verilerle yeniden doldurulabiliyor

DuckDB ile yerel verileri analiz etme

  • Başta yalnızca grep ile arama yaptım
    • correct horse battery staple” ifadesi Hacker News’te 231 kez geçiyor
    • Son görünme örneği, yazı anı itibarıyla “bugün” yayımlanan bir item idi
  • Ardından DuckDB ile analiz denedim
    • DuckDB, gömülebilir, hızlı bir analitik yürütme motoru ve komut satırı aracı olarak da sunuluyor
    • Yeni UI sayesinde yeni başlayanlar için de kullanımı kolaydı; LLM, SQL sorguları yazmada yardımcı oldu
  • JSON verisi DuckDB’ye şu şekilde alındı
CREATE TABLE items AS
SELECT *
FROM read_json_auto('/home/jason/full.json', format='nd', sample_size=-1);
  • Örnek sorgu item’ları haftalık bazda grupluyor ve tüm item’lar içinde belirli bir kelimeyi içerenlerin oranını hesaplıyor
    • python, javascript, java, ruby, rust, text ILIKE ile aranıyor
    • Her oran için 12 haftalık hareketli ortalama hesaplanıyor
  • Aynı yöntemle veritabanı ile ilgili kelimeler de görselleştirildi
    • Örnek grafikte mysql, postgres, mongo, redis, sqlite için 12 haftalık hareketli ortalama bahsedilme oranları yer alıyor
  • DuckDB, bu boyuttaki bir veri kümesini analiz etmek için çok iyi göründü
  • Hacker News içeriğinin tamamının yerel bir kopyasına sahip oldum, ancak projeyi burada bitirmeye karar verdim

1 yorum

 
GN⁺ 2025-05-02
Hacker News yorumları
  • Önceden indirmeden analiz çalıştırabileceğiniz, güncel Hacker News tablolarına sahip iki veritabanı biliyorum
    BigQuery için bir Google Cloud hesabı gerekiyor; sorgular muhtemelen ücretsiz katmanda çalıştırılabilir ve bigquery-public-data.hacker_news.full kullanılabilir
    ClickHouse için kayıt gerekmiyor ve sorguları doğrudan tarayıcıda çalıştırabilirsiniz: https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPT...

  • Bir süre önce @fesshole Twitter/Bluesky hesabıyla benzer bir şey yapmıştım. Tüm arşivi indirdim ve modeli daha da uçuk itiraflar üretmesi için ince ayar yaptım
    Epey gurur duymuştum ama sonunda saf bir makineye sadece mastürbasyon ve boşanmayı öğretmiş olduğumu fark ettim
    Bilim kurgu filmlerinde uzaylıların ya da süper zekâ bir yapay zekanın insanlık tarihini çok hızlı izleyip bizim kurtarılmaya değmeyeceğimize karar verdiği sahneler gibiydi

    • “Saf bir makineye mastürbasyon ve boşanmayı” kısmı için, çoktan yok olmuş bir medeniyetin USB belleğini bulup modelinizi o metin verileriyle eğittiğinizi düşünün
      Bu verilere dair dış dünyayla hiçbir bağlantı yoksa, o USB bellekte mastürbasyon ve boşanmayla ilgili veriler bulunduğunu bir insan ya da model nasıl anlayabilir?
    • Mastürbasyon ve boşanmanın nesi sorun, bilmiyorum. İkisi de insanların daha mutlu ve bağımsız yaşamalarını sağlayan, kendilerine uymayan durumlardan çıkmalarına yarayan yollar
      İkisini de genel olarak olumlu görüyorum ve bunların normalleştiği bir toplumda yaşayabildiğim için minnettarım
  • Java sorgusu JavaScript’in tüm örneklerini de kapsadığı için Java olduğundan fazla örnekleniyor

    • Benzer şekilde Rust sorgusu da trust, antitrust, frustration gibi bir sürü kelimeyi içerecektir
    • Doğru… o zaman düşüş eğilimi görülmesi aslında daha da beklenmedik olabilir
  • Hacker News’te olup biten her şeyi içeren 20GiB’lık bir JSON dosyası olması, yalnızca metinden oluşan bir site olduğu düşünülünce şaşırtıcı derecede büyük
    Bu, HN’in var olduğu 18 yıl boyunca insanların 20 milyar bayttan fazla metin yüklediği anlamına mı geliyor? Günlük ortalama 2MB’tan fazla, saniyede yaklaşık 7,5KB ediyor

    • Günde 2MB pek fazla görünmüyor. Özellikle Reddit olayından sonra gelen, yakın dönemdeki ve en büyük “bitmeyen Eylül” ile birlikte gönderi sayısının yıllar içinde üstel olarak artmış olması muhtemel
      Üstelik bunun kayda değer bir kısmı insanlardan gelmiyor olabilir. /newest bot spam’iyle dolu
    • 7,5KB/s, yani saniyede 7500 karakter gerçekçi gelmediği için hesapladım[0]; aslında saniyede yaklaşık 34 bayt, yani 0,03KB/s’ye daha yakın
      JSON’un metaverisi ve söz dizimi de buna dahil olduğundan gerçek metin miktarı bundan da düşük olacaktır. “Günde 2MB’tan fazla” hesabı doğruydu
      [0] Aslında hesabı ChatGPT yaptı ama doğru görünüyor: https://chatgpt.com/share/68124afc-c914-800b-8647-74e7dc4f21...
    • Reddit’in tüm arşivi, API’yi kaldırmalarından hemen önce sıkıştırılmış halde yaklaşık 4TB idi. Eskiden the-eye’da barındırılıyordu; isterseniz dosyaları hâlâ torrent’leyebileceğiniz yerler var
      Bunun önemli bir kısmı çöp, ama özellikle daha akıllı botların ortaya çıktığı 2018-2019 öncesindeki erken dönem veriler incelemeye değer gibi
    • 20GB JSON olması şaşırtıcı. Tüm HN verilerini içeren bir SQLite dosyam var, o da 20GB; JSON olsaydı çok daha büyük olması gerekirmiş gibi geliyor
    • Toplam boyut bana aksine küçük geliyor. Neredeyse 20 yıl boyunca yüz binlerce aktif üyenin ve toplamda milyonlarca kişinin katkısının sonucu
      HN, Facebook öncesi ölçütlere göre epey büyük bir sosyal ağ sayılırdı; boyutunun makul ve aktif biçimde yönetiliyor olması sayesinde değeri de yüksek
      2019’da Google+ kapanırken o siteye katkı olarak girilmiş metin verisinin ne kadar olduğunu modellemeyi denemiştim
      Burada metin verisi, görsel·ses·video gibi medyaları ve HTML iskeleti, CSS, JS gibi ek sayfa öğelerini hariç tutuyor
      Katılım oranının çok düşük olması ve gönderi ortalamasının yaklaşık 120 karakter olması dikkate alındığında, on milyonlarca aktif hesabın 7 yıllık geçmişi bile yalnızca birkaç GiB ediyordu. Kayıtlı profil sayısı 4 milyarı aşmıştı ama gerçek etkinlik çok daha azdı
      Archive Team, Internet Archive ile işbirliği içinde ama ayrı olarak Google+ koruma çalışması yaptı ve sonuçlar karışıktı. Çok içerik korundu ama çok daha fazlası kaçtı; yorumlar neredeyse hiç kalmadı, başlıklar son 10 civarı öğeyle kesildi ve arama olmadığı için genel olarak pek işe yaramaz hale geldi. Rastgele hash yerine seçilmiş hesap adı kullanan “vanity accounts” için erişilebilirlik daha da kötüydü
      Üstelik tüm sayfayı kazıyıp çevrimiçinde görünen hali yeniden üretmeye çalıştıkları için depolama gereksinimini ciddi biçimde artırırken, siteyi gerçekten ilginç kılan unsurların çoğunu kaçırıyorlar
      Büyük nüfus gruplarının metin katkılarını saklamak istediğinizde bile depolama gereksinimi oldukça modest kalıyor. Örneğin günlük ortalama çevrimiçi süre 45 dakika, yazma hızı 45wpm ve çevrimiçi sürenin yalnızca yarısı okuma değil de yazma olsa bile kişi başına günde yaklaşık 1.000 kelime, yani yaklaşık 6KiB eder. 1.000 kişi için 6MiB, 1 milyon kişi için 6GiB, 1 milyar kişi için yaklaşık 6PiB
      Gerçek değer neredeyse kesinlikle daha düşük. Yazma süresi abartılmış durumda ve gerçekte %10’a daha yakın olacaktır; mobil giriş hızı da muhtemelen 20-30wpm civarındadır. Örneğin Facebook’a günde yaklaşık 2,45 milyar “içerik parçası” yükleniyor ve bunların yarısı video. Gönderi başına 120 karakter varsayarsak metin verisi günde 300GiB’tan çok daha az, şaşırtıcı derecede küçük bir miktar
      Günümüzde veri toplama ve gözetim kapitalizmi sistemlerinin büyük bölümünü konum, video, çevrimiçi etkileşim, ticaret gibi insanların doğrudan girmediği veriler oluşturuyor
  • HN’i indirirken netiket ne olmalı? Sunuculara yük bindirmeden önce dang’e sormak mı gerekir?
    Yoksa artık milyarlarca dolarlık teknoloji şirketleri bunu zaten defalarca yapıyor olduğundan fark edilmeyeceğini mi varsaymalı?

    • Makalede de geçtiği gibi HN’in bir API’si var, üstelik hız sınırı bile yok. Tüm veriler bir YC şirketi olan Firebase üzerinde barındırılıyor, yani sorun yok
    • Kelimenin tam anlamıyla herkese açık bir veritabanı var
      https://console.cloud.google.com/marketplace/product/y-combi...
    • Üç harfli kurumların HN takma adlarını gerçek isimlerle eşleştiriyor olma ihtimalini de göz ardı etmemek gerek
    • Adı Hacker News olduğuna göre, en azından iyi anlamdaki hacking adil oyun sayılır
    • Açık web’de yayımlanmışsa zaten binlerce bot tarafından scrape ediliyordur
  • Benzer bir şey yapmıştım. BigQuery veri kümesini kullanma gibi bir hileye başvurdum; nedense sürekli güncelleniyordu, verileri Parquet olarak dışa aktarıp indirdim ve DuckDB ile sorguladım

    • Bu hile değil, sadece pratik bir tercih
  • “Artık Hacker News’teki tüm içeriği yerelde indirdiğimize göre, yüzlerce LLM tabanlı botu eğitip katkıcı olarak çalıştırabilir, geçmişi sonsuza dek yankılayan ve geri dönüştüren bir Çin odası titreştiricisinin çıktısıyla tüm insan metinlerini yavaş yavaş, kaçınılmaz biçimde değiştirebiliriz” diye yapılan bir şaka bu; ama bir gün birinin bunu deneyeceğinden korkuyorum
    Umarım böyle bir şey olmaz, ama olursa engelleyebilir miyiz?

    • Zaman geçtikçe daha da önemli hale gelen eski bir fikre giderek daha çok inanıyorum: İnsanlar arasında bir güven ağı kurmak; yani bir hesabın, benim tanımadığım ama güvendiğim birinin güvendiği, onun da benim tanıdığım birinin güvendiği ve o kişinin de benim güvendiğim biri olduğu türden bir yol üzerinden doğrulanması
      Çözülmesi gereken çok sorun var; gizlilik de bunlardan biri. Bağlantı ilişkilerini kullanıcıya açmak gerekmeyebilir, ama saf bir uygulamada bunlar sunucuda kalır
      Güvensizlik yolları negatif ağırlık olarak da eklenebilir. Birine doğrudan ya da dolaylı olarak güvenmiyorsam, benimle o kişiyi bağlayan güven zincirinin değeri düşer
      Bir ağ olduğu için sistem, onu manipüle etme girişimlerine karşı kendini ayarlayabilir; ama ne kadar sağlam olacağı hâlâ bir soru
    • Bunun zaten yaşanmadığını nereden biliyoruz?
      Uzun ve içerikli yorumlar genelde ayırt edilebiliyor, ama bu 1-2 yıl öncesine göre çok daha zorlaştı. Kısa, bir iki cümlelik yorumlarda LLM’lerin artık insan gibi geçecek kadar iyi olduğunu düşünüyorum
    • Bizim LLM’lerimiz yalnızca birden çok kaynaktan doğrulanmış sonuçlar verebildiği için insanın ortalama yanıtını üretir
      Buna karşılık HN’deki birçok yorum, ortalama popüler düşünceyle çelişen oldukça özgün içgörülerdir. LLM bunu taklit etmeye çalışırsa yalnızca saçmalık üretecektir
      O saçmalığın üstüne yalnızca makul ve anlamlı yanıtları geçiren bir filtre koyarsanız, cevaplar sıkıcılaşır ve yine saçmalığa yakın kalır
      Yanıtların doğru, kesin ve özgün olması için LLM olmayan bir şey kullanmak gerekir
    • HN’de bu tür şeylere karşı zaten oldukça iyi bir bağışıklık sistemi var. Düşük emekli, tekrarlı yorumlar hızla downvote alır, bildirime uğrar ve hız sınırına takılır
      Sitenin karma ve hız sezgiselleri, gösterişli makine öğrenmesine kıyasla kaba kalır; ama topluluk Reddit veya Twitter’a göre küçük olduğu ve yöneticiler doğrudan müdahale ettiği için işe yarar
      LLM sahte hesap sürüsünün insan metnini “ikame” etmesi için, insanların gerçekten ilginç bulduğu şeyleri sürekli yazması gerekir. Aksi halde çok daha önce sınırlandırılır ya da sessizce kaldırılırlar
      Birkaç AI hesabını hayatta tutsanız bile marjinal maliyet yüksektir. 24 saat boyunca onlarca yeni başlıkta çıkarım çalıştırmak ücretsiz değildir; çıktının sıradan SEO çöpüne kaymamasını sağlamak da şaşırtıcı derecede zordur
      Getirisi de fiilen yoktur. HN trafiğini paraya çeviremezsiniz; karma da bot operatörü için berbat bir para birimidir
      Kaynağı olan inatçı bir kötü niyetli aktör durdurulabilir mi derseniz, muhtemelen evet; ama karşı önlemler bugünkülerle aynı olurdu: güçlü hız sınırları, yeni hesap sınırlarının sıkılaştırılması, insan moderatör incelemesi, belki biraz da üslup analizi
      Meşru yeni kullanıcılar için can sıkıcı olurdu ama ölümcül olmazdı. Sonuçta HN, buradaki insanlar başka insanların yazdıklarını okumak istediği için hayatta kalıyor. Yorumlar olasılıksal papağan gibi gelmeye başlarsa okurlar onları görmezden gelir ya da bildirir; botlar da birbirleriyle konuşur hale gelir
      GPT-3o tarafından yazıldı
    • Metal Gear serisi[0], ölü internet teorisi[1] gibi bu gidişatı zaten öngören şeyler var
      “Metal Gear Solid 2’de Hideo Kojima’nın iddialı senaryosu, bazen postmodern video oyununun ilk örneklerinden biri olarak değerlendirilmiş; ayrıca hakikat-sonrası siyaset, sahte haber, yankı odası ve alternatif gerçekler gibi kavramları öngördüğü de söylenmiştir”
      [0] https://en.wikipedia.org/wiki/Metal_Gear
      [1] https://en.wikipedia.org/wiki/Dead_Internet_theory
  • Önümüzdeki birkaç yıl içinde birçok API’nin yalnızca DuckDB dosyası döndürme seçeneği sunmaya başlayacağını düşünüyorum
    Nasıl olsa JSON’u veritabanına yükleyecekseniz, yanıt olarak veritabanı almamak için bir sebep yok

    • DuckDB 1.2 dosyasından dışa aktarılan zstd Parquet 2-3 kat daha iyi sıkıştırılıyor
  • Yığılmış grafikler kullanılmasa keşke. Okurun izlenimini çarpıtmamalarının neredeyse imkânsız olduğunu düşünüyorum
    Belirli bir veri noktasının yüksekliğini gürültü içinde kestirmek çok zor; ayrıca muhtemelen var olmayan bir bağımlılık ima ediyorlar

    • Benim de ilk aklıma gelen buydu. uPlot’un yazarı, tuzağı iyi gösteren bir demoya sahip: https://leeoniya.github.io/uPlot/demos/stacked-series.html
    • Doğru :( Ama aynı verileri çizgi grafik olarak çizince çok fazla üst üste binme oluyor ve hiçbir şey görmek zorlaşıyordu
      Bir dahaki sefere, her biri bölge başına tek bir seri içeren birden çok çizgi grafiği hizalayıp üst üste dizmeyi düşünüyorum
    • 3D yaklaşımın bu sorunu çözdüğü yer tam burası. Yığıp hafif bir ofset verirseniz, oyun motoru teknolojisini gerçek iş zekâsında kullanarak büyük hacimli veriyi tek seferde anlamak için bundan daha iyisi yok
      https://flowimmersive.com/ çalışmalarına bakabilirsiniz
    • Logaritmik y eksenli yığılmış grafikler hakkında ne düşünüyorsunuz? Bazı fizik deneyleri bunu hep böyle yapıyor[1], ama bana epey sezgisel olmayan bir şey gibi geliyor
      [1]: https://atlas.web.cern.ch/Atlas/GROUPS/PHYSICS/PUBNOTES/ATL-...
  • Daha önce bir tane yapmıştım; https://github.com/ashish01/hn-data-dumps oldukça eğlenceliydi
    Uygulandığında güzel olacak özellik, yeni öğelerin zaman geçtikçe daha sık güncellenmesi nedeniyle, yakın zamanda indirilen öğelerin eski öğelere göre daha hızlı bayat önbelleğe dönüşmesini yansıtmak olurdu

    • HN’nin, birçok başka site gibi kilitlemek yerine böyle bir API sunması gerçekten güzel
      Ben bayatlığı belirlemek için yaşa dayalı bir fonksiyon kullandım. İlk başta oluşturulduktan 1–2 dakika sonra bayat sayıyor, birkaç gün boyunca sık sık yeniliyor, ilk haftadan sonra hızla azaltarak yaklaşık 2 hafta geçince değişmez kabul ediyordum
      // DefaultStaleIf marks stale at 60 seconds after creation, then frequently for the first few days after an item is
      // created, then quickly tapers after the first week to never again mark stale items more than a few weeks old.
      const DefaultStaleIf = "(:now-refreshed)>" +
      "(60.0*(log2(max(0.0,((:now-Time)/60.0))+1.0)+pow(((:now-Time)/(24.0*60.0*60.0)),3)))"
      https://github.com/jasonthorsness/unlurker/blob/main/hn/core...