مهندسی پرامپت ساختاریافته و تولید خروجی‌های معتبر JSON Schema

چکیده اجرایی: چگونه خروجی مدل‌های هوش مصنوعی را مجبور کنیم دقیقاً مطابق JSON Schema معتبر برگردانند تا کدهای فرانت‌اند و دیتابیس کرش نکنند؟ آموزش فریم‌ورک RCTRF و حذف هالوسینیشن در استخراج اسناد.

۰۱ // کالبدشکافی اصطکاک و سناریوی بازار (Failure Mode)

هالوسینیشن و خروجی‌های نامعتبر متنی به جای JSON تمیز

اگر مدل حین استخراج اطلاعات فاکتور چند کلمه توضیح متنی اضافه کند یا یک کاما را اشتباه بگذارد، کل پایپ‌لاین کدنویسی شما با ارور SyntaxError: Unexpected token از کار می‌افتد.

نشانه‌های بالینی در سازمان‌های سنتی:

کرش کردن ورکر به دلیل دریافت مارک‌داون به جای JSON خام.
اختراع کدهای فیلد جدید توسط مدل که در دیتابیس تعریف نشده‌اند.
عدم تطابق نوع داده (مثلاً برگرداندن قیمت به صورت استرینگ فارسی به جای عدد صحیح).

۰۲ // دیاگرام معماری اتصال داده (Architecture Flow)

STANDARD BLUEPRINT // MERMAID SVG

flowchart TD
    Prompt["پرامپت ساختاریافته RCTRF + اسناد ورودی"] --> Model["مدل هوش مصنوعی بهینه"]
    Model --> Enforcement{"اجبار خروجی ساختاریافته (Structured Output Engine)"}
    Enforcement -->|اعتبارسنجی با JSON Schema سخت‌گیرانه| CleanJSON["خروجی ۱۰۰٪ معتبر JSON بدون هالوسینیشن"]
    CleanJSON --> API["مصرف مستقیم در فرانت‌اند و کوئری SQL"]

flowchart TD
    Prompt["پرامپت ساختاریافته RCTRF + اسناد ورودی"] --> Model["مدل هوش مصنوعی بهینه"]
    Model --> Enforcement{"اجبار خروجی ساختاریافته (Structured Output Engine)"}
    Enforcement -->|اعتبارسنجی با JSON Schema سخت‌گیرانه| CleanJSON["خروجی ۱۰۰٪ معتبر JSON بدون هالوسینیشن"]
    CleanJSON --> API["مصرف مستقیم در فرانت‌اند و کوئری SQL"]

۰۳ // پروتکل اجرایی و استانداردهای میدانی

گام ۱

تدوین پرامپت با فریم‌ورک RCTRF

نقش (Role)، زمینه (Context)، وظیفه (Task)، محدودیت‌ها (Restrictions) و فرمت نهایی (Format).

گام ۲

تعریف اسکیما با استاندارد JSON Schema

مشخص کردن فیلدهای اجباری (required)، نوع فیلدها و ممنوع کردن فیلدهای اضافی با `additionalProperties: false`.

اسکیمای استاندارد استخراج فاکتور سازمانی

JSON

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "invoice_number": { "type": "string" },
    "total_amount_toman": { "type": "integer" },
    "items": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "name": { "type": "string" },
          "qty": { "type": "integer" },
          "unit_price": { "type": "integer" }
        },
        "required": ["name", "qty", "unit_price"],
        "additionalProperties": false
      }
    }
  },
  "required": ["invoice_number", "total_amount_toman", "items"],
  "additionalProperties": false
}

گام ۳

اعتبارسنجی سمت کلاینت با Zod یا Ajv

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

۰۴ // هشدارهای امنیتی و پروداکشن (Production Guardrails)

⚠️ نکات حیاتی اجرای پروداکشن در سازمان‌های ایرانی:

همیشه دمای مدل (Temperature) را برای استخراج داده‌های مالی و حسابداری روی 0 یا 0.1 بگذارید.
پرامپت‌های سیستمی را با گاردریل ضد نشت قفل کنید.

PRONEE_SANDBOX // LAB-04-10

+100 XP READY

⚡ سناریوی چالش میدانی: آزمایشگاه سنجش: اعتبارسنجی خروجی ساختاریافته با JSON Schema

یک شیء JSON خروجی استخراج فاکتور مطابق اسکیمای استاندارد ارسال کنید تا ورکر پرونی صحت آن را بررسی کند.

PAYLOAD_BUFFER // JSON & SQL کلید میانبر: Cmd/Ctrl + Enter

زمان پاسخ: ۰ میلی‌ثانیه

[SYSTEM] Sandboxed evaluation engine initialized.

[TARGET] Ready for: JSON_SCHEMA_VALIDATE