21 คะแนน โดย GN⁺ 2025-12-21 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ปี 2025 เป็นปีที่ การเรียนรู้เสริมกำลังจากรางวัลที่ตรวจสอบได้ (RLVR) ก้าวขึ้นมาเป็นขั้นตอนแกนกลางใหม่ของการฝึก LLM และถูกเพิ่มเข้าไปในไปป์ไลน์เดิมอย่าง pretraining-SFT-RLHF
  • LLM พัฒนากลยุทธ์การให้เหตุผลได้ด้วยตัวเองใน สภาพแวดล้อมที่ตรวจสอบได้ เช่น คณิตศาสตร์และปริศนาโค้ด จนเรียนรู้รูปแบบการแก้ปัญหาที่สำหรับมนุษย์แล้วดูคล้ายกับการ “คิด”
  • Cursor นิยาม เลเยอร์ใหม่ของแอป LLM โดยแสดงวิธีทำ context engineering และ orchestration ของการเรียกใช้ LLM ที่ซับซ้อนในบาง vertical โดยเฉพาะ
  • Claude Code ปรากฏขึ้นในฐานะ ตัวอย่างแรกที่น่าเชื่อถือของเอเจนต์ LLM ที่รันอยู่บนคอมพิวเตอร์โลคัลของผู้ใช้ และนำเสนอพาราไดม์ใหม่ของการปฏิสัมพันธ์กับ AI
  • Vibe Coding ทำให้คนที่ไม่ใช่ผู้เชี่ยวชาญก็สร้างโปรแกรมได้ด้วยภาษาอังกฤษเพียงอย่างเดียว และส่งสัญญาณถึงการทำให้การพัฒนาซอฟต์แวร์เป็นประชาธิปไตยมากขึ้น รวมถึงการเปลี่ยนความหมายของอาชีพ

1. การผงาดขึ้นมาของการเรียนรู้เสริมกำลังจากรางวัลที่ตรวจสอบได้ (RLVR)

  • จนถึงต้นปี 2025 สแตกการผลิตของ LLM มีโครงสร้าง 3 ขั้น ได้แก่ pretraining, supervised fine-tuning (SFT) และ reinforcement learning from human feedback (RLHF)
  • RLVR (Reinforcement Learning from Verifiable Rewards) ถูกเพิ่มเข้ามาเป็นขั้นตอนหลักใหม่ เพื่อฝึก LLM กับ รางวัลที่ตรวจสอบอัตโนมัติได้ เช่น คณิตศาสตร์และปริศนาโค้ด
  • LLM เรียนรู้พฤติกรรมที่คล้าย “การให้เหตุผล” ได้เองโดยธรรมชาติ เช่น การ แยกปัญหาออกเป็นขั้นตอนคำนวณย่อย และพัฒนากลยุทธ์การแก้ปัญหาที่หลากหลาย
    • กลยุทธ์เหล่านี้ยากจะบรรลุได้ในพาราไดม์ก่อนหน้า เพราะไม่ชัดเจนว่า reasoning trace แบบไหนจึงถือว่าเหมาะสมที่สุด
    • LLM ต้องค้นหาวิธีที่ เหมาะกับตัวเอง ผ่านการทำ optimization กับรางวัล
  • ต่างจาก SFT/RLHF ตรงที่ RLVR สามารถทำ optimization ที่ยาวกว่ามากกับ reward function ที่เป็นวัตถุวิสัยและเล่นเกมไม่ได้
  • ด้วย capability/$ ที่สูงของ RLVR ทรัพยากรคอมพิวต์ที่เดิมใช้กับ pretraining จึงถูกโยกมาที่ RLVR
    • ความก้าวหน้าด้านความสามารถส่วนใหญ่ในปี 2025 ถูกนิยามโดยการใช้ รอบ RL ที่ยาวขึ้น กับ LLM ขนาดใกล้เคียงเดิม
  • มีปุ่มปรับใหม่ (และ scaling law ใหม่) เกิดขึ้นในรูปของ test-time compute ซึ่งทำให้ปรับความสามารถได้ผ่านการสร้าง reasoning trace ที่ยาวขึ้นและเพิ่ม “เวลาในการคิด”
  • OpenAI o1 (ปลายปี 2024) คือเดโมแรกของโมเดล RLVR และ การเปิดตัว o3 (ต้นปี 2025) คือจุดหักเหที่ทำให้สัมผัสความต่างได้อย่างชัดเจน

