ข่าวเผยแพร่โดย Enterprise AI Thailand
Anthropic เผยผลพิสูจน์โค้ด
ประเด็นสำคัญ
ก่อนรับโค้ดที่มี formal proof ต้องจับคู่หลักฐานกับไบนารี ข้อกำหนด และสภาพแวดล้อมที่พิสูจน์ การตรวจระบบจริงยังต้องครอบคลุมสิ่งที่อยู่นอกขอบเขตนั้น
- ข่าววันที่
- ตรวจทานล่าสุด
- เวลาอ่าน
- ประมาณ 3 นาที

Anthropic พิสูจน์อะไรในงานนี้
Anthropic และ Theorem เผยงานใช้ Claude สร้าง formal proof วันที่ 22 ตุลาคม 2026 ครอบคลุม 239 จุดเข้าของโปรแกรมใน 123 ไลบรารี OSS-Fuzz ตาม รายงานวิจัย ขณะที่ Theorem ยืนยันวันเผยแพร่งานร่วมกัน
ขอบเขตคือไบนารี RISC-V แบบ static ที่ทำงานเธรดเดียว บนแบบจำลอง Linux ด้วยหน่วยความจำที่กำหนดและข้อมูลเข้าต่ำกว่า 64 MB หลักฐานผ่านตัวตรวจ Rocq แต่ยังพึ่งข้อกำหนดและแบบจำลองที่ใช้ คำว่า verified จึงต้องอ่านพร้อมเงื่อนไขเหล่านี้
ก่อนรับมอบต้องผูกหลักฐานกับอะไร
ข้อเสนอสำหรับฝ่ายจัดซื้อและ security คือขอหลักฐานเป็นชุดที่ตรวจย้อนกลับถึงสิ่งที่จะติดตั้งได้ ตัวอย่างเช่น หากผู้ส่งมอบพิสูจน์ตัวอ่านไฟล์ฉบับหนึ่ง แต่ระบบจริงเปลี่ยนตัวคอมไพล์หรือใช้ไบนารีอีกชุด ผู้รับมอบต้องรู้ว่าความต่างนั้นได้รับการประเมินอย่างไร
| รายการรับมอบ | หลักฐานที่ควรเก็บ | คำถามเมื่อมีการเปลี่ยนแปลง |
|---|---|---|
| ไบนารีที่จะติดตั้ง | hash และวิธีสร้าง artifact | ตรงกับตัวที่ตรวจหลักฐานหรือไม่ |
| ข้อกำหนดที่พิสูจน์ | theorem และข้อยกเว้นที่อ่านได้ | ครอบคลุมความเสียหายที่องค์กรกังวลหรือยัง |
| สภาพแวดล้อม | CPU ระบบปฏิบัติการ และข้อจำกัดทรัพยากร | ระบบปลายทางต่างจากสมมติฐานตรงไหน |
| ผลตรวจหลักฐาน | รุ่นตัวตรวจและผลการตรวจซ้ำ | ใครตรวจได้โดยไม่พึ่งคำบอกของผู้ส่งมอบ |
| ส่วนที่ยังต้องทดสอบ | ชุดตรวจการเชื่อมต่อและพฤติกรรมงานจริง | ใครอนุมัติความเสี่ยงที่เหลือ |
ตารางนี้เป็นเกณฑ์รับมอบที่เสนอ ไม่ใช่รายการที่งานวิจัยรับรองให้ทุกระบบ องค์กรควรเลือกจุดเริ่มจากส่วนที่มีข้อกำหนดชัดและความเสียหายที่วัดได้ เช่น การอ่านข้อมูลเข้าก่อนส่งต่อบริการอื่น
ให้การเปลี่ยนรุ่นเปิดการพิจารณาใหม่
แนวทาง verified software stack ของ Theorem เป็นบริบทก่อนหน้าเรื่องการนำหลักฐานของส่วนประกอบกลับมาใช้ ทีมองค์กรนำแนวคิดนี้มาจัดเจ้าของหลักฐานได้ แต่ต้องบันทึกความสัมพันธ์ระหว่างส่วนประกอบกับระบบที่ใช้จริงด้วย
กำหนดผู้รับผิดชอบเมื่อมี patch รุ่นใหม่ รวมถึงกรณีที่แก้ปัญหาเฉพาะหน้าแล้วต้องย้อนกลับรุ่นเดิม เก็บคำตัดสินเรื่องขอบเขต proof แยกจากผลทดสอบใช้งาน เพื่อให้ตรวจได้ว่าทั้งสองอย่างตอบความเสี่ยงใด
วิดีโอของ Claude เดือนกันยายนอธิบายบริบทความปลอดภัยองค์กร ไม่ใช่การสาธิต formal verification ใช้รายการรับมอบข้างต้นประกอบการออกแบบ security และ governance ของระบบ AI ก่อนนำคำรับรองไปใช้ในข้อกำหนดโครงการ
คำถามที่พบบ่อย
- formal proof ใช้รับรองแพ็กเกจที่อัปเดตแล้วได้ทันทีหรือไม่
- ต้องตรวจว่าหลักฐานผูกกับไบนารีและข้อกำหนดฉบับใด เมื่อ artifact หรือเงื่อนไขเปลี่ยน ให้เจ้าของการรับมอบตัดสินว่าต้องสร้างหรือตรวจหลักฐานใหม่ส่วนใด
- ใครควรอนุมัติการใช้ผลพิสูจน์ในองค์กร
- ให้เจ้าของบริการ ผู้ดูแลความปลอดภัย และผู้เข้าใจข้อกำหนดร่วมกันระบุสิ่งที่หลักฐานครอบคลุม พร้อมชื่อผู้รับความเสี่ยงของส่วนที่เหลือ
วิดีโอที่เกี่ยวข้อง
Building Enterprise Frontier Safeguards with our customers
Claude · เผยแพร่
วิดีโอประกอบความเข้าใจ
ดูวิดีโอต้นทางบน YouTube
แหล่งข้อมูล
- LLMs are making formal software verification feasible at a much larger scale
Anthropic
- เผยแพร่ต้นทาง
- เข้าถึงข้อมูล
- Theorem research: LLMs are making formal software verification feasible at a much larger scale
Theorem
- เผยแพร่ต้นทาง
- เข้าถึงข้อมูล
- Bootstrapping the Verified Software Stack
Theorem
- เผยแพร่ต้นทาง
- เข้าถึงข้อมูล