ทุกสิ่งรอบตัว LLM ยังคงเหมือนเวทมนตร์และความคิดที่มองโลกในแง่ดีเกินไป

• เรื่องเล่าความสำเร็จของเครื่องมือ LLM มักขาด เกณฑ์เปรียบเทียบ เช่น เงื่อนไขของโปรเจกต์ ความเชี่ยวชาญของผู้ใช้ และปริมาณงานติดตามผล จึงยากจะตัดสินประโยชน์ที่แท้จริง
• ท่าทีในวงถกเถียงเรื่อง MCP, การใช้เครื่องมือ และเอเจนต์ ที่มองนักวิจารณ์ว่าเป็น “คนที่ยังไม่ได้มองให้ลึกพอ” คล้ายกับ การถกเถียงเรื่อง crypto ในอดีต
• LLM และเอเจนต์มีลักษณะ ไม่กำหนดผลแน่นอน ดังนั้นแม้เป็นปัญหาเดียวกัน วิธีที่ใช้ได้ตอนนี้ก็ไม่อาจถือว่าจะใช้ได้เหมือนเดิมในอีก 1 นาทีถัดไป
• คำพูดดังที่ว่า Claude Code “จัดการบั๊ก legacy ได้” ก็ได้รับ 1.8 พันไลก์ และ 204 รีโพสต์ ทั้งที่ไม่มีรายละเอียดเรื่องขนาด codebase ประเภทของบั๊ก และวิธีบริหารจัดการ
• แม้จากมุมมองของคนที่ใช้งานเครื่องมือหลายอย่างจริง ๆ แล้ว LLM ก็ใกล้เคียงกับ เครื่องจักรสถิติที่ไม่กำหนดผลแน่นอน และแม้ตอนที่มันทำงานได้จะรู้สึกเหมือนเวทมนตร์ ก็ยังยากจะฟันธงว่าเป็นเวทมนตร์หรือวิศวกรรม

---

เหตุผลที่เปรียบเทียบประสบการณ์เกี่ยวกับ LLM ระหว่างกันได้ยาก

• ประสบการณ์ทั้งเชิงบวกและเชิงลบต่อเครื่องมือ LLM มักถูกแชร์เป็น ชิ้นส่วนที่แยกขาดจากกัน จึงยากจะตรวจสอบว่ากำลังพูดถึงเงื่อนไขเดียวกันหรือไม่
• บ่อยครั้งไม่มีการระบุลักษณะของโปรเจกต์และ codebase
  • ไม่ชัดเจนว่าเป็น greenfield, codebase ที่โตเต็มที่แล้ว หรือ codebase แบบ proprietary
• ความเชี่ยวชาญของผู้ใช้ก็เปรียบเทียบแบบง่าย ๆ ได้ยาก
  • ไม่รู้ว่าความเชี่ยวชาญนั้นถูกนำไปใช้กับโดเมนเดียวกัน codebase เดียวกัน หรือภาษาเดียวกันหรือไม่
• ปริมาณ งานเพิ่มเติม ที่จำเป็น เช่น การรีวิว การแก้ไข การ deploy และการเก็บงาน ก็ส่งผลอย่างมากต่อการประเมิน
• แม้คนคนหนึ่งจะให้ข้อมูลทั้งหมดข้างต้นครบถ้วน หากไม่รู้เงื่อนไขของคนอื่น การเปรียบเทียบระหว่างประสบการณ์ก็ยังมีข้อจำกัดอยู่ดี
• นอกจากนี้ยังมี ความไม่กำหนดผลแน่นอน ของระบบ LLM และเอเจนต์เข้ามาเพิ่มอีก
  • แม้เป็นปัญหาเดียวกัน ก็ไม่อาจถือว่าวิธีที่ใช้ได้ตอนนี้จะยังใช้ได้ในอีก 1 นาทีถัดไป
  • ประสบการณ์ของวิศวกรอาวุโสในโปรเจกต์ React แบบ greenfield กับประสบการณ์ของดีไซเนอร์ที่ไม่ใช่นักพัฒนาบน codebase OCaml แบบ proprietary จะยิ่งเปรียบเทียบกันยากขึ้นเมื่อโมเดลและเอเจนต์เปลี่ยนไป
  • แม้เป็นโมเดลและเอเจนต์เดียวกัน ผลลัพธ์ก็อาจแตกต่างกันในแต่ละครั้งที่รัน จึงยากต่อการเปรียบเทียบแบบง่าย ๆ

ช่องว่างระหว่างวาทกรรมที่ร้อนแรงกับการใช้เครื่องมือจริง

• ปฏิกิริยาที่ปฏิบัติต่อนักวิจารณ์ LLM ว่าเป็น “คนที่ยังไม่ได้ดู MCP และเครื่องมือมากพอ” สะท้อนถึง ความร้อนแรงเกินไปของการถกเถียงเรื่อง AI
• มีการยกคำพูดเกี่ยวกับ Claude Code ของ Steve Yegge มาเป็นกรณีตัวอย่างจาก “industry leaders”
  • เนื้อหาคือ Claude Code จัดการบั๊ก legacy ใน codebase เก่าได้อย่างหนักหน่วงตลอดหลายวัน
  • มีถ้อยคำในทำนองว่า Claude Code เดินหน้าต่อได้โดยไม่ต้องเลือก context เองโดยตรง
  • ยังรวมถึงเนื้อหาที่ว่าหากอนุมัติค่าใช้จ่ายผ่านธนาคารไปเรื่อย ๆ การแก้บั๊กก็จะต่อเนื่องไปจนถึงการ deploy ขึ้น production และตรวจสอบ log ของผู้ใช้
• แม้ในกรณีนี้ ข้อมูลที่จำเป็นต่อการประเมินก็ยังขาดหายไป
  • ไม่ทราบขนาดของ codebase
  • ไม่รู้ว่าเป็นบั๊กประเภทใด
  • ไม่ชัดเจนว่ามีการบริหารจัดการเพิ่มเติมหรือไม่
  • ภาษาโปรแกรมและเฟรมเวิร์กก็ไม่ปรากฏ
• ถึงอย่างนั้น คำพูดดังกล่าวก็ได้รับ 1.8 พันไลก์ และ 204 รีโพสต์
• ฝ่ายกังขาและนักวิจารณ์เองก็ไม่ได้ไม่ใช้เครื่องมือเหล่านี้
  • มี side project ที่ออกแบบทั้งหมดด้วย v0 ของ Vercel
  • สร้างแอปมอนิเตอร์ด้วย SwiftUI ผ่าน Claude Code ทั้งที่ไม่รู้ Swift
  • สร้างโปสเตอร์งานอีเวนต์ด้วย Midjourney
  • vibe-coding MCP server ด้วย Elixir แต่ไม่ได้ใช้ phoenix.new
• ประสบการณ์ใช้งานจริงสรุปได้ทำนองว่า “ทำงานได้แค่ 50% ในเวลา 50%”
• LLM เป็น เครื่องจักรสถิติที่ไม่กำหนดผลแน่นอน และแม้ตอนที่มันทำงานได้จะให้ความรู้สึกเหมือนเวทมนตร์ แต่มันก็ไม่ใช่เวทมนตร์หรือวิศวกรรมโดยตัวมันเอง
• วาทกรรมเกี่ยวกับ LLM มีแนวโน้มที่จะ扱扱มันราวกับว่าต้องเป็นอย่างใดอย่างหนึ่งระหว่างเวทมนตร์กับวิศวกรรมเท่านั้น

[GN⁺]

ความคิดเห็นบน Hacker News

• รู้สึกหงุดหงิดที่ผู้บริหารในที่ทำงานได้ยินเรื่องอย่าง ผลิตภาพเพิ่มขึ้น 10 เท่า คำกล่าวอ้างบางส่วนก็มาจาก early adopter ภายในบริษัทด้วย
  แต่ความคาดหวังสูงเกินไปมาก เหตุผลหนึ่งคือ กฎของ Amdahl เพราะในความเป็นจริง เราใช้เวลากับการคิด และการสื่อสารกับคนอื่น ๆ ที่เป็นลูกค้าของโค้ดเรามากกว่าการเขียนโค้ดเสียอีก ต่อให้การเขียนโค้ดเร็วขึ้น 10 เท่า ส่วนใหญ่ของงานก็ไม่ได้เร็วขึ้นตาม และผลิตภาพโดยรวมก็ดีขึ้นประมาณ 10–15% เท่านั้น ไม่ใช่เรื่องเล็กจนมองข้ามได้ แต่ก็ไม่ใช่ 10 เท่า

  • อาจเป็นเพราะงานที่ทำตอนนี้มีลักษณะเป็นงานวิจัยและพัฒนาค่อนข้างมาก แต่ในกรณีของผม LLM ช่วยเพิ่มผลิตภาพในส่วนของ การคิด ได้พอ ๆ กับการเขียนโค้ด ส่วนการสื่อสารตอนนี้ผมยังจัดการเองได้ดี
    ความรู้สึกของการใช้ LLM ทำงานด้านการคิดคล้ายกับตอนที่เรียนรู้การค้นเว็บเมื่อกว่า 20 ปีก่อน เสิร์ชเอนจินทำให้เข้าถึงข้อมูลได้เมื่อเรารู้ว่ากำลังหาอะไรอยู่ ส่วนตอนนี้ LLM ช่วยให้รู้ว่าตั้งแต่แรกควรหาอะไร และยังช่วยค้นหาให้ด้วย งานที่เมื่อก่อนจัดว่าเป็นเรื่องยากเพราะต้องใช้ความพยายามและมีความไม่แน่นอน กลายเป็นเรื่องเล็กน้อยไป
    ตอนนี้ผมใช้ ChatGPT o3 แทนการค้นเว็บประมาณ 1/3 และตอนนี้คงเลิกใช้ได้ยากแล้ว
    มันยังมีผลทางจิตวิทยาในการช่วยจัดระเบียบความคิดที่ยังไม่สุกงอม และรับฟังเหมือน rubber duck ทำให้งานจำนวนมากรู้สึกหนักน้อยลงมาก และแค่นั้นเองก็สร้างความแตกต่างได้มากแล้ว
  • บริษัทเราก็คล้ายกัน ข้ออ้างเรื่องผลิตภาพจาก early adopter ภายในที่เห็นมาจนถึงตอนนี้ ล้วนตั้งอยู่บน วิธีวัดผลิตภาพที่แคบมาก และการคำนวณที่พูดให้ดีที่สุดก็ยังน่าสงสัย
  • นั่นอาจเป็นเพราะ LLM เป็นตัวเร่งสำหรับ นักพัฒนาอาวุโส ได้มากกว่านักพัฒนาจูเนียร์อย่างมาก จูเนียร์ยังไม่ค่อยรู้ว่าอะไรดีอะไรแย่
    ถ้าให้นักพัฒนาอาวุโส 1 คนมี workflow กับ LLM ที่ปรับแต่งมาดี ก็ไม่น่าแปลกใจหากจะมีผลิตภาพเท่ากับจูเนียร์ 10 คนในยุคก่อน LLM ด้วยซ้ำ ยิ่งไปกว่านั้น นักพัฒนาที่แย่อาจดึงเวลาของซีเนียร์ไปจนทำให้ผลิตภาพติดลบได้ กรณีนั้นแทบจะเรียกได้ว่าเพิ่มขึ้นเป็นอนันต์
    แม้แต่จูเนียร์ที่พอใช้ได้ โดยทั่วไปก็มักถูกผูกติดอยู่กับงานซ้ำ ๆ ระดับล่าง ซึ่ง LLM ทำงานเหล่านั้นได้ดีกว่าอยู่แล้ว
    ดังนั้นจึงเข้าใจได้ที่บอกว่างานอาจหายไปจริง ๆ
  • ถ้าต้นทุนของเครื่องมือ LLM ทำให้ต้นทุนการจ้างงานเพิ่มขึ้น 10–15% การมี ผลิตภาพเพิ่มขึ้น 10–15% ก็ไม่ใช่เรื่องที่มองข้ามไม่ได้ แต่เป็นเรื่องที่ต้องคำนวณให้ดี ต้องดูต้นทุนการผลิตโดยรวมเสมอ ไม่ใช่ดูแค่ throughput
  • มันก็เป็นแค่อีกระลอกหนึ่งของ กระแสอวยเทคโนโลยีเกินจริง ความจริงคงอยู่ somewhere ระหว่างหายนะสิ้นเชิงกับยูโทเปียไร้ขีดจำกัด แต่ก็น่าจะไม่ใช่ทั้งสองอย่าง
    กระแส AI ทำให้นึกถึงความพยายามช่วงต้นทศวรรษ 2000 ที่จะ outsource วิศวกรซอฟต์แวร์จำนวนมากไปต่างประเทศ ตอนนั้นผู้บริหารคาดหวังกันมหาศาล และบนกระดาษก็ดูสมเหตุสมผล แต่ส่วนใหญ่จบลงด้วยความล้มเหลวครั้งใหญ่ และแทบทุกตำแหน่งก็ย้ายกลับมาที่สหรัฐฯ
    หลายคนมองข้ามไปว่าวิศวกรซอฟต์แวร์ทำงานจุกจิกจำนวนมากที่ช่วยยึดทุกอย่างไว้ด้วยกัน AI ยังขาดส่วนแบบนั้นอยู่มาก ไม่ได้หมายความว่าคนต่างชาติไม่มีสิ่งนี้ แต่กำแพงภาษา ความต่างของเขตเวลา ความต่างทางวัฒนธรรม ฯลฯ ทำให้เกิดปัญหาคล้ายกัน คุณภาพโค้ดและความสามารถในการบำรุงรักษาดิ่งลงอย่างมาก และผลงานจำนวนมากที่บริษัท outsource ทำออกมาก็ต้องทิ้งไป
    ตอนนี้แม้แต่ codebase ที่ผมดูแลก็เริ่มมี กาก AI สะสมอยู่แล้ว ของพวกนี้ที่ผ่าน code review มาแล้วจับได้ยากมาก เพราะดูจาก diff แล้วมันดูสมเหตุสมผล ปัญหาคือโค้ดซ้ำที่มองไม่เห็น และ abstraction แปลก ๆ ที่มองในระดับสูงแล้วไม่สมเหตุสมผลเลย

• ผมอยู่ในกลุ่มเดียวกับที่ผู้เขียนกำลังบ่นถึงนี่แหละ ตั้งแต่สมัยที่มีแค่ ChatGPT และประสิทธิภาพก็ยังไม่ค่อยดี ผมก็ปล่อย ผลิตภัณฑ์ greenfield ที่ไม่ใช่เรื่องเล็ก ๆ ออกมาแล้ว ตอนแรกใช้ Claude โดยคัดลอก-วางไปมาระหว่างเว็บแชตกับ XCode แล้วต่อมาก็เจอ Cursor
  Cursor ทิ้งข้อผิดพลาดตอน build ที่น่ารำคาญไว้เยอะ แต่ productivity ก็ยังอย่างน้อย 3 เท่าอยู่ดี ตอนนี้พอ agent ดีขึ้น และ Claude 4 ออกมาแล้ว ผมแทบไม่ได้เขียนโค้ดเองเลย และก็ไม่ได้เกลียดมันด้วย ผมเอนเอียงไปทางบทบาทสถาปนิก/ผู้จัดการมากขึ้น และถ้าจำเป็นก็ใช้ความเชี่ยวชาญเฉพาะทางกำกับ agent
  ผมเข้าไปอยู่ในสตาร์ทอัพที่งานหินมาหลายเดือนแล้ว แต่ยังไม่ได้เขียนโค้ดด้วยมือสักบรรทัด ก่อนจะสร้าง PR ผม audit เองทั้งหมดและทดสอบอย่างละเอียด แต่ Cursor + Sonnet ใน codebase นั้นทรงพลังแบบเหลือเชื่อจริง ๆ ไม่ใช่วัดด้วยตัวชี้วัดไร้สาระอย่างจำนวนบรรทัดโค้ด แต่ในแง่ที่ว่าแม้ผู้เชี่ยวชาญของ codebase นั้นจะเอาบั๊กแปลก ๆ มาให้ ผมซึ่งเพิ่งเข้ามาในโดเมนนั้นก็สามารถจำกัดขอบเขตมันได้ภายใน 5–30 นาที ผมมั่นใจว่าตัวเองเป็นพนักงานที่ productive ที่สุด
  แม้แต่งานนักพัฒนา frontend ซึ่งเดิมทีผมหลีกเลี่ยงมาตลอดอาชีพ ก็ต้องถอนตัวออกมาหลังจาก Claude ทำให้ผมเผลอแก้ปัญหาเล็ก ๆ ที่เห็นไปเรื่อย ๆ นี่ไม่ใช่ vibe coding แต่เป็นกระบวนการที่มีการสืบค้น วางแผน สำรวจอย่างระมัดระวัง และจัดฉากให้ agent ทำงานสำเร็จ ความรู้โดเมนก็จำเป็นด้วย แต่ผมประหลาดใจจริง ๆ ว่าทำไมบางคนถึงดึงประโยชน์แบบเดียวกันออกมาไม่ได้ และรู้สึกเหมือนบทความแบบนี้โผล่มาสัปดาห์ละสองชิ้น

  • แต่คุณเพิ่งยืนยันทุกอย่างที่บทความบล็อกเมื่อกี้กล่าวอ้างไปแล้ว
    คุณเล่าเรื่องที่เชื่อได้ยาก แต่กลับไม่แชร์ หลักฐาน เลยแม้แต่นิดเดียว แถมยังสร้างบัญชีใช้ครั้งเดียวเพื่อทำให้ยืนยันตัวตนและตรวจสอบคำกล่าวอ้างไม่ได้ด้วย
    เลยรู้สึกเหมือนเป็นเรื่องตลก
  • ผมก็มีประสบการณ์คล้ายกัน เพียงแต่วิธีทำงานน่าจะต่างกันนิดหน่อย ผมเป็นนักศึกษาปริญญาเอก เคยสงสัย LLM อย่างหนัก แต่ Claude Code เปลี่ยนวิธีทำงานของผมไปโดยสิ้นเชิง
    ถึงอย่างนั้น ความจำเป็นในการคัดสรร/กำกับคุณภาพก็ไม่ได้หายไป นั่นยังเป็นหน้าที่ของผม และก็เป็นส่วนหนึ่งที่หลักสูตรปริญญาเอกควรสอนด้วย ความสามารถในการจัดการอย่างแม่นยำและไตร่ตรองว่าเราทำ X ไปทำไม อยากแสดงอะไรด้วย Y และแยกทุกขั้นตอนออกมาอธิบายให้คนอื่นฟังได้ เป็น soft skill ที่ทรงพลังมาก ตอนนี้มันยิ่งสำคัญขึ้น เพราะ agent ไม่มี world model ที่คงอยู่ต่อเนื่อง และแม้จะใช้การบีบอัดอย่างฉลาด มันก็ลืมเป้าหมายของการโต้ตอบได้เร็ว
    ถ้าผมอยู่ในสภาพที่สื่อสารได้อย่างแม่นยำ ผมก็สามารถใช้ Claude Code จัดระเบียบงานคำนวณในแบบที่เมื่อก่อนเป็นไปไม่ได้
    ถ้าใส่ใจคุณภาพ มันไม่ได้ง่ายกว่าการเขียนโปรแกรม แต่แตกต่างกัน และต้องการสำนวน/วิธีปฏิบัติคนละแบบ
  • ผมมองว่า คุณภาพโค้ด ที่ LLM ผลิตออกมาค่อนข้างแย่ พอแก้ซ้ำหลายรอบ หลายครั้งผมทำเองเร็วกว่า
    สิ่งที่ agent มีประโยชน์จริง ๆ คือการ refactor เชิงกลไกขนาดใหญ่ แทนที่จะมานั่งคิด vim macro หรือสคริปต์เขียน AST ใหม่ให้สมบูรณ์แบบ ก็โยนให้ agent ทำ
  • คุณบอกว่าก่อนสร้าง PR จะ audit เองทั้งหมดและทดสอบอย่างละเอียด แต่ LLM ไม่ได้เก็บทั้งโปรเจกต์ไว้ในหัว และยัง hallucinate เก่งด้วย แล้วคุณ audit โค้ดจากแหล่งที่ไม่น่าเชื่อถือได้เร็วขนาดนั้นอย่างไร?
    โดยเฉลี่ย prompt ยาวแค่ไหน และ unit test ก็ให้ LLM เขียนด้วยหรือเปล่า?
  • ผมใช้ Claude Code วันละหลายชั่วโมง เจ้านี่เป็น จอมโกหก การเชื่อแล้วใช้มัน ทุกคนต้องรับความเสี่ยงเอง
    ส่วนตัวผมคิดว่าคุณกำลังเล่าประสบการณ์ให้ดูดีเกินจริง

