AI News · 2026-08-04

Alibaba เปิด Qwen3.8-Max ให้ใช้งานทั่วไปเมื่อ 3 ส.ค. หลังอยู่ในสถานะ preview มาตั้งแต่ 19 ก.ค. ตัวโมเดลมีพารามิเตอร์รวม 2.4 ล้านล้านตัวแบบ MoE โดยใช้งานจริง 95 พันล้านตัวต่อหนึ่งคำถาม คิดเป็นราว 4% ของพูลทั้งหมด ราคาอยู่ที่ 2 ดอลลาร์ต่อล้านโทเคนขาเข้าและ 6 ดอลลาร์ขาออก ส่วนการอ่านจากแคชอยู่ที่ 0.25 ดอลลาร์ ตอนเปิดตัว preview เดือนที่แล้ว Alibaba พูดถึงสมรรถนะด้วยคำเดียวว่าเป็นรองแค่ Claude Fable 5 โดยไม่มีตัวเลขประกอบ วันนี้ตัวเลขออกมาครบแล้ว

สิ่งที่ตารางบอกคือคำเคลมนั้นไม่ตรง บน SWE-bench Pro ซึ่งวัดงานแก้โค้ดจริง Qwen ได้ 67.7 แพ้ทั้ง Claude Opus 4.8 ที่ 69.2 และ Claude Fable 5 ที่ 80.0 บน FrontierSWE ได้ 73.5 แพ้ Fable 5 ที่ 88.8 อยู่ 15.3 จุด ส่วน GPQA Diamond ที่ได้ 92.6 นั้นเสมอ Fable 5 พอดีและแพ้ GPT-5.6 Sol ที่ 94.1 จุดที่ชนะจริงมีจุดเดียวคือ Terminal-Bench 2.1 ที่ได้ 86.6 เหนือทั้ง Opus 4.8 และ Fable 5 ซึ่งได้ 84.6 เท่ากันพอดี แต่ก็ยังแพ้ GPT-5.6 Sol โหมด max ที่ 88.8

ฝั่งการวัดอิสระซึ่งเป็นคำถามที่คลังตั้งค้างไว้ตั้งแต่เดือนที่แล้ว ตอนนี้มีคำตอบแล้ว บนกระดาน Code Arena หมวด WebDev ของ arena.ai เมื่อ 4 ส.ค. Qwen3.8-Max อยู่อันดับสี่ที่ 1,668 คะแนน ตามหลัง Claude Opus 5 โหมด Max ที่ 1,705 Kimi K3 โหมด Max ที่ 1,676 และ Claude Opus 5 โหมด High ที่ 1,669 คือแพ้อันดับสามอยู่แค่คะแนนเดียว ข้อควรระวังคือคะแนนแบบนี้ขยับจริงและขยับเร็ว เมื่อ 28 ก.ค. กระดานเดียวกันเคยรายงาน Opus 5 โหมด Max ที่ 1,725 และ Kimi K3 ที่ 1,682 ตกลงมาภายในสัปดาห์เดียว ตัวเลขกระดานจึงต้องติดวันที่กำกับเสมอ

เรื่อง weights ยังเป็นคำสัญญาเหมือนเดิม Alibaba ระบุว่าจะปล่อยสัปดาห์หน้าและจะปล่อยรุ่นเล็ก Qwen3.8-27B ด้วย ซึ่งถ้าเกิดขึ้นจริงจะเป็นครั้งแรกที่ Alibaba เปิด weights ของรุ่นระดับ Max แต่ ณ วันนี้ยังโหลดไม่ได้ และยังไม่มีแหล่งไหนระบุ license เลยแม้แต่เจ้าเดียว จึงห้ามเดาว่าเป็น Apache 2.0 ตามรุ่นก่อน

