มีคนลองสั่งให้ LLM หรือโมเดลภาษาขนาดใหญ่ที่เป็นเบื้องหลัง ChatGPT และ Claude สุ่มตัวเลขระหว่าง 1 ถึง 30 พอถามซ้ำแล้วซ้ำอีก เลขที่ได้ก็ยังวนอยู่ที่ 17 แถมมีคนตอบเสริมว่าเจอเลข 17 ติดกันถึง 4 ครั้ง เรื่องนี้มาจากกระทู้บน Hacker News เว็บบอร์ดของคนสายเทคโนโลยี ในหัวข้อ "มีงานง่ายๆ อะไรบ้างที่ LLM ทำพังได้อย่างไม่น่าเชื่อ"

คนตั้งกระทู้ไม่ได้มาตั้งเพื่อบ่น แต่กำลังหาไอเดียพัฒนาโมเดลเฉพาะทาง จึงอยากรู้ว่ามีงานพื้นฐานอะไรบ้างที่คนใช้ ChatGPT หรือ Claude อยู่ทุกวัน แล้วยังเจอมันทำงานพลาดอยู่เรื่อยๆ คำตอบทั้งหมด 89 ความเห็นแทบไม่มีงานยากๆ เลย มีแต่งานพื้นฐานทั่วไป เช่น ลบย่อหน้าออกจากเอกสาร ตอบคำถามสั้นๆ ให้สั้นจริง วาดแปลนห้องให้ใช้งานได้ นับจำนวนสิ่งของ หรือนับความยาวข้อความ

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

ให้เขียนเพิ่มทำได้ดี แต่ให้ลบกลับทำพัง

เวลาสั่งให้ AI เขียนเพิ่ม มันมักจะทำได้ดี แต่พอสั่งให้ตัดข้อความออก มันมักจะเผลอเติมอะไรบางอย่างกลับเข้ามาแทน

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

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

มีคนในกระทู้ยกหลักการออกแบบจากเอกสารระบบเครือข่าย RFC 1925 ซึ่งรวบรวมข้อคิด 12 ข้อในการออกแบบโปรโตคอล ขึ้นมาเปรียบเทียบว่า พฤติกรรมของโมเดลกำลังสวนทางกับหลักการนี้:

โปรโตคอลจะสมบูรณ์แบบ ไม่ใช่เมื่อเพิ่มอะไรไม่ได้อีก แต่เมื่อไม่มีอะไรให้ตัดออกแล้ว

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

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

บรรยายแปลนบ้านได้ แต่วาดเองไม่รอด

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

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

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

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

ยิ่งคำตอบดูน่าเชื่อถือ ยิ่งต้องตรวจให้ละเอียด

นักดูนกคนหนึ่งเล่าประสบการณ์ตรงว่า เขาอัปโหลดภาพถ่ายนกให้ ChatGPT และ Gemini ช่วยระบุสายพันธุ์ พบว่าประมาณ 10% ของรูปที่ส่งไป ตอบผิดอย่างไม่น่าเชื่อ ส่วนอีก 90% ที่เหลือระบุได้ถูกต้องและใช้งานได้ดี

แต่ตัวเลข 90% ที่ถูกต้องนี่เองคือจุดที่อันตรายที่สุด เพราะคำตอบที่ผิดอีก 10% นั้นออกมาหน้าตาเดียวกันเป๊ะ เช่น ในรูปถ่ายนกกระจอกที่เห็นได้ชัดเจน โมเดลทายรอบแรกว่าเป็น Song Sparrow พอบอกว่าผิด มันก็เปลี่ยนเป็น Savannah Sparrow และ Saltmarsh Sparrow ตามลำดับ กว่าจะตอบถูกว่าเป็น Seaside Sparrow ก็ต้องทักท้วงกันถึง 3 รอบ และสิ่งที่น่ากลัวกว่าการทายผิดคือ ในอีกรูปหนึ่งที่เขาส่งไป โมเดลบรรยายลักษณะขนขาและขนหางที่ไม่ได้ปรากฏในภาพนั้นเลยอย่างเป็นตุเป็นตะ รายละเอียดที่แต่งขึ้นมาเองแบบนี้ ทำให้คำตอบที่ผิดฟังดูน่าเชื่อถือพอๆ กับคำตอบที่ถูก

เรื่องเกมก็เจอปัญหาแบบเดียวกัน มีคนเล่าว่าเกมออนไลน์อย่าง OSRS มีวิกิรวบรวมข้อมูลคู่มือไว้ละเอียดมาก แต่โมเดลก็ยังแนะนำวิธีเล่นผิดๆ และแต่งระบบการเล่นที่ไม่มีอยู่จริงขึ้นมา เกมอื่นที่มีคนยกเป็นตัวอย่างก็มีทั้ง Anno 1800, Rainbow Six Siege และรายละเอียดคลาสตัวละครใน World of Warcraft โดยมีผู้ใช้ระบุว่าพบปัญหานี้ใน Claude Opus โมเดลรุ่นท็อปที่ฉลาดที่สุด

ส่วนกรณีที่ลามไปถึงเวลาทำงานของคนทั้งทีมคือเรื่องตัวเลข มีคนเล่าว่าเขาให้ Claude ช่วยวิเคราะห์ระยะเวลาการทำงานของระบบทดสอบโค้ดอัตโนมัติอย่าง CI บนแพลตฟอร์ม GitLab ปรากฏว่าโมเดลแต่งตัวเลขสถิติขึ้นมาเอง ทำให้คนในทีมหลงเชื่อและเสียเวลาทำงานไปจริงๆ กว่าจะรู้ตัวว่าตัวเลขไม่ตรงกับความจริง พอไปถามโมเดลตรงๆ มันก็ยอมรับว่าแต่งตัวเลขขึ้นมาเอง ส่วนเหตุผลว่าทำไมโมเดลถึงเลือกเดาแทนที่จะบอกว่าไม่รู้ เราเคยเขียนถึงไว้แล้วในบทความ ทำไม AI ถึงหลอน

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