• โดยส่วนตัวแล้วผมไม่ค่อยเข้าใจเรื่องนี้นัก
  งานจำนวนมหาศาลในอุตสาหกรรมบริการทั่วโลก แท้จริงแล้วแทบจะเป็นการ ย้ายข้อมูลด้วยมือ จากชีต Excel หนึ่งไปยังอีกชีตหนึ่ง หรือจาก CRM/อีเมลไปยัง Excel ในแทบทุกองค์กรขนาดใหญ่มีพนักงานประจำหลายร้อยถึงหลายพันคนที่ทำงานแบบนี้ทุกวัน และจำนวนไม่น้อยเป็นงานจ้างภายนอก ผมคิดว่าน่าจะมีคนทำงาน data pipeline แบบแมนนวลอย่างนี้สัก 100 คนต่อวิศวกรซอฟต์แวร์ 1 คน
  ดังนั้น LLM ไม่จำเป็นต้องเก่ง OCaml มาก ๆ เพื่อสร้างมูลค่ามหาศาล แค่ทำงานใน Excel ได้ดีกว่ามนุษย์นิดหน่อยก็พอ จุดที่ MCP ช่วยได้จริง ๆ คือการเชื่อมต่อระบบเหล่านี้ได้ง่าย ข้อผิดพลาดจำนวนมากในงานแบบนี้เกิดจากการพยายามยัดงานทั้งหมดเข้าไปในบริบทครั้งเดียว ถ้าใช้ MCP ดึงอีเมลมา สกัดข้อมูล แล้วใช้ MCP อีกครั้งใส่ข้อมูลลง CRM ทีละบรรทัด จากประสบการณ์ของผม อัตรา hallucination จะต่ำมาก อย่างน้อยก็อยู่ในระดับพนักงานจูเนียร์ที่ทำงานหนักเกินไป
  บางทีใจความของบทความอาจเป็นเรื่องนี้ก็ได้ แต่สำหรับกรณีใช้งานแบบนี้ ความไม่กำหนดแน่นอนไม่ใช่ปัญหา เพราะคนที่เกี่ยวข้องเองก็ไม่ได้กำหนดแน่นอนเช่นกัน เราสามารถสร้างระบบและกระบวนการที่บังคับคุณภาพของระบบที่ไม่กำหนดแน่นอน เช่น ระบบมนุษย์ ได้
  สุดท้าย ผมติดตามทั้งคริปโตเคอร์เรนซีและ LLM อย่างใกล้ชิด แต่ในแง่ประโยชน์ใช้สอยและการยอมรับใช้งาน ทั้งสองอย่างดูไม่คล้ายกัน สิ่งที่ใกล้ที่สุดคือการยอมรับสมาร์ตโฟน ตอน iPhone ออกมาครั้งแรก เพื่อนที่ไม่ใช่สายเทคนิคหลายคนบอกว่าไม่ต้องการสมาร์ตโฟน แต่ภายในไม่กี่ปีก็มีใช้กันหมด LLM ก็คล้ายกัน ตอนนี้เพื่อนที่ไม่ใช่สายเทคนิคแทบทุกคนใช้มันในงานหลากหลายมาก

  • การเอาไปเทียบกับคริปโตเคอร์เรนซีเป็น คำวิจารณ์แบบขี้เกียจ แทบไม่มีคุณค่าให้ตรวจสอบด้วยซ้ำ เป็นแค่การหยิบเอาบรรยากาศเชิงลบของคริปโตมาใช้ซ้ำ เทคโนโลยีทั้งสองอย่างไม่เกี่ยวข้องกัน ดังนั้นจึงไม่มีเหตุผลชัดเจนที่จะประเมินเปรียบเทียบกันในเชิงเทคนิค
    อย่างไรก็ดี ปฏิกิริยาทางสังคมเป็นกระแสของการบูชาเทคโนโลยี และวิศวกรจำนวนมากที่ผ่านเรื่องแบบนี้มานานก็สมควรจะรู้สึกเหนื่อยล้า คำกล่าวอ้างที่ไม่สมจริงหาได้ง่าย และที่แย่ที่สุดมักมาจาก CEO ของบริษัท AI
    ในขณะเดียวกัน ผู้คนจำนวนมากจริง ๆ แทบจะไม่รู้หนังสือคอมพิวเตอร์ สำหรับคนที่แทบไม่เคยสัมผัสแม้แต่ระบบอัตโนมัติพื้นฐาน ก็พอจะจินตนาการได้ว่ามันดูน่าตื่นเต้นแค่ไหน “คอมพิวเตอร์พูดได้” ที่เราคุ้นเคยจากนิยายวิทยาศาสตร์ กำลังแทบจะกลายเป็นความจริงแล้ว
    ไม่กี่ปีก่อนยุค AI ผมเคยทำแมชชีนเลิร์นนิงและการประมวลผลภาษาธรรมชาติ สิ่งที่เด่นชัดที่สุดคือมันกลายเป็นกระแสหลักมากกว่าสิ่งใด ๆ ที่เคยเกิดขึ้นในสาขานี้มาก นั่นหมายความว่ามีคนจำนวนมากขึ้นที่ยังขาดประสบการณ์ในการออกแบบบนพื้นฐานของการอนุมานเชิงสถิติ ช่วงนี้จะเป็นยุคบุกเบิกตะวันตกในทุกด้าน ทั้งการเรียนรู้ความคิดเห็น การนำไปใช้ที่สำเร็จ และไอเดียโครงการที่เป็นจริงได้
    มองแบบนี้ก็ได้ ตอนนี้ถ้ามีเพื่อนมาพร้อมไอเดียแอปเหมือนนิยาย คุณบอกให้เขาลองสร้างเองได้แล้ว อย่างน้อยนั่นก็เป็นผลดีต่อทุกคน
  • พนักงานประจำแต่ละคนที่ทำงาน data pipeline แบบแมนนวลเหล่านั้น กำลัง ตรวจสอบความถูกต้อง ของงานนั้นไปพร้อมกันด้วย และยังมีความรับผิดชอบด้านการปฏิบัติตามกฎระเบียบที่ต้องทำให้ถูกต้องตรงเวลา
    ยังอาจมีส่วนที่ผูกพันทางอารมณ์กับบริษัทด้วย เช่น สัญชาตญาณเอาตัวรอดเพื่อไม่ให้ถูกไล่ออก ความทะเยอทะยานที่จะทำให้ดีขึ้น หรือจริยธรรมและวิจารณญาณที่จะรายงานผู้จัดการแปลก ๆ ผ่านช่องทางอื่น
    LLM จะไม่โทรไปตรวจสอบกับโหนดอื่นในองค์กรเมื่อเห็นว่าค่าดูผิดปกติด้วยเหตุผลนอกบริบท เช่น สถานการณ์ที่เมื่อวานเป็นวันหยุดธนาคารแบบครั้งเดียว จึงควรมีค่าเป็น 0 การรับประกันว่าตัวเลขเหล่านี้ถูกต้องอาจมีมูลค่าเท่ากับเงินเดือนพนักงานประจำหนึ่งคน และการมีใครสักคนให้โทษ ไล่ออก หรือส่งเข้าคุกเมื่อมันไม่ถูกต้อง ก็มีมูลค่าเช่นกัน
  • ผมสงสัยว่าบริษัทแบบไหนที่เรื่องคนทำ data pipeline แบบแมนนวล 100 คนต่อวิศวกรซอฟต์แวร์ 1 คนเป็นเรื่องจริง อยากให้มีใครสักคนสำรวจและจัดหมวดหมู่ งานไวท์คอลลาร์ 500 ตำแหน่ง แบบครบถ้วน
    สิ่งที่ทำให้เป็นอัตโนมัติได้จริง ๆ ถูกทำให้เป็นอัตโนมัติไปแล้ว ผมเชื่อว่า AI จะสร้างความปั่นป่วนครั้งใหญ่ แต่ผมกังขามากกับมุมมองที่ว่างานไวท์คอลลาร์ส่วนใหญ่คือ “งานอีเมล” หรือการป้อนข้อมูล มันไม่ตรงกับประสบการณ์ของผม และผมก็เคยทำงานในบริษัทระบบราชการขนาดใหญ่ที่คนแถวนี้คงบอกว่าติดอยู่กับอดีตมาแล้ว
  • นี่เป็นการประเมินความซับซ้อนของงานประเภทนี้ต่ำไปอย่างมาก

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

  • คงพูดแทนประสบการณ์เฉพาะเจาะจงไม่ได้ แต่ฉันเป็นคนที่ระแวงสงสัยทุกอย่างมาก ๆ ถึงอย่างนั้นมันก็ทำได้เกินคาดในทุกแง่เท่าที่เป็นไปได้
    ฉันสร้างบางอย่างขึ้นมาได้ในไม่ถึง 24 ชั่วโมง ทั้งที่แค่จะเริ่มต้นอย่างเดียวก็คงใช้เวลาหลายเดือน และกว่าจะไปถึงเวอร์ชันที่ขัดเกลาได้แบบตอนนี้ก็คงนานกว่านั้น สิ่งที่น่าประทับใจที่สุดคือมันทำสิ่งที่ฉันทำเองได้ให้เร็วขึ้น สิ่งที่น่าประทับใจกว่านั้นคือมันทำงานที่ฉันทำเองไม่ไหวจนต้องจ้างพนักงานหรือจ้างคนนอก ด้วยเงินและเวลาน้อยกว่ามาก และวนรอบปรับแก้ได้เร็วกว่าการสื่อสารกับคนอื่น
    มันไม่สมบูรณ์แบบ และบางครั้งก็น่าหงุดหงิดอย่างเหลือเชื่อ บอกชัด ๆ ว่าไม่ให้ทำ แต่มันก็ hardcode ค่า หรือโกหกว่าแก้เฉพาะจุดแล้ว ทั้งที่จริง ๆ ไปเปลี่ยนอย่างอื่นที่ไม่เกี่ยวเลย ถึงอย่างนั้นในความเห็นฉัน มันคือ ตัวเปลี่ยนเกม
  • ฉันลองแนวทาง “คู่คิด” อยู่พักหนึ่ง และช่วงสั้น ๆ ก็คิดว่ามันใช้ได้ดี แต่เมื่อถึงจุดหนึ่งรอยร้าวก็เริ่มปรากฏ และมองออกว่ามันเป็นการวางท่า LLM เก่งมากในการทำให้ดูเหมือนว่ามันรู้และให้เหตุผลได้ แต่ไม่ค่อยดีในการต่อยอด บทสนทนาทางปัญญา
    โดยเฉพาะเวลาพยายามขุดความรู้ในสาขาที่เพิ่งเริ่มรู้จักใหม่ ๆ การถูก LLM ชักนำผิดนั้นง่ายและอันตรายมาก ถ้าใช้เสิร์ชเอนจินทั่วไป เราดูเว็บไซต์ต้นทางแล้วประเมินความน่าเชื่อถือได้ แต่ LLM ไม่มีสิ่งนั้น ผลลัพธ์อาจเป็นอะไรก็ได้โดยพื้นฐาน และฉันไม่เห็นด้วยว่าข้อผิดพลาดจะต้องจับได้ง่ายเสมอ
  • ฉันเขียนโปรแกรมมา 40 ปี และเริ่มใช้ LLM เมื่อไม่กี่เดือนก่อน วิธีทำงานเปลี่ยนไปจริง ๆ ให้มันเขียนโค้ดชิ้นเล็ก ๆ ให้ วางข้อความ error จาก log ลงไป ส่วนใหญ่ก็ให้แนวทางแก้ได้ใน 1 นาที และยังใช้ระดมสมองเรื่องสถาปัตยกรรมหรือวิธีแก้ปัญหาใหม่ ๆ ด้วย
    แน่นอนว่าฉันตรวจโค้ดที่มันเขียน แต่ก็ยังประหลาดใจแทบทุกวันกับความฉลาดและความแม่นยำของมัน มันต่างจากคริปโตโดยสิ้นเชิง
  • ในฐานะคนที่ไม่เชื่อ LLM ขอพูดว่า โค้ดทั้งหมด รวมถึงโค้ดที่นักพัฒนามากประสบการณ์เขียน ล้วนมีลักษณะ เชิงความน่าจะเป็น โดยเนื้อแท้ นั่นจึงเป็นเหตุผลที่โปรเจกต์สำคัญมี code review, unit test, pair programming, guideline และ safeguard
    ถ้าใช้ output ของ LLM แบบไม่วิพากษ์วิจารณ์ ก็ใช้ผิดแล้ว แต่ output ของมนุษย์ก็เช่นกัน ถ้าใช้แบบไม่วิพากษ์วิจารณ์ก็ผิด
    อย่างไรก็ดี LLM ไม่ใช่เวทมนตร์ และฉันกังวลว่าผู้คนจะใช้ copilot หรือโมเดล agent ต่าง ๆ ไปปกปิดแนวปฏิบัติทางวิศวกรรมที่แย่ และในระยะยาวจะกอง boilerplate เพิ่มขึ้น แทนที่จะให้ความสำคัญกับประสิทธิภาพ ความปลอดภัย และการออกแบบใหม่ที่สำคัญ
  • มีด้านหนึ่งที่ LLM ทำได้ดีมาก นั่นคือ data science ถ้า input/output ถูกนิยามไว้ชัดเจน ก็ตรวจสอบได้ง่ายว่าผลลัพธ์ถูกหรือไม่ ถ้ารู้คุณสมบัติบางอย่างของข้อมูล ก็ยังสั่งให้เขียน test ได้ด้วย
    ปัญหาคือต้องให้บริบทกับ LLM ว่าฉันกำลังทำอะไรอยู่ แต่ในการแชตแบบ ChatGPT เรามักไม่ให้บริบทนั้น หรือขี้เกียจจนให้ไม่ไหว ตรงนี้เองที่ Claude Code เปลี่ยนเกม
    เช่น สมมติว่ามีไฟล์ PCAP ที่มีหลายข้อความอยู่ในแต่ละ UDP packet จะกรอง IP, port, protocol, เวลาอย่างไร? ก็ใช้ LLM แล้วตรวจ output จะหาจำนวน packet ที่มีแพตเทิร์น A, AB, AAB, ABB ฯลฯ ได้อย่างไร? ก็ใช้ LLM แล้วตรวจ output จะสร้าง PCAP ที่มีแต่ packet แบบนั้นสำหรับทดสอบได้อย่างไร? ก็ใช้ LLM แล้วตรวจ output
    มันอ่านโค้ดได้ด้วย ดังนั้นพูดตรง ๆ คือ งานของคุณไม่ได้พิเศษอะไรนัก มันจึงอนุมานได้ดีกว่ามากว่าคุณกำลังพยายามทำอะไร อย่างไรก็ตาม แค่ความจริงที่ว่าสามารถสั่งว่า “เขียน unit test สำหรับฟังก์ชันทั้งหมดข้างบน” ได้ ก็ช่วยให้คุณตรวจสอบด้วยตัวเองได้แล้ว

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

  • นี่แทบจะเป็นการอ้างคำพูดจาก The Weatherman ที่ว่า “มันใช้ได้ทุกครั้งใน 60% ของกรณี”
    ฉันก็ใช้ gpt และ Claude ผ่าน Cursor ทุกวัน gpt o3 ค่อนข้างดีสำหรับการค้นหาความรู้ทั่วไป Claude มักพังบ่อย แต่ก็เห็นอยู่ไม่น้อยว่าระหว่างที่มันเปลือง token ไปกับการอวดตัวเอง มันก็แตะจุดที่เกี่ยวข้องกับปัญหาจริงได้
    โมเดลพวกนี้โง่ และใกล้เคียงกับแค่คนโง่มากกว่าจะเป็นอัจฉริยะงี่เง่า ถึงอย่างนั้นบางครั้งมันก็ทายรายการที่เกี่ยวข้องถูก ถ้าคุณพอรู้คร่าว ๆ ว่าอะไรควรเกิดขึ้น และปฏิบัติกับ LLM เหมือนสุนัขเทอร์เรียจับหนูในทุ่งนา คุณก็ใช้มันให้เกิดประโยชน์ได้
  • คำพูดนี้ก็ไม่ได้ดีกว่าคอมเมนต์ที่ผู้เขียนตำหนิเลย
    ตัวเลข 90% ก็ดูน่าสงสัยอยู่บ้าง

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

  • ฝ่ายคัดค้านมักชี้ข้อบกพร่องจริง ๆ ส่วนฝ่ายสนับสนุนมักยกย่อง LLM แบบไม่วิพากษ์วิจารณ์ว่าเป็น ปาฏิหาริย์ ที่แก้ปัญหาอะไรก็ได้ในครั้งเดียว โดยไม่มีรายละเอียดเฉพาะเจาะจง
  • การแปล การถอดเสียง และการสร้างโค้ดในระดับหนึ่ง เคยเป็นปัญหาที่แทบจัดการไม่ได้จริงหรือ?
    Google Translate, Whisper, และเครื่องมือสร้างโค้ดมีอยู่มานานพอสมควรแล้วโดยไม่ต้องมี LLM

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

  • นี่แทบจะเป็น use case เดียวของคริปโต และยังเป็นวัตถุประสงค์ที่มันถูกออกแบบมาอย่างชัดเจนด้วย นั่นคือ การต้านทานการเซ็นเซอร์
    นั่นจึงเป็นเหตุผลว่าทำไมจึงหาเรื่องที่มีประโยชน์ซึ่งคริปโตทำได้ในเศรษฐกิจที่ถูกกฎหมายได้ยาก เพราะมันถูกออกแบบมาเพื่อทำให้ธุรกรรมที่รัฐบาลไม่ต้องการหรือไม่สามารถส่งเสริมเกิดขึ้นได้ ในบางกรณีก็มีการประยุกต์ใช้เชิงมนุษยธรรม และก็มีการประยุกต์ใช้ที่ผิดกฎหมายจำนวนมากด้วย
  • ช่วยอธิบายสถานการณ์เพิ่มเติมได้ไหม? อยู่ประเทศไหน และใช้คริปโตที่นั่นอย่างไร?
  • ท่ามกลางกระแสโฆษณาเกินจริงไร้สาระทำนองว่า “ถ้าไม่เชื่อในความหมายที่แท้จริงของคริปโตก็โง่” นี่เป็น use case ที่ถูกต้อง
    “คุณต้องเคยอยู่ตรงนั้นถึงจะเชื่อได้” https://x.com/0xbags/status/1940774543553146956
    กระแส AI ตอนนี้ก็กำลังผ่านช่วงคล้าย ๆ กันอยู่ คำวิจารณ์ใด ๆ ถูกปัดว่าเป็นคำพูดของคนโง่ที่ไม่รู้อะไรเลย
  • จริง ๆ แล้วดูเหมือนไม่ได้พูดขัดกับมุกของผู้เขียนนะ คุณอยากใช้คริปโตเป็น เงินตรา ขณะที่ต้นฉบับน่าจะพูดถึงการหลอกลวงรอบ ๆ คริปโตในฐานะสินทรัพย์ลงทุนมากกว่า
    ถ้าใช้เป็นเงินตรา คนที่พยายามปั่นแล้วทุบเหรียญและใช้มันเป็นเครื่องมือหาเงินคือศัตรูของคุณ ยิ่งมันมีเสถียรภาพมากเท่าไร ก็ยิ่งดีต่อคุณเท่านั้น ไม่ใช่รถไฟเหาะที่พุ่งขึ้นพุ่งลง
  • เป็นปัญหาเดียวกับที่คริปโตเจอ แทบทุกคนกำลังเผยแพร่เรื่องโกหกเกี่ยวกับเทคโนโลยี และในนั้นหลายคนก็แค่ไม่เข้าใจมากพอจะรู้ว่าตัวเองกำลังโกหกอยู่ นี่คือความต่างระหว่างความใสซื่อกับเจตนาร้าย
    ผมมองว่าฝั่งคริปโตมีการโกหกโดยเจตนามากกว่า และมีคุณค่าที่ควรได้มาน้อยกว่า แต่ทั้งสองกรณี คนที่อาจได้ประโยชน์จริง ๆ กลับถอยออกไปตั้งแต่ยังไม่ทันเข้าประตู เพราะความไม่ซื่อสัตย์และการบิดเบือน และทั้งสองกรณีก็มีตัวอย่างที่ให้คุณค่าจริงในปัจจุบันอยู่

• เป็นเรื่องที่เกี่ยวข้องกันเล็กน้อย แต่ช่วงนี้ผมหงุดหงิดกับวิธีใช้คำว่า AGI และบางครั้งแม้แต่คำว่า AI โดยเฉพาะในบทความวิทยาศาสตร์ เราคาดหวังว่าทุกอย่างจะถูกนิยามไว้อย่างดี อย่างน้อยก็ต้องชัดเจนว่าบทความนั้นใช้คำนี้อย่างไร
  ทำไมถึงสร้างนิยามว่า AGI คืออะไรไม่ได้? ถ้ามีแล้วก็อาจพิสูจน์เชิงตรรกะได้ว่า AI ตัวไหนเข้ากับนิยามนั้นหรือไม่ ถึงในเชิงปฏิบัติจะดูไม่ค่อยมีประโยชน์นัก แต่ในเชิงทฤษฎีก็มีประโยชน์กว่าการใช้คำแบบไม่มีความหมายมาก
  ตอนนี้มันรู้สึกเหมือนเป็นทางหนีทีไล่ชนิดหนึ่ง Wikipedia เขียนว่า “ประเภทของ AI ที่เท่ากับหรือเหนือกว่าความสามารถของมนุษย์ในงานด้านความรู้ความเข้าใจแทบทั้งหมด” แล้วจะวัดอย่างไร? ถ้าพิสูจน์ไม่ได้ว่าระบบใดมีคุณสมบัตินี้ แล้วมันมีประโยชน์อะไร?
  อาจเป็นการบ่นนิดหน่อย แต่ก็หวังว่ายังพออ่านรู้เรื่อง

  • ไม่จำเป็นต้องมีฉันทามติโดยรวมก็ได้ ผมมีหลักไมล์ของตัวเองที่ผ่อนปรนกว่าเกี่ยวกับว่าอะไรคือ AGI แต่ไม่ได้คาดหวังว่าคนอื่นจะเห็นร่วมด้วย
    คล้ายกับที่สำหรับผม “crypto” ยังหมายถึงการเข้ารหัส ไม่ใช่คริปโตเคอร์เรนซี บางครั้งกระแสหลักก็แค่มีความเห็นต่างออกไป
  • มีนิยามอยู่แล้ว
    “AI คือสิ่งที่ยังทำไม่ได้”[1]
    1. https://en.wikipedia.org/wiki/AI_effect

