AI News · 2026-07-17

Moonshot ประกาศ Kimi K3: 2.8 ล้านล้านพารามิเตอร์ · active 16 จาก 896 experts · context 1M · ใช้ได้แล้วผ่านเว็บ/API · weights สัญญาว่าจะปล่อยภายใน 27 ก.ค. 2026 · Moonshot เรียกตัวเองว่า first "open 3T-class model" (Willison แซว: ปัด 2.8T ขึ้นเป็น 3T) แต่ ณ วันนี้ Artificial Analysis จัดเป็น proprietary เพราะ weights ยังไม่ออก · independent (AA-Briefcase · knowledge work ระยะยาว): K3 = 1547 Elo อันดับ 2 รอง Fable 5 (1583) เหนือ GPT-5.6 Sol max (1495) และ Opus 4.8 (1354) · กระโดดจาก K2.6 (815) +732 Elo ในรุ่นเดียว · vendor ยอมรับเองว่าภาพรวมยังแพ้ Fable 5/Sol · ราคา $3/$15 ต่อ 1M = เท่า Claude Sonnet ขึ้นจาก K2.6 ($0.95/$4) ราว 3.2-3.75 เท่า

▲ ทำไมต้องรู้ · ข่าวนี้ทุบภาพจำที่ว่าโมเดลจีนต้องถูกกว่าเสมอ เพราะ K3 ตั้งราคาเท่ากับ Claude Sonnet ซึ่งแพงที่สุดเท่าที่ lab จีนเคยตั้งมา แต่ตัวเลขที่งานเปิดตัวไม่ค่อยพูดถึงคือความแม่นยำที่ขึ้นจาก 33% เป็น 46% มาพร้อมกับอัตรา hallucination ที่ขึ้นจาก 39% เป็น 51% ในเวลาเดียวกัน และแม้จะเคลมว่าประหยัด token แต่ AA วัดว่า K3 ตอบยาวกว่าค่าเฉลี่ยถึง 2 เท่า ส่วนตัวเลขต้นทุนต่องานที่เอาไปเทียบกับคู่แข่งอย่าง DeepSeek V4 Pro ก็มาจากคนละ benchmark กับที่วัดความสามารถ จึงเทียบตรงๆ กันไม่ได้ ที่สำคัญคือ weights ยังไม่ปล่อยจริง ต้องรอดูถึงวันที่ 27 ก.ค. ตามที่ Moonshot สัญญาไว้ก่อนจะเรียกโมเดลนี้ว่า "open" ได้เต็มปาก → kimi-k3

Moonshot · Simon Willison · AA-Briefcase · the-decoder

Thinking Machines Lab (Mira Murati อดีต CTO OpenAI) ปล่อย Inkling: MoE 975B total / 41B active (256 routed + 2 shared experts · active 6 routed/token) · Apache 2.0 · input = text/image/audio · output text อย่างเดียว · video เป็นแค่ training data ไม่ใช่ input · context 1M บน weights แต่ Tinker API ของ TML เองจำกัด 256K · เทรนด้วย 45T token (vendor claim ล้วน · เอกสาร Training Data Documentation เองบอกแค่ "trillions") · AA: debut ที่ score 41 บน Intelligence Index = อันดับ 1 ของ US open-weights เหนือ Nemotron 3 Ultra (38), Gemma 4 31B (29), gpt-oss-120b (24) แต่ยังตามโมเดลจีนระดับท็อปในภาพรวม · TML ยอมรับเองว่าไม่ใช่ frontier: "Inkling is not the strongest overall model available today, open or closed" วางตัวเป็น ฐานสำหรับ fine-tune ผ่าน Tinker · Inkling-Small (276B/12B) พรีวิวแล้ว weights รอ

▲ ทำไมต้องรู้ · ตัวเลข 41 ตัวเดียวกันนี้อ่านผิดชั้นเดียวก็เปลี่ยนความหมายไปคนละเรื่อง เพราะ 41 คือคะแนนที่ทำให้ Inkling ขึ้นเป็นผู้นำ US open-weights ไม่ใช่อันดับที่ 41 ซึ่งจะฟังดูเป็นโมเดลกลางๆ ทันที เป็นตัวอย่างที่ดีว่าตัวเลขที่ไม่มีหน่วยกำกับชัดเจนพาคนอ่านเข้าใจผิดได้ง่ายแค่ไหน อีกเรื่องที่ควรรู้คือ Apache 2.0 ไม่ได้แปลว่าเอา weights ไปทำอะไรก็ได้ เพราะมีรายงานว่า Inkling แปะ Model Acceptable Use Policy แยกต่างหากมาด้วย ทีมกฎหมายหรือฝ่ายจัดซื้อจึงควรอ่าน license ตัวจริงก่อนนำไปใช้งาน ไม่ใช่ดูแค่ชื่อ license บนหน้าประกาศ ส่วนเอกสารอธิบายที่มาของข้อมูลฝึกก็สั้นผิดปกติ บอกเพียงว่าใช้ "เนื้อหาสาธารณะและเนื้อหาที่อาจมีลิขสิทธิ์" ซึ่งตอบคำถามเรื่อง audit ไม่ได้เลย → inkling-thinking-machines

Thinking Machines · Simon Willison · AA · Blognone (ไทย)

คอนซอร์เชียมที่ประสานโดย KI Bundesverband (Fraunhofer, DFKI, TU Darmstadt + Ellamind, Merantix Momentum) ปล่อย Soofi S: hybrid Mamba-Transformer · 31.6B total / active ~3.2B ต่อ token · เทรน ~27T token สามเฟส · ภาษาเยอรมันคิดเป็น 7.2-15.3% ของ data mix (web/code/math + ข้อมูลหนังสือพิมพ์ที่ซื้อ license) · คะแนน 70.1 (อังกฤษรวม) / 79.1 (เยอรมันรวม) ชนะ OLMo 3 32B และ Apertus 70B · ผ่านเกณฑ์ Open Source AI Definition 1.0 แต่ ~1.3% ของ training data ติดข้อจำกัดเชิงพาณิชย์

▲ ทำไมต้องรู้ · นี่คือคำตอบที่จับต้องได้สำหรับคำถามที่หลายคนสงสัยว่าประเทศขนาดกลางจะมีโมเดลภาษาตัวเองได้ไหม เคสเยอรมันแสดงให้เห็นว่ารัฐ สถาบันวิจัย และเอกชนร่วมมือกันได้จริง โดยใช้โมเดลขนาดไม่ใหญ่มาก (31.6B) และใส่ภาษาเป้าหมายเข้าไปในข้อมูลฝึกเพียง 7 ถึง 15 เปอร์เซ็นต์ก็ยังชนะ benchmark เฉพาะทางภาษาตัวเองได้ สถาปัตยกรรมแบบ hybrid Mamba-Transformer ก็เริ่มปรากฏในโมเดลใช้งานจริงแล้ว ไม่ใช่แค่ในเปเปอร์ ข้อควรระวังคือยังมีข้อมูลฝึกราว 1.3% ที่ติดเงื่อนไขเชิงพาณิชย์อยู่ แม้จะเคลมว่าเป็น open source และตัวเลข benchmark ทั้งหมดยังเป็นตัวเลขที่คอนซอร์เชียมรายงานเอง รอการตรวจสอบอิสระ

the-decoder · HN 116 pts

