ข้ามไปยังเนื้อหา
Enterprise AI Thailand

ข่าวเผยแพร่โดย Enterprise AI Thailand

Anthropic เผยผลพิสูจน์โค้ด

ประเด็นสำคัญ

ก่อนรับโค้ดที่มี formal proof ต้องจับคู่หลักฐานกับไบนารี ข้อกำหนด และสภาพแวดล้อมที่พิสูจน์ การตรวจระบบจริงยังต้องครอบคลุมสิ่งที่อยู่นอกขอบเขตนั้น

ข่าววันที่
ตรวจทานล่าสุด
เวลาอ่าน
ประมาณ 3 นาที
ภาพวาดวงกลมและจุดสีเขียวกับสีแดงเชื่อมด้วยเส้น
ภาพประกอบแนวคิดจากงานวิจัย Anthropic ไม่ใช่หน้าจอผลตรวจ proofภาพ: Anthropicแหล่งที่มาของภาพ

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 หรือเงื่อนไขเปลี่ยน ให้เจ้าของการรับมอบตัดสินว่าต้องสร้างหรือตรวจหลักฐานใหม่ส่วนใด
ใครควรอนุมัติการใช้ผลพิสูจน์ในองค์กร
ให้เจ้าของบริการ ผู้ดูแลความปลอดภัย และผู้เข้าใจข้อกำหนดร่วมกันระบุสิ่งที่หลักฐานครอบคลุม พร้อมชื่อผู้รับความเสี่ยงของส่วนที่เหลือ

วิดีโอที่เกี่ยวข้อง

แหล่งข้อมูล

  1. LLMs are making formal software verification feasible at a much larger scale

    Anthropic

    เผยแพร่ต้นทาง
    เข้าถึงข้อมูล
  2. Theorem research: LLMs are making formal software verification feasible at a much larger scale

    Theorem

    เผยแพร่ต้นทาง
    เข้าถึงข้อมูล
  3. Bootstrapping the Verified Software Stack

    Theorem

    เผยแพร่ต้นทาง
    เข้าถึงข้อมูล