2. ผี vs. สัตว์ / สติปัญญาแบบไม่สม่ำเสมอ (Jagged Intelligence)

  • ในปี 2025 เราเริ่มเข้าใจ “รูปร่าง” ของสติปัญญา LLM ได้อย่างเป็นรูปธรรมมากขึ้น
  • LLM ไม่ได้เป็นการ “วิวัฒนาการ/เลี้ยงดูสัตว์” แต่คือการ “อัญเชิญผี”
    • เพราะทั้ง neural architecture, ข้อมูลฝึก, อัลกอริทึมการฝึก และแรงกดดันจาก optimization ต่างกันทั้งหมด จึงก่อให้เกิดสิ่งมีชีวิตที่ต่างไปมากใน space ของสติปัญญา
  • เครือข่ายประสาทของมนุษย์ถูกปรับให้เหมาะกับ การอยู่รอดของเผ่าพันธุ์ในป่า ขณะที่เครือข่ายประสาทของ LLM ถูกปรับให้เหมาะกับ การเลียนแบบข้อความของมนุษยชาติ การสะสมรางวัลจากปริศนาคณิตศาสตร์ และการได้ upvote ใน LM Arena
  • เมื่อ RLVR ใช้ได้ในโดเมนที่ตรวจสอบได้ ความสามารถของ LLM ในพื้นที่เหล่านั้นจึง พุ่งเป็นยอดแหลม และแสดง ลักษณะประสิทธิภาพที่ไม่สม่ำเสมอ
    • ในเวลาเดียวกันมันอาจเป็นทั้ง อัจฉริยะรอบรู้ และ เด็กประถมที่สับสน รวมถึงอาจถูกหลอกให้ jailbreak แล้วทำข้อมูลรั่วไหลได้ภายในไม่กี่วินาที
  • เกิด การสูญเสียความเชื่อมั่นและความสนใจต่อ benchmark
    • Benchmark แทบจะโดยนิยามแล้วเป็นสภาพแวดล้อมที่ตรวจสอบได้ จึงเปราะบางทันทีต่อ RLVR และรูปแบบอ่อน ๆ ของการสร้างข้อมูลสังเคราะห์
    • ในกระบวนการ benchmaxxing ทีมต่าง ๆ สร้างสภาพแวดล้อมให้ครอบคลุมบริเวณใกล้เคียง embedding space ของ benchmark
    • การเรียนจาก test set กลายเป็นเทคนิคใหม่
  • หน้าตาของโลกที่ “ผ่าน benchmark ทุกตัวแต่ยังไม่ไปถึง AGI” จะเป็นอย่างไร?
  • บทความที่เกี่ยวข้อง

3. Cursor / เลเยอร์ใหม่ของแอป LLM

  • พร้อมกับการเติบโตอย่างรวดเร็วของ Cursor เราเริ่มเห็นชัดถึง เลเยอร์ใหม่ของ “แอป LLM”
    • เริ่มมีการใช้สำนวนว่า “Cursor for X”
  • แอป LLM อย่าง Cursor ทำการ bundle และ orchestration การเรียกใช้ LLM เพื่อ vertical เฉพาะทาง
    1. ทำ context engineering
    2. ทำ orchestration เป็น DAG ที่ซับซ้อนขึ้นเรื่อย ๆ ของการเรียก LLM หลายครั้ง เพื่อถ่วงดุลระหว่างประสิทธิภาพกับต้นทุน
    3. มี GUI เฉพาะแอปสำหรับ human in the loop
    4. มี “ตัวเลื่อนระดับความเป็นอิสระ”
  • มีการถกเถียงกันมากว่าเลเยอร์แอปใหม่นี้จะ “หนา” แค่ไหน
    • ถกกันว่า LLM lab จะยึดแอปทั้งหมดไปเลยหรือไม่ หรือยังมีโอกาสสำหรับแอป LLM อยู่
  • โดยทั่วไป LLM lab มักผลิตสิ่งที่เหมือนนักศึกษามหาวิทยาลัยที่เก่งกาจออกมา แต่คาดว่าแอป LLM จะเป็นตัวเติม ข้อมูลส่วนตัว, เซนเซอร์, แอคชูเอเตอร์, feedback loop ให้กับ vertical เฉพาะ เพื่อจัดระเบียบ ปรับละเอียด และทำให้สิ่งเหล่านี้กลายเป็นผู้เชี่ยวชาญตัวจริง

4. Claude Code / AI ที่พำนักอยู่บนคอมพิวเตอร์

  • Claude Code (CC) ปรากฏขึ้นในฐานะ เดโมแรกที่น่าเชื่อถือของเอเจนต์ LLM
    • มันเชื่อมการใช้เครื่องมือและการให้เหตุผลเข้าด้วยกันแบบลูป เพื่อแก้ปัญหาที่ขยายขอบเขตได้
  • CC รันอยู่บนคอมพิวเตอร์ของผู้ใช้ พร้อมกับ สภาพแวดล้อม, ข้อมูล และบริบทส่วนตัว
  • OpenAI วางทิศทางพลาดในความพยายามยุคแรก ๆ ของ Codex/เอเจนต์ โดยไปโฟกัสกับ การ deploy container บนคลาวด์ ที่ orchestrate จาก ChatGPT
    • คือไปโฟกัสที่คลาวด์ แทนที่จะเป็นแค่ localhost
  • การมี agent swarm รันอยู่บนคลาวด์ให้ความรู้สึกเหมือน “AGI endgame” แต่ปัจจุบันเราอยู่ในโลกของ การกระโดดแบบก้ำกึ่งและช้า ภายใต้ความสามารถที่ไม่สม่ำเสมอ
    • การรันเอเจนต์บนคอมพิวเตอร์ของนักพัฒนาโดยตรงจึงสมเหตุสมผลกว่า
  • ประเด็นสำคัญไม่ใช่ว่า “งาน AI” รันที่ไหน แต่คือเรื่องของ คอมพิวเตอร์ที่มีอยู่แล้วและถูกบูตไว้, การติดตั้ง, บริบท, ข้อมูล, secrets, การตั้งค่า, และการปฏิสัมพันธ์แบบหน่วงต่ำ
  • Anthropic มองลำดับความสำคัญนี้ได้แม่น และแพ็ก CC มาใน ฟอร์มแฟกเตอร์แบบ CLI ที่กระชับ
    • นี่คือพาราไดม์ใหม่ของการปฏิสัมพันธ์ ที่ AI ไม่ใช่เว็บไซต์แบบ Google ที่เราเข้าไปเยี่ยมชม แต่เป็นวิญญาณ/ผีเล็ก ๆ ที่ “พำนักอยู่” บนคอมพิวเตอร์

5. Vibe Coding

  • ปี 2025 คือปีที่ AI ข้ามพ้น threshold ด้านความสามารถในการสร้างโปรแกรมที่น่าประทับใจได้หลากหลาย ด้วยภาษาอังกฤษเพียงอย่างเดียว
    • เราสามารถเขียนโปรแกรมได้โดยแทบลืมไปเลยว่ามีโค้ดอยู่จริง
  • ผู้เขียน coin คำว่า “vibe coding” ในทวีต แต่ไม่ได้คาดคิดว่ามันจะแพร่หลายได้มากเพียงนี้
  • Vibe coding ทำให้การเขียนโปรแกรมเปลี่ยนจากสิ่งที่เป็น พื้นที่ของผู้เชี่ยวชาญที่ผ่านการฝึกอย่างหนักเท่านั้น ไปสู่สิ่งที่ใคร ๆ ก็ทำได้
  • LLM เป็นกรณีที่ไม่เหมือนเทคโนโลยีอื่นทั้งหมด คือ คนทั่วไปได้รับประโยชน์มากกว่าผู้เชี่ยวชาญ บริษัท หรือรัฐบาลอย่างมาก
  • Vibe coding ไม่เพียงเปิดทางให้คนทั่วไปเข้าถึงการเขียนโปรแกรม แต่ยังทำให้ผู้เชี่ยวชาญที่ผ่านการฝึกแล้วสามารถสร้าง ซอฟต์แวร์ที่ไม่อย่างนั้นคงไม่ถูกเขียนขึ้นมาเลย (ซอฟต์แวร์แบบ vibe-coded) ได้มากขึ้นอย่างมหาศาล
  • ตัวอย่างที่เป็นรูปธรรม:
    • ใน nanochat มีการ vibe code BPE tokenizer แบบ custom ประสิทธิภาพสูงด้วย Rust โดยไม่ต้องรับไลบรารีเดิมมาใช้หรือเรียน Rust เชิงลึก
    • vibe code สิ่งที่อยากให้มี เช่น menugen, llm-council, reader3, HN time capsule ให้เป็น เดโมแอปแบบรวดเร็ว
    • vibe code ทั้งแอปแบบใช้ครั้งเดียว เพียงเพื่อหาบั๊กตัวเดียว — อยู่ ๆ โค้ดก็กลายเป็นของฟรี ชั่วคราว ยืดหยุ่น และใช้แล้วทิ้ง
  • Vibe coding จะ terraform วงการซอฟต์แวร์ และเปลี่ยนนิยามของอาชีพ

