อันนี้เป็นบั๊กที่ผมชอบมาก เพราะมันหลอกเก่งจัด 555 คือผมส่งข้อความไทยยาวๆ เข้าไปหา AI ใน Newton แล้วมันเงียบครับ ไม่ใช่เงียบแบบกำลังคิดนะ แต่เงียบแบบ "ข้อความหายไปเลย" พอเปิดดูฝั่งระบบก็เหมือนมันได้รับอะไรไม่ครบสักอย่าง ตอนแรกผมนึกว่าเป็นเรื่อง context ใหญ่ไป, AI มึน, หรือไม่ก็ session เก่าเกิน แต่สุดท้ายตัวการจริงดันเล็กมาก คือ input buffer 1KB ของ terminal

ผมเลยอยากเล่าเคสนี้ เพราะมันเป็นตัวอย่างชัดมากว่าเวลาคุณมี AI Agent ที่ลงมือทำงานจริง ปัญหามันจะไม่ได้อยู่แค่ prompt หรือ model อย่างเดียว บางทีสิ่งที่ทำให้ระบบพังคือรายละเอียดระดับ byte ที่คนใช้ทั่วไปไม่มีทางเห็นเลย

อาการแปลกมาก — ไทยยาวหาย แต่อังกฤษยาวไม่เป็น

เรื่องเริ่มจากผมส่งข้อความไทยยาวประมาณ 400 กว่าตัวอักษรเข้าไปหา Codex ผ่านหน้าแชทของ Newton ครับ เป็นข้อความอธิบายงานธรรมดานี่แหละ ไม่ได้มีอะไร exotic เลย แต่ผลคือ AI ไม่ตอบ ทำงานไม่ต่อ rollout ไม่โต เหมือนข้อความไม่เคยไปถึงมัน

ทีแรกผมยังไม่ปักใจ เพราะปัญหาพวกนี้มันชอบหลอก คนเราจะเผลอคิดก่อนว่า "AI คงงง", "session นี้คงหนัก", หรือ "เน็ตคงสะดุด" แต่พอลองอีกแบบกลับยิ่งงงกว่าเดิม — ถ้าผมส่งข้อความอังกฤษยาวพอๆ กัน มันผ่านปกติครับ

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

ขั้นแรก — ตัดความเชื่อผิดออกทีละตัว

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

  • ไม่ใช่ context ใหญ่ — ลองบน session ใหม่เอี่ยมที่แทบไม่มีประวัติอะไรเลย ยังพังเหมือนเดิม
  • ไม่ใช่ model คิดนาน — เพราะ rollout ฝั่ง AI ไม่โตเลย แปลว่าข้อความยังไม่เข้ากระบวนการคิดด้วยซ้ำ
  • ไม่ใช่ warm/cold boot — เคสนี้ต่างจากบั๊กเคอร์เซอร์กระพริบที่ผมเคยเล่า เพราะครั้งนี้เครื่องพร้อมแล้ว prompt ขึ้นแล้ว แต่ข้อความยังโดนตัดอยู่
  • ไม่ใช่ภาษาไทยเป็น unsupported — ข้อความไทยสั้นๆ ผ่านปกติ ปัญหาเกิดตอน "ยาว" เท่านั้น

พอตัดตัวเลือกพวกนี้ออกไป เหลือโจทย์ชัดมากครับ: ความยาวของข้อความสัมพันธ์กับจำนวน bytes ที่ส่งเข้า terminal

ตัวการจริง — terminal รับได้แค่ 1KB ต่อการ write ครั้งเดียว

Newton ฝั่ง Codex ที่ผมทำไว้ ต้องคุยกับ AI ผ่าน PTY หรือ pseudo-terminal ครับ พูดง่ายๆ คือเราจำลองหน้าต่าง terminal ขึ้นมา แล้วพิมพ์ข้อความเข้าไปเหมือนคนพิมพ์จริงๆ

ของเดิมทิมใช้วิธีง่ายที่สุดเลย คือเวลา user ส่งข้อความมา 1 ก้อน ก็เอาทั้งก้อนยาวๆ นั้น write เข้า PTY รวดเดียว ผมก็คิดว่าไม่น่ามีอะไร เพราะในหัวคนเรามันก็มองเป็น "ข้อความเดียว" ใช่ไหมครับ

แต่พอไปเทสต์ตรงๆ ระดับ PTY เลย กลายเป็นว่าช่องรับ input ของ terminal ตัวนี้มีขนาดประมาณ 1024 bytes ต่อการ write ครั้งเดียว ถ้าคุณยัดเกิน มันไม่ได้เตือน ไม่ได้ error ไม่ได้บอกว่า "รับไม่หมดนะ" แต่มันทิ้งส่วนเกินไปเฉยๆ เลย เงียบมาก นี่แหละครับที่ทำให้หลอน

ทีนี้ทำไมภาษาไทยโดน แต่ภาษาอังกฤษรอด? เพราะ ไทยหนึ่งตัวอักษรใช้ประมาณ 3 bytes ใน UTF-8 ครับ ส่วนอังกฤษทั่วไปใช้ 1 byte ต่อหนึ่งตัวอักษร

แปลเป็นภาพง่ายๆ คือ:

  • อังกฤษ 455 ตัว = ประมาณ 455 bytes ยังไม่ชนเพดาน 1KB
  • ไทย 455 ตัว = ประมาณ 1,165 bytes เกินเพดานไปแล้ว

สรุปคือ ข้อความไทยยาวๆ ที่ดูธรรมดามากในสายตามนุษย์ พอแปลงเป็น bytes แล้วมันอ้วนกว่าที่คิดเยอะ จนไปชนกำแพงของ terminal แบบเงียบๆ

อธิบายแบบบ้านๆ — กระดาษโน้ตแผ่นเล็ก แต่ผมเขียนภาษาไทยตัวโต

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

ตัวคนรับไม่ได้โง่ ไม่ได้อ่านไม่ออกนะครับ เขาแค่ ไม่เคยได้รับกระดาษแผ่นท้าย เท่านั้นเอง

วิธีแก้ — เลิกยัดทีเดียว เปลี่ยนเป็นพิมพ์ทีละ chunk

พอรู้ root cause แล้ว ทางแก้มันตรงไปตรงมามากครับ — ถ้าช่องมันรับได้ทีละ 1KB เราก็ไม่ควรยัดเกิน 1KB ตั้งแต่แรก

ทิมเลยเปลี่ยน logic การพิมพ์ใหม่ จากเดิมที่ write ทั้งข้อความรวดเดียว เป็น ตัดข้อความออกเป็น chunk ละ 40 ตัวอักษร แล้วค่อยๆ พิมพ์เข้า PTY ทีละก้อน เว้นจังหวะสั้นๆ ประมาณ 50 มิลลิวินาทีระหว่างก้อน

40 ตัวอักษรภาษาไทยคร่าวๆ ก็ราว 120 bytes เท่านั้นครับ ต่ำกว่าเพดานมาก ต่อให้มีสัญลักษณ์ปนบ้างก็ยังปลอดภัย พอมันไหลเข้าไปทีละก้อน ระบบปลายทางก็รับครบทุกตัว ไม่โดนตัดหางอีก

สิ่งที่ผมชอบคือ fix นี้ไม่ได้ใช้วิธี hack แปลกๆ เลย มันแค่เคารพความจริงของระบบว่า "ปลายทางรับได้ทีละแค่นี้" แล้วส่งให้พอดีกับที่มันรับไหว แค่นั้นเอง

ผลหลังแก้ — ไทยยาวผ่านครบ และไม่ได้พังเคสอื่น

หลังแก้เสร็จ ทิมทดสอบทั้งบน PTY ตรงๆ และบน flow จริงของ Newton ครับ เอาข้อความไทยชุดเดิมที่เคยพังมาลองใหม่ ผลคือผ่านครบ rollout โตตามปกติ AI รับงานต่อได้เหมือนไม่มีอะไรเกิดขึ้น

ที่สำคัญคือมันไม่ได้แก้แบบ "ผ่านเคสนี้แล้วพังอีก 3 เคส" เพราะภาษาอังกฤษก็ยังเร็วเหมือนเดิม ข้อความสั้นก็ไม่ช้าจนน่ารำคาญ และ session ใหม่ก็ยังทำงานร่วมกับชั้นอื่นที่ผมวางไว้ก่อนหน้านี้ได้ครบ ไม่ว่าจะเป็นเรื่อง memory ที่ต้องป้อนให้แต่ละ engine ไม่เหมือนกัน หรือเรื่องความพร้อมของหน้าจอ terminal ก่อนเริ่มพิมพ์

พูดอีกแบบคือ บั๊กนี้ไม่ได้อยู่ระดับ prompt แต่มันอยู่ระดับ plumbing ครับ และพอ plumbing ตัน ต่อให้ model ดีแค่ไหนมันก็ช่วยไม่ได้

บทเรียนที่ผมได้ — ปัญหาหลายอย่างไม่ได้อยู่ที่ AI แต่อยู่ที่ "ท่อ"

เวลาคนพูดถึง AI ส่วนใหญ่จะคุยกันเรื่อง model ไหนเก่งกว่า, prompt ยังไง, tool ไหนฉลาดกว่า แต่พอคุณเอา AI มาทำงานจริงทั้งระบบ ปัญหาที่เจอบ่อยมากกลับเป็นเรื่องทำนองนี้ครับ — bytes, buffer, encoding, timing, process, screen state พวกนี้ล้วนเป็น "ท่อ" ที่ถ้าพัง ต่อให้สมองฉลาดแค่ไหนก็ไปไม่ถึงงานจริง

มันคล้ายกับอีกเคสที่ผมเคยเจอแล้วต้อง push fix ไปหลาย server ลูกค้าพร้อมกัน เลยครับ คือสิ่งที่ user เห็นมีแค่ว่า "มันใช้ไม่ได้" แต่ข้างหลังจริงๆ อาจเป็นเรื่องเล็กมากระดับ parser, byte limit หรือ buffer เงียบๆ นี่แหละ

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

คำถามที่พบบ่อย

PTY input buffer คืออะไร ทำไมถึงจำกัดขนาดข้อความ?

PTY (pseudo-terminal) คือหน้าต่าง terminal จำลองที่ใช้คุยกับโปรแกรม CLI ครับ มัน buffer input ไว้ประมาณ 1024 bytes ต่อการ write ครั้งเดียว ถ้ายัดข้อมูลเกิน มันไม่ error แต่ทิ้งส่วนเกินไปเงียบๆ ซึ่งทำให้ debug ยากมากเพราะไม่มีสัญญาณเตือน

ทำไมภาษาไทยถึงมีปัญหา PTY buffer แต่ภาษาอังกฤษไม่มี?

เพราะ UTF-8 encode ภาษาไทยใช้ 3 bytes ต่อ 1 ตัวอักษร ในขณะที่อังกฤษใช้แค่ 1 byte ครับ ดังนั้นข้อความไทย 455 ตัวอักษรมีขนาดประมาณ 1,365 bytes ซึ่งเกิน limit 1024 bytes แต่ภาษาอังกฤษ 455 ตัวอักษรแค่ ~455 bytes ซึ่งยังไม่ชนเพดาน

วิธีแก้ PTY buffer limit สำหรับข้อความยาวคืออะไร?

วิธีที่ดีที่สุดคือแบ่งข้อความออกเป็น chunk เล็กๆ แล้วส่งทีละก้อนครับ สำหรับภาษาไทย chunk ละ 40 ตัวอักษรประมาณ 120 bytes ซึ่งต่ำกว่า limit มาก เว้นจังหวะ 50 มิลลิวินาทีระหว่างก้อน ปลายทางก็รับข้อมูลครบและไม่มีอะไรหายครับ

ปัญหาระดับ plumbing ส่งผลต่อ AI อย่างไร?

ถ้า plumbing พัง ต่อให้ AI model ฉลาดแค่ไหนก็ช่วยไม่ได้ครับ เพราะข้อความไม่เคยไปถึงมันจริงๆ เหมือน email ที่เขียนดีมากแต่ส่งไม่ออก ปัญหาพวกนี้ได้แก่ buffer limit, encoding, timing, process state ซึ่ง developer ทั่วไปมักมองข้ามตอน build แต่จะเจอเมื่อใช้งานจริงครับ

Newton — ถ้าคุณอยากมี AI ที่ไม่ได้แค่ตอบ แต่ลงไปแก้ระบบจริงให้คุณ

สิ่งที่ผมกำลังสร้างกับ Newton ไม่ใช่แค่หน้าแชท AI สวยๆ ครับ แต่มันคือ AI Agent ที่อยู่บน server ส่วนตัวของคุณจริงๆ คุยจากมือถือได้ แต่ข้างหลังมันลงไปจับของจริงได้หมด ทั้งไฟล์, process, terminal, cron, deploy และบั๊กระดับ plumbing แบบวันนี้นี่แหละ

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

— ปอนด์