Vibe Coding - ไวบ์โค้ดดิ้ง

 (x.com/karpathy)
3 คะแนน โดย GN⁺ 2025-02-04 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Andrej Karpathy กล่าวถึง vibe coding ว่าเป็นวิธีใหม่ในการสร้างโค้ด โดยแทบไม่ต้องใส่ใจกับตัวโค้ดเอง เมื่อ LLM ดีพอแล้ว
  • ใช้ Cursor Composer ร่วมกับ Sonnet และการป้อนข้อมูลด้วยเสียงผ่าน SuperWhisper เพื่อ บอกความต้องการด้วยคำพูด โดยแทบไม่ใช้คีย์บอร์ด
  • แม้แต่คำขอเล็กน้อยอย่างลด padding ลงครึ่งหนึ่ง ก็ปล่อยให้เครื่องมือจัดการแทนการค้นหาเอง และกด Accept All โดยไม่อ่าน diff
  • คัดลอกข้อความ error แล้ววางกลับไปโดยไม่อธิบาย และหาก LLM แก้บั๊กไม่ได้ ก็เลี่ยงปัญหาหรือสั่งแก้แบบสุ่มซ้ำ ๆ จนปัญหาหายไป
  • ใช้ได้พอสมควรกับโปรเจกต์ใช้ครั้งเดียวช่วงสุดสัปดาห์ แต่โค้ดอาจขยายใหญ่เกินขอบเขตที่เข้าใจได้ จึงใกล้เคียงกับการดู พูด สั่งรัน และคัดลอกวาง มากกว่าการเขียนโค้ด

วิธีทำงานของ “vibe coding”

  • vibe coding คือแนวทางที่ฝากทุกอย่างไว้กับ LLM แทบจะถึงขั้นลืมไปว่ามีโค้ดอยู่
  • ตัวอย่างเครื่องมือคือ Cursor Composer with Sonnet และใช้ SuperWhisper สำหรับการป้อนข้อมูลด้วยเสียง
  • แทนที่จะค้นหาหรือแก้โค้ดเอง จะทำซ้ำตามลำดับนี้
    • ดูการเปลี่ยนแปลงที่ต้องการจากหน้าจอ
    • บอกคำขอกับ Composer ด้วยเสียงพูด
    • รันผลลัพธ์
    • คัดลอกข้อความ error แล้ววางกลับไป
  • ไม่อ่าน diff อีกต่อไป และกด Accept All เสมอ
  • เมื่อโค้ดใหญ่เกินระดับความเข้าใจตามปกติ จะกลายเป็นสภาวะที่ต้องใช้เวลาอ่านโค้ดอยู่พักหนึ่งเพื่อให้เข้าใจจริง ๆ

