خطای هوش مصنوعی که در فارسی معمولاً «توهم» ترجمه میشود، رایج‌ترین شکایت از این فناوری است: سیستم چیزی میگوید که درست نیست، و با همان اطمینانی میگوید که چیز درست را.
بیشتر متن‌هایی که در این باره خوانده‌ام، آن را مثل یک اشکال توصیف می‌کنند — چیزی که در نسخهٔ بعدی درست میشود.
نمیشود. و فهمیدن دلیلش، تمام تفاوت را در نحوهٔ ساختن سیستم میسازد.
چرا اتفاق می‌افتد
کار یک مدل زبانی، در ساده‌ترین بیان، این است: با توجه به آنچه تا اینجا آمده، محتمل‌ترین ادامه را بساز.
توجه کنید که در این تعریف هیچ مرحله‌ای برای «بررسی درستی» نیست. مدل بین «این را می‌دانم» و «این را نمیدانم» تمایزی قائل نمیشود، چون چنین حالتی برایش وجود ندارد.
پس وقتی می‌پرسید «موجودی فلان محصول چقدر است» و مدل به انبار شما وصل نیست، متوقف نمیشود. محتمل‌ترین ادامه را میسازد — و آن ادامه روان و مطمئن است، چون از نوشته‌های مطمئن یاد گرفته.
این دروغ گفتن نیست. دروغ گفتن قصد میخواهد و دانستن حقیقت. اینجا هیچ‌کدام نیست.
چرا «توهم» اسم بدی است
اسم رایجش گمراهکننده است و همین گمراهی به تصمیم‌های بد منجر میشود.
«توهم» یعنی چیزی که نیست را دیدن — حالتی ذهنی که با حالت عادی فرق دارد. این تصور میسازد که سیستم معمولاً «می‌داند» و گاهی «توهم می‌زند».
واقعیت این است که سیستم هیچ‌وقت به آن معنا نمی‌داند. وقتی جواب درست می‌دهد و وقتی جواب غلط می‌دهد، دقیقاً همان کار را می‌کند. تنها تفاوت این است که در حالت اول، محتمل‌ترین ادامه اتفاقاً درست بوده.
نتیجهٔ عملی این تفاوت بزرگ است: اگر فکر کنید سیستم گاهی خطا می‌کند، دنبال کاهش نرخ خطا می‌گردید. اگر بفهمید که همیشه همان کار را می‌کند، دنبال طراحی‌ای می‌گردید که نگذارد دربارهٔ چیزی که نمی‌داند حرف بزند.
کدام خطاها خطرناک‌ترند
همهٔ خطاها یکسان نیستند و اولویت مهار باید بر اساس همین باشد.
خطای آشکار — جمله‌ای که به‌وضوح بی‌ربط است. آزاردهنده و بی‌خطر، چون فوری دیده میشود.
خطای معقول — عدد، تاریخ یا شرطی که کاملاً منطقی به نظر می‌رسد و غلط است. این خطرناکترین است. کسی بررسی‌اش نمیکند چون دلیلی برای شک ندارد، و بعد به تعهدی تبدیل میشود که کسبوکار باید پایش بایستد.
خطای ترکیبی — نود درصد جواب درست است و یک جمله‌اش ساخته. سخت‌ترین برای تشخیص، چون درستیِ بقیه اعتماد میسازد.
اگر بخواهید فقط یک چیز را مهار کنید، دستهٔ دوم را مهار کنید: هر عدد، تاریخ و شرطی که به مشتری گفته میشود.
چهار کاری که مهارش می‌کند
هیچ‌کدام به انتخاب مدل مربوط نیستند. همه طراحی‌اند.
یک: واقعیت از منبع، نه از مدل
قاعده: هر جمله‌ای که به عدد، موجودی، وضعیت سفارش، تاریخ یا شرط اشاره می‌کند، باید از یک منبع واقعی خوانده شود.
شکل درستش این است که مدل فقط بفهمد پرسش چیست، و پاسخ از منبع بیاید. اگر مدل خودش پاسخ را بسازد، هر لحظه ممکن است چیزی بسازد که در هیچ سیستمی نیست.
تفاوت ظریف ولی تعیین‌کننده است: در طراحی درست، سیستم نمی‌تواند تاریخ تحویل اشتباه بگوید — نه چون درست میگوید، بلکه چون اصلاً اجازهٔ ساختن آن جمله را ندارد.
دو: «نمیدانم» باید یک پاسخ مجاز باشد
سیستمی که مجبور است همیشه جواب بدهد، وقتی نداند هم جواب می‌دهد.
پس باید صراحتاً تعریف شود که «این را نمیدانم، پیگیری می‌کنم» یک خروجی معتبر است، نه شکست. و مهم‌تر، باید مسیری داشته باشد: پرونده‌ای که فردا صبح روی میز کسی باشد.
در عمل، همین یک جمله بیشترین اثر را بر اعتماد مشتری دارد — چون مشتری خیلی زود می‌فهمد طرفش کِی مطمئن است و کِی نیست.
سه: توانایی را بگیرید، نه اینکه ممنوع کنید
اگر تنها چیزی که جلوی سیستم را می‌گیرد جمله‌ای است مثل «هرگز تخفیف نده»، شما حدی ندارید؛ یک درخواست دارید. مدل درخواست را معمولاً رعایت می‌کند و گاهی نه.
حد واقعی این است که سیستم به فهرست تخفیف‌ها دسترسی نداشته باشد. چیزی که ندارد را نمی‌تواند بگوید.
چهار: خطا باید جایی ثبت شود که خوانده میشود
بیشتر خطاها در ساعت‌هایی رخ می‌دهند که کسی نگاه نمیکند. اگر ثبت نشوند، فردا هیچ نشانه‌ای از آن‌ها نیست — فقط یک مشتری که دیگر پیام نداد.
لازم نیست پیچیده باشد: یک فهرست ساده از گفتگوهایی که به نتیجه نرسیدند، با دلیلش، که صبح خوانده شود.
دو موقعیتی که خطا را بیشتر می‌کنند
اینها را می‌نویسم چون قابل پیش‌بینی‌اند و میشود از قبل برایشان آماده شد.
وقتی پرسش مبهم است. «همون قبلیه چی شد؟» — اگر سیستم سابقه نداشته باشد، به‌جای اینکه بپرسد کدام، حدس می‌زند. و حدسش را مثل واقعیت میگوید.
راهش این است که ابهام به‌عنوان یک حالت تعریف شود: وقتی چند تفسیر ممکن است، سیستم باید بپرسد نه انتخاب کند. این یک قاعدهٔ ساده است و کمتر کسی می‌نویسدش.
وقتی مشتری اصرار می‌کند. اگر کسی چند بار بپرسد و جواب نگیرد و بعد بنویسد «پس یعنی هست دیگه؟»، سیستم گرایش دارد که همراهی کند. این خاصیت شناخته‌شده‌ای است: مدل‌ها به تأیید کردنِ فرضِ داخل پرسش تمایل دارند.
راهش این است که پاسخ «نمیدانم» نباید با اصرار عوض شود. اگر بار اول نمی‌دانست، بار سوم هم نمی‌داند.
چطور بفهمید سیستمتان چقدر این کار را می‌کند
اگر سیستمی در حال کار دارید، این را میشود اندازه گرفت — و تقریباً هیچ‌کس نمی‌گیرد.
روش ساده: هفته‌ای بیست گفتگوی تصادفی را بخوانید. نه گزارش را؛ خود گفتگوها را، از اول تا آخر. برای هرکدام یک چیز را علامت بزنید: آیا جمله‌ای هست که سیستم گفته و شما نمی‌توانید منبعش را نشان بدهید؟
اگر در بیست گفتگو حتی یکی پیدا شد، عددش را بنویسید و هفتهٔ بعد دوباره بشمارید. این تنها معیاری است که واقعاً میگوید سیستم شما چقدر قابل اعتماد است — و در هیچ داشبوردی وجود ندارد، چون سیستم نمی‌داند کِی چیزی ساخته.
نکتهٔ مهم: این کار را کسی باید بکند که کسبوکار را می‌شناسد، نه کسی که سیستم را ساخته. جملهٔ ساخته‌شده معمولاً از نظر فنی بی‌عیب است؛ فقط از نظر واقعیت غلط است.
این برای کسبوکار ایرانی یعنی چه
اول، خطا در فارسی بیشتر است. حجم متن فارسی که این مدل‌ها دیده‌اند از انگلیسی بسیار کمتر است، و در موضوعات محلی — قوانین، رویه‌های اداری، جزئیات بازار داخلی — این تفاوت بیشتر میشود. سیستمی که در انگلیسی قابل اعتماد به نظر می‌رسد، لزوماً در فارسی نیست.
دوم، اطلاعات محلی را جدی‌تر بسنجید. هر چیزی که به رویه‌های اداری، تعطیلات، یا شرایط محلی مربوط است، احتمال خطای بالاتری دارد. اینها باید حتماً از منبع خوانده شوند.
سوم، هزینهٔ خطا در گفتگوی فروش فوری است. وقتی تمام مذاکره در پیام‌رسان انجام میشود، جملهٔ غلط سیستم بلافاصله تعهد میسازد — و پس گرفتنش، برخلاف یک صفحهٔ وب، در متن گفتگو ثبت شده و قابل استناد است.
چهارم، تشخیصش را به مشتری نسپارید. فرض نکنید مشتری متوجه میشود که این جواب از سیستم آمده و ممکن است غلط باشد. اگر سیستم چیزی گفت، از نظر مشتری شما گفته‌اید.
آزمونی که در ده دقیقه انجام میشود
اگر سیستمی دارید یا در حال انتخاب یکی هستید، این سه پرسش را بدهید:
۱. چیزی بپرسید که مطمئنید نمی‌داند. موجودی یک محصول خاص در انبار خودتان. اگر با اطمینان جواب داد، مهم‌ترین چیز را فهمیده‌اید.
۲. چیزی بپرسید که وجود ندارد. «گارانتی ده ساله‌تون شامل چی می‌شه؟» — وقتی چنین گارانتی‌ای ندارید. سیستم خوب میگوید چنین چیزی نداریم؛ سیستم بد شرایطش را توضیح می‌دهد.
۳. همان پرسش را سه بار بپرسید. اگر سه جواب متفاوت گرفتید، روی رفتارش نمیشود حساب کرد.
هر سه دانش فنی نمی‌خواهند و از هر جلسهٔ ارائه‌ای گویاترند.
کجا این خطا اصلاً اهمیتی ندارد
برای اینکه تصویر متوازن باشد: در بخش بزرگی از کاربردها، این خطا مسئله نیست.
وقتی خروجی به مشتری نمی‌رسد. خلاصه کردن صد گفتگو برای خودتان، پیدا کردن الگو، دسته‌بندی پیام‌ها برای مسیریابی داخلی. اگر اشتباه کند، شما می‌بینید و اصلاح می‌کنید. هیچ تعهدی ساخته نمیشود.
وقتی خروجی پیش‌نویس است. متن آگهی، توضیح محصول، پاسخ آماده — به شرطی که کسی پیش از انتشار بخواندش. اینجا خطا فقط یک ویرایش است.
وقتی کار، ترجیح است نه واقعیت. پیشنهاد چند عنوان، چند جمله‌بندی، چند ایده. اینجا اصلاً «درست و غلط» معنا ندارد.
الگوی مشترک هر سه روشن است: خطا وقتی گران است که خروجی مستقیم و بدون بازبینی به بیرون برود. پس تقسیم‌بندی کار به «مستقیم به مشتری» و «با بازبینی»، بیشتر از هر تنظیمات فنی، ریسک را مهار می‌کند.
و نتیجهٔ عملی‌اش این است: اگر تازه شروع کرده‌اید، از دستهٔ دوم شروع کنید. هم ارزش میسازد، هم هیچ ریسکی ندارد، و هم به شما یاد می‌دهد این فناوری کجا خوب است و کجا نه — پیش از اینکه با مشتری واقعی امتحانش کنید.
چیزی که نباید انتظار داشت
صادقانه: این خطا به صفر نمی‌رسد.
هر کسی که وعده بدهد سیستمش هیچ‌وقت اشتباه نمیکند، یا نمی‌داند چه میگوید یا امیدوار است شما ندانید.
آنچه شدنی است، این است: خطا در جاهایی که هزینه دارند بسته شود، در جاهایی که هزینه ندارند تحمل شود، و وقتی رخ داد دیده شود.
این با «بی‌نقص بودن» فرق دارد و از آن مفیدتر است — چون قابل ساختن است.
جمع‌بندی
خطای هوش مصنوعی از روش کارش می‌آید، نه از کیفیت ساختش. سیستمی که کارش پیشبینی ادامه است، وقتی نداند هم ادامهای میسازد.
پس پرسش درست این نیست که «کدام مدل کمتر اشتباه می‌کند»، بلکه این است که «سیستم من طوری ساخته شده که اشتباهش کجا می‌افتد و چقدر خرج برمی‌دارد».
جواب دوم در دست شماست. جواب اول نیست.
هوش مصنوعی چیست همین سازوکار را از پایه توضیح می‌دهد، و هوش مصنوعی عاملی و جایی که نباید اختیار داد دربارهٔ حدی است که در بند سوم گفتم. و امنیت اطلاعات مشتری دربارهٔ خطای دیگری است که با اطمینان اتفاق می‌افتد: دادهٔ مشتری که جایی می‌رود که نباید.