پرش به محتوای اصلی
پرش به محتوای مقاله

سه رویکرد متضاد در دبیان برای مدیریت یا ممنوعیت کدهای تولید‌شده با هوش مصنوعی

·۴ مرداد ۱۴۰۵۱۰ دقیقه مطالعه۱ بازدید
پیش‌نویس قطعنامه: استفاده از مدل‌های زبانی بزرگ در دبیان
پیش‌نویس قطعنامه: استفاده از مدل‌های زبانی بزرگ در دبیان
اشتراک‌گذاری
واقعاً چه چیز جدید است؟

تلاش برای قانونی‌کردن یا ممنوعیت رسمی خروجی‌های LLM در سطح «قرارداد اجتماعی» یک پروژه زیربنایی؛ گذار از بحث‌های پراکنده به یک resolução رسمی و الزام‌آور.

تصور کنید در مدیریت یک سیستم‌عاملی هستید که اعتبارش تنها به یک چیز وابسته است: پایداری مطلق. حالا باید تصمیم بگیرید آیا اجازه می‌دهید کدهایی که توسط یک ماشین نوشته شده‌اند و احتمال خطا در آن‌ها بالاست، وارد قلب تپنده این زیرساخت شوند یا خیر.

پروژه دبیان (Debian Project) در حال حاضر درگیر یک بحث بنیادین است؛ اینکه آیا باید اجازه دهد کدها و مستنداتی که توسط مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — نوشته شده‌اند، پذیرفته شوند یا نه. طبق اعلام رسمی این پروژه، در ۲۴ ژوئیه ۲۰۲۶، جامعهٔ کاربران وارد دورهٔ بحث‌های رسمی شدند تا سه پیشنهاد رقیب را ارزیابی کنند که می‌تواند تعهد تاریخی دبیان به پایداری را بازتعریف کند.

این شکاف ایدئولوژیک درست زمانی رخ می‌دهد که اکوسیستم نرم‌افزاری جهان با تضادی سخت روبروست: سرعت بالای تولید کد توسط هوش مصنوعی در برابر قابلیت اطمینان تأییدشده توسط انسان. همان‌طور که در تحلیل قبلی ما درباره‌ی عامل‌های خودکار علی‌بابا (Alibaba) اشاره کردیم، بسیاری از سازمان‌ها پذیرفته‌اند که بررسی کد را به ماشین‌ها بسپارند، اما مشارکت‌کنندگان دبیان می‌پرسند آیا این ابزارها ماهیت یک سیستم‌عامل جامعه‌محور را تخریب نمی‌کنند؟

پیشنهاد A: ممنوعیت کامل

این طرح که توسط ماتیاس گایگر [[email protected]] ارائه شده و با همکاری جسی رودز و با ورودی‌هایی از Sledge و josch نوشته شده است، به‌طور صریح هرگونه مشارکت نوشته‌شده با کمک ابزارهای هوش مصنوعی زاینده (Generative AI) یا LLMها را ممنوع می‌کند. برای حذف هرگونه تردید، این پیشنهاد توصیه می‌کند بخش ششمی به «قرارداد اجتماعی» (Social Contract) دبیان با عنوان «آثار خلق‌شده توسط مدل‌های زبانی بزرگ (LLMs)» اضافه شود.

حوزهٔ شمول این ممنوعیت غیرجامع است اما به‌طور مشخص موارد زیر را در بر می‌گیرد:

  • بسته‌های منبع (source packages) دبیان
  • نرم‌افزارهای رسمی پروژه دبیان، مانند لینتیان (lintian)
  • منابع وب دبیان
  • مستندات و ترجمه‌های ارسالی توسط مشارکت‌کنندگان دبیان
  • ارتباطات رسمی دبیان

لازم به ذکر است که این ممنوعیت شامل پروژه‌های Upstream (بالادستی) که از LLMها برای توسعه استفاده می‌کنند، نرم‌افزارهای مرتبط با هوش مصنوعی، یا وصله‌های Upstream و اصلاحات امنیتی نمی‌شود. این پیشنهاد مورد حمایت گروه گسترده‌ای از جمله یوهانس شاور، مارین رودریگز، آنتوان لو گونی‌دک، سیمون ریشتر، دیوید برمنر، پیر-الیوت بکویه، ایان جکسون، امین بندعلی و تورستن گلازر قرار گرفته است.

منطق این پیشنهاد ریشه در نقد رویکرد «سریع حرکت کن و چیزها را بشکن» (move fast and break things) دارد. گایگر استدلال می‌کند که استفاده از LLM با شهرت دبیان در پایداری و قابلیت اطمینان در تضاد است و این پایداری را برای جایگاه دبیان در اکوسیستم نرم‌افزار آزاد حیاتی می‌داند. او چهار نگرانی اصلی را مطرح می‌کند:

۱. ابهامات حقوقی و کپی‌رایت
وضعیت قانونی خروجی‌های LLM نامشخص است. ممکن است این خروجی‌ها به خودی خود دارای کپی‌رایت باشند یا نباشند؛ همچنین ممکن است تحت تأثیر تمام لایسنس‌ها و کپی‌رایت‌های موجود در داده‌های آموزشی باشند یا نباشند. از آنجایی که سیاست‌های دبیان (Debian Policy) و DFSG نیازمند شفافیت مطلق در مورد لایسنس و کپی‌رایت هستند، خروجی‌های LLM نباید استثنای خاصی داشته باشند، به‌ویژه وقتی مشارکت‌های انسانی معمولی با وضعیت نامشخص ممنوع هستند. این پیشنهاد به‌طور صریح به سیاست‌های دبیان در مورد ملاحظات کپی‌رایت آرشیو و دستورالعمل‌های قرارداد اجتماعی اشاره می‌کند.

۲. کیفیت و دقت فنی
مدل‌های زبانی به جای تولید کد درست، «ترکیبات احتمالی از نظر نحوی» (syntactically likely combinations) تولید می‌کنند. آن‌ها نمی‌توانند «بدانند» که آیا خروجی درست است یا خیر. در حوزه بسته‌بندی (Packaging)، جایی که هر بسته منبع منحصر‌به‌فرد است و روش‌های بهینه در حال تکامل هستند، بسته‌های تولیدشده توسط LLM اغلب ترکیبی از محتویاتی هستند که از کل تاریخچه آرشیو جمع‌آوری شده‌اند. این امر منجر به ایجاد Overrideهای خارج از کانتکست، کپی‌رایت‌های خیالی و فایل‌های watch می‌شود که کار نمی‌کنند و در نتیجه برای آپلود نامناسب هستند.

گایگر اشاره می‌کند که در حالی که یک مشارکت‌کننده باسابقه با تخصص در بسته‌بندی ممکن است کاربرد محدودی در این ابزارها بیابد، اما یک مشارکت‌کننده تازه‌وارد نخواهد دانست که چگونه این خطاها را اصلاح کند. این پیشنهاد برای توجیه نگرانی‌های کیفی، به تحقیقات مربوط به توهمات (hallucinations) چت‌بات‌های هوش مصنوعی و شکست گراف‌های ارجاع (attribution graphs) استناد می‌کند.

۳. تخریب جامعه و فرسودگی بازبین‌ها
دبیان جامعه‌ای است که بر پایه حل مسائل فنی بنا شده است. اجازه دادن به مشارکت‌های LLM، رشد این جامعه را متوقف می‌کند. مشارکت‌کنندگان جدیدی که خروجی‌های AI را ارسال می‌کنند، فشار غیرضروری بر بازبین‌ها وارد می‌کنند که منجر به «سوختگی شغلی» (Burnout) آن‌ها می‌شود. علاوه بر این، تازه‌واردهایی که وابسته به LLM هستند، جزئیات بسته‌بندی دبیان را یاد نمی‌گیرند و این بدان معناست که آن‌ها نمی‌توانند جایگزین توسعه‌دهندگان باسابقه دبیان (DDs) شوند که در نهایت بازنشسته خواهند شد.

