AI News · 2026-08-18

Artificial Analysis เผยแพร่ผลการวัด Qwen3.8 รุ่น 27B บนดัชนีรวมของตัวเองเมื่อวันที่ 17 ส.ค. ได้คะแนน 52 ซึ่งเป็นอันดับหนึ่งในกลุ่มโมเดลเปิดขนาด 4 ถึง 40 พันล้านพารามิเตอร์ทั้งหมด 135 ตัว โดยค่ากลางของกลุ่มนี้อยู่ที่ 9 เท่านั้น

สิ่งที่ทำให้ตัวเลขนี้มีน้ำหนักคือของที่มันไปเทียบติด Simon Willison สรุปไว้ว่า "That's the same score as GPT-5.6 Luna (max), and just one point behind GLM-5.2 (max) and DeepSeek V4 Pro 0813 (max)" และเขาชี้เองว่าตัวเทียบสองตัวนั้นมีขนาด 753 พันล้านและ 1.6 ล้านล้านพารามิเตอร์ตามลำดับ

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

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

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

Artificial Analysis · Simon Willison

Cursor ประกาศบนหน้าบันทึกการเปลี่ยนแปลงของตัวเองเมื่อวันที่ 17 ส.ค. เปิดบริการชื่อ Origin ด้วยประโยคสั้นว่า "Cursor can now host your code." โดยเพิ่มแท็บใหม่ชื่อ Codebase เข้าไปในโปรแกรม ให้สร้างคลังโค้ด เปิดดูโค้ด และทำคำขอรวมโค้ดพร้อมดูความเปลี่ยนแปลงได้จบในที่เดียวโดยไม่ต้องออกไปเว็บอื่น

จุดที่ต่างจากบริการเดิมในตลาดคือมันวางให้ agent เป็นผู้ใช้ระดับเดียวกับคน คือให้ agent เข้ามาตอบคำถามเกี่ยวกับคลังโค้ดและลงมือแก้ในกระบวนการเดียวกับที่คนทำ พร้อมเชื่อมกับบริการนำโค้ดขึ้นใช้งานอย่าง Vercel, Depot และ Buildkite

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

เงื่อนไขการเข้าถึงระบุไว้ว่า "rolling out in early beta to all paid plan users starting today, except enterprise orgs whose admins opt out" คือเปิดให้ผู้ใช้แบบเสียเงินทุกคนทันทีในสถานะทดลองใช้ระยะแรก ยกเว้นองค์กรที่ผู้ดูแลเลือกไม่รับ ส่วนพื้นที่เก็บโค้ดเปิดเฉพาะแพ็กเกจแบบเสียเงินและไม่เปิดให้แพ็กเกจฟรี โดยยังไม่ประกาศราคาแยกและไม่ประกาศเพดานพื้นที่

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

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

Cursor changelog · เอกสาร Origin · เอกสารการทำสำเนาจาก GitHub · นโยบายการใช้ข้อมูล · Tech Startups

หน้าสถานะของ GitHub บันทึกไว้ว่าเหตุขัดข้องเริ่มเวลา 13:40 UTC ของวันที่ 17 ส.ค. และปิดเคสเวลา 21:15 UTC ของวันเดียวกัน รวม 7 ชั่วโมง 35 นาที โดยบริการที่ได้รับผลกระทบครอบคลุมแทบทั้งระบบ ทั้งการดึงและส่งโค้ด การเรียกผ่านช่องทางโปรแกรม ระบบรันงานอัตโนมัติ หน้าคำขอรวมโค้ด และตัวช่วยเขียนโค้ดของ GitHub เอง

ตัวเลขนี้เป็นจุดที่การรายงานคลาดเคลื่อนกันมาก เพราะมีการประกาศเมื่อเวลา 16:59 UTC ว่าแก้ปัญหาของบริการชุดใหญ่ได้แล้ว หลายเจ้าจึงนับจบที่ตรงนั้นและได้ตัวเลขราวสามถึงสี่ชั่วโมง แต่หลังจากนั้นยังมีอาการย้อนกลับของการดึงส่งโค้ดและของหน้ารายการปัญหา ตามด้วยปัญหาการยืนยันตัวตนของตัวช่วยเขียนโค้ดที่ลากยาวจนถึงเวลาปิดเคสจริง

ระดับความเสียหายที่บริษัทรายงานคืออัตราความผิดพลาดราว 20% ของการใช้งานผ่านเว็บและผ่านช่องทางโปรแกรม และราว 50% ของการดาวน์โหลดไฟล์รวมและไฟล์ดิบ ส่วนตัวช่วยเขียนโค้ดถูกประกาศว่าให้บริการไม่เต็มที่ตั้งแต่เวลา 14:31 UTC โดยในช่วงท้ายบริษัทระบุว่าการเรียกใช้ตัวช่วยผ่านโปรแกรมบรรทัดคำสั่งและผ่านแอปไม่ได้รับผลกระทบ

ผลกระทบไม่ได้จบที่ผู้ใช้ GitHub เท่านั้น Cursor เปิดบันทึกเหตุขัดข้องของตัวเองซึ่งระบุสาเหตุว่ามาจากความขัดข้องของ GitHub ตั้งแต่เวลา 14:34 UTC ถึง 20:40 UTC โดยบรรทัดสรุปท้ายหน้าระบุบริการที่ได้รับผลกระทบไว้สี่ตัว คือระบบงานอัตโนมัติ agent ที่ทำหน้าที่ตรวจโค้ด agent ที่รันบนคลาวด์ และบริการที่เพิ่งเปิดตัวในวันเดียวกันตามข้อ 2

สาเหตุยังไม่ถูกเปิดเผย โดยประโยคท้ายของข้อความปิดเคสเขียนไว้ว่า "A detailed root cause analysis will be shared as soon as it is available." และจนถึงวันที่ 18 ส.ค. ยังไม่มีการเผยแพร่รายงานสาเหตุ

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

GitHub Status · Cursor Status · Hacker News

บันทึกการเปลี่ยนแปลงทางการระบุรุ่น 2.1.234 เป็นรุ่นบนสุด และหน้าเผยแพร่บนคลังโค้ดระบุเวลาไว้ที่ 17 ส.ค. เวลา 20:20 ซึ่งเป็นรุ่นถัดจาก 2.1.233 ที่คลังบันทึกไว้เมื่อ 15 ส.ค.

งานหลักของรุ่นนี้คือการปิดช่องเดิมที่ทำต่อเนื่องมาสามรุ่น ถ้อยคำในบันทึกคือ "remote file reads, session restore, CLAUDE.md includes, workflow scripts and file uploads now reject Windows NT-namespace (\??\) paths, hardening the remaining pre-approval file accesses against the NTLM credential-leak vector" คือปิดเส้นทางที่ไฟล์ถูกอ่านก่อนถึงด่านขออนุญาต ซึ่งเป็นช่องที่ใช้ล่อให้เครื่องส่งข้อมูลยืนยันตัวตนออกไปได้

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

อีกจุดที่ควรรู้เพราะเกี่ยวกับข้อมูลส่วนตัวคือบันทึกระบุว่า "Claude is now told to use your account email only to identify you, and not to send it to unrelated services unless you ask" ข้อควรระวังคือบันทึกการเปลี่ยนแปลงไฟล์นี้ไม่มีวันที่กำกับรายรุ่น วันที่ที่ใช้ในข่าวนี้จึงมาจากหน้าเผยแพร่บนคลังโค้ด ไม่ใช่จากตัวบันทึกเอง

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

Claude Code CHANGELOG · หน้าเผยแพร่รุ่น

บริษัทความปลอดภัย Wiz เผยแพร่รายงานเมื่อวันที่ 17 ส.ค. ว่าพบช่องโหว่ในคลังโค้ดสาธารณะของ Snowflake ที่ชื่อ snowflake-connector-net จุดที่พังอยู่ในสคริปต์งานอัตโนมัติที่คอยสร้างรายการติดตามงานเมื่อมีคนเปิดรายงานปัญหาใหม่ โค้ดพยายามกันอักขระพิเศษด้วยคำสั่งแทนที่ข้อความสองชั้น แต่กันไม่พอและกันผิดชั้น เพราะชื่อรายงานปัญหาถูกแทนค่าลงไปในตัวสคริปต์ก่อนที่หน้าที่กันจะได้ทำงาน ผลคือใครก็ตามที่ตั้งชื่อรายงานปัญหาให้ถูกวิธี สั่งให้เครื่องของโครงการรันคำสั่งได้โดยไม่ต้องมีสิทธิ์อะไรเลย

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

จุดที่ยังไม่จบและต้องเล่าเป็นข้อพิพาท ไม่ใช่ข้อเท็จจริง คือบทบาทของฟีเจอร์นั้นในขั้นตรวจ Wiz เติมหมายเหตุแก้ไขท้ายบทความในเย็นวันเดียวกันว่าฟีเจอร์นี้เป็นผู้ร่วมเขียนที่เข้าไปตรวจการรวมโค้ดแล้วรายงานว่าไม่พบปัญหา ขณะที่ GitHub ให้ถ้อยแถลงตรงข้ามว่า "the contributions leading to the vulnerability were authored by a human, and were not reviewed by or contributed to by Copilot" สองฝ่ายนี้ขัดกันเต็มๆ และยังไม่มีหลักฐานสาธารณะชิ้นไหนชี้ขาด สิ่งที่ตรวจสอบซ้ำได้คือ Wiz เติมหมายเหตุแก้ไขแล้วแต่ยังปล่อยประโยคเดิมในเนื้อบทความที่ระบุว่าการแก้อัตโนมัติเป็นตัวสร้างช่องทางโจมตีไว้ตามเดิม

ฝั่งสื่อ The Register แก้พาดหัวพร้อมเติมหมายเหตุว่าหลังตีพิมพ์ Wiz ปรับบทความเพื่ออธิบายว่าตัวเองไม่แน่ใจว่าฟีเจอร์นั้นเป็นต้นเหตุ ส่วน Forbes เติมหมายเหตุว่าอัปเดตเพื่อใส่คำชี้แจงของ GitHub และเปลี่ยนพาดหัวเช่นกัน ขณะที่ยังมีสำนักข่าวที่คงพาดหัวเดิมไว้โดยไม่มีคำแก้ไขใดๆ

ข้อควรระวังของตัวเหตุการณ์เองคือหน้าต่างที่ช่องโหว่เปิดอยู่มีเพียงห้าวัน ตั้งแต่โค้ดถูกรวมเข้าสายหลักเมื่อ 18 มิ.ย. 2026 จนถูกพบเมื่อ 23 มิ.ย. และถูกปิดภายในยี่สิบนาทีหลังเปิดคำขอแก้ ผู้ที่ค้นเจอคือระบบ AI สายโจมตีซึ่งเป็นสินค้าที่ Wiz ขายอยู่ Wiz ระบุว่าสิ่งที่ได้คือสิทธิ์อ่านระบบติดตามงานภายใน ครอบคลุมโครงการฝั่งวิศวกรรม ฝั่งกำกับดูแลความปลอดภัย และฝั่งรับแจ้งช่องโหว่ ส่วน Snowflake ระบุว่าตรวจสอบแล้วไม่พบหลักฐานการเข้าถึงโดยไม่ได้รับอนุญาต เรื่องนี้ยังไม่มีรหัสช่องโหว่สากลกำกับ ณ วันที่ 18 ส.ค. และยังไม่พบตัวเลขเผยแพร่ที่ไหนว่าโค้ดที่ฟีเจอร์แก้อัตโนมัติเสนอมามีอัตราความผิดพลาดเท่าไรเทียบกับที่คนเขียน ถ้อยคำเต็มที่ Wiz สรุปบทเรียนไว้คือ "Critical vulnerabilities can still be introduced and approved within workflows involving AI coding agents, while autonomous AI security agents can rapidly discover and exploit them in the wild."

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

Wiz · Forbes · The Register · The Hacker News · Hacker News