6. Nano Banana / LLM GUI

  • Google Gemini Nano Banana คือหนึ่งในโมเดลที่พลิกพาราไดม์ได้ชวนทึ่งที่สุดของปี 2025
  • หากมองว่า LLM คือ พาราไดม์การคอมพิวต์ใหญ่ถัดไป ที่คล้ายกับคอมพิวเตอร์ในยุค 1970–80 นวัตกรรมประเภทคล้ายกันก็น่าจะเกิดขึ้นด้วยเหตุผลพื้นฐานที่คล้ายกัน
    • จะมีสิ่งที่เทียบได้กับ personal computing, microcontroller (แกนรับรู้), internet (ของเอเจนต์) เป็นต้น
  • ในแง่ UIUX การ “คุย” กับ LLM นั้นคล้ายกับการสั่งงานผ่านคอนโซลคอมพิวเตอร์ในยุค 1980
  • ข้อความเป็นรูปแบบข้อมูลดิบที่คอมพิวเตอร์ (และ LLM) ชอบ แต่ ไม่ใช่รูปแบบที่มนุษย์ชอบ
    • โดยเฉพาะฝั่ง input มนุษย์ไม่ชอบการอ่านข้อความเยอะ ๆ เพราะช้าและต้องใช้แรง
  • มนุษย์ชอบบริโภคข้อมูลในรูปแบบ ภาพและเชิงพื้นที่ จึงเกิด GUI ขึ้นในโลกคอมพิวเตอร์แบบดั้งเดิม
  • ในทำนองเดียวกัน LLM ก็ควรสื่อสารในรูปแบบที่มนุษย์ชอบ เช่น ภาพ, infographic, สไลด์, whiteboard, animation/video, web app
  • เวอร์ชันเริ่มต้นที่มีตอนนี้คืออีโมจิและ Markdown — การจัดวางข้อความให้ “ดูเป็นภาพมากขึ้น” ด้วยหัวเรื่อง ตัวหนา ตัวเอียง รายการ ตาราง ฯลฯ
  • Nano Banana คือคำใบ้แรก ๆ ว่า LLM GUI อาจมีหน้าตาอย่างไร
    • สิ่งสำคัญไม่ใช่แค่การสร้างภาพเองเท่านั้น แต่คือ ความสามารถแบบผสานกัน ที่ทั้งการสร้างข้อความ การสร้างภาพ และความรู้เกี่ยวกับโลก ถักรวมอยู่ในน้ำหนักของโมเดลเดียวกัน

TLDR; สรุปรวม

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

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

 
laeyoung 2025-12-21

"vibe coding" ทำเดโมแอปอย่างรวดเร็วสำหรับสิ่งที่อยากให้มีอยู่ เช่น menugen, llm-council, reader3, HN time capsule


สมกับเป็นบิดาแห่ง vibe coding จริงๆ สิ่งที่เขาทำด้วย vibe coding นั้นแตกต่างจากของเล็กๆ น้อยๆ ที่ผมทำอย่างมหาศาลเลย 🤣

 
GN⁺ 2025-12-21
ความคิดเห็นจาก Hacker News
  • สำหรับฉัน นวัตกรรมที่น่าประทับใจที่สุดในปีนี้คือ Claude Code
    Cursor เป็นการพิสูจน์แนวคิดที่ดี แต่สิ่งที่ทำให้ฉันเริ่มใช้ LLM ในการเขียนโค้ดจริงๆ คือ Claude Code
    โค้ดที่ Claude สร้างขึ้นแทบจะเหมือนโค้ดที่ฉันเขียนเอง ราวกับมันอ่านความคิดฉันได้
    เลยทำให้ดูแล บำรุงรักษา โค้ดที่ Claude สร้างได้ง่ายด้วย
    ฉันเดาสไตล์โค้ดได้ราว 90~95% และมันเขียนได้เร็วกว่าฉันมาก
    Gemini ก็น่าประทับใจ แต่โดยเฉพาะ Nano Banana มีประโยชน์กับงานกราฟิกดีไซน์
    ฉันยังไม่ได้ลองใช้ Gemini กับงานเขียนโค้ด เพราะ Claude Code ดีเกินไป จนรู้สึกว่าถ้าเขียนได้เร็วไปกว่านี้อาจเกิด decision fatigue
    ปกติฉันจะไม่รีบตัดสินใจเรื่องสถาปัตยกรรมหรือ UX แต่จะคิดอยู่สักวันสองวันก่อนค่อยเริ่มลงมือ เพราะพอเริ่มเดินไปในทิศทางหนึ่งแล้วจะย้อนกลับได้ยาก และอาจยึดติดกับทางเลือกที่ผิดเพราะ sunk cost fallacy

    • ตอนนี้ฉันแทบไม่รู้สึกว่ามีเหตุผลอะไรให้ใช้ Cursor แล้ว
      ฉันติดตั้งปลั๊กอิน Claude Code ใน IntelliJ IDEA แล้วใช้ IDE แค่สำหรับสำรวจโค้ดหรือรีวิวเท่านั้น
      จำไม่ได้แล้วว่าครั้งล่าสุดที่พิมพ์โค้ดเองเกินสองบรรทัดคือเมื่อไร
      ด้วย Claude Code ผลิตภาพของฉันเพิ่มขึ้นอย่างน้อย 5 เท่าขึ้นไป และเพราะต้นทุนการเขียนเทสต์แทบไม่มีเลย test coverage ก็เลยดีขึ้นมากด้วย
      ตอนนี้ฉันใช้ เวิร์กโฟลว์ AI agent แบบเต็มรูปแบบ โดยวางแผนกับ Claude, ถามคำถาม, ให้มันลงมือทำ, รีวิว แล้วก็ขอให้แก้ไข
      ไม่มีการเขียนโค้ดด้วยมือเลย ศูนย์จริงๆ
    • Nano Banana Pro เป็นเครื่องมือที่บ้าพลังมากถ้าคุณรู้วิธีใช้มันอย่างถูกต้อง
      จนถึงตอนนี้ก็ยังไม่อยากเชื่อว่าของแบบนี้ถูกปล่อยออกมาสู่สาธารณะแล้ว
    • ตอนแรกฉันเริ่มเข้าสู่ agent coding ด้วยแพ็กเกจโค้ดดิ้งของ GLM (ประมาณ 2 ดอลลาร์ต่อเดือน)
      แต่เพราะต้องคอยขอให้ Claude ทำโค้ดให้ สวยงามและอ่านง่ายขึ้น ทุกครั้ง สุดท้ายก็เลยย้ายมาใช้ Claude Code เลย
      GLM ก็ใกล้เคียงมากถ้าใช้พรอมป์ต์ดีๆ แต่ถ้าจ่ายแค่ 0.6 ดอลลาร์ต่อวันแล้วไม่ต้องกังวลเรื่องพวกนั้น ก็รู้สึกว่าไม่ต้องคิดมาก
    • ฉันไม่มีเวลามานั่งประเมินเครื่องมือใหม่ทุกเดือน เลยปักหลักอยู่กับ Cursor
      ใช้โมเดลเดียวกันแท้ๆ เลยสงสัยว่าฉันกำลังพลาดอะไรไป
  • ฉันชอบบทความของ Karpathy แต่ช่วงนี้พอเห็น โครงสร้างประโยคแบบ LLM อย่าง “It’s not X, it’s Y” ก็สะดุ้งโดยสัญชาตญาณ
    เมื่อ 3 ปีก่อนมันไม่ได้รบกวนอะไร แต่ตอนนี้รู้สึกว่าสำนวนแบบนี้พังไปหมดแล้ว

    • ใช่เลย พอโดนชี้ให้เห็นแล้ว ตอนนี้ฉันก็ เห็นแต่สำนวนนี้เต็มไปหมด จนเลิกสังเกตไม่ได้
    • เมื่อก่อนฉันใช้ em dash (—) บ่อยมาก แต่พอคนเริ่มบอกว่างานเขียนของฉัน “ดูเหมือน AI เขียน” ก็ต้องเปลี่ยนวิธีเขียน
    • ฉันเข้ามาเพื่ออ่านงานของ Karpathy แต่ตอนนี้กลับเริ่มคิดว่า หรือจะถาม LLM ตรงๆ เลยดีกว่า
    • ฉันเกลียดประโยคแบบนี้มาตั้งแต่ก่อนยุค LLM แล้ว
      ประโยคอย่าง “It’s not just a website…” ฉันเรียกว่า ไขมันเชิงวาทศิลป์ (rhetorical fat)
      ตัดส่วนเกินพวกนี้ออกไป ประโยคจะดูเรียบขึ้นแต่ชัดเจนกว่า
      โดยเฉพาะคำอย่าง “little spirit” ที่ให้ความรู้สึกโอเวอร์จนฉันต้องกลอกตา
      แน่นอนว่าผู้เขียนคงใส่มาเพื่อเน้นน้ำหนัก แต่สำหรับฉันมันไม่ตรงกับอุดมคติในการเขียน เลยทำให้รู้สึกต่อต้าน
      ประโยคอย่าง “It’s not just about image generation…” สร้าง ความตึงเครียดเชิงแนวคิดที่ไม่จำเป็น
      ฉันคิดว่าเขียนตรงๆ ไปเลยว่า “การสร้างภาพจะเจ๋งขึ้นเมื่อรวมเข้ากับการสร้างข้อความ” ยังจะดีกว่า
    • ตอนนี้พอเห็นแต่สำนวนนี้เต็มไปหมด ก็เลยสนุกกับอินเทอร์เน็ตได้ยากขึ้น
  • เป็นรีวิวที่ยอดเยี่ยมและสมจริงมาก
    คำพูดที่ว่า “LLM ฉลาดกว่าที่คาด แต่ก็โง่กว่าที่คาดในเวลาเดียวกัน” ทำให้ฉันกังวล
    เราจะรู้ได้อย่างไรว่าครั้งไหนจะเจอด้านไหน?
    ในงานเขียนโค้ดเราจับข้อผิดพลาดได้ค่อนข้างง่าย แต่ในโดเมนทั่วไปมันยากกว่านั้นไม่ใช่หรือ
    อีกทั้งกับคำกล่าวที่ว่า “คนทั่วไปได้ประโยชน์จาก LLM มากกว่าผู้เชี่ยวชาญ” อดีตก็เคยมีความหวังแบบเดียวกันกับ AppleScript, VB, visual programming แต่สุดท้าย AI กลับถูกใช้เหมือนเสิร์ชเอนจินที่ฉลาดขึ้น
    แต่พื้นที่นั้นแหละคือจุดที่ hallucination หนักที่สุด จึงคิดว่านี่คือปัญหาและอยากรู้ว่าจะแก้อย่างไร

  • ฉันชอบท่าทีมองโลกในแง่ดีของ Andrej แต่ก็อยากฟังมุมมองของเขาด้วยว่าในปี 2025 การกระจุกตัวของอำนาจในอุตสาหกรรม เปลี่ยนไปอย่างไร รวมถึงประเด็นอย่าง โอเพนซอร์ส, local inference, ข้อจำกัดด้านฮาร์ดแวร์
    ตัวอย่างเช่น เขาเขียนว่า Claude Code “รันแบบโลคัล” แต่ในความเป็นจริง มีแค่ TUI ที่รันโลคัล ส่วน inference เกิดขึ้นบนคลาวด์
    เลยอยากรู้ว่าโครงสร้างแบบนี้จะพัฒนาไปทางไหนหลังปี 2026

    • ประเด็นของ CC อยู่ที่ ข้อมูลและบริบทของสภาพแวดล้อม ไม่ใช่ว่าคำนวณที่ไหน
      สิ่งที่ทำให้การตั้งค่าแบบคลาวด์ไม่สะดวกไม่ใช่เรื่องการคำนวณ แต่เป็นเรื่อง UI/UX และ user loop
    • llama.cpp ตอนนี้รองรับฟอร์แมตข้อความของ Anthropic แล้ว จึงใช้ร่วมกับ Claude Code ได้
    • หนึ่งใน coding agent ที่น่าสนใจและรันแบบโลคัลได้คือ OpenAI Codex
      สามารถรันร่วมกับโมเดล gpt-oss ที่โฮสต์บน Ollama ได้
      เช่น codex --oss -m gpt-oss:20b และก็ใช้กับโมเดลที่ใหญ่กว่า (120b) ได้ด้วย
    • สิ่งที่ Karpathy หมายถึงด้วย “agent ที่รันในเครื่อง” น่าจะหมายถึงไม่ใช่เว็บเซอร์วิสแบบ LangChain แต่เป็น software wrapper (Harness) ที่เรียกใช้ LLM API
      agent นี้สามารถเรียก Bash, จัดการไฟล์ในระบบ, และทำแทบทุกอย่างบน OS ได้
      กล่าวคือ โมเดลเป็นเหมือน สมอง ที่อยู่ไกลออกไป ส่วน agent คือ ชุดจักรกล
    • ฉันคิดว่าส่วนที่พูดถึง Claude Code เขียนไว้ค่อนข้าง กำกวม
      เขาน่าจะหมายถึงว่า ตัว agent รันในเครื่อง ไม่ใช่ inference รันในเครื่อง
      ดูเหมือนเขาต้องการเน้นว่า OpenAI ออกแบบ Codex แบบเน้นคลาวด์ ในขณะที่ CC เลือกแนวทางที่ให้ความสำคัญกับโลคัลก่อน
      แต่ความต่างนี้ควรถูกอธิบายให้ชัดกว่านี้มาก
  • ฉันรู้สึกว่าอุปมา RLVR ของ Karpathy เรื่อง “เลี้ยงสัตว์ vs อัญเชิญผี” เป็นโมเดลที่อธิบาย jagged intelligence ในตอนนี้ได้อย่างสมบูรณ์แบบ
    เราไม่ได้กำลังสร้างผู้รอดชีวิตแบบอเนกประสงค์ แต่กำลังโอเวอร์ออปติไมซ์เฉพาะโดเมนให้เข้ากับรางวัลที่ตรวจสอบได้
    และแนวคิดเรื่อง “ซอฟต์แวร์ใช้ครั้งเดียวจาก vibe coding” ก็โดนใจมาก
    เวิร์กโฟลว์ที่สร้างแอปชั่วคราวขึ้นมาเพื่อดีบักปัญหาแค่เรื่องเดียวแล้วลบทิ้งทันที มันให้ความรู้สึกว่าเป็นการเปลี่ยนแปลงจริงๆ

    • แต่ฉันไม่คิดว่าอุปมา “สัตว์ vs ผี” จะลึกซึ้งอะไรขนาดนั้น
      มนุษย์กับสัตว์คือ สิ่งมีชีวิตที่มีสติปัญญาจริง แต่ LLM แค่ สะท้อนผลผลิตของมนุษย์ ในขอบเขตแคบๆ เท่านั้น
      ถ้าจะเป็นปัญญาประดิษฐ์ที่แท้จริง มันต้องมีคุณลักษณะอย่าง อิสระในการกระทำ, การเรียนรู้อย่างต่อเนื่อง, ความอยากรู้อยากเห็น, ภาวะมีตัวตนเสมือน
      สัตว์ส่วนใหญ่ขับเคลื่อนด้วยสัญชาตญาณ แต่มีเพียงสิ่งมีชีวิตที่เรียนรู้แบบทั่วไปได้เหมือนมนุษย์เท่านั้นที่ถือว่ามีสติปัญญาอย่างแท้จริง
    • อย่างไรก็ดี การใช้งาน LLM ในตอนนี้ก็อยู่ได้ด้วย เงินอุดหนุน
      ต้องรอดูว่าถ้าต้องจ่ายต้นทุนจริง การทำแอปใช้ครั้งเดียวแบบนี้จะยังไปต่อได้หรือไม่
    • ฉันใช้งานแบบนั้นมาแล้วหลายเดือน สนุกมากจริงๆ
      ฉันสรุปไว้ในโพสต์ของฉัน ว่านี่คือสแตกที่ทำงานที่ Jupyter เริ่มไว้ให้เสร็จ
      มันมีโครงสร้าง functional fence ที่เรียกใช้ได้และประกอบต่อกันได้
      คล้ายกับ MCP และแค่เรียนรู้แพตเทิร์นก็พอ ไม่ต้องฝึกอะไรเพิ่มเติม
      ถึงขั้นมี functor ที่เชื่อมวิธีสอนเปียโนในศตวรรษที่ 18 เข้ากับ context engineering เลยด้วย
  • ส่วนที่ Karpathy บอกว่า “LLM ควรสื่อสารใน รูปแบบที่ผู้ใช้ชอบ เช่น ภาพ, สไลด์, ไวต์บอร์ด” น่าสนใจมาก
    แต่ถ้า LLM สร้าง UX ใหม่ให้ผู้ใช้แต่ละคนทุกครั้ง มันก็อาจกลายเป็น นรกของอินเทอร์เฟซที่คาดเดาไม่ได้ ได้เหมือนกัน
    อาจเกิดสถานการณ์แบบ “ในแอปนี้ Command-W จะทำอะไรนะ?”

    • ในทางกลับกัน agent บางตัวช่วงนี้เริ่มใส่ใจเรื่อง accessibility แล้ว
      อย่าง Codex นี่ละเอียดกว่ามนุษย์เสียอีก
    • ถ้ามองจากวิธีสื่อสารจริงของมนุษย์ อันดับหนึ่งน่าจะเป็น ข้อความ/เสียง และอันดับสองคือ ภาพ
    • แต่จริงๆ แล้ว LLM แก้ปัญหานั้นไปแล้ว
      ตัว LLM เองนี่แหละคือ UI ที่ดีที่สุด
      เพราะมันเข้าใจได้ทั้งหลายภาษาและแนวคิดเชิงนามธรรม จึงไม่จำเป็นต้องสร้าง UI แบบสุ่มขึ้นมา
      ฉันเป็นผู้ใช้ที่ไม่ได้ใช้ภาษาอังกฤษเป็นหลัก ต่อให้พิมพ์ปนคำเยอรมัน มันก็ยังเข้าใจได้ดี
  • อินฟลูเอนเซอร์ด้าน AI หลายคนมั่นใจว่า “text UI จะหายไป” แต่ในความเป็นจริง อินเทอร์เฟซแบบข้อความยังคงเป็นศูนย์กลาง

    • เมื่อไม่กี่วันก่อนฉันพยายามยกเลิกสมัครเครื่องมือ AI 3D modeling ตัวหนึ่ง แต่หาปุ่มไม่เจออยู่ 5 นาที
      สุดท้ายมันซ่อนอยู่ใน เมนูสามจุดสีจางๆ บนการ์ดแพ็กเกจ พอกดแล้วกลับเปิด หน้าต่างแชตบอต AI ขึ้นมา
      ต้องพิมพ์พรอมป์ต์คำว่า “unsubscribe” ถึงจะมีปุ่มให้
      ฉันรู้สึกว่าการเอา UX แบบระบบโทรศัพท์ตอบรับอัตโนมัติ มาใส่ในแอปเป็นเรื่องเลวร้ายมาก
      ในฐานะวิศวกรฟรอนต์เอนด์ เทรนด์นี้ทำให้ฉันรู้สึกน่ากลัว
    • ตลอดชีวิตของฉัน ดูเหมือนผู้คนจะค่อยๆ พิมพ์ข้อความมากกว่าพูดคุย กันมากขึ้นเรื่อยๆ
  • ฉันสงสัยว่า Andrej คิดอย่างไรกับ โมเดลความเร็วสูง แห่งปีนี้ (Gemini 3 Flash, Grok 4 Fast)
    ตอนนี้มีโมเดลที่เร็ว ถูก และดีแบบนี้ออกมาแล้ว แต่ดูเหมือนชุมชนแทบไม่ค่อยสนใจ
    ถ้าวิสัยทัศน์เรื่อง LLM สำหรับอินเทอร์เฟซแบบภาพจะเป็นจริง โมเดลประเภทนี้น่าจะขาดไม่ได้

    • เป็นไปได้มากว่าโมเดลขนาดเล็กพวกนี้คือเวอร์ชัน distillation ของโมเดลใหญ่
      เดาว่ามันน่าจะถูกฝึกด้วย reasoning traces ที่โมเดลใหญ่สร้างขึ้น
    • แนะนำให้ลองดูงานวิจัยของ Sasha Luccioni
  • ปี 2025 ยังเป็นปีที่ ผีเริ่มสิงอยู่ในข้อมูลฝึก ด้วย
    ตอนนี้ครึ่งหนึ่งของ X (Twitter) คือ LLM ตอบ LLM
    พูดอีกอย่างคือ มีการเรียกซ้อนอยู่ภายในตัวชุดข้อมูลเอง

    • ถ้าใครมี เคล็ดลับแยกบัญชี LLM ออกได้ก็อยากรู้ ฉันไม่อยากไปเถียงกับบอต
  • เห็นด้วยที่บอกว่า o3 คือ จุดเปลี่ยน
    มีคนบอกว่า o3 หรือ o4-mini จริงๆ แล้วก็ระดับ gpt-5 แล้ว
    แต่เพราะชื่อไม่คุ้นหู คนเลยไม่ค่อยสนใจ และพอ gpt-5 ออกมากลับมีแค่ การพัฒนาแบบค่อยเป็นค่อยไป เลยทำให้คนผิดหวัง
    o4-mini อาจไม่เหมาะเป็นโมเดลพื้นฐานเพราะภาษาสนทนาดูแปลกๆ แต่ถ้าใช้ชื่ออย่าง “gpt-5 pro” แล้วใส่ไว้ในแพ็กเกจ 20 ดอลลาร์ก็คงดี

    • ฉันก็เห็นด้วย ตอนนั้นแทบไม่มีใครได้ลอง o3 และชื่อมันก็แปลกจนไม่ค่อยมีใครสนใจ
      มองย้อนกลับไป ตอนนั้นแหละคือจังหวะของ การเปิดตัวใหญ่