۵ تصمیم مهندسی برای حذف توهمات هوش مصنوعی در گزارش‌های تغییرات گیت

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

به نقل از سازنده Patchlog، در ۱ اوت ۲۰۲۶ ثابت شد که شکست‌های واقعی در ادغام مدل‌های زبانی بزرگ (LLM) ناشی از دانه‌بندی خروجی (Output Granularity)، سیاست‌های نگهداری داده (Retention Policies) و نحوه دریافت اطلاعات (Data Ingestion) است. این یافته‌ها در جریان توسعه ویژگی جدیدی برای Patchlog به دست آمد. پچ‌لاگ در واقع یک ویجت گزارش تغییرات (Changelog) برای سرویس‌های SaaS کوچک است. ویژگی مورد نظر، Pushهای گیت‌هاب را به پیش‌نویس‌های گزارش تغییرات برای کاربران طرح Pro تبدیل می‌کند.

بسیاری از توسعه‌دهندگان با هوش مصنوعی مانند یک جعبه جادویی برخورد می‌کنند که در آن یک پرامپت بهتر مستقیماً برابر با محصول بهتر است. اما در واقعیت، قابلیت اطمینان سیستم به کدِ پوششی (Wrapper Code) بستگی دارد که مدیریت می‌کند مدل چه داده‌هایی را می‌بیند و در مواجهه با پاسخ‌های بد، چگونه واکنش نشان می‌دهد. این رویکرد، تمرکز را از «پرامپت‌نویسی» به تعریف یک «قرارداد نرم‌افزاری صلب» (Rigid Software Contract) تغییر می‌دهد. همان‌طور که نویسنده اشاره می‌کند، گذراندن یک هفته کامل روی یک پرامپت و کشف اینکه اصلاً پرامپت بخش ریسکی پروژه نبوده است، یکی از تله‌های رایج در صنعت است.

با تکیه بر پوشش‌های قبلی ما درباره خط لوله‌های RAG و اینکه چگونه بازیابی دانش خارجی توهمات را کاهش می‌دهد، این پیاده‌سازی نشان می‌دهد که اعتبارسنجی سخت‌گیرانه خروجی برای AI در سطح تولید (Production-grade) به همان اندازه حیاتی است. این رویکرد با اولویت‌بندی پایداری در گیت‌های استقرار مدل‌ها هم‌سو است تا ریسک عرضه مدل‌های معیوب به حداقل برسد. در حالی که RAG داده‌های درست را فراهم می‌کند، یک اعتبارسنج (Validator) تضمین می‌کند که هوش مصنوعی فرمت‌بندی‌هایی را اختراع نکند که ماهیت رباتیک آن را برملا کند. هدف این است که LLM از یک «عامل خلاق» به یک «مؤلفه پیش‌بینی‌پذیر» با ورودی و خروجی تعریف‌شده تبدیل شود.

مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در این سیستم دیگر اجازه ندارد هر چه می‌خواهد بنویسد.

معماری تولید قابل‌اطمینان

به جای تولید یک مورد گزارش تغییرات برای هر Push تک‌گانه در گیت، Patchlog از یک «ضرب‌آهنگ بافری» (Buffered Cadence) استفاده می‌کند. طراحی بدیهی — یعنی تولید گزارش در لحظه رسیدن هر Push — به دو دلیل اساسی نقص دارد: حجم زیاد و نبود زمینه (Context).

• حجم: یک روز کاری عادی در محیط توسعه پر از نویزهایی مثل «اصلاح غلط املایی» (fix typo)، «کار در جریان» (wip) یا «اصلاح واقعی» (actually fix it) است. تولید یک مورد برای هر Push، منجر به ایجاد ۲۰ پیش‌نویس در روز می‌شود؛ این یعنی یک صف بررسی که هیچ کاربری هرگز آن را باز نخواهد کرد.
• زمینه: یک ویژگی (Feature) واحد معمولاً در چندین Push مختلف تکمیل شده و ارسال می‌شود. اگر تولید گزارش برای هر Push انجام شود، مدل هرگز شکل کلی تغییرات را نمی‌بیند. نتیجه این می‌شود که مدل به جای یک توصیف منسجم از یک ویژگی، سه توصیف ناقص و نصفه از یک چیز واحد می‌نویسد.

با بافر کردن Pushها و اجرای فرآیند تولید بر اساس زمان‌بندی تعریف‌شده توسط کاربر — که می‌تواند برای مخازنی با ارسال‌های مداوم «ساعتی» و برای پروژه‌های جانبی «هفتگی» باشد — مدل می‌تواند شکل کامل کار را مشاهده کند. زمان‌بند (Scheduler) را به گونه‌ای تنظیم کرده‌اند که بیشتر از کوتاه‌ترین بازه زمانی تیک بزند تا تضمین شود تنظیمات «ساعتی» به طور مخفیانه به معنای «تا یک ساعت تأخیر» نباشد.

