Leanstral 1.5: coding model ที่วัดด้วย proof ไม่ใช่แค่ pass@1

ของชิ้นนี้อาจเหมาะมากกับงานหนึ่งและผิดที่อย่างชัดเจนกับอีกงานหนึ่ง Mistral เปิด Leanstral 1.5 สำหรับงาน formal reasoning และ proof-oriented coding จุดที่ต้องระวังคือ ข้อดีของ proof คือ verifier ตัดสินได้ชัด แต่ไม่ได้ครอบคลุม requirement ที่เขียนคลุมเครือ

จุดนี้ควรเริ่มจากการลองในขอบเขตเล็ก ไม่ใช่การถก Leanstral 1.5 แบบนามธรรม

การลอง “Leanstral 1.5” ควรมีเวลาเริ่ม–จบ เก็บสภาพเดิมไว้เทียบ และเขียนทางถอยก่อนลงมือ ขอบเขตแบบนี้ช่วยให้ตอบได้ว่าผลที่เห็นมาจากสิ่งที่เปลี่ยนจริง

หลักฐานสำหรับ Leanstral 1.5 ควรมี prompt, expected output, latency, RAM หรือ VRAM และ failure ที่เกิดซ้ำได้ ชุดข้อมูลเล็กแต่ตรงงานมีค่ากว่า benchmark ใหญ่ที่ไม่เหมือนสิ่งที่เราจะใช้

## ข่าวกับงานจริง

รายละเอียดของ “Leanstral 1.5” ควรตรวจกลับไปที่ Mistral news โดยตรง โดยเฉพาะถ้อยคำ สเปก และขอบเขตที่ประกาศไว้ ส่วนข้อจำกัดของระบบ งบ และความเสี่ยงที่รับได้ยังเป็นคำถามของคนใช้งาน

เวลาประเมิน Leanstral 1.5 ต้องดูพร้อมกันสามด้าน: คุณภาพคำตอบ เวลาตอบสนอง และเส้นทางที่ข้อมูลเดินทาง การดีขึ้นด้านหนึ่งอาจแลกกับอีกด้านโดยที่หน้า demo ไม่ได้บอกเรา

พอมีผลจากการลอง Leanstral 1.5 แล้ว trade-off จะชัดกว่าตอนอ่านประกาศ

ในกรณีของ “Leanstral 1.5” ความเป็นไปได้กับความพร้อมใช้งานเป็นคนละเรื่องกัน ของใหม่อาจน่าสนใจและยังไม่เหมาะกับระบบของเราในวันนี้ได้พร้อมกัน

คำว่า local ควรถูกพิสูจน์จาก network trace และ config ไม่ใช่จากชื่อผลิตภัณฑ์ ส่วนคำว่าเก่งควรถูกพิสูจน์จากโจทย์ของเราเอง การเริ่มด้วย ลองกับ invariant สำคัญหนึ่งตัว แล้วเทียบเวลาเขียน spec กับเวลาที่ลดจาก bug ทำให้สองเรื่องนี้ตรวจสอบได้พร้อมกัน

## เก็บหรือถอย

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