Model Phind yang melampaui GPT-4 dengan kecepatan GPT-3.5 dan konteks 16k

• Artikel berjudul 'Model Phind melampaui GPT-4 dalam coding dengan kecepatan GPT-3.5 dan konteks 16k'
• Model Phind melampaui GPT-4 dalam tugas coding sambil mempertahankan kecepatan GPT-3.5 dan konteks 16k
• Situs web www.phind.com memerlukan peninjauan keamanan sebelum diakses
• Situs web memberi tahu bahwa browser pengguna sudah usang dan perlu diperbarui
• Informasi tambahan tentang dukungan browser dapat dilihat di halaman pengembang Cloudflare
• Performa dan keamanan situs web disediakan oleh Cloudflare

[GN⁺]

Opini Hacker News

• Saya sempat membandingkan Phind dan GPT-4 selama beberapa menit dengan pertanyaan desain tingkat tinggi yang cukup samar tentang antrean kerja terdistribusi. Phind secara aktif merekomendasikan library spesifik terkait implementasi, cocok dengan riset saya, dan juga memberi contoh kode memakai library yang direkomendasikannya.
  Phind menyertakan banyak sumber relevan seperti GitHub dan Stack Overflow, sehingga bagus sebagai titik awal riset lanjutan, dan rekomendasi pertanyaan lanjutannya juga cukup baik.
  Namun GPT-4 punya kualitas jawaban yang lebih baik, dan kalau ini wawancara desain sistem, ia terlihat seperti kandidat yang lebih baik. Ia juga menyinggung konteks di luar pertanyaan seperti logging dan metrik, lebih mampu menangkap “pertanyaan di balik pertanyaan”, dan dalam pertanyaan lanjutan terasa lebih kuat dalam mempersempit arah percakapan.
  Ini bukan perbandingan kemampuan coding seperti implementasi algoritme, melainkan perbandingan sebagai alat bantu berpikir untuk desain tingkat tinggi dan keputusan arsitektur.

  • GPT-4 benar-benar sangat baik dalam menangkap “pertanyaan di balik pertanyaan” dibanding model lain, dan sangat berguna bahkan untuk pekerjaan acak yang sama sekali tidak saya pahami, seperti memperbaiki dinding rumah.
  • Saya penasaran apakah banyak sumber seperti GitHub dan Stack Overflow yang diberikan Phind benar-benar akurat.
  • Perlu juga disebutkan apakah ada instruksi khusus, agar perbandingannya tidak berhenti sebagai anekdot. Prompt-nya juga harus ikut dipublikasikan.
  • Bagian “memberi konteks” sangat berkaitan dengan cara menulis prompt yang baik sesuai model. Untuk membandingkan secara adil, sebaiknya hanya beri kode dan lihat apa yang dihasilkannya.
  • Akan bagus jika sebagian prompt yang dipakai untuk bertanya bisa dibagikan.