این جداسازی همچنین مانع از توقف (Hanging) خط لوله‌های CI/CD می‌شود. فرآیند دریافت داده (Ingestion) باید سریع باشد، زیرا یک مرحله در CI منتظر پاسخ HTTP است. از آنجا که تولید متن توسط مدل دقایقی زمان می‌برد، قرار دادن این دو در یک درخواست واحد باعث می‌شود شغل CI در انتظار مدل زبانی متوقف شود. با ایجاد این شکاف (Seam)، دریافت داده‌ها آنی باقی می‌ماند و تولید متن به صورت غیرهمزمان (Asynchronous) رخ می‌دهد.

تطبیق طرح‌واره با دانه‌بندی

این سیستم از درخواست‌های کلی مانند «کارهای این هفته را خلاصه کن» پرهیز می‌کند. چنین درخواست‌هایی معمولاً یک توده متن تولید می‌کنند که بیشتر شبیه به یک «گزارش وضعیت» (Status Report) است. اما کاربران برای گزارش وضعیت مشترک نمی‌شوند. در عوض، خروجی مستقیماً روی طرح‌واره (Schema) موجود در پایگاه داده نگاشت می‌شود.

جزئیات دانه‌بندی:

• قرارداد: مدل موظف است N مورد تولید کند، به گونه‌ای که هر مورد دقیقاً به یک تغییر کاربر-محور (User-facing change) متناظر باشد.
• دسته‌بندی: هر مورد باید دقیقاً در یکی از چهار دسته قرار گیرد: ویژگی (Feature)، اصلاح (Fix)، بهبود (Improvement) یا امنیت (Security). هر یک از این‌ها در رابط کاربری (UI) به صورت یک آیتم با یک نشان (Badge) خاص نمایش داده می‌شود.
• خوشه‌بندی: مدل صراحتاً دستور می‌گیرد که کامیت‌های مرتبط را در یک مورد منطقی تجمیع (Cluster) کند، به جای اینکه تک‌تک کامیت‌ها را لیست کند.

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

مدیریت حالت «موفقیت خالی» (Empty Success)

یکی از بزرگ‌ترین عوامل ایجاد نویز در AI، اکراه مدل در بازگرداندن «هیچ» است. اگر یک هفته کاری فقط شامل ارتقای وابستگی‌ها (Dependency bumps)، بازسازی کد (Refactors)، اصلاحات CI و تغییرات تست باشد، پاسخ درست یک «لیست خالی» است. اما بدون دستورالعمل‌های صریح، LLMها اغلب جملاتی کلی مانند «بهبود عملکرد و پایداری» را توهم می‌کنند، صرفلاً به این دلیل که بازگرداندن هیچ‌چیز را برای خود مدل به عنوان یک شکست تلقی می‌کنند.

برای مقابله با این موضوع، قرارداد سیستم مقدار {"entries": []} را به عنوان یک حالت موفقیت درجه‌یک تعریف می‌کند. پرامپت صراحتاً بیان می‌کند که این یک پاسخ درست و مورد انتظار است. مهم‌تر از همه، پرامپت هشدار می‌دهد که اختراع یک مورد برای فرار از نتیجه خالی، بدتر از خودِ نتیجه خالی است. این منطق در هر ویژگی استخراج یا خلاصه‌سازی کاربرد دارد: تعریف پاسخ خالی به عنوان یک خروجی معتبر، مانع از تبدیل «نبود سیگنال» به «نویز» می‌شود.

قوانین سخت‌گیرانه در کد (Code-Enforced House Rules)

قوانین مبتنی بر پرامپت صرفاً «ترجیحات» هستند؛ اما اعتبارسنج‌های کد-محور «الزامات»‌اند. برای حذف «نشانه‌های رباتیک» (AI tell) — به‌ویژه استفاده از خط تیره بلند (em dash) و خط تیره کوتاه (en dash) که نشانه‌های بسیار شناخته‌شده متن‌های تولید شده توسط AI هستند — Patchlog از یک اعتبارسنج سخت (Hard Validator) استفاده می‌کند. از آنجا که این پیش‌نویس‌ها تبدیل به متون عمومی در وب‌سایت مشتریان می‌شوند، رعایت این قوانین باید مطلق باشد.

اگر یک کاراکتر ممنوعه شناسایی شود، سیستم مسیر بازیابی صلب زیر را طی می‌کند:

