- การถกเถียงเกี่ยวกับ LLM ในปัจจุบันเกิดขึ้นโดยแทบไม่มี หลักฐานเชิงปริมาณ ที่ชัดเจน
- ประสบการณ์ของผู้ใช้แต่ละคน กระจัดกระจายอย่างมาก และแทบไม่มีการแชร์ปัจจัยสำคัญอย่างสภาพแวดล้อมการใช้งานจริงหรือความรู้พื้นฐาน
- ด้วย คุณสมบัติแบบไม่กำหนดตายตัว แม้งานเดียวกันก็อาจให้ผลลัพธ์ต่างกันในแต่ละเวลา จึงมีข้อจำกัดด้านความน่าเชื่อถือ
- คำกล่าวอ้างเกินจริง ของผู้นำในอุตสาหกรรมกำลังผลักดันการยอมรับแบบไม่วิพากษ์วิจารณ์และความคาดหวังที่สูงเกินไป
- ผู้เขียนเองก็ใช้ เครื่องมือ AI หลากหลายแบบในชีวิตประจำวันจริง และแบ่งปันประสบการณ์ตรงว่ามีโอกาสเพียงราวครึ่งหนึ่งที่จะได้ผลลัพธ์ตามต้องการ
มุมมองต่อการถกเถียงและเทคโนโลยีรอบ LLM
คำวิจารณ์ต่อ LLM และบรรยากาศโดยรอบ
- ในการถกเถียงเรื่อง AI โดยเฉพาะ LLM (โมเดลภาษาขนาดใหญ่) ช่วงหลัง มักเกิดบรรยากาศที่มองมุมวิจารณ์ว่าเป็นเพียง "ความเห็นของคนที่ไม่เข้าใจเทคโนโลยีจริง"
- บน Hacker News และที่อื่น ๆ มักมีปฏิกิริยาซ้ำ ๆ ว่า "ถ้ายังต้องตั้งคำถามกับ AI ก็แปลว่ายังไม่เข้าใจแก่นแท้ของมัน"
ช่องว่างของประสบการณ์ระหว่างผู้ใช้
- มีความเห็นต่างกันระหว่างผู้ใช้ที่มองว่า LLM "ช่วยได้ในระดับหนึ่ง" กับผู้ใช้ที่บอกว่า "ลองทุกวิธีแล้วแต่แทบไม่มีประโยชน์"
- เหตุผลที่เกิดความต่างนี้คือ ไม่มีการแชร์เกณฑ์และข้อมูลที่เป็นรูปธรรมเกี่ยวกับประสบการณ์
- ใช้กับโปรเจกต์ประเภทไหน
- สถานะของโค้ดเบส (โปรเจกต์ใหม่, โค้ดที่พัฒนาเต็มที่แล้ว, ซอร์สแบบปิด ฯลฯ)
- ระดับความเชี่ยวชาญของผู้ใช้ และความเชี่ยวชาญนั้นเชื่อมโยงกับปัญหาจริงมากแค่ไหน
- ต้องลงแรงเพิ่มอีกเท่าไรเพื่อขัดเกลาผลลัพธ์จาก LLM และนำไปใช้งานจริงจนถึงขั้น deploy ได้อย่างเหมาะสม
ความยากในการเปรียบเทียบประสบการณ์และความไม่กำหนดตายตัว
- ต่อให้ผู้ใช้บางคนแชร์ข้อมูลทุกอย่างอย่างละเอียด ก็ยังแทบ เป็นไปไม่ได้ที่จะเปรียบเทียบประสบการณ์ กับผู้ใช้อีกคนได้อย่างแท้จริง
- LLM และเอเจนต์อัตโนมัตินั้นโดยธรรมชาติแล้ว ไม่กำหนดตายตัว
- แม้จะขอให้แก้ปัญหาเดียวกันด้วยวิธีเดียวกัน ก็ยังได้ ผลลัพธ์ต่างกันทุกครั้ง
- มีปัจจัยเปลี่ยนแปลงมากมาย เช่น ประเภทของโปรเจกต์ โมเดลที่ใช้ เครื่องมือ ภาษา ฯลฯ ทำให้ตรวจสอบแบบสม่ำเสมอได้ยาก
ผู้นำในอุตสาหกรรมและความคาดหวังที่เกินจริง
- มีหลายกรณีที่ผู้นำในอุตสาหกรรมเน้นย้ำความสำเร็จของ LLM มากเกินจริง
- ตัวอย่าง: ผู้นำรายหนึ่งเล่าว่าใช้ "Claude Code" แล้วแก้บั๊กเก่าได้อย่างน่าทึ่งและง่ายดาย โดยไม่ได้แชร์รายละเอียดเชิงลึก แต่กลับได้รับเสียงตอบรับอย่างกว้างขวาง
- ข้อมูลสำคัญอย่างขนาดของโค้ด ความยากของบั๊ก งานเพิ่มเติมที่ต้องทำ หรือภาษาโปรแกรมมิงและเฟรมเวิร์กที่ใช้ ถูกละไว้ ขณะที่มีเพียงข้อความเชิงบวกอย่างมากแพร่กระจายออกไป
- กรณีลักษณะนี้ได้รับ การตอบรับมากกว่า 1.8 พันครั้ง และการรีโพสต์ 204 ครั้ง ทำให้การตลาดแบบเกินจริงแพร่กระจายได้ง่าย
ประสบการณ์การใช้งานและการมองความเป็นจริง
- ผู้เขียนเองก็ใช้เครื่องมือ AI หลากหลายแบบทุกวัน เช่น Vercel's v0, Claude Code, Midjourney
- สร้างแอปมอนิเตอร์ด้วย SwiftUI ทั้งที่ไม่มีความรู้เรื่อง Swift
- ใช้ Midjourney สร้างโปสเตอร์สำหรับอีเวนต์แบบอัตโนมัติ
- เขียนฟังก์ชัน MCP server บนพื้นฐาน Elixir เป็นต้น
- แต่ โอกาสสำเร็จมีเพียงราว 50% และผลลัพธ์ก็ไม่เคยสม่ำเสมอ
- บางครั้ง LLM อาจให้ความรู้สึกเหมือน เวทมนตร์ แต่ในความเป็นจริงมันก็เป็นเพียงโมเดลเชิงสถิติที่ไม่กำหนดตายตัวเท่านั้น
- ผู้เขียนชี้ว่าในการถกเถียงของอุตสาหกรรมตอนนี้ ยังวนอยู่กับ การแบ่งแบบสองขั้ว (เวทมนตร์ vs. วิศวกรรม) เท่านั้น
บทสรุป
- แวดวง LLM และ AI มีแนวโน้มจะชื่นชอบ จินตนาการ ความคาดหวัง และความเชื่อที่เกินจริง มากกว่าระบบตรวจสอบที่แน่ชัดและชัดเจน
- สิ่งสำคัญคือการไม่หยุดคิดเชิงวิพากษ์ และพยายามตรวจสอบการทำงานกับประสิทธิผลจริงอย่างละเอียด
- สิ่งที่สำคัญในการถกเถียงคือ การแบ่งปันข้อมูลที่เป็นรูปธรรมและเชิงปริมาณ
- จำเป็นต้องมีมุมมองที่สมดุลต่อทั้งข้อจำกัดและความเป็นไปได้ของ LLM
1 ความคิดเห็น
ความเห็นจาก Hacker News
ผมหงุดหงิดที่ผู้บริหารในที่ทำงานผมได้ยินเรื่องเพิ่มผลิตภาพ 10 เท่า บางคนก็ได้ยินแบบนี้ตรง ๆ จากกลุ่มผู้ใช้ระยะแรกในบริษัทเราเองด้วย แต่ความคาดหวังแบบนั้นสูงเกินไป กฎของ Amdahl ก็มีส่วน เพราะเวลาส่วนใหญ่ของผมไม่ได้ใช้ไปกับการเขียนโค้ด แต่ใช้ไปกับการคิดและการสื่อสาร ต่อให้การเขียนโค้ดเร็วขึ้น 10 เท่าจริง ๆ (ซึ่งส่วนใหญ่ก็ไม่เป็นแบบนั้น) ผลิตภาพโดยรวมก็เพิ่มแค่ 10–15% เท่านั้น ถึงอย่างนั้นก็ยังเป็นผลลัพธ์ที่ค่อนข้างดี แต่อย่างไรก็ไม่ใช่ 10 เท่า
อาจเป็นเพราะงานปัจจุบันของผมมีลักษณะเป็น R&D มากกว่า LLM เลยช่วยในส่วนของ "การคิด" ได้มากพอ ๆ กับ "การเขียนโค้ด" (ส่วนการสื่อสารผมจัดการเองได้ดีอยู่แล้ว) การใช้ LLM ทำงานด้านความคิดให้ความรู้สึกคล้ายกับตอนที่เชี่ยวชาญการค้นหาบนเว็บเมื่อ 20 ปีก่อน สมัยก่อน search engine ต้องให้ผมรู้ก่อนว่ากำลังหาอะไร แต่ตอนนี้ LLM ช่วยหาตั้งแต่ระดับว่าเราควรค้นหาอะไร (และบางทีก็ค้นให้แทนด้วย) งานหลายอย่างที่เมื่อก่อนผมจัดว่าเป็นเรื่องยาก ตอนนี้แก้ได้ง่ายขึ้นเพราะ LLM ตอนนี้การค้นหาเว็บประมาณ 1/3 ของผมทำผ่าน ChatGPT o3 ไปแล้ว ผมนึกภาพไม่ออกเลยว่าจะเลิกใช้มันได้ยังไง นอกจากนี้ยังมีปัจจัยทางจิตใจที่ LLM ช่วยจัดระเบียบความคิดที่ยังไม่สมบูรณ์ของผมและทำหน้าที่เป็นคู่สนทนาให้ด้วย ทำให้หลายเรื่องน่ากลัวน้อยลงมาก และความต่างตรงนี้ก็สำคัญมาก
ที่บริษัทผมก็คล้ายกัน ตัวเลขเพิ่มผลิตภาพที่กลุ่มผู้ใช้ระยะแรกภายในองค์กรอ้างกัน มักวัดในกรอบที่แคบมาก หรือไม่ก็คิดเลขกันแบบหลวม ๆ
LLM อาจเร่งงานให้ senior developer ได้มากกว่า junior ก็ได้ (เพราะ junior แยกโค้ดดี/แย่ไม่ค่อยออก) senior คนหนึ่งที่ใช้ workflow แบบ LLM ได้ดี อาจทำงานได้ระดับเท่ากับ junior สิบคนในอดีตด้วยซ้ำ ในทางกลับกัน ถ้าเป็นนักพัฒนาที่ไม่เก่งจริง ๆ ก็อาจทำให้ผลิตภาพติดลบได้ด้วยซ้ำ (เพราะไปดึงเวลาของ senior มา) แม้แต่ junior ที่พอใช้ได้ก็อาจติดอยู่กับงานซ้ำ ๆ ที่ตอนนี้ LLM ทำได้ดีกว่าอยู่แล้ว เพราะงั้นผมเลยมองว่าอาชีพนี้อาจหายไปจริง ๆ ก็ได้
ถ้าการใช้เครื่องมือ LLM เพิ่มผลิตภาพได้แค่ 10–15% แต่ต้นทุนจ้างงานแพงขึ้น 10–15% เพราะต้องจ่ายค่าเครื่องมือ LLM ผมก็ไม่เห็นว่ามีข้อได้เปรียบพิเศษอะไร ต้องมองต้นทุนรวมของการผลิตด้วย
กับโปรเจกต์ส่วนตัวนี่เร็วขึ้นเกือบ 10 เท่าได้ง่าย ๆ แต่ในบริษัทมันไม่เข้ากับสภาพแวดล้อมที่ต้องคุยหลายทีม เปลี่ยน requirement และมี PR review การออกแบบที่ปรับเหมาะสุดและแพตเทิร์นมาตรฐานแบบนี้เกิดได้แค่ในสตาร์ตอัปขนาดเล็กหรือโปรเจกต์เดี่ยวเท่านั้น พอมีหลายคนเข้ามา แค่จะหาข้อสรุปร่วมกันก็ยากแล้ว ถ้า AI จะทำผลงานได้ดีที่สุด ทุกอย่างต้องเป็นมาตรฐาน แต่โลกจริงคือทุกอย่างคลาดกันไปคนละนิด เลยยากที่จะได้ผลขนาดนั้นในองค์กรจริง ถ้าเป็นนักพัฒนาไม่กี่คนที่มีแนวคิดตรงกัน การทำงานร่วมกันอาจไปถึง 10 เท่าได้ แต่ในสภาพแวดล้อมองค์กรแทบเป็นไปไม่ได้ ผมว่า AI เหมาะกับงาน middle management และ project planning มากกว่า
ผมนี่แหละคือฝั่งที่คนเขียนบทความกำลังบ่นถึง ตอนที่ ChatGPT ยังอ่อนมาก ผมก็ปล่อยผลิตภัณฑ์แบบ greenfield ออกมาแล้ว หลังจากนั้นก็ใช้ Claude กับการคัดลอกแปะระหว่างเว็บแชต~XCode แล้วต่อมาก็ใช้ Cursor ถึงจะมี build error บ่อย แต่ผลิตภาพก็เพิ่มอย่างน้อย 3 เท่าแน่ ๆ ตอนนี้ความสามารถของ agent ดีขึ้นและ Claude 4 ก็ออกมาแล้ว ผมแทบไม่เขียนโค้ดเองเลย ทำหน้าที่แนว Architect/Manager ใช้ความเชี่ยวชาญของตัวเองเพื่อคอยกำกับ agent ให้ถูกทาง ในสตาร์ตอัปผมไม่ได้เขียนโค้ดเองสักบรรทัดมาหลายเดือนแล้ว ผมตรวจทุกอย่างก่อนเปิด PR เอง และทดสอบอย่างเข้มงวด แต่ชุด Cursor+Sonnet นี่สุดจริง จำนวนบรรทัดไม่สำคัญเลย ตรงกันข้าม คนที่เชี่ยวชาญ codebase เดิมและอยู่กับมันมานานยังมาถามผมเรื่องบั๊กจุกจิกด้วยซ้ำ ผมยังระวังตัวอยู่เพราะถึงกับเข้าไปแตะงานของ frontend developer ได้ด้วยอาศัย Claude ผมไม่ได้แค่โยน query เข้าไป แต่บังคับให้มันผ่านกระบวนการ research, planning และ exploration แบบเป็นขั้นตอนอย่างละเอียด ความรู้โดเมนยังจำเป็นอยู่ดี แต่ก็ยังแปลกใจว่ามีคนที่ใช้สิ่งนี้ให้มีประโยชน์ขนาดนี้ไม่ได้ด้วย ผมรู้สึกว่าเห็นบทความแบบนี้อาทิตย์ละสองชิ้น
ผมก็มีประสบการณ์คล้ายกันแต่บริบทต่างกันนิดหน่อย (เป็นนักศึกษาปริญญาเอก) เดิมทีผมก็สงสัยเรื่อง LLM แต่หลังจาก Claude Code แล้ว วิธีทำงานเปลี่ยนไปหมด ถึงอย่างนั้นการคัดเลือกและกลั่นกรองยังเป็นหน้าที่ผมทั้งหมด (ซึ่งเป็น soft skill สำคัญที่ต้องเรียนในปริญญาเอก และเพราะ LLM มักหลุดเป้าหมายหรือบริบท หรือจำมันไว้ไม่ได้) ถ้าสื่อสารได้แม่นจริง ๆ เราจะจัดระเบียบการคำนวณด้วย CC ในแบบที่เมื่อก่อนไม่มีทางทำได้ การเขียนโปรแกรมไม่ได้ง่ายขึ้น แต่มันกลายเป็นรูปแบบการทำงานคนละแบบไปเลย
ผมสงสัยเรื่องกระบวนการตรวจสอบจริง ๆ เช่น ตรวจโค้ดที่เชื่อถือไม่ได้จาก LLM อย่างไร หรือ LLM เขียน unit test ให้ด้วยไหม และความยาว prompt โดยเฉลี่ยประมาณไหน
มีคนทักว่าคุณเชื่อผลลัพธ์จาก LLM ตรง ๆ เลยหรือ เพราะ LLM มองบริบททั้งโปรเจกต์ไม่ออก และมักพูดเพ้อฝัน (hallucination) เลยจำเป็นต้องมีการตรวจสอบ
ผมรู้สึกว่าคุณภาพโค้ดจาก LLM โดยรวมยังต่ำมาก ต้องวนแก้หลายรอบจนบางทีเขียนเองยังเร็วกว่า แต่สำหรับการทำ mechanical refactoring ขนาดใหญ่ agent มีประโยชน์มาก ผมใช้ agent แทนการเขียน vim macro ซับซ้อน ๆ หรือ AST script
ส่วนตัวคิดว่าการไม่ได้เขียนโค้ดเองสักบรรทัดมาหลายเดือนนี่น่าเบื่อมาก
เนื้อหาที่คุณเล่ากลับยืนยันข้ออ้างจากโพสต์บล็อกนั้นตรง ๆ เลย ทั้งเรื่องตรวจสอบไม่ได้หรือชอบอ้างผลลัพธ์มหาศาล แถมดูเหมือนบัญชีที่เพิ่งสร้างใหม่ด้วย
ผมคิดว่าแรงงานจริงในภาคบริการส่วนใหญ่เป็นงานใช้มืออย่างย้ายข้อมูลใน Excel sheet หรือย้ายข้อมูลจาก CRM/อีเมลไปลง Excel ในบริษัทใหญ่ ๆ น่าจะมีพนักงานประจำที่ทำงานซ้ำ ๆ แบบนี้มากกว่าวิศวกรซอฟต์แวร์สักร้อยเท่า ดังนั้นต่อให้ LLM ทำ OCaml ไม่ได้ก็ไม่สำคัญ ถ้ามันเก่งกว่าแรงงานมนุษย์ใน Excel แค่นิดเดียวก็มหาศาลแล้ว ถ้าเอาพวกมันมาเชื่อมอีเมล-CRM-Excel ด้วยอะไรอย่าง MCP แล้วทำอัตโนมัติ อัตราความผิดพลาดหรือ hallucination ก็จะลดลงมาก มนุษย์เองก็ไม่ได้มีความแน่นอนตายตัว เพราะงั้นในกระบวนการแบบนี้ความเป็น deterministic ไม่ได้สำคัญ LLM กับคริปโตนั้นต่างกันโดยสิ้นเชิงทั้งด้าน utility และการยอมรับใช้งาน มันทำให้ผมนึกถึงตอนสมาร์ตโฟนแพร่หลาย เพื่อนผมที่ไม่ใช่สายเทคก็ใช้ LLM กันหลากหลายมากแล้วตอนนี้
ผมว่าการเปรียบเทียบกับคริปโตไม่ค่อยสร้างสรรค์ เพราะในเชิงเทคนิคแล้วไม่เกี่ยวกันเลย แต่ก็มีปรากฏการณ์เชื่อเทคโนโลยีเกินจริงอยู่ ตอนนี้สำหรับคนที่ยังไม่เคยเจอแม้แต่ automation พื้นฐาน LLM อาจดูเหมือนนิยายวิทยาศาสตร์ได้ สาขานี้ไม่เคยแมสระดับนี้มาก่อน ต่อจากนี้คงเป็นยุค wild west ที่มีทั้งความสำเร็จ ความล้มเหลว ความเห็นหลากหลาย และประสบการณ์ใช้งานจริงปนกันไป ข้อดีคือเดี๋ยวนี้แม้แต่ไอเดียแอปของเพื่อนคุณก็ลองทำเองได้แล้ว
พนักงาน FTE (Full-time Employee) ที่ทำ data cleansing แบบ manual ก็ยังต้องมีหน้าที่ตรวจผล รักษา deadline และรับผิดทางกฎหมายด้วย LLM ไม่สามารถรู้ข้อยกเว้นชั่วคราวได้จากนอกบริบท (เช่น วันหยุดจึงควรมีค่าเป็น 0) แล้วคอยตรวจให้ งานตรวจสอบแบบนี้มีค่าพอจะจ้าง FTE คนหนึ่งได้สบาย
ผมสงสัยว่าตัวเลขพนักงาน FTE งาน data pipelining แบบ manual 100 คนต่อ software engineer 1 คน นี่ใช้ได้กับบริษัทแบบไหน เพราะผมไม่คิดว่างาน back office/data entry คือแรงงานส่วนใหญ่จริง ๆ ผมเห็นด้วยว่า AI จะมีผลกระทบมาก แต่ยังสงสัยกับข้ออ้างว่าพนักงาน white-collar เกือบทั้งหมดคือคนทำอีเมล+data entry
ผมคิดว่าคุณกำลังประเมินความซับซ้อนของงานประเภทนี้ต่ำไป
ในฐานะโปรแกรมเมอร์ที่เกษียณแล้ว ผมนึกภาพไม่ออกว่าจะยอมเอาความรับผิดชอบระดับ mission-critical ไปฝากไว้กับโค้ดที่สร้างจากความน่าจะเป็น ถ้าบอกว่าเอามาแก้นิดหน่อยแล้วใช้ต่อได้ ผมพอเข้าใจ แต่ในงานนอกเหนือจากการเขียนโค้ด (เช่น brainstorming, creative thinking, research support) LLM น่าทึ่งมาก ผมใช้ LLM เป็นเหมือนคู่คิด มันก็พลาดบ้าง แต่ถ้าตรวจทานกับแหล่งอื่นหรือให้ LLM ตัวอื่นช่วยรีวิว ก็จับได้ง่าย
ผมเองก็เป็นคนขี้สงสัยโดยธรรมชาติ แต่พอได้ใช้จริงมันเกินความคาดหวังทุกด้าน ผมดันโปรเจกต์ที่ปกติต้องใช้เวลาหลายเดือนให้ไปถึงขั้น prototype~launch ได้ภายในไม่กี่ชั่วโมง งานที่ผมทำได้อยู่แล้วก็ทำได้เร็วขึ้น งานที่ปกติทำไม่ได้ (ต้องจ้างคนนอกหรือรับคนเพิ่ม) ก็ทำได้ด้วยต้นทุนเล็กน้อยและเร็วมาก แน่นอนว่ามันไม่สมบูรณ์และมีเรื่องน่าหงุดหงิดเยอะ (เช่น เมินคำสั่งชัด ๆ หรือโกหก) แต่สำหรับผมมันคือ game changer
การใช้ LLM เป็นคู่คิดดูเหมือนจะเวิร์กอยู่พักหนึ่ง แต่พอถึงจุดหนึ่งจะเริ่มเห็นความเพ้อฝันของมัน LLM เก่งมากในการทำให้เราหลงว่ามันมีความรู้หรือกำลังใช้เหตุผล โดยเฉพาะในเรื่องที่เราไม่รู้ ยิ่งอันตราย Search engine ยังพอเทียบความน่าเชื่อถือจากแหล่งที่มาได้ แต่ LLM ทำแบบนั้นไม่ได้ และการจับผิดพลาดก็ไม่ได้ง่ายเสมอไป
ผมเป็นนักพัฒนา 40 ปี เริ่มใช้ LLM เมื่อไม่กี่เดือนก่อน แล้ววิธีทำงานเปลี่ยนไปมาก แปะข้อความ error จาก log เข้าไปก็ได้ทางแก้ใน 1 นาที ใช้ brainstorm ด้านการออกแบบ และเสนอทางออกใหม่ ๆ ผมยังตรวจโค้ดอยู่ แต่ก็ยังทึ่งกับความแม่นยำและความฉลาดของมันทุกวัน (มันต่างจากคริปโตโดยสิ้นเชิง)
ผมเป็นฝั่งสงสัย LLM เหมือนกัน แต่จริง ๆ แล้วโค้ดทุกบรรทัดที่มนุษย์เขียนก็เป็นผลลัพธ์เชิงความน่าจะเป็นในตัวมันเองอยู่แล้ว นั่นจึงเป็นเหตุผลที่มี code review, unit test, pair programming และ guideline เราไม่ควรใช้ผลลัพธ์จากทั้ง LLM หรือมนุษย์แบบไม่วิจารณ์ อย่างไรก็ตาม LLM ไม่ใช่เวทมนตร์ และผมห่วงว่ามันจะถูกใช้ผิดทางเพื่อพ่น boilerplate ออกมาเรื่อย ๆ โดยไม่สนคุณค่าระยะยาวอย่างประสิทธิภาพ ความปลอดภัย หรือ refactoring ที่ดี
ผมคิดว่าสิ่งที่ LLM ทำได้ดีที่สุดคือ data science เพราะ IO ชัดเจน ทำให้ตรวจผลได้ง่าย ถ้าคุณรู้คุณสมบัติของข้อมูลเฉพาะชุดอยู่แล้ว ก็สั่งให้มันสร้าง test code ได้ง่ายด้วย ถ้าต้องการบริบท Claude Code เปลี่ยนเกมมาก ตัวอย่างเช่น การดึงหลายข้อความภายในแต่ละ UDP packet จากไฟล์ PCAP, การกรอง, การจับแพตเทิร์น, การแยกเพื่อทดสอบ ฯลฯ ถ้าพูดว่า "ช่วยเขียน unit test ให้ทุกฟังก์ชันนี้หน่อย" LLM ก็ตรวจตนเองต่อได้ด้วย
ผมใช้ LLM แทบทุกวันมา 1 ปีแล้ว และ 90% ของเวลาก็ช่วยแก้ปัญหาให้ผมได้ ผมไม่รู้ว่าความเห็นเชิงลบต่อ AI/LLM ควรถูกมองจริงจังตอนไหน จากประสบการณ์ผม ไม่เคยมีการยัด codebase ทั้งก้อนเข้าไปแล้วหวังปาฏิหาริย์ ผมถามเฉพาะคำถามที่แม่น ชัดเจน และเป็นเรื่องที่ตัวเองรู้/เข้าใจ พร้อมทั้งนำวิธีแก้ไปใช้แบบที่ตรวจสอบได้ ถ้าไม่ได้ใช้แบบนี้ ก็แปลว่าใช้ LLM ผิดวิธี ถ้าอยากเจอความมหัศจรรย์จริง ๆ หัวใจคือการใช้แบบเล็ก ๆ ในชีวิตประจำวัน และใช้อย่างสม่ำเสมอ
มีคนเหน็บแบบล้อ Weatherman ว่า "มันทำงานได้เสมอด้วยความน่าจะเป็น 60%" ผมเองก็ใช้ GPT กับ Claude ผ่าน Cursor ทุกวัน GPT o3 ดีสำหรับค้นหาความรู้ทั่วไป ส่วน Claude บางทีก็พลาด ตัวโมเดลเองก็ดูโง่ ๆ แต่บางครั้งก็จับประเด็นสำคัญได้เหมือนกัน ผมคิดว่าถ้าคุณรู้เองว่าต้องการอะไร และฝึก LLM ให้เชื่องเป็น ก็ใช้มันอย่างมีประสิทธิภาพได้
มีความเห็นว่าคำพูดแบบ "จากประสบการณ์ผม มันเวิร์ก 90%" ฟังแล้วก็ยังไม่น่าเชื่อถือเท่าไร
ดูเหมือนคนเขียนต้นฉบับจะโกรธพวกนักวิจารณ์ที่ให้ความเห็นไม่แม่นยำ แต่ในความเป็นจริง ผมคิดว่าคนที่ใช้ LLM ทุกวันและสนับสนุนมันนี่แหละรู้ปัญหาและข้อจำกัดของมันดีที่สุด เพราะต้องเจอมันทุกวัน ขณะเดียวกัน ปัญหาที่เดิมทีทำไม่ได้เลยหรือแทบทำไม่ได้ เช่น การแปล การถอดเสียง และการสร้างโค้ด (ในขนาดหนึ่ง) ตอนนี้ถูกแก้ได้หมดหรือเกือบหมดแล้ว
มีคนแย้งว่าการแปล การถอดเสียง และการสร้างโค้ด นี่เมื่อก่อนมันถึงขั้นแทบเป็นไปไม่ได้จริงหรือ ก็มี Google Translate, Whisper และเครื่องมืออื่น ๆ มานานแล้วนี่
คนที่เปิดโปงข้อบกพร่องจริง ๆ คือ detractor (ผู้วิจารณ์) มากกว่า ขณะที่ promoter (ผู้เชิดชู) ต่างหากที่มักยก LLM ให้เป็นของสารพัดประโยชน์โดยไม่วิจารณ์อะไรเลย
ช่วงนี้ผมรู้สึกว่าการใช้คำว่า AGI, AI โดยเฉพาะในงานวิจัยวิทยาศาสตร์ มันคลุมเครือเกินไปมาก อย่างน้อยอยากให้แต่ละงานวิจัยกำหนดนิยามของตัวเองให้ชัด ถ้ากำหนดชัดว่า AGI คืออะไร เราก็อาจพิสูจน์เชิงตรรกะได้ว่า AI ตัวหนึ่งผ่านนิยามนั้นหรือไม่ ถึงมันอาจดูไม่มีประโยชน์ใช้งานจริง แต่ก็ยังดีกว่าคำที่ไม่มีความหมาย ตอนนี้เหมือนใช้คำว่า AGI แบบพร้อมจะวิ่งหนีจากการนิยาม Wikipedia บอกว่าเป็น "งานด้านการรับรู้แทบทั้งหมดที่มนุษย์ทำได้เทียบเท่าหรือดีกว่า" แต่ก็วัดไม่ได้ เลยอดสงสัยไม่ได้ว่าทำไมต้องใช้คำกลวงแบบนี้
ไม่จำเป็นว่าทุกคนต้องใช้คำนี้ในความหมายเดียวกันก็ได้ แค่คุณมีเกณฑ์ของตัวเองสำหรับคำว่า AGI ก็พอ (แม้คนส่วนใหญ่จะไม่เห็นด้วยก็ตาม) สำหรับผม crypto ก็ยังหมายถึง cryptography อยู่เหมือนเดิม มาตรฐานกระแสหลักกับมาตรฐานส่วนตัวอาจต่างกันได้
ถ้าจะให้นิยาม AI แบบหนึ่ง ก็คือ "อะไรก็ตามที่ยังทำไม่สำเร็จ เราเรียกมันว่า AI" พร้อมลิงก์อธิบาย AI effect
ที่บริษัทผมเพิ่งเริ่มใช้ LLM งานแรกคือถอดเสียงสายคอลเซ็นเตอร์ลูกค้า 20,000 สายและดึงข้อมูลออกมา (เช่น สินค้าที่เปรียบเทียบ ปัญหาที่พบ และ use case ตัวแทน) งานวิจัยที่เมื่อก่อนต้องใช้เวลาหลายสัปดาห์ ตอนนี้จบในไม่กี่ชั่วโมง เรายังวางกลยุทธ์ธุรกิจใหม่จากสิ่งนี้ได้ และได้คุณค่าจริงมาก LLM ยอดเยี่ยมมากในฐานะ natural language processing engine มันมีการโฆษณาเกินจริงเยอะก็จริง แต่สำหรับพวกเรามันช่วยได้จริงในทางปฏิบัติ มันก็เป็นแค่เครื่องมือชิ้นหนึ่ง ผมไม่รู้สึกว่าต้องพิสูจน์อะไรให้ใครดู
ผมคิดว่าการโฆษณาเกินจริงไม่ได้ไร้พิษภัย เพราะมันทำให้ตลาดบิดเบือน ลงทุนเกินตัว ลดขนาดองค์กร และสร้างความคาดหวังที่เป็นไปไม่ได้ บทความแบบนี้จึงจำเป็นเพื่อช่วยลดความร้อนแรงของตลาด/ความคาดหวัง คนที่ขาย LLM มักไม่ได้พูดแค่เรื่องสรุปสายคอล แต่ชอบเล่าภาพฝันเกินจริงว่าจะเอาไปแทนคนได้สารพัด
ดูเหมือนว่ามีแต่คนที่ไม่เคยมีประสบการณ์แก้ปัญหาการประมวลผลข้อมูลจำนวนมากแบบเชื่อถือได้เท่านั้นที่บอกว่า LLM ไม่มีประโยชน์ ตอนนี้แม้แต่การแปลก็ทำได้เข้าใจบริบทกว่ามากแล้ว
คนในวงการเทคที่น่าเชื่อถือหลายคนก็พูดตรง ๆ ว่า GenAI ช่วยเพิ่มผลิตภาพการพัฒนาได้มาก ความหมายของคำว่า "มาก" จะกว้างตั้งแต่ 5%~100% ก็แล้วแต่ อย่างน้อยที่สุดผมคิดว่าเราควรยอมรับว่ามันเป็นเครื่องมือที่มีประโยชน์พอสมควร และไม่จำเป็นต้องมีตัวเลขเฉพาะเจาะจงอย่างจำนวนบรรทัดโค้ด ไบต์ หรือ CPU มาอ้างเพื่อพูดแบบนี้
เทคโนโลยี LLM ก็คงมีที่ทางการใช้งานที่เหมาะสมของมันในท้ายที่สุด แต่ตอนนี้คนจำนวนมากเกินไปใช้มันผิดทางไปแล้ว จนคงย้อนกลับไม่ได้ นักพัฒนาระดับต้นจำนวนมากจะเสี่ยงและล้มเหลว การลงทุนจำนวนมากจะสูญเปล่า และบริษัทต่าง ๆ ก็อยู่ในสภาพทุ่มหมดหน้าตักจนถอนตัวยากแล้ว