ข้อจำกัดและตัวอย่าง

  • บางครั้ง LLM ก็แก้บั๊กไม่ได้
    • ในกรณีนี้จะเลี่ยงบั๊ก
    • หรือขอให้เปลี่ยนแบบสุ่มต่อไปเรื่อย ๆ จนกว่าปัญหาจะหายไป
  • ประเมินว่าวิธีนี้ไม่เลวสำหรับ throwaway weekend projects
  • เขายังสร้างเกม Battleship ได้ด้วย vibe coding ประมาณหนึ่งชั่วโมง
    • เป็นรูปแบบที่โมเดล LLM สองตัวใด ๆ ที่ผู้ใช้เลือก ต่อสู้กันแบบเรียลไทม์
    • ยังไม่มีสถิติที่หนักแน่น แต่กล่าวว่า 4o ดูเหมือนจะชนะ 4o-mini

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

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

 
GN⁺ 2025-02-04
ความคิดเห็นจาก Hacker News

  • ลองใช้เองแล้วถือว่าค่อนข้างดี แต่ต้องระวัง ภาพหลอน ให้มาก
    ตัวอย่างเช่น ผมให้มันเขียนรายงานแนะนำตัวผม 500 คำ แล้วพบข้อผิดพลาดอย่างน้อย 3 จุด มันบอกว่าผมมีชื่อเสียงบน Stack Overflow 47,000 คะแนน แต่ความจริงคือมันสับสนระหว่าง "จำนวนคนที่เข้าถึง 47k" ในโปรไฟล์กับชื่อเสียง 525 คะแนน อีกทั้งยังอ้างว่าผมเคยตอบเรื่อง PHP monkey-patching แต่จริง ๆ แล้วนั่นเป็นคำถามที่ผมถามไว้เมื่อ 15 ปีก่อน และคนตอบเป็นคนอื่น สุดท้ายแม้แต่คำพูดอ้างอิงจากบทสัมภาษณ์ก็ไม่ใช่ของผม แต่เป็นของพี่ชายที่ร่วมก่อตั้งบริษัทด้วยกัน
    ใช้เป็นจุดเริ่มต้นได้ แต่ผลลัพธ์ต้อง ตรวจสอบโดยไล่ตามลิงก์แหล่งที่มา ทุกครั้ง

    • การบอกว่า “ค่อนข้างดีแต่ระวังภาพหลอน” เป็นการมองปัญหาเบาเกินไป เราคงไม่จ้างหรือจ้างต่อคนที่แต่งเรื่องมั่ว ๆ ได้ขนาดนี้ แล้วทำไมเครื่องมือ “AI” แบบนี้ถึงถูกมองว่าเป็นอะไรที่มากกว่าโปรเจ็กต์วิจัยน่าสนใจได้ ผมรู้สึกว่าเราควรส่งโมเดลภาษาขนาดใหญ่กลับไปที่ขั้นออกแบบใหม่ จนกว่าจะมีความน่าเชื่อถือในระดับหนึ่งไม่ใช่หรือ
    • ผมไม่ค่อยเห็นว่านี่จะเป็นจุดเริ่มต้นที่มีประโยชน์ แม้จะมองในแง่บวกต่อ AI ก็ตาม รายงานที่เต็มไปด้วย ข้อผิดพลาดข้อเท็จจริง แบบที่แม้แต่เด็กฝึกงานที่รอบคอบยังไม่ทำ ยังแย่กว่าของที่ไร้ประโยชน์เสียอีก
      ถ้าส่วนที่ยากคือการเขียนประโยค สู้ค้นคว้าเองแล้วเขียนโครงก่อน จากนั้นค่อยให้โมเดลภาษาขนาดใหญ่แปลงเป็นประโยคสมบูรณ์ยังจะเร็วกว่า แต่พอทำแบบนั้นก็เท่ากับพิสูจน์ว่าสไตล์ร้อยแก้วคือส่วนที่มีมูลค่าน้อยในงาน ซึ่งในฐานะคนที่เคยเรียนวรรณคดีอังกฤษมันเจ็บปวด แต่ก็น่าจะจริงเป็นส่วนใหญ่
    • ผมสงสัยว่าระหว่างการเขียนรายงาน 500 คำเองตั้งแต่ต้น กับให้ AI เขียนแล้วค่อย ตรวจสอบข้อเท็จจริง ทุกคำตอบและแก้มือทีละจุด อะไรจะเร็วกว่ากัน เพราะงั้นงานที่ต้องการ “คำตอบถูกต้อง” ผมจึงไม่ใช้ AI ผมใช้มันแค่ช่วยเรียบเรียงย่อหน้าหรือประโยคให้อ่านดีขึ้น แต่ไม่เชื่อข้อมูลที่ AI ให้มาโดยตรง
    • การจำผิดว่า “ผมเคยตอบใน Stack Overflow” แทบจะเหมือน ภาวะสมองเสื่อมเทียม
      มีหลายที่ที่ปล่อยของออกมาเร็วกว่าความสามารถที่จะเปิดตัวผลิตภัณฑ์ให้ดีจริง ๆ มาก และผมก็ไม่แน่ใจว่าการป้องกันทางกฎหมายจะแน่นหนาขนาดนั้นหรือเปล่า อย่างไรก็ตาม เอาต์พุตที่มีฐานข้อมูลช่วยกำกับสามารถและควรจะจำกัดอาการจำผิดแบบนี้ได้มาก จำเป็นต้องมีการตรวจสอบแบบเป็นเส้นตรงที่คล้ายมนุษย์ คือคิดไอเดียก่อนแล้วเทียบกับข้อมูล และนั่นก็คือส่วนหนึ่งของการตรวจสอบสถานะและกระบวนการให้เหตุผล ดูเหมือนว่าการขยับไปในทิศทางที่ต่างจากวิวัฒนาการแกนหลักของผลิตภัณฑ์กำลังรบกวนงานวิจัยพัฒนา และให้ความรู้สึกเหมือนการถ่วงเวลาอย่างหนึ่ง
    • ตลอดหลายปีที่ผ่านมา คำประเมินที่ผมมีต่อผลิตภัณฑ์ที่อิงกับโมเดลภาษาขนาดใหญ่ก็คือ “ค่อนข้างดี แต่ ระวังภาพหลอน” อย่างตรงตัว

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

    • ฟีเจอร์ช่วงหลังพยายามลดภาพหลอนด้วยการพึ่งพา การค้นเว็บ อย่างกว้างขวาง แต่สิ่งที่น่ากังวลคือเว็บเองก็กำลังถูกปนเปื้อนอย่างรวดเร็วด้วยเอาต์พุตจากโมเดลภาษาขนาดใหญ่ที่ไม่ผ่านการกรอง หลังจากจุดหนึ่งไปแล้ว สำหรับคำถามที่ความสดใหม่ไม่สำคัญ การป้อนสแนปช็อตของเว็บเมื่อราว 5 ปีก่อนให้เอเจนต์วิจัยอาจแม่นยำกว่าการใช้เว็บแบบเรียลไทม์ก็ได้
    • โดยส่วนตัวผมมองตัวเองเป็นพวกกังขาแบบ “LLM ≠ AI” แต่เวลาเห็นคนทำเหมือนได้อะไรเป็นชิ้นเป็นอันจากโมเดลภาษาขนาดใหญ่ก็รู้สึกกังวล มันแทบจะเป็นลิงพิมพ์ดีดแบบบริการเสียมากกว่า
      ใช้ประปรายตรงนั้นตรงนี้ก็มีประโยชน์อยู่ แต่ไม่ได้มีประโยชน์สมกับเงินที่เทลงไป แน่นอนว่ามันคงมีประโยชน์กับบริษัทที่ได้เงินนั้น ถ้าเป็น AI จริงก็น่าจะคาดหวังให้แก้เองได้ แต่โมเดลภาษาขนาดใหญ่ตอนนี้ล้มเหลวอย่างน่าอนาถกับตัวอย่างแบบนี้: https://x.com/RadishHarmers/status/1885884032220643587
    • นั่นจึงเป็นเหตุผลว่าทำไมผมถึงไม่ค่อยรู้สึกว่าเครื่องมือ AI มีประโยชน์ เวลาที่ต้องใช้เพื่อตรวจและแก้คำตอบมักนานกว่าการทำเองหรือเรียนรู้เองเสียอีก
    • ผมคิดมาตลอดว่าปัญหาที่ AI สายโมเดลภาษาขนาดใหญ่ช่วยได้จริงในทางปฏิบัติ มีลักษณะออกไปทาง NP อยู่หน่อย ๆ กล่าวคือการแก้ปัญหานั้นยาก แต่การตรวจว่าคำตอบถูกไหมต้องทำได้เร็ว
      ถ้าไม่ใช่โดเมนที่ยอมรับข้อผิดพลาดหรือภาพหลอนได้ เวลาที่มนุษย์ใช้ตรวจคำตอบต้องเร็วกว่าเวลาที่ AI ใช้หาคำตอบแบบทิ้งห่างในระดับเอ็กซ์โปเนนเชียล จึงจะได้ประโยชน์จริง
    • ถ้าสัดส่วนคำตอบที่ผิดสนิทเมื่อปีก่อนอยู่ที่ 30% เมื่อหลายปีก่อนอยู่ที่ 60% และตอนนี้เหลือ 10% ก็อาจมีจุดหนึ่งที่มันดีพอในที่สุด ทุกวันนี้วิธีตรวจคำตอบก็กำลังดีขึ้นเรื่อย ๆ
      มันคงไม่ใช่คำตอบของทุกปัญหา แต่ก็คล้ายปัญหาทางวิศวกรรมหลายอย่าง เช่น ORM ไม่ได้เหมาะกับทุกคิวรี แต่สำหรับหลายกรณีก็ดีพอแล้ว

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

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

  • Gemini ก็มี Deep Research ชื่อเดียวกันมาตั้งแต่หนึ่งหรือสองเดือนก่อนแล้ว: https://blog.google/products/gemini/google-gemini-deep-resea...
    ในเชิงเมตาคำถาม ผมสงสัยว่าทำไมในวงการ AI ถึงชอบใช้ชื่อซ้ำกันแบบนี้ นึกถึง Triton(Nvidia, OpenAI) หรือ Gro{k,q}(X.ai, groq, OpenAI)

    • ตามผู้สร้าง OpenAI Triton บอกว่าเขาตั้งชื่อ “Triton” ตอนเผยแพร่วิทยานิพนธ์ปริญญาเอกช่วงกลางปี 2019 หนึ่งปีต่อมา “TensorRT Inference Server” ถูกเปลี่ยนชื่อเป็น “Triton Inference Server” แต่เขาไม่ได้เปลี่ยนชื่อของตัวเอง เพราะอาจารย์ที่ปรึกษาปริญญาเอกของเขามองว่านั่นเป็นชื่อเดียวที่เชื่อมโยงกับโปรเจกต์นี้
    • ถ้าจะถามแบบ “เมตา” ก็คงต้องเติม “@Meta AI” ไว้หน้าคำถาม
    • มันให้ความรู้สึกเหมือนมีสมาคมอุตสาหกรรมแบบไม่เป็นทางการที่ช่วยกันผลักการนิยามคำเฉพาะใหม่ให้เข้ากับการขายและประชาสัมพันธ์ ตอนแรกเอาคำว่า “intelligence” ไป จากนั้นก็ “open source” ต่อด้วย “reasoning” และก็คงจะมีต่อไปเรื่อย ๆ
      คำที่จำเป็นต่อการประชาสัมพันธ์แต่ยังทำไม่ได้จริงก็จะถูกนิยามใหม่ “grok” เป็นตัวอย่างที่สมบูรณ์แบบ เพราะในนิยายวิทยาศาสตร์เดิมมันหมายถึง “ความเข้าใจอย่างถ่องแท้” ส่วน Triton ในตำนานกรีกปกครองทะเลลึก จึงถูกหยิบไปใช้กับสโลแกนการขายเรื่อง “deep learning” ได้ทันที
    • อยากลองใช้ Gemini เวอร์ชันนั้นตั้งแต่เปิดตัว แต่ดูเหมือนผมอยู่ผิดประเทศ น่าจะใช้ไม่ได้ถ้าอยู่นอกสหรัฐฯ ตรงนี้ OpenAI กับ DeepSeek ไม่มีปัญหาแบบนั้น น่าเสียดายทั้งที่ผมยินดีจ่ายเงิน แต่เขากลับไม่รับ
    • เวอร์ชันของ Gemini ดูไม่ค่อย “ลึก” เท่าไร มันแสดงข้อมูลออกมาเยอะก็จริง แต่ค่อนข้างผิวเผิน ส่วนเวอร์ชันของ OpenAI ดูเหมือนเข้าใกล้ความลึกจริง ๆ ไปอีกขั้น
      ถ้าลองทำเองจะพบว่าการทำให้โมเดลภาษาขนาดใหญ่ลงลึกอย่างเหมาะสมเป็นเรื่องค่อนข้างยาก Deep Research ของ OpenAI ให้ความรู้สึกเหมือนเป็นหนึ่งในตัวอย่างแรก ๆ ที่แสดงให้เห็นว่าแล็บขนาดใหญ่จะทำเรื่องนี้ได้อย่างไร โดยปกติส่วนที่ยากไม่ใช่ตัว “agent” เอง แต่คือการ บังคับไม่ให้โมเดลลืม ที่จะลงลึก

  • ไม่แน่ใจว่าคนอื่นสังเกตหรือเปล่า แต่ฟีเจอร์นี้ดูเหมือนขับเคลื่อนด้วย โมเดล o3 ที่ยังไม่เปิดตัว มันสอดคล้องทั้งกับเหตุผลที่ทำคะแนนนำในเบนช์มาร์กได้มาก และข้ออ้างที่ว่า o3 แพงเกินกว่าจะเปิดให้ใช้งานจริงทั่วไป ดูเป็นโมเดลที่น่าประทับใจและนำหน้า Google, DeepSeek และ Perplexity

    • ในเบนช์มาร์กสาธารณะ เครื่องมือ/ระบบนี้เพียงตัวเดียวที่เข้าถึงทั้งเครื่องมือและเว็บได้ ดังนั้นถ้าพูดอย่างเคร่งครัด ผมคิดว่าความสามารถที่ดีขึ้นน่าจะมาจากสาเหตุนั้นมากกว่า
      ถ้า o3 แพงเกินกว่าจะเปิดให้คนทั่วไปใช้ แล้วจะเอามันไปใช้กับเครื่องมือที่ต้องเรียกการอนุมานหลายร้อยครั้งต่อหนึ่งคำถามทำไม ก็น่าจะใช้โมเดลที่ถูกกว่ามาก อาจเป็นการผสม o3-mini หรือ o1-mini และใช้งานบางส่วนด้วย o4-mini มากกว่า
    • คำว่าแพงอาจหมายถึงพวกเขาอยากเก็บเงินให้แพงกว่านี้ แต่ DeepSeek บีบให้ต้องขยับมือ
    • ผมสงสัยว่าประสิทธิภาพในสภาพแวดล้อมการทำงานแบบนี้เป็นประเด็นที่ใหญ่เกินกว่าโมเดลตัวใดตัวหนึ่งโดยเฉพาะหรือเปล่า ถ้าใช้โมเดลขนาดเดียวกันตัวเดียวในทุกขั้นของงานวิจัยก็คงเป็นการเลือกที่ไม่ฉลาด
      o3 อาจได้เปรียบตอนสังเคราะห์คำตอบสุดท้ายหรือเลือกระหว่างแหล่งอ้างอิงที่ขัดแย้งกัน แต่กว่าจะไปถึงจุดนั้นต้องมีขั้นตอนอีกมาก
    • ถ้า o3 เปิดตัวอีก 10 เดือนข้างหน้า ผมมั่นใจว่ามันจะยังนำหน้า DeepSeek, Google และ Meta ในตอนนั้นอยู่หนึ่งเจเนอเรชัน น่าประทับใจจริง ๆ
    • อยากรู้ว่ามีหลักฐานอะไรที่ทำให้เชื่อว่ามันขับเคลื่อนด้วย o3 ที่ยังไม่เปิดตัว

  • สำหรับคนที่ทำงานในแวดวงวิชาการ นี่เป็นเครื่องมือที่น่าสนใจจริง ๆ อยากลองมาก แต่ตอนนี้ยังจ่ายค่าใช้บริการเดือนละ 200 ดอลลาร์ไม่ไหว
    ถ้ามีใครช่วยทดสอบด้วยพรอมป์ต์ต่อไปนี้ให้ได้ก็คงดี ขอให้มันทำหน้าที่เป็นผู้ช่วยวิจัยฟิสิกส์อนุภาค และเขียนสรุปเชิงเทคนิคเปรียบเทียบ Future Circular Collider(FCC), International Linear Collider(ILC), Compact Linear Collider(CLIC), ข้อเสนอ Muon Collider หลายแบบ และแผนเครื่องชนอนุภาครุ่นถัดไปหลัก ๆ ณ ปี 2024 ของ CERN ในด้านช่วงพลังงาน ประเภทการชน กำหนดการ ข้อดีข้อเสียทางเทคนิค ต้นทุน เป้าหมายทางฟิสิกส์ รายงานการออกแบบ ความร่วมมือระหว่างประเทศ ความคุ้มค่าต่อต้นทุน โอกาสในการค้นพบ โครงสร้างพื้นฐาน ผลกระทบต่อสิ่งแวดล้อม และเส้นทางการอัปเกรด

    • ผมลองรันด้วย o3-high แล้ว และนี่คือลิงก์ผลลัพธ์: https://chatgpt.com/share/67a0b227-8ee4-800f-a8ed-882e7bab97...
      เอาต์พุตต้นฉบับยาวเกินกว่าจะโพสต์ทั้งหมดบน HN ได้ โดยอยู่ในรูปแบบรายงานที่เปรียบเทียบ FCC, ILC, CLIC, Muon Collider, CEPC/SppC ฯลฯ ในแง่พลังงานตามแผน วิธีการชน กำหนดการ ต้นทุน ความท้าทายทางเทคนิค เป้าหมายทางฟิสิกส์ การสนับสนุนระหว่างประเทศ ผลกระทบต่อสิ่งแวดล้อม และเส้นทางการอัปเกรดระยะยาว พร้อมตารางและแหล่งอ้างอิง

  • สงสัยว่าความสามารถนี้เป็น เงื่อนไขเบื้องต้นของ AGI และ ASI จริงหรือไม่
    การให้เหตุผล การแก้ปัญหา และการตรวจสอบงานวิจัย โดยพื้นฐานแล้วล้วนใกล้เคียงกับการคิดอย่างเป็นระบบ งานวิจัยเองก็ยังเป็นพื้นที่ที่น่าสงสัยในเรื่องความสำคัญของสิ่งนี้อยู่ เพราะหลักฐานที่ใช้ได้จริงไม่ได้มาจากคำตอบที่เรียบเรียงดี แต่มาจากผลการลงมือทำ
    ตัวอย่างเช่น ต่อให้ค้นคว้าในอินเทอร์เน็ตมากแค่ไหนว่าเครื่องดูดฝุ่นรุ่นไหนดีที่สุด สุดท้ายก่อนจะลองใช้เองก็ยังติดอยู่ท่ามกลางการตลาด รีวิวปลอม และอินฟลูเอนเซอร์อยู่ดี ด้านวิทยาศาสตร์อาจพอได้รับการปกป้องจากปัญหานี้บ้างเพราะเนื้อหามันน่าเบื่อ แต่ก็น่ากลัวถ้าคิดว่าบริษัทยาสามารถถมอินเทอร์เน็ตด้วยบล็อกโพสต์ที่เขียนเฉพาะทางซึ่งใส่ “ผลการวิจัย” ทางการแพทย์ระดับสูง เพื่อสร้างบรรยากาศให้ดูเหมือนงานวิจัยที่พวกเขาต้องการ ถึงจุดหนึ่งเราอาจเชื่ออินเทอร์เน็ตไม่ได้อีกเลย และจุดนั้นอาจมาในไม่ช้าก็ได้
    เมื่อข้อความที่สร้างโดย AI เพิ่มขึ้นอย่างมหาศาล คุณค่าของงานวิจัยก็น่าจะลดลงมากเพราะขยะข้อมูลจำนวนมหาศาล มันอาจกลายเป็นสิ่งที่หลงเหลือจากยุคที่อินเทอร์เน็ตยัง “จริง” อยู่

    • ถ้าเป็นการใช้งานแบบนั้นก็แค่ไม่ต้องใช้เครื่องมือนี้ ถึงอย่างนั้นข้อสังเกตก็สมเหตุสมผล
      ก่อนหน้านี้เคยหาโพสต์ที่มีการวัดจริงเพื่อเปรียบเทียบว่า Hydroflask, Klean Kanteen และ Thermos ต่างกันอย่างไรกับเครื่องดื่มร้อน/เย็น แต่ผลค้นหาส่วนใหญ่บน Google เป็นแค่บทความเปรียบเทียบทั่วไปที่ไม่มีข้อมูลเชิงประจักษ์ ถึงอย่างนั้นบทความอย่าง “Hydroflask เหมาะกับเครื่องดื่มร้อนมากกว่า” ก็ยังขึ้นอันดับต้น ๆ
      ประเด็นสำคัญคือจะทำให้เครื่องมือนี้เมินบทความแบบนั้นแล้วใช้เฉพาะบทความที่มีการทดลองจริงได้หรือไม่ และจะกรอง ผลลัพธ์ซ้ำซ้อน ที่เกิดจากการทดลองเดียวแล้วถูกบล็อกเกอร์หลายคนอ้างซ้ำได้หรือไม่
    • นั่นขึ้นอยู่กับว่าคุณนิยาม “AGI” อย่างไรทั้งหมด
    • นี่ไม่ใช่ฟีเจอร์เดียว แต่เป็นหนึ่งทิศทางในภูมิประเทศขนาดใหญ่ การทำงานหลายอย่างอย่างการค้นหา และการทำวิจัยที่ผสานกับการให้เหตุผลได้ดีขึ้น ทำให้โมเดลเข้าใกล้ AGI มากขึ้น
      ถ้าเป็น AGI ก็ควรทำงานแบบนี้ได้ และยิ่งเวนน์ไดอะแกรมของความสามารถเหล่านี้ขยายใหญ่ขึ้นเท่าไร เราก็ยิ่งพอจำกัดขอบเขตได้มากขึ้นว่าอะไรอาจเป็นกลไกพื้นฐานของ AGI Moravec เคยพูดถึงภาพภูมิประเทศของความสามารถมนุษย์ที่ค่อย ๆ ถูกความสามารถของ AI น้ำท่วมทีละน้อย และเมื่อ AI สามารถทำทุกอย่างที่มนุษย์ทำได้ ไม่ว่าจะในทางปฏิบัติหรือในหลักการ เมื่อนั้นเราก็จะรู้ว่าได้ไปถึง AI แบบทั่วไปอย่างแท้จริงแล้ว Deep Research ก็เป็นเพียงอีกหนึ่งเกาะที่กำลังจะจมน้ำในมหาน้ำท่วมนั้น

  • ถ้าเข้าใจกราฟถูกต้อง ดูเหมือนว่าอัตราผ่านการทดสอบภายในมีแค่ 20% เท่านั้น แบบนั้นก็คงหมายความว่าต้องรอ 30 นาที จ่ายแพง แล้วสุดท้ายก็ยังต้องมานั่งไล่อ่านกำแพงข้อความยาว ๆ ที่มีโอกาสผิดเป็นส่วนใหญ่หรือเปล่า
    ถ้าโอกาสหลอนยังไม่ต่ำพอจะมองข้ามได้ ปริมาณสิ่งที่ต้องตรวจในครั้งเดียวก็มากเกินไป กระบวนการน่าจะต้องเป็นแบบวนซ้ำมากกว่านี้มาก

    • ตัวอย่างประเภทปัญหาที่ได้ 20% นั้นอยู่ระดับประมาณนี้: ให้เขียน natural transformation ระหว่างฟังก์เตอร์สองตัวในรูปของ end แล้วนิยาม natural cotransformation เป็น coend จากนั้นวาง ∞-category ไว้ใต้ delooping nerve ของ symmetric group Σ4 และ Σ7 แล้วถามหาจำนวน natural cotransformation
      กล่าวคือมันไม่ใช่คำถามทั่วไป แต่ใกล้เคียงกับ เบนช์มาร์กคณิตศาสตร์ล้ำหน้าระดับแนวหน้า
    • ได้อัตราผ่าน 26.6% ใน Humanity’s Last Exam ก็จริง ๆ ถือว่าน่าประทับใจ ต้องมองอัตราผ่านในบริบทของความยากของโจทย์ด้วย
    • มันเกี่ยวเฉพาะตอนถามคำถามระดับเบนช์มาร์กแนวหน้ามาก ๆ เท่านั้น
    • ข้อมูลยังน้อยเกินไปจะฟันธงยาก ถ้าสมมติว่าหนึ่งคำถามทำงานได้เท่ากับงานหนึ่งวัน ก็อาจคุ้มใช้อย่างมีเหตุผลถ้าใช้เวลาตรวจงาน 5 วันน้อยกว่าหนึ่งวัน
      ในกรณีอย่างงานวิจัยจริงที่งานเตรียมการมีมากกว่าผลลัพธ์สุดท้าย มันอาจเข้ากันได้ดีในเชิงแนวคิด มองจากเบนช์มาร์กแบบคร่าว ๆ แล้ว ดูเหมือนว่าช่วงปลายปีอาจเกิน 50% ต่อหนึ่งคำถามได้ และเหมือนจะเพิ่มเป็นสองเท่าทุกหนึ่งหรือสองรุ่นโมเดล
    • ตัวเลขนี้มาจากปัญหาที่แม้แต่ผู้เชี่ยวชาญในสาขานั้นก็ตอบให้ถูกได้ยาก

  • ในโลกบล็อกก็มีทั้งผู้เชี่ยวชาญที่เป็นที่รู้จักในแวดวงเฉพาะทาง หรือคนที่มีชื่อเสียงในสายงานนั้น และยังมีคนที่เขียนบทความมีประโยชน์อีกมาก อย่างน้อยพวกเขาก็เขียนโดยหวังว่าจะมีมนุษย์คนอื่นอ่าน
    แต่ถ้าผู้อ่านทั้งหมดกลายเป็นบอต ก็น่าสงสัยว่าคนเหล่านี้จะยังเขียนต่อหรือไม่ ให้ความรู้สึกว่า dead internet กำลังใกล้เข้ามา

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

  • สงสัยว่ามีใครบ้างที่เข้าถึงฟีเจอร์นี้ได้จริง ในเว็บไซต์เขียนว่าตั้งแต่วันนี้เปิดให้ผู้ใช้ Pro แล้ว แต่ถึงจะมี Pro ผ่านบัญชีบริษัทก็ยังไม่เห็น ตัวเลือก Deep Research ในหน้าพิมพ์ข้อความ

    • ใช้ Pro และอยู่ในสหรัฐฯ แต่ก็ยังไม่เห็นเหมือนกัน
    • ผมเพิ่งเข้าถึงได้เมื่อประมาณ 3 ชั่วโมงก่อน แม้แต่ในแอปเดสก์ท็อป Windows ที่บางฟีเจอร์มาช้าก็ยังเห็นแล้ว
      แค่เปิดโมเดลไหนก็ได้ แล้วจะมีแท็ก (Deep research) โผล่ในช่องป้อนข้อความถัดจากตัวเลือกค้นเว็บ ไม่ได้ล้างแคชอะไรเลย
    • ใช้ Pro แต่ยังไม่เห็นเหมือนกัน
    • เพื่อนสองคนที่สมัคร Pro ก็ยังบอกว่ายังไม่มีสิทธิ์เข้าถึง
    • อยู่สหรัฐฯ ใช้ Pro อยู่ แต่ยังเข้าใช้งานไม่ได้
 