• رد کامل (Full Rejection): کل پاسخ رد می‌شود، نه فقط آن مورد بد. این کار باعث می‌شود وضعیت سیستم ساده بماند؛ زیرا ذخیره کردن سه مورد از چهار مورد، کاربر انسانی را مجبور می‌کند حدس بزند کدام مورد گم شده و چرا.
• تلاش مجدد مستدل (Reasoned Retry): سیستم یک بار دیگر تلاش می‌کند و دلیل دقیق رد را به مدل بازمی‌گرداند: «پاسخ قبلی شما رد شد: یک عنوان حاوی خط تیره (em dash) بود. آن را اصلاح کرده و دوباره پاسخ دهید». این روش بسیار مؤثرتر از ارسال مجدد همان پرامپت بدون تغییر است.
• شکست سخت (Hard Failure): اگر تلاش دوم نیز شکست بخورد، کل عملیات با شکست مواجه شده و هیچ‌چیز تولید نمی‌کند. از دست دادن یک اجرا، ترجیح داده می‌شود تا ارسال متنی که قوانین را نقض کرده است.

این طراحی از روش‌های «جستجو و جایگزینی» (Find and Replace) اجتناب می‌کند. جایگزین کردن یک خط تیره با کاما، ریتم رباتیک متن را حفظ می‌کند؛ تنها راه حفظ کیفیت، درخواست بازنویسی کامل یا حذف کامل پاسخ است. این سطح از دقت در پیاده‌سازی ضروری است، زیرا بسیاری از آزمون‌های سخت‌گیرانه کدنویسی نشان می‌دهند که خطاهای فنی کوچک می‌توانند منجر به شکست کامل سیستم در دنیای واقعی شوند.

حریم خصوصی و نگهداری داده‌ها

از آنجا که گزارش‌های تغییرات باکیفیت نیاز به خواندن Diffهای کد دارند تا پیام‌هایی مثل «اصلاح چیزها» (fix stuff) را درک کنند، سیستم با کد منبع به عنوان یک «بدهی موقت» (Temporary Liability) برخورد می‌کند. این موضوع به جای یک پاراگراف ساده در سیاست حریم خصوصی، به عنوان یک تصمیم معماری فنی پیاده شده است.

مکانیزم‌های نگهداری:

• استثنائات پیش از ارسال (Pre-transmission Exclusions): استثنائات در مرحله CI و قبل از خروج هرگونه داده از مخزن اعمال می‌شوند تا تضمین شود مسیرهای استثنا شده هرگز منتقل نمی‌شوند.
• حذف تراکنشی (Transactional Deletion): Diffها تنها تا زمانی ذخیره می‌شوند که یک اجرا (Run) آن‌ها را مصرف کند؛ سپس در همان تراکنشی که پیش‌نویس‌ها را می‌نویسد، مقدار آن‌ها به null تغییر می‌یابد.
• پاک‌سازی ایمنی (Safety Sweeps): یک فرآیند پاک‌سازی، Diffهای مربوط به اجراهایی که هرگز به پایان نرسیدند را null می‌کند تا کد منبع به دلیل شکست در تولید متن، در سیستم باقی نماند.
• ردپاهای بازرسی (Audit Trails): تنها پیام‌های کامیت و آمارها نگه داشته می‌شوند، زیرا حاوی کد منبع نیستند و ردپای لازم برای شناسایی منبع هر پیش‌نویس را فراهم می‌کنند.

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

این چارچوب عملیاتی با LLM به عنوان یک مؤلفه با ورودی، خروجی و حالت شکست تعریف‌شده برخورد می‌کند. تیم‌هایی که صرفاً به پرامپت تکیه می‌کنند، در نهایت سیستمی بر اساس «نظر و گمان» خواهند داشت؛ اما کسانی که قرارداد را از طریق کد تحمیل می‌کنند، واقعاً می‌توانند محصول خود را به محیط تولید (Production) ارسال کنند.

گام بعدی شما

• اگر از LLM برای تولید داده‌های ساختاریافته استفاده می‌کنید، به جای تکیه بر پرامپت، یک لایه اعتبارسنجی (Validator) در کد بنویسید که خروجی‌های غیرمنطبق را کاملاً رد کند.
• برای کاهش توهمات در خلاصه‌سازی، حالت «پاسخ خالی» را به عنوان یک خروجی موفق تعریف کنید تا مدل مجبور به تخیله نشود.
• در سیستم‌های اتوماسیون، تولید متن را از دریافت داده (Ingestion) جدا کنید تا سرعت CI/CD شما تحت تأثیر تأخیر مدل قرار نگیرد.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.