Researcher cereblab ใช้ mitmproxy + canary file จับได้ว่า Grok Build อัป tracked git repo ทั้งก้อนพร้อม git history เป็น bundle ขึ้น bucket grok-code-session-traces โดยไม่ขึ้นกับว่า model อ่านไฟล์ไหน · เลขที่ฟ้องตัวเอง: repo 12 GB · model channel 192 KB แต่ storage channel 5.10 GiB = ~27,800 เท่า · privacy toggle เป็นแค่ retention setting ไม่ได้บล็อกการส่ง (บริษัทเองใช้คำว่า "disabled default retention" ซึ่งคนละเรื่องกับหยุดส่ง) · ปิดฟีเจอร์แล้วจริง (server-side flag + v0.2.93 หยุดยิง storage request) · ~3 วันต่อมา open-source ทั้ง codebase xai-org/grok-build Apache-2.0 Rust 99.6% · ในโค้ดที่เปิดออกมา: subagent prompt ห้ามเปิดเผย system prompt แต่ main prompt ไม่ห้าม · tool ยืมจาก openai/codex (apply_patch, grep_files, list_dir, read_file) และ sst/opencode (bash, edit, glob, grep, read, skill, todowrite, write) · ซากระบบอัปโหลดยังอยู่: upload/gcs.rs (มี SESSION_TRACES_BUCKET ตรงกับที่ cereblab จับได้) + upload/trace.rs ที่ upload_session_state() return error ตายตัว

▲ ทำไมต้องรู้ · เคสนี้ต่างจากช่องโหว่ security ที่เคยเจอมา เพราะไม่มีผู้โจมตีคนไหนเกี่ยวข้องเลย ตัวเครื่องมือเองส่งข้อมูลออกโดยดีไซน์ บทเรียนที่คมที่สุดคือข้อมูลที่ agent ส่งออกไปไม่จำเป็นต้องเท่ากับข้อมูลที่ agent ใช้ทำงานจริง เพราะโมเดลใช้ข้อมูลแค่ 192 KB ในการทำงาน แต่ระบบกลับอัปโหลด repo ทั้งก้อนออกไปถึง 5.10 GiB คำถามที่ทุกองค์กรควรถามกับเครื่องมือ AI ทุกตัวคือมันส่งอะไรออกไปบ้าง และตรวจสอบเองได้ไหม วิธีที่ทีม security ตรวจสอบได้เองโดยไม่ต้องเชื่อคำแถลงของ vendor คือใช้ mitmproxy ควบคู่กับ canary file ส่วนคำยืนยันของบริษัทว่าลบข้อมูลที่อัปโหลดไปแล้วทั้งหมด ยังไม่มีใครยืนยันได้อย่างอิสระ

The Register (14 ก.ค.) · The Register (16 ก.ค.) · cereblab · The Hacker News · Simon Willison

Willison ยกคำอธิบายของ Thibault Sottiaux เรื่องรายงานที่ GPT-5.6 ลบไฟล์ผู้ใช้โดยไม่ตั้งใจ · เงื่อนไขที่ระบุ: เปิด full access mode + รัน codex แบบไม่มี sandbox (รวมถึงไม่มี auto review) · กลไก: โมเดลพยายาม override $HOME เพื่อกำหนด temp directory แล้ว "makes an honest mistake and mistakenly deletes $HOME instead"

▲ ทำไมต้องรู้ · เคสนี้ตอกย้ำหลักสำคัญข้อหนึ่งของการใช้ AI agent คือ sandbox และ permission ไม่ใช่พิธีกรรมที่ทำตามขั้นตอน แต่เป็นสิ่งเดียวที่กั้นระหว่างโมเดลทำพลาดกับข้อมูลหายจริง เหตุเกิดขึ้นตอนเปิดโหมด full access และรันโดยไม่มี sandbox โมเดลพยายามกำหนด temp directory ใหม่แล้วลบ $HOME ของผู้ใช้ไปโดยไม่ตั้งใจ เรื่องนี้เกิดขึ้นในสัปดาห์เดียวกับที่ Claude Code ต้องแก้บั๊กที่ auto mode เคย override permission hook สำหรับคำสั่งที่ไม่มี sandbox เช่นกัน ชี้ให้เห็นว่าการรันโดยไม่มี sandbox คือความเสี่ยงที่เกิดได้กับทุกเจ้า และเจตนาที่ดีของโมเดลไม่ใช่ตัวป้องกันความปลอดภัยที่เชื่อถือได้

