โมเดล Phind ที่เหนือกว่า GPT-4 สำหรับงานเขียนโค้ด ด้วยความเร็วระดับ GPT-3.5 และคอนเท็กซ์ 16k

 (phind.com)
1 คะแนน โดย GN⁺ 2023-11-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บทความหัวข้อ 'โมเดล Phind เหนือกว่า GPT-4 ในงานเขียนโค้ด ด้วยความเร็วระดับ GPT-3.5 และคอนเท็กซ์ 16k'
  • โมเดล Phind เหนือกว่า GPT-4 ในงานเขียนโค้ด โดยยังคงความเร็วระดับ GPT-3.5 และคอนเท็กซ์ 16k
  • เว็บไซต์ www.phind.com ควรตรวจสอบด้านความปลอดภัยก่อนเข้าใช้งาน
  • เว็บไซต์แจ้งว่าบราว์เซอร์ของผู้ใช้เป็นเวอร์ชันเก่าและควรอัปเดต
  • สามารถดูข้อมูลเพิ่มเติมเกี่ยวกับการรองรับบราว์เซอร์ได้ที่หน้าเว็บนักพัฒนาของ Cloudflare
  • ประสิทธิภาพและความปลอดภัยของเว็บไซต์ให้บริการโดย Cloudflare

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-11-01
ความคิดเห็นจาก Hacker News

  • ลองเปรียบเทียบ Phind กับ GPT-4 อยู่ไม่กี่นาทีด้วยคำถามเชิงออกแบบระดับสูงที่ค่อนข้างกำกวมเกี่ยวกับ distributed work queue แล้วพบว่า Phind แนะนำไลบรารีเฉพาะที่เกี่ยวกับการนำไปใช้งานอย่างเชิงรุก ซึ่งก็สอดคล้องกับสิ่งที่ฉันค้นมา และยังให้โค้ดตัวอย่างโดยใช้ไลบรารีที่แนะนำด้วย
    Phind ยังแนบแหล่งอ้างอิงที่เกี่ยวข้องอย่าง GitHub, Stack Overflow ฯลฯ มาอย่างมากมาย จึงเหมาะจะใช้เป็นจุดเริ่มต้นสำหรับการค้นต่อ และคำแนะนำคำถามติดตามก็ทำได้ค่อนข้างดี
    อย่างไรก็ตาม GPT-4 ให้คุณภาพคำตอบที่ดีกว่า และถ้าเป็นการสัมภาษณ์ออกแบบระบบก็ดูจะเป็นตัวเลือกที่ดีกว่า มันชี้ไปถึงบริบทนอกเหนือจากคำถาม เช่น logging และ metrics เข้าใจ “คำถามที่ซ่อนอยู่หลังคำถาม” ได้ดีกว่า และในคำถามต่อเนื่องก็ให้ความรู้สึกว่าค่อย ๆ บีบกรอบทิศทางของบทสนทนาให้แคบลงได้ดีกว่า
    นี่ไม่ใช่การเปรียบเทียบในฐานะแบบทดสอบความสามารถเขียนโค้ดอย่างการ implement อัลกอริทึม แต่เป็นการเปรียบเทียบในฐานะ เครื่องมือช่วยคิด สำหรับการออกแบบระดับสูงและการตัดสินใจด้านสถาปัตยกรรม

    • GPT-4 เก่งมากในการจับ “คำถามที่ซ่อนอยู่หลังคำถาม” เมื่อเทียบกับโมเดลอื่น และมีประโยชน์มากแม้กับงานสุ่มที่ไม่เคยรู้อะไรมาก่อนเลย เช่น ซ่อมผนังบ้าน
    • อยากรู้ว่าแหล่งอ้างอิงจำนวนมากอย่าง GitHub, Stack Overflow ฯลฯ ที่ Phind ให้มานั้น แม่นยำจริงหรือไม่
    • ควรเปิดเผยด้วยว่ามี custom instruction หรือไม่ เพื่อให้การเปรียบเทียบไม่เป็นแค่เรื่องเล่าเฉพาะกรณี ควรโพสต์พรอมป์ต์มาด้วย
    • ส่วนที่ว่า “ให้บริบท” นั้นเกี่ยวข้องอย่างมากกับการ เขียนพรอมป์ต์ให้เหมาะกับโมเดล ถ้าจะเทียบอย่างยุติธรรมควรให้แค่โค้ดแล้วดูว่ามันสร้างอะไรออกมา
    • ถ้าแชร์บางส่วนของพรอมป์ต์ที่ใช้ถามก็น่าจะดี

  • มีคำถามหลอกที่ชอบถาม LLM บ่อย ๆ คือ “ขอ paper และโค้ดแมชชีนเลิร์นนิงล่าสุด 5 ชิ้นที่ใช้ข้อมูลภูมิสารสนเทศอย่าง GeoJSON ทั้งเป็นอินพุตและเอาต์พุต”
    ฉันเข้าใจว่า ไม่มีสาขาวิจัยล่าสุดแบบนั้นอยู่จริง และมองว่าข้อมูลภูมิสารสนเทศนั้นไม่ต่อเนื่องจึงไม่เหมาะกับทรานส์ฟอร์เมอร์ และยังพึ่งพาบริบทสูงจนยากกับวิธีอื่นด้วย ถ้ามีคำอธิบายที่ดีกว่าจากผู้เชี่ยวชาญแมชชีนเลิร์นนิงจริง ๆ ฉันก็พร้อมเชื่อตามนั้น
    ปกติ LLM มักแต่ง paper/โค้ดที่ไม่มีอยู่จริงขึ้นมา 5 ชิ้น แต่ Phind ให้ลิงก์ที่มีอยู่จริง 5 อัน พร้อมอธิบายว่าทำไมสิ่งเหล่านั้นจึงไม่ใช่ paper+code ที่ใช้ข้อมูล GIS ด้วย และนั่นเป็นคำตอบที่ดีที่สุดเท่าที่เคยได้รับมา

    • ไม่เข้าใจว่านี่เกี่ยวอะไรกับ โมเดลโค้ด โมเดลโค้ดไม่ได้ถูกฝึกมาให้ค้น paper หรือบทความ แต่มีไว้สำหรับการเติมโค้ด การไปหาภาพหลอนในงานที่ไม่เกี่ยวข้องจึงไม่ค่อยน่าสนใจนัก
    • ใช้ ChatGPT 4 พร้อมเว็บบราวซิง: https://chat.openai.com/share/19a425b5-ed37-469e-860d-65ee70...
      ใช้ ChatGPT 4 โดยไม่เปิดเว็บบราวซิง: https://chat.openai.com/share/7e11b4a6-52f2-441a-8614-7266c3...
    • งาน GIS บางประเภทใช้ ข้อมูลเวกเตอร์ ที่เป็นจุด เส้น และรูปหลายเหลี่ยม เช่น ตำแหน่งถนนหรือขอบเขตอาคาร และสามารถเก็บในรูปแบบอย่าง GeoJSON หรือ WKT ได้
      ส่วนข้อมูลรีโมตเซนซิงหรือภาพถ่ายดาวเทียมอาจถูกเก็บในรูปแบบแรสเตอร์อย่าง GeoTIFF ซึ่งโดยพื้นฐานแล้วคือภาพ TIFF ที่มีข้อมูลอ้างอิงเชิงภูมิศาสตร์แนบมา
      งานแมชชีนเลิร์นนิงกับภาพถ่ายดาวเทียมที่ทั้งอินพุตและเอาต์พุตเป็นข้อมูลภูมิสารสนเทศนั้นทำได้แน่นอน เช่น ในการจำแนกการใช้ประโยชน์ที่ดิน อินพุตอาจเป็นภาพหลายช่วงคลื่น และเอาต์พุตอาจเป็นภาพที่ค่าของแต่ละพิกเซลแสดงประเภทการใช้ที่ดินที่ระบุได้
      การใช้แมชชีนเลิร์นนิงกับ การตรวจจับ footprint ของอาคารและการดึงเส้นขอบ จากภาพถ่ายดาวเทียมก็ทำได้ และผลลัพธ์ที่เป็นรูปหลายเหลี่ยมก็สามารถบันทึกเป็น GeoJSON ได้ สิ่งเหล่านี้จึงน่าจะเข้าข่ายตัวอย่างของ “แมชชีนเลิร์นนิงที่ใช้ข้อมูลภูมิสารสนเทศเป็นทั้งอินพุตและเอาต์พุต”
      [1]: https://azure.microsoft.com/en-us/blog/how-to-extract-buildi...
    • EarthPT ก็น่าลองดูเช่นกัน: https://arxiv.org/abs/2309.07207

  • ยินดีที่มีการแข่งขันเพิ่มขึ้น แต่ตอนนี้ยังมองว่า GPT-4 ดีกว่า ตอนขอคิวรีสำหรับเติม teaser จากประมาณ 200 คำแรกใน full_text ของตาราง PostgreSQL นั้น Phind ให้คำตอบเป็นการสร้างฟังก์ชัน PL/pgSQL แยกต่างหากเพื่อวนลูปนับคำ ขณะที่ GPT-4 เสนอคิวรี UPDATE ตรง ๆ โดยใช้ generate_series และ STRING_AGG

    • ถ้าเปิด “Ignore Web Context” แล้วรัน งานออกแบบแบบนี้อาจทำได้ดีขึ้น ได้คำตอบที่ดูสมเหตุสมผลกว่า และตอนนี้กำลังปรับปรุงเรื่อง ความสม่ำเสมอ อยู่: https://www.phind.com/search?cache=f0fkv5mxscwvagxgkuwnwgtl
    • ตัวอย่างเดียวไม่พอจะสรุป ประสิทธิภาพ
    • พอถามให้สั้นและชัดเจน ก็ได้คำตอบประมาณ UPDATE your_table SET teaser = substring(full_text from '(\\S+\\s*){1,200}')
    • ฉันเกลียด article teaser กับปุ่ม “read more” มากจริง ๆ และตอนนี้ก็ได้รู้แล้วว่านั่นคือผลจากการตัดข้อความออกโดยตั้งใจ

  • สงสัยว่าที่บอกว่า “ทำได้ถึง 100 โทเค็นต่อวินาทีในสตรีมเดี่ยว และ GPT-4 อย่างมากก็ราว 20 โทเค็นต่อวินาที” เป็นผลจากการใช้ batch processing หรือเปล่า ถ้าใช่ก็น่าประทับใจมาก
    ส่วนที่บอกว่า Phind Model อาจต้องลองสร้างคำตอบมากกว่า GPT-4 เพื่อไปให้ถึงคำตอบที่ถูกในคำถามยาก ๆ ดูเหมือนบางส่วนจะเป็นปัญหาเรื่องการจูน sampler
    ถ้ายังไม่ได้ใช้ ก็ควรดู grammar-based sampling(https://github.com/ggerganov/llama.cpp/pull/1773) กับ dynamic sampling อย่าง mirostat, dynatemp(https://github.com/LostRuins/koboldcpp/pull/464)
    แม้แต่ใน implementation ของ Nvidia ก็น่าจะใช้ได้ถ้าเปลี่ยนเฉพาะ sampling ไปเป็นเวอร์ชันของ Hugging Face และการที่สามารถลงมือทำฟีเจอร์ทดลองแบบนี้ได้เองคือ ข้อดีใหญ่ของการไม่ต้องพึ่ง OpenAI

    • ใช้ Flash Decoding ของ TensorRT-LLM เพื่อให้ได้ 100 โทเค็นต่อวินาทีบน H100: https://crfm.stanford.edu/2023/10/12/flashdecoding.html
    • ไม่แน่ใจว่านั่นเป็นตัวเลขที่น่าประทับใจไหม ถ้าคิดถึงที่ LMDeploy เคลมว่าได้มากกว่า 2000 โทเค็นต่อวินาทีบน A100 กับ batch size ใหญ่ ๆ แล้ว 100 โทเค็นต่อวินาที บน H100 ก็ดูค่อนข้างช้า

  • ใช้ GPT-4 เยอะมาก และ Phind ก็น่าประหลาดใจที่ทำได้สูสีกับ GPT-4 ในหลายงานเขียนโปรแกรมที่โยนให้ตั้งแต่แรก พอคิดถึง หน้าต่างบริบทที่ยาว ของ Phind แล้ว ก็ดูมีโอกาสที่ในบางงานจะเหนือกว่า GPT-4 ได้ด้วย ถือเป็นผลงานที่น่าประทับใจมาก

    • อนึ่ง หน้าต่างบริบท มาตรฐานของ GPT-4 ผ่าน ChatGPT กำลังจะเปลี่ยนเป็น 32k ในไม่ช้า

  • ชอบที่ Phind อ้างอิงแหล่งที่มา ของสิ่งที่ดึงมาใช้ คิดว่าควรบังคับให้ LLM ทุกตัวทำแบบนี้ และนี่ก็เป็นเหตุผลที่มักแนะนำให้ใช้ Phind มากกว่า ChatGPT

    • สิ่งที่ถูกอ้างอิงไม่ใช่เนื้อหาที่ LLM “ไปกวาดมา” แต่เป็นเนื้อหาที่ โมเดลค้นหา ใส่ให้ LLM ต่างหาก ไม่มีอะไรรับประกันว่ามันถูกใช้จริงในผลลัพธ์ และมันก็ไม่ใช่ความรู้ทั้งหมดที่จำเป็นต่อการสร้างคำตอบ
      ความรู้ถูกกระจายอยู่ในตัวอย่างหลายล้านชุดของภาษาและภาษามนุษย์ที่มันเรียนมา และก็ไม่ได้คงอยู่ในรูปแบบที่มนุษย์เข้าใจได้ด้วย
    • ในมุมผู้ใช้ การ ได้คำตอบที่ถูกต้อง สำคัญกว่าการคายลิงก์ออกมา ไม่ได้แปลว่า Phind แย่ แต่ก่อนจะไปจำกัด LLM ที่ยังอยู่ในช่วงเริ่มต้น ก็ควรโฟกัสให้มันตอบถูกจริง ๆ ก่อน

  • เคยลองให้มันใช้งานโปรแกรมที่เขียนเองแล้วเทียบกับ GPT-4 ปรากฏว่า Phind ไม่เข้าใจสิ่งที่ฉันต้องการอย่างถูกต้อง แต่ GPT-4 เข้าใจครบถ้วนและพร้อมจะทำต่อผ่านพรอมป์ต์ถัด ๆ ไปจนเสร็จ
    https://www.phind.com/agent?cache=cloeowfla000dl1084ermly3c
    vs
    https://chat.openai.com/share/4147da33-3669-4657-88fa-3a9dfc...
    มันอาจไม่ใช่ตัวแทนของภาพรวมทั้งหมด แต่คำตอบกลับไหลไปสู่เรื่องแปลก ๆ ที่ไม่ได้ขอ และข้อมูลพื้นฐานที่รู้อยู่แล้ว

    • ตอนนี้โหมด Pair Programmer ใช้ GPT-4 หรือถ้าใช้โควตาหมดก็จะใช้ GPT-3.5 ถ้าจะใช้ Phind Model ต้องลองใหม่ในโหมดค้นหาแบบปกติ
      ถ้าใช้ Phind Model ในการค้นหาแบบปกติ ดูเหมือนจะทำงานได้ดี: https://www.phind.com/search?cache=ln6dpdtv5auwn4cq1ofg3gs9
    • ปัญหาคือมันค้นหาเรื่องที่ค่อนข้างเฉพาะทาง และอาจดึงผลลัพธ์คุณภาพต่ำกลับมา โดยข้อความจากการค้นหามีน้ำหนักมากกว่าโมเดลพื้นฐานอยู่แล้ว ดังนั้นถ้าบริบทนั้นไม่ค่อยช่วย ก็ยิ่งทำให้ประสิทธิภาพแย่ลง
      เห็นอาการแบบเดียวกันนี้ได้ใน Bing search ของ ChatGPT และฉันก็เคยเจอกับโปรเจกต์ของตัวเองด้วย

  • น่าทึ่งที่ CodeLlama รองรับได้ถึง 16k โทเค็น หน้าต่างโทเค็นเป็นหนึ่งในข้อจำกัดของการสร้าง AI ที่จดจำผู้ใช้และสานต่อบทสนทนาในอดีตได้
    สำหรับแอป AI ในอนาคตที่มีบทสนทนายาวต่อเนื่องกันเป็นสัปดาห์ เป็นเดือน หรือเป็นปี หน้าต่างบริบทขนาดใหญ่จะเป็นหัวใจสำคัญ และถึงตอนนี้เทคโนโลยีก็น่าประทับใจอยู่แล้ว แต่จะยิ่งน่าสนใจขึ้นมากถ้ามันจำได้เหมือน pair programmer จริง ๆ ว่าเคยเรียนรู้อะไรร่วมกันและเคยทำอะไรด้วยกันมาก่อน
    [0] https://huggingface.co/docs/transformers/main/model_doc/llam...

    • 640k ก็น่าจะพอสำหรับทุกคนแล้ว
    • ขนาดของ หน้าต่างโทเค็น กำลังถูก virtualize ด้วยแนวทางแบบ MemGPT ดังนั้นผลกระทบของมันน่าจะลดลง
    • กำลังรอวันที่ หน่วยความจำระยะกลาง แบบ mean pooling ของโทเค็นใน sentence transformers จะถูกนำมาใช้กับงานลักษณะนี้ มันดูเป็นอะไรที่ชัดเจนมากสำหรับทุกบริษัท แต่กลับเหมือนไม่มีใครคิดจะลงมือทำ

  • แม้จะรู้ว่าไม่ค่อยเป็นที่นิยม แต่ก็อยากให้มีวิธีใช้สิ่งนี้ใน Emacs หรือ Vim ได้บ้าง ไม่อยากใช้ VS Code อีกแล้ว

    • กระแสที่ทุกอย่างค่อย ๆ ถูกทำให้เป็นมาตรฐานด้วย VS Code ในช่วงหลายปีมานี้เป็นหนึ่งในการเปลี่ยนแปลงที่น่าเสียดายมาก การมี VS Code อยู่ก็เป็นเรื่องดี แต่โลกกำลังไปในทางที่ถ้าอยากใช้เครื่องมือที่ดีที่สุดก็ต้องใช้ VS Code
      ตอนพัฒนา Java ก็เคยเป็นแบบนั้นกับ IntelliJ และผมมองว่าไม่ดีต่อ ecosystem อย่างมาก โชคดีจริง ๆ ที่ Copilot รองรับ Vim แต่ก็อดกังวลไม่ได้ว่าสักวันอาจจะไม่เป็นแบบนั้น
    • อยากให้ความรักอันลึกซึ้งที่มีต่อ Emacs ถูกตลาดให้คุณค่ามากกว่านี้
      ยกตัวอย่างเช่น มีเหตุผลที่บอกว่าดนตรีและศิลปะถูกทำให้มาตรฐานต่ำลง เพราะการทำอัลบั้มที่มีมูลค่า 10 ดอลลาร์สำหรับคนหลายสิบล้านคนนั้นทำเงินได้มากกว่าการทำอัลบั้มที่มีมูลค่า 1 ล้านดอลลาร์สำหรับคนไม่กี่สิบคน
      เพราะสุดท้ายราคาอัลบั้มก็ถูกตั้งไว้ที่ 10 ดอลลาร์อยู่ดี และเพิ่งมานึกได้ว่าปรากฏการณ์เดียวกันนี้ก็ใช้ได้กับ เครื่องมือพัฒนา เช่นกัน
    • ลองทำคีย์ลัดใน Vim เพื่อส่งข้อความที่เลือกไปให้ Phind หรือ LLM อื่น ๆ โดยไปได้ถึงขั้น :'<,'>y|call system('firefox ?q='.shellescape(@*).' &') แล้ว
      ปัญหาที่เหลือคือข้อความยังไม่ได้ถูก URL encoding และน่าจะมีวิธีที่เรียบร้อยกว่านี้ แต่ยังหาไม่เจอ
    • อาศัยตัวอย่าง Copilot ของคนอื่น ผมเลยทำ การเชื่อมต่อ Emacs กับ ollama API แบบพื้นฐาน ๆ สำหรับ code completion อย่างง่ายกับ local LLM เอาไว้คร่าว ๆ
      บน M1 Mac ใช้เวลาประมาณ 7 วินาทีต่อการ inference ซึ่งช้ากว่าที่อยากได้ และการส่ง context ก็ยังเรียบง่ายมาก แต่ก็ยังพอใช้งานได้แบบเฉียด ๆ
      เดิมทีไม่คิดจะปล่อย เพราะต้องพึ่ง Python façade เพื่อรับส่งคำขอ/คำตอบแบบสไตล์ Copilot กับ ollama แต่ถ้ามีคนสนใจก็พอจะขัดเกลาแล้วปล่อยได้
    • เท่าที่ทราบ GitHub Copilot มี integration กับ Emacs/Vim อยู่

  • ลองเทียบแบบเร็ว ๆ แล้ว ผลลัพธ์ยอดเยี่ยมมาก และเมื่อคำนึงถึงข้อดีที่มี การค้นเว็บและการอ้างอิง แนบมาด้วย ก็ให้ความรู้สึกใกล้เคียง GPT-4 แต่เร็วกว่า อย่างไรก็ตามมีจุดติดใจเล็กน้อยสองอย่าง
    โหมดมืดใช้ฟอนต์ในเนื้อหาคำตอบที่หนาและสว่างเกินไป ทำให้อ่านย่อหน้ายาว ๆ ที่ไม่ใช่โค้ดได้ยาก ส่วนโหมดสว่างก็สว่างเกินไปโดยรวม สำหรับข้อความยาว ๆ พื้นหลังมืดโทนเทาแบบ OpenAI หรือพื้นหลังสว่างโทนเซเปียแบบ HN น่าจะดีกว่า
    และในหน้าราคา ข้อความ “ต่อวัน 500+ best model uses (GPT-4)” ก็ทำให้สับสนว่า GPT-4 หมายถึงอะไร การที่ Phind ประกาศว่าตัวเองเป็นคู่แข่งของ GPT-4 แต่ขณะเดียวกันก็ใส่ปริมาณการใช้ GPT-4 ไว้ในราคาดูแปลก ๆ

    • รองรับ GPT-4 เป็นโมเดลสำหรับตอบด้วย ดังนั้นผู้ใช้จึงเลือกให้เหมาะกับงานได้ แต่สำหรับผู้ใช้ส่วนใหญ่ แนะนำ Phind Model