Jessamyn West บรรณารักษ์ที่ทำงานสอนคอมพิวเตอร์ให้คนทั่วไป ปรับปรุงคู่มือของเธอครั้งล่าสุดเมื่อวันที่ 17 ส.ค. เป็นหน้ารวมวิธีปิดหรือหลบฟีเจอร์ AI ที่ผู้ผลิตเปิดให้เองโดยผู้ใช้ไม่ได้ขอ ครอบคลุมราวสิบแปดหมวด ตั้งแต่ Adobe, Android, Apple, เบราว์เซอร์หลักทุกตัว, Google Workspace, Slack, WhatsApp, Zoom, Windows ไปจนถึงอีเมล

ที่มาของคู่มือคือคำถามที่เธอเจอซ้ำที่สุดจากคนที่มาขอความช่วยเหลือที่ห้องสมุด ถ้อยคำของเธอคือ "One of the biggest questions I get at Drop-In Time at the library (besides 'what is taking up all my cloud storage?') is how to disable or avoid intrusive AI that shows up where people don't want it."

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

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

librarian.net · Hacker News

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

ข้อค้นพบที่กลับความเข้าใจเดิมคือกลไกที่ทำให้มันได้ผล ถ้อยคำของผู้เขียนคือ "Procedural anchoring accounts for 65.7% of skill cases, versus 4.5% for explicit knowledge injection, showing that skills stabilize action rather than inject missing facts." แปลว่าประโยชน์หลักไม่ได้มาจากการเติมความรู้ที่โมเดลไม่มี แต่มาจากการยึดลำดับขั้นตอนให้การทำงานนิ่งขึ้น

ตัวเลขที่กระทบวิธีทำงานมากที่สุดคือเรื่องขนาดคลัง "Retrieval is a separate bottleneck: as pools grow from 5 to 100, actual-use precision falls from 29.6% to 3.3%." คือเมื่อคลังคำสั่งโตจากห้าใบเป็นร้อยใบ ความแม่นในการหยิบใบที่ถูกต้องมาใช้จริงตกจากราวสามในสิบเหลือไม่ถึงหนึ่งในสามสิบ

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

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

arXiv 2608.14036

งานนี้จับข้ออ้างที่ฝังอยู่ในการออกแบบเครื่องมือช่วยเขียนโค้ดแทบทุกตัว คือการให้ agent ค้นโค้ดด้วยเครื่องมือที่เข้าใจโครงสร้างภาษา จะประหยัดกว่าการค้นด้วยการจับคู่ข้อความธรรมดา ถ้อยคำของผู้เขียนคือ "The claim that semantic retrieval is more token-efficient is, we find, asserted almost everywhere and measured almost nowhere" ทีมจึงตั้งหน่วยวัดเดียวคือจำนวนโทเคนที่ใช้จนกว่างานจะสำเร็จ แล้วทดลองตัดองค์ประกอบทีละส่วนห้าแบบ บนคลังโค้ดภาษา Python และ TypeScript

ผลที่ได้สวนกับความเชื่อ "The answer is conditional and usually negative. On symbol-named localization the LSP costs tokens (+6% to +118%) and the agent ignores it when free." คือบนงานหาตำแหน่งของสิ่งที่รู้ชื่ออยู่แล้ว เครื่องมือที่เข้าใจโครงสร้างกินโทเคนเพิ่มตั้งแต่ 6% ถึง 118% และเมื่อปล่อยให้ agent เลือกเอง มันหยิบเครื่องมือนั้นมาใช้เพียง 0 ถึง 6% ของเวลา ขณะที่บนงานตามหาจุดที่อ้างอิงถึงกัน มันเลือกใช้ราวครึ่งหนึ่งของเวลา

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

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

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

arXiv 2608.13568

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

ทีมเสนอวิธีเลือกโมเดลแบบใหม่ที่ดูสัญญาณระหว่างทางว่างานนี้มีแนวโน้มจะต้องลองใหม่หรือไม่ แล้วรายงานว่า "On GSM8K under a fixed budget, InflationAgent achieves 94.7% accuracy versus 91.0% for FrugalGPT while using 31% fewer tokens, and we show that forwarding a failed reasoning chain to GPT-4o reduces its accuracy by up to 34.8 percentage points, validating the fresh-escalation design."

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

