پرش به مطلب اصلی

الگوهای تألیف ایمن با هوش مصنوعی

BDL برای تألیف با کمک هوش مصنوعی طراحی شده است، اما تعریف‌های تولیدشده باید مبتنی بر شواهد، آگاه از قابلیت و با اولویت اعتبارسنجی باشند. این صفحه الگوهای ایمن تولید، تغییر یا استدلال دربارهٔ BDL را برای سامانه‌های هوش مصنوعی تعریف می‌کند.

قاعدهٔ اصلی

هرگز وضعیت بومی برسا را اختراع نکنید. سامانهٔ هوش مصنوعی نباید شناسه‌ها، موجودیت‌ها، فیلدها، فرم‌ها، گردش‌کارها، صفحات یا گروه‌های موجود، قابلیت‌های Runtime یا فرادادهٔ استقرار را جعل کند.

وضعیت نامعلوم باید تا دسترسی به فرادادهٔ معتبر، تعیین‌نشده باقی بماند.

الگوی ۱: تعیین پیش از ارجاع

پیش از تولید مرجع به شیء موجود:

  1. فرادادهٔ لازم را مشخص کنید.
  2. شیء را از فرادادهٔ زندهٔ معتبر تعیین کنید.
  3. هویت و دامنه را تأیید کنید.
  4. تنها پس از آن مرجع BDL را تولید کنید.

هویت داخلی را فقط از عنوان نمایشی یا نام خواندنی برای انسان استخراج نکنید.

الگوی ۲: بررسی هر چهار لایهٔ قابلیت

برای هر ویژگی مهم این موارد را تفکیک کنید:

  1. Native Barsa — آیا برسا آن را پشتیبانی می‌کند؟
  2. Runtime Support — آیا Runtime می‌تواند آن را اجرا کند؟
  3. BDL Expressibility — آیا BDL می‌تواند آن را توصیف کند؟
  4. BDL Authoring Availability — آیا سطح فعلی تألیف مجاز به تولید آن است؟

این پرسش‌ها را در یک فرض واحد supported خلاصه نکنید.

الگوی ۳: تولید کوچک‌ترین تعریف معتبر

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

الگوی ۴: حفظ مقادیر تعیین‌نشده

وقتی مقادیر وابسته به استقرار نامعلوم‌اند، آن‌ها را صریح و تعیین‌نشده نگه دارید. نمونه:

{
"systemId": "${RESOLVE_SYSTEM_ID}"
}

جای‌نگهدار تعیین‌نشده از شناسهٔ حدسی ایمن‌تر است.

الگوی ۵: تشخیص به‌جای ساختن اطلاعات

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

  • نبود شناسهٔ بومی
  • فرادادهٔ نامعلوم فیلد
  • عملیات تألیف پشتیبانی‌نشده
  • قابلیت تأییدنشدهٔ Runtime
  • شیء هدف مبهم
  • محدودیت شناخته‌شدهٔ مؤثر بر تألیف بدون اتلاف

الگوی ۶: اعتبارسنجی پیش از تغییر

BDL تولیدشده باید پیش از هر تغییر بومی مراحل اعتبارسنجی را بگذراند. روند مورد انتظار:

  1. تجزیه
  2. تعیین فرادادهٔ زنده
  3. Preflight
  4. اعتبارسنجی یا کامپایل
  5. ساخت طرح اجرا
  6. بازبینی پیام‌های تشخیصی مسدودکننده
  7. تأیید
  8. اجرا
  9. بررسی پس از اجرا
  10. تطبیق

الگوی ۷: کنترل کد سیستم

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

الگوی ۸: حفظ زمینهٔ نسخه

سامانه‌های هوش مصنوعی باید ابعاد مستقل نسخه را صریح نگه دارند. نسخهٔ زبان BDL، نسخهٔ مبنای دانش، نسخهٔ قرارداد بومی، نسخهٔ بستهٔ Runtime و نسخهٔ سایت مستندات را یک نسخهٔ مشترک ندانید.

الگوی ۹: رعایت محدودیت‌های شناخته‌شده

محدودیت‌های شناخته‌شده بخشی از قرارداد معتبر هستند. هوش مصنوعی نباید با اختراع نحو پشتیبانی‌نشده یا فرض رفتار بدون اتلاف، محدودیت را بی‌سروصدا دور بزند. اگر محدودیتی بر درخواست اثر دارد، آن را صریحاً نشان دهید.

الگوی ۱۰: بررسی وضعیت بومی پس از اجرا

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

الگوهای ناایمن

از این رفتارها پرهیز کنید:

  • حدس شناسه‌ها
  • استنباط نام داخلی از عنوان نمایشی
  • فرض اینکه حضور در مدل به معنای دسترس‌پذیری تألیف است
  • تضمین‌دانستن پشتیبانی Runtime از روی نحو BDL
  • تولید زیرسیستم بزرگ پیش از اعتبارسنجی پایه‌ها
  • استفاده از کد سیستم برای دورزدن ساختارهای پشتیبانی‌نشده
  • نادیده‌گرفتن محدودیت‌های شناخته‌شده
  • ترکیب بی‌سروصدای نسخه‌های مبنا

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

این الگو BDL تولیدشده را قابل ممیزی، قابل توضیح و برای اجرا ایمن‌تر نگه می‌دارد.