- Martin Fowler ชี้ว่า แบบสำรวจเกี่ยวกับวิธีใช้งาน LLM ในช่วงหลังอาจนำไปสู่ข้อสรุปที่บิดเบือนได้ เพราะไม่สะท้อนรูปแบบการใช้งานจริง
- สำหรับคำถามเรื่องอนาคตของการเขียนโปรแกรมหรือความมั่นคงของอาชีพนั้น ยังไม่มีใครตอบได้อย่างแน่ชัด และสิ่งสำคัญคือการทดลองด้วยตนเองและแบ่งปันประสบการณ์
- อุตสาหกรรม AI อยู่ในภาวะ ฟองสบู่ อย่างชัดเจน แต่ในทางประวัติศาสตร์ นวัตกรรมทางเทคโนโลยีทุกครั้งก็เป็นเช่นนั้น และแม้หลังฟองสบู่แตกก็อาจยังมี บริษัทที่อยู่รอดแบบ Amazon เกิดขึ้นได้
- แก่นแท้ของ LLM คือ การหลอน (hallucination) และกระบวนการตั้งคำถามหลายรูปแบบแล้วนำคำตอบมาเปรียบเทียบกันนั้นมีประโยชน์ในตัวเอง
- LLM ทำให้ พื้นผิวการโจมตี ของระบบซอฟต์แวร์ขยายใหญ่ขึ้นมาก และเตือนว่าโดยเฉพาะเอเจนต์บนเบราว์เซอร์มีความเสี่ยงเชิงโครงสร้างที่ไม่อาจทำให้ปลอดภัยได้อย่างแท้จริง
วิธีใช้ LLM และประสิทธิภาพการทำงานของนักพัฒนา
- ช่วงหลังมีการถกเถียงกันอย่างคึกคักเกี่ยวกับผลกระทบระยะแรกของ AI ต่อการพัฒนาซอฟต์แวร์
- การใช้งาน LLM ส่วนใหญ่มุ่งไปที่การทำงานแบบ auto-complete ขั้นสูง (ลักษณะ co-pilot)
- อย่างไรก็ตาม ผู้ที่ใช้ LLM ได้อย่างมีประสิทธิภาพที่สุดในความเป็นจริงมักชอบ ใช้ LLM ในลักษณะที่สามารถอ่านและแก้ไขไฟล์ซอร์สโค้ดได้โดยตรง
- แบบสำรวจที่มองข้ามความแตกต่างของวิธีใช้ LLM มีความเสี่ยงสูงที่จะ ตีความข้อมูลไปในทิศทางที่ผิด
- นอกจากนี้ ความแตกต่างด้านความสามารถ ของโมเดล LLM แต่ละตัวก็ยิ่งทำให้การตีความผลลัพธ์ยากขึ้น
อาชีพโปรแกรมเมอร์และอนาคตของ LLM
- มีคำถามเกิดขึ้นบ่อยเกี่ยวกับอนาคตของการเขียนโปรแกรม ความจำเป็นของวิศวกรมือใหม่ และอนาคตของผู้มีประสบการณ์
- ต่อคำถามเหล่านี้ยังไม่อาจให้คำตอบที่ชัดเจนได้ เพราะ เรายังอยู่ในช่วงที่วิธีใช้ LLM อย่างมีประสิทธิผลยังไม่ถูกสถาปนาแน่ชัด
- สิ่งที่จำเป็นคือ แนวทางเชิงทดลอง และท่าทีที่คอยสังเกตและแบ่งปันประสบการณ์เวิร์กโฟลว์ที่เป็นรูปธรรมของผู้อื่น
- การลองใช้ด้วยตัวเองและแบ่งปันประสบการณ์คือ วิธีปรับตัวที่ชาญฉลาดที่สุด
ปรากฏการณ์ฟองสบู่ในวงการ AI·LLM
- ต่อมุมมองที่ว่า AI เป็นฟองสบู่ มีการอธิบายว่า นวัตกรรมทางเทคโนโลยีทุกครั้งล้วนมาพร้อมภาวะฟองสบู่
- ฟองสบู่ย่อมแตกลงในสักวัน และย่อมมีการลงทุนที่ล้มเหลวเกิดขึ้น
- อย่างไรก็ตาม ช่วงเวลาที่ฟองสบู่จะแตกและขนาดของมูลค่าที่จะถูกสร้างขึ้น นั้นไม่อาจคาดการณ์ได้
- แม้ฟองสบู่จะแตก ไม่ใช่ว่าทุกบริษัทจะหายไปทั้งหมด และบางส่วนก็อาจ เติบโตต่อเนื่อง ได้
- ในยุคฟองสบู่ดอตคอม pets.com, Webvan ล้มเหลว แต่ Amazon เป็นตัวอย่างเด่นของบริษัทที่อยู่รอดและเติบโตต่อ
คุณลักษณะการหลอนของ LLM
- ปรากฏการณ์ การหลอน (Hallucination) ของ LLM ไม่ใช่ข้อบกพร่อง แต่เป็นคุณลักษณะโดยเนื้อแท้
- โดยท้ายที่สุดแล้ว LLM คือเครื่องมือสำหรับ สร้างการหลอนที่ใช้งานได้จริง
- แนวทางที่เหมาะสมคือถามคำถามเดิมหลายครั้ง โดยปรับถ้อยคำให้หลากหลาย เพื่อ รับหลายคำตอบแล้วนำมาเปรียบเทียบกัน
- ในกรณีที่ต้องการคำตอบเชิงตัวเลข ควร ตรวจสอบความผันแปรระหว่างคำตอบด้วยการถามซ้ำ
- ไม่เหมาะที่จะให้ LLM ตอบปัญหาที่ สามารถคำนวณแบบกำหนดแน่นอนได้โดยตรง
การนำความไม่เป็นเชิงกำหนดเข้าสู่วิศวกรรมซอฟต์แวร์
- วิศวกรรมซอฟต์แวร์แบบดั้งเดิมถูกออกแบบและพัฒนาขึ้นใน สภาพแวดล้อมที่เป็นเชิงกำหนด
- วิศวกรโครงสร้างและวิศวกรกระบวนการจะออกแบบค่าคลาดเคลื่อนโดยคำนึงถึง ความไม่เป็นเชิงกำหนด (ความไม่แน่นอน) ของโลกจริง
- การนำ LLM มาใช้อาจเป็นจุดเปลี่ยนที่ทำให้วิศวกรรมซอฟต์แวร์ ก้าวเข้าสู่โลกของความไม่เป็นเชิงกำหนด
การเปรียบเทียบ LLM กับนักพัฒนารุ่นจูเนียร์
- LLM มักถูกเปรียบว่าเป็น เพื่อนร่วมงานระดับจูเนียร์
- แต่ LLM มักพูดว่า "ผ่านทุกเทสต์" ทั้งที่ในความเป็นจริง ยังมีเทสต์ที่ล้มเหลวให้เห็นอยู่บ่อยครั้ง
- หากเป็นมนุษย์ นี่คงเป็นพฤติกรรมที่นำไปสู่ปัญหาด้านบุคลากรได้อย่างรวดเร็ว
ภัยคุกคามด้านความปลอดภัยที่เพิ่มขึ้นและปัญหาของเอเจนต์บนเบราว์เซอร์
- LLM ขยาย พื้นผิวการโจมตีของระบบซอฟต์แวร์ ออกไปอย่างกว้างขวาง
- 'ปัจจัยสามประสานร้ายแรง (Trifecta)' ที่ Simon Willison ชี้ไว้คือ การเข้าถึงข้อมูลที่ไม่เปิดเผย, การสื่อสารภายนอก, และการเผชิญกับคอนเทนต์ที่ไม่น่าเชื่อถือ
- สามารถหลอก LLM ให้ รั่วไหลข้อมูลอ่อนไหว ได้ผ่านคำสั่งที่ซ่อนอยู่บนหน้าเว็บ (เช่น ตัวอักษรสีขาวขนาด 1pt เป็นต้น)
- เอเจนต์ที่ทำงานบนเบราว์เซอร์มีความเสี่ยงเป็นพิเศษ และอาจถูกใช้ให้ทำ การกระทำอันเป็นอันตราย เช่น โอนเงินจากบัญชี ผ่านคำสั่งภายนอก
- Willison เสนอความเห็นว่า ส่วนขยายเบราว์เซอร์แบบเอเจนต์ไม่อาจทำให้ปลอดภัยได้อย่างถึงราก
บทสรุป
- LLM เปิด ความเป็นไปได้ใหม่ ให้กับการพัฒนาซอฟต์แวร์ แต่ต้องเข้าใจวิธีใช้และข้อจำกัดของมันอย่างชัดเจน
- ฟองสบู่ เป็นสิ่งที่หลีกเลี่ยงไม่ได้ แต่ก็อาจนำไปสู่การพัฒนาเทคโนโลยีที่ยั่งยืนได้
- นักพัฒนาควรใช้ แนวทางเชิงทดลอง และ คำนึงถึงความปลอดภัย เพื่อดึงศักยภาพของ LLM ออกมาให้ได้มากที่สุด
3 ความคิดเห็น
แค่คิดก็รู้สึกอึดอัดขึ้นมาแล้ว…
> การนำความไม่เป็นเชิงกำหนดเข้ามาในวิศวกรรมซอฟต์แวร์
> วิศวกรรมซอฟต์แวร์แบบดั้งเดิมถูกออกแบบและพัฒนาขึ้นในสภาพแวดล้อมที่เป็นเชิงกำหนด
> วิศวกรโครงสร้างและกระบวนการออกแบบค่าความคลาดเคลื่อนโดยคำนึงถึงความไม่เป็นเชิงกำหนด (ความไม่แน่นอน) ของโลกความจริง
> การนำ LLM มาใช้อาจเป็นจุดเปลี่ยนที่ทำให้วิศวกรรมซอฟต์แวร์ก้าวเข้าสู่โลกของความไม่เป็นเชิงกำหนด
เห็นด้วยกับอุปมาเรื่องจูเนียร์เป็นพิเศษแบบ 100% เลยครับ หมวดหมู่ของความผิดพลาดที่มันก่อขึ้นต่างจากของคน... ผมคิดว่านี่เป็นอุปมาที่พังแบบตัวอย่างชัดเจนเลยครับ
ความคิดเห็นจาก Hacker News
Rebecca Parsons อดีตเพื่อนร่วมงานของฉันพูดมานานแล้วว่าอาการหลอนของ LLM (hallucination) ไม่ได้เป็นบั๊ก แต่เป็นฟีเจอร์หลักของมันด้วยซ้ำ จริง ๆ แล้วสิ่งที่ LLM ทำคือสร้างอาการหลอนที่มีประโยชน์ขึ้นมา ทุกครั้งที่ได้ยินข้ออ้างแบบนี้ ฉันมักรู้สึกว่าเป็นการนิยามคำว่า "อาการหลอน" ใหม่ตามใจชอบ แล้วทำให้มันดูเหมือนเป็นอินไซต์ใหม่ ทั้งที่เดิมคำว่า 'อาการหลอน' หมายถึงการสร้างรายละเอียดที่ไม่เกี่ยวกับความจริงขึ้นมาอย่างแนบเนียนราวกับรับรู้ได้จริง แต่ตรรกะนี้ก็ไม่ต่างจากการพูดว่า "เอาต์พุต" เฉย ๆ ไม่ใช่ว่าการที่ LLM สร้างเอาต์พุตเป็นเรื่องใหม่ มันแค่เอาป้ายกำกับที่แต่ก่อนมองว่า 'ไม่ดี' มาแปะกับพฤติกรรมทั้งหมดเพื่อให้ดูใหม่เท่านั้น
ผมไม่คิดว่า Fowler กำลังนิยามคำว่า "อาการหลอน" ใหม่จริง ๆ ตรงกันข้าม เขากำลังเน้นแบบประชด ๆ ว่านี่คือวิธีทำงานพื้นฐานของระบบนี้ คล้ายกับการพูดว่า "ความเสียหายข้างเคียงเป็นส่วนสารัตถะของระเบิด" ไม่จำเป็นต้องตีความตามตัวอักษร
ข้อโต้แย้งนี้ต้องการแก้การมองแบบทวิภาคที่ผิด ๆ ประมาณว่า “LLM ไม่ก็สร้างความจริง ไม่ก็สร้างอาการหลอน” เพราะการพูดแบบนั้นทำให้ดูเหมือนว่าแค่ลดอาการหลอนลง ก็จะเหลือแต่ความจริง ทั้งที่จริงแล้วเอาต์พุตทั้งหมดก็เป็นอาการหลอนชนิดหนึ่ง เพียงแต่บางส่วนสะท้อนความเป็นจริงหรือสอดคล้องกับความคาดหวัง จึงดูเหมือนจริง มันก็เหมือนเวลาทอยลูกเต๋าแล้วได้เลขที่ต้องการ จากนั้นบอกว่า "ลูกเต๋าอ่านใจฉันได้" เหมือนกับลิงอนันต์ที่พิมพ์บนเครื่องพิมพ์ดีดอนันต์แล้วสักวันหนึ่งจะได้ Hamlet ขึ้นมา เพียงแต่เราเพิ่มความน่าจะเป็นนั้นด้วย AI
ฉันคิดว่าความเห็นนั้นน่าสนใจ การยอมรับว่า LLM ไม่สามารถรู้ได้ว่าสิ่งที่มันสร้างออกมาถูกต้องหรือไม่ ช่วยให้คนที่นำ LLM มาใช้ในการพัฒนาซอฟต์แวร์มีบริบทเชิงปฏิบัติมากขึ้น
ฉันรู้สึกไม่สบายใจกับการใช้อธิบายปรากฏการณ์นี้ด้วยคำว่า "อาการหลอน" เวลาเราพูดถึงคนที่พูดเรื่องฟังดูน่าเชื่อถือขึ้นมาโดยไม่มีหลักฐาน เรามักเรียกว่า "bullshit" และ LLM ก็แทบจะเป็นแบบนั้นเหมือนกัน ถ้ามองจากมุมของ "bullshit" การวิจารณ์การใช้ LLM ก็จะดูไร้น้ำหนักลงอีก สุดท้าย ถ้าคุณรับด้านนี้ของ LLM ไม่ได้ คุณก็คงทำงานกับคนไม่ได้เหมือนกัน เพียงแต่คำว่า "bullshit" นั้นนิยามใหม่ยากกว่ามาก ถึงอย่างนั้น ฉันก็คิดว่าบทความนั้นทำหน้าที่ของมันได้ดีในฐานะชุดความคิดที่กระจัดกระจาย และผู้เขียนก็ดูไม่ได้พยายามวางท่าผู้มีอำนาจอะไร
เขาพูดประเด็นหลักได้ค่อนข้างกระอักกระอ่วน แต่ใจความจริง ๆ คือไม่มีเส้นแบ่งชัดเจนระหว่างเอาต์พุตแบบ 'อาการหลอน' กับเอาต์พุตแบบอื่น ๆ เหมือนกับที่ผลลัพธ์ของสองคิวรีใน RDBMS มีสารัตถะเดียวกัน ถือเป็นข้อสังเกตที่มีความหมาย
ที่บริษัทเราให้ความรู้สึกเหมือนมีโค้ดกองเต็มไปหมดที่ 90% ใช้ได้ แต่อีก 10% พัง และเกือบจะถึงระดับที่ต้องการแล้ว ปริมาณโค้ดเพิ่มขึ้น แต่ไม่มีใครตามทัน ทำให้คุณภาพตกลงอย่างชัดเจน มันไม่ใช่การค่อย ๆ เข้าใกล้เป้าหมาย แต่เป็นการพุ่งไปถึง 90% ทันที แล้วค่อยเสียเวลาไปกับการทำความคุ้นเคยกับโค้ดที่ไม่คุ้นและแก้ซ้ำไปมา มันอาจเร็วกว่าเดิมก็ได้ แต่ในทางปฏิบัติความต่างระหว่างสองวิธีอาจไม่ได้มากอย่างที่คิด สิ่งที่ฉันไม่ชอบที่สุดคือ ฉันชอบสร้างอะไรใหม่ ๆ มากกว่าต้องมาเสียเวลาแก้โค้ดที่ไม่คุ้น
ฉันก็ชอบสร้างอะไรใหม่ ๆ มากกว่าเหมือนกัน แต่บางคนกลับสนุกกับวิธีทำงานใหม่ที่เร็วและด้นสดแบบนี้มากกว่า ฉันเองเคยจำใจลองใช้พักหนึ่งแล้วรู้สึกแปลกแยก เลยลบทิ้งหมดแล้วสร้างใหม่เองแบบแมนนวลโดยมี AI ช่วย ซึ่งตอนนั้นรู้สึกพอใจจริง ๆ โค้ดที่ AI สร้างแล้วฉันยังไม่เข้าใจ 100% มีอยู่ชนิดเดียวคือ SQL query ที่ซับซ้อน แต่ SQL query นั้นตรวจสอบการทำงานได้เร็ว และไม่มีผลข้างเคียงที่คาดไม่ถึง เลยยังพอรับได้
ปรากฏการณ์นี้คล้ายอย่างเจ็บปวดกับตอนที่ทีมขยายจาก 3 คนเป็น 10 คน อยู่ ๆ โค้ดที่ตัวเองไม่รู้จักก็ถาโถมเข้ามา ความสอดคล้องของสถาปัตยกรรมก็ลดลง และต้องพึ่งพานโยบายกับ CI มากขึ้น ความต่างของ LLM คือการเมนเทอร์หรือไล่ออกแทบไม่มีความหมาย วิธีใช้ LLM อย่างมีประสิทธิภาพคือคนที่ใช้ LLM ต้องรับผิดชอบต่อผลลัพธ์ที่สร้างออกมา 100% กล่าวคือ ต้องเข้าใจโค้ดที่สร้างขึ้นอย่างชัดเจน ซึ่งคงยากมากที่จะทำให้รับประกันได้จริง
LLM เก่งมากในการสร้าง boilerplate code อัตโนมัติ และนั่นทำให้เราขี้เกียจจัดการ boilerplate มากขึ้น พอมีโค้ดปริมาณมหาศาลขึ้น PR การรีวิวก็ยาก GitHub เองก็ไม่เหมาะกับการรีวิวทีละหลายบรรทัดจำนวนมากในครั้งเดียว ผลคือ นักพัฒนาระดับจูเนียร์/มิดเดิลจะได้แต่ทำงานแกะ boilerplate จนโอกาสเรียนรู้ลดลง ถ้าเป็นแบบนี้ต่อไป คุณภาพโค้ดจะเสื่อมลงอย่างรวดเร็ว
มีการอ้างถึงคำคมข้อ 7 ของ Perlis: ‘การเขียนโปรแกรมที่ผิดนั้นง่ายกว่าการเข้าใจโปรแกรมที่ถูกต้อง’<br>http://cs.yale.edu/homes/perlis-alan/quotes.html
เห็นด้วยกับความเห็นที่ว่า "คุณภาพกำลังตกลงอย่างชัดเจน" และปรากฏการณ์นี้จะยิ่งแย่ลงต่อไป ท้ายที่สุด เราต้องเข้าใจแนวคิดเรื่อง trade-off ทางเศรษฐศาสตร์ให้ดี จึงจะตัดสินได้ว่ามันให้ ‘กำไรสุทธิ’ จริงหรือไม่ ดูเหมือนผู้คนจะมองข้ามความจริงที่ว่าไม่มีของฟรี
ฉันอินกับกรอบคิดของ Rebecca Parsons มากที่ว่า “อาการหลอนคือฟีเจอร์หลักของ LLM” ฉันเองก็พยายามอธิบายเรื่องนี้ให้คนรอบตัวฟัง และประโยคนี้ก็สรุปสิ่งที่ฉันอยากพูดได้ตรงมาก
ฉันเองก็อธิบายให้ครอบครัวและเพื่อนฟังมาตลอดโดยเปรียบ LLM เป็นนักแสดง LLM แค่แสดงบทให้เข้ากับตัวละคร และจะใช้ข้อเท็จจริงก็ต่อเมื่อจำเป็นต่อการแสดง<br>https://jstrieb.github.io/posts/llm-thespians/
คำกล่าวเก่าแก่ที่ว่า “โมเดลทุกตัวผิด มีเพียงบางโมเดลเท่านั้นที่มีประโยชน์” ใช้ได้พอดีเลย
สติปัญญาคือความสามารถในการกรองข้อมูลที่ไม่จำเป็น ไม่ว่าจะเป็นความคิดหรือการรับรู้ก็เหมือนกัน
จำไม่ได้ว่าใครเป็นคนพูด แต่เอาต์พุตของ LLM นั้นเป็นอาการหลอนเสมอ แค่กว่า 90% ของมันออกมาถูกเท่านั้นเอง
ช่วงหนึ่งฉันรู้สึกเหมือน LLM จะมาแย่งงานเรา แต่สุดท้ายกลับพบว่ามันอาจสร้างงานกองมหึมาที่เราต้องมาตามแก้ทีหลังมากกว่า ตอนนี้เลยใช้มันได้ดีในฐานะเครื่องมือช่วยที่ใช้งานได้จริงอย่าง Claude Code และรับรู้ชัดเจนว่ามันเป็นเครื่องมือเสริม ไม่ใช่เครื่องมือแทนที่
เคยเห็นคำแนะนำว่า “ถ้าจะขอคำตอบเชิงตัวเลขจาก LLM ให้ถามซ้ำสักสามครั้ง” วิธีนี้ใช้กับคนก็ได้เหมือนกัน เวลาตำรวจสอบสวนก็มักให้เล่าเรื่องเดิมสามครั้ง หรือเล่าย้อนกลับด้วย ถ้าโกหกหรือจำไม่ชัด พอทวนหลายครั้งก็อาจหลุดได้ ในการสัมภาษณ์งานก็เช่นกัน ถ้าให้ใครสักคนอธิบายหัวข้อเดียวกันสามแบบ ก็พอจะดูได้ว่าเขาเข้าใจจริงหรือไม่
เทคนิคนี้ก็ทำให้คนบริสุทธิ์สับสนจนฟังดูเหมือนโกหกได้เหมือนกัน ต้องใช้ด้วยความระวัง
วิธีแบบนี้ใช้ได้แค่ภายใต้เงื่อนไขบางอย่างเท่านั้น มีหลายกรณีที่ยิ่งนึกย้อนและเล่าบ่อย ความทรงจำก็ยิ่งบิดเบือน ตำรวจที่ถามซ้ำ ๆ ตอนสอบสวน บางครั้งก็จงใจชักนำให้เกิดความขัดแย้งในคำให้การ ต่อให้เป็นข้อมูลเดียวกัน ถ้าให้ตอบเองหลายครั้งเกินไปในหลายรูปแบบ สุดท้ายก็อาจพลาดได้ และต้องระวังเสมอว่าผู้ถามสามารถชี้นำคำตอบไปในทิศทางที่ต้องการได้
กระสวยอวกาศของ NASA ใช้ triple modular redundancy เพื่อรับมือกรณีที่โปรเซสเซอร์หรือหน่วยความจำถูกรังสีอวกาศรบกวน<br>https://llis.nasa.gov/lesson/18803
ฉันรู้สึกว่าตัวเองมี productivity สูงขึ้นพอสมควรจาก LLM ไม่ใช่แค่ autocomplete ธรรมดา แต่ช่วยประหยัดเวลาได้มาก อย่างไรก็ตามก็ยังกังวลว่าถ้าใช้แบบปล่อยอิสระเกินไป มันอาจสร้างหนี้ในแบบของมันเอง สำหรับฉัน วิธีที่ประสบความสำเร็จคือค่อย ๆ สร้างฟีเจอร์ร่วมกับ Claude Sonnet หรือ GPT-5 แบบ Test Driven Development (TDD) แต่ยังไม่ค่อยเห็นบทความหรือการพูดคุยเกี่ยวกับแนวทางนี้มากนัก พออ่านบทความของ Martin แล้วก็พอเข้าใจว่าทำไม คนที่เก่ง TDD มาก ๆ มักไม่ใช่สายที่จะกระโดดเข้าไปใช้ระบบอัตโนมัติสร้างโค้ดด้วย LLM กันเต็มตัว และมักภูมิใจกับความงามของโค้ดหรือการสื่อสารแบบมนุษย์ จึงยังขาดเคล็ดลับภาคปฏิบัติที่สั่งสมแบบเมื่อก่อน ฉันคาดหวังว่าในอนาคตจะมี ‘ทุ่งหญ้าใหม่’ เปิดขึ้นสำหรับวิธีเขียนซอฟต์แวร์ด้วยเครื่องมือ LLM และจะมีบทเรียนมากมายตามมา อ้างอิง: https://news.ycombinator.com/item?id=45055439
หน้าที่พื้นฐานของนักพัฒนาคือการตรวจสอบและเช็กโค้ดที่ LLM สร้างขึ้นด้วยตัวเอง อย่าขอโค้ดจำนวนมากเกินไปในครั้งเดียว ควรใช้ LLM กับงานที่เล็กลง และฉันก็รัน unit test เองด้วย การที่ LLM บอกว่าได้รันเทสต์แล้วและ ‘ผ่าน’ อาจไม่ใช่เรื่องจริง ต้องรันเองถึงจะเชื่อถือได้
เห็นด้วยกับความเห็นที่ว่า “อาการหลอนคือฟีเจอร์ของ LLM”
ฉันอยากอธิบายว่า LLM อาศัยอยู่ในโลกที่ประกอบขึ้นจากข้อความและการจัดเรียงข้อความเท่านั้น คำกับคำ เรื่องเล่ากับเรื่องเล่า คือโลกทั้งหมดของมัน เพราะแบบนั้นมันจึงเก่งที่สุดในการสร้างเรื่องเล่าใหม่ ๆ เรื่องเล่าเหล่านี้บางครั้งก็ไม่แม่นยำและขัดแย้งกันเอง จนสุดท้ายต้องพึ่งการคาดเดา LLM ไม่ได้ “นับ” ตัวเลขเป็นจริงเป็นจัง แต่รู้รูปแบบอย่าง ‘2 มาหลัง 1 และ 3 มากกว่า 2’ เหมือนที่มนุษย์ใช้เครื่องคิดเลข พวกมันก็สามารถคำนวณผ่านเครื่องมือได้เช่นกัน ในอนาคต สิ่งที่ควรถูกนำเข้ามาไม่ใช่ arithmetic engine แต่เป็น "epistemic engine" ที่ช่วยด้านตรรกะ การป้องกันความขัดแย้ง และการแยกแยะข้อเท็จจริงที่เชื่อถือได้ จึงจะทำให้ AI กลายเป็นสิ่งที่ไว้วางใจได้จริง
ถ้ามองจากมุมนั้น LLM agent ก็อาจถูกมองได้ว่าเป็นเพียงเครื่องมือสำหรับกรองผลลัพธ์ที่เป็นอาการหลอน
ฉันเห็นด้วยกับประโยคที่ว่า “เอาต์พุตของโมเดล (ภาษาขนาดใหญ่) ทุกตัวคืออาการหลอน มีเพียงบางส่วนที่มีประโยชน์” มากกว่า และเพราะสัดส่วนของอาการหลอนที่มีประโยชน์นั้นสูงมาก จึงเกิดกระแส AI boom ขึ้น
ฉันคิดว่านั่นเป็นมุมมองที่ลดทอนเกินไป
นี่เองคือเหตุผลที่คำว่า “อาการหลอน” เป็นคำที่ถกเถียงกันตลอด เพราะมันทำให้คนเข้าใจผิดว่ามีผลลัพธ์บางแบบที่ ‘ไม่ใช่’ อาการหลอน ทั้งที่จริงแล้วเอาต์พุตทั้งหมดของ LLM ถูกสร้างขึ้นโดยไม่ได้คิดจริง ๆ
ทุกวันนี้การใช้ LLM ให้ได้ผลลัพธ์ตามต้องการยังต้องอาศัยนักพัฒนาระดับซีเนียร์คอยรับมืออย่างมีเหตุผล ถ้าในอนาคตจูเนียร์หายไป บทบาทของซีเนียร์จะมีใครมาแทนก็น่าสงสัย สุดท้ายฉันคาดว่า LLM จะเขียนโปรแกรมได้ด้วยตัวเองมากพอ ตอนนี้ AI เป็นเครื่องมือช่วยที่ดีอย่างแน่นอน แต่ยังไม่ใช่สิ่งทดแทน
เกี่ยวกับคำแนะนำให้ถาม LLM หลายครั้ง ถ้าเป็นผู้ใช้ macOS ขอแนะนำให้ใช้ Alfred workflow กด command + space แล้วพิมพ์ 'llm <พรอมป์ต์>' ก็สามารถเปิดแท็บเบราว์เซอร์ให้รัน LLM หลายตัวพร้อมกันได้ตามต้องการ เช่น perplexity, deepseek (local), chatgpt, claude, grok ทำให้ทำ cross-check ระหว่าง LLM ตามที่ Fowler พูดได้อย่างรวดเร็วและมีประสิทธิภาพ และเมื่อใช้ไปกับงานหลายแบบ ก็จะเริ่มจับได้ว่า LLM ตัวไหนเก่งงานแบบไหน