۴. اثرات اخلاقی و زیرساختی
شرکت‌های LLM بدون توجه به لایسنس‌ها، کپی‌رایت‌ها یا فایل‌های robots.txt، وب را می‌تراشند (Scrape می‌کنند). این رفتار به عنوان یک حمله Denial of Service گسترده و دائمی به منابع وب عمومی، از جمله زیرساخت‌های دبیان، توصیف شده است. این وضعیت پروژه را مجبور کرد تا بررسی‌های مبتنی بر JS را فعال کند و باعث تلف شدن زمان مدیران سیستم شد.

علاوه بر این، آموزش LLMها مقدار خیره‌کننده‌ای منابع مصرف می‌کند و به بحران انرژی مراکز داده دبیان دامن می‌زند. این بی‌توجهی به اینترنت به عنوان یک منبع عمومی، با اولویت قرارداد اجتماعی دبیان در خدمت به کاربران و نرم‌افزارهای آزاد در تضاد است. این پیشنهاد با این نتیجه‌گیری پایان می‌یابد که دبیان برای عجله در ارائه ویژگی‌های جدید یا بسته‌بندی هر تکه نرم‌افزار در جهان نیست، بلکه برای قابل اعتماد و امن ماندن است.

پیشنهاد B: پذیرش تنظیم‌شده

در تضاد کامل، لوکاس نوسبام [[email protected]] چارچوبی را پیشنهاد داده است که اجازه می‌دهد مشارکت‌های کمک‌گرفته از AI، به شرط رعایت شرایط سخت‌گیرانه پذیرفته شوند. این پیشنهاد که مورد تأیید مشارکت‌کنندگانی چون اندرای رahmatولین، کریستین کاستنر، آنتون گلدکی، استفانو زاکیرولی، سیمون کویگلی، سورن استاتنر، جولیان اندرس کلود، اندراس تیله و فیلیپ کرن است، تشخیص می‌دهد که بسیاری از مشارکت‌کنندگان در حال حاضر این ابزارها را برای بهبود پروژه مفید می‌بینند.

با استفاده از اختیارات بخش ۴.۱ (۵) قانون اساسی، پیشنهاد B جایگاهی را ایجاد می‌کند که می‌تواند در طول زمان تکامل یابد بدون اینکه نیاز به قطعنامه‌های عمومی بیشتر باشد. طبق پیشنهاد B، استفاده از AI مجاز است اگر مشارکت‌کنندگان از این دستورالعمل‌ها پیروی کنند:

دستورالعمل‌های استفاده از AI:

  • سازگاری قانونی: کاربران باید اطمینان حاصل کنند که شرایط ابزار مورد استفاده، محدودیت‌های قراردادی تحمیل نکند که با توزیع، تغییر یا استفاده از خروجی در دبیان در تضاد باشد.
  • لایسنس و ارجاع: مشارکت‌کنندگان باید تأیید کنند که اگر ابزار AI مواد کپی‌رایت‌شده پیشین توسط اشخاص ثالث را گنجانده باشد، حق ارسال خروجی تحت لایسنس متن‌باز مربوطه را دارند.
  • مسئولیت‌پذیری کامل: مشارکت‌کننده انسانی مسئولیت کامل مزایای فنی، امنیت و رعایت لایسنس را بر عهده می‌گیرد. آن‌ها باید تغییرات پیشنهادی را به‌طور کامل درک کرده و آماده توجیه آن‌ها باشند.
  • افشای اجباری: کمک‌های قابل توجه AI باید به‌وضوح قابل مشاهده باشد. یک گزینه مناسب برای کامیت‌ها، استفاده از تریلر گیت (Git trailer) مانند Generated-By: یا Assisted-By: است. این مورد شامل کدها، پست‌های لیست پستی و بحث‌های مربوط به باگ‌ها می‌شود.
  • پروتکل تغییرات انبوه: مشابه فرآیند ثبت انبوه باگ‌ها در بخش ۷.۱.۱ مرجع توسعه‌دهندگان، مشارکت‌کنندگان باید پیش از ارسال مشارکت‌های انبوه یا تولیدشده به‌صورت خودکار، قصد خود را مورد بحث قرار دهند. این موارد باید تحت نظارت یک انسان باشد.
  • حفاظت از حریم خصوصی: مشارکت‌کنندگان از استفاده از ابزارهایی که اطلاعات غیرعمومی یا حساس پروژه — مانند گزارش‌های امنیتی محرمانه (embargoed) یا ارتباطات خصوصی — را به ارائه‌دهندگان غیرقابل اعتماد ارسال می‌کنند، منع شده‌اند.

پیشنهاد C: رد اخلاقی

ایان جکسون [[email protected]] در پیشنهاد C موضعی فلسفی‌تر و تهاجمی‌تر گرفته و درخواست می‌کند که تمام مشارکت‌کنندگان و تصمیم‌گیرندگان به عنوان یک اصل اخلاقی از LLMها دوری کنند. این پیشنهاد که مورد تأیید آندریا پاپاکودا، ماتیاس گایگر، سیمون ریشتر، آنتوان لو گونی‌دک، امین بندعلی، بیل بلو، انریکو زینی و شان ویتون است، LLMها را تولیدکنندگان «مهملات» (bullshit) می‌نامد که فضای مشترک اطلاعاتی را آلوده می‌کنند.

جکسون طیف گسترده‌ای از مشکلات مرتبط با LLMها را فهرست می‌کند: تضعیف ساخت جامعه نرم‌افزارهای آزاد، آسیب‌های محیط‌زیستی، استثمار نویسندگان، خطرات برای سلامت روان کاربران، حباب‌های اقتصادی، تحریف بازار سخت‌افزار، کلاهبرداری و مالکیت توسط «افراد و شرکت‌های وحشتناک».

در حالی که او تشخیص می‌دهد ممنوعیت کامل تمام نرم‌افزارهای Upstream در حال حاضر غیرعملی است، پیشنهاد C الزامات سخت‌گیرانه‌ای را به عنوان مکمل «کد رفتاری» (Code of Conduct) معرفی می‌کند:

اجرا و استانداردهای انسانی:

  • ارتباطات فقط انسانی: پیام‌ها به انسان‌ها — شامل گزارش‌های باگ، پیام‌های لیست پستی، بحث‌های Salsa و پست‌های وبلاگی در Planet Debian — باید صرفاً توسط انسان و بدون کمک LLM پیش‌نویس شوند.
  • الزامات افشا: هرگونه استفاده از LLM برای کارهای دبیان باید افشا شود.
  • خودمختاری محلی: پروژه‌ها و نگهدارندگان (maintainers) به‌صورت فردی می‌توانند مشارکت‌های LLM را به‌طور کامل ممنوع کنند و این ممنوعیت‌ها (حتی اگر توسط Upstreamها باشند) باید مورد احترام قرار گیرند.
  • اجرا: تخلفات به عنوان نقض کد رفتاری تلقی شده و منجر به اقدامات انضباطی سریع اما متناسب خواهند شد.
  • شمول زبانی: برای اطمینان از اینکه غیرانگلیسی‌زبان‌ها به حاشیه نروند، این پیشنهاد به‌طور صریح اجازه می‌دهد که افراد به زبان مادری خود بنویسند. خوانندگان تشویق می‌شوند از ابزارهای ترجمه شخصی خود استفاده کنند. پروژه قول می‌دهد که هیچ‌کس را به‌خاطر اشتباهات زبانی شرم‌زده نکند و در حالی که خلاصه‌های انگلیسی نوشته‌شده توسط انسان مورد استقبال قرار می‌گیرند، اما اجباری نیستند.

تحلیل: پایداری در برابر سرعت