• ไม่นานมานี้บริษัทเริ่มใช้ LLM และงานแรกคือถอดเสียงสายโทรศัพท์ลูกค้า 20,000 ครั้ง แล้วดึงข้อมูลต่อไปนี้ออกมา

  1. ผลิตภัณฑ์ของเรามักถูกนำไปเปรียบเทียบกับผลิตภัณฑ์ใด
  2. ผู้ใช้เจอปัญหาอะไรในซอฟต์แวร์ของเรา
  3. use case ที่ผู้ใช้พูดถึงบ่อยที่สุดคืออะไร
     งานวิจัยที่เมื่อก่อนต้องใช้เวลาหลายสัปดาห์ เสร็จได้ภายในไม่กี่ชั่วโมง มันช่วยในการวางกลยุทธ์ใหม่ และสร้าง มูลค่าทางธุรกิจ ได้จริง
     ผมมอง LLM เป็นแค่เอนจินประมวลผลภาษาธรรมชาติ และมันยอดเยี่ยมสำหรับการใช้งานแบบนั้น จริงอยู่ที่บางคนพูดเกินจริง แต่ก็ไม่ได้เปลี่ยนข้อเท็จจริงว่าในกรณีของเรา มันมีประโยชน์จริง ๆ ไม่เข้าใจว่าทำไมบทความ “LLM แย่” ถึงมีเยอะขนาดนี้ ถ้ามันไม่เหมาะกับคุณก็แค่ผ่านไป ทำไมใครต้องพิสูจน์อะไรให้ใครด้วย? มันก็แค่เครื่องมือ
  • คุณกำลังประเมิน ผลกระทบเชิงลบ ที่เกิดจากกระแสโฆษณาเกินจริงต่ำเกินไป มันบิดเบือนตลาด ทำให้เกิดการลงทุนเกินตัว ลดขนาดแผนกล่วงหน้า และสร้างความคาดหวังที่ไม่มีวันเป็นจริง
    บทความแบบนี้สำคัญต่อการลดความคาดหวังลง เวลา लोगขาย LLM พวกเขามักไม่ได้พูดถึงการสรุปสายซัพพอร์ตลูกค้า แต่พยายามขายแนวคิดว่าสามารถปลดพนักงานซัพพอร์ตลูกค้าได้
  • จริงมาก คนที่บอกว่า LLM ไม่มีประโยชน์จริง มักไม่เคยเจอปัญหาที่ต้องประมวลผลข้อมูลจำนวนมากด้วยวิธีที่ค่อนข้างเสถียร
    หลายปีที่ผ่านมา การแปลส่วนใหญ่บนเว็บไม่มี บริบท ตอนนี้มันสามารถมีบริบทได้แล้ว

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

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