تصور کنید یک اپلیکیشن تغذیه به‌دلیل یک توهم (Hallucination) — شبیه دوستی که خاطره‌ای را با اطمینان اما کاملاً اشتباه تعریف می‌کند — کل تاریخچه سلامتی شما را به‌صورت خودکار و غلط تغییر دهد. چه اتفاقی می‌افتد وقتی توهمات هوش مصنوعی یک برنامه تغذیه، از طریق ذخیره‌سازی خودکار، به‌طور خاموش کل تاریخچه سلامت کاربر را فاسد می‌کند؟ برای حل این بحران، تیم FoodWarz در ۷ اکتبر ۲۰۲۶ رویکردی در مدل‌سازی داده‌ها معرفی کرد که خروجی هوش مصنوعی را به‌جای یک رکورد دائمی، به‌عنوان یک «تحلیل» موقت می‌بیند.
بسیاری از ادغام‌های هوش مصنوعی دچار «فروپاشی مرزها» می‌شوند؛ یعنی به‌محض دریافت پاسخ موفق از مدل، پایگاه‌داده به‌روزرسانی می‌شود. طبق گزارش این تیم، تصور کنید هوش مصنوعی یک وعده غذایی را شناسایی کرده و کالری آن را پیشنهاد می‌دهد؛ اگر این مقدار فوراً در دفترچه یادداشت ثبت شود، کاربر توانایی تأیید اندازه پرس یا نوع ماده غذایی را پیش از تغییر مجموع کالری روزانه‌اش از دست می‌دهد. این وضعیت حلقه‌ای خطرناک می‌سازد که در آن تفسیر سیستم به تنها حقیقت تبدیل می‌شود. در چنین حالتی، حتی افزودن یک صفحه بازبینی در مراحل بعدی هم نمی‌تواند تمایزی را که در لایه مدل داده از بین رفته است، بازگرداند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت داده‌های تولیدشده توسط مدل‌ها اشاره کردیم، تفکیک لایه‌های استنتاج از لایه‌های ذخیره‌سازی حیاتی است. این رویکرد در راستای کاهش خطاهای محاسباتی است، مشابه تجربه‌ی تیم Protealpes که برای دستیابی به دقت مطلق، محاسبات LLM را با کدهای قطعی جایگزین کرد. FoodWarz برای این کار از واژگان دامنه (Domain Vocabulary) استفاده می‌کند تا «تحلیل» (Analysis) را از «وعده غذایی» (Meal) جدا کند. تحلیل، یک تفسیر قابل بازبینی است، اما وعده غذایی، یک snapshot یا عکس لحظه‌ای از داده‌هایی است که کاربر آگاهانه انتخاب کرده تا ذخیره شوند و شامل مقدار، اطلاعات تغذیه‌ای و منبع است.
به نقل از گزارش dev.to، این سیستم از یک انتقال وضعیت سخت و دقیق پیروی می‌کند: ابتدا تحلیل تکمیل می‌شود $\rightarrow$ یک پیش‌نویس بازبینی باز می‌شود $\rightarrow$ کاربر ویرایش می‌کند $\rightarrow$ کاربر تأیید می‌دهد $\rightarrow$ وعده غذایی اعتبارسنجی و ذخیره (Persist) می‌شود $\rightarrow$ و در نهایت آن وعده ذخیره‌شده در مجموع کالری دفترچه لحاظ می‌گردد.
حفاظ‌های فنی در سطح کد
این تیم برای اجبار به رعایت این مرزها در سطح کد، از تایپ‌های خاص در زبان TypeScript استفاده می‌کند. اصل کلیدی این است که هر شیء تنها یک وظیفه داشته باشد. این کار تضمین می‌کند تابعی که یک «وعده ذخیره‌شده» را می‌پذیرد، نتواند به‌اشتباه یک «نتیجه تحلیل» را بپذیرد، صرفاً به این دلیل که هر دو حاوی مقدار کالری هستند:
- AnalysisResult: تفسیری قابل بازبینی از داده‌ها که حاوی
suggestedNutrition(تغذیه پیشنهادی) است. - ReviewDraft: وضعیتی موقت که در آن پیشنهاد اصلی (
original) هوش مصنوعی از مقدار ویرایش‌شده توسط کاربر (editedNutrition) متمایز نگه داشته می‌شود. - SavedMeal: یک رکورد بادوام و نهایی که حاوی
nutritionSnapshotاست. - PlannedDish: وضعیتی مجزا برای وعده‌های آینده که حاوی
proposedNutritionاست و بر مجموع مصرف فعلی تأثیر نمی‌گذارد.
ناورداهای سیستم (System Invariants)
برای ساده‌تر شدن بازبینی هندلرهای رویداد، تیم برای هر اقدام قوانین سخت‌گیرانه‌ای (Invariants) تعریف کرده است:
- تکمیل تحلیل: یک پیشنهاد برای بازبینی آماده می‌شود، اما تکمیل تحلیل به‌تنهایی هیچ غذایی را به لیست مصرف‌شده اضافه نمی‌کند.
- ویرایش مقدار: پیش‌نویس بازبینی تغییر می‌کند، اما تحلیل اصلی همچنان از اصلاحات کاربر قابل تشخیص و متمایز است.
- تأیید وعده: تنها پس از بازبینی، یک اسنپ‌شات وارد دفترچه می‌شود و تخمین ذخیره‌شده، مبنا و منشأ (Provenance) خود را حفظ می‌کند.
- تغییر منبع: اگر اطلاعات یک آیتم در کاتالوگ تغییر کند، این تغییر می‌تواند برای ورودی‌های آینده استفاده شود، اما سوابق تاریخی به‌صورت خاموش بازنویسی یا بازمحاسبه نمی‌شوند.
- برنامه‌ریزی: افزودن یک غذا به برنامه، وضعیت برنامه‌ریزی را تغییر می‌دهد، اما غذای برنامه‌ریزی‌شده وارد مجموع مصرف فعلی نمی‌شود.
حفظ یکپارچگی تاریخی
بخش حیاتی این مدل، «قانون اسنپ‌شات» است. اگر کاربر وعده‌ای را بر اساس یک آیتم کاتالوگ ذخیره کند، سیستم مقادیر تغذیه‌ای دقیق آن لحظه را ذخیره می‌کند. بر اساس مستندات این تیم، اگر آن آیتم یک ماه بعد اصلاح شود، ورودی‌های تاریخی در دفترچه تغییر نمی‌کنند.
این رویکرد مانع از «بازمحاسبات خاموش» می‌شود؛ وضعیتی که در آن مجموع کالری دیروز بدون هیچ ویرایشی از سوی کاربر، تغییر می‌کند. با متصل نگه داشتن تحلیل اولیه هوش مصنوعی به تخمین نهایی ذخیره‌شده، توسعه‌دهندگان می‌توانند دقیقاً دیباگ کنند که سیستم چه چیزی پیشنهاد داده و کاربر در واقع چه چیزی را پذیرفته است. این موضوع حیاتی است زیرا یک عدد کالری به‌تنهایی مدرک کافی نیست؛ مقدار، واحد و مبنای تغذیه‌ای (مثلاً مقدار در ۱۰۰ گرم در برابر مقدار کل مصرف‌شده) باید به‌صورت یک مجموعه در کنار هم حفظ شوند. این سطح از نظارت بر صحت داده‌ها، یادآور متدهای امتیاز اعتماد داده برای شناسایی ریسک‌های عملیاتی است که برای رفع نقاط کور مدل‌های هوش مصنوعی به کار می‌روند.
برای کاربر، این یعنی هوش مصنوعی به‌جای یک حسابدار خودکار، مانند یک دستیار خبره عمل می‌کند. سیستم تضمین می‌کند که مقدار، واحد و مبنای تغذیه‌ای در مرز ورود به رکورد دائمی اعتبارسنجی شوند. البته این قرارداد ثابت نمی‌کند که هر تفسیری از مدل در بالادست درست است، و بازبینی نیز یک تخمین را به یک اندازه‌گیری دقیق تبدیل نمی‌کند.
این تغییر رویکرد، پیاده‌سازی هوش مصنوعی را از الگوی ساده‌ی «پرامپت-و-ذخیره» به یک خط لوله ساختاریافته از «پیشنهاد، بازبینی و تثبیت» تبدیل می‌کند. این مدل می‌پذیرد که تخمین‌های هوش مصنوعی اندازه‌گیری‌های دقیق نیستند و برای تبدیل یک احتمال به یک حقیقت، حضور انسان در حلقه (Human-in-the-loop) ضروری است. این ساختار اجازه می‌دهد تا قابلیت‌هایی نظیر شخصی‌سازی تحلیل منوها برای بیماران و ورزشکاران با دقت و ایمنی بیشتری پیاده‌سازی شوند.
توسعه‌دهندگانی که سیستم‌های ثبت داده مبتنی بر AI می‌سازند، باید انتقال وضعیت‌های خود را بازبینی کنند تا مطمئن شوند پیشنهادات تولیدشده نمی‌توانند مرحله بازبینی را دور بزنند. تست‌ها باید روی سناریوهای رگرسیون متمرکز شوند؛ مثلاً تأیید اینکه بستن یک پیش‌نویس بازبینی، هیچ اثری در مجموع مصرف باقی نمی‌گذارد، یا اطمینان از اینکه تغییر یک رکورد منبع قابل استفاده مجدد، تغذیه ثبت‌شده در یک وعده موجود را تغییر نمی‌دهد.
گام بعدی شما
- اگر از مدل‌های زاینده برای به‌روزرسانی پایگاه‌داده استفاده می‌کنید، لایه‌ی ReviewDraft را بین خروجی مدل و دستور UPDATE قرار دهید.
- در مدل داده‌های خود، مقادیر استخراج‌شده را به‌صورت Snapshot ذخیره کنید تا تغییرات آتی در منابع (Source Records) سوابق تاریخی را تخریب نکند.
- برای هر انتقال وضعیت (State Transition)، یک قانون ناوردا (Invariant) تعریف کنید تا از ورود داده‌های تأییدنشده به لایه‌ی Persistence جلوگیری شود.
اما چالش بزرگ‌تر، مدیریت هزینه‌های استنتاج در مقیاس‌های میلیونی است — به تحلیل ما درباره‌ی بهینه‌سازی هزینه GPU مراجعه کنید.
گفتگو