یک جمله توهمی در مستندات یک کتابخانه نرمافزاری میتواند کابوسی حقوقی یا پشتیبانی ایجاد کند؛ درست زمانی که یک مدل بهطور نامحسوس توصیف یک ویژگی را به یک تضمین محصول تبدیل میکند. مستندات تولیدشده توسط هوش مصنوعی زمانی شکست میخورند که جملات پیشنویس بدون داشتن یک مالک انسانی مشخص، بهطور آرام به وعدههای محصول تبدیل شوند. برای حل این مشکل، یک پروتکل فنی جدید پیشنهاد شده است تا هر جمله در مستندات تولیدشده را پیش از رسیدن به درخواست ادغام (Merge Request)، با یک توکن منشأ (Provenance Token) مهر کند.
اکثر خط لولههای تولید مستندات، این فرآیند را یک مرحله واحد میبینند که خروجی نهایی را به صورت Markdown از یک اسنپشات مخزن تولید میکند. این طراحی دچار یک خطای دستهبندی است؛ زیرا استخراج داده، استنتاج و تعهد را از یک نوع جمله میداند. در واقعیت، استخراج داده را میتوان با درخت کد چک کرد، استنتاج یک فرضیه است و وعده، یک قرارداد اجتماعی با کاربران است.
اگر این سه دسته در یک فایل بدون علامت مشترک شوند، بازبینها نمیتوانند بین شواهد و تعهدات تمایز قائل شوند. این نبود شفافیت اجازه میدهد «زبان موجودی» وعدههای خطرناکی را پنهان کند؛ مثلاً مدلی ادعا کند ابزاری «همیشه کار میکند» در حالی که این جمله را در کنار لیستی از فلگهای واقعی آورده است. راهکار عملی این است که هر جمله پیش از ادغام هرگونه خروجی مدل، با یک توکن منشأ مشخص شود. این رویکرد در واقع تکامل یافتهی ایدهی تبدیل نویسنده به کامپایلر است که برای پایان دادن به توهمات در مستندات فنی پیشنهاد شده بود.
چارچوب سه توکنی
این پروتکل سه مرز سخت برای تمام ادعاهای مستندات تعریف میکند تا اطمینان حاصل شود تعهدات پشتیبانی توسط استخراجکنندهای که توانایی تأیید آنها را ندارد، ایجاد نمیشوند:
- ادعاهای استخراجشده (Extracted Claims): یک جمله استخراجشده، حقیقتی را بازگو میکند که پیش از این در یک منبع ماشینخوان داخل مخزن وجود داشته است. منابع معتبر شامل امضاهای توابع، پارسرهای CLI، نام تستها، متادیتای بستهها، کلیدهای پیکربندی اعلامشده و جداول اکسپورت هستند. یک جمله تنها زمانی این توکن را میگیرد که خواننده بتواند مسیر ذکرشده را باز کرده و نماد (Symbol) مورد نظر را بخواند. اگر مسیر یا نماد قابل نامگذاری نباشد، جمله استخراجشده محسوب نمیشود و نباید این توکن را داشته باشد.
- ادعاهای استنتاجی (Inferred Claims): اینها دستهبندیها، ترتیبها یا ملاحظات مربوط به نحوه استفاده احتمالی هستند که مستقیماً در منبع کد وجود ندارند. مدلها این خطوط را بهراحتی تولید میکنند، و دقیقاً به همین دلیل است که آنها به جای ادغام پیشفرض، به یک صف بازبینی نیاز دارند. استنتاج ممکن است طرح کلی یک آموزش (Tutorial) را بنویسد یا دستورات مرتبط را خوشهبندی کند، اما مجاز نیست رفتار یا نسخههای جدیدی را اختراع کند. هر خط استنتاجی یک فرضیه است که با تغییر فایلهای ذکرشده در کامیتهای بعدی، منقضی میشود.
- ادعاهای وعدهشده (Promised Claims): یک جمله وعدهشده به کاربر میگوید که پروژه چه کاری انجام خواهد داد، چه چیزی را پشتیبانی میکند، چه تضمینی میدهد یا چه خدماتی را ادامه خواهد داد. مطالب وعدهشده معمولاً شامل بازههای سازگاری، محیطهای اجرای پشتیبانیشده، برچسبهای پایداری و نمونههایی است که به عنوان قراردادهای کاری ارائه میشوند. هیچ مدلی نباید این خطوط را بنویسد، حتی اگر موجودی اطراف آن بهطور دقیق از درخت کد استخراج شده باشد. یک نگهدارنده (Maintainer) نامدار باید هر جمله وعدهشده را پیش از انتشار سند، بنویسد یا صراحتاً آن را بپذیرد.
پیادهسازی فنی و کنترل
برای اجرای این مرزها، پروتکل از یک نقشه مالکیت JSON به نام docs/provenance.json و یک بررسیکننده محلی پایتونی (scripts/check_doc_provenance.py) استفاده میکند. این نقشه تعیین میکند کدام فایلها استخراجشده، استنتاجی یا وعدهشده هستند و عبارات ممنوعه را برای هر دسته تعریف میکند تا از تعهدات تصادفی جلوگیری شود.
جزئیات نقشه مالکیت
فایل docs/provenance.json به عنوان قرارداد عمل میکند. این فایل، فایلهای خاص را به نوع منشأ آنها متصل کرده و banned_phrases را تعریف میکند. برای مثال:
- فایلهای استخراجشده عباراتی مانند «تضمین میکند»، «همیشه کار میکند»، «هرگز شکست نمیخورد»، «ما پشتیبانی میکنیم»، «آماده تولید (Production-ready)»، «SLA» و «ادامه خواهد داد» را ممنوع میکنند.
- فایلهای استنتاجی عباراتی مانند «تضمین میکند»، «پشتیبانی شده تا تاریخ...»، «آماده تولید» و «SLA» را ممنوع میکنند.
- فایلهای وعدهشده چون توسط انسان نوشته میشوند، هیچ عبارت ممنوعهای ندارند.
برای اینکه قوانین بازنویسی واضح بمانند، پروتکل پیشنهاد میکند موجودی استخراجشده، فرضیات استنتاجی و تعهدات وعدهشده در سه فایل مجزا نگه داشته شوند. یک فیلتر مسیر در شغل استخراج (Extract Job) باید فایل docs/promised.md را به صورت «فقط خواندنی» لیست کند. این مورد باید با یک ورودی CODEOWNERS برای نگهدارندگان مطابقت داشته باشد. اگر یک شغل استخراج بتواند فایل وعدهها را بنویسد، توکنها در عناوین صرفاً جنبه تزئینی پیدا میکنند و دیگر ابزار کنترل نیستند. نقشه JSON قرارداد اصلی است و کامنتهای Markdown تنها شواهد هر بخش برای آن قرارداد هستند.
نشانگرهای عنوان و بررسی (Linting)
پیشنویسهای کاربر با کامنتهای منشأ در هر عنوان سطح دو مشخص میشوند که بررسیکننده میتواند آنها را تحلیل کند. پاراگرافها توکن عنوان را به ارث میبرند تا عنوان سطح دو بعدی برسد؛ این کار گرامر را برای بررسی (Lint) آسان میکند. ترکیب توکنها در یک بخش ممنوع است زیرا تعهدات معمولاً در همین بخشهای ترکیبی تحت پوشش زبان موجودی پنهان میشوند.
مثالهایی از این نشانگرها:
## Flags <!-- provenance:extracted source:src/cli.py -->## Suggested reading order <!-- provenance:inferred reviewer:pending -->## Compatibility <!-- provenance:promised signer:pending -->
در مثال اول، متن ممکن است بیان کند: `pack` accepts `--out` and `--force` as declared on `parse_args` in `src/cli.py`. در مثال دوم، ممکن است ذکر شود که کاربران جدید معمولاً ابتدا فلگها و سپس مثال pack را میخوانند. بخش سوم فقط برای متن انسانی رزرو شده است و نباید تولید شود.
مکانیزم بررسیکننده محلی
سیستم یکپارچهسازی مداوم (CI) بهگونهای تنظیم میشود که اگر یک عنوان وعدهشده فاقد امضاکننده انسانی باشد یا افعال ممنوعه در فایلهای موجودی نفوذ کنند، بیلد (Build) را با خطا متوقف کند. بررسیکننده اعتبارسنجیهای خاصی را انجام میدهد:
- اطمینان حاصل میکند که هر عنوان سطح دو دارای یک کامنت منشأ قابل تحلیل است.
- تأیید میکند که توکن با نوع مورد انتظار تعریفشده در نقشه JSON مطابقت دارد.
- برای توکنهای استخراجشده، تأیید میکند که مسیر
sourceواقعاً در مخزن وجود دارد. - برای توکنهای استنتاجی، بررسی میکند که
reviewerیک هویت ممنوعه نباشد. - برای توکنهای وعدهشده، اطمینان حاصل میکند که یک
signerانسانی حضور دارد.
این بررسیکننده یک پیشنهاد محلی است که میتواند روی دادههای نمونه (Fixtures) اجرا شود. این ابزار جایگزین نیاز به خواندن بخش وعدهها توسط انسان نمیشود. اسکریپت پایتون از عبارات منظم (Regular Expressions) برای تحلیل عناوین و کامنتها استفاده میکند و بخشها را پیمایش میکند تا مطمئن شود هیچ عبارت ممنوعهای در بدنه بخشهای استخراجشده یا استنتاجی ظاهر نشده است.
پروتکل تولید ششمرحلهای
پیادهسازی این سیستم نیازمند عبور از پرامپتهای تکمرحلهای به سمت یک توالی ساختاریافته است:
۱. فهرست منابع: لیست کردن فایلهایی که میتوانند ادعایی را اثبات کنند: پارسرها، ماژولهای عمومی، تستها، مانیفستهای بسته و شمای JSON تولیدشده. هر منبع را به عنوان یک glob در نقشه منشأ ثبت کنید تا شغلهای استخراج بعدی به فایلهای روایتی نفوذ نکنند. از مدل نخواهید که با پیمایش کل درخت، منابع را کشف کند، زیرا این کار منجر به تولید مسیرهای استنتاجی میشود. اگر منبع کاندید در مخزن نباشد، هر جمله استخراجشده از آن را تا زمان ورود فایل به مخزن، «استنتاجی» تلقی کنید.
۲. انجماد وعدهها: ایجاد یک فایل Markdown وعدهشده که شامل عناوین و فیلدهای امضاکننده باشد، اما هیچ متن بدنه تولیدشده توسط مدل نداشته باشد. این فایل را با قانون CODEOWNERS (مثلاً docs/promised.md @your-org/maintainers) یا فیلتر مسیر در شغل استخراج محافظت کنید تا تولید مدل نتواند آن را بازنویسی کند. انسانها در مرحله بعد، سازگاریها، بازههای پشتیبانی و مثالهای قراردادی را پر میکنند. تا زمانی که فیلد امضاکننده خالی باشد، CI باید کل مجموعه اسناد را به عنوان «منتشر نشده» در نظر بگیرد.
۳. تخلیه موجودی: ابتدا یک استخراجکننده قطعی (Deterministic) را اجرا کنید تا نام دستورات، فلگها، انواع بازگشتی و شناسههای گره تست را در قالب YAML یا JSON تخلیه کند. تنها پس از وجود این تخلیه، مدل باید ردیفهای موجودی را به جملات تبدیل کند و برای هر کدام یک مسیر منبع ذکر نماید. هر جمله تولیدشده باید زیر یک عنوان استخراجشده شروع شود و شامل استناد به منبع در نشانگر باشد. هر جملهای را که استخراجکننده نتواند استناد کند، حذف کنید.
۴. پارکینگ استنتاج: زبانهای مربوط به ترتیب، خوشهبندی یا استفاده معمول را فقط در inferred.md بنویسید. الزام کنید که یک انسان هر پاراگراف استنتاجی را پیش از کپی شدن در سند کاربر، بپذیرد یا حذف کند. استنتاجهای رد شده به عنوان دادههای شکست عمل میکنند و نشان میدهند مدل کجا سعی کرده یک گردشکار بدون مالک اختراع کند. متنهای استنتاجی را بهطور خودکار ادغام نکنید، زیرا مراحل استخراج بعدی نمیدانند آیا فرضیه قدیمی شده است یا خیر.
۵. پذیرش انسانی: نگهدارندگان بهطور دستی جملات وعدهشده را مینویسند، از جمله هر مثالی که کاربران به عنوان قرارداد در نظر میگیرند. نمونههای کپی-پیست شدهای که تلویحاً میگویند دستور برای کاربر کار میکند، «وعده» هستند، حتی اگر خود فلگها استخراج شده باشند. نمای نهایی را تنها پس از آنکه بررسیکننده گزارش صفر بلوک بدون علامت و صفر نشت (Leak) داد، جمعآوری کنید. فایل منتشر شده میتواند توکنها را حذف کند، به شرطی که سه منبع همچنان درخت کانونی باقی بمانند.
۶. ابطال: هنگامی که امضاهای عمومی، فلگهای CLI یا متادیتای بستهبندی تغییر میکنند، جملات استخراجشدهای را که به مسیرهای قدیمی ارجاع میدادند، باطل کنید. پاراگرافهای استنتاجی که به آن مسیرها اشاره میکنند به صف بازبینی بازمیگردند. پاراگرافهای وعدهشده تا زمانی که یک انسان آنها را ویرایش کند باقی میمانند؛ استخراج هرگز نباید یک وعده پشتیبانی را صرفاً به دلیل تغییر نام یک فلگ، بهروزرسانی کند. این تفکیک تضمین میکند که تغییرات موجودی بهطور تصادفی زبان پشتیبانی را بازنویسی نکند.
جدول تصمیمگیری برای ادعاها
برای رفع ابهام، پروتکل از این قوانین پیروی میکند:
| ادعای کاربر | توکن | نویسنده مجاز | قانون ادغام |
|---|---|---|---|
| بازگویی یک فلگ، نوع یا مسیر | استخراجشده | مدل | مسیر منبع باید موجود باشد |
| گروهبندی دستورات در ترتیب یادگیری | استنتاجی | مدل | بازبین نامدار، نه pending |
| نام بردن از محیطهای پشتیبانی شده یا پایداری | وعدهشده | فقط انسان | امضاکننده الزامی است |
| نمونه کد قابل کپی با فرض کارکرد | وعدهشده | فقط انسان | امضاکننده الزامی است |
| بازگویی شناسهی گره تست | استخراجشده | مدل | مسیر منبع باید موجود باشد |
در موارد مبهم، سیستم بهطور پیشفرض حالت وعدهشده را انتخاب میکند، زیرا هزینه وعدههای پشتیبانی غلط بیشتر از نبود یک مورد در موجودی است. یک مثال قابل کپی همیشه «وعدهشده» است هرگاه متن اطراف تلویحاً بگوید که نمونه برای کاربر کار خواهد کرد. یک امضای تابع استخراجشده تلقی میشود تنها زمانی که مسیر ماژول در نشانگر همچنان در HEAD موجود باشد.
حفاظها در برابر جعل
این پروتکل صراحتاً استفاده از شناسههای مدل (مانند "bot"، "none" یا "model") را به عنوان امضاکننده معتبر ممنوع میکند. در شاخه پیشفرض، reviewer=pending و signer=pending باید باعث شکست بررسیکننده شوند تا فرضیات بدون علامت منتشر نشوند. شاخههای کاری میتوانند وضعیت pending را حفظ کنند تا زمانی که یک شخص آن را با هویت واقعی جایگزین کند. جعل امضاکنندگان خطرناکتر از خطای سخت CI است زیرا حس کاذبی از بررسی انسانی ایجاد میکند در حالی که متن همچنان تولید ماشین است.
در حالی که بررسیکننده ثابت میکند توکنی وجود دارد و امضاکنندهای نامگذاری شده است، ثابت نمیکند که جمله استخراجشده خوانشی صحیح از منبع است. این ابزار فقط ثابت میکند توکن وجود دارد، عناوین وعدهشده امضاکننده دارند و افعال ممنوعه در موجودی نیستند. تخلیههای سینتکس همچنان میتوانند غلط باشند و تستها میتوانند رفتاری را نام ببرند که APIهای عمومی نمایش نمیدهند. بازبینها همچنان باید پاراگرافها را با درخت کد تطبیق دهند، بهویژه پس از تغییرنامهای گسترده یا تغییرات بستهبندی.
محدوده و محدودیتها
این رویکرد برای تمام مستندات نیست. کاربران باید در موارد زیر از این پروتکل صرفنظر کنند:
- اگر سند یک اطلاعیه قانونی، هشدار امنیتی یا صفحه بازاریابی با محدودیتهای شعاری سخت است.
- اگر هیچ انسانی
inferred.mdرا نخواهد خواند، زیرا صف بازبینی به یک README دوم بدون علامت تبدیل میشود. - اگر یادداشتها موقتی هستند و هرگز منتشر نمیشوند، جایی که هزینه نشانهگذاری بیشتر از هزینه یک جمله بد است.
برای تیمهایی که از سرویسهای پیشنویس مانند MonkeyCode استفاده میکنند (که دسترسی رایگان به مدل و گزینه سرور رایگان برای مراحل پیشنویس فقط-استخراج ارائه میدهد)، پروتکل تأکید دارد که فایل وعدهها باید در ماشینی باشد که مدل به آن دسترسی نوشتاری ندارد. دستورات پرامپت در مقایسه با مجوزهای فایل و بررسیکنندههای خودکار، کنترلهای ضعیفی هستند. اگر شغل استخراج بتواند docs/promised.md را به عنوان فایل قابل نوشتن ببیند، مسیر خروجی باید پیش از تنظیم پرامپتها جابجا شود.
از مدل برای پر کردن فیلدهای امضاکننده استفاده نکنید. با بررسیکننده روی یک README کتابخانه شروع کنید و نقشه را تنها پس از آنکه اولین بخش وعدهشده امضاکننده داشت، گسترش دهید. این تغییر، هدف مستندات AI را از «متن بیشتر» به مخزنی تبدیل میکند که در آن هر ادعای کاربر دارای یک مالک انسانی نامدار است. موجودی میتواند با سرعت استخراج حرکت کند، اما وعدهها باید با سرعت نگهدارندهای حرکت کنند که همچنان در پروژه حضور دارد. این سیستم در کنار دفتر کل پیامدها که برای توقف خطاهای خاموش هوش مصنوعی طراحی شده، لایهای جامع از امنیت را برای مستندات فنی فراهم میکند.
گام بعدی شما
- بررسی کنید آیا در مستندات فعلی شما، جملاتی وجود دارد که «تضمین» یا «پشتیبانی» را بدون نام یک مسئول انسانی ادعا میکنند؟
- برای پروژههای متنباز، یک فایل
provenance.jsonساده برای تفکیک حقایق کد از توصیفات مدل ایجاد کنید. - در پرامپتهای تولید مستندات، مدل را مجبور کنید برای هر ادعا یک مسیر فایل (
source path) ارائه دهد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو