پارسرهای اصلاح‌شده در برابر قراردادهای پیچیده برای جلوگیری از فساد داده

اگر امروز بخشی از بودجه توکن‌های خود را صرف تلاش مجدد (Retry) برای خروجی‌های جداشده با کاما می‌کنید، در واقع در حال جنگیدن در جبهه‌ای بازنده هستید. طبق گزارش منتشر شده در ۲۴ اوت ۲۰۲۶ در وب‌سایت dev.to، حذف تنها ۱۸ کاراکتر از یک پارسر خط جدید، صحت ثبت رکوردها را از ۳۴.۴۸٪ به ۶۴.۶۳٪ رسانده است. این یافته نشان می‌دهد که گران‌ترین شکست‌ها در خط لوله‌های داده‌ی هوش مصنوعی، کرش‌های بلند و واضح نیستند، بلکه «فسادهای خاموش» (Silent Corruptions) هستند؛ جایی که جملات خوش‌وبش مدل، به طور نامحسوس جذب اولین فیلد داده می‌شوند.

بسیاری از توسعه‌دهندگان با خروجی هوش مصنوعی زاینده (Generative AI) — شبیه به یک دستیار پرحرف که گاهی جواب را لابلای جملات خوش‌وبش می‌پیچد — مانند یک وضعیت صفر و یکی برخورد می‌کنند: یا داده‌ها پارس می‌شوند یا نمی‌شوند. اما در واقعیت، یک پارسر (Parser) — ابزاری که متن خام را به داده‌های ساختاریافته تبدیل می‌کند — به دو شکل متمایز شکست می‌خورد. شکست «بلند» خطایی صریح می‌دهد یا تعداد فیلدهای اشتباهی را برمی‌گرداند که منجر به یک تلاش مجدد (Retry) می‌شود. اما شکست «خاموش» دقیقاً k فیلد را با اطمینان کامل برمی‌گرداند، در حالی که یکی از آن‌ها غلط است؛ این یعنی کاربر یک ردیف داده‌ی فاسد را برای همیشه در پایگاه‌داده ذخیره می‌کند.

متدولوژی آزمایش

برای اندازه‌گیری این اثر، محقق ۱۴ جفت رمزگذار/رمزگشای (Encoder/Decoder) واقعی را ساخت. این مجموعه شامل یک JSON.parse واقعی، یک اسکنر تگ، یک اسکنر خط و یک اسکنر RFC 4180 با قابلیت دوبرابر کردن کوتیشن‌ها بود.

در این تست از یک رکورد «خسته‌کننده» استفاده شد که هیچ کاما، خط جدید، پایپ، کوتیشن یا هش (Hash) در آن نبود. تنها متغیر موجود، متن‌های پیرامونی (Wrapping text) مدل بود. نتایج نشان داد که وقتی مدل یک خوش‌وبش ساده مانند «حتماً! این‌ها فیلدهایی هستند که خواستید» اضافه می‌کرد، ۵ مورد از ۱۴ پارسر داده‌های خاموش و غلط را برمی‌گرداندند.

مکانیسم شکست

هر فرمت تک‌خطی، جملات خوش‌آمدگویی را در فیلد اول و جملات خداحافظی را در آخرین فیلد (فیلد k) جذب می‌کند. چون تعداد فیلدها درست باقی می‌ماند، پارسینگ بدون هیچ خطایی موفقیت‌آمیز به نظر می‌رسد و در سکوت شکست می‌خورد. وقتی پنج نوع دیگر از پوشش‌های متنی معمولی اضافه شد، ۸ مورد از ۱۴ پارسر شکست خوردند. تنها ۳ پارسر از هر ۶ سناریو جان سالم به در بردند و نکته اینجاست که تمام این بازماندگان، فرمت‌هایی بودند که دارای یک «توکن پایانی صریح» (Explicit Closing Token) بودند.

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

هزینه اصلاحات «رایگان»

این مطالعه چندین تنظیم با اثر بالا و هزینه توکن صفر (Zero-token) را شناسایی کرد:

