چرا هوش مصنوعی نباید عدد بسازد؛ الگوی «سامانه محاسبه می‌کند، AI روایت می‌کند»

یک جواب روان، یک عدد نامعلوم

فرض کنید مدیر مالی از یک دستیار می‌پرسد: «حاشیه سود این فصل نسبت به فصل قبل چطور بوده؟» دستیار می‌نویسد که حاشیه سود بهتر شده و درصدی هم ذکر می‌کند. متن مرتب است و لحن مطمئن. مدیر همان عدد را در جلسه می‌گوید.

حالا سؤال اصلی: آن درصد از کجا آمده است؟ اگر کسی نتواند مسیرش را تا داده واقعی نشان بدهد، آن عدد فقط یک جمله خوش‌ساخت است. در یک متن تبلیغاتی شاید چنین خطایی با یک ویرایش حل شود. در گزارش مالی می‌تواند به تصمیم غلط برسد.

توهم چیست و چرا اتفاق می‌افتد

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

به این رفتار توهم (Hallucination) می‌گویند. مدل دروغ نمی‌گوید، چون قصدی ندارد. فقط بین «می‌دانم» و «به نظر محتمل است» مرز روشنی نمی‌کشد. در ضمن، بسیاری از مدل‌ها در محاسبه هم قابل اتکا نیستند. جمع زدن یک ستون طولانی، کاری است که یک ماشین‌حساب همیشه درست انجام می‌دهد، ولی یک مدل زبانی ممکن است در آن اشتباه کند.

چرا توهم در عدد خطرناک‌تر است

• عدد مقتدر به نظر می‌رسد: عددی با یک رقم اعشار آن‌قدر دقیق به نظر می‌رسد که کسی به شک نمی‌افتد.
• خطا پنهان می‌ماند: غلط املایی را همه می‌بینند، ولی عدد غلط تا وقتی با منبع مقایسه نشود شبیه عدد درست است.
• تکرارپذیر نیست: یک سؤال را دو بار بپرسید، شاید دو جواب متفاوت بگیرید. در گزارش مالی این پذیرفتنی نیست.
• قابل حسابرسی نیست: حسابرس از شما مسیر عدد را می‌خواهد. «مدل این‌طور گفت» جواب نیست.

راه‌حل‌هایی که کافی نیستند

سه راه‌حل رایج به نظر معقول می‌آیند، ولی به‌تنهایی مسئله را حل نمی‌کنند:

• فقط به مدل بگوییم عدد نسازد: این دستور لازم است، ولی یک دستور متنی تضمین نیست و مدل همچنان می‌تواند از آن عبور کند.
• همه داده را به مدل بدهیم تا حساب کند: هم محدودیت حجم دارد، هم ممکن است در محاسبه اشتباه کند، و هم داده‌ای را به مدل می‌دهد که کاربر شاید اجازه دیدنش را ندارد.
• از RAG استفاده کنیم: RAG برای جواب دادن از روی سند عالی است. ولی سود خالص امسال در هیچ سندی نوشته نشده است. این عدد باید از داده زنده محاسبه شود.

الگوی «سامانه محاسبه می‌کند، AI روایت می‌کند»

راه‌حل این است که کار را تقسیم کنیم. هر کس کاری را انجام دهد که در آن قابل اتکاست:

• کاربر می‌پرسد: «سود و زیان امسال چقدر بوده؟»
• مدل تصمیم می‌گیرد: می‌فهمد برای این سؤال به گزارش سود و زیان نیاز است. عدد نمی‌گوید.
• سامانه محاسبه می‌کند: گزارش را با کد قطعی و با دسترسی همان کاربر از داده واقعی می‌سازد.
• نتیجه به مدل داده می‌شود: فقط عددهای محاسبه‌شده، معمولاً به‌صورت داده ساختاریافته.
• مدل روایت می‌کند: توضیح می‌دهد این عددها چه معنایی دارند و کجا باید توجه کرد.

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

Function Calling به زبان ساده

فناوری پشت این الگو Function Calling است. به مدل فهرستی از ابزارها داده می‌شود، مثلاً «گزارش سود و زیان سالانه» یا «فهرست فاکتورهای معوق». مدل هیچ‌کدام را خودش اجرا نمی‌کند. فقط می‌گوید کدام ابزار را با چه ورودی می‌خواهد.

اجرا با سامانه است. پس سامانه می‌تواند پیش از اجرا بررسی کند که این کاربر چنین اجازه‌ای دارد یا نه. نتیجه هم به مدل برمی‌گردد و مدل با آن جواب را می‌نویسد. اگر یک ابزار کافی نباشد، این رفت‌وبرگشت چند دور تکرار می‌شود. ایده مشابهی پشت MCP هم هست.

مثال: گزارش سود و زیان

این الگو چه چیزی را حل نمی‌کند

این الگو خطر عددسازی را خیلی کم می‌کند، ولی خطای مدل را صفر نمی‌کند. چند خطر باقی می‌ماند:

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

پرسش‌هایی که ابزار آماده ندارند

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

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

دسترسی هم بخشی از درستی جواب است

فرض کنید مدیر یک شعبه می‌پرسد «فروش امسال چقدر بوده؟» جواب درست برای او فروش شعبه خودش است، نه کل سازمان. اگر دستیار دسترسی را نشناسد، یا عددی را نشان می‌دهد که او نباید ببیند، یا عددی که به کارش نمی‌آید.

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

یک گزارش هوش مصنوعی را چطور بررسی کنید

• یک عدد را انتخاب کنید و مسیرش را تا منبع دنبال کنید. اگر راهی نیست، به آن اتکا نکنید.
• یک سؤال را دو بار بپرسید. عددها باید یکی باشند.
• سؤالی بپرسید که داده‌اش وجود ندارد. سیستم خوب می‌گوید داده کافی نیست.
• با یک کاربر کم‌دسترسی سؤال حساس بپرسید. جواب نباید لو برود.
• جمله‌های علت‌ومعلولی را جدا بخوانید و با آن‌ها مثل فرضیه رفتار کنید.

اگر می‌خواهید این الگو را پیاده کنید

• تعریف عددها را یکی کنید: پیش از هر چیز روشن کنید درآمد، سود و معوقات در سازمان شما دقیقاً یعنی چه.
• از چند ابزار کوچک شروع کنید: پرتکرارترین سؤال‌های مدیران را پیدا کنید و برای هر کدام یک ابزار مطمئن بسازید.
• دمای مدل را پایین نگه دارید: در کارهای تحلیلی، خلاقیت مدل فایده‌ای ندارد.
• همه‌چیز را ثبت کنید: پرسش، ابزار اجراشده و جواب را نگه دارید تا خطا قابل پیگیری باشد.

نمونه عملی: این الگو در Caren Enterprise AI

در دستیار سازمانی Caren Enterprise AI، محصولی از کارن تکنولوژی، مدل از بین ۱۶ ابزار داده انتخاب می‌کند و این حلقه تا ۶ دور ادامه پیدا می‌کند. هر ابزار با هویت و دسترسی همان کاربر اجرا می‌شود و ۸ ابزار حساس، مثل سود و زیان سالانه، فقط برای نقش‌های مدیریتی است. در دستور مدل هم صریحاً آمده است که هیچ عددی از خودش نسازد.

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

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