پرش به محتوای اصلی
پرش به محتوای مقاله

بنچ‌مارک Kaggle: مدل‌های زبانی در محاسبات وام مسکن شکست خوردند

·۱۹ مهر ۱۴۰۵۵ دقیقه مطالعه
درخواست وام مسکن از هوش مصنوعی: هر ماه ۱۰ روپیه خطا!
درخواست وام مسکن از هوش مصنوعی: هر ماه ۱۰ روپیه خطا!
اشتراک‌گذاری
واقعاً چه چیز جدید است؟

شناسایی پدیده «لغزش ویرگول غربی» و اثبات اینکه مدل‌های برتر حتی در محاسبات قطعی و ساده مالی، با اطمینان کامل پاسخ‌های غلط می‌دهند.

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

زمینه: جستجوی خانه آنانیا

این محک بر اساس سناریوی یک کاربر فرضی به نام «آنانیا» طراحی شده است. او زنی ۳۱ ساله است که هشت سال است برای خرید خانه پس‌انداز می‌کند. آنانیا در حال آماده شدن برای امضای قرارداد خرید یک آپارتمان ۲ خوابه (2 BHK) به قیمت ۷۲ لک (Lakh) روپیه است. در حالی که بروشور ملک ادعا می‌کند فضای خانه ۱۰۵۰ فوت مربع است، اسناد رسمی ثبت نشان می‌دهند که متراژ مفید (Carpet Area) واقعی تنها ۷۲۰ فوت مربع است.

برای میلیون‌ها کاربر در هند، سواد مالی شامل پیمایش در مفاهیمی چون «لک» و «کرور» و تشخیص تفاوت بین متراژ مفید و متراژ کل (Super Built-up Area) است. این‌ها موارد خاص یا حاشیه‌ای نیستند، بلکه پرسش‌های اصلی هستند که هر دستیار خرید ملک باید به آن‌ها پاسخ دهد. این تمرکز بر نیازهای بومی در حالی رخ می‌دهد که هند به سرعت در حال تبدیل شدن به قطب جذب استعدادهای ارشد هوش مصنوعی است تا بتواند چنین چالش‌های منطقه‌ای را حل کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی توهمات مدل‌های زبانی اشاره کردیم، وقتی مدل‌ها سعی می‌کنند این محاسبات را به‌صورت ذهنی انجام دهند، اغلب به فرمت‌های شماره‌گذاری غربی تغییر مسیر می‌دهند یا در الزامات دقیق سود مرکب دچار لغزش می‌شوند.

طبق گزارش منتشر شده، این محک شامل ۶۰ پرسش قطعی در چهار دسته‌بندی است. هر پرسش دقیقاً یک پاسخ درست دارد که به جای محاسبه دستی، توسط زبان پایتون محاسبه شده است. هر پرامپت از مدل می‌خواهد که پاسخ خود را دقیقاً با عبارت "ANSWER: " به پایان برساند.

جزئیات محک

  • تبدیل واحد (۱۵ پرسش): بررسی درک مفاهیم لک، کرور، LPA (درآمد سالانه لک) و درصدها. برای مثال: «۱.۲ کرور روپیه منهای ۴۵ لک روپیه، بر حسب لک چقدر می‌شود؟»
  • محاسبه متراژ (۱۵ پرسش): بررسی تفاوت متراژ مفید در مقابل متراژ ساخته شده و متراژ کل، محاسبه درصد فضای پرت (Loading) و واحد «گاج» (Gaj). برای مثال: «متراژ کل ۱۳۰۰ فوت مربع و متراژ مفید ۹۱۰ فوت مربع است. درصد فضای پرت نسبت به متراژ مفید چقدر است؟»
  • EMI و مالیات (۱۵ پرسش): محاسبه اقساط ماهانه با روش مانده کاهش‌یافته (Reducing-balance EMI)، مالیات استامپ (Stamp Duty)، مالیات بر ارزش افزوده (GST)، مالیات تکلیفی (TDS) و کارمزد دلالی. برای مثال: «وام ۷۲,۰۰,۰۰۰ روپیه با نرخ ۸.۴٪ برای ۲۵ سال؛ اقساط ماهانه (EMI) چقدر است؟»
  • فرمت‌بندی (۱۵ پرسش): توانایی نوشتن اعداد به سبک شماره‌گذاری هندی. برای مثال: نوشتن عدد ۹۸۷۶۵۴۳۲ به صورت ۹,۸۷,۶۵,۴۳۲.

تحلیل عملکرد مدل‌ها

توسعه‌دهنده طیفی از مدل‌ها را از سه ارائه‌دهنده مختلف و در دو سطح قیمتی آزمایش کرد. سیستم امتیازدهی، حاشیه خطای ۲ روپیه را برای گرد کردن EMI پذیرفت اما برای فرمت‌بندی، تطبیق دقیق رشته‌ها (Exact String Match) را الزامی دانست.

  • Gemini 3.7 Flash (گوگل، سطح سریع): برترین مدل با امتیاز ۱.۰۰ که تمام ۱۵ سوال EMI و مالیات را به درستی پاسخ داد.
  • Gemini 3.1 Pro Preview (گوگل، سطح برتر): امتیاز ۰.۹۸ را کسب کرد و تنها در یک سوال EMI شکست خورد.
  • Claude Sonnet 4.6 (آنتروپیک): امتیاز ۰.۹۵ را به دست آورد و در دو سوال EMI و یک تکلیف تبدیل واحد خطا داشت.
  • GPT-5.4 mini (اوپن‌ای‌آی، سطح کوچک): ضعیف‌ترین عملکرد با امتیاز ۰.۹۲؛ این مدل در ۵ مورد از ۱۵ سوال EMI و مالیات شکست خورد.

یک مورد خاص، وام ۷۲,۰۰,۰۰۰ روپیه با نرخ ۸.۴٪ برای ۲۵ سال بود. در حالی که پاسخ درست ۵۷,۴۹۲ روپیه است، مدل Claude Sonnet 4.6 عدد ۵۷,۴۸۷ و Gemini 3.1 Pro Preview عدد ۵۷,۴۸۲ را اعلام کردند. نکته تکان‌دهنده این است که هیچ‌کدام از مدل‌ها از عباراتی مثل «تقریباً» استفاده نکردند و با اطمینان کامل، عددی غلط را ارائه دادند.

علاوه بر ریاضیات، پدیده‌ای به نام «لغزش ویرگول غربی» (Western Comma Drift) شناسایی شد. با وجود اینکه سوالات در سیستم شماره‌گذاری هندی پرسیده شده بود، ۵ تا ۱۲ درصد پاسخ‌های تمام مدل‌ها در جریان محاسبات داخلی خود به گروه‌بندی غربی تغییر یافتند (مثلاً ۴,۰۰۰,۰۰۰ به جای ۴۰,۰۰,۰۰۰). بیشترین لغزش متعلق به Claude Sonnet 4.6 با ۱۲ درصد بود، در حالی که Gemini 3.7 Flash با ۵ درصد کمترین لغزش را داشت. مدل‌های GPT-5.4 mini و Gemini 3.1 Pro هر دو روی ۱۰ درصد متوقف شدند.

شکست بحرانی دیگری در دقت واحدها رخ داد. در یک مورد، مدل Claude Sonnet 4.6 در سوال c14 شکست خورد؛ جایی که پیش‌پرداخت ۲۰٪ از یک آپارتمان ۹۵ لک روپیه بود. مدل پاسخ داد «۱۹ لک»، که از نظر ریاضی درست است، اما چون پرامپت صراحتاً پاسخ را به «روپیه» خواسته بود، مدل رد شد.

درس‌هایی در مدیریت خطا

توسعه‌دهنده همچنین به شکستی در خودِ فرآیند محک‌زنی اشاره کرد. اجراهای اولیه نشان می‌داد که Claude Opus 5 امتیاز ۰.۰۸ گرفته و GPT-5.5 کاملاً با خطا مواجه شده است. اما بررسی لاگ‌ها نشان داد که این‌ها خطاهای ریاضی نبودند، بلکه پیام‌های 403 PermissionDeniedError بودند؛ زیرا مدل‌های گران‌قیمت در طول فراخوانی‌های موازی از سهمیه (Quota) موجود فراتر رفته بودند. سیستم امتیازدهی این خطاها را به عنوان پاسخ غلط شمرده بود. این موضوع درسی حیاتی دارد: اعتبار یک نمره در محک، به اندازه دقت مدیریت خطاهای آن است. این تجربه تأیید می‌کند که در تعامل با هوش مصنوعی، کیفیت تصمیمات و دقت در تحلیل خطاها بسیار مهم‌تر از حجم داده‌های پردازش شده است.

این داده‌ها نشان می‌دهد که مدل‌ها سعی می‌کنند فرمول‌های پیچیده ریاضی مانند $(1 + r)^{300}$ را از طریق پیش‌بینی توکن‌ها حل کنند، نه از طریق محاسبات واقعی. برای یک انسان، اختلاف چند روپیه شاید خطای گرد کردن باشد، اما برای یک ابزار مقایسه وام، این یک شکست در حقیقت است.

این تغییر در درک ما به این معناست که توسعه‌دهندگان دیگر نمی‌توانند محاسبات EMI را «ریاضیات ساده» تلقی کنند. برای تضمین قابلیت اطمینان، مدل باید برای توضیح فرمول استفاده شود، در حالی که یک ابزار نرم‌افزاری اختصاصی مقدار واقعی را محاسبه کند.

آزمایش‌های آینده بررسی خواهند کرد که آیا ارائه ابزار ماشین‌حساب به مدل‌ها، این خطاها را از بین می‌برد یا مدل‌ها همچنان وقتی بیش از حد به خود اعتماد می‌کنند، ابزار را نادیده می‌گیرند. محققان همچنین قصد دارند واحدهای منطقه‌ای مانند Bigha، Guntha و cents را — که معنای آن‌ها از ایالتی به ایالت دیگر تغییر می‌کند — و همچنین عبارت‌های «هینگلیش» (ترکیب هندی و انگلیسی) مانند "72 lakh ka flat, 20% down, EMI kitni?" را آزمایش کنند.

گام بعدی شما

  • اگر از LLM برای کارهای مالی استفاده می‌کنید، هرگز اجازه ندهید مدل عدد نهایی را محاسبه کند؛ از آن بخواهید فرمول را بنویسد و سپس آن را در ماشین‌حساب اجرا کنید.
  • در پرامپت‌های مالی، صراحتاً از مدل بخواهید از استفاده از ابزار (Tool Use) یا کدنویسی پایتون برای رسیدن به جواب استفاده کند.
  • برای بررسی دقت مدل‌ها در زبان‌های محلی، نتایج بنچمارک‌های منطقه‌ای را دنبال کنید.

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

چرا این موضوع مهم است؟

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

تأثیر برای ایران

این خبر برای توسعه‌دهندگان ایرانی که در حال ساخت دستیارهای مالی یا حسابداری با LLM هستند هشدار است؛ استفاده از مدل بدون لایه کدنویسی (Code Interpreter) برای محاسبات پولی، منجر به خطاهای بحرانی می‌شود.

·نگاه ما
تحریریه دات‌هوش

اعتماد به «اطمینانِ» مدل‌های زبانی در محاسبات عددی، یکی از خطرناک‌ترین نقاط کور فعلی است. این نتایج ثابت می‌کند که حتی مدل‌های پیشرفته، ریاضیات را «شبیه‌سازی» می‌کنند نه «محاسبه». راهکار نهایی نه در افزایش اندازه مدل، بلکه در جداسازی لایه استدلال از لایه محاسبه از طریق فراخوانی توابع خارجی است.

منابع

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

گفتگو

پنج‌شنبه‌های هوش‌محور

بسته‌ی هفتگی دات‌هوش

۵ خبر، ۲ ابزار، ۱ پرامپت در هر شماره. به‌زودی راه‌اندازی می‌شود — هر پنج‌شنبه صبح.

خبر کلیدی
ابزار کاربردی
پرامپت حرفه‌ای
تحلیل پژوهش
به‌زودی
زاویه‌ی ایرانی
به‌زودی
تمرین این هفته
به‌زودی

راهنماهای دات‌هوش

راهنماهای کاربردیِ دات‌هوش برای کار با هوش مصنوعی — از همین‌جا شروع کنید:

دات‌هوش

راهنمای فارسی هوش مصنوعی — با نگاه به ایران

اخبار روزانه، معرفی ابزارها و مدل‌ها، و آموزشِ کار با هوش مصنوعی؛ همیشه با این پرسش که از ایران چه چیزی کار می‌کند و چه چیزی نه.