▲ ทำไมต้องรู้ · บทเรียนที่ใช้ได้ทันทีไม่ใช่เรื่องว่าโมเดลตัวไหนเก่งกว่า แต่เป็นเรื่องวิธีอ่านข่าวโมเดล เพราะข่าวนี้มีสื่อสองเจ้ารายงานตัวเลขจากตารางใบเดียวกันแล้วให้ภาพตรงข้ามกัน เจ้าที่เทียบกับ Claude Opus 4.8 ได้ข้อสรุปว่า Qwen ชนะสองในสามรายการ ส่วนเจ้าที่เทียบกับ Claude Fable 5 ได้ข้อสรุปว่าแพ้ขาด และทั้งคู่ไม่มีใครเขียนเลขผิดเลยสักตัว ต่างกันแค่หยิบคนละคอลัมน์ เวลาเห็นพาดหัวว่าโมเดลใหม่ชนะรุ่นท็อป คำถามแรกที่ต้องถามคือชนะเทียบกับตัวไหนและตัวนั้นเป็นรุ่นบนสุดของค่ายนั้นจริงหรือเปล่า สำหรับคนที่ต้องเลือกโมเดลไปใช้งานจริง ราคา 2 ต่อ 6 ดอลลาร์ถือว่าถูกกว่ารุ่นท็อปของฝั่งอเมริกาอยู่มาก และถ้า weights ออกจริงสัปดาห์หน้าก็จะเป็นตัวเลือกที่รันเองในองค์กรได้ แต่ตอนนี้ยังเรียกว่าโมเดลเปิดไม่ได้เพราะยังโหลดไม่ได้จริง

Alibaba Qwen · the-decoder · MarkTechPost · Blognone · Artificial Analysis · qwen-3-8

MiniMax เปิด MiniMax-H3 บน Hugging Face เป็นโมเดล Transformer แบบ dense single-stream ขนาด 33 พันล้านพารามิเตอร์ ชื่อสถาปัตยกรรมว่า H3-Omni-Transformer แบ่งเป็นสามส่วนคือ H3-Context-IR สำหรับเตรียมข้อมูล H3-Base สำหรับสร้าง และ H3-Regenerate-2K สำหรับขยายความละเอียด

ความสามารถที่หน้าโมเดลระบุคือรับ context ผสมทั้งข้อความ ภาพ วิดีโอ และเสียงพร้อมกัน แล้วสร้างวิดีโอที่มีเสียงสเตอริโอมาในตัวเลย ที่ความละเอียดสูงสุด 2K และความยาวสูงสุด 15 วินาที ในราว 13 พันล้านพารามิเตอร์เป็นส่วน AdaLN ที่แคชไว้ได้ตอนใช้งานจริง จึงไม่ต้องโหลดทั้ง 33 พันล้านตัวทุกครั้ง

ข้อควรระวังคือหน้าโมเดลไม่ให้คะแนน benchmark ไว้เลยแม้แต่ตัวเดียว และไม่ระบุขนาด context window ด้วย license เป็นสัญญาเฉพาะของ MiniMax เองชื่อ MiniMax H3 Community License Agreement ไม่ใช่ MIT หรือ Apache จึงต้องอ่านเงื่อนไขก่อนเอาไปใช้เชิงพาณิชย์

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

Hugging Face

David Crawshaw เขียนเมื่อ 2 ส.ค. ว่าสิ่งที่ AI agent เปลี่ยนไม่ใช่ความเร็วในการเขียนโค้ด แต่เป็นเศรษฐศาสตร์ของการปรับแต่งซอฟต์แวร์ให้เข้ากับตัวเอง เดิมทีการเพิ่มฟีเจอร์ที่คุณคนเดียวต้องการนั้นไม่คุ้มแรง ทุกคนจึงยอมใช้ระบบตั้งค่าที่ผู้ผลิตเตรียมไว้ให้ แต่เขาเขียนว่า "Agents do the heavy lifting. For a single user...a top-end agent can usually now add a feature in a single shot." คือ agent รับงานหนักไปแล้ว สำหรับผู้ใช้คนเดียว agent ระดับบนสุดมักเพิ่มฟีเจอร์ให้ได้จบในครั้งเดียว

ข้อสรุปของเขาคือ "For end-user products to make sense in a company today, they need to be personalizable. Which means we need the source code." และเขายกตัวอย่างที่ตรงตัวที่สุดว่า "Where you would hit a wall, however, is Claude Code. It is closed-source software, so you don't get to personalize it." คือจุดที่จะชนกำแพงคือ Claude Code เพราะมันปิดซอร์ส คุณจึงปรับแต่งมันไม่ได้