Simon Willison

Release note ระบุว่า mid-conversation system messages ใช้ได้แล้วบน Claude Fable 5, Claude Mythos 5, Claude Opus 4.8 ทั้งบน Claude API, Amazon Bedrock และ Google Cloud (Vertex AI) · ไม่ต้องใช้ beta header · หมายเหตุระบุตรงว่าเป็น การแก้ไขประกาศ availability ก่อนหน้า

▲ ทำไมต้องรู้ · ฟีเจอร์นี้ดูเล็กแต่มีประโยชน์จริงกับใครที่ควบคุม AI agent ระหว่างทำงาน เพราะแทรกคำสั่งระดับ system กลางบทสนทนาได้โดยไม่ต้องเริ่มการสนทนาใหม่ ใช้ทำ guardrail แบบไดนามิกหรือเปลี่ยนโหมดกลางงานได้ และครอบคลุมทั้ง Amazon Bedrock และ Google Cloud Vertex AI ด้วย ไม่ใช่แค่ API ตรงของ Anthropic จุดที่น่าสนใจอีกอย่างคือ release note เขียนเองว่านี่คือการแก้ไขข้อมูล availability ที่เคยประกาศผิดไว้ก่อนหน้า ย้ำให้เห็นว่าแม้แต่เอกสารของ vendor เองก็อาจมีข้อมูลที่ล้าสมัยหรือผิดพลาดได้ ควรเช็ค availability จริงก่อนนำไปใช้งานเสมอ

Anthropic API release notes

LM Studio ปล่อย Bionic: แอป agent ที่ทำงาน coding/research/งานเอกสาร โดยรันโมเดลได้ ในเครื่องเอง หรือผ่าน LM Studio Secure Cloud · มี transcribe เสียงแบบ offline ด้วย Voxtral ของ Mistral · ตรวจโปรเจกต์โค้ดพร้อม inline diff · โมเดลที่ระบุชื่อมีแค่ GLM 5.2 และ Kimi K2.7 Code · ฝั่ง cloud เคลม Zero Data Retention และไม่เทรนบนข้อมูลผู้ใช้

▲ ทำไมต้องรู้ · Bionic ตอบคำถามที่หลายองค์กรถามบ่อยว่ามีทางใช้ AI agent โดยที่ข้อมูลไม่ต้องออกจากองค์กรไหม เพราะวางตำแหน่งเป็น local-first รันในเครื่องเองได้หรือผ่าน Secure Cloud ของตัวเอง พร้อม transcribe เสียงแบบ offline แต่ควรอ่านคู่กับข่าว Grok Build ก่อนหน้านี้ให้ดี เพราะการเคลมว่า Zero Data Retention เป็นเพียงคำพูดของ vendor เคส Grok Build เพิ่งพิสูจน์ให้เห็นว่า toggle ที่เขียนว่าเกี่ยวกับ privacy อาจคุมแค่ระยะเวลาเก็บข้อมูล ไม่ได้คุมว่าข้อมูลถูกส่งออกไปหรือไม่ วิธีที่เชื่อถือได้กว่าคือตรวจสอบเองด้วยเครื่องมืออย่าง mitmproxy และ canary file แทนที่จะเชื่อคำโฆษณา ทั้งนี้โพสต์เปิดตัวยังไม่มีเลขเวอร์ชัน ราคา หรือ benchmark ให้ตรวจสอบเลย

LM Studio · HN 122 pts

เปเปอร์ที่ upvote นำอันดับ 2 เกือบเท่าตัว · แกน: ความสามารถของ agent ไม่ได้ขึ้นกับโมเดลอย่างเดียว แต่ขึ้นกับ harness (โค้ดที่ประกอบ prompt, จัดการ state, เรียก tool, คุม execution) ซึ่งต้องแก้ตลอดเวลาเมื่อโมเดล/API/ความต้องการเปลี่ยน · คอขวดจริงไม่ใช่การ generate edit แต่คือ behavior localization: หาให้เจอว่าพฤติกรรมที่ต้องการอยู่ในโค้ดจุดไหนบ้าง · เพราะ harness จริงใหญ่ ผูกกันแน่น และพฤติกรรมกระจายอยู่หลายที่ ขณะที่คำสั่งแก้มาในรูป "ระบบควรทำอะไร" แต่ repo จัดตามไฟล์/โมดูล · ทางแก้: representation ที่ยึดพฤติกรรมเป็นแกน สังเคราะห์อัตโนมัติจาก codebase (static analysis + LLM) โยงพฤติกรรมกับ source + Behavior-Guided Progressive Disclosure ที่พา agent ไล่จากพฤติกรรมระดับสูงลงไปหา implementation · ผล: localization และคุณภาพแผนแก้ดีขึ้น โดยใช้ token ของ planner น้อยลง เด่นสุดตรงจุดที่กระจายหลายที่ · path ที่แทบไม่เคยรัน · และ interaction ข้ามโมดูล

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

arXiv 2607.13285

การทดลองกับ ผู้เข้าร่วม 3,132 คน พบว่าการมี AI ให้คำแนะนำ "nearly eliminated participants' willingness to suspend judgment" (แทบลบความเต็มใจที่จะบอกว่า "ไม่รู้/ขอไม่ตัดสิน") · เกิดขึ้นแม้คำแนะนำจะผิด และแม้จะให้แรงจูงใจตอบแม่นยำ

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

arXiv 2607.13562

สี่งานที่มาพร้อมกัน: OAT ทำ failure attribution แบบ unsupervised เทรนจาก trajectory ที่สำเร็จเท่านั้น (100 เส้น) แล้วชี้ step ที่ผิดใน trajectory ที่พังได้ ด้วย one-class learning + neural CDE จับ "พลวัตของความสำเร็จ" แล้วให้คะแนน anomaly ตามระยะเบี่ยง · เร็วกว่า prompting baseline 200-5000 เท่า และแม่นกว่า (+20% F1 in-domain · +7% OOD) · STRACE หา root cause ด้วย causal localization บน dependency graph ดัน success rate 42.5% → 58.5% · AgentCompass เป็น infra eval แยก Benchmark/Harness/Environment ออกจากกัน (20+ benchmark) · DevicesWorld (6,140 task) พบ agent ระดับ frontier ทำงานข้ามอุปกรณ์ได้แค่ 12.5%

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

OAT 2607.12747 · STRACE 2607.07702 · AgentCompass 2607.13705 · DevicesWorld 2607.13465

โมเดลตระกูล open (Base/Turbo/Edit/Edit-Turbo) ทำทั้งความเข้าใจภาพและ generate: text-to-image, แก้ภาพตามคำสั่ง, เรนเดอร์ตัวอักษรจีน-อังกฤษ · ข้อโต้แย้งหลักเป็นเชิงเศรษฐศาสตร์: ระบบปิดอย่าง Nano-Banana-Pro/GPT-Image-2 ชนะด้วย system-level integration ที่ไม่เปิดเผย ไม่ใช่โมเดลเดี่ยวที่เหนือกว่า · เคลมว่าการปรับปรุงที่ตรงจุด (ความเข้าใจ, คุณภาพ data, pipeline) + agentic inference-time scaling ปิดช่องว่างได้มากด้วยงบจำกัด · เลขพาดหัว: ภาพ unique 208.62 ล้านภาพ · ต้นทุนเทรน base model เชิงทฤษฎี ~$400K · ปล่อย weights/code/recipe Apache 2.0

▲ ทำไมต้องรู้ · ตัวเลขงบประมาณราว $400,000 ที่เคลมว่าใช้เทรน base model ตัวนี้เป็นตัวเลขที่ทำให้หลายคนสะดุด เพราะความสามารถระดับที่เมื่อสองปีก่อนต้องใช้เงินระดับร้อยล้าน วันนี้เคลมว่าทำได้ด้วยงบที่บริษัทขนาดกลางพอจ่ายไหว ประเด็นที่ลึกกว่าตัวเลขคือเปเปอร์นี้ชี้ว่าช่องว่างระหว่างโมเดลปิดกับโมเดลเปิดจริงๆ อยู่ที่การผสานระบบในระดับ system ไม่ใช่ตัวโมเดลเดี่ยวๆ พูดง่ายๆ คือคุณค่าไม่ได้อยู่ที่ตัวโมเดลอย่างเดียว แต่อยู่ที่ระบบทั้งหมดที่ล้อมรอบโมเดลด้วย ทั้งนี้ตัวเลข $400,000 เป็นต้นทุนเชิงทฤษฎีของ base model เท่านั้น ไม่ใช่ค่าใช้จ่ายจริงทั้งโครงการ และตัวเลขทั้งหมดเป็นข้อมูลที่ผู้พัฒนารายงานเอง ยังรอการตรวจสอบอิสระ

arXiv 2607.13125

บทความ Fortune (เผยแพร่ครั้งแรก 3 ก.ค. · เพิ่งพุ่ง HN 288 คะแนน) โดย David Siegel ผู้ร่วมก่อตั้ง Two Sigma (และผู้ก่อตั้ง Open Athena) · กรอบข้อโต้แย้ง: การต่อสู้เรื่อง AI วันนี้คือภาคต่อของการถกเถียงกับ Richard Stallman สมัยยุค 80 · "AI is software, and AI is increasingly closed" · ข้อเสนอรูปธรรม: ทุน compute สาธารณะสำหรับงานวิจัยเปิด · ให้บริษัท/มูลนิธิสนับสนุนมหาวิทยาลัยและองค์กรไม่แสวงกำไร · และกฎว่า "AI ที่สร้างด้วยเงินภาษี ต้องเปิดโดยปริยาย" · แยกให้เห็น "โค้ดที่รันมัน" กับ "โค้ดที่สร้างมัน" โดยเถียงว่า ความโปร่งใสของ training data สำคัญกว่าการเปิดให้รัน · อ้าง GCC และ GNU/Linux เป็นหลักฐานว่าโมเดลนี้ได้ผล · ไม่มีตัวเลขงบประมาณ

▲ ทำไมต้องรู้ · ข่าววันนี้ประกบกันได้พอดี เพราะทั้ง Inkling ที่แปะ Apache 2.0 แต่มี Acceptable Use Policy แยกต่างหาก และ Soofi S ที่เคลม open source ทั้งที่ 1.3% ของข้อมูลฝึกยังติดเงื่อนไขเชิงพาณิชย์ ล้วนเป็นตัวอย่างสดของสิ่งที่ Siegel เถียงพอดี นั่นคือคำว่าเปิด weights ไม่เท่ากับเปิดจริง และจุดที่ทึบที่สุดมักอยู่ที่ข้อมูลฝึก ข้อสรุปที่นำไปใช้ได้จริงคือคำว่า open ในโลก AI ยังไม่มีความหมายเดียว มีอย่างน้อยสามเฉดคือเปิด weights เปิด license จริง และเปิดข้อมูลฝึก ใครที่ต้องเลือกเครื่องมือ AI มาใช้งานควรถามให้ชัดว่าเปิดในความหมายไหน ไม่ใช่เห็นคำว่า open แล้วสบายใจไปเลย ทั้งนี้บทความนี้เป็นความเห็นของผู้มีส่วนได้เสียในสายนี้เอง ควรใช้เป็นกรอบคิดมากกว่าข้อสรุปสำเร็จรูป

Fortune (via Siegel Endowment) · HN 288 pts

Linus Torvalds · Mass-Driver