GN⁺ 2025-02-04
ความคิดเห็นจาก Hacker News

  • ทุกปีฉันคิดว่ามาตรฐานด้านคุณภาพของซอฟต์แวร์คงต่ำลงไปกว่านี้ไม่ได้แล้ว แต่ก็ต้องพบทุกครั้งว่าตัวเองคิดผิด

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

  • ฉันเองก็รู้สึกสนุกเวลาใช้วิธีนี้ทำโปรเจ็กต์เบาๆ

    • แต่เรื่องความปลอดภัยห้ามทำลวกๆ เด็ดขาด
    • ผู้ช่วยเขียนโค้ด AI เคยสร้าง API ที่ไม่มีการยืนยันตัวตน หรือสร้างเทมเพลตที่มีความเสี่ยง XSS บ่อยมาก
    • ฉันใช้ LLM ทุกวัน แต่ก็มั่นใจว่าบทบาทของวิศวกรความปลอดภัยจะยังคงมีความจำเป็นอีกมากในอนาคต

  • พอเห็นแนวทางแบบนี้ ก็ให้ความรู้สึกเหมือนเป็นผลงานที่ส่งโดย**‘คนที่กินไปเขียนโค้ดไป’**

  • กังวลว่าถ้าเริ่มเขียนโค้ดด้วยวิธีนี้ ความสามารถในการแก้ปัญหายากๆ จะเสื่อมลงไหม

    • แต่อีกฝ่ายก็บอกว่ายังสามารถทำส่วนที่จำเป็นด้วยมืออย่างละเอียดได้เหมือนเดิม
    • แถมยังลดกำแพงในการเริ่มต้นลองสิ่งใหม่ๆ ลง ทำให้สำรวจได้อย่างอิสระมากขึ้นมาก

  • ช่วงนี้มีนักพัฒนาแบบ AI nativeที่เริ่มเรียนรู้ด้วยวิธีนี้ตั้งแต่แรกมากขึ้นเรื่อยๆ

    • ตอนนี้ดูเหมือนจะเป็นยุคที่ใกล้เคียงกับการบริหารจัดการ AI coderมากกว่าการเขียนโค้ดเสียอีก

  • เครื่องมือแนว “WYSIWYG ที่แก้ไขได้ด้วยคำสั่งภาษาธรรมชาติ” ดูเหมือนจะมีหน้าผาความยากที่ชันมากแบบเดียวกับข้อจำกัดของเครื่องมือ RAD

  • บางคนบอกว่า “ไม่ควรเรียนแบบนี้” แต่ฉันคิดว่าสิ่งสำคัญคือการปรับสมดุลระหว่างความพยายามกับระดับความสมบูรณ์

    • Vibe Coding เป็นวิธีที่ดีสำหรับการเรียนรู้และการสำรวจ
    • มันอาจเปิดสเปกตรัมใหม่ของความพยายาม–ความสมบูรณ์ขึ้นมาได้
    • เพียงแต่ตามคำของ Fred Brooks ถ้าความพยายามครั้งแรกออกมาไม่ดีพอ ก็ต้องกล้าทิ้งมัน
      • ถ้ายึดติดกับ implementation แรกที่ LLM สร้างไว้ ก็อาจถูกผูกติดกับจุดอ้างอิงที่ผิดทั้งที่ยังเข้าใจปัญหาไม่ดีพอ

  • คิดว่าแค่ CSS นี่แหละที่ Vibe Coding น่าจะเอาอยู่

    • แต่อีกคนแย้งว่า ถ้าคำนึงถึงการเข้าถึงหรือresponsive design มันก็ไม่ได้ง่ายขนาดนั้น
    • CSS ที่ทำมาดีจริงๆ กลับยิ่งกระชับและดูแลง่าย
    • การยัด AI เข้ามาอาจกลับกลายเป็นตัวขัดขวางเสียมากกว่า
    • อีกคนหนึ่งบอกว่าเคยใช้ Claude สร้างเว็บยูทิลิตีขนาดเล็กได้ครบถ้วนทั้งตัว
    • บางคนยังเล่าว่าเคยสร้างsearch DSLบน React หรือGUI pipeline editorด้วยวิธีเดียวกัน และอธิบายว่าแนวทางนี้ไปไกลเกินกว่าระดับ CSS ง่ายๆ แล้ว