สิ่งที่นำไปใช้ได้ทันทีคือ prompt ที่เขาเสนอ ซึ่ง Simon Willison หยิบมาเน้นเป็นโพสต์แยกต่างหาก คือ "Set up a nightly cron job that executes the prompt: fetch upstream changes to the and rebase all local changes on top of upstream. Check that the software works as intended and replace the current version." แปลว่าตั้งงานอัตโนมัติรายคืนให้ดึงการเปลี่ยนแปลงจากต้นทางมา แล้ววางการแก้ของเราทับลงไป จากนั้นตรวจว่ายังทำงานได้ตามเดิมแล้วค่อยเปลี่ยนเวอร์ชัน

ฝั่ง Willison เสริมในความเห็นบน Hacker News ว่าอุดมคติดั้งเดิมของ open source ที่ว่าผู้ใช้แก้เครื่องมือเองได้นั้น เอาเข้าจริงคนส่วนใหญ่ไม่มีเวลาทำ เขาเขียนว่า "Getting software to compile in order to start hacking on it used to be enough friction that I often wouldn't bother." คือแค่ทำให้มันคอมไพล์ผ่านก็เป็นอุปสรรคมากพอที่เขาจะไม่ยุ่งด้วยแล้ว และสรุปว่า "I think LLMs have changed that equation in a way that makes the original dream much more feasible."

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

exe.dev · Willison ยกคำพูด · Willison ความเห็นบน HN

Niklas Gruhn เขียนเมื่อ 3 ส.ค. ถึงพฤติกรรมที่เขาเจอบ่อยขึ้นเรื่อยๆ คือเพื่อนร่วมงานเอาคำตอบจาก AI มาวางต่อให้เขาใน Slack ในคอมเมนต์ pull request และในกลุ่มแชต โดยไม่ได้อ่านหรือกลั่นกรองอะไรก่อน เขาเรียกคนที่ทำแบบนี้ว่า meat proxy คือเป็นแค่ตัวกลางที่เป็นเนื้อหนัง

เหตุผลที่เขาบอกว่ามันไม่มีประโยชน์คือ "I can talk to Claude myself. It's going to be faster and I get to control the context." คือเขาคุยกับ Claude เองได้ เร็วกว่า และคุมบริบทได้ด้วย การมีคนมาวางคำตอบให้จึงไม่ได้เพิ่มอะไรเลย

เขาอธิบายต่อว่าทำไมมันถึงเป็นภาระกับคนรับ ด้วยประโยคที่ตรงกับประสบการณ์คนจำนวนมาก คือ "Reading AI output is extra effort. It's verbose, frequently contains all too plausible nonsense, and is increasingly jargon dense." แปลว่าการอ่านผลลัพธ์จาก AI เป็นงานเพิ่ม เพราะมันยาว มักมีเรื่องผิดที่ฟังดูน่าเชื่อปนอยู่ และศัพท์แน่นขึ้นเรื่อยๆ

ข้อเสนอของเขาไม่ใช่ห้ามใช้ AI แต่เป็นการกำหนดว่าอะไรคือคุณค่าที่คนเพิ่มเข้าไป เขาเขียนว่า "By all means, prompt AI. But don't just relay the output. Read it, understand it, validate it, and then write a response in your own words (a decent certificate that you've done the prior steps)." คือใช้ AI ได้เต็มที่ แต่อย่าแค่ส่งต่อผลลัพธ์ ให้อ่าน ทำความเข้าใจ ตรวจสอบ แล้วเขียนตอบด้วยคำของตัวเอง ซึ่งการเขียนด้วยคำตัวเองนั่นแหละคือใบรับรองว่าคุณทำสามขั้นแรกมาแล้วจริง

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

gruhn.me · Willison

release note ของ Claude Platform API ลงวันที่ 1 ส.ค. ระบุสั้นๆ ว่า "Dreams (research preview) now supports Claude Opus 5." คือฟีเจอร์ Dreams ซึ่งอยู่ในกลุ่ม Managed Agents และยังมีสถานะเป็น research preview รองรับ Claude Opus 5 แล้ว

นี่เป็นรายการเดียวที่เพิ่มเข้ามาใน changelog ของฝั่ง API นับตั้งแต่ 24 ก.ค. ซึ่งเป็นวันเปิดตัว Opus 5 ส่วนฝั่ง Claude Code changelog ยังค้างที่เวอร์ชัน 2.1.220 เป็นวันที่เจ็ดติดต่อกัน และ Gemini API changelog ก็ยังไม่มีอะไรใหม่หลัง 30 ก.ค.

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

Claude Platform release notes

