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