مرداد
اخبار
احیای ۲۰ هزار خط کد ژنومیک؛ گزارش میدانی تازهی اوپنایآی
حدود ۲۰ هزار خط کد ژنومیک که سالها دستنخورده و شکننده مانده بود، حالا با کمک عاملهای کدنویس بازنویسی شده است. اوپنایآی در یک گزارش میدانی تازه، هشت پروژهی واقعی نرمافزار علمی را دنبال کرده که در آنها Codex و در برخی موارد Claude Code وارد کار شدهاند. نتیجهها چشمگیرند: از شصت برابر شدن سرعت اجرا تا بازنویسی کامل یک ابزار همترازسازی ژنوم. اما همین گزارش یک هشدار روشن هم دارد که مهمتر از خود اعداد است.
لیست مطالب
۱) گزارشی از میدان، نه از آزمایشگاه
اواخر ژوئیهی ۲۰۲۶ اوپنایآی سندی منتشر کرد با عنوان «محاسبات علمی در عصر هوش مصنوعی عاملمحور: یک گزارش میدانی اکتشافی». تفاوت این سند با معیارسنجیهای معمول در همان کلمهی «میدانی» نهفته است. اینجا خبری از مسئلههای ساختگی و آزمونهای استاندارد نیست؛ هشت پروژهی نرمافزاری واقعی که پژوهشگران هر روز از آنها استفاده میکنند، در اختیار عاملهای کدنویس قرار گرفتند و نتیجه ثبت شد.
مدلهای بهکاررفته در این پروژهها یکسان نبودند. در بیشتر موارد از نسخههای GPT-5.5 و GPT-5.2 از طریق Codex استفاده شد و در بخشی از پروژهها هم Claude Code وارد کار شد. یعنی گزارش عمداً خودش را به یک خانوادهی مدل محدود نکرده و تصویری از وضعیت کلی عاملهای کدنویس ارائه میدهد.
اهمیت انتخاب حوزهی نرمافزار علمی هم کم نیست. کدهای پژوهشی معمولاً بدترین کابوس هر مهندس نرمافزارند: نوشتهشده توسط زیستشناس یا فیزیکدانی که برنامهنویس حرفهای نبوده، بدون مستندات، بدون آزمون خودکار، وابسته به کتابخانههایی که سالهاست بهروزرسانی نشدهاند و اغلب نویسندهی اصلیشان دیگر در آن آزمایشگاه نیست. اگر عاملهای هوش مصنوعی بتوانند در این محیط کار کنند، تقریباً هرجای دیگری هم میتوانند.
۲) داستان اصلی؛ بازسازی ۲۰ هزار خط ابزار همترازسازی ژنوم
پرسروصداترین مورد این گزارش پروژهای است که در آن یک ابزار مرجع همترازسازی توالی ژنوم، با حجمی در حدود ۲۰ هزار خط کد سی و سیپلاسپلاس، از پایه در زبان Rust بازنویسی شد. این ابزار سالهاست ستون فقرات تحلیل دادههای توالییابی RNA در هزاران آزمایشگاه است و دست بردن در آن همیشه پرریسک بوده.
معیار موفقیت هم دقیقاً به همین دلیل سختگیرانه تعریف شد: خروجی نسخهی جدید باید با نسخهی اصلی یکی میشد. طبق ارقام گزارششده، میزان تطابق برای خوانشهای تکانتهایی حدود ۹۹.۸۱۵ درصد و برای خوانشهای جفتانتهایی حدود ۹۹.۸۸۳ درصد بود. در دنیای ژنومیک، این سطح از تطابق یعنی نسخهی جدید عملاً قابل جایگزینی است، هرچند آن کسر باقیمانده هم بیاهمیت نیست و باید ریشهیابی شود.
نکتهی ظریف اینجاست که چنین پروژهای پیش از این عملاً غیرممکن بود. بازنویسی ۲۰ هزار خط کد علمی پیچیده در یک زبان دیگر، در حالت عادی ماهها کار تماموقت یک تیم چندنفره میخواهد و هیچ آزمایشگاهی بودجهاش را ندارد. کاهش هزینهی مهندسی، همان چیزی است که این کار را از دستورکار آرزویی به دستورکار واقعی منتقل کرده است.
۳) شصت برابر سریعتر: از ۱۵ ساعت به ۱۵ دقیقه
چشمگیرترین عدد گزارش به پروژهای برمیگردد که در آن حدود ۱۵ ابزار جداگانهی کنترل کیفیت دادههای توالییابی در یک بستهی یکپارچهی نوشتهشده به Rust ادغام شدند. زمان اجرای این خط لوله روی مجموعهدادهی مرجع، از حدود ۱۵ ساعت و نیم به حدود ۱۵ دقیقه کاهش پیدا کرد؛ یعنی بیش از شصت برابر سریعتر.
برای درک معنای عملی این عدد باید به روال کار آزمایشگاه فکر کرد. وقتی یک مرحلهی پیشپردازش ۱۵ ساعت طول میکشد، پژوهشگر عملاً روزی یک بار میتواند آن را اجرا کند؛ هر اشتباه کوچک در تنظیمات یعنی یک روز از دست رفته. وقتی همان مرحله ۱۵ دقیقه طول بکشد، پژوهشگر میتواند دهها بار در روز آزمون و خطا کند. این تغییر، تفاوت میان «تحلیل داده بهعنوان یک پروژه» و «تحلیل داده بهعنوان یک عملیات روزمره» است.
پروژهی دیگری هم در همین حالوهوا گزارش شده: یک تولیدکنندهی دادهی ژنومی مصنوعی که با بهرهگیری از پردازش گرافیکی، حدود ۵۹.۶ برابر سریعتر از ابزار مرجع پیشین عمل کرد و در عین حال فراوانی جهشهای تولیدشده را به مقادیر هدف نزدیکتر کرد. یعنی هم سریعتر شد، هم دقیقتر.
۴) شش پروژهی دیگر و کارنامهی واقعی عاملها
بقیهی موارد گزارش، تصویر متعادلتری میسازند. یکی از پروژهها یک کتابخانهی پایتون برای خواندن فایلهای تنوع ژنتیکی بود که مشکل اصلیاش نه الگوریتم، بلکه فرایند ساخت و نصب پیچیده و شکنندهی آن بود؛ عامل توانست این فرایند را یکپارچه و ساده کند. پروژهی دیگری یک مدل ایمنیشناسی بود که حدود ۱۰ هزار خط کد آن از TensorFlow و Keras به PyTorch منتقل شد، آن هم با حفظ سازگاری وزنهای مدل؛ کاری که یکی از مشارکتکنندهها آن را «نگهداری بیزرقوبرق و طاقتفرسا» توصیف کرده، همان کاری که پروژههای علمی را زنده نگه میدارد.
در یک ابزار سرهمبندی ژنوم، بهینهسازی حدود ۲۵ درصد روی هدفهای تعیینشده و حدود ۱۵ درصد روی دادههای واقعی توالییابی انسانی کاهش زمان اجرا داد. در یک کتابخانهی شبیهسازی ژنتیکی، دو مرحله بهینهسازی حدود ۳۱ درصد زمان اجرا را کم کرد، بدون آنکه خروجی تغییر کند؛ یکی از مشارکتکنندهها نتیجه را از دید کاربر نهایی «چیزی کم از جادو» توصیف کرده است.
و در نهایت یک بستهی آماری که به Rust منتقل شد و بین ۲.۳ تا ۲.۷ برابر در حالت تکرشتهای و بین ۴.۴ تا ۹.۵ برابر روی هشت رشته سریعتر شد. اما همین پروژه، جالبترین درس گزارش را هم در خود دارد؛ درسی که در بخش بعد به آن میرسیم.
۵) نقطهی کور: کد کار میکند، اما آیا علم درست است؟
همان بستهی آماری، در آزمونهای اولیه سالم به نظر میرسید. اما بررسی دقیقتر نشان داد که کد بازنویسیشده خطاهای ظریفی دارد: پارامترهایی که جایشان برعکس شده و ضریبهایی که اشتباه محاسبه شدهاند. اینها خطاهایی نیستند که برنامه را متوقف کنند یا پیام خطا بدهند؛ برنامه با کمال آرامش اجرا میشود و عددی برمیگرداند که غلط است.
یکی از پژوهشگران شرکتکننده توصیف دقیقی از این وضعیت داده است: عاملها «شیوا، متقاعدکننده و با اطمینان کامل اشتباهاند، آن هم به شکلی که بهراحتی از چشم میافتد». این جمله شاید مهمترین خط کل گزارش باشد. مسئله این نیست که عامل ضعیف عمل میکند؛ مسئله این است که وقتی اشتباه میکند، هیچ نشانهی بیرونی از اشتباه بروز نمیدهد.
در نرمافزار معمولی، خطا معمولاً خودش را نشان میدهد: برنامه کرش میکند یا خروجی آشکارا بیمعنا میدهد. در نرمافزار علمی اینطور نیست. یک ضریب اشتباه در یک مدل آماری، عددی تولید میکند که کاملاً معقول به نظر میرسد و ممکن است سر از یک مقالهی منتشرشده دربیاورد. این تفاوت، جوهرهی خطری است که گزارش روی آن دست میگذارد. بحث مشابهی دربارهی فاصلهی میان «کدی که اجرا میشود» و «کدی که مهندسیشده است» را میتوانید در تحلیل توهم برنامهنویس تنها در برابر مهندس واقعی بخوانید.
۶) بار اعتبارسنجی؛ جایی که وقت انسان واقعاً صرف شد
مهمترین یافتهی عملی گزارش این است که در بیشتر این هشت پروژه، بخش عمدهی زمان انسانی نه صرف نوشتن کد، بلکه صرف ساختن سازوکارهای سنجش درستی شد. انسانها باید مشخص میکردند «موفقیت» یعنی چه، سپس ابزارهای مستقلی میساختند که بتوانند این موفقیت را اندازه بگیرند.
این جابهجایی، تعریف نقش برنامهنویس علمی را عوض میکند. تا دیروز، مهارت اصلی نوشتن پیادهسازی درست بود. حالا مهارت اصلی، طراحی آزمونی است که بتواند پیادهسازیِ نوشتهشده توسط ماشین را به چالش بکشد. به بیان دیگر، گلوگاه از تولید به تأیید منتقل شده است.
یک مشاهدهی دیگر گزارش هم در همین راستاست: عاملها در چند مورد توانستند مشکلات کارایی را «تشخیص دهند» اما نتوانستند خودشان آنها را «حل کنند». انسان باید دادههای پروفایلینگ را در اختیارشان میگذاشت و آنها را از حلقهی تکرار شکستهای مشابه بیرون میکشید. این دقیقاً همان جایی است که کیفیت دستور و زمینهای که به مدل میدهید تعیینکننده میشود؛ موضوعی که در راهنمای پرامپتنویسی به زبان ساده مفصل توضیح داده شده است.
۷) چهار روشی که برای اعتبارسنجی جواب داد
گزارش الگوهای اعتبارسنجی موفق را دستهبندی کرده و همین بخش، کاربردیترین قسمت آن برای هر تیم مهندسی است. روش نخست، تطابق دقیق خروجی است: نسخهی جدید باید روی دادههای مرجع، دقیقاً همان خروجی نسخهی قدیم را بدهد. این سختگیرانهترین معیار است و در پروژهی همترازسازی ژنوم به کار رفت.
روش دوم، برابری با یک ابزار مستقل موجود است. اگر نمیتوان خروجی را دقیقاً بازتولید کرد، دستکم میتوان نتیجه را با ابزار دیگری که همان کار را انجام میدهد سنجید. روش سوم، بررسی رفتار آماری مناسب است؛ یعنی بهجای مقایسهی تکتک اعداد، اطمینان حاصل شود که توزیع نتایج آنگونه که تئوری پیشبینی میکند رفتار میکند.
روش چهارم؛ پاسخِ از پیش معلوم
هوشمندانهترین الگو، ساختن دادهی شبیهسازیشدهای است که پاسخ درستش را از قبل میدانید. وقتی خودتان داده را با پارامترهای مشخص تولید کردهاید، میدانید تحلیل درست باید به چه عددی برسد. اگر کد بازنویسیشده به همان عدد نرسید، بدون هیچ ابهامی اشتباه است. این روش تنها راهی است که میتواند خطاهای «با اطمینان اشتباه» را شکار کند.
۸) مالکیت پیش از استقرار؛ توصیهی پایانی گزارش
جالب است که گزارش با یک تأیید کلی از فناوری تمام نمیشود، بلکه با یک توصیهی مشخص سازمانی به پایان میرسد: پیش از استقرار هر بازنویسی، مالکیت آن مشخص شود. یعنی معلوم باشد چه کسی مسئول نگهداری، رفع اشکال و پاسخگویی دربارهی نسخهی جدید است.
منطق این توصیه روشن است. وقتی هزینهی مهندسی پایین میآید، تیمهای کوچک هم میتوانند دست به بازنویسیهای بزرگ بزنند؛ این خبر خوبی است. اما نتیجهی جانبیاش میتواند تکهتکه شدن اکوسیستم ابزارهای علمی باشد: پنج نسخهی ناسازگار از یک ابزار مرجع که هرکدام در یک آزمایشگاه ساخته شده و هیچکدام نگهدارندهی بلندمدت ندارد. در علم، سازگاری میان ابزارها به اندازهی سرعت آنها اهمیت دارد، چون بازتولیدپذیری نتایج به همین وابسته است.
این هشدار، فراتر از حوزهی علم هم معنا دارد. هر سازمانی که امروز با کمک عاملها سامانههای قدیمی خود را بازنویسی میکند، با همین پرسش روبهروست: شش ماه بعد چه کسی این کد را میفهمد؟ برای مرور گستردهتر تواناییها و مرزهای فعلی این فناوری، مطالعهی تواناییها و محدودیتهای واقعی هوش مصنوعی پیشنهاد میشود.
۹) درسهای عملی برای توسعهدهندهی ایرانی
اگرچه این گزارش دربارهی ژنومیک است، نتیجهگیریهایش برای هر تیم نرمافزاری قابل استفاده است. نخست اینکه پروژههای «کد قدیمی و ترسناک» که سالها معطل ماندهاند، حالا واقعاً قابل دست زدناند؛ همان بدهی فنی که همیشه بهانهی «وقت نداریم» داشت.
دوم اینکه پیش از شروع هر بازنویسی، باید معیار موفقیت را نوشت. اگر نمیتوانید در یک جمله بگویید «کار وقتی درست است که فلان خروجی با فلان مرجع تطابق داشته باشد»، هنوز آمادهی استفاده از عامل نیستید. سوم اینکه بودجهی زمانی پروژه را باید برعکس گذشته بست: زمان کمتر برای پیادهسازی، زمان بیشتر برای آزمون و بازبینی.
و چهارم اینکه هیچکدام از اینها جایگزین دانش حوزهای نمیشود. یکی از مشارکتکنندههای گزارش تأکید کرده که «راهنمایی متخصص، فهم، سلیقه و دقت» همچنان ضروریاند؛ سرعت عامل، جای قضاوت انسان را نمیگیرد. برای دنبال کردن روزانهی این دست تحولات میتوانید سری به بخش اخبار هوش مصنوعی بزنید و اگر با کارنامهی سازندهی این ابزارها آشنا نیستید، معرفی کامل اوپنایآی نقطهی شروع خوبی است. آموزشهای کاربردی هم در بخش آموزش چتجیپیتی در دسترس است.
پرسشهای پرتکرار دربارهی بازنویسی کد علمی با هوش مصنوعی
این گزارش دقیقاً چیست و چه کسی آن را منتشر کرده است؟
سندی است با عنوان «محاسبات علمی در عصر هوش مصنوعی عاملمحور: گزارش میدانی اکتشافی» که اواخر ژوئیهی ۲۰۲۶ از سوی اوپنایآی منتشر شد و هشت پروژهی واقعی بازسازی نرمافزار پژوهشی را با کمک عاملهای کدنویس بررسی میکند.
چه مدلهایی در این پروژهها استفاده شدند؟
طبق گزارش، عمدتاً نسخههای GPT-5.5 و GPT-5.2 از طریق Codex به کار رفتند و در بخشی از پروژهها هم Claude Code استفاده شد. یعنی نتیجهها محدود به یک خانوادهی مدل نیست.
آیا واقعاً سرعت اجرا شصت برابر شد؟
بله، اما فقط در یک پروژهی مشخص؛ ادغام حدود ۱۵ ابزار کنترل کیفیت در یک بستهی یکپارچه که زمان اجرا را از حدود ۱۵ ساعت و نیم به حدود ۱۵ دقیقه رساند. بهبود در پروژههای دیگر بسیار متنوعتر و اغلب در محدودهی ۱۵ تا ۳۱ درصد یا چند برابر بود.
بزرگترین ضعف عاملهای کدنویس در این گزارش چه بود؟
ناتوانی در قضاوت دربارهی درستی علمی خروجی خودشان. در یک پروژهی آماری، خطاهایی مثل معکوس شدن پارامترها و ضریبهای اشتباه از آزمونهای اولیه عبور کردند، چون برنامه بدون خطا اجرا میشد و عدد ظاهراً معقولی میداد.
اگر بخواهم از عامل برای بازنویسی کد قدیمی استفاده کنم، از کجا شروع کنم؟
پیش از هر چیز معیار موفقیت را بنویسید و یک آزمون مستقل بسازید؛ ترجیحاً با دادهای که پاسخ درستش را از قبل میدانید. سپس دامنهی کار را کوچک و مشخص تعریف کنید، چون گزارش نشان میدهد عاملها روی درخواستهای محدود و دقیق بهترین عملکرد را دارند.