• پارسرهای خط جدید: حذف خط .filter(x => x !== '') صحت را از ۳۴.۴۸٪ به ۶۴.۶۳٪ رساند و فساد خاموش را از ۳.۸۳٪ به ۰.۰۰٪ کاهش داد.
• پارسینگ JSON: حذف فنس‌های مارک‌داون (Markdown fences) قبل از فراخوانی JSON.parse، نرخ موفقیت را از ۸۵.۴۲٪ به ۹۲.۸۵٪ رساند و هزینه توکن هر رکورد را از ۱۰۸.۲ به ۹۹.۶ کاهش داد.
• توکن‌های پایانی: تنها فرمت‌هایی که توکن پایانی صریح داشتند، از تمام ۶ سناریوی رایج پوشش متنی جان سالم به در بردند. این ثابت می‌کند که توکن‌های پایان‌دهنده، داده‌ها را در برابر نثری که پس از پاسخ می‌آید، محافظت می‌کنند.

شکست قراردادهای گریز (Escape)

برخلاف راهنماهای رایج، افزودن قراردادهای گریز برای کاراکترهایی مثل پایپ (|) اغلب نتیجه عکس می‌دهد. گریز کردن پایپ، ۲۶ توکن دستورالعمل به هر فراخوانی اضافه کرد اما تنها ۰.۶۹ امتیاز به صحت داده‌ها افزود. گریز کردن موجودیت‌های XML (Entity-escaping) نیز ۲۲ توکن دستورالعمل را برای همیشه اضافه کرد، در حالی که ۰.۰۰ امتیاز سود داشت. این چالش‌ها نشان می‌دهد که برای کاهش خطاهای عملیاتی، استفاده از قراردادهای سخت‌گیرانه در ابزارها می‌تواند نرخ خطا را به شکل چشم‌گیری کاهش دهد.

در حالی که یک قرارداد گریز در محیط ایزوله (Vacuum) دقتی معادل ۹۹.۵۴٪ ارائه داد، اما با معرفی خوش‌وبش‌های هوش مصنوعی، این دقت به ۹۱.۵۸٪ سقوط کرد. بحرانی‌تر از آن، این کار ۰.۶۹ امتیاز به فساد خاموش اضافه کرد.

دلیل این اتفاق این است که خودِ «رمزگشا» (Un-escaper) به نقطه جدیدی برای شکست تبدیل می‌شود. برای مثال، اگر مدل یک مسیر فایل خام مانند C:\temp را بنویسد، رمزگشا ممکن است با حسن نیت بک‌اسلش را حذف کند و C:temp را به عنوان یک داده محتمل اما زباله ذخیره کند، به جای اینکه یک خطای سخت (Hard Error) ایجاد کند و سیستم را متوقف سازد. این نوع شکست‌های خاموش در لایه‌های داده، مشابه ریسک‌هایی است که سیستم‌های GuardRail برای جلوگیری از حذف داده‌های عملیاتی را مدیریت می‌کنند.

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

اگر در حال حاضر بخش بزرگی از بودجه توکن‌های خود را صرف تلاش مجدد برای خروجی‌های جداشده با کاما می‌کنید — که می‌تواند ۷۳.۲۸٪ از صورت‌حساب توکن‌های شما را تشکیل دهد — در حال جنگیدن در جبهه‌ای بازنده هستید. داده‌ها نشان می‌دهد ۴۷.۵۰٪ از رکوردهای پنج‌فیلدی در هر وضعیت تولیدکننده‌ای شکست می‌خورند، به این معنی که بودجه تلاش مجدد آن‌ها عملاً صفر است.

برای پیاده‌سازی این تغییرات، ابتدا نحوه مدیریت رشته‌های خالی و فنس‌های مارک‌داون در پارسر خود را بازرسی کنید. شما می‌توانید مجموعه کامل ۵۶۴ ادعای درون‌صفحه‌ای (In-page assertions) و تاییدکننده ۵۳۶ ادعایی را در سایت منبع پروژه بیابید.

گام بعدی شما

• بررسی کنید آیا پارسر شما رشته‌های خالی و فنس‌های مارک‌داون را به درستی مدیریت می‌کند یا خیر.
• برای تمام خروجی‌های ساختاریافته، یک توکن پایان صریح (مانند </data>) تعریف کنید تا جملات پایانی مدل جذب داده‌ها نشود.
• قراردادهای پیچیده Escape را حذف کرده و به جای آن روی ساده‌سازی منطق پارسینگ تمرکز کنید.

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