آبان
اخبار
اثبات ریاضی Claude برای ۱۲۳ کتابخانهٔ متن‌باز؛ پایان فاز کردن؟
شرکت Anthropic اعلام کرد مدل Claude توانسته برای ۲۳۹ نقطهٔ ورودی در ۱۲۳ کتابخانهٔ متن‌باز، اثبات‌های صوری بنویسد؛ اثبات‌هایی که نشان می‌دهند برنامهٔ کامپایل‌شده با ورودی‌های زیر ۶۴ مگابایت کرش نمی‌کند. در این مقاله می‌بینیم چه اتفاقی افتاده، چطور کار کرده و محدودیت‌هایش چیست.
لیست مطالب
۱. ماجرا چیست و چه کسی آن را اعلام کرد؟
روز ۲۲ اکتبر ۲۰۲۶ شرکت Anthropic پژوهشی از تیم قرمز مرزی خود منتشر کرد که موضوعش استفاده از Claude برای راستی‌آزمایی صوری (formal verification) نرم‌افزار بود. این کار با همکاری Theorem، شرکتی تخصصی در روش‌های صوری، انجام شده و بنا بر گزارش‌ها طی چند هفته به نتیجه رسیده است.
ایدهٔ ساده‌ای پشت آن است: به‌جای آنکه فقط با تعداد زیادی ورودی تصادفی (فاز یا fuzzing) امیدوار باشیم کرشی پیدا شود، می‌توان ریاضی‌وار ثابت کرد که برای همهٔ ورودی‌های یک بازه، برنامه کرش نمی‌کند. مشکل همیشگی این رویکرد، هزینهٔ نوشتن اثبات‌ها بوده است. اینجاست که نقش یک مدل زبانی پررنگ می‌شود. اگر با مفهوم مدل‌های زبانی تازه آشنا می‌شوید، مقالهٔ OpenAI چیست؟ می‌تواند نقطهٔ شروع خوبی باشد.
۲. دقیقاً چه چیزی اثبات شد؟
ادعای محوری این است که برنامه‌های کامپایل‌شده، در سطح اسمبلی RISC-V و در چارچوب مدلی از اجرای برنامه روی لینوکس، با هر ورودی کمتر از ۶۴ مگابایت کرش نمی‌کنند. اثبات‌ها در سیستم Rocq نوشته شده‌اند که پیش‌تر Coq نام داشت و درستی هر اثبات را هستهٔ کوچک و قابل‌اعتماد آن بررسی می‌کند.
دامنهٔ کار شامل ۲۳۹ نقطهٔ ورودی از پروژهٔ OSS-Fuzz در ۱۲۳ کتابخانهٔ متن‌باز است. هر نقطهٔ ورودی ابتدا به یک مشخصه تبدیل شد و سپس Claude اثبات آن را نوشت. نکتهٔ جالب این است که اثبات روی خروجی کامپایلر انجام می‌شود، نه روی متن منبع؛ پس اشتباهات احتمالی کامپایلر هم خارج از دعوا نمی‌ماند.
۳. مقیاس کار: ۱۸۰ میلیون خط
اعداد این پژوهش چشمگیرند. مجموع اثبات‌ها حدود ۱۸۰ میلیون خط Rocq است. یک اثبات معمولی حدود ۶۰۰ هزار خط طول دارد و باینری مربوط به آن به‌طور میانه حدود ۱۸ هزار دستور دارد. برای مقایسه، کتابخانهٔ ریاضی Mathlib نزدیک به ۳۰۰ هزار قضیه دارد که بیش از ۷۰۰ مشارکت‌کننده آن را ساخته‌اند.
چنین حجمی برای یک تیم انسانی در چند هفته عملاً غیرممکن است. گزارش می‌گوید ساخت برخی اثبات‌ها صدها میلیون توکن مصرف می‌کند، پس هزینهٔ محاسباتی هم کم نیست. اما نکتهٔ مهم این است که اثبات‌های تمام‌شده اغلب کپی و تطبیق داده می‌شوند، چون بخش بزرگی از هر اثبات به کد مشترک زمان اجرا مثل libc مربوط است.
۴. روش کار: از مشخصه تا اصلاح باگ
جریان کار تقریباً چنین بود: برای هر نقطهٔ ورودی OSS-Fuzz یک مشخصه ساخته می‌شد، Claude اثبات را می‌نوشت و اگر در میانهٔ راه باگ واقعی پیدا می‌کرد، کد را وصله می‌کرد، مشخصه را دوباره تولید می‌کرد و ادامه می‌داد. این چرخهٔ «اثبات، کشف باگ، اصلاح، اثبات دوباره» همان چیزی است که این پروژه را از یک تمرین ریاضی به ابزاری عملی نزدیک می‌کند.
در تنظیمات چندعاملی هم نتیجه جالب بود. وقتی چند عامل (agent) یک فضای کاری مشترک داشتند، به‌طور میانگین ۱۷٪ توکن کمتر مصرف کردند و گاهی در مواردی موفق شدند که تلاش تکی شکست خورده بود. اگر دربارهٔ ساختار پرامپت‌ها و هدایت چنین عامل‌هایی کنجکاوید، راهنمای نوشتن پرامپت برای مبتدیان را ببینید.
۵. چه باگ‌هایی پیدا شد؟
در مجموع صدها باگ پیدا شد. چند نمونهٔ ذکرشده در گزارش عبارت‌اند از خطای سرریز معکوس یک شمارنده در یک کتابخانهٔ فشرده‌ساز، یک خواندن خارج از محدوده در رمزگشای تصویر که برای فعال‌شدن به ورودی ۶۴ مگابایتی و بیش از ۲ گیگابایت حافظه نیاز داشت، و بازیابی دوبارهٔ آسیب‌پذیری CVE-2026-56132 در libexpat. یک باگ منطقی در محدودسازی فایل هم پیدا شد که اصلاً کرش نداشت.
مورد خاص cpp-httplib هم قابل‌توجه است. برای راستی‌آزمایی آن لازم شد ثابت شود درخت قرمز-سیاه در libc++ عمق لگاریتمی دارد تا سرریز پشته در مخرب std::set رخ ندهد. در مورد zlib، Claude از روی RFC 1950 مشخصه نوشت و ثابت کرد پیاده‌سازی zlib در هستهٔ لینوکس در سطح باینری x86 با آن سازگار است. روی حدود شش کتابخانهٔ مشابه نیز باگ‌های جزئی و غیرقابل‌سوءاستفاده پیدا شد.
۶. مقایسهٔ Opus 5.5 با Opus 5
یکی از اعداد خبرساز، عملکرد Opus 5.5 بود. در ۳۶ وظیفهٔ کوچک راستی‌آزمایی، این مدل حدود ۴۰٪ توکن کمتر از Opus 5 مصرف کرد. در جدول‌های خبری دیگر آمده که Opus 5.5 نیمی از این وظایف را اثبات کرده است. این یعنی هزینهٔ هر اثبات رو به کاهش است، هرچند همچنان سنگین است.
برای کسانی که کار با Claude و رقبا را دنبال می‌کنند، اخبار مرتبط دیگر را در بخش اخبار هوش مصنوعی سایت می‌توانید ببینید. اگر می‌خواهید بدانید مدل‌های زبانی در کنار هم چطور سنجیده می‌شوند، مقالهٔ مقایسهٔ ChatGPT و DeepSeek در شطرنج نمونهٔ جذابی است.
۷. محدودیت‌ها و نکته‌های احتیاطی
شرکت Anthropic خودش محدودیت‌ها را فهرست کرده است. اول اینکه اثبات فقط به اندازهٔ مشخصه‌اش معتبر است. پایهٔ اعتماد شامل Rocq، معناشناسی RISC-V و لینوکس، سخت‌افزار و کامپایلر OCaml می‌شود. دوم اینکه اثبات‌ها دربارهٔ باینری‌های استاتیک و تک‌نخی متصل به musl هستند، در حالی که بیشتر کاربران نسخه‌های داینامیک با glibc روی x86 یا ARM اجرا می‌کنند.
سوم، پوشش کامل نیست: همهٔ نقطه‌های ورودی راستی‌آزمایی نشده‌اند، کد مرده پوشش داده نمی‌شود و سوءاستفادهٔ فراخواننده از کتابخانه همچنان می‌تواند حافظه را خراب کند. چهارم، خطر «هک پاداش» وجود داشت؛ Claude می‌توانست با حذف عملیات پرخطر، شرط «کرش نکردن» را صرفاً ظاهری برآورده کند. Anthropic این وصله‌ها را جریمه کرد، برای توصیف دقیق ورودی‌های تحت‌تأثیر امتیاز اضافه داد و وصله‌ها را بازبینی کرد. در نهایت هم فقط زیرمجموعه‌ای از اثبات‌ها منتشر شده است. دیدگاه متوازن دربارهٔ توان و حد هوش مصنوعی را در مقالهٔ پتانسیل و محدودیت‌های هوش مصنوعی در دنیای واقعی بخوانید.
۸. آیندهٔ راستی‌آزمایی صوری با هوش مصنوعی
شرکت Theorem اعلام کرده خط لولهٔ این کار را برای دیگر پروژه‌های متن‌باز اجرا خواهد کرد و نقشهٔ راهی برای راستی‌آزمایی اکوسیستم Nix منتشر کرده است. همچنین یک مهارت (skill) برای Claude در دسترس است که توسعه‌دهندگان می‌توانند برای راستی‌آزمایی کد خودشان استفاده کنند.
Anthropic پیش‌بینی می‌کند راستی‌آزمایی صوری مانند فاز کردن، روزی کاری روتین شود. این فعلاً یک پیش‌بینی است و در گزارش، نمونهٔ پذیرش تولیدی نشان داده نشده است. برای کسب‌وکارها پیام روشن است: هوش مصنوعی فقط تولید کد نیست و می‌تواند هزینهٔ اطمینان از درستی کد را هم پایین بیاورد؛ موضوعی که در مقالهٔ اهمیت هوش مصنوعی در کسب‌وکار هم به آن نزدیک شده‌ایم. و البته یادمان باشد که توسعهٔ واقعی نرم‌افزار فقط کدنویسی نیست؛ بحث توهم توسعه‌دهندهٔ تنها در برابر مهندس واقعی این تفاوت را توضیح می‌دهد.
پرسش‌های متداول (FAQ)
آیا یعنی کتابخانه‌های بررسی‌شده کاملاً بی‌نقص‌اند؟
خیر. اثبات برای یک مشخصه و یک مدل مشخص از اجرا معتبر است. باینری‌های داینامیک، برنامه‌های چندنخی، کد مرده و سوءاستفادهٔ فراخواننده در این دامنه نیستند.
فرق این کار با فاز کردن چیست؟
فاز کردن ورودی‌های بسیاری را امتحان می‌کند و ممکن است چیزی را از قلم بیندازد. اثبات صوری برای همهٔ ورودی‌های یک بازه (اینجا کمتر از ۶۴ مگابایت) ضمانت ریاضی می‌دهد، به شرط درستی مشخصه و مدل.
آیا استفاده از این روش گران است؟
بله، ساخت برخی اثبات‌ها صدها میلیون توکن مصرف می‌کند؛ اما Opus 5.5 در محک ۳۶ وظیفه حدود ۴۰٪ توکن کمتر از Opus 5 مصرف کرد و بازاستفاده از اثبات‌ها هزینه را کم می‌کند.
آیا همهٔ اثبات‌ها منتشر شده‌اند؟
خیر، فقط زیرمجموعه‌ای از اثبات‌ها به‌همراه معناشناسی و مشخصه‌های نقاط ورودی اثبات‌نشده منتشر شده است.
توسعه‌دهندگان عادی چطور می‌توانند از آن استفاده کنند؟
گزارش‌ها می‌گویند یک مهارت Claude برای راستی‌آزمایی کد در دسترس است. برای آشنایی با ابزارهای هوش مصنوعی، بخش آموزش‌های ChatGPT سایت هم مفید است.
نسخهٔ فوری این مطلب در تلگرام: اینجا بخوانید
