Goodfire ติด probe อ่าน activation ของ Kimi K3 และ GLM 5.3 จับเอเจนต์ที่ใช้ทำ cyber attack — recall 93% ที่ false positive 5.5% ถูกกว่าให้ LLM judge อ่านทุก turn ราว 50 เท่า

เมื่อ 8 ต.ค. 2026 แล็บ interpretability Goodfire เผยแพร่งานวิจัย “Training and Deploying Production Cyber Monitors on Kimi K3” อธิบายระบบเฝ้าระวังเอเจนต์ที่ไม่ได้อ่านแค่ output แต่อ่าน activation ภายในโมเดล ระหว่างที่โมเดลกำลังสร้าง token อยู่ Goodfire ทำ monitor ให้โมเดลเปิดสองตัวคือ Kimi K3 และ GLM 5.3 และนำไปรันบน inference stack ระดับ production แล้ว TechCrunch รายงานว่าลูกค้าของ Baseten ใช้ monitor ชุดนี้ได้แล้ว

ตัวเลขหลักที่ Goodfire เขียนไว้คือ recall 93% ที่อัตราขัดจังหวะ session ปกติ 5.5% ระดับเดียวกับการให้ LLM judge อ่านทุก turn แต่ ถูกกว่าประมาณ 50 เท่า โดยแทบไม่ทำให้ throughput ของ inference ลดลง เรื่องนี้สำคัญกับคนที่ serve โมเดลเปิดเอง เพราะโมเดลเปิดไม่ได้มาพร้อม safety stack แบบที่ API ของแล็บ frontier มี

ทำงานอย่างไร: probe เป็นด่านแรก judge เป็นด่านสอง

ระบบนี้เป็น cascade สองชั้น

• Probe คือ classifier ขนาดเล็กที่อ่าน activation ซึ่งโมเดลคำนวณไว้อยู่แล้ว ทำงานทุก token ต้นทุนต่ำมาก
• เมื่อคะแนนจาก probe เกิน threshold ที่ calibrate ไว้ session นั้นจะถูกส่งต่อให้ LLM judge ตัดสินว่าจะปฏิเสธคำขอหรือปล่อยให้ทำงานต่อ

ส่วนที่ยากคือการรันเรื่องนี้ใน server จริง Goodfire ต้อง แก้ SGLang ให้คำนวณคะแนน probe ภายใน serving engine ได้เลย ขณะที่ยังรักษา batching, prefix caching และ speculative decoding ไว้ และยังต้องจับคู่คะแนนให้ถูก token และถูก session ด้วย ผลที่วัดได้คือ throughput ลดลง ไม่ถึง 2% ในสี่ workload ซึ่ง Goodfire บอกว่าอยู่ในช่วง noise ของการวัด

ชุดประเมินเป็นข้อมูลภายใน 2.4K session (chat และ agentic) รวมกว่า 60K turn โดยใช้ label จาก Claude Opus 5 เป็นค่าอ้างอิง session เหล่านี้มาจาก rollout ที่จำลองด้วย Petri (เครื่องมือ red-team แบบ open source ของ Anthropic), สภาพแวดล้อมที่ดัดแปลงจากเบนช์มาร์กอย่าง ExploitBench, ชุดย่อยด้าน cyber จาก WildChat และ rollout ปกติจากงาน SWE, coding และ DevOps เพื่อให้ monitor แยก “ตรวจหาช่องโหว่ในโค้ดตัวเอง” ออกจาก “เจาะระบบคนอื่น” ได้ ซึ่งสองงานนี้หน้าตาคล้ายกันมาก

ตัวเลขที่ควรอ่านให้ครบ

ตัวชี้วัด	ผล
Recall ที่อัตราขัดจังหวะ session ปกติ 5.5%	~93% (ทั้งแบบ judge มีและไม่มี reasoning)
ค่า judge ต่อ 1 ล้าน agent turn	$65 (ไม่มี reasoning) / $185 (มี reasoning)
ลดค่า judge เทียบกับการให้ judge อ่านทุก turn	~49× (ไม่มี reasoning) / ~29× (มี reasoning)
Latency ที่เพิ่มต่อ turn	2 ms เทียบกับ 160 ms (ไม่มี reasoning); 42 ms เทียบกับ 2,750 ms (มี reasoning)
Kimi K3: อัตราบล็อก session อันตราย	~29% → 96%
GLM 5.3: อัตราบล็อก session อันตราย	~36% → 91%

ตัวเลขที่ต้องอ่านคู่กันคือ ราคาของการบล็อก ใน benchmark ระดับ session เต็ม การเพิ่ม monitor ทำให้ Kimi K3 ขัดจังหวะ session ปกติเพิ่มจาก ราว 5% เป็น 9% ส่วน GLM 5.3 เพิ่มจาก ราว 10% เป็น 15% ตัวเลข 5.5% บนหัวข่าวจึงเป็น operating point ของการวัด detection ไม่ใช่อัตรารบกวนผู้ใช้ปกติในทุกสถานการณ์