โปรเจกต์ชื่อ Nightcrawler ขึ้น Hacker News เมื่อ 3 ส.ค. ได้ 102 คะแนน เป็น agent ทดสอบเจาะระบบที่ทำงานครบวงจรบนโทรศัพท์เครื่องเดียว ตั้งแต่ค้นหาเครื่องในเครือข่าย ไล่ดูบริการที่เปิดอยู่ หาช่องโหว่ ไปจนถึงออกรายงาน โดย README ระบุว่าทำได้ "all without cloud connectivity" คือไม่ต้องต่อคลาวด์เลย เพราะใช้โมเดลขนาด 1.2 พันล้านพารามิเตอร์รันบน GPU ของโทรศัพท์ผ่าน OpenCL ตัวเครื่องที่ทดสอบคือ Android ที่ลง Kali NetHunter แรม 12GB ขึ้นไป และต้อง root license เป็น MIT

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

คำถามที่คมที่สุดในกระทู้จึงไม่ใช่ว่ามันเก่งแค่ไหน แต่เป็นคำถามที่ว่า "What does the 50% look like when it fails? Garbage the parser throws out is easy to handle, but a well formed command aimed at the wrong host gets past the scope check..." คือความล้มเหลวอีกครึ่งหนึ่งหน้าตาเป็นอย่างไร เพราะคำสั่งที่พังจนพาร์สไม่ผ่านนั้นจัดการง่าย แต่คำสั่งที่รูปแบบถูกต้องทุกอย่างแต่ยิงไปผิดเครื่อง จะผ่านด่านตรวจขอบเขตไปได้

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

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

GitHub · HN

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

ตัวเลขที่ต้องเล่าให้ตรงคือ 57 จาก 72 การตั้งค่าผ่านด่านเดโม และ 32 ผ่านด่านใช้งานจริง คิดเป็น 44.4% ของทั้งหมด แต่ตัวเลขที่เปเปอร์ใช้พาดหัวคือ 56.1% ซึ่งเป็นคนละฐาน มันคือสัดส่วนของตัวที่ผ่านเดโมมาแล้วและไปถึงใช้งานจริงได้ นับจากฐาน 57 ไม่ใช่ 72 อีกนัยหนึ่งคือในบรรดาของที่โชว์เดโมผ่านให้ผู้บริหารดูแล้ว มี 43.9% ที่ไปไม่ถึงการใช้งานจริง

ผลที่นำไปใช้ได้ตรงที่สุดคือเรื่องภาระการตรวจ เครื่องมือที่ไม่บอกความมั่นใจของตัวเองเลย บังคับให้ต้องตรวจงาน 100% เพราะไม่ได้ให้อะไรคนตรวจไว้ใช้คัดกรองเลย พอบังคับให้มันอ้างอิงแหล่งที่มาของทุกชิ้นและระบุความมั่นใจ ภาระลดเหลือ 49% ส่วนการเพิ่มขั้นตอนให้มันอ่านทวนตัวเองอีกรอบ ลดต่อได้อีกเล็กน้อยเหลือ 44% แต่แลกมาด้วยเวลาที่เพิ่มขึ้น 2.3 เท่า

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

ข้อควรระวังมีสามข้อและต้องพูดครบ ข้อแรกคือนี่เป็น preprint ผู้เขียนคนเดียว ยังไม่ผ่าน peer review ข้อสองคือผู้เขียนเป็นผู้บริหารสายกลยุทธ์ AI ของกลุ่มธนาคารเพื่อการลงทุนแห่งหนึ่ง และข้อสรุปของเปเปอร์ที่ว่าการตั้งค่าแบบมีกำกับดูแลคือตัวชนะ ตรงกับสิ่งที่เขาสร้างและดูแลในงานประจำ ซึ่งเปเปอร์ไม่ได้ประกาศความเกี่ยวข้องนี้ไว้เลย ทั้งที่ตัวเกณฑ์ตัดสินก็มาจากเขาเอง โดยเปเปอร์ระบุตรงๆ ว่า "The acceptance bars are practitioner-elicited, not derived. They represent one operator's view of what a regulated deployment requires." ข้อสามคือเอกสารที่ใช้ทดสอบสี่ในหกแบบเป็นข้อมูลสังเคราะห์ อีกสองแบบใช้เอกสารยื่นจริงจากระบบเปิดเผยข้อมูลของ ก.ล.ต. สหรัฐ ไม่มีข้อมูลลูกค้าจริงของสถาบันไหนเลย และเปเปอร์ยอมรับเองว่าเอกสารชุดนี้สะอาดกว่าของจริง ช่องว่างที่วัดได้จึงเป็นขอบล่าง