این درگیری فراتر از یک اختلاف فنی است؛ این نبردی برای روح «سیستم‌عامل جهانی» است. اگر پیشنهاد A یا C پیروز شود، دبیان سیگنالی می‌دهد که شهود انسانی و تأیید دستی، تنها استانداردهای پذیرفته‌شده برای زیرساخت‌های حیاتی هستند. این رویکرد به‌طور مؤثر دبیان را به عنوان «جنبش غذای آرام» (Slow-food) در دنیای نرم‌افزار معرفی می‌کند؛ جایی که منشأ (provenance) و اخلاق بر حجم خروجی اولویت دارد. پیشنهاد A به‌طور خاص از سیاست‌های مشابه AI در GNOME، Gentoo و Codeberg الهام گرفته است. این رویکرد یادآور چالش‌های مشابهی است که در پلتفرم Codeberg برای مقابله با تهدیدات مدل‌های زبانی بر اکوسیستم نرم‌افزارهای آزاد مطرح شده است.

اما اگر پیشنهاد B پذیرفته شود، دبیان واقعیت جدیدی را می‌پذیرد: برنامه‌نویس دیگر صرفاً نویسندهٔ کد نیست، بلکه ویراستار پیش‌نویس‌های AI است. در این حالت، ریسک از «چگونه بنویسیم؟» به «چگونه تأیید کنیم؟» تغییر می‌کند. این تغییر یا چرخهٔ توسعه را سرعت می‌بخشد یا لایه‌ای از «بدهی فنی» (Technical Debt) ایجاد می‌کند که بازبین‌های خسته، که در حال حاضر با فرسودگی شغلی مواجه‌اند، برای شناسایی آن در تکاپو باشند.

گام‌های بعدی

جامعه دبیان به دوره بحث‌های خود ادامه خواهد داد تا تعیین کند کدام قطعنامه (اگر اصلاً پذیرفته شود) تصویب خواهد شد. منتظر رای‌گیری نهایی باشید تا ببینید آیا «قرارداد اجتماعی» این پروژه به‌طور رسمی برای ممنوع کردن هوش مصنوعی زاینده اصلاح می‌شود یا خیر.

چرا این موضوع مهم است؟

این تصمیم بر استاندارد پذیرش کد در تمام توزیع‌های لینوکس و پروژه‌های زیربنایی تأثیر می‌گذارد. اعتبار دبیان به دلیل سخت‌گیری در تأیید انسانی است و هر تغییری در این روند، مفهوم «پایداری» در نرم‌افزار را تغییر می‌دهد.

تأثیر برای ایران

این بحث برای توسعه‌دهندگان ایرانی که در پروژه‌های متن‌باز جهانی مشارکت دارند اهمیت دارد؛ پذیرش یا رد کدهای AI در دبیان می‌تواند الگوی پذیرش در سایر پروژه‌های Open Source شود.

·نگاه ما
تحریریه دات‌هوش

دبیان با این تصمیم، مرز بین «بهره‌وری» و «صحت» را دوباره ترسیم می‌کند. این رویکرد نشان می‌دهد که در لایه‌های زیربنایی فناوری، اعتماد به خروجی‌های احتمالی AI هنوز یک ریسک پذیرفته‌ناپذیر است و دبیان ترجیح می‌دهد «کند اما درست» باشد تا «سریع اما خطاآلود».

منابع

این گزارش با خط‌لولهٔ خودکار دات‌هوش از منابع معتبر جهانی تدوین و زیر نظر تحریریه منتشر شده است. روش کار ما

گفتگو

پنج‌شنبه‌های هوش‌محور

بسته‌ی هفتگی دات‌هوش

۵ خبر، ۲ ابزار، ۱ پرامپت در هر شماره. به‌زودی راه‌اندازی می‌شود — هر پنج‌شنبه صبح.

خبر کلیدی
ابزار کاربردی
پرامپت حرفه‌ای
تحلیل پژوهش
به‌زودی
زاویه‌ی ایرانی
به‌زودی
تمرین این هفته
به‌زودی

راهنماهای دات‌هوش

راهنماهای کاربردیِ دات‌هوش برای کار با هوش مصنوعی — از همین‌جا شروع کنید:

دات‌هوش

راهنمای فارسی هوش مصنوعی — با نگاه به ایران

اخبار روزانه، معرفی ابزارها و مدل‌ها، و آموزشِ کار با هوش مصنوعی؛ همیشه با این پرسش که از ایران چه چیزی کار می‌کند و چه چیزی نه.