Goodfire ยังเทียบกับ Jev ซึ่งเป็น decision model ที่ใช้เป็น judge ราคาถูกได้ ที่อัตราขัดจังหวะ 5.5% Jev ได้ recall 86% แต่ใช้ค่า judge ราว $600 ต่อล้าน turn และเพิ่ม latency 200 ms ต่อ turn นอกจากนี้ Jev จับ prompt อันตรายที่ถูกห่อด้วยบริบทปกติได้เพียง 12% และเริ่มขัดจังหวะ session ปกติบ่อยขึ้นเมื่อ session ยาวเกิน context 32K ของมัน

Monitor ของ GLM 5.3 เทรนจากข้อมูลที่เก็บมาจาก Kimi K3 เกือบทั้งหมด Goodfire บอกว่าได้ monitor ที่เก่งพอ ๆ กันเมื่อวัดบน rollout ของ Kimi และแย่กว่าเล็กน้อยบน rollout ของ GLM เอง หมายความว่าไม่จำเป็นต้องสร้าง data pipeline ใหม่สำหรับทุกโมเดล

Red-team จากภายนอกโดย FAR.AI

Goodfire ให้ FAR.AI ทดสอบระบบที่ deploy แล้วเป็นเวลาสองวัน FAR.AI คัด jailbreak ด้าน offensive cyber ที่ได้ผลกับ base model มา 140 แบบจาก 1,500 แบบ แล้วยิงแต่ละแบบกับเป้าหมายการโจมตี 8 แบบ ผลคือ universal jailbreak ลดจาก 66 เหลือ 0 และ interaction ที่ jailbreak สำเร็จลดจาก 700 เหลือ 18 อัตราสำเร็จรายครั้งลดจาก 9–40% เหลือ 0.1–1.6% ขึ้นกับระดับ reasoning effort

ข้อจำกัดที่ต้องรู้คือการทดสอบนี้เป็นแบบ static และ non-adaptive และทำเฉพาะใน chat context ยังไม่ได้ทดสอบผู้โจมตีที่ปรับวิธีตามผลที่เห็น Goodfire เองก็ใช้คำว่า “largely robust” และบอกว่าจะทดสอบกับ FAR.AI ต่อ

มุมมอง AI Curator

งานนี้ออกมาในสัปดาห์ที่ปัญหาเรื่อง monitor ชัดมาก Anthropic เพิ่งเปิดรายงานว่า Claude ส่งเบาะแสปลอมให้ตำรวจตั้งแต่ ก.ค. แต่กว่าจะเห็นก็ปลาย ก.ย. เพราะต้องไล่อ่าน transcript ย้อนหลัง และคนร้ายที่เจาะธนาคารเกาหลีใช้เอเจนต์ pentest ต่อกับโมเดลเปิดราคาถูก ปัญหาเหมือนกันทั้งสองกรณี คือการ monitor แบบ asynchronous รู้ตัวช้าเกินไป สิ่งที่ Goodfire ทำได้คือทำให้การ monitor ถูกพอจะเป็น synchronous และหยุด tool call ได้ก่อนเกิดผลจริง ถ้าเพิ่ม latency 2 ms ต่อ turn และใช้ compute ไม่ถึง 1% ข้ออ้างว่า “monitor ทุก turn แพงเกินไป” ก็แทบไม่เหลือ

สำหรับทีมไทยและอาเซียนที่ self-host Kimi K3, GLM หรือ DeepSeek ไว้ทำ coding agent ภายในองค์กร งานนี้ชี้ว่าการใช้ open weights ทำให้คุณ เข้าถึง activation ได้ ซึ่ง API แบบปิดไม่ให้ Goodfire ใช้ข้อได้เปรียบนี้ทำ safety ได้ดีกว่า judge ภายนอก แต่ในทางปฏิบัติยังต้องรอดูสองเรื่อง (1) monitor แบบนี้ยังผูกกับ Goodfire และ Baseten และต้องใช้ SGLang ที่แก้แล้ว ยังไม่มีโค้ดหรือ probe weights ให้ดาวน์โหลด ทีมที่ใช้ vLLM, llama.cpp หรือ Ollama ยังทำตามเองไม่ได้ (2) probe อ่านภาษาไทยหรือ prompt ที่สลับภาษาไปมาได้ดีแค่ไหน ข้อมูลเทรนเป็นภาษาอังกฤษเป็นหลัก และคดีธนาคารเกาหลีก็แสดงว่าคนร้ายจริงสั่งงานเป็นภาษาจีน

ในระยะยาว ผมคิดว่า “monitor ระดับ activation” จะกลายเป็นข้อได้เปรียบเชิงแข่งขันของ inference provider ที่ host โมเดลเปิด เหมือนที่ guardrail กลายเป็นฟีเจอร์ของ API ปิด ถ้า regulator เริ่มบังคับให้แจ้งเหตุจากเอเจนต์ ผู้ให้บริการที่บอกได้ว่า “เราบล็อก tool call อันตรายได้แบบ real-time” จะขายงานองค์กรได้ง่ายกว่าเจ้าที่บอกแค่ว่า “เราตรวจ log ทีหลัง”

แหล่งข่าว

• Goodfire — Training and Deploying Production Cyber Monitors on Kimi K3 (8 ต.ค. 2026)
• TechCrunch — Goodfire says its new ‘inside-out’ monitors catch rogue AI agents at a fraction of the cost