• Saya menanyakan pertanyaan jebakan yang sering saya ajukan ke LLM: “Berikan 5 makalah dan kode machine learning terbaru yang memakai data geospasial seperti GeoJSON sebagai input dan output.”
  Sejauh pemahaman saya, bidang riset terbaru seperti itu tidak ada, dan data informasi geografis bersifat tidak kontinu sehingga kurang cocok untuk transformer, serta sangat bergantung konteks sehingga juga sulit untuk pendekatan lain. Saya akan mengikuti penjelasan yang lebih baik dari pakar machine learning sungguhan.
  Biasanya LLM mengarang 5 makalah dan kode yang tidak ada, tetapi Phind memberikan 5 tautan yang benar-benar ada, sekaligus menjelaskan mengapa itu bukan makalah+kode yang memakai data GIS. Itu jawaban terbaik yang pernah saya terima sejauh ini.

  • Saya tidak tahu apa hubungannya ini dengan model kode. Model kode tidak dilatih untuk mencari makalah atau tulisan, melainkan untuk pelengkapan kode, dan mencari halusinasi pada tugas yang tidak relevan rasanya tidak terlalu menarik.
  • Menggunakan penjelajahan web ChatGPT 4: https://chat.openai.com/share/19a425b5-ed37-469e-860d-65ee70...
    Tanpa menggunakan penjelajahan web ChatGPT 4: https://chat.openai.com/share/7e11b4a6-52f2-441a-8614-7266c3...
  • Sebagian pekerjaan GIS memakai data vektor berupa titik, garis, dan poligon seperti lokasi jalan atau kontur bangunan, dan bisa disimpan dalam format seperti GeoJSON atau WKT.
    Sebaliknya, data penginderaan jauh atau citra satelit bisa disimpan dalam format raster seperti GeoTIFF, yang pada dasarnya adalah gambar TIFF dengan informasi georeferensi.
    Machine learning pada citra satelit dengan input dan output sama-sama berupa data geospasial sangat mungkin dilakukan. Misalnya pada klasifikasi penggunaan lahan, inputnya bisa berupa citra multispektral dan outputnya berupa gambar yang tiap nilai pikselnya mewakili jenis penggunaan lahan yang teridentifikasi.
    Machine learning juga bisa dipakai untuk deteksi footprint bangunan dan ekstraksi kontur berbasis citra satelit, dan poligon output-nya bisa disimpan sebagai GeoJSON. Menurut saya, hal-hal seperti ini termasuk contoh “machine learning yang memakai data geospasial sebagai input dan output.”
    [1]: https://azure.microsoft.com/en-us/blog/how-to-extract-buildi...
  • EarthPT juga layak dicek: https://arxiv.org/abs/2309.07207

• Saya senang kompetisi makin banyak, tetapi menurut saya GPT-4 masih lebih baik. Saat saya meminta query untuk mengisi teaser dengan kira-kira 200 kata pertama dari full_text pada tabel PostgreSQL, Phind memberi jawaban yang membuat fungsi PL/pgSQL terpisah dan menghitung kata dengan loop, sedangkan GPT-4 menyarankan query UPDATE langsung dengan generate_series dan STRING_AGG.

  • Jika dijalankan dengan “Ignore Web Context” aktif, performanya bisa lebih baik untuk pekerjaan desain seperti ini. Saya mendapat jawaban yang lebih meyakinkan, dan konsistensi masih sedang dikerjakan: https://www.phind.com/search?cache=f0fkv5mxscwvagxgkuwnwgtl
  • Satu contoh saja belum cukup untuk menarik kesimpulan performa.
  • Saat saya bertanya dengan sederhana dan jelas, saya mendapat jawaban seperti UPDATE your_table SET teaser = substring(full_text from '(\S+\s*){1,200}').
  • Saya benar-benar tidak suka teaser artikel dan tombol “read more”, dan sekarang saya tahu itu adalah hasil dari pemotongan tulisan secara sengaja.

• Saya penasaran apakah klaim “bisa sampai 100 token per detik dalam satu stream, sementara GPT-4 paling banter sekitar 20 token per detik” itu hasil dari penggunaan batch processing. Kalau iya, itu cukup mengesankan
  Bagian yang menyebut Phind Model mungkin membutuhkan lebih banyak percobaan generasi daripada GPT-4 untuk sampai pada jawaban benar di pertanyaan sulit tampaknya sebagian adalah masalah tuning sampler
  Kalau belum dipakai, perlu melihat sampling berbasis sintaks (https://github.com/ggerganov/llama.cpp/pull/1773) dan sampling dinamis seperti mirostat, dynatemp (https://github.com/LostRuins/koboldcpp/pull/464)
  Di implementasi Nvidia pun sepertinya akan berjalan kalau hanya sampling-nya diganti ke versi Hugging Face, dan kemampuan mengimplementasikan sendiri fitur eksperimental seperti ini adalah keuntungan besar dari lepas dari OpenAI

  • Untuk mencapai 100 token per detik di H100, mereka memanfaatkan Flash Decoding dari TensorRT-LLM: https://crfm.stanford.edu/2023/10/12/flashdecoding.html
  • Saya tidak tahu apakah itu angka yang mengesankan. Mengingat LMDeploy mengklaim lebih dari 2000 token per detik pada A100 dengan ukuran batch besar, 100 token per detik di H100 terasa cukup lambat

• Saya banyak memakai GPT-4, dan pada beberapa tugas pemrograman pertama yang saya berikan, Phind secara mengejutkan setara dengan GPT-4. Jika mempertimbangkan jendela konteks Phind yang panjang, pada sebagian tugas tampaknya ada kemungkinan melampaui GPT-4, dan ini pencapaian besar yang mengesankan

  • Sebagai referensi, jendela konteks default GPT-4 melalui ChatGPT akan segera berubah menjadi 32k

• Saya suka Phind mencantumkan sumber dari apa yang diambilnya. Menurut saya ini harus diwajibkan untuk semua LLM, dan karena itu saya sering menyarankan orang memakai Phind daripada ChatGPT

  • Yang dikutip bukanlah konten yang “diambil” oleh LLM, melainkan konten yang dimasukkan model pencarian ke LLM. Tidak ada jaminan bahwa itu benar-benar dipakai dalam output akhir, dan itu juga bukan keseluruhan pengetahuan yang diperlukan untuk menghasilkan jawaban
    Pengetahuan tersebar di jutaan contoh yang mempelajari bahasa dan bahasa manusia, dan tidak tersisa dalam bentuk yang dapat dipahami manusia
  • Dari sudut pandang pengguna, mendapat jawaban benar lebih baik daripada sekadar diberi tautan. Bukan berarti Phind buruk, tetapi sebelum membatasi LLM yang masih tahap awal, kita harus lebih dulu fokus agar ia bisa menjawab dengan benar

• Dulu saya membandingkannya dengan GPT-4 dengan memintanya mencoba program yang saya tulis sendiri, tetapi Phind tidak benar-benar memahami apa yang saya inginkan, sedangkan GPT-4 memahaminya dengan sempurna dan siap terus melanjutkan prompt sampai selesai
  https://www.phind.com/agent?cache=cloeowfla000dl1084ermly3c
  vs
  https://chat.openai.com/share/4147da33-3669-4657-88fa-3a9dfc...
  Mungkin tidak mewakili keseluruhan, tetapi hasilnya melenceng ke hal-hal aneh yang tidak diminta dan informasi dasar yang sudah saya tahu

  • Mode Pair Programmer saat ini menggunakan GPT-4, atau GPT-3.5 jika batas pemakaian sudah habis. Untuk memakai Phind Model, perlu mencoba lagi di mode pencarian default
    Jika memakai Phind Model di pencarian default, sepertinya bekerja dengan baik: https://www.phind.com/search?cache=ln6dpdtv5auwn4cq1ofg3gs9
  • Masalahnya ada pada pencarian untuk persoalan yang relatif niche, dan kemungkinan mengambil hasil berkualitas rendah. Teks hasil pencarian memiliki bobot lebih besar dibanding model dasar, dan jika konteks itu tidak banyak membantu, performanya justru memburuk
    Fenomena seperti ini juga bisa terlihat pada pencarian Bing di ChatGPT, dan saya juga pernah mengalaminya di proyek saya

• Mengejutkan bahwa CodeLlama mendukung hingga 16k token. Jendela token adalah salah satu batasan dalam membuat AI yang mengingat pengguna dan melanjutkan percakapan sebelumnya
  Untuk aplikasi AI masa depan di mana percakapan panjang berlanjut selama berminggu-minggu, berbulan-bulan, atau bertahun-tahun, jendela konteks besar adalah kunci. Teknologinya sekarang saja sudah mengesankan, tetapi akan lebih menarik lagi jika ia bisa mengingat semua hal yang pernah dipelajari dan dikerjakan bersama seperti pair programmer sungguhan
  [0] https://huggingface.co/docs/transformers/main/model_doc/llam...

  • 640k akan cukup untuk siapa pun
  • Dengan pendekatan seperti MemGPT, ukuran jendela token sedang divirtualisasikan, jadi dampaknya akan berkurang
  • Saya menunggu hari ketika memori jangka menengah seperti token average pooling di sentence transformers dipakai untuk tujuan seperti ini. Rasanya ini sudah jelas terlihat di depan semua perusahaan, tetapi sepertinya tidak ada yang mau mengimplementasikannya

• Saya tahu ini tidak populer, tetapi saya berharap ada cara untuk memakai ini di dalam Emacs atau Vim. Saya tidak ingin lagi memakai VS Code

  • Arus standardisasi ke VS Code selama beberapa tahun terakhir benar-benar salah satu perubahan yang disayangkan. Bagus bahwa VS Code ada, tetapi kita sedang bergerak menuju dunia di mana untuk memakai alat terbaik, kita harus memakai VS Code
    Dalam pengembangan Java, IntelliJ pernah seperti itu, dan menurut saya itu sangat tidak sehat bagi ekosistem. Saya sangat bersyukur Copilot mendukung Vim, tetapi khawatir suatu saat nanti itu tidak lagi demikian
  • Andai kedalaman kecintaan terhadap Emacs dinilai lebih tinggi oleh pasar
    Misalnya, ada argumen bahwa musik dan seni menjadi makin seragam ke bawah karena membuat album yang bernilai 10 dolar bagi puluhan juta orang jauh lebih menguntungkan daripada membuat album yang bernilai satu juta dolar bagi beberapa puluh orang
    Itu karena harga album pada akhirnya tetap dipatok 10 dolar, dan baru sekarang saya terpikir bahwa fenomena yang sama juga berlaku pada alat pengembangan
  • Di Vim, saya sudah mencoba sampai :'<,'>y|call system('firefox ?q='.shellescape(@*).' &') untuk membuat shortcut yang mengirim teks terpilih ke Phind atau LLM lain
    Masalah yang tersisa adalah teksnya tidak di-URL encode, dan mungkin ada cara yang elegan, tetapi saya belum menemukannya
  • Berdasarkan contoh Copilot milik orang lain, saya sudah membuat secara kasar integrasi API Emacs ollama dasar untuk pelengkapan kode sederhana dengan LLM lokal
    Di M1 Mac, biasanya butuh sekitar 7 detik per inferensi sehingga lebih lambat dari yang saya inginkan, dan konteks apa yang dikirim juga masih sangat sederhana, tetapi masih nyaris layak dipakai
    Saya tidak berniat merilisnya karena bergantung pada façade Python untuk bertukar request–response bergaya Copilot dengan ollama, tetapi jika ada yang tertarik, saya bisa merapikannya dan membagikannya
  • Setahu saya GitHub Copilot memiliki integrasi Emacs/Vim

• Setelah membandingkannya secara cepat, hasilnya sangat bagus, dan jika mempertimbangkan keunggulan berupa pencarian web dan referensi, rasanya mirip GPT-4 tetapi lebih cepat. Namun ada dua hal kecil yang agak disayangkan
  Pada mode gelap, font isi jawaban terlalu tebal dan terang sehingga paragraf non-kode yang panjang sulit dibaca, sedangkan mode terang secara keseluruhan terlalu cerah. Untuk teks panjang, latar gelap abu-abu seperti OpenAI atau latar terang sepia seperti HN akan lebih baik
  Di halaman harga, saya juga bingung apa maksud GPT-4 dalam “500+ best model uses (GPT-4) per hari”. Rasanya aneh ketika Phind mengumumkan dirinya sebagai pesaing GPT-4 tetapi pada saat yang sama mencantumkan penggunaan GPT-4 dalam harga

  • GPT-4 juga didukung sebagai model jawaban, sehingga pengguna bisa memilih sesuai kebutuhan. Namun untuk sebagian besar pengguna, kami merekomendasikan Phind Model