از یک فرایند دستی تا عامل هوش مصنوعی؛ نقشه راه واقعی پیاده‌سازی در شرکت‌ها
پیاده‌سازی عامل هوش مصنوعی نباید با انتخاب مدل یا ابزار شروع شود؛ نقطه شروع، یک فرایند واقعی و قابل اندازه‌گیری در کسب‌وکار است. ابتدا فرایند را مستند کنید، گلوگاه را پیدا کنید و کارهای قانون‌محور را از وظایف نیازمند تحلیل جدا کنید. سپس منابع داده، سطح دسترسی، تأیید انسانی و شاخص موفقیت را مشخص کنید. نسخه اولیه باید کوچک و قابل آزمایش باشد و تنها پس از اثبات ارزش، به نرم‌افزارهای واقعی سازمان متصل و توسعه داده شود. هدف نهایی «داشتن هوش مصنوعی» نیست؛ هدف ساخت فرایندی سریع‌تر، دقیق‌تر و کمتر وابسته به پیگیری دستی است.
ساعت ۹ صبح است. کارشناس فروش فایل مشتریان را باز می‌کند، پیام‌های دیروز را مرور می‌کند و سعی می‌کند به یاد بیاورد کدام مشتری گفته بود «هفته بعد تماس بگیرید». کمی بعد یکی از همکاران در پیام‌رسان می‌پرسد آخرین وضعیت سفارش فلان مشتری چیست. برای پیدا کردن جواب باید نرم‌افزار مدیریت ارتباط با مشتری، چند پیام و احتمالاً یک فایل اکسل دیگر بررسی شود.
ساعت ۱۱ یک مشتری پیگیری نشده، یک درخواست در صندوق ایمیل مانده و گزارشی که مدیر فروش می‌خواهد هنوز آماده نیست.
هیچ‌کس هم لزوماً کم‌کاری نکرده است.
مشکل جای دیگری است: فرایندی که باید توسط سیستم مدیریت شود، هنوز به حافظه و پیگیری آدم‌ها وابسته است.
در چنین شرایطی معمولاً یک پیشنهاد جذاب مطرح می‌شود: «بیایید برایش عامل هوش مصنوعی بسازیم.»
اما اینجا دقیقاً همان جایی است که بسیاری از پروژه‌های هوش مصنوعی مسیر اشتباه را شروع می‌کنند.
پیاده‌سازی عامل هوش مصنوعی نباید با انتخاب مدل، خرید اشتراک یک ابزار یا ساخت یک چت‌بات شروع شود. نقطه شروع، خود فرایند کسب‌وکار است.
اگر فرایند خراب، مبهم یا بدون داده باشد، اضافه کردن هوش مصنوعی فقط همان آشفتگی را سریع‌تر می‌کند.
پس سؤال این مقاله این نیست که «چطور یک عامل هوش مصنوعی بسازیم؟»
سؤال کاربردی‌تر این است:
چطور یک فرایند واقعی در شرکت را از حالت دستی، مرحله‌به‌مرحله به یک فرایند هوشمند و قابل کنترل تبدیل کنیم؟
آیا واقعاً باید از «عامل هوش مصنوعی» شروع کنیم؟
خیر؛ و همین پاسخ کوتاه می‌تواند جلوی هزینه زیادی را بگیرد.
اولین اشتباه این است که فناوری را قبل از مسئله انتخاب کنیم.
مدیر می‌بیند شرکت‌های دیگر درباره عامل‌های هوش مصنوعی صحبت می‌کنند و می‌پرسد: «ما کجا می‌توانیم عامل هوش مصنوعی داشته باشیم؟»
سؤال بهتر این است:
کدام فرایند شرکت امروز زمان، پول یا فرصت زیادی از ما می‌گیرد و آیا هوش مصنوعی می‌تواند بخشی از آن را بهتر انجام دهد؟
ممکن است پاسخ اصلاً عامل هوش مصنوعی نباشد.
گاهی یک فرم بهتر، یک اتصال ساده میان دو نرم‌افزار، چند قانون مشخص در سیستم مدیریت ارتباط با مشتری یا یک اتوماسیون معمولی مسئله را حل می‌کند.
در مقابل، بعضی فرایندها واقعاً به چیزی بیشتر از چند قانون ثابت نیاز دارند. سیستم باید اطلاعات مختلف را بخواند، وضعیت را تحلیل کند، تصمیم بگیرد چه اقدامی مناسب است، از ابزار مشخصی استفاده کند و بر اساس نتیجه مرحله بعد را انتخاب کند.
اینجاست که عامل هوش مصنوعی معنا پیدا می‌کند.
پس قبل از ساخت Agent، باید تفاوت آن با اتوماسیون معمولی را بشناسیم.
عامل هوش مصنوعی چه تفاوتی با اتوماسیون معمولی دارد؟
اتوماسیون سنتی معمولاً بر یک منطق نسبتاً مشخص بنا شده است:
اگر اتفاق «الف» افتاد، کار «ب» را انجام بده.
برای مثال، اگر فرم سایت تکمیل شد، اطلاعات مشتری را وارد نرم‌افزار مدیریت ارتباط با مشتری کن و یک پیام برای کارشناس فروش بفرست.
این نوع اتوماسیون همچنان بسیار ارزشمند است و بسیاری از شرکت‌ها حتی هنوز از تمام ظرفیت آن استفاده نکرده‌اند.
عامل هوش مصنوعی زمانی ارزش بیشتری ایجاد می‌کند که میان ورودی و اقدام، نیاز به تفسیر، تصمیم یا انتخاب ابزار وجود داشته باشد.
فرض کنید درخواست مشتری وارد می‌شود.
عامل می‌تواند متن درخواست را بخواند، موضوع آن را تشخیص دهد، سابقه مشتری را بررسی کند، اطلاعات مرتبط را از سیستم پیدا کند، اقدام بعدی را پیشنهاد دهد و در محدوده‌ای که برایش تعریف شده، آن اقدام را انجام دهد.
تفاوت را می‌توان ساده کرد:
| روش | نحوه کار | مناسب برای |
|---|---|---|
| فرایند دستی | انسان تصمیم می‌گیرد و اجرا می‌کند | کارهای متغیر و بدون سیستم |
| اتوماسیون سنتی | قوانین از قبل تعریف‌شده اجرا می‌شوند | کارهای تکراری و قابل پیش‌بینی |
| عامل هوش مصنوعی | اطلاعات را تفسیر می‌کند و بین اقدامات مجاز تصمیم می‌گیرد | فرایندهای نیمه‌ساختاریافته و چندمرحله‌ای |
بنابراین هدف نباید این باشد که هر اتوماسیونی را با هوش مصنوعی جایگزین کنیم.
هدف، پیدا کردن ترکیب درست انسان، نرم‌افزار، اتوماسیون و هوش مصنوعی است.
اما کدام فرایند ارزش شروع کردن دارد؟
کدام فرایند شرکت بهترین نقطه شروع برای عامل هوش مصنوعی است؟
فرض کنید در یک شرکت ۳۰ فرایند دستی وجود دارد. قرار نیست از روز اول ۳۰ عامل هوش مصنوعی بسازیم.
بهتر است فرایندی را انتخاب کنیم که سه ویژگی داشته باشد:
تکرار زیاد + هزینه یا زمان قابل توجه + امکان اندازه‌گیری نتیجه
برای مثال، این فرایندها معمولاً ارزش بررسی دارند:
- دسته‌بندی و پاسخ اولیه به درخواست‌های مشتریان
- پیگیری سرنخ‌های فروش
- استخراج اطلاعات از اسناد و فاکتورها
- آماده‌سازی گزارش‌های تکراری
- بررسی اولیه رزومه‌ها
- جمع‌آوری اطلاعات از چند سیستم
- ثبت و به‌روزرسانی اطلاعات در نرم‌افزارها
- خلاصه‌سازی مکالمات و ایجاد وظیفه بعدی
- کنترل اولیه اسناد بر اساس قواعد مشخص
یک تست ساده هم وجود دارد.
از کارمندان بپرسید:
«کدام کار را هر هفته انجام می‌دهید که تکراری است، زمان زیادی می‌گیرد و دوست دارید دیگر مجبور نباشید خودتان انجامش دهید؟»
پاسخ‌های این سؤال معمولاً معدن Use Case هستند.
اما تکراری بودن به‌تنهایی کافی نیست.
چه فرایندهایی فعلاً گزینه خوبی نیستند؟
فرایندی که سالی دو بار انجام می‌شود، داده مشخصی ندارد، هر بار کاملاً متفاوت است یا اشتباه در آن می‌تواند پیامد حقوقی و مالی بسیار بزرگی داشته باشد، احتمالاً اولین گزینه خوبی نیست.
همچنین اگر خود تیم نمی‌تواند توضیح دهد فرایند فعلی چگونه انجام می‌شود، هوش مصنوعی هم قرار نیست به شکل جادویی آن را مرتب کند.
پس بعد از انتخاب نامزد مناسب، اولین کار فنی نیست.
باید قلم و کاغذ را برداریم.
مرحله اول: قبل از هوش مصنوعی، فرایند را روی کاغذ بیاورید
فرض کنیم مشکل تیم فروش، پیگیری مشتریان است.
گفتن اینکه «پیگیری‌ها ضعیف است» برای طراحی سیستم کافی نیست.
باید فرایند واقعی را باز کنیم:
مشتری از کجا وارد می‌شود؟
اطلاعات او کجا ثبت می‌شود؟
چه کسی اولین تماس را انجام می‌دهد؟
نتیجه تماس کجا نوشته می‌شود؟
زمان پیگیری بعدی چگونه تعیین می‌شود؟
اگر کارشناس فراموش کند چه اتفاقی می‌افتد؟
مدیر چگونه متوجه مشتریان رهاشده می‌شود؟
وقتی این مسیر روی کاغذ قرار می‌گیرد، معمولاً چیزهای جالبی دیده می‌شود.
مثلاً متوجه می‌شویم اطلاعات مشتری ابتدا در فرم سایت است، بعد در پیام‌رسان فرستاده می‌شود، سپس کارشناس بخشی از آن را در نرم‌افزار ثبت می‌کند و زمان پیگیری بعدی را در تقویم شخصی خودش می‌نویسد.
این یعنی قبل از مسئله هوش مصنوعی، یک مسئله فرایندی و داده‌ای داریم.
تجربه طراحی سیستم‌های سازمانی نشان می‌دهد بخش مهمی از تحلیل اولیه دقیقاً همین‌جاست. در توسعه نرم‌افزار مارون سیستم نیز منطقی‌تر است پروژه‌های اتوماسیون هوشمند از تحلیل فرایند آغاز شوند، نه از انتخاب یک مدل زبانی؛ چون تا وقتی مسیر کار مشخص نباشد، نمی‌توان تعیین کرد عامل باید چه ببیند، چه تصمیمی بگیرد و به چه چیزی دسترسی داشته باشد.
حالا که فرایند را می‌بینیم، می‌توانیم گلوگاه واقعی را پیدا کنیم.
مرحله دوم: گلوگاه واقعی را پیدا کنید، نه جذاب‌ترین قسمت را
هر مرحله دستی الزاماً نیازمند خودکارسازی نیست.
گاهی یک کار ۳۰ ثانیه طول می‌کشد و روزی پنج بار انجام می‌شود. خودکار کردن آن شاید از نظر فنی جالب باشد، اما ارزش اقتصادی چندانی ایجاد نمی‌کند.
در مقابل، ممکن است کارشناسان فروش روزانه مجموعاً سه ساعت صرف پیدا کردن اطلاعات، مرور مکالمات قبلی و تعیین پیگیری بعدی کنند.
اینجا فرصت واقعی وجود دارد.
برای هر مرحله سه سؤال بپرسید:
چقدر تکرار می‌شود؟
چقدر زمان می‌گیرد؟
اشتباه در آن چقدر هزینه ایجاد می‌کند؟
بعد سؤال چهارم را اضافه کنید:
اگر این مرحله سریع‌تر یا دقیق‌تر شود، چه شاخص کسب‌وکاری بهتر می‌شود؟
اگر هیچ پاسخ مشخصی برای سؤال چهارم نداریم، شاید پروژه فقط یک نمایش جذاب از هوش مصنوعی باشد.
اما پیدا کردن گلوگاه هنوز به این معنی نیست که همه آن را به مدل هوش مصنوعی بسپاریم.
مرحله سوم: مشخص کنید کدام کار قانون می‌خواهد و کدام کار هوش
یکی از بهترین راه‌ها برای کنترل هزینه و پیچیدگی، جدا کردن وظایف قطعی از وظایف تفسیری است.
برای مثال:
«اگر مشتری ۴۸ ساعت پاسخ نداده، یک وظیفه پیگیری ایجاد کن.»
این کار احتمالاً به مدل زبانی نیاز ندارد.
اما:
«با توجه به مکالمات قبلی، دلیل احتمالی تردید مشتری را تشخیص بده و مناسب‌ترین اقدام بعدی را پیشنهاد کن.»
اینجا استفاده از مدل هوش مصنوعی منطقی‌تر می‌شود.
معماری خوب قرار نیست همه‌چیز را به هوش مصنوعی بسپارد.
قسمت‌های قطعی را نرم‌افزار و قواعد انجام می‌دهند؛ قسمت‌هایی که نیازمند فهم زبان، استخراج مفهوم، دسته‌بندی یا تصمیم در شرایط متغیر هستند به مدل سپرده می‌شوند.
این تفکیک معمولاً سیستم را ارزان‌تر، سریع‌تر، قابل پیش‌بینی‌تر و قابل کنترل‌تر می‌کند.
حالا می‌توانیم سراغ سوخت اصلی چنین سیستمی برویم: داده.
مرحله چهارم: عامل هوش مصنوعی قرار است اطلاعاتش را از کجا بیاورد؟
عامل بدون Context مناسب، فقط یک مدل عمومی است.
اگر قرار است وضعیت مشتری را تحلیل کند، احتمالاً به بخشی از اطلاعات سیستم مدیریت ارتباط با مشتری نیاز دارد.
اگر قرار است درخواست پشتیبانی را پاسخ دهد، شاید به پایگاه دانش و تاریخچه درخواست‌ها نیاز داشته باشد.
اگر قرار است وضعیت سفارش را بررسی کند، باید به نرم‌افزار فروش یا برنامه‌ریزی منابع سازمان متصل شود.
بنابراین برای هر Use Case یک نقشه داده تهیه کنید:
| نیاز عامل | منبع |
|---|---|
| مشخصات مشتری | مدیریت ارتباط با مشتری |
| مکالمات قبلی | سامانه پشتیبانی یا پیام‌رسان |
| وضعیت سفارش | سامانه فروش |
| قوانین شرکت | پایگاه دانش |
| موجودی | انبار |
| فاکتور | نرم‌افزار مالی |
اما یک نکته بسیار مهم وجود دارد:
عامل نباید صرفاً چون می‌تواند به اطلاعات دسترسی داشته باشد، به همه اطلاعات دسترسی بگیرد.
اگر فقط وضعیت سفارش لازم است، دسترسی به کل اطلاعات مالی مشتری توجیهی ندارد.
این موضوع ما را از «داده» به یکی از مهم‌ترین تصمیم‌های معماری می‌رساند: سطح اختیار.
مرحله پنجم: عامل هوش مصنوعی تا کجا اجازه دارد جلو برود؟
همه Agentها نباید خودمختار باشند.
می‌توان سطح اختیار را مرحله‌ای تعریف کرد.
سطح اول: فقط مشاهده
عامل اطلاعات را می‌خواند و تحلیل می‌کند، اما هیچ تغییری در سیستم ایجاد نمی‌کند.
سطح دوم: پیشنهاد
عامل اقدام مناسب را پیشنهاد می‌دهد و انسان تصمیم نهایی را می‌گیرد.
سطح سوم: اقدام با تأیید
عامل کار را آماده می‌کند اما برای اجرای عملیات حساس منتظر تأیید انسان می‌ماند.
سطح چهارم: اقدام مستقل در محدوده مشخص
عامل فقط برای عملیات کم‌ریسک و از قبل تعریف‌شده اجازه اجرای خودکار دارد.
برای بسیاری از شرکت‌ها، شروع از سطح دوم یا سوم منطقی‌تر از دادن اختیار کامل است.
مثلاً عامل می‌تواند پاسخ ایمیل را آماده کند، اما کارشناس ارسال را تأیید کند. بعد از چند هزار تعامل و اندازه‌گیری کیفیت، بعضی پاسخ‌های کم‌ریسک می‌توانند خودکار شوند.
این رویکرد یک مزیت مهم دارد:
اعتماد به سیستم به‌تدریج و با داده واقعی ساخته می‌شود، نه با امید.
و همین منطق باید در اندازه پروژه اولیه هم رعایت شود.
مرحله ششم: اول یک مسئله کوچک را حل کنید، نه کل شرکت را
پروژه‌ای با این عنوان معمولاً خطرناک است:
«می‌خواهیم کل فرایند فروش را هوشمند کنیم.»
دامنه نامشخص است، موفقیت تعریف نشده و احتمالاً هر واحد انتظار متفاوتی دارد.
در مقابل:
«می‌خواهیم سرنخ‌هایی را که بعد از اولین تماس پیگیری نشده‌اند شناسایی کنیم و اقدام بعدی مناسب را به کارشناس پیشنهاد دهیم.»
این یک پروژه قابل آزمایش است.
برای نسخه اولیه باید مشخص باشد:
ورودی چیست؟
عامل چه کاری انجام می‌دهد؟
به چه ابزارهایی دسترسی دارد؟
خروجی چیست؟
موفقیت را با چه عددی می‌سنجیم؟
نسخه اولیه لازم نیست زیبا یا کامل باشد.
باید یک چیز را ثابت کند:
آیا این راهکار واقعاً فرایند را بهتر می‌کند؟
اگر پاسخ مثبت بود، تازه زمان اتصال عمیق‌تر به زیرساخت شرکت می‌رسد.
مرحله هفتم: عامل را به نرم‌افزارهای واقعی شرکت متصل کنید
یک عامل هوش مصنوعی که فقط در یک صفحه چت زندگی می‌کند، برای بسیاری از فرایندهای سازمانی ارزش محدودی دارد.
ارزش جدی زمانی ایجاد می‌شود که بتواند در محدوده کنترل‌شده با سیستم‌های موجود کار کند.
این اتصال معمولاً از طریق رابط‌های برنامه‌نویسی انجام می‌شود.
عامل ممکن است لازم باشد اطلاعات مشتری را بخواند، سفارش را بررسی کند، یک وظیفه ایجاد کند، گزارش را در پنل مدیریتی ثبت کند یا داده مشخصی را به نرم‌افزار دیگری منتقل کند.
در این مرحله یکی از چالش‌های واقعی شرکت‌های ایرانی ظاهر می‌شود: همه نرم‌افزارها رابط برنامه‌نویسی مناسب ندارند و گاهی اطلاعات بین چند سیستم قدیمی، فایل اکسل و فرایندهای دستی پخش شده است.
در چنین شرایطی مسئله دیگر فقط «ساخت عامل» نیست.
ممکن است به یک لایه نرم‌افزاری اختصاصی نیاز داشته باشیم که سیستم‌های موجود، داده‌ها، قوانین کسب‌وکار و هوش مصنوعی را به یکدیگر متصل کند.
اینجاست که توسعه نرم‌افزار و هوش مصنوعی عملاً به یک پروژه واحد تبدیل می‌شوند.
مرحله هشتم: انسان را حذف نکنید؛ نقش او را تغییر دهید
یکی از برداشت‌های اشتباه درباره Agentها این است که موفقیت پروژه را با تعداد آدم‌هایی بسنجیم که از فرایند حذف شده‌اند.
معیار بهتری وجود دارد:
چقدر از وقت انسان از کارهای کم‌ارزش به تصمیم‌های باارزش منتقل شده است؟
فرض کنید کارشناس پشتیبانی روزانه ۱۰۰ درخواست دریافت می‌کند.
اگر عامل بتواند درخواست‌ها را دسته‌بندی کند، اطلاعات مشتری را پیدا کند، پاسخ اولیه را آماده کند و موارد حساس را مشخص کند، کارشناس دیگر مجبور نیست ۱۰۰ بار یک فرایند تکراری را از صفر انجام دهد.
اما موارد پیچیده همچنان به انسان می‌رسند.
این همان تأیید و نظارت انسانی است.
هدف، ساختن سازمانی بدون انسان نیست.
هدف، ساختن فرایندی است که انسان مجبور نباشد کارهایی را انجام دهد که ماشین می‌تواند با کیفیت مناسب انجام دهد.
و هرچه اختیار ماشین بیشتر شود، سؤال امنیت جدی‌تر می‌شود.
مرحله نهم: امنیت را بعد از ساخت Agent اضافه نکنید
اگر عامل فقط متن تولید می‌کند، دامنه آسیب یک اشتباه محدودتر است.
اما اگر به ایمیل، فایل‌ها، مدیریت ارتباط با مشتری، پایگاه داده یا رابط‌های برنامه‌نویسی دسترسی دارد، شرایط تغییر می‌کند.
در اینجا باید اصل حداقل دسترسی اجرا شود.
عامل فقط باید به اطلاعات و ابزارهایی دسترسی داشته باشد که برای همان وظیفه نیاز دارد.
همچنین عملیات حساس باید محدود شوند. حذف داده، انتقال اطلاعات محرمانه، پرداخت مالی یا تغییر Permission کاربران نباید بدون کنترل مناسب در اختیار یک مدل قرار بگیرد.
در مقاله «امنیت عامل‌های هوش مصنوعی» می‌توان این موضوع را عمیق‌تر بررسی کرد؛ از محیط ایزوله و جداسازی زمان اجرا تا کنترل شبکه و تأیید انسانی.
قاعده مدیریتی اما ساده است:
سیستم را با این فرض طراحی نکنید که عامل هیچ‌وقت اشتباه نمی‌کند؛ طوری طراحی کنید که اگر اشتباه کرد، نتواند آسیب بزرگی ایجاد کند.
حالا فقط یک سؤال باقی می‌ماند: از کجا بفهمیم تمام این کارها ارزش داشته است؟
مرحله دهم: موفقیت عامل هوش مصنوعی را با عدد اندازه بگیرید
«خیلی خوب کار می‌کند» شاخص نیست.
«تیم از آن راضی است» هم به‌تنهایی کافی نیست.
قبل از اجرای پروژه، چند عدد پایه ثبت کنید.
مثلاً:
زمان متوسط پاسخ‌گویی قبل از اجرا چقدر بود؟
هر کارشناس چند ساعت در هفته صرف کار دستی می‌کرد؟
چند درصد سرنخ‌ها بدون پیگیری می‌ماندند؟
هزینه پردازش هر درخواست چقدر بود؟
نرخ خطای انسانی چقدر بود؟
سپس همان شاخص‌ها را بعد از اجرای Agent اندازه بگیرید.
برای مثال:
قبل: بررسی هر درخواست ۱۲ دقیقه
بعد: بررسی هر درخواست ۴ دقیقه
یا:
قبل: ۱۸ درصد سرنخ‌ها بدون پیگیری
بعد: ۶ درصد
اینجا دیگر درباره «جذاب بودن هوش مصنوعی» صحبت نمی‌کنیم.
درباره بازگشت سرمایه صحبت می‌کنیم.
و این دقیقاً همان نقطه‌ای است که یک آزمایش فناوری می‌تواند به یک قابلیت واقعی کسب‌وکار تبدیل شود.
یک سناریوی واقعی: از پیگیری دستی فروش تا عامل هوش مصنوعی
فرض کنید یک شرکت خدماتی ماهانه ۸۰۰ سرنخ جدید دریافت می‌کند.
اطلاعات وارد نرم‌افزار مدیریت ارتباط با مشتری می‌شود، اما ادامه کار تا حد زیادی وابسته به کارشناسان است.
یکی از مشتریان می‌گوید:
«قیمت خوبه، اجازه بدید با شریکم صحبت کنم. سه‌شنبه تماس بگیرید.»
کارشناس یادداشت می‌کند.
سه‌شنبه شلوغ است و تماس انجام نمی‌شود.
پنج‌شنبه مشتری از یک رقیب خرید می‌کند.
مشکل نبودن سرنخ نبود. مشکل شکستن فرایند پیگیری بود.
حالا همان مسیر را مرحله‌ای بازطراحی کنیم.
مرحله اول؛ ثبت ساختاریافته
تمام سرنخ‌ها و تعاملات باید در یک نقطه قابل اتکا ثبت شوند.
مرحله دوم؛ اتوماسیون ساده
اگر زمان پیگیری رسید، سیستم به کارشناس یادآوری کند.
هنوز Agent لازم نداریم.
مرحله سوم؛ اضافه شدن هوش
عامل مکالمه قبلی را تحلیل می‌کند و می‌فهمد مشتری درباره قیمت تردید داشته و باید سه‌شنبه پیگیری شود.
مرحله چهارم؛ پیشنهاد اقدام
عامل خلاصه‌ای برای کارشناس آماده می‌کند:
«مشتری به خدمات علاقه‌مند است؛ مانع اصلی تصمیم، هماهنگی با شریک است. امروز زمان پیگیری تعیین‌شده است.»
حتی می‌تواند متن پیشنهادی پیگیری را آماده کند.
مرحله پنجم؛ اقدام کنترل‌شده
در صورت تعریف سیاست مناسب، عامل می‌تواند برای گروه مشخصی از مشتریان پیام پیگیری را آماده کند و پس از تأیید کارشناس ارسال شود.
مرحله ششم؛ یادگیری از نتیجه
پاسخ مشتری دوباره وارد سیستم می‌شود و وضعیت به‌روزرسانی می‌شود.
اینجا دیگر Agent یک چت‌بات تزئینی کنار سایت نیست.
بخشی از Workflow واقعی فروش است.
این همان تفاوت میان «داشتن هوش مصنوعی» و ساختن یک قابلیت هوشمند در کسب‌وکار است.
هزینه پیاده‌سازی عامل هوش مصنوعی به چه عواملی بستگی دارد؟
برای چنین پروژه‌ای نمی‌توان بدون شناخت Use Case یک قیمت معنادار اعلام کرد.
دو Agent که ظاهراً هر دو «عامل فروش» هستند ممکن است از نظر پیچیدگی چند برابر با هم تفاوت داشته باشند.
هزینه معمولاً به این عوامل وابسته است:
تعداد سیستم‌های متصل: اتصال به یک نرم‌افزار ساده با اتصال هم‌زمان به مدیریت ارتباط با مشتری، حسابداری، ایمیل و پایگاه داده متفاوت است.
کیفیت زیرساخت فعلی: اگر داده‌ها ساختاریافته و رابط‌های برنامه‌نویسی آماده باشند، کار ساده‌تر می‌شود.
سطح استقلال: Agent پیشنهاددهنده معمولاً ساده‌تر از سیستمی است که خودش عملیات چندمرحله‌ای انجام می‌دهد.
حجم استفاده: تعداد درخواست‌ها و مصرف مدل روی هزینه عملیاتی اثر می‌گذارد.
امنیت: سیستم‌هایی که با داده مالی، پزشکی یا محرمانه سروکار دارند به کنترل‌های بیشتری نیاز دارند.
نیاز به نرم‌افزار اختصاصی: گاهی خود Agent بخش کوچکی از پروژه است و بخش اصلی، طراحی پنل، اتصال سیستم‌ها و مدیریت Workflow است.
بنابراین سؤال درست این نیست که «قیمت یک Agent چقدر است؟»
سؤال درست این است:
برای حل این فرایند مشخص، چه معماری‌ای واقعاً لازم داریم؟
چه زمانی نرم‌افزار اختصاصی کنار عامل هوش مصنوعی لازم می‌شود؟
همیشه نه.
اگر شرکت از ابزارهای مدرن با رابط‌های برنامه‌نویسی مناسب استفاده می‌کند و Workflow ساده است، شاید بتوان بخش زیادی از پروژه را با ابزارهای موجود پیاده‌سازی کرد.
اما شرایطی وجود دارد که نرم‌افزار اختصاصی منطقی‌تر می‌شود.
مثلاً وقتی چند سیستم باید به هم متصل شوند، قوانین داخلی شرکت خاص هستند، Permissionهای متفاوت لازم داریم، گزارش‌گیری مدیریتی اختصاصی نیاز است یا Agent باید داخل یک فرایند موجود شرکت قرار بگیرد.
در چنین پروژه‌ای مارون سیستم مسئله را صرفاً «اتصال یک مدل هوش مصنوعی» نمی‌بیند. طراحی می‌تواند شامل تحلیل فرایند، معماری داده، اتصال نرم‌افزارها، لایه هوش مصنوعی، سطح دسترسی، پنل مدیریتی و Monitoring باشد.
چون در پروژه سازمانی، Agent فقط یک قطعه از سیستم است؛ نه تمام سیستم.
اما حتی اگر ساخت آن از نظر فنی ممکن باشد، هنوز یک سؤال مهم وجود دارد: آیا شرکت واقعاً آماده است؟
چه کسب‌وکارهایی هنوز نباید سراغ عامل هوش مصنوعی بروند؟
هوش مصنوعی همیشه پاسخ درست نیست.
اگر فرایند شما هنوز مشخص نیست، اول فرایند را اصلاح کنید.
اگر داده‌ها در هیچ سیستم قابل اتکایی ثبت نمی‌شوند، اول مسئله داده را حل کنید.
اگر کاری بسیار کم تکرار می‌شود و هزینه انجام دستی آن ناچیز است، شاید اتوماسیون ارزش اقتصادی نداشته باشد.
اگر یک قانون ساده می‌تواند مسئله را حل کند، مدل زبانی اضافه نکنید.
اگر کوچک‌ترین خطا می‌تواند خسارت بزرگی ایجاد کند و امکان نظارت یا محدود کردن Agent وجود ندارد، فعلاً استقلال کامل ندهید.
و اگر تنها دلیل اجرای پروژه این است که «رقبا درباره هوش مصنوعی صحبت می‌کنند»، هنوز Use Case ندارید.
شرکتی که هنوز سفارش‌ها را بین چند فایل پراکنده مدیریت می‌کند، ممکن است قبل از Agent به یک سیستم عملیاتی درست نیاز داشته باشد.
گاهی بهترین پروژه هوش مصنوعی، پروژه‌ای است که بعد از تحلیل تصمیم می‌گیریم فعلاً انجامش ندهیم.
اشتباهات رایج در پیاده‌سازی عامل هوش مصنوعی چیست؟
شروع از ابزار به‌جای مسئله
اینکه ابتدا یک فناوری انتخاب کنیم و بعد دنبال جایی برای استفاده از آن بگردیم، مسیر را برعکس می‌کند.
تلاش برای خودکارسازی همه‌چیز
بهترین پروژه اولیه معمولاً کوچک، مشخص و قابل اندازه‌گیری است.
استفاده از هوش مصنوعی برای کارهای قطعی
اگر یک قانون ساده مسئله را حل می‌کند، نیازی به مدل زبانی نیست.
نادیده گرفتن داده‌های نامرتب
Agent نمی‌تواند اطلاعاتی را که وجود ندارند یا دائماً اشتباه ثبت می‌شوند جادویی اصلاح کند.
دادن اختیار بیش از حد
خودمختاری بیشتر همیشه به معنی سیستم بهتر نیست.
حذف زودهنگام انسان
در مراحل اولیه بهتر است عملیات حساس تأیید انسانی داشته باشند.
نداشتن شاخص موفقیت
اگر قبل از اجرا عدد پایه نداریم، بعداً نمی‌توانیم ثابت کنیم پروژه ارزش ایجاد کرده است.
ساخت نمونه نمایشی به‌جای سیستم واقعی
اینکه Agent در جلسه دمو پاسخ جذابی بدهد، با اینکه بتواند شش ماه پایدار در Workflow واقعی شرکت کار کند تفاوت زیادی دارد.
و همین آخرین مورد، مرز میان یک آزمایش هوش مصنوعی و یک سیستم سازمانی واقعی است.
آینده عامل‌های هوش مصنوعی در شرکت‌ها چگونه خواهد بود؟
احتمالاً ارزش اصلی Agentها در آینده نه در یک پنجره چت مستقل، بلکه در جایی دیده می‌شود که تقریباً نامرئی هستند: داخل فرایندهای روزمره شرکت.
عامل فروش در کنار مدیریت ارتباط با مشتری کار می‌کند. عامل پشتیبانی در کنار سامانه تیکتینگ قرار می‌گیرد. عامل مالی اسناد را بررسی می‌کند. عامل منابع انسانی بخشی از فرایند استخدام را آماده می‌کند و عامل مدیریتی اطلاعات چند سیستم را برای تصمیم‌گیری کنار هم قرار می‌دهد.
اما شرکت‌هایی بیشترین ارزش را از این فناوری خواهند گرفت که Agent را به‌عنوان یک «کارمند جادویی دیجیتال» نبینند.
عامل هوش مصنوعی یک جزء از معماری کسب‌وکار است.
به داده نیاز دارد، Permission می‌خواهد، باید به نرم‌افزارها متصل شود، نیازمند Monitoring است، هزینه عملیاتی دارد، ممکن است اشتباه کند و باید محدوده مسئولیت مشخصی داشته باشد.
در نتیجه رقابت آینده احتمالاً فقط بر سر این نیست که چه شرکتی به بهترین مدل هوش مصنوعی دسترسی دارد.
تفاوت واقعی را شرکتی ایجاد می‌کند که بتواند مدل، داده، نرم‌افزار، فرایند و انسان را درست کنار هم قرار دهد.
جمع‌بندی؛ مسیر درست از فرایند شروع می‌شود، نه از هوش مصنوعی
اگر قرار باشد فقط یک نکته از این مقاله باقی بماند، این باشد:
از Agent شروع نکنید؛ از فرایندی شروع کنید که ارزش اصلاح کردن دارد.
فرایند را روی کاغذ بیاورید. گلوگاه را پیدا کنید. کارهای قانون‌محور را از کارهای نیازمند تحلیل جدا کنید. منابع داده را مشخص کنید. سطح اختیار Agent را محدود کنید. یک نسخه کوچک بسازید. آن را به سیستم‌های واقعی متصل کنید. انسان را در نقاط حساس نگه دارید. امنیت را از ابتدا طراحی کنید و نتیجه را با عدد بسنجید.
گاهی نتیجه این تحلیل یک عامل هوش مصنوعی است.
گاهی یک اتوماسیون ساده.
گاهی نرم‌افزار اختصاصی.
و گاهی ترکیبی از هر سه.
مهم این نیست که در پایان پروژه بتوانیم بگوییم «ما هم AI داریم».
مهم این است که بتوانیم بگوییم:
این فرایند قبلاً سه ساعت زمان می‌گرفت و حالا ۳۰ دقیقه طول می‌کشد.
یا:
این تعداد مشتری قبلاً فراموش می‌شدند و حالا نمی‌شوند.
یا:
این کار قبلاً به حافظه یک نفر وابسته بود و حالا تبدیل به یک سیستم قابل اندازه‌گیری شده است.
این همان نقطه‌ای است که هوش مصنوعی از یک فناوری جذاب به مزیت عملیاتی کسب‌وکار تبدیل می‌شود.
اگر در شرکت شما فرایندی وجود دارد که هنوز به فایل‌های پراکنده، پیگیری دستی، انتقال اطلاعات بین چند نرم‌افزار یا حافظه افراد وابسته است، لازم نیست اولین تصمیم شما «ساخت Agent» باشد.
می‌توانید ابتدا خود فرایند را بررسی کنید.
تیم توسعه نرم‌افزار مارون سیستم می‌تواند در تحلیل فرایند، تشخیص نقاط مناسب اتوماسیون، بررسی امکان استفاده از عامل هوش مصنوعی و در صورت توجیه، طراحی نرم‌افزار و اجرای راهکار در کنار کسب‌وکار شما باشد.
گاهی ارزشمندترین سؤال جلسه اول این نیست که:
«چه عامل هوش مصنوعی‌ای برای ما می‌سازید؟»
بلکه این است:
«کدام بخش کسب‌وکار ما اصلاً ارزش هوشمند شدن دارد؟»
این سؤال، نقطه شروع درست است.
سوالات پرتکرار
پیاده‌سازی عامل هوش مصنوعی را از کجا شروع کنیم؟
پیاده‌سازی باید از شناسایی یک فرایند تکراری، زمان‌بر و قابل اندازه‌گیری شروع شود. ابتدا فرایند فعلی را مستند کنید، گلوگاه را بیابید و سپس مشخص کنید کدام بخش با اتوماسیون معمولی و کدام بخش با هوش مصنوعی بهتر می‌شود.
چه فرایندهایی برای عامل هوش مصنوعی مناسب هستند؟
فرایندهایی که تکرار نسبتاً بالا، داده قابل دسترس و نیاز به تحلیل یا تصمیم‌گیری دارند، گزینه‌های بهتری هستند؛ مانند پیگیری فروش، دسته‌بندی درخواست‌های پشتیبانی، پردازش اسناد و جمع‌آوری اطلاعات از چند سیستم.
تفاوت عامل هوش مصنوعی با اتوماسیون معمولی چیست؟
اتوماسیون معمولی عمدتاً طبق قوانین از پیش تعریف‌شده کار می‌کند. عامل هوش مصنوعی می‌تواند اطلاعات را تفسیر کند، شرایط را ارزیابی کند و بین مجموعه‌ای از اقدامات مجاز، اقدام مناسب را انتخاب کند.
آیا برای پیاده‌سازی عامل هوش مصنوعی به نرم‌افزار اختصاصی نیاز داریم؟
همیشه نه. در فرایندهای ساده می‌توان از ابزارهای موجود استفاده کرد. اگر چند سیستم باید یکپارچه شوند، قوانین کسب‌وکار اختصاصی باشند یا کنترل و گزارش‌گیری خاصی لازم باشد، توسعه یک لایه نرم‌افزاری اختصاصی می‌تواند منطقی باشد.
هزینه ساخت عامل هوش مصنوعی چقدر است؟
هزینه به پیچیدگی فرایند، تعداد یکپارچه‌سازی‌ها، حجم استفاده، کیفیت داده، سطح استقلال، الزامات امنیتی و نیاز یا عدم نیاز به نرم‌افزار اختصاصی بستگی دارد.
آیا عامل هوش مصنوعی می‌تواند کاملاً مستقل کار کند؟
از نظر فنی در برخی کاربردها امکان استقلال بالایی وجود دارد، اما استقلال باید متناسب با ریسک تعریف شود. عملیات مالی، حقوقی، امنیتی یا برگشت‌ناپذیر معمولاً به کنترل و تأیید انسانی بیشتری نیاز دارند.
آیا هر کسب‌وکاری به عامل هوش مصنوعی نیاز دارد؟
خیر. اگر مشکل با اصلاح فرایند، یک نرم‌افزار ساده یا اتوماسیون قانون‌محور حل می‌شود، اضافه کردن عامل هوش مصنوعی می‌تواند فقط هزینه و پیچیدگی بیشتری ایجاد کند.
برای پروژه‌تان مشاوره می‌خواهید؟
کارشناسان مارون سیستم رایگان راهنمایی‌تان می‌کنند.
دیدگاه‌ها (۰)
اولین نفری باشید که دیدگاه می‌نویسد.