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

มันเป็น CLI ที่สแกน จัดหมวดหมู่ และจัดระเบียบสถานการณ์อย่างเช่น จากสกิล 60 อัน มีครึ่งหนึ่งที่ไม่เคยใช้เลยสักครั้ง หรือ CLAUDE.md พองตัวขึ้นเพราะปลั๊กอิน การนับโทเค็นอิงกับ js-tiktoken ไม่ได้ลบออก แต่ย้ายไปไว้ที่ skills.disabled/ เพื่อให้ restore กลับได้ทุกเมื่อ

https://github.com/iops-leo/claude-slim

ทิศทางของมันเสริมกับการตั้งค่าในบทความได้พอดี คิดว่าน่าใช้ควบคู่กันครับ

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

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

พอลองใช้ดูแล้ว ความแม่นยำในการรู้จำสเก็ตช์บนกระดาษน่าทึ่งมาก ตอนนี้ไม่ต้องแชตแล้วด้วยซ้ำ

ผมกลับมาใช้ nvim หลังจากลองใช้ AI Agent เสียอีกครับ
เพราะการดูซอร์สด้วย nvim สะดวกกว่ามาก..

เห็นด้วย ข้อมูลแกนหลักของโดเมนที่มีความซับซ้อนสูง เช่น อากาศยานและอวกาศ การแพทย์ การควบคุมความแม่นยำสูง ฯลฯ ถูกปิดไว้ในเครือข่ายภายในอย่างเข้มงวด และหากจะเข้าถึงก็ต้องเป็นคนวงในระดับสำคัญ หรือถ้าเป็นคนนอกก็แทบจะต้องจ่ายค่าใช้จ่ายสูงและเซ็น NDA ก่อนจึงจะพอเปิดให้เข้าถึงได้ ข้อมูลส่วนใหญ่ที่ AI ใช้เรียนรู้คือสิ่งที่เปิดเผยอยู่บนอินเทอร์เน็ต และถ้าเป็นบริการเว็บ/แอปที่อิง Python, JavaScript ก็พอจะทำ Full Automation ได้ในระดับหนึ่ง
แต่ 3D graphics และอัลกอริทึมที่อิง CAD ซึ่งใช้ในโดเมนขั้นสูงนั้น มีอยู่กระจัดกระจายบนอินเทอร์เน็ตหรือแทบไม่มีเลย ดังนั้นต่อให้เป็น AI ก็ทำได้แค่สร้างผลลัพธ์แบบผิวเผินผ่าน vibe coding เท่านั้น ผมคิดว่าแนวทางที่ปลอดภัยและสมจริงคือ วาง main agent ไว้หนึ่งตัว แล้วคอยป้อนบริบทของโดเมนอย่างต่อเนื่องในระดับ micro-managing พร้อมเดินงานด้วยวงจร Planning → Redirection → Review โดยให้นักพัฒนาเป็นผู้ขับเคลื่อนโดยตรง ไม่ใช่ full automation แต่เป็นการพัฒนาในรูปแบบการเสริมพลังอย่างต่อเนื่อง

เห็นพวกนักพัฒนาที่โค้ดแบบปล่อยสมองว่างตามกระแส vibe coding แล้วหงุดหงิดชะมัด ผลงานของตัวเองคุณภาพเละเทะ แต่ลองมาแก้ตัวว่า AI เป็นคนเขียนดูสิ สุดท้ายคนที่ต้องรับผิดชอบก็คือตัวเอง

ในบรรดาวัวสีดำกับวัวสีน้ำตาล ตัวไหนทำงานเก่งกว่ากัน?

วัวที่โดนด่าทำงานเก่งกว่าขอรับ

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

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

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

ดังนั้น สำหรับคำถามที่ต้องการความเป็นกลาง ฉันจึงใช้พรอมป์ให้ตอบเป็น 3 พาร์ต ได้แก่ "เชิงบวก/เชิงวิจารณ์/ภาพรวม"

ว้าว......!

ผมก็เห็นด้วยกับความเห็นนี้เช่นกัน
ท้ายที่สุดแล้วผมมองว่ามันเป็นเครื่องมือที่มี trade-off ชัดเจน
แม้จะกังวลว่ายิ่งใช้ AI มากขึ้น ทักษะการเขียนโค้ดอาจลดลง แต่ก็ชัดเจนว่าเรากำลังได้คิดเรื่องอื่น ๆ ที่เมื่อก่อนเราไม่ได้ทำ (หรือทำไม่ได้) มากขึ้น

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

เดิมทีค่อนข้างพอใจมากนะครับ.. แต่พออัปเกรดแล้วข้อกำหนดด้านความปลอดภัยเข้มขึ้น.. ก็เริ่มรู้สึกว่ามันโง่ลงเรื่อย ๆ T_T .. ตอนนี้ค่า bedrock token อยู่ที่ประมาณวันละ 100 ดอลลาร์..

id
name
displayName
email
active
admin
guest
timezone
createdAt
updatedAt
lastSeen

ว่ากันว่ามีข้อมูลหลุด รวมถึงคีย์ API เช่น npm token หรือ GitHub token ด้วย เห็นว่ามีพ่อค้าข้อมูลโผล่มาแล้ว

เบื้องหลังการพังทลายนี้มีข้อจำกัดทางคณิตศาสตร์ของ 'การทำ normalization แบบ softmax' ซึ่งเป็นหัวใจของสถาปัตยกรรมทรานส์ฟอร์เมอร์อยู่ ภายใต้กลไก attention ผลรวมของค่าน้ำหนักความสนใจของทุกโทเคนจะต้องเท่ากับ 1 เสมอ จึงเป็นการกระจายแบบผลรวมเป็นศูนย์ ดังนั้นเมื่อความยาวของลำดับอินพุต N ขยายเพิ่มขึ้นแบบทวีคูณ น้ำหนักเชิงสารสนเทศที่สามารถจัดสรรให้โทเคนสำคัญบางตัวได้ย่อมลู่เข้าไปที่ 1/N อย่างหลีกเลี่ยงไม่ได้และถูกเจือจางลงในเชิงคณิตศาสตร์ นี่ไม่ได้หมายถึงเพียงความไร้ประสิทธิภาพของการคำนวณเท่านั้น แต่ยังหมายความว่า 'noise floor' ที่โมเดลต้องประมวลผลพุ่งสูงขึ้นอย่างรวดเร็วด้วย

นี่มันไม่ใช่เรื่องล้อเล่นแล้วนะ..

เป็นบทความที่ไร้สาระ มีแต่การไล่เรียงข้อโต้แย้ง แต่ไม่มีทั้งหลักฐานชี้ขาดรองรับข้ออ้างและการทดลองโดยตรง

เหมือนเป็นแค่ภาคต่อที่น่าเบื่อของคำพูดของ Yann LeCun อย่าง "ต่อให้ไปถึง GPT-5000 โมเดลก็จะยังเรียนรู้ไม่ได้ว่า ถ้าวางของไว้บนโต๊ะแล้วผลักโต๊ะ ของก็จะถูกผลักไปด้วย" หรือ "โมเดลแบบอัตถถดถอยเมื่อไปถึงลำดับที่ยาวขึ้นก็จะพังทลายลงอย่างเลี่ยงไม่ได้เพราะความผิดพลาดสะสม" ...

พูดกันตรงๆ ก็อดสงสัยไม่ได้ว่านี่อาจไม่ใช่อัปโหลดเพื่อไวรัลให้บริษัทที่ถูกพูดถึงท้ายไวต์เปเปอร์

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

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

วันหนึ่งถ้าเครื่องคิดเลขเสียแล้วแสดงว่า 3 X 3 = 10 แต่ไม่มีใครรู้เลยว่ามันผิด แบบนั้นก็น่ากังวลเหมือนกันนะ... ถ้าเรื่องแบบนั้นเกิดขึ้นบนคอมพิวเตอร์ของโปรแกรมเมอร์ที่ดูแลบัญชีธนาคารของผม... ระวังไว้ก็คงไม่เสียหายอะไรครับ