«دفتر ثبت حقایق»؛ راهکاری برای جلوگیری از اختراع واقعیت توسط AI

یک عدد اشتباه در راهنمای نصب می‌تواند اعتماد کاربر را به‌طور کامل نابود کند و هزینه‌های گزافی برای اصلاح عمومی به بار آورد. شرکت MonkeyCode برای حل این مشکل، تفکیکی عملیاتی را پیشنهاد می‌دهد که مانع از آن می‌شود مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیارد‌ها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — حقایق محصول را از خودشان اختراع کنند.

بسیاری از تیم‌ها با تولید مستندات توسط هوش مصنوعی، آن را صرفاً یک مسئلهٔ مربوط به لحن و جریان متن می‌بینند و تمرکز خود را بر روی روان بودن جملات می‌گذارند. اما شکست واقعی در «شکاف مالکیت» رخ می‌دهد؛ جایی که ادعاهای فنی — مانند سهمیه‌های API یا مرزهای امنیتی — هرگز به شخص مشخصی واگذار نمی‌شوند. این وضعیت منجر به «رانش داده‌ها» (Drift) می‌شود؛ یعنی صفحه‌ای که ظاهرش کامل است، اما حاوی ادعاهایی است که با کد فعلی محصول همخوانی ندارد و سرعت تغییر این ادعاها با سرعت تغییر کد متفاوت است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تکیه بر خروجی مدل بدون لایه‌ی اعتبارسنجی، ریسک عملیاتی را افزایش می‌دهد. در مستندات فنی، صفحات نصب معمولاً ترکیبی از دستورات محلی و ادعاهای محصول هستند. این دو نوع جمله با سرعت‌های متفاوتی قدیمی می‌شوند. دستورات محلی را می‌توان با یک کامیت (Commit) مشخص در مخزن کد تأیید کرد. در مقابل، سهمیه‌ها و پیشنهادهای سرور خارج از آن کامیت تغییر می‌کنند. این چالش شباهت زیادی به خطرات اعتبارسنجی در تست‌های نرم‌افزاری دارد، چرا که تکیه بر خروجی‌های AI بدون متغیرهای تغییرناپذیر می‌تواند منجر به شکست در تأیید کدهای محیط عملیاتی شود.

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

طبق گزارشی که در ۸ اکتبر ۲۰۲۶ منتشر شد، راهکار این است که ادعاهای بدون مالک، به‌جای ممنوعیت ابزارهای AI، به‌عنوان «نقص‌های بازبینی» تلقی شوند. سازوکار اصلی در اینجا یک «دفتر ثبت» (Register) است که مالکیت هر داده را پیش از پذیرش حتی یک پاراگراف در شاخه (Branch) کد، تعیین می‌کند.

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

محتوای قابل تولید توسط مدل:

• ساختار سرفصل‌ها و ترتیب بخش‌ها (به شرطی که هیچ حقیقت محصولی در داخل سرفصل‌ها نباشد).
• توضیح کدهایی که در مخزن موجود است، به شرط ارجاع دقیق به یک مسیر (Path) و تأیید مسیر و کامیت توسط بازبین.
• دستوراتی که به‌عنوان «پیشنهاد اجرا نشده» با یک برچسب پیشنهاد مشخص شده‌اند. در اینجا انسان تصمیم می‌گیرد که آیا آن‌ها را اجرا کند یا خیر و اطمینان حاصل می‌کند که این دستورات به‌عنوان نتایج اندازه‌گیری شده ارائه نشوند.

محتوای تحت مالکیت انسان:

• نسخه‌های دقیق (Version Pins)، نام APIها و پرچم‌های پیش‌فرض. این موارد باید مستقیماً از مخزن یا مستندات بالادستی نقل شوند.
• هرگونه بیانیه مربوط به در دسترس بودن سرویس که کاربر ممکن است به آن تکیه کند.

محتوای مسدود شده (Blocked):

• سهمیه‌ها (Quotas)، مدت‌زمان، سخت‌افزار و قیمت؛ این موارد باید یک منبع اولیه به‌روز داشته باشند یا به‌طور کامل حذف شوند.
• مرزهای امنیتی و نحوه مدیریت داده‌ها. انسان باید نام کنترل امنیتی و مالک آن را مشخص کند.
• رتبه‌بندی‌ها و عبارات مربوط به پایداری و همیشگی بودن. بازبین‌ها باید هرگونه مقایسه بدون پشتوانه را رد کنند.

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

برای درک بهتر، سه جمله در یک راهنمای نصب برای یک ابزار میزبانی شده را بررسی کنیم:
۱. جمله‌ای که لیست فایل‌های محلی را می‌آورد که کاربر باید ویرایش کند. این جمله قابل تولید توسط AI است، مشروط بر اینکه مسیرها در کامیت تثبیت شده موجود باشند.
۲. جمله‌ای که بیان می‌کند یک گزینه سرور رایگان وجود دارد. این جمله تحت مالکیت انسان می‌ماند تا زمانی که URL مستندات فعلی در ردیف ثبت شود.
۳. جمله‌ای که مقدار توکن‌ها را نام می‌برد. این مورد مسدود است تا زمانی که یک منبع اولیه در روز انتشار، آن مقدار را تأیید کند.

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

برای پیاده‌سازی این روش، تیم‌ها باید توالی شش‌گانه زیر را دنبال کنند تا هزینه تولید پایین و نرخ خطا نزدیک به صفر بماند. هرگز از مدل درخواست نثر نکنید تا زمانی که ردیف‌های دفتر ثبت ایجاد شده باشند:

۱. تثبیت منبع: ثبت کامیت مخزن، مسیر مستندات و تمام صفحات محصولی که انسان به آن‌ها ارجاع می‌دهد.
۲. استخراج جملات: استخراج جملات کاندید به‌گونه‌ای که هر ادعا در یک خط قرار گیرد تا بتواند پیش از تولید متن، مهر مالکیت دریافت کند.
۳. طبقه‌بندی مسیرها: برچسب‌گذاری هر خط به عنوان model_draft (پیش‌نویس مدل)، human_own (مالکیت انسان) یا blocked (مسدود) و اتصال منبع به هر حقیقت انسانی فعلی.
۴. تولید بخش‌های باز: درخواست سرفصل‌ها، جملات انتقالی و مثال‌های برچسب‌دار به AI و سپس جایگذاری بدون تغییر خطوط تثبیت‌شده انسانی.
۵. مقایسه (Diff): رد کردن صفحه در صورتی که یک ادعای مسدود ظاهر شود یا یک خط مالکیت انسانی بازنویسی (Paraphrase) شده باشد.
۶. تأیید انسانی: الزام به امضای شخصی که بتواند از حقایق محصول دفاع کند. خروجی مدل باید تا زمان این تأیید، به‌عنوان «پیش‌نویس» علامت‌گذاری شود.

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

برای مقیاس‌پذیری، این گردش‌کار شامل یک بررسی‌کننده مبتنی بر پایتون است. این اسکریپت یک فایل JSON (دفتر ثبت) و یک پیش‌نویس Markdown را می‌خواند و اگر زبان‌های محصول بدون مالک — مانند کلماتی چون «سهمیه» (Quota)، «GPU»، «SLA»، «همیشگی» (Permanent)، «نامحدود» (Unlimited) یا «بنچ‌مارک» (Benchmark) — خارج از خطوط مهرشده ظاهر شوند، با وضعیت غیرصفر (خطا) خارج می‌شود. این رویکرد برای جلوگیری از توهمات مدل در گزارش‌های فنی است، مشابه آنچه در متدولوژی‌های جدید برای جلوگیری از دروغ‌گویی مدل‌ها در بنچ‌مارک‌های کیفیت دنبال می‌شود.

این بررسی‌کننده صرفاً یک دروازه رشته‌ای (String Gate) است. این ابزار تضمین می‌کند که اگر یک خط مالکیت انسانی گم شده یا یک خط مسدود حضور داشته باشد، ادغام (Merge) متوقف شود. خروجی صفر تنها به این معناست که رشته‌های اسکن شده با دفتر ثبت مطابقت داشتند، نه اینکه ادعاها لزوماً درست باشند. بررسی لینک‌ها، اجرای مثال‌ها و بازبینی حقوقی همچنان دروازه‌های جداگانه‌ای هستند.

ساختار دفتر ثبت باید به‌گونه‌ای باشد که بازبین بتواند تمام جملات مالکیت‌دار را در یک دور بازبینی بخواند. هر ردیف باید شامل مسیر، جمله دقیق که انسان از آن دفاع می‌کند و منبعی که مهر تأیید را توجیه می‌کند باشد.

مثال از ساختار دفتر ثبت:

{
  "commit": "REPLACE_WITH_REVIEWED_SHA",
  "claims": [
    {
      "id": "avail-1",
      "lane": "human_own",
      "text": "Operator-stated options are free model access and a free server option.",
      "source": "REPLACE_WITH_CURRENT_PRODUCT_DOC_URL"
    },
    {
      "id": "quota-1",
      "lane": "blocked",
      "text": "The free tier includes a fixed token quantity.",
      "source": null
    }
  ]
}

برای اجرای بررسی‌کننده از ریشه مخزن دستورات زیر را بزنید:
mkdir -p tools docs
python3 tools/doc_ownership_check.py docs/register.json docs/setup.md

یک انتظار اجرا نشده، خروجی غیرصفر است زمانی که باقی‌مانده پیش‌نویس حاوی کلمه «quota» خارج از یک خط مالکیت انسانی باشد. پیش‌نویسی که فقط خطوط مهرشده را تکرار کند و از لیست ممنوعه در سایر بخش‌ها بپرهیزد، باید خط تأیید (Pass) را چاپ کند.

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

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

محدودیت این روش در این است که یک «دروازه رشته‌ای» است؛ یعنی اگر یک ادعای مسدود را با کلمات متفاوت (Paraphrase) بنویسید و کلمات ممنوعه را حذف کنید، ممکن است از فیلتر رد شود. این ابزار مثال‌ها را اجرا نمی‌کند، لینک‌ها را تأیید نمی‌کند و ثابت نمی‌کند که صفحه ارجاع شده هنوز با دفتر ثبت دیروز مطابقت دارد. تیم‌ها نباید اجرای موفق این ابزار را به‌عنوان گواهینامه انطباق، بازبینی امنیتی یا جایگزینی برای خواندن متن تلقی کنند. نویسندگانی که نمی‌توانند یک مالک انسانی برای ادعای در دسترس بودن نام ببرند، باید آن ادعا را حذف کنند به‌جای آنکه سعی کنند با تغییر کلمات دور آن بزنند.

البته این سطح از سخت‌گیری برای همه صفحات لازم نیست. در موارد زیر می‌توان از دفتر ثبت صرف‌نظر کرد:

• لاگ‌های شخصی: صفحاتی که حاوی حقایق محصولی نیستند که غریبه‌ها به آن تکیه کنند. در این حالت، دفتر ثبت فقط تشریفات اضافه است بدون اینکه ریسک را کاهش دهد.
• متون حقوقی/امنیتی: محتوایی که باید مستقیماً از مشاوران حقوقی بیاید، زیرا مسیر مستندات فنی مالک مناسبی برای مسئولیت‌های حقوقی نیست.
• صفحات صرفاً بازاریابی: زمانی که تنها هدف به حداکثر رساندن ذکر نام یک ابزار است، زیرا صفحه باید بدون آن ذکرها نیز مفید باقی بماند.

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

این تغییر، نقش هوش مصنوعی را از «منبع مرجع» به «محیط پیش‌نویس» تغییر می‌دهد. با تفکیک لایه حقایق از لایه نثر، تیم‌ها می‌توانند از سرعت هوش مصنوعی زاینده (Generative AI) استفاده کنند بدون اینکه عادت مدل به اختراع جزئیات برای «کامل به نظر رسیدن» متن را به ارث ببرند.

این رویکرد به سمت «مستندسازی رسمی» حرکت می‌کند. اکنون بازبین‌ها به‌جای ویرایش سبک، روی «منشأ داده‌ها» (Provenance) تمرکز می‌کنند. معیار موفقیت یک صفحه دیگر روانی متن نیست، بلکه تعداد ادعاهای بدون مالک در آن است.

منتظر ادغام این دفاتر ثبت در خط لوله‌های CI/CD باشید، جایی که مستندات پیش از استقرار با اسکیماهای زنده API اعتبارسنجی می‌شوند.

گام بعدی شما

• لیست کلمات حساس محصول خود (مانند قیمت، سهمیه و محدودیت‌ها) را استخراج کرده و آن‌ها را در یک لیست «ممنوعه برای AI» قرار دهید.
• برای مستندات حساس، یک فایل JSON ساده برای ثبت مالکیت جملات کلیدی ایجاد کنید تا پیش از تولید متن، منبع هر ادعا مشخص باشد.
• اسکریپت‌های ساده‌ای برای چک کردن وجود کلمات کلیدی در پیش‌نویس‌های AI بنویسید تا از ورود ادعاهای بدون منبع جلوگیری کنید.