สิ่งที่บทคัดย่อไม่ได้บอกคือไม่ระบุชื่อโมเดลขนาดเจ็ดพันล้านพารามิเตอร์ที่ใช้ และผลปลายทางรายงานบนชุดทดสอบเดียวซึ่งเป็นโจทย์คณิตศาสตร์ ไม่ใช่งาน agent ที่เรียกเครื่องมือจริง อีกทั้งไม่มีตัวเลขเวลาที่ใช้จริงและไม่มีตัวเลขเป็นเงิน งานนี้ส่งขึ้นระบบตั้งแต่ 2 ก.ค. 2026 โมเดลที่ใช้เทียบจึงเก่ากว่าวันประกาศ

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

arXiv 2608.13571

ทีมวิจัยประเมินระบบตอบคำถามกฎหมายที่ทำงานด้วยการค้นจากตัวบทจริงก่อนตอบจำนวน 8 ระบบ บนตัวบทกฎหมายสองชุดคือกฎหมายคุ้มครองข้อมูลของยุโรปฉบับภาษาอังกฤษ และประมวลกฎหมายแพ่งฉบับภาษาฝรั่งเศส โดยตรวจทั้งระดับข้อความรายข้อและระดับคำตอบทั้งคำตอบ แยกดูตามประเภทคำถามและตามลักษณะผู้ถาม แล้วยืนยันผลด้วยชุดคำถาม 142 ข้อที่ผู้เชี่ยวชาญกฎหมายเขียนขึ้นเองต่างหาก

ผลที่รายงานคือ "Our results show that hallucinations remain pervasive, ranging from less than 10% of responses for the best-performing systems to nearly half in the worst case." คือช่วงห่างระหว่างระบบที่ดีที่สุดกับแย่ที่สุดกว้างมาก จากต่ำกว่าหนึ่งในสิบไปจนถึงเกือบครึ่งของคำตอบทั้งหมด

ประเภทคำถามที่ทำให้ระบบพังหนักที่สุดคือคำถามที่มีสมมติฐานผิดฝังอยู่ในตัวคำถามเอง ซึ่งคำตอบที่ถูกต้องคือการปฏิเสธสมมติฐานนั้น ไม่ใช่การตอบตามที่ถาม

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

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

arXiv 2608.14210

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

ผลคือไม่มีวิธีไหนชนะครบทั้งสี่แกน และตัวเลขที่แรงที่สุดคือ "A 120B LLM-judge, strongest on benign inputs, loses 47 accuracy points (0.74 to 0.27) on keyword-stuffed Consumer Duty inputs" คือตัวตัดสินที่เก่งที่สุดบนข้อความปกติ พอเจอข้อความที่จงใจยัดคำที่ฟังดูเข้าเกณฑ์เข้าไป ความแม่นตกจาก 0.74 เหลือ 0.27

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

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

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

arXiv 2608.14329

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

ตัวเลขที่รายงานคือ "In an illustrative 200-item, 10-epoch evaluation, it removes 57%-97% of planned trials across nine validation settings, with overall conclusions equivalent to the full run." คือบนการประเมิน 200 ข้อ 10 รอบ ตัดรอบที่วางแผนไว้ออกได้ตั้งแต่ 57% ถึง 97% ข้ามเก้าสถานการณ์ทดสอบ โดยข้อสรุปรวมเท่ากับการรันเต็ม

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

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

arXiv 2608.14425

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

ตัวเลขที่บอกขนาดของงานคือรายการสินค้าที่อยู่ในบัญชีเฝ้าระวังเพิ่มจาก 49 รายการครอบคลุม 194 พิกัดศุลกากร เป็น 67 รายการครอบคลุม 274 พิกัด โดยมีผลตั้งแต่ 1 มิ.ย. 2569 และมีกำหนดหารือกับผู้แทนการค้าสหรัฐระหว่างวันที่ 28 ถึง 31 ส.ค. นี้

ถ้อยคำของนางอารดา เฟื่องทอง อธิบดีกรมการค้าต่างประเทศ คือ "ไทยตระหนักถึงความเสี่ยงเรื่อง transshipment และให้ความสำคัญกับเรื่องนี้อย่างจริงจัง หากพบการแอบอ้างถิ่นกำเนิดสินค้าหรือการกระทำที่ฝ่าฝืนกฎหมาย ไทยพร้อมดำเนินการตามกฎหมาย"

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

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

ไทยรัฐ

รายงานที่ Blognone เรียบเรียงจาก Reuters เมื่อวันที่ 17 ส.ค. ระบุว่าไมโครซอฟท์แจ้งตลาดหลักทรัพย์ว่าได้ปิดสำนักงานและกิจการร่วมค้าในจีนไปแล้วอย่างน้อย 15 แห่งในรอบห้าปี ปลดพนักงานฝ่ายคลาวด์ในจีนราว 200 ถึง 400 คน และย้ายสายการผลิตฮาร์ดแวร์ออกนอกประเทศโดยตั้งเป้าให้ผลิตนอกจีน 80%

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

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

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

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

Blognone

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

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

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

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

กรุงเทพธุรกิจ

SB Energy ประกาศเมื่อวันที่ 17 ส.ค. ว่าร่วมกับ Nvidia และ OpenAI สร้างศูนย์ข้อมูลสำหรับงาน AI ที่ Pike County รัฐโอไฮโอ โดย OpenAI เป็นผู้เช่าหลักภายใต้สัญญา 20 ปี กำลังการประมวลผลระยะแรกอยู่ที่ 4.25 กิกะวัตต์ และมีสิทธิ์ขยายอีก 3.75 กิกะวัตต์ รวมเป็น 8 กิกะวัตต์ ส่วน Nvidia เป็นผู้ให้การสนับสนุนด้านเครดิตแก่ผู้สร้าง และลงทุนในบริษัทผู้สร้างอีก 1,500 ล้านดอลลาร์

ตัวเลขที่บอกขนาดของโครงการคือเงินลงทุนโครงสร้างพื้นฐานระบบไฟฟ้า 4,200 ล้านดอลลาร์ กองทุนคืนประโยชน์ให้ชุมชนตั้งต้น 80 ล้านดอลลาร์ บวกอีก 40 ล้านจาก OpenAI เฟสแรก 800 เมกะวัตต์มีกำหนดเดินเครื่องปี 2571 ใช้เวลาสร้างหกปี สร้างงานก่อสร้าง 35,000 ตำแหน่ง แต่เป็นงานถาวรเพียง 2,500 ตำแหน่ง ที่ตั้งคือโรงงานเสริมสมรรถนะยูเรเนียมเดิมที่เดินเครื่องระหว่างปี 2497 ถึง 2544

จุดที่ต้องบันทึกไว้เพราะตัวเลขยังไม่นิ่งคือวงเงินที่ Nvidia ค้ำให้ สื่อรายงานไม่ตรงกันระหว่างตัวเลขสูงสุด 105,000 ล้านดอลลาร์ในรูปภาระผูกพันค่าเช่าและค่าไฟที่มีเงื่อนไข กับรายงานก่อนหน้าเมื่อ 14 ส.ค. ที่ระบุว่าจะค้ำในระยะแรกต่ำกว่า 120,000 ล้านดอลลาร์ ซึ่งเป็นการปรับลดจากตัวเลขเดิม 250,000 ล้านที่คลังบันทึกไว้เมื่อ 16 ส.ค. ยังไม่มีแหล่งใดอธิบายว่าสองตัวเลขนี้นับจากฐานเดียวกันหรือไม่

ข้อควรระวังคือประกาศฉบับของ OpenAI เองยังเปิดอ่านไม่ได้ ข้อมูลทั้งหมดจึงมาจากประกาศของคู่สัญญาและสื่อท้องถิ่น และสัญญาเช่า 20 ปีที่ปรากฏในประกาศของผู้สร้าง ขัดกับรายงานของสื่อบางเจ้าที่ระบุ 10 ปี

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

SB Energy · WOSU · Blognone

404 Media เผยแพร่งานสืบสวนเมื่อวันที่ 17 ส.ค. โดยขอให้ผู้ขายหนังสือใส่อุปกรณ์ติดตามของ Apple ไว้ในหนังสือหนึ่งเล่มจากคำสั่งซื้อที่ผิดปกติ แล้วตามไปจนพบว่าปลายทางคือคลังของ Amazon ในลาสเวกัส และพนักงานที่ทำงานที่นั่นระบุว่างานของพวกเขาคือการรับหนังสือจำนวนมากแล้วตัดสันออกเพื่อให้สแกนได้เร็วขึ้น

ข้อสรุปที่บทความเขียนไว้ตรงตัวคือ "Amazon is buying massive quantities of books, scanning them for AI training data, and destroying them in the process." และคำอธิบายจากฝั่งพนักงานคือ "Amazon employees who work at this location say all they do is receive massive shipments of printed books which they then cut the bindings off in order to scan the books more quickly."

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

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

404 Media · Simon Willison

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

Jingna Zhang ผู้ก่อตั้งแพลตฟอร์มระบุว่ามาตรการป้องกันในระดับแพลตฟอร์มเอาไม่อยู่ และชี้ว่ายังไม่มีนโยบายจากภาครัฐที่คุ้มครองผู้สร้างงานอย่างชัดเจน

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

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

Blognone

Dario Amodei ผู้บริหารสูงสุดของ Anthropic เผยแพร่ข้อความยาวเมื่อวันที่ 15 ส.ค. ที่กลายเป็นกระทู้ถกเถียงใหญ่บนเว็บบอร์ดนักพัฒนาในวันที่ 17 ส.ค. โดยเถียงว่าข้อกล่าวหาที่ว่าการสนับสนุนให้ออกกฎกำกับ AI เท่ากับการกีดกันผู้เล่นรายเล็กนั้นเป็นทางเลือกลวง และยกตัวอย่างกฎหมายที่บริษัทสนับสนุนซึ่งยกเว้นบริษัทที่มีรายได้ต่ำกว่า 500 ล้านดอลลาร์

ประเด็นที่เขายอมรับเองและเป็นส่วนที่ถูกอ้างต่อมากที่สุดคือ "I think by far the most accurate criticism of AI companies including Anthropic is that we haven't yet delivered on our big promises to benefit the world. That is totally on us." และเขาเขียนต่อว่า "at this point, saying that AI will cure cancer is more a cliche than it is inspiring, and most people think it is deceptive. The thing that will work is actually curing cancer."

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

ฝั่งที่โต้กลับคือ Gary Marcus ที่เผยแพร่บทความในวันที่ 17 ส.ค. โดยยกข้อโต้แย้งว่า "not one drug designed by AI had yet reached clinical adoption, even after over a decade of efforts" และยกคำอธิบายของนักวิจัยว่ามะเร็งไม่ใช่โรคเดียวแต่เป็นโรคที่ต่างกันกว่าสองร้อยชนิด ข้อควรระวังคือข้อความต้นทางเปิดอ่านโดยตรงไม่ได้ ต้องอ่านผ่านเว็บสะท้อนภาพ จึงยืนยันเวลาโพสต์จากต้นทางไม่ได้

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

xcancel mirror · Semafor · Gary Marcus · Hacker News

Rick Manelius เผยแพร่บทความเมื่อวันที่ 17 ส.ค. เสนอคำเรียกใหม่ว่า AI;DR โดยล้อกับคำว่า TL;DR ที่คนใช้กันมานาน ใจความคือถ้าผู้ส่งไม่ยอมอ่านและแก้สิ่งที่ AI เขียนก่อนส่ง ผู้รับก็มีสิทธิ์ที่จะไม่อ่านเช่นกัน ถ้อยคำของเขาคือ "If you're not bothered enough to review and edit it...then I'm not going to bother reading it." และ "TL;DR (too long; didn't read) was the solution for social media. AI;DR (AI; didn't read) is the solution for AI slop."

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

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

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

rickmanelius.com · Hacker News