▲ ทำไมต้องรู้ · ประโยคที่ผู้เขียนสรุปไว้เองใช้ได้ทันทีกับทุกองค์กรที่กำลังจะซื้อหรือสร้างเครื่องมือ AI คือ "the value of an AI workflow is set less by how often it is right than by how much of it a human must still check, and that the second property is measurable and rarely measured." แปลว่าคุณค่าของงานที่ให้ AI ทำ ถูกกำหนดโดยสัดส่วนที่คนยังต้องตรวจ มากกว่าถูกกำหนดโดยความถี่ที่มันตอบถูก และคุณสมบัติข้อหลังนี้วัดได้แต่แทบไม่มีใครวัด คำถามที่ควรถามผู้ขายเพิ่มจึงไม่ใช่แค่ว่าแม่นกี่เปอร์เซ็นต์ แต่คือเครื่องมือนี้บอกได้ไหมว่าชิ้นไหนมันไม่มั่นใจ ถ้าตอบไม่ได้ แปลว่าทีมคุณต้องตรวจทุกชิ้นและตัวเลขความแม่นที่โชว์มาก็แทบไม่ช่วยอะไร อีกจุดที่ควรจำคือช่องว่างระหว่างเดโมกับของจริง เพราะเกือบครึ่งของสิ่งที่สาธิตผ่านแล้วไปต่อไม่ได้ การเห็นเดโมสำเร็จจึงยังไม่ใช่หลักฐานว่าใช้งานได้

arXiv 2607.28666

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

ปัญหาแรกอยู่ที่ตัวชี้วัด เปเปอร์ชี้ว่าบน benchmark ที่ตัดสินแบบสองทางและให้คะแนนด้วยค่า F₁ นโยบายที่ตอบว่าใช่ทุกข้อโดยไม่ต้องคิดเลย จะได้คะแนน 0.690 บนชุด R-Judge ซึ่งสูงกว่าโมเดลจริงถึงห้าตัวจาก 21 ตัวที่แยกแยะได้จริง

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

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

▲ ทำไมต้องรู้ · ทุกวันนี้เวลาผู้ขายบอกว่าโมเดลของเขาปลอดภัย มักมาพร้อมคะแนนหนึ่งตัวโดยไม่บอกว่ามาจากชุดไหน งานนี้ให้ประโยคปิดที่ใช้ถามกลับได้เลย คือ "Naming the benchmark, metric, target behavior, and model panel is the minimum a safety claim needs." แปลว่าการระบุชื่อชุดทดสอบ ตัวชี้วัด พฤติกรรมที่วัด และรายชื่อโมเดลที่เอามาเทียบ คือขั้นต่ำที่คำเคลมความปลอดภัยต้องมี ถ้าขาดข้อใดข้อหนึ่งก็ยังไม่ใช่ข้อมูลที่ใช้ตัดสินใจได้ อีกบทเรียนที่กว้างกว่านั้นและใช้ได้กับ benchmark ทุกประเภทคือ ก่อนเชื่อคะแนนใดๆ ให้ถามว่าถ้าตอบมั่วแบบเดาทางเดียวไปเลยจะได้เท่าไร เพราะถ้าตัวเลขนั้นสูงใกล้เคียงของจริง คะแนนชุดนั้นก็ยังไม่ได้บอกอะไร ข้อควรระวังคือทั้งหมดเป็นตัวเลขที่เปเปอร์รายงานเอง ยังไม่มีใครทำซ้ำ

arXiv 2607.28685

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

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

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

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

arXiv 2607.28802

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

ชุดทดสอบชื่อ ANCHOR ประกอบด้วยบทสนทนา 2,008 ชุด ครอบคลุม 27 บุคลิก ตารางการคุยเก้าแบบ การตั้งค่าความจำสามแบบ และโมเดลสี่ตัว โดยแยกวัดสองมิติคือความสามารถในการสวมบทบาท ด้วยแบบสอบถามปิดผนึก 102 ข้อบวกการตัดสินรายรอบ กับความสามารถในการจำเส้นทางที่คุยกันมา ด้วยคำถามย้อนแย้ง 110 ข้อที่ปรับเทียบแล้วจากคลังบทสนทนา 35 ชุด

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

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

arXiv 2607.28818

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

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

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

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

arXiv 2607.23802

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

ประเด็นสำคัญคือช่องว่างไม่ได้อยู่ที่ความรู้ทางการแพทย์ เพราะโมเดลสอบใบประกอบวิชาชีพผ่านแล้ว และในเคสที่คัดมาอย่างดีก็สู้แพทย์ได้ในการให้เหตุผลเชิงวินิจฉัย แต่ช่องว่างอยู่ที่ธรรมชาติของงาน โดยผู้เขียนอธิบายว่า "Safe triage is not the selection of the most likely diagnosis; it is a sequential decision under asymmetric cost, in which the single catastrophic miss outweighs many false alarms" คือการคัดกรองที่ปลอดภัยไม่ใช่การเลือกโรคที่น่าจะเป็นที่สุด แต่เป็นการตัดสินใจต่อเนื่องภายใต้ต้นทุนที่ไม่สมมาตร ซึ่งการพลาดร้ายแรงครั้งเดียวหนักกว่าการเตือนผิดหลายครั้ง

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

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

arXiv 2607.28677

Bloomberg รายงานโดยอ้างแหล่งข่าวที่ไม่เปิดเผยชื่อว่า Moonshot AI บรรลุข้อตกลงจัดหาชิป NVIDIA ตระกูล Blackwell เพิ่มอีก 20,000 ชิป ผ่านทาง Alibaba ก่อนหน้านี้ Moonshot เคยได้ชิปรุ่น Hopper มาแล้วราว 20,000 ตัวจากประเทศหนึ่งในเอเชียตะวันออกเฉียงใต้

จุดที่ทำให้เรื่องนี้น่าสนใจคือความสัมพันธ์ที่ซับซ้อนระหว่างสองบริษัท เพราะ Alibaba เป็นทั้งผู้ลงทุนรายใหญ่ใน Moonshot และเป็นคู่แข่งโดยตรงในเวลาเดียวกัน เนื่องจาก Alibaba พัฒนา Qwen ซึ่งแข่งกับ Kimi อยู่ และก่อนหน้านี้ Alibaba เคยปฏิเสธข่าวว่าจัดหาชิป H200 ให้ Moonshot

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

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

Blognone

Wafer.ai ทดลองรันโมเดลเปิด Kimi K3 บนชิป AMD MI355X เทียบกับ NVIDIA B300 ผลด้านราคาคือ MI355X เช่าอยู่ที่ 2.5 ดอลลาร์ต่อชิปต่อชั่วโมง ขณะที่ B300 อยู่ที่ 6 ดอลลาร์ ส่วนความเร็วในการสร้างคำตอบ B300 ทำได้ 172 โทเคนต่อวินาที ส่วน MI355X ได้ 118

เมื่อคิดเป็นต้นทุนต่อโทเคนจากตัวเลขสองชุดนี้ ฝั่ง AMD ถูกกว่าราว 39% แม้จะช้ากว่าราว 31% ก็ตาม ตรงนี้เป็นการคำนวณของเราเองจากตัวเลขข้างต้น ไม่ใช่ตัวเลขที่ Wafer.ai ระบุไว้เอง

สิ่งที่ต้องแลกคืองานวิศวกรรมที่ต้องทำเอง รุ่น Kimi-K3-DSpark รันบน ROCm ไม่ได้เลย และในขั้นตอน prefill นั้น ROCm ไม่ยอมโหลดเคอร์เนล AITER MLA เพราะ Kimi K3 ใช้ attention head จำนวน 12 ซึ่งไม่ตรงกับขนาดที่รองรับคือ 4, 8 และ 16 ทีมงานแก้ด้วยการเติมค่าศูนย์เข้าไปให้ครบขนาดที่รองรับ แล้วได้ประสิทธิภาพเพิ่มขึ้น 2 ถึง 3 เท่า

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

Blognone

บทความลงวันที่ 31 ก.ค. รวบรวมตัวเลขหนี้ที่มากับการลงทุนโครงสร้างพื้นฐาน AI จากหลายแหล่ง ตัวเลขที่เป็นพาดหัวมาจากการศึกษาของ Nikkei ซึ่งระบุว่าหนี้ที่ไม่ปรากฏบนงบดุลของบริษัทเทคยักษ์ใหญ่สหรัฐอยู่ที่ 1.65 ล้านล้านดอลลาร์ และโตขึ้นแปดเท่าในเวลาเพียงสี่ปี เทียบกับหนี้ที่อยู่บนงบดุลอย่างเป็นทางการซึ่งอยู่ที่ 1.35 ล้านล้านดอลลาร์

ฝั่ง Moody's ให้ตัวเลขดีลนอกงบดุลไว้ที่ 1.2 ล้านล้านดอลลาร์ โดยในจำนวนนั้นราว 820 พันล้านดอลลาร์เป็นดาต้าเซ็นเตอร์ที่ยังก่อสร้างไม่เสร็จ ส่วนการออกหุ้นกู้ของกลุ่มผู้ให้บริการคลาวด์รายใหญ่อยู่ที่ราว 225 พันล้านดอลลาร์ถึงกลางปี 2026 และคาดว่าจะแตะ 400 พันล้านดอลลาร์เมื่อจบปี

บทความยกคำเตือนจากฝั่งตลาดว่า "Market participants are growing leery of quickly rising leverage from issuers previously characterized by strong and reliable cash flow" คือผู้เล่นในตลาดเริ่มระแวงการก่อหนี้ที่พุ่งเร็วของผู้ออกตราสารที่เคยขึ้นชื่อเรื่องกระแสเงินสดแข็งแรงและคาดเดาได้

ข้อควรระวังที่บทความระบุเองและต้องเล่าคู่กันเสมอคือหนี้นอกงบดุลเหล่านี้เป็นวิธีบัญชีที่ถูกกฎหมายและมักเปิดเผยไว้ในเชิงอรรถอยู่แล้ว อีกทั้งส่วนใหญ่จะทยอยกลับมาปรากฏบนงบดุลในภายหลัง และ Moody's เองก็ยืนยันว่ากลุ่มผู้ให้บริการคลาวด์รายใหญ่ยังมีงบดุลแข็งแรงและอันดับความน่าเชื่อถือระดับลงทุนได้ ยังไม่ได้เผชิญความเสี่ยงเฉพาะหน้า ในกระทู้ Hacker News ที่ได้ 110 คะแนน ก็มีคนแย้งว่าตัวเลข 1.65 ล้านล้านอาจไม่ใช่ปัญหาเมื่อเทียบกับกระแสเงินสดอิสระระดับหลายแสนล้านต่อไตรมาสของบริษัทเหล่านี้

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

Fortune · HN

Palantir ประกาศผลไตรมาส 2 ปี 2026 เมื่อ 4 ส.ค. รายได้รวมอยู่ที่ 1,935 ล้านดอลลาร์ เติบโต 93% เทียบปีก่อน และโต 19% จากไตรมาสก่อนหน้า กำไรสุทธิตามมาตรฐานบัญชีอยู่ที่ 1,062 ล้านดอลลาร์

รายได้จากสหรัฐอยู่ที่ 1,573 ล้านดอลลาร์ โต 115% แบ่งเป็นฝั่งเอกชน 764 ล้านดอลลาร์ที่โต 149% และฝั่งหน่วยงานรัฐ 809 ล้านดอลลาร์ที่โต 90% ด้านสัญญาที่ปิดได้ในไตรมาสมีมูลค่ารวม 3,373 ล้านดอลลาร์ โดยเป็นสัญญาระดับ 1 ล้านดอลลาร์ขึ้นไปจำนวน 220 ฉบับ ระดับ 5 ล้านดอลลาร์ 98 ฉบับ และระดับ 10 ล้านดอลลาร์ 73 ฉบับ บริษัทปรับคาดการณ์ทั้งปี 2026 ขึ้นเป็นโต 82% และปรับคาดการณ์ฝั่งลูกค้าเอกชนสหรัฐขึ้นเป็นโต 134%

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

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

Blognone

สำนักข่าว Model Republic เผยแพร่รายงานของ Tyler Johnston ที่เริ่มจากเหตุการณ์เล็กๆ คือมีอีเมลขอสัมภาษณ์จากนักข่าวชื่อ Michael Chen ส่งไปหาที่ปรึกษากฎหมายขององค์กรรณรงค์แห่งหนึ่ง เพื่อขอความเห็นเรื่องร่างกฎหมาย AI ในรัฐเทนเนสซี รายงานสรุปว่า "Michael Chen, it turns out, almost certainly isn't a real reporter. And Acutus, it turns out, almost certainly doesn't have any real reporters at all." คือเกือบแน่นอนว่า Michael Chen ไม่ใช่นักข่าวจริง และเว็บ Acutus แทบจะไม่มีนักข่าวจริงอยู่เลยสักคน

หลักฐานที่รายงานยกมามีสองชั้น ชั้นแรกคือผลจากเครื่องมือตรวจจับข้อความที่ AI เขียน ซึ่งชี้ว่า 69% จากบทความ 94 ชิ้นเป็นงานที่ AI เขียนทั้งหมด อีก 28% เขียนบางส่วน เหลือเพียง 3 ชิ้นที่จัดว่าเป็นงานมนุษย์ ชั้นที่สองซึ่งหนักกว่าคือโครงสร้างภายในของเว็บเอง ที่พบช่องข้อมูลชื่อ AI Background Context และ AI interviewer อยู่ในโค้ด พร้อมร่องรอยว่าขั้นตอนตรวจทานด้วย AI ใช้เวลากลางที่ 44 วินาทีต่อชิ้น และมี 42 เรื่องที่ถูกเผยแพร่ทั้งที่ระบบตีกลับว่าต้องแก้ก่อน ส่วนเส้นเชื่อมทางการเมืองที่รายงานเสนอคือ Acutus โยงไปถึงบริษัทประชาสัมพันธ์แห่งหนึ่งซึ่งมี Targeted Victory เป็นลูกค้า และ Targeted Victory คือบริษัทที่อยู่ใจกลางกลุ่มการเมืองมูลค่า 125 ล้านดอลลาร์ที่ OpenAI หนุนอยู่

ข้อควรระวังมีสามข้อและห้ามข้าม ข้อแรกคือนี่ไม่ใช่ข่าวของวันนี้ หน้าบทความแสดงวันที่ขัดกันเองสองอัน คือ timestamp ระบุ 21 ก.ค. ขณะที่บรรทัด byline เขียนว่า 24 เม.ย. เราตรวจแล้วแก้ไม่ได้ว่าอันไหนถูก ที่แน่ชัดคือมันเพิ่งขึ้น Hacker News เมื่อ 3 ส.ค. และได้ 205 คะแนน ข้อสองคือในกระทู้มีคนแย้งตรงๆ ว่าเครื่องมือตรวจจับข้อความ AI นั้นเชื่อถือไม่ได้ และเส้นเชื่อมไปถึง OpenAI เป็นการคาดเดาที่ไกลเกินหลักฐาน โดยมีคนตอบกลับว่าหลักฐานส่วนโครงสร้างภายในเว็บหนักแน่นกว่าผลจากเครื่องตรวจจับมาก ข้อสามคือรายงานไม่มีคำชี้แจงจากฝ่ายใดเลย ทั้ง OpenAI บริษัทประชาสัมพันธ์ที่ถูกพาดพิง และตัวเว็บ Acutus เอง

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

Model Republic · HN

Bjorn Roche เขียนบทความนี้ตั้งแต่ 12 ก.ค. แต่เพิ่งขึ้น Hacker News เมื่อ 3 ส.ค. และได้ 102 คะแนน ข้อเสนอของเขาคือผลิตภาพที่ AI เพิ่มให้นักพัฒนานั้นอยู่ราว 15% สำหรับวิศวกรอาวุโส และราว 25% สำหรับระดับต้น ซึ่งต่ำกว่าที่คนคาดกันมาก

เหตุผลที่เขาให้คือการเขียนโค้ดเป็นสัดส่วนเล็กของเวลาทำงานจริง เวลาส่วนใหญ่หมดไปกับการออกแบบระบบ การไล่หาบั๊ก การรีวิวโค้ดคนอื่น และการประชุม ซึ่งเป็นส่วนที่ AI ยังช่วยได้ไม่มาก เขาเขียนว่า "Senior engineers in particular spend a lot of time figuring out what code they need to write, and AI hasn't yet made that part any easier." คือวิศวกรอาวุโสใช้เวลาไปมากกับการคิดว่าต้องเขียนโค้ดอะไร และ AI ยังไม่ได้ทำให้ส่วนนั้นง่ายขึ้นเลย ข้อสังเกตจากงานจริงของเขาคือ "Building production features still seems to take almost as long as it used to."

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

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

bjornroche.com · HN