เขียนกฎไว้ในไฟล์ชัดเจน แต่มันก็ยังไม่ทำตาม

วิธีคุมพฤติกรรมของโมเดลที่ตรงไปตรงมาที่สุด คือเขียนกฎไว้ในไฟล์ให้โมเดลอ่านก่อนเริ่มทำงาน มีคนเล่าว่าเขาเขียนกฎการทำงานไว้อย่างละเอียดใน CLAUDE.md ไฟล์รวมข้อบังคับประจำโปรเจกต์สำหรับ Claude แต่สุดท้าย Claude Opus ก็ยังฝ่าฝืนกฎซ้ำแล้วซ้ำเล่า

ตัวอย่างที่เขายกขึ้นมา เช่น โมเดลใช้คำสั่ง ripgrep -r โดยเข้าใจผิดว่าเป็นคำสั่งค้นหาข้อความในโฟลเดอร์ย่อย ทั้งที่จริงแล้วออปชัน -r ของคำสั่งนี้ใช้สำหรับแทนที่ข้อความ หรือโมเดลสั่งบันทึกโค้ดส่งเข้า Git เองโดยไม่รออนุมัติ ทั้งที่ในไฟล์กฎเขียนห้ามไว้อย่างชัดเจน และทุกครั้งที่ทักท้วง โมเดลก็ตอบขอโทษแต่ก็ยังทำผิดซ้ำอีก

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

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

งานที่เกี่ยวกับตัวเองคือจุดบอดของโมเดล

หนึ่งในข้อสังเกตที่น่าสนใจที่สุดในกระทู้ ไม่ใช่งานคำนวณหรืองานวาดภาพ แต่เป็นงานที่โมเดลต้องประเมินหรือปรับปรุงพฤติกรรมของตัวเอง

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

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

เรื่องการค้นหาข้อมูลบนเว็บก็เจอปัญหาแบบเดียวกัน มีคนสังเกตว่าเวลาโมเดลค้นหาข้อมูล มันมักจะพิมพ์คำค้นซ้ำซ้อนและยาวเกินจำเป็น เช่น nhl toronto scores nhl hockey toronto scores "nhl hockey" toronto score today ทั้งที่พิมพ์คำค้นสั้นๆ ไม่กี่คำกลับได้ผลดีกว่า นอกจากนี้ อีกคนยังเสริมว่าโมเดลมักใส่ปีปัจจุบันลงในคำค้นหา แต่ปีที่ใส่กลับล้าหลังกว่าปีปัจจุบันจริง 2 ถึง 3 ปี ทั้งที่ระบบแจ้งวันที่ปัจจุบันให้ทราบอยู่แล้ว แม้จะมีคนแย้งว่าเรื่องนี้อาจไม่ใช่ข้อบกพร่องของโมเดลโดยตรง แต่อาจเป็นพฤติกรรมที่เรียนรู้มาจากเครื่องมือค้นหาบนอินเทอร์เน็ตที่ทำงานแย่ลง

ทั้งสามกรณีมาจากคนละคน แต่ชี้ไปทางเดียวกันว่า พอเป็นงานที่ต้องหันกลับมามองตัวเอง สิ่งที่โมเดลตอบได้คือหลักการที่เคยอ่านเจอมาว่า Prompt ที่ดีควรเขียนอย่างไร ส่วนที่มันตอบไม่ได้คือ Prompt ชุดนี้จะพามันไปพลาดตรงไหน จากเรื่องที่เล่ามา คนที่รู้ว่างานของตัวเองต้องการอะไร จึงเขียนคำสั่งได้ตรงกว่า

อ่านบทเรียนเหล่านี้อย่างไรให้ไม่เข้าใจผิด

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

นอกจากนี้ อย่าลืมว่าคนที่บอกว่าโมเดลตอบผิด 10% ก็คือคนเดียวกับที่บอกว่าอีก 90% โมเดลตอบได้ถูกต้องและใช้งานได้ดี ปัญหาที่แท้จริงจึงไม่ใช่เพราะมันทำงานผิดพลาดบ่อย แต่เป็นเพราะมันทำงานถูกบ่อยจนทำให้เราวางใจและเผลอเชื่อคำตอบทั้งหมดโดยไม่ได้ตรวจสอบ

มองอีกมุมหนึ่ง รายชื่องานที่โมเดลทั่วไปยังทำพลาด ก็คือรายการช่องว่างที่รอคนมาอุด ซึ่งตรงกับสิ่งที่เจ้าของกระทู้ตามหามาตั้งแต่ต้น คือไอเดียว่าจะฝึกโมเดลเฉพาะทางไว้ทำงานด้านไหนดี

เวลารับงานยากๆ จาก AI เรามักจะตรวจความถูกต้องอย่างละเอียดเสมอ เพราะรู้อยู่แล้วว่างานนั้นยาก แต่งานง่ายๆ เรากลับมักจะปล่อยผ่านโดยไม่ตรวจ เพียงเพราะคิดว่าง่ายเกินกว่าจะผิดพลาด

---

ที่มา: กระทู้ Ask HN: What is one simple thing LLMs are insanely bad at? จาก Hacker News