1 puan yazan GN⁺ 2023-11-01 | 1 yorum | WhatsApp'ta paylaş
  • 'Phind modeli, GPT-3.5 hızı ve 16k bağlamla kodlamada GPT-4'ün önüne geçiyor' başlıklı makale
  • Phind modeli, GPT-3.5'in hızını ve 16k bağlamını korurken kodlama görevlerinde GPT-4'ü geride bırakıyor
  • www.phind.com web sitesi, erişmeden önce güvenlik incelemesi gerektiriyor
  • Web sitesi, kullanıcının tarayıcısının eski sürüm olduğunu ve güncelleme gerektiğini bildiriyor
  • Tarayıcı desteği hakkında daha fazla bilgi Cloudflare geliştirici sayfasında bulunabilir
  • Web sitesinin performansı ve güvenliği Cloudflare tarafından sağlanıyor

1 yorum

 
GN⁺ 2023-11-01
Hacker News görüşleri
  • Dağıtık iş kuyruğu hakkında oldukça belirsiz, üst düzey bir tasarım sorusuyla Phind ile GPT-4’ü birkaç dakika karşılaştırdım; Phind uygulamayla ilgili somut kütüphaneleri aktif biçimde önerdi, kendi araştırmamla da iyi örtüştü ve önerdiği kütüphaneyle örnek kod da verdi.
    Phind, GitHub, Stack Overflow vb. ilgili kaynakları bolca eklediği için devam araştırması için iyi bir başlangıç noktasıydı; önerdiği takip soruları da oldukça iyiydi.
    Ancak GPT-4’ün yanıt kalitesi daha iyiydi ve bir sistem tasarımı mülakatında daha iyi aday gibi görünürdü. Loglama ve metrikler gibi sorunun dışındaki bağlamları da yakaladı, “sorunun arkasındaki soruyu” daha iyi kavradı ve takip sorularında da sohbetin yönünü daraltarak ilerlediği hissi daha güçlüydü.
    Bu, algoritma uygulama gibi bir kodlama becerisi testi değil; üst düzey tasarım ve mimari kararlar için bir düşünme yardımcı aracı olarak karşılaştırmaydı.

    • GPT-4, diğer modellere kıyasla “sorunun arkasındaki soruyu” gerçekten iyi yakalıyor; ev duvarı onarımı gibi hiç bilmediğim rastgele işlerde bile çok faydalı oldu.
    • Phind’in sağladığı GitHub, Stack Overflow vb. zengin kaynakların gerçekten doğru olup olmadığı merak konusu.
    • Karşılaştırmanın anekdotta kalmaması için özel yönergeler olup olmadığı da belirtilmeli. Prompt da birlikte paylaşılmalı.
    • “Bağlam vermek” kısmı, modele uygun biçimde iyi prompt yazma yöntemiyle büyük ölçüde ilgili. Adil karşılaştırma için sadece kod verip ne ürettiğine bakmak gerekir.
    • Hangi prompt ile sorduğunun bir kısmını paylaşsan iyi olur.
  • LLM’lere sık sorduğum tuzak sorulardan biri olarak, “GeoJSON gibi jeo-uzamsal verileri girdi ve çıktı olarak kullanan 5 güncel makine öğrenimi makalesi ve kodu ver” diye sordum.
    Böyle güncel bir araştırma alanı olmadığını düşünüyorum; coğrafi bilgi verilerinin ayrık olması nedeniyle transformer’lara uygun olmadığını, bağlama bağımlı olduğu için başka yöntemler açısından da zor olduğunu sanıyorum. Gerçek makine öğrenimi uzmanlarının daha iyi açıklamasına elbette uyarım.
    LLM’ler genelde var olmayan 5 makale ve kod uyduruyor; Phind ise gerçekten var olan 5 bağlantı verdi ve bunların neden GIS verisi kullanan makale+kod olmadığını da açıkladı. Şimdiye kadar aldığım en iyi yanıttı.

    • Bunun kod modeliyle ne ilgisi olduğunu bilmiyorum. Kod modeli makale veya yazı aramak üzere değil, kod tamamlama için eğitilmiştir; ilgisiz bir görevde halüsinasyon aramak pek ilginç değil.
    • ChatGPT 4 web tarama kullanılarak: https://chat.openai.com/share/19a425b5-ed37-469e-860d-65ee70...
      ChatGPT 4 web tarama kullanılmadan: https://chat.openai.com/share/7e11b4a6-52f2-441a-8614-7266c3...
    • Bazı GIS çalışmalarında yol konumları veya bina konturları gibi nokta, çizgi ve çokgen vektör verileri kullanılır; bunlar GeoJSON veya WKT gibi biçimlerde saklanabilir.
      Buna karşılık uzaktan algılama verileri veya uydu görüntüleri GeoTIFF gibi raster biçimlerde saklanabilir; bunlar esasen coğrafi referans bilgisi eklenmiş TIFF görüntüleridir.
      Hem girdisi hem çıktısı jeo-uzamsal veri olan uydu görüntüsü makine öğrenimi gayet mümkündür. Örneğin arazi kullanımı sınıflandırmasında girdi çok bantlı görüntü, çıktı ise her piksel değerinin tanımlanan arazi kullanımını gösterdiği bir görüntü olabilir.
      Uydu görüntüsü tabanlı bina footprint tespiti ve kontur çıkarımı için de makine öğrenimi kullanılabilir; çıktı çokgenleri GeoJSON olarak saklanabilir. Bunların “jeo-uzamsal verileri girdi ve çıktı olarak kullanan makine öğrenimi” örnekleri olduğunu düşünüyorum.
      [1]: https://azure.microsoft.com/en-us/blog/how-to-extract-buildi...
    • EarthPT’ye de bakmaya değer: https://arxiv.org/abs/2309.07207
  • Rekabetin artması sevindirici ama bence hâlâ GPT-4 daha iyi. PostgreSQL tablosundaki full_text alanından kabaca ilk 200 kelimeyi teaser alanına dolduran bir sorgu istediğimde, Phind ayrı bir PL/pgSQL fonksiyonu oluşturup döngüyle kelime sayan bir yanıt verdi; GPT-4 ise generate_series ve STRING_AGG ile doğrudan UPDATE yapan bir sorgu önerdi.

    • “Ignore Web Context”i açıp çalıştırırsan bu tür tasarım işlerinde performans daha iyi olabilir. Daha makul bir yanıt aldım; tutarlılık ise üzerinde çalışılan bir konu: https://www.phind.com/search?cache=f0fkv5mxscwvagxgkuwnwgtl
    • Tek bir örnekle performans sonucu çıkarmak için yeterli değil.
    • Basit ve net biçimde sorunca UPDATE your_table SET teaser = substring(full_text from '(\S+\s*){1,200}') gibi bir yanıt aldım.
    • Makale teaser’larından ve “read more” düğmelerinden gerçekten nefret ediyorum; şimdi bunun ilgili yazıyı bilerek kesmenin sonucu olduğunu anlamış oldum.
  • “Tek bir akışta saniyede 100 token’a kadar çıkabiliyor, GPT-4 ise en iyi ihtimalle saniyede 20 token civarında” denmesinin toplu işleme kullanmanın sonucu olup olmadığını merak ediyorum. Öyleyse oldukça etkileyici
    Phind Model’in zor sorularda doğru yanıta ulaşmak için GPT-4’ten daha fazla üretim denemesi gerektirebileceği kısmı, kısmen örnekleyici ayarlama sorunu gibi görünüyor
    Henüz kullanmıyorlarsa dil bilgisi tabanlı örneklemeye (https://github.com/ggerganov/llama.cpp/pull/1773) ve mirostat, dynatemp gibi dinamik örneklemeye (https://github.com/LostRuins/koboldcpp/pull/464) bakmaları gerekir
    Nvidia uygulamasında da yalnızca örnekleme kısmı Hugging Face sürümüyle değiştirilirse çalışacak gibi; bu tür deneysel özellikleri doğrudan uygulayabilmek OpenAI’dan uzaklaşmanın büyük avantajı

    • H100’de saniyede 100 token’a ulaşmak için TensorRT-LLM’in Flash Decoding özelliğinden yararlanıyor: https://crfm.stanford.edu/2023/10/12/flashdecoding.html
    • Bunun etkileyici bir sayı olup olmadığını bilmiyorum. LMDeploy’un A100 ve büyük batch boyutlarında saniyede 2000 token’dan fazlasını iddia ettiğini düşününce, H100’de saniyede 100 token epey yavaş hissettiriyor
  • GPT-4’ü çok kullanıyorum; Phind, ilk verdiğim birkaç programlama görevinde şaşırtıcı şekilde GPT-4 ile başa baştı. Phind’in uzun bağlam penceresi düşünüldüğünde bazı işlerde GPT-4’ü aşma ihtimali de var gibi görünüyor; kayda değer bir başarı ve etkileyici

    • Bu arada ChatGPT üzerinden GPT-4’ün varsayılan bağlam penceresi yakında 32k olacak
  • Phind’in tarayıp getirdiği şeylerin kaynaklarını alıntılaması hoşuma gidiyor. Bence bu tüm LLM’ler için zorunlu olmalı; bu yüzden insanlara sık sık ChatGPT yerine Phind kullanmalarını öneriyorum

    • Alıntılanan şey, LLM’in “taradığı” içerik değil, arama modelinin LLM’e verdiği içerik. Gerçek çıktıda onu kullandığının garantisi yok ve yanıtı üretmek için gereken bilginin tamamı da bu değil
      Bilgi, dili ve insan dilini öğrenmiş milyonlarca örneğe dağılmış durumda; insanın anlayabileceği bir biçimde de kalmış değil
    • Kullanıcı açısından link dökmesindense doğru yanıtı almak daha iyi. Phind kötü demek istemiyorum, ama hâlâ erken aşamada olan LLM’leri kısıtlamadan önce, öncelik onların doğru cevap vermesini sağlamak olmalı
  • Daha önce kendi yazdığım bir programı denetip GPT-4 ile karşılaştırmıştım; Phind ne istediğimi doğru düzgün anlayamadı, GPT-4 ise mükemmel anladı ve prompt’u sürdürerek tamamlamaya hazırdı
    https://www.phind.com/agent?cache=cloeowfla000dl1084ermly3c
    vs
    https://chat.openai.com/share/4147da33-3669-4657-88fa-3a9dfc...
    Geneli temsil etmiyor olabilir, ama istemediğim alakasız konulara ve zaten bildiğim temel bilgilere kaydı

    • Pair Programmer modu şu anda GPT-4’ü, limit dolarsa GPT-3.5’i kullanıyor. Phind Model’i kullanmak için varsayılan arama modunda tekrar denemek gerekiyor
      Varsayılan aramada Phind Model’i kullanınca iyi çalışıyor gibi: https://www.phind.com/search?cache=ln6dpdtv5auwn4cq1ofg3gs9
    • Sorun, nispeten niş bir problemi arayıp muhtemelen düşük kaliteli sonuçlar getirmesinde. Arama metni temel modele kıyasla daha büyük ağırlık taşıyor; o bağlam pek işe yaramıyorsa performans aksine kötüleşiyor
      ChatGPT’nin Bing aramasında da bu olguyu görebilirsiniz; kendi projemde de yaşadım
  • CodeLlama’nın 16k token’a kadar desteklemesi şaşırtıcı. Token penceresi, kullanıcıyı hatırlayan ve geçmiş konuşmaları sürdüren yapay zekalar geliştirmenin kısıtlarından biri
    Haftalar, aylar, yıllar süren uzun sohbetlerin olduğu gelecekteki yapay zeka uygulamalarında büyük bağlam penceresi kilit önemde olacak; teknoloji şu anda da etkileyici, ama geçmişte birlikte öğrendiklerini ve üzerinde çalıştıklarını gerçek bir pair programmer gibi tamamen hatırlayabilir hale gelirse daha da ilginç olacak
    [0] https://huggingface.co/docs/transformers/main/model_doc/llam...

    • 640k herkes için yeterlidir
    • MemGPT gibi yaklaşımlarla token penceresi boyutu sanallaştırılıyor; dolayısıyla etkisi azalacak
    • sentence transformers’daki token ortalama havuzlama gibi orta vadeli belleğin bu amaçla kullanılacağı günü bekliyorum. Bu, tüm şirketlerin gözünün önünde apaçık duruyor gibi, ama kimse uygulamaya niyetli görünmüyor
  • Popüler olmadığını biliyorum ama bunu Emacs veya Vim içinde kullanmanın bir yolu olsa keşke. Artık VS Code kullanmak istemiyorum.

    • Son birkaç yılda VS Code’un standart hâline gelmesi gerçekten üzücü değişimlerden biri. VS Code’un var olması iyi, ama en iyi araçları kullanmak için VS Code kullanmak zorunda olduğumuz bir dünyaya gidiyoruz.
      Java geliştirmede IntelliJ’de de böyle olmuştu ve bunun ekosistem için pek sağlıklı olmadığını düşünüyorum. Copilot’ın Vim’i desteklemesine gerçekten seviniyorum ama yakında bunun değişmesinden endişe ediyorum.
    • Emacs’e duyulan sevginin derinliği piyasada daha fazla değer görseydi keşke.
      Örneğin, onlarca kişi için bir milyon dolar değerinde bir albüm yapmak yerine, on milyonlarca kişi için 10 dolar değerinde bir albüm yapmanın çok daha kârlı olması yüzünden müzik ve sanatın aşağıya doğru ortalamaya çekildiği yönünde bir argüman var.
      Çünkü albümün fiyatı sonuçta 10 dolar olarak belirleniyor; aynı olgunun geliştirici araçları için de geçerli olduğunu ancak şimdi fark ettim.
    • Vim’de seçili metni Phind’e veya başka bir LLM’e gönderen bir kısayol yapmak için :'<,'>y|call system('firefox ?q='.shellescape(@*).' &') noktasına kadar geldim.
      Geriye kalan sorun, metnin URL encode edilmemesi; muhtemelen zarif bir yolu vardır ama henüz bulamadım.
    • Başkasının Copilot örneğine dayanarak, yerel bir LLM için basit kod tamamlama yapan temel bir Emacs ollama API entegrasyonunu kabaca hazırladım.
      M1 Mac’te çıkarım başına genelde yaklaşık 7 saniye sürüyor; istediğimden yavaş ve hangi bağlamın gönderileceği de çok basit, ama yine de zar zor kullanılabilir düzeyde.
      Copilot tarzı istek/yanıtları ollama ile alıp vermek için bir Python façade’ına dayandığından yayımlamayı düşünmemiştim; ama ilgi olursa elden geçirip paylaşabilirim.
    • Bildiğim kadarıyla GitHub Copilot’ın Emacs/Vim entegrasyonu var.
  • Hızlıca karşılaştırınca sonuçlar harika; web araması ve referanslar eklenmesini de düşününce GPT-4’e benzer ama daha hızlı. Yine de iki küçük eksik var.
    Koyu modda yanıt gövdesinin yazı tipi fazla kalın ve parlak olduğu için uzun kod dışı paragrafları okumak zor; açık mod ise genel olarak fazla parlak. Uzun metinler için OpenAI’daki gibi gri koyu arka plan ya da HN’deki gibi sepya açık arka plan daha iyi olurdu.
    Fiyatlandırma sayfasındaki “günde 500+ best model uses (GPT-4)” ifadesinde GPT-4’ün ne anlama geldiği de kafa karıştırıyor. Phind’in GPT-4 rakibi olduğunu duyururken aynı anda fiyatlandırmada GPT-4 kullanımını belirtmesi tuhaf geliyor.

    • Yanıt modeli olarak GPT-4 de destekleniyor; kullanıcılar kullanım amacına göre seçim yapabiliyor. Yine de kullanıcıların büyük çoğunluğuna Phind Model öneriliyor.