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