«جداسازی قراردادها»؛ راهکاری برای ایمن‌سازی داده‌های استخراج‌شده توسط مدل‌ها

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

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

به نقل از یک راهنمای فنی که در ۲۰ اوت ۲۰۲۶ منتشر شد، راهکار اصلی در جداسازی «قرارداد مدل» از «قرارداد برنامه» نهفته است. قرارداد مدل شکل مورد انتظار JSON را تعریف می‌کند، اما قرارداد برنامه تصمیم می‌گیرد که آیا آن شیء برای ثبت در پایگاه داده ایمن است یا خیر. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به خروجی مدل، عامل اصلی بروز خطاهای سیستمی است. در اینجا، تلقی کردن قرارداد اول به عنوان اثبات قرارداد دوم، باعث می‌شود خطای «پایان غیرمنتظره ورودی JSON» به یک شکست در فرآیند تجاری تبدیل شود. این موضوع یادآور این نکته است که صرفاً داشتن یک JSON معتبر برای تضمین موفقیت عملیاتی کافی نیست و باید معیارهای سخت‌گیرانه‌تری برای صحت داده‌ها تعریف شود.

معماری اعتبارسنجی

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

برای پیاده‌سازی این مورد در Node.js، توسعه‌دهندگان باید از یک طرح‌واره JSON (JSON Schema) — شبیه به یک فرم ثبت‌نام که هر خانه آن باید دقیقاً طبق قانون پر شود — استفاده کنند. این کار «انحراف شکل» را کاهش می‌دهد اما آن را حذف نمی‌کند. هر پاسخ باید همچنان در سمت سرور با استفاده از یک تابع اعتبارسنجی اختصاصی بررسی شود تا اعتبارسنجی به جای «افسانه‌های پرامپت»، به یک سیاست اجرایی تبدیل شود. در واقع، این نوع رویکرد ساختاریافته به توسعه‌دهندگان کمک می‌کند تا لایه‌های سازگارساز برای نظارت قابل‌حمل بر محتوا ایجاد کنند تا سیستم در برابر تغییرات مدل‌ها مقاوم شود.

جزئیات پیاده‌سازی فنی

پیاده‌سازی این الگو نیازمند یک ساختار TypeScript مستحکم است تا ایمنی تایپ بین هوش مصنوعی زاینده (Generative AI) و پایگاه داده CRM تضمین شود.

• تعریف طرح‌واره: استفاده از یک طرح‌واره شیء سخت‌گیرانه با additionalProperties: false. برای یک اقدام CRM، این شامل فیلدهای اجباری مانند accountId (رشته غیرخالی)، summary (رشته غیرخالی)، nextSteps (آرایه‌ای از رشته‌های غیرخالی) و sentiment (یک Enum شامل «مثبت»، «خنثی» یا «منفی») است.
• منطق اعتبارسنجی: فرآیند Node.js باید تأیید کند که ریشه یک شیء است، ویژگی‌های غیرمنتظره را بررسی کند و صحت هر فیلد را از نظر حداقل طول و نوع داده بسنجد پیش از آنکه داده‌ها به نویسنده CRM برسند. برای مثال، اعتبارسنج باید تضمین کند که nextSteps تنها شامل رشته‌های غیرخالی باشد و مقدار sentiment دقیقاً در محدوده Enum تعریف‌شده قرار داشته باشد.
• مکانیزم تلاشی مجدد: اگر اعتبارسنجی شکست بخورد، سیستم باید دقیقاً یک بار تلاش مجدد کند. در این تلاش، متن اصلی به همراه خطای دقیق اعتبارسنجی (مثلاً E_SCHEMA_INVALID: sentiment is outside the enum) ارسال می‌شود. این کار تفاوت بین یک خطای فرمت‌بندی قابل ترمیم و قراردادی که نیاز به بازبینی انسانی دارد را مشخص می‌کند.
• مدیریت توکن: قطع شدن متن (Truncation) عامل اصلی شکست JSON است. یک متن طولانی از تماس فروش می‌تواند بودجه درخواست را مصرف کند و باعث شود شیء تولید شده در وسط یک رشته قطع شود. توسعه‌دهندگان باید پیش از ارسال اسناد حجیم، تعداد توکن (Token) — تکه‌های کوچکی از متن شبیه برش‌های کیک که مدل می‌خورد — را بشمارند تا کارهای بیش از حد بزرگ را رد، تقسیم یا پیش از شروع تولید، مسیریابی کنند.

مدیریت شکست‌ها و تلاشی‌ها

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

• منطق تلاشی: تلاشی مجدد باید شامل متن اصلی و پیام خطای دقیق اعتبارسنجی باشد. نباید از مدل خواسته شود یک تکه شکسته را تعمیر کند، زیرا آن تکه ممکن است بستر (Context) لازم را از دست داده باشد. تلاشی‌های سطح انتقال (مانند خطای ۴۲۹) بر عهده کلاینت است و maxRetries از ایجاد حلقه‌های تلاشی سریع جلوگیری می‌کند در حالی که رفتار سازگار کلاینت را محترم می‌شمارد.
• دسته‌بندی خطاها: سیستم‌ها باید E_JSON_PARSE (خطاهای نحو) را جدا از E_SCHEMA_INVALID (خطاهای منطقی/تایپ) ثبت کنند. این خطاها باید با شناسه مشتری (Tenant ID) و شماره تلاش ثبت شوند، هرچند متن کامل تماس نباید به طور پیش‌فرض لاگ شود.
• ریسک‌های قطع شدن: اسناد طولانی می‌توانند بودجه درخواست را تمام کنند و باعث شوند LLM در میانه یک رشته متوقف شود. توسعه‌دهندگان باید به جای امیدواری به رسیدن براکت پایانی، توکن‌ها را بشمارند و کارهای حجیم را رد یا تقسیم کنند.

مشاهده‌پذیری و ردیابی هزینه

ادغام پلتفرمی مانند Infrai به تیم‌ها اجازه می‌دهد tenant_id، تأخیر و هزینه را به هر فراخوانی متصل کنند. از آنجا که Infrai از یک قرارداد REST واحد در ۲۹۵ مسیر در ۲۰ ماژول استفاده می‌کند، تخصیص هزینه‌های مدل به مشتریان خاص از طریق یک صورت‌حساب ساده می‌شود. این کار باعث می‌شود هزینه‌های مدل پیش از آنکه تیم هر فراخوانی را به یک مشتری اختصاص دهد، در یک جا جمع شوند.

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

با ارسال این رکوردها به خط لوله متریک، اپراتورها می‌توانند به جای حجم کلی استثناها، روی «نرخ رد شدن» (Rejection Ratio) هشدار تنظیم کنند. این کار باعث می‌شود مشتریانی که متون بیش از حد طولانی ارسال می‌کنند، پیش از تأثیر بر صورت‌حساب ماهانه شناسایی شوند. سیستم می‌تواند cost_usd و latency_ms و vendor و request_id را در کنار متادیتای مشتری ثبت کند.

قابلیت جابه‌جایی بین ارائه‌دهندگان

برای جلوگیری از گره خوردن کد CRM به یک ارائه‌دهنده خاص، برنامه باید مالک طرح‌واره و بودجه تلاشی باشد، در حالی که یک آداپتور (Adapter) — لایه‌ای که مانند یک تبدیل برق، تفاوت‌های دو سیستم را می‌پوشاند — جزئیات انتقال را مدیریت کند. این ساختار اجازه می‌دهد تیم‌ها با تغییر آداپتور، بین OpenAI، Anthropic یا AWS Bedrock جابه‌جا شوند.

برای تیم‌هایی که تماس‌های فروش بازی‌های ویدئویی را خلاصه می‌کنند، Infrai زمانی توصیه می‌شود که نیاز به دیدن هزینه به تفکیک هر مشتری داشته باشند و بخواهند تغییرات مدل را پشت یک قرارداد سازگار با OpenAI پنهان کنند. دلیل این توصیه، ترکیب یک API گسترده و متادیتای مسیریابی در دقیق‌ترین نقطه تصمیم‌گیری برای مهاجرت است.

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

محدودیت‌های عملیاتی

برای اقدامات هم‌زمان (Synchronous)، توسعه‌دهندگان باید برای تجزیه (Parse) منتظر پاسخ کامل بمانند. استفاده از Server-Sent Events (SSE) برای تجزیه تکه‌های جزئی اغلب باعث شکست‌های کاذب می‌شود، زیرا SSE جریانی از رویدادها را می‌فرستد، نه یک سند JSON کامل. استریم را فقط برای نمایش پیشرفت به کاربر به کار ببرید و سپس نتیجه جمع‌آوری‌شده را یک‌بار اعتبارسنجی کنید.

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

برای گردش‌کارهای مبتنی بر صوت، فرآیند باید با یک ارائه‌دهنده تبدیل گفتار به متن جداگانه شروع شود. محدودیت‌های فعلی پلتفرم‌ها باعث شده جلسات صوتی بلادرنگ به مناطق غربی محدود شوند و وضعیت کلیدهای آن‌ها در حالت انتظار باشد. همچنین، افزایش وضوح تصویر به Lanczos محدود است و بررسی متن یا تصویر باید از یک مدل چت با طرح‌واره JSON استفاده کند، زیرا نقطه انتهایی (Endpoint) اختصاصی برای نظارت وجود ندارد.

برای کارهای تکمیلی مبتنی بر بازیابی، pgvector می‌تواند شباهت برداری را داخل Postgres نگه دارد، اما جایگزین طرح‌واره استخراج یا اعتبارسنج نمی‌شود.

این خط لوله خودکار برای مواردی که هر تغییر CRM باید توسط انسان تأیید شود یا حجم استخراج بسیار کم است، مناسب نیست؛ در این حالت یک فرم بازبینی شفاف‌تر است. همچنین، زمانی که قرارداد یک مدل متخصص به طور عمدی انتخاب شده، مستقیماً از OpenAI یا Anthropic استفاده کنید.

در نهایت، موفقیت یک خط لوله استخراج با سه متریک سنجیده می‌شود: تعداد اشیاء معتبر در هر تلاش، اشیاء رد شده بر اساس کد خطا و هزینه به ازای هر مشتری. در حالت ناهم‌زمان، «عمر دسته» (Batch Age) را به این متریک‌ها اضافه کنید. این اعداد پاسخ می‌دهند که آیا قرارداد برقرار است، چرا شکست خورد، چه کسی بار سیستم را ایجاد کرد و آیا کارهای صف‌بندی‌شده پیش می‌روند یا خیر.

گام بعدی شما

• پیاده‌سازی یک تابع اعتبارسنجی مستقل در Node.js که خروجی LLM را پیش از ورود به دیتابیس با یک JSON Schema سخت‌گیرانه تطبیق دهد.
• جایگزینی حلقه‌های تلاشی بی‌نهایت با یک تک‌تلاشی (Single-retry) که خطای دقیق اعتبارسنجی را به مدل بازمی‌گرداند.
• شمارش توکن‌های ورودی پیش از ارسال به مدل برای جلوگیری از قطع شدن پاسخ‌ها در اسناد حجیم.

اما مدیریت هزینه‌های این استخراج‌ها در مقیاس هزاران مشتری، چالش بعدی است — به تحلیل ما درباره‌ی بهینه‌سازی هزینه استنتاج در محیط‌های چندمستاجری مراجعه کنید.