تصور کنید ابزاری دارید که می‌تواند پیچیده‌ترین استدلال‌های حقوقی را بنویسد، اما در ضرب دو عدد چهاررقمی شکست می‌خورد. این تضاد، نتیجه‌ی یک نقص بنیادین در معماری هوش مصنوعی است، نه کمبود داده برای آموزش. این عدم تطابق بین احتمال آماری و دقت ریاضی توضیح می‌دهد که چرا یک مدل می‌تواند یک لایحه حقوقی را پیش‌نویس کند اما در ابتدایی‌ترین محاسبات ریاضی ناکام بماند.
به نقل از تحلیل مفصلی که در ۲۳ اوت ۲۰۲۶ در dev.to منتشر شد، مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — اصلاً محاسبه نمی‌کنند، بلکه در حال تکمیل الگوهای احتمالی با ریسک بالا هستند. این بینش توضیح می‌دهد که چرا یک پاسخ با اعتمادبه‌نفس از سوی هوش مصنوعی می‌تواند منطقی بی‌نقص را ارائه دهد اما در نهایت به یک عدد اشتباه ختم شود. چنین شکست‌هایی نشانه یک «شکاف یادگیری» نیستند، بلکه یک محدودیت معماری بنیادین هستند. این محدودیت‌ها را می‌توان در دیدگاه‌های متخصصان دید که برخی ریاضیدانان بر این باورند که این مدل‌ها فاقد شهود خلاق برای اکتشافات بنیادین هستند و صرفاً بر بازتولید الگوها تکیه می‌کنند.
این یعنی وقتی یک مدل ریاضی حل می‌کند، در واقع می‌پرسد: «با توجه به این رشته از کاراکترها، محتمل‌ترین متنی که در ادامه می‌آید چیست؟»؛ دقیقاً همان فرآیندی که برای تکمیل جمله «پایتخت فرانسه ___ است» به کار می‌برد. همان‌طور که در تحلیل قبلی ما درباره‌ی شناسایی الگوهای بازار در ابزارهایی مثل IndieDex اشاره کردیم، قدرت این مدل‌ها در یافتن شباهت‌هاست (مثلاً استفاده از اثر انگشت LLM برای یافتن بازی‌های استیم). اما اعمال همین تطبیق الگو در ریاضیات منجر به نتایجی می‌شود که «متقاعدکننده اما غلط» هستند. این همان نوع اشتباهی است که شاید حتی متوجه آن نشوید، زیرا با تسلط و آرامش کامل ارائه می‌شود.
این وضعیت شبیه کسی است که دفترچه راهنمای دوچرخه‌سواری را حفظ است و می‌تواند آن را با تسلط بخواند، اما به محض نشستن روی زین و لمس پدال‌ها، تعادلش را از دست می‌دهد. مدل زبانی در توصیف فرآیند ریاضی مسلط است، اما در اجرای آن ناتوان. این مدل‌ها می‌توانند فیزیک کوانتوم را توضیح دهند یا استدلال‌های حقوقی پیچیده بنویسند، اما در محاسباتی تپق می‌زنند که یک ماشین‌حساب ۲ دلاری در سال ۱۹۷۵ به راحتی از پس آن برمی‌آمد.
موتور پیش‌بینی در برابر ماشین‌حساب
یک ماشین‌حساب بر اساس قوانین قطعی (Deterministic) کار می‌کند. اگر عدد ۴۸۲۷ را در ۳۹۱ ضرب کنید، یک الگوریتم دقیق را اجرا کرده و هر بار دقیقاً عدد ۱,۸۸۷,۳۵۷ را برمی‌گرداند. ماشین‌حساب «فکر» نمی‌کند؛ بلکه محاسبه می‌کند. اگر یک میلیون بار ورودی یکسانی به آن بدهید، تضمین شده است که یک میلیون بار خروجی یکسانی دریافت کنید.
در مقابل، یک LLM محاسبه نمی‌کند؛ بلکه محتمل‌ترین تکه متن بعدی را بر اساس داده‌های آموزشی پیش‌بینی می‌کند. برای این مدل، مسئله ریاضی شبیه به یک وظیفه تکمیل جمله است. زبان ماهیتی آماری دارد و نسبت به خطا منعطف است. در یک جمله، چندین کلمه مختلف می‌توانند «درست» یا «به اندازه کافی نزدیک» باشند و در عین حال متن روان باقی بماند. در ارتباطات انسانی، «تقریباً درست» نه تنها پذیرفتنی است، بلکه اساس کارکرد زبان است.
اما حساب ریاضی صفر درصد تحمل دارد. وقتی پاسخ درست ۱,۸۸۷,۳۵۷ است، نتیجه‌ی ۱,۸۸۷,۰۰۰ دقیقاً به اندازه عدد ۴۲ غلط است. «نزدیک بودن» در ریاضیات مطلقاً هیچ ارزشی ندارد. مدل در حال بازی با احتمالات در قلمرویی است که دقت مطلق می‌طلبد. به همین دلیل است که مدل می‌تواند روش حل مسئله را بی‌نقص توضیح دهد (که یک وظیفه زبانی است)، اما در محاسبه نهایی (که یک وظیفه ریاضی است) خطا کند.
توکن‌سازی؛ خرابکار خاموش
قبل از اینکه مدل متنی را پردازش کند، آن را به توکن (Token) — تکه‌های کوچکی از متن، مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — تبدیل می‌کند. این فرآیند به طور خاموش دقت عددی را تخریب می‌کند. توکن‌ها واحدهای تجزیه‌ناپذیری هستند که مدل با آن‌ها برخورد می‌کند. برای کلمات، این سیستم عالی عمل می‌کند، اما برای اعداد یک فاجعه است.
برای انسان، عدد ۸۷۴۳۹ دارای ارزش مکانی است (ده‌هزارگان، هزارگان و غیره). اما برای مدل، این عدد مجموعه‌ای از شناسه‌های (ID) دلخواه در یک واژگان است. توکن مربوط به یک تکه عدد، از نظر ماهیت هیچ تفاوتی با توکن کلمه «سیب» یا «ایده» ندارد. این یک نماد است که هیچ درک داخلی از مقدار یا ارزش مکانی ندارد.
بسته به نوع توکن‌سازی (Tokenization)، عدد ۸۷۴۳۹ ممکن است به «۸۷۴» و «۳۹» یا شاید «۸ + ۷۴۳ + ۹» تقسیم شود. مدل این‌ها را به عنوان نمادهایی می‌بیند بدون اینکه بفهمد کدام رقم در ستون دهگان و کدام در ستون هزارگان قرار دارد.
ریاضیات واقعی کاملاً بر ساختار مکانی متکی است:
- تراز کردن یکان‌ها، دهگان‌ها و صدگان‌ها.
- انتقال (Carry) عدد ۱ از یک ستون به ستون بعدی.
- جایگاه هر رقم، تمام بازی است.
توکن‌سازی این ساختار را به «توده‌های کلمه-مانند» تبدیل می‌کند و ریاضی ستونی را تقریباً غیرممکن می‌سازد. در واقع از مدل خواسته می‌شود ریاضی ستونی را روی اعدادی انجام دهد که ستون‌هایشان پیش از شروع کار، له و ترکیب شده‌اند.
این موضوع توضیح می‌دهد که چرا مدل‌ها در ضرب ۳ در ۴ کاملاً موفق هستند:
- این‌ها اعداد کوچک و تک‌توکنی هستند.
- آن‌ها به طور مداوم در داده‌های آموزشی دیده شده‌اند.
- نمونه‌های پاک و بی‌شماری برای تطبیق الگو وجود دارد.
در مقابل، مدل‌ها در ضرب ۸۷۴۳ در ۴۳۹۷ شکست می‌خورند زیرا:
- این‌ها الگوهای عددی چندتوکنی و ناآشنا هستند.
- مدل در طول آموزش، آن‌ها را دقیقاً به این شکل به ندرت دیده است.
- این وظیفه نیازمند حساب ستونی واقعی است که مدل اساساً قادر به انجام آن نیست.
در هیچ‌کدام از این دو مورد، محاسبه واقعی صورت نمی‌گیرد. در هر دو، مدل در حال تطبیق الگو است. تفاوت در این است که جمع‌های کوچک، الگوهای بسیار بهتری برای تطبیق دارند. محققان دریافته‌اند که تغییر نحوه توکن‌سازی اعداد — مانند اجبار به استفاده از توکن‌های تک‌رقمی یا تراز کردن آن‌ها از راست به چپ — عملکرد را به طور محسوسی بهبود می‌بخشد. این ثابت می‌کند که توکن‌سازی یک مشکل محوری است، نه یک جزئیات جانبی.
سوگیری داده‌های آموزشی
طبق گزارش‌های فنی، مدل‌ها از اقیانوسی از متون انسانی یاد می‌گیرند که به شدت زبانی هستند تا محاسباتی. آن‌ها کتاب‌ها، مقالات، وب‌سایت‌ها، تالارهای گفتگو و کدها را می‌خوانند. در حالی که آن‌ها مقادیر عظیمی نوشته «درباره» ریاضی خوانده‌اند، اما در مقایسه، مطالب بسیار کمی دیده‌اند که به آن‌ها بیاموزد با اعداد به عنوان موجوداتی که توسط قوانین سخت و جهانی اداره می‌شوند، برخورد کنند.
آن‌ها حفظ کرده‌اند که «۲ + ۲ = ۴» یک توالی رایج است، درست مثل «نان و پنیر». اما مکانیسم زیربنایی جمع را که به آن‌ها اجازه دهد ۲۸۳۷ + ۴۹۹۱ را (حتی اگر هرگز قبلاً ندیده باشند) به طور قابل اعتمادی حل کنند، جذب نکرده‌اند. آن‌ها ظاهر ریاضیات درست را حفظ کرده‌اند بدون اینکه ماشین تولیدکننده آن را درک کنند.
وقتی مدل با یک محاسبه ناآشنا روبه‌رو می‌شود، همان کاری را می‌کند که همیشه در زمان تردید انجام می‌دهد: یک حدس متقاعدکننده و با اعتمادبه‌نفس می‌زند. مدل نتایج رایج — جمع‌های کوچک، ثابت‌های مشهور و مثال‌های کتاب درسی — را بازتولید می‌کند زیرا این‌ها به عنوان الگوهای متنی آشنا در مدل تثبیت شده‌اند.
این اعتمادبه‌نفس کاذب خطرناک‌ترین بخش ماجراست. ابزاری که آشکارا ضعیف است، امن است؛ اما ابزاری که به طور ظریف و با اطمینان اشتباه می‌کند، کاربر را به خواب می‌برد و حس امنیت کاذبی ایجاد می‌کند. مدل پاسخ غلط را با همان لحن قاطعانه ارائه می‌دهد که برای چیزهایی که به آن‌ها اطمینان دارد استفاده می‌کند. این نتیجه مستقیم نحوه عملکرد توهم (Hallucination) است: مدل برای «متقاعدکننده بودن» بهینه شده است، نه برای «حقیقت».
افسانهٔ «زنجیره تفکر»
بسیاری از کاربران بر این باورند که دستور دادن به مدل برای تفکر گام‌به‌گام یا همان زنجیره تفکر (Chain-of-Thought)، این مشکل را حل می‌کند. اما این یک باور غلط و گسترده است. این تصور که این روش یک موتور احتمالی را به یک استدلال‌گر نمادین تبدیل می‌کند، اشتباه است. در واقع، بررسی‌های عمیق‌تر نشان می‌دهد که زنجیره‌های تفکر ممکن است تنها توهمی از منطق باشند که از تطبیق الگوها حاصل شده است و نه یک ابزار محاسباتی واقعی.
اگرچه نمایش مراحل حل مسئله دقت را بهبود می‌بخشد، اما یک واحد محاسباتی پنهان به مدل اضافه نمی‌کند. هیچ ماشین‌حساب داخلی وجود ندارد که ناگهان روشن شود. در عوض، این روش مدل را سوق می‌دهد تا گام‌های میانی تولید کند که شبیه به استدلال دقیق به نظر برسند. این هنوز همان پیش‌بینی است، اما با داربست‌های بهتر؛ نه محاسبه.
تقسیم یک مسئله به قطعات کوچک‌تر، مدل را به سمت الگوهای آماری بهتر هدایت می‌کند:
- محاسبه «۷ × ۸» یک گام کوچک و آشنا است.
- «انتقال عدد ۵ به ستون بعد» یک الگوی رایج در متون ریاضی است.
- این گام‌های کوچک احتمال بیشتری دارند که با داده‌های آموزشی مطابقت داشته باشند تا یک جهش بزرگ به پاسخ نهایی.
در نهایت، مدل در حال حدس زدن در قطعات کوچک‌تر و آشناتر است. برای حوزه‌های حساس مثل دوز داروهای پزشکی، مشخصات مهندسی یا مدل‌های مالی، «حدس زدنِ بهبود یافته» یک زیربنای غیرقابل قبول است. شما کیفیت حدس زدن را ارتقا داده‌اید، اما حدس زدن را با محاسبه جایگزین نکرده‌اید.
راهکار معماری: سامانه‌های ترکیبی
راه حل در انتظار یک مدل «باهوش‌تر» نیست، بلکه در تغییر معماری است. تلاش برای اینکه یک مدل زبانی را در محاسبات دقیق داخلی قابل اعتماد کنیم، در تضاد با همان چیزی است که آن را به یک مدل زبانی خوب تبدیل کرده است.
هدف این است که LLM نقش ارکستراتور (هماهنگ‌کننده) را داشته باشد و یک ابزار قطعی، محاسبه را انجام دهد. این همان مفهوم سامانه‌های ترکیبی (Hybrid Systems) است که از نقاط قوت هر بخش استفاده می‌کند:
- مدل زبانی (LLM): درخواست مبهم انسان را مدیریت می‌کند، شناسایی می‌کند چه چیزی باید محاسبه شود، مسئله را فرموله می‌کند و نتیجه را به زبان ساده توضیح می‌دهد.
- ابزار (Tool): یک ماشین‌حساب، یک خط کد پایتون یا یک فرمول اکسل که قوانین دقیق را دنبال کرده و هر بار تنها پاسخ درست را برمی‌گرداند.
این همان فلسفه پشت محیط‌های کاری تطبیقی مانند Xenition است، جایی که سیستم درخواست‌ها را به سطح مناسب هدایت می‌کند. به جای اعتماد به یک چت برای پردازش اعداد، ابزار مناسب خودش باز می‌شود:
- یک صفحه گسترده (Spreadsheet) با فرمول‌های واقعی و اجرایی برای کارهای مالی.
- یک ویرایشگر کد که برای هر مورد محاسباتی واقعاً اجرا می‌شود.
- یک سند برای نوشتن گزارش پیرامون داده‌ها.
وقتی یک مدل یک قطعه کد پایتون می‌نویسد و برای حل ضرب ۴۸۲۷ در ۳۹۱ اجرا می‌کند، نتیجه ۱,۸۸۷,۳۵۷ می‌شود زیرا یک موتور محاسباتی واقعی آن را تولید کرده است، نه یک توزیع احتمالی روی ارقامی که به نظر درست می‌رسند. وظیفه مدل شناسایی نیاز به محاسبه و هدایت درست آن بود؛ وظیفه کامپیوتر، محاسبه واقعی بود.
عادت‌های کاربردی برای کاربران
برای اجتناب از اعداد «با اعتمادبه‌نفس اما غلط»، کاربران باید عادت‌های خاصی را اتخاذ کنند:
- هرگز به محاسبات خام اعتماد نکنید: به ویژه برای اعداد بزرگ، درصدها، عملیات زنجیره‌ای یا داده‌های مالی، پزشکی و حقوقی. لحن آرام مدل، نشانه درست بودن پاسخ نیست.
- صراحتاً دستور استفاده از ابزار را بدهید: به مدل بگویید «برای محاسبه این مورد از کد استفاده کن» یا در محیطی کار کنید که مدل بتواند محاسبات را اجرا کند. این کار حدس‌های غیرقابل اعتماد را به پاسخی قابل تأیید تبدیل می‌کند.
- تقسیم کار کنید: از مدل برای تفسیر مسئله، انتخاب فرمول مناسب و توضیح معنای اعداد استفاده کنید. اجازه دهید یک ماشین‌حساب یا اسکریپت، ارقام دقیق را مدیریت کند. در این مسیر، تخصص کاربر در حوزه مربوطه همچنان متغیر اصلی در ارتقای کیفیت خروجی مدل است تا بتواند خطاهای احتمالی را شناسایی کند.
- بزرگی اعداد را چک کنید (Sanity-check): یک تخمین ذهنی سریع می‌تواند خطاهایی را که در آن مدل یک مرتبه بزرگی (Order of Magnitude) اشتباه کرده است، شناسایی کند. از خود بپرسید: «آیا این مرتبه بزرگی منطقی است؟»
- مراقب مسائل متنی چندمرحله‌ای باشید: این مسائل ریسک‌ها را روی هم انباشته می‌کنند. مدل باید زبان را تجزیه کند (نقطه قوت) و چندین محاسبه انجام دهد (نقطه ضعف). یک لغزش کوچک محاسباتی در ابتدای راه، در کل پاسخ اثر می‌گذارد و منجر به یک پاسخ نهایی با اعتمادبه‌نفس می‌شود که بر پایه یک گام شکسته بنا شده است.
در نهایت، LLMها موتورهای زبانی فوق‌العاده‌ای هستند، نه ماشین‌حساب. جنگیدن با ماهیت آن‌ها منجر به شکست می‌شود؛ اما بهره‌برداری از نقاط قوت آن‌ها منجر به صحت می‌شود. از یک نویسنده درخشان نخواهید که ماشین‌حساب باشد. اجازه دهید مدل فکر کند، چارچوب بسازد و توضیح دهد — و اجازه دهید یک ابزار واقعی، شمارش را انجام دهد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو