بیشتر پروژههای هوش مصنوعی در شرکتها با یک نمایش امیدوارکننده شروع میشوند. چند سند در اختیار سیستم قرار میگیرد، مدیر یکی دو سؤال میپرسد و پاسخهایی تحویل میگیرد که تا همین چند سال پیش برای یک نرمافزار غیرممکن به نظر میرسید. جلسه معمولاً با این تصور تمام میشود که فاصله زیادی تا خودکار شدن بخشی از کارهای شرکت باقی نمانده است. اما درست وقتی قرار است این نمایش جذاب به یک ابزار واقعی کسبوکار تبدیل شود، مسئله اصلی خودش را نشان میدهد.
فرض کنید مدیر فروش میخواهد مشتریانی را پیدا کند که در سه ماه گذشته خرید قابلتوجهی داشتهاند اما بیشتر از ۳۰ روز است سفارشی ثبت نکردهاند. انتظار او فقط دریافت فهرستی از مشتریان نیست. میخواهد سابقه هر مشتری بررسی شود، مشتریان مهمتر در اولویت قرار بگیرند و برای کارشناس مسئول، پیگیری مناسبی در سامانه مدیریت ارتباط با مشتری ثبت شود. درخواست در ظاهر ساده است، اما اجرای آن به اطلاعاتی نیاز دارد که احتمالاً در چند نرمافزار مختلف پراکنده شدهاند.
مشخصات مشتری و سابقه تماس شاید در سامانه مدیریت ارتباط با مشتری باشد، اطلاعات خرید در فروشگاه یا نرمافزار فروش قرار گرفته باشد و وضعیت پرداخت از نرمافزار مالی بیاید. حتی ممکن است بخشی از اطلاعات مهم در یادداشت کارشناسان، فایلهای اکسل یا متن مکالمات قبلی باقی مانده باشد. مدل زبانی میتواند منظور مدیر را بفهمد، اما فهمیدن درخواست فقط بخش کوچکی از کار است. مسئله واقعی این است که سیستم چگونه باید اطلاعات لازم را پیدا کند، میان آنها ارتباط برقرار کند و در نهایت عملیاتی واقعی را در نرمافزار شرکت انجام دهد.
همینجا مرز میان یک چتبات و عامل هوش مصنوعی سازمانی مشخص میشود. مسئله دیگر تولید پاسخ بهتر نیست؛ مسئله ساخت سیستمی است که بتواند در محدودهای مشخص و قابلکنترل، از «فهمیدن» به «انجام دادن» برسد.
عامل هوش مصنوعی زمانی معنا پیدا میکند که پای یک کار واقعی وسط باشد
تعریفهای زیادی برای عامل هوش مصنوعی وجود دارد، اما برای یک مدیر کسبوکار شاید تعریف سادهتر مفیدتر باشد. عامل هوش مصنوعی سیستمی است که برای انجام یک هدف، فقط متن تولید نمیکند؛ میتواند اطلاعات لازم را از منابع مجاز دریافت کند، شرایط را بررسی کند، ابزار مناسب را به کار بگیرد و در محدودهای که برایش تعیین شده است اقدام انجام دهد.
تفاوت اصلی در همین «اقدام» است. یک دستیار معمولی میتواند پس از بررسی سابقه مکالمه پیشنهاد کند که یک مشتری بهتر است امروز پیگیری شود. در مقابل، یک عامل فروش میتواند اطلاعات همان مشتری را از سامانه دریافت کند، آخرین مذاکره را خلاصه کند، مسئول حساب را تشخیص دهد و وظیفه پیگیری فردا را در سیستم ثبت کند. اگر معماری اجازه دهد، حتی میتواند پیشنویس پیام مناسب را هم آماده کند تا کارشناس فقط آن را بررسی کند.
البته این تعریف نباید ما را به تصویر اغراقآمیز «کارمند دیجیتالی کاملاً مستقل» برساند. در یک سیستم سازمانی سالم، استقلال بیشتر الزاماً مزیت بیشتر نیست. اتفاقاً بخش مهم مهندسی Agent این است که مشخص کنیم چه کارهایی را میتواند انجام دهد، به چه اطلاعاتی دسترسی ندارد، کجا باید متوقف شود و در چه نقطهای تصمیم را به انسان تحویل دهد.
بنابراین یک عامل خوب لزوماً عاملی نیست که بتواند کارهای بیشتری انجام دهد. گاهی بهترین Agent همان سیستمی است که مسئولیت محدودی دارد، همان مسئولیت را خوب انجام میدهد و خارج از آن محدوده تقریباً هیچ اختیاری ندارد.
مشکل اصلی معمولاً مدل هوش مصنوعی نیست
در بسیاری از جلسات اولیه پروژه، بحث خیلی زود به انتخاب مدل میرسد. کدام مدل دقیقتر است؟ کدامیک فارسی را بهتر میفهمد؟ هزینه کدام کمتر است؟ آیا مدل خارجی استفاده شود یا مدل روی زیرساخت خود شرکت اجرا شود؟ همه این سؤالها مهماند، اما معمولاً زودتر از زمانی که باید مطرح میشوند.
فرض کنید بهترین مدل موجود را در اختیار داشته باشیم، اما اطلاعات مشتریان شرکت ناقص باشد. کارشناسان فروش وضعیت فرصتها را بهدرستی ثبت نکرده باشند، نرمافزار مالی رابط برنامهنویسی مناسبی نداشته باشد و هیچکس هم نتواند دقیق توضیح دهد که یک سرنخ از زمان ورود تا تبدیل شدن به مشتری چه مسیری را طی میکند. در چنین شرایطی، مدل قویتر مشکل بنیادی را حل نمیکند.
عامل سازمانی در واقع یک سیستم نرمافزاری است که مدل زبانی فقط یکی از اجزای آن محسوب میشود. در کنار مدل، باید داده قابل استفاده وجود داشته باشد، ابزارهایی برای انجام عملیات تعریف شوند، نرمافزارهای مختلف بتوانند با یکدیگر ارتباط برقرار کنند، قواعد کسبوکار مشخص باشند و سطح دسترسی هر بخش نیز کنترل شود. اگر یکی از این قطعات درست طراحی نشده باشد، افزایش قدرت مدل لزوماً نتیجه بهتری ایجاد نمیکند.
این نکته برای کسبوکارهایی که میخواهند وارد پروژههای Agentic شوند بسیار مهم است. بخش دشوار کار همیشه این نیست که هوش مصنوعی «چه جوابی میدهد». گاهی دشوارترین بخش این است که بفهمیم جواب مدل چگونه باید بدون ایجاد آشفتگی به یک عملیات معتبر در سیستم شرکت تبدیل شود.
اتصال عامل به نرمافزارهای شرکت، جایی است که پروژه جدی میشود
فرض کنیم یک شرکت از سه سیستم اصلی استفاده میکند: سامانه مدیریت ارتباط با مشتری برای مدیریت فرصتها، فروشگاه اینترنتی برای سفارشها و نرمافزار مالی برای پرداختها. مدیر فروش میخواهد مشتریانی پیدا شوند که ارزش خرید بالایی داشتهاند اما مدتی است فعالیتی ندارند.
برای رسیدن به این نتیجه، عامل باید بتواند اطلاعات مرتبط را از چند منبع دریافت کند. این ارتباط معمولاً از طریق رابطهای برنامهنویسی انجام میشود. اما اتصال فنی بهتنهایی کافی نیست. سؤال مهمتر این است که عامل دقیقاً به کدام بخش هر سیستم نیاز دارد.
اگر فقط قرار است آخرین سفارش مشتری خوانده شود، چرا باید امکان ویرایش سفارش هم در اختیار عامل قرار بگیرد؟ اگر فقط مانده حساب برای تصمیمگیری لازم است، چه دلیلی وجود دارد که امکان ثبت سند مالی نیز باز باشد؟ اگر عامل فقط باید وظیفه پیگیری بسازد، چرا باید اجازه حذف اطلاعات مشتری را داشته باشد؟
این سؤالات شاید در ظاهر امنیتی باشند، اما در اصل بخشی از طراحی نرمافزارند. معماری مناسب تلاش نمیکند Agent را به تمام سیستم متصل کند؛ تلاش میکند کوچکترین مسیر لازم برای انجام یک وظیفه مشخص را در اختیار آن قرار دهد.
در پروژههای واقعی، همین مرحله معمولاً زمان بیشتری از چیزی میگیرد که در نمایشهای ساده هوش مصنوعی دیده میشود. سیستمهای قدیمی ممکن است رابط مناسبی نداشته باشند، دادهها نامنظم باشند یا یک مفهوم واحد در دو نرمافزار با تعریف متفاوت ثبت شده باشد. برای مثال، «مشتری فعال» در واحد فروش ممکن است معنایی متفاوت از همان عبارت در سیستم مالی داشته باشد. تا این اختلافها روشن نشوند، مدل زبانی چیزی برای حل کردن ندارد.
ابزار خوب از دسترسی گسترده مهمتر است
یکی از تصمیمهای هوشمندانه در معماری عامل این است که بهجای باز کردن مستقیم سیستمها، مجموعهای از ابزارهای محدود و مشخص برای آن ساخته شود. بهعنوان نمونه، یک ابزار فقط سابقه خرید مشتری را برگرداند، ابزار دیگر وضعیت پرداخت را بررسی کند و ابزار سوم وظیفهای برای کارشناس فروش ایجاد کند.
این روش از یک جهت ساده به نظر میرسد، اما اثر مهمی دارد. وقتی ابزار «ساخت وظیفه فروش» فقط اجازه تعیین عنوان، کارشناس، توضیح و تاریخ را دارد، عامل حتی اگر رفتار غیرمنتظرهای نشان دهد نمیتواند از همان ابزار برای حذف مشتری یا تغییر قرارداد استفاده کند. محدوده قابلیت در خود معماری تعریف شده است، نه در خواهش از مدل برای اینکه «لطفاً کار دیگری انجام نده».
اینجاست که توسعه نرمافزار دوباره به مرکز ماجرا برمیگردد. کیفیت یک Agent فقط به توانایی استدلال مدل بستگی ندارد؛ به کیفیت ابزارهایی بستگی دارد که اطراف مدل ساخته شدهاند. ابزار مبهم، دسترسی بیش از حد و رابط برنامهنویسی ضعیف میتواند یک مدل خوب را به سیستم نامطمئنی تبدیل کند. در مقابل، ابزارهای محدود و روشن میتوانند رفتار سیستم را بسیار قابلکنترلتر کنند.
به همین دلیل، تیم توسعه نرمافزار مارون سیستم در تحلیل چنین پروژهای باید قبل از انتخاب فناوری به جریان واقعی کار نگاه کند: کاربر امروز چه کاری انجام میدهد، میان کدام نرمافزارها جابهجا میشود، کدام تصمیم واقعاً به تحلیل نیاز دارد و کدام عملیات صرفاً یک دستور قطعی نرمافزاری است.
هر تصمیمی ارزش سپردن به مدل زبانی را ندارد
یکی از نشانههای معماری ضعیف این است که برای تقریباً هر تصمیم کوچکی از مدل زبانی استفاده شود. این کار نهتنها هزینه و زمان پاسخ را افزایش میدهد، بلکه رفتاری را که میتوانست کاملاً قابل پیشبینی باشد به یک تصمیم احتمالاتی تبدیل میکند.
فرض کنید سیاست فروش شرکت میگوید تخفیف بیشتر از ۱۵ درصد باید به تأیید مدیر برسد. اینجا نیازی به «هوشمندی» نداریم. یک شرط نرمافزاری ساده، سریع و قابل اعتماد کافی است. اما تشخیص اینکه مشتری در مکالمه اخیر بیشتر درباره قیمت نگرانی داشته یا درباره زمان تحویل، مسئله متفاوتی است. اینجا تحلیل زبان و زمینه میتواند مفید باشد.
معماری بالغ این دو جهان را با یکدیگر اشتباه نمیگیرد. آنچه قانون مشخص دارد با نرمافزار و قواعد قطعی اجرا میشود و آنچه نیازمند تفسیر زبان، طبقهبندی یا تحلیل زمینه است در اختیار مدل قرار میگیرد. نتیجه، سیستمی است که فقط در جایی «هوشمند» میشود که هوشمندی واقعاً ارزش ایجاد میکند.
این موضوع یک اثر اقتصادی هم دارد. هر فراخوانی مدل هزینه دارد، زمان میبرد و یک نقطه جدید برای خطا ایجاد میکند. استفاده کمتر اما هدفمندتر از مدل، در بسیاری از پروژهها نه عقبماندگی، بلکه نشانه معماری بهتر است.
حافظه بیشتر همیشه به معنی عامل بهتر نیست
حافظه یکی دیگر از بخشهایی است که در بحث Agentها گاهی بیش از حد سادهسازی میشود. تصور رایج این است که هرچه سیستم اطلاعات بیشتری از گذشته نگه دارد، عملکرد بهتری خواهد داشت. در محیط سازمانی، چنین قاعدهای همیشه درست نیست.
اگر سابقه یک مشتری از قبل در سامانه مدیریت ارتباط با مشتری ثبت شده است، لزوماً دلیلی ندارد نسخه دیگری از همان اطلاعات در «حافظه Agent» ساخته شود. این کار خیلی زود مسئله تازهای ایجاد میکند: اگر اطلاعات CRM تغییر کرد، کدام نسخه معتبر است؟ اگر مشتری درخواست حذف دادههایش را داشت، اطلاعات ذخیرهشده در حافظه چه میشود؟ اگر دو سیستم درباره یک مشتری اطلاعات متفاوتی داشتند، کدامیک باید مبنای تصمیم قرار گیرد؟
معماری خوب تلاش میکند برای هر نوع اطلاعات یک منبع معتبر مشخص داشته باشد. اطلاعات مشتری ممکن است متعلق به CRM باشد، وضعیت پرداخت متعلق به سیستم مالی و دانش مربوط به محصول در سامانه مستندات نگهداری شود. عامل در زمان لازم این اطلاعات را دریافت میکند، نه اینکه الزاماً یک نسخه موازی از تمام سازمان برای خودش بسازد.
حافظه زمانی ارزش دارد که واقعاً برای حفظ زمینه میان مراحل یک فرآیند یا تعاملهای مرتبط لازم باشد. حتی در آن شرایط هم باید مشخص باشد چه چیزی ذخیره میشود، تا چه زمانی باقی میماند و چه کسی اجازه دسترسی به آن را دارد.
دانش سازمان فقط داخل پایگاه داده نیست
مشکل دیگری که خیلی زود ظاهر میشود این است که بخش مهمی از دانش شرکت اصلاً ساختاریافته نیست. قراردادها، دستورالعملهای داخلی، توضیحات محصولات، رویههای پشتیبانی، فایلهای فنی و سیاستهای سازمانی معمولاً در اسناد مختلف پراکندهاند.
اینجا بازیابی اطلاعات اهمیت پیدا میکند. بهجای اینکه انتظار داشته باشیم مدل همه دانش شرکت را «بداند»، سیستم میتواند هنگام انجام یک کار، بخش مرتبط از اسناد معتبر را پیدا کند و در اختیار مدل قرار دهد. معماریهایی مانند تولید تقویتشده با بازیابی اطلاعات یا RAG برای همین مسئله استفاده میشوند.
اما باید یک مرز مفهومی را حفظ کرد. پیدا کردن اطلاعات با انجام دادن کار یکسان نیست. سامانه بازیابی ممکن است بند مربوط به بازپرداخت را از دستورالعمل شرکت پیدا کند؛ Agent بعد از خواندن همان بند ممکن است وضعیت سفارش را بررسی کند و پرونده را به مسیر مناسب بفرستد. یکی دانش را در دسترس قرار میدهد و دیگری آن دانش را وارد یک فرآیند عملیاتی میکند.
این تفاوت زمانی مهم میشود که قرار باشد درباره میزان استقلال سیستم تصمیم بگیریم.
عامل سازمانی بدون جریان کاری مشخص خیلی زود غیرقابل پیشبینی میشود
تصویر جذابی وجود دارد که در آن یک هدف کلی به Agent داده میشود و سیستم خودش تمام مراحل رسیدن به هدف را پیدا میکند. برای آزمایش و بعضی کاربردهای کمریسک، این آزادی میتواند جالب باشد. اما در فرآیندهای مهم سازمانی، آزادی نامحدود معمولاً چیزی نیست که مدیر فناوری به دنبالش باشد.
فرض کنید موضوع بازپرداخت مشتری است. فرآیند شرکت احتمالاً مراحل مشخصی دارد: سفارش باید وجود داشته باشد، شرایط بازپرداخت بررسی شود، وضعیت ارسال مشخص باشد، مبلغ محاسبه شود و در بعضی شرایط مدیر تأیید کند. منطقی نیست هر بار از مدل بخواهیم این فرآیند را از ابتدا اختراع کند.
روش قابلکنترلتر این است که چارچوب اصلی Workflow در نرمافزار مشخص باشد و مدل فقط در نقاطی وارد شود که واقعاً نیاز به تحلیل دارد. مثلاً متن شکایت مشتری را طبقهبندی کند، دلیل درخواست را استخراج کند یا یک مورد غیرعادی را تشخیص دهد. ادامه مسیر بر اساس قواعد کسبوکار انجام میشود.
به این ترتیب، هوش مصنوعی جای فرآیند را نمیگیرد؛ داخل فرآیند قرار میگیرد.
انسان دقیقاً کجای این معماری باقی میماند؟
هدف یک پروژه خوب لزوماً حذف انسان نیست. در بسیاری از فرآیندها، ارزش اصلی در این است که زمان انسان از کارهای تکراری آزاد شود و روی تصمیمهایی متمرکز شود که واقعاً به قضاوت نیاز دارند.
عامل فروش میتواند سابقه مشتری را جمعآوری کند، مکالمات را خلاصه کند و اقدام بعدی را پیشنهاد دهد؛ اما تخفیف خارج از عرف به مدیر برسد. عامل قرارداد میتواند بندهای غیرمعمول را پیدا کند؛ اما پذیرش ریسک حقوقی همچنان با مسئول مربوط باشد. سیستم مالی میتواند مغایرت را تشخیص دهد؛ اما پرداخت مبلغ قابلتوجه بدون تأیید انجام نشود.
مرز مناسب برای هر سازمان متفاوت است، اما یک قاعده مفید وجود دارد: هرچه یک اقدام برگشتناپذیرتر، مالیتر، حقوقیتر یا امنیتیتر باشد، دلیل بیشتری برای باقی ماندن انسان در نقطه تصمیم وجود دارد.
این رویکرد برخلاف تصور اولیه، از ارزش اتوماسیون کم نمیکند. اگر سیستم بتواند ۹۰ درصد کار آمادهسازی یک تصمیم را انجام دهد و فقط ۱۰ درصد حساس را به فرد مسئول تحویل دهد، همچنان بخش بزرگی از زمان فرآیند حذف شده است.
امنیت از همان لحظهای جدی میشود که Agent امکان اقدام پیدا میکند
تا زمانی که یک سیستم فقط پاسخ تولید میکند، خطای آن اغلب در همان صفحه باقی میماند. اما وقتی به فایل، CRM، پایگاه داده یا API متصل میشود، خطای مدل میتواند اثر واقعی داشته باشد.
اینجا امنیت دیگر یک مرحله جدا در پایان پروژه نیست. سطح دسترسی هر ابزار، محل نگهداری کلیدها، ارتباطات شبکه، جداسازی محیط اجرا، ثبت فعالیتها و تأیید عملیات حساس باید از ابتدا در معماری دیده شوند.
عامل فروش که فقط باید اطلاعات مشتری را بخواند، نباید امکان حذف آن را داشته باشد. عاملی که فقط به سه سرویس مشخص نیاز دارد، دلیل قابل قبولی برای دسترسی آزاد به تمام اینترنت ندارد. کلیدهای حساس نیز نباید صرفاً به این دلیل که استفاده از آنها سادهتر میشود، مستقیماً در دسترس مدل قرار بگیرند.
ما این موضوع را در مقاله «امنیت عامل هوش مصنوعی؛ معماری امن از محیط ایزوله تا شبکه بدون اعتماد» مفصلتر بررسی کردهایم. ارتباط میان این دو بحث اتفاقی نیست. هرچه قدرت اقدام Agent بیشتر میشود، معماری امنیتی آن نیز باید جدیتر شود.
آیا کسبوکار شما اصلاً به عامل هوش مصنوعی نیاز دارد؟
در فضای فعلی فناوری، پاسخ «نه» گاهی از پاسخ «بله» ارزشمندتر است. همه فرآیندها به Agent نیاز ندارند.
اگر یک کار کاملاً مشخص و قانونمحور است، اتوماسیون معمولی احتمالاً سادهتر، ارزانتر و قابل اعتمادتر خواهد بود. اگر هر روز ساعت ۹ باید گزارشی از یک پایگاه داده گرفته و برای مدیر ارسال شود، دلیل زیادی برای وارد کردن مدل زبانی به این فرآیند وجود ندارد.
عامل زمانی جذابتر میشود که کار میان چند سیستم حرکت میکند، بخشی از اطلاعات به شکل متن و سند است، تصمیم به زمینه وابسته است و کارکنان زمان زیادی صرف جمعآوری اطلاعات و انتخاب اقدام بعدی میکنند.
اما حتی وجود این شرایط هم به معنی شروع فوری پروژه نیست. اگر فرآیند فعلی نامشخص باشد، دادهها کیفیت مناسبی نداشته باشند یا شرکت نتواند بگوید از پروژه چه نتیجه قابلاندازهگیری میخواهد، بهتر است ابتدا همان مشکلات حل شوند.
هوش مصنوعی فرآیند نامنظم را الزاماً اصلاح نمیکند. گاهی فقط کمک میکند همان بینظمی با سرعت بیشتری اجرا شود.
هزینه واقعی ساخت عامل سازمانی کجاست؟
وقتی درباره هزینه Agent صحبت میشود، توجه معمولاً به هزینه مدل و تعداد توکنها میرود. در پروژههای سازمانی، این فقط بخشی از ماجراست و گاهی حتی بخش اصلی هم نیست.
ممکن است بیشترین زمان پروژه صرف اتصال به نرمافزاری قدیمی شود که رابط مناسبی ندارد. شاید پاکسازی دادههای CRM دشوارتر از ساخت خود Agent باشد. ممکن است تعریف Permissionها، ساخت ابزارهای امن، ثبت رویدادها و طراحی مسیر تأیید انسانی بخش قابلتوجهی از توسعه را تشکیل دهند.
به همین دلیل دو Agent که از یک مدل استفاده میکنند میتوانند هزینه توسعه کاملاً متفاوتی داشته باشند. یکی شاید فقط چند سند را بخواند و در یک سیستم وظیفه بسازد؛ دیگری باید با پنج نرمافزار، اطلاعات حساس و چند سطح دسترسی سازمانی کار کند.
برآورد واقعی زمانی ممکن میشود که Use Case بهاندازه کافی محدود شده باشد. قبل از آن، سؤال «ساخت Agent چقدر هزینه دارد؟» تقریباً شبیه این است که بپرسیم «ساخت نرمافزار چقدر هزینه دارد؟»
از کجا باید شروع کرد؟
بهترین نقطه شروع معمولاً یک فرآیند کوچک اما دردناک است؛ کاری که مرتب انجام میشود، وقت قابلتوجهی میگیرد و نتیجه آن قابلاندازهگیری است.
مثلاً تیم فروش هر روز باید از چند منبع اطلاعات جمع کند تا بفهمد کدام مشتریان نیاز به پیگیری دارند. بهجای ساخت یک «Agent فروش همهکاره»، میتوان فقط همین فرآیند را بررسی کرد.
وضعیت فعلی اندازهگیری میشود. مشخص میکنیم امروز این کار چقدر زمان میگیرد، چه خطاهایی دارد و نتیجه مطلوب چیست. بعد منابع داده، ابزارهای لازم و نقاط تصمیم شناسایی میشوند. تازه در این مرحله مشخص میشود کجا واقعاً به مدل زبانی نیاز داریم و کجا یک API یا Rule ساده کافی است.
نسخه اولیه نیز بهتر است محدود باشد. چند کاربر، چند ابزار و یک سناریوی مشخص. اگر نتیجه مطلوب بود، دامنه سیستم میتواند مرحلهبهمرحله افزایش پیدا کند.
این همان رویکردی است که توسعه نرمافزار مارون سیستم برای چنین پروژههایی میتواند از آن شروع کند: نه با سؤال «چه Agentی بسازیم؟»، بلکه با بررسی اینکه کدام بخش از کار امروز شرکت ارزش هوشمندسازی دارد و برای تغییر آن چه معماریای واقعاً لازم است.
جمعبندی؛ فاصله میان یک دموی جذاب و یک سیستم واقعی در معماری است
ساخت سیستمی که به یک سؤال خوب پاسخ بدهد دیگر دشوارترین بخش ماجرا نیست. چالش واقعی زمانی آغاز میشود که انتظار داریم همان سیستم با دادههای شرکت کار کند، میان چند نرمافزار حرکت کند و نتیجه تحلیلش را به یک اقدام واقعی تبدیل کند.
در این مرحله دیگر انتخاب مدل تنها تصمیم مهم پروژه نیست. کیفیت داده، ابزارها، رابطهای برنامهنویسی، قواعد کسبوکار، حافظه، جریان کاری، امنیت و جایگاه انسان همگی تعیین میکنند سیستم در عمل چقدر مفید خواهد بود.
عامل هوش مصنوعی سازمانی زمانی ارزش ایجاد میکند که دقیقاً بدانیم چه مسئولیتی دارد و، شاید مهمتر از آن، چه مسئولیتی ندارد.
برای همین پیش از اینکه از خودمان بپرسیم «چطور برای شرکت Agent بسازیم؟» سؤال دقیقتری وجود دارد:
امروز کدام کار در شرکت میان انسانها، نرمافزارها و اطلاعات پراکنده گیر کرده است و اگر بخشی از آن هوشمند شود، چه نتیجه قابلاندازهگیری برای کسبوکار ایجاد میکند؟
پاسخ همین سؤال معمولاً نقطه شروع پروژهای است که قرار است چیزی بیشتر از یک دموی جذاب باشد.
سوالات پرتکرار درباره عامل هوش مصنوعی سازمانی
عامل هوش مصنوعی سازمانی چیست؟
عامل هوش مصنوعی سازمانی نرمافزاری است که علاوه بر تحلیل اطلاعات، میتواند از ابزارهای مشخص برای انجام یک کار استفاده کند. برای مثال، اطلاعات مشتری را از سامانه مدیریت ارتباط با مشتری بخواند، سابقه سفارش را بررسی کند یا برای کارشناس فروش وظیفه پیگیری بسازد.
تفاوت عامل هوش مصنوعی با چتبات چیست؟
چتبات معمولاً به سؤال پاسخ میدهد یا اطلاعات ارائه میکند، اما عامل هوش مصنوعی میتواند به نرمافزارها و ابزارهای مجاز متصل شود و بخشی از یک فرآیند واقعی را انجام دهد. به همین دلیل، طراحی عامل علاوه بر مدل زبانی به داده، یکپارچهسازی نرمافزارها، سطح دسترسی و جریان کاری هم وابسته است.
آیا عامل هوش مصنوعی میتواند به نرمافزارهای فعلی شرکت متصل شود؟
بله. اگر نرمافزارهایی مانند سامانه مدیریت ارتباط با مشتری، نرمافزار مالی یا سامانه سازمانی رابط مناسبی برای تبادل اطلاعات داشته باشند، میتوان عامل را به آنها متصل کرد. در نرمافزارهای قدیمیتر ممکن است ابتدا به یک رابط یا لایه واسط اختصاصی نیاز باشد.
چه زمانی یک کسبوکار واقعاً به عامل هوش مصنوعی نیاز دارد؟
زمانی که یک فرآیند تکرارشونده و زمانبر به جمعآوری اطلاعات از چند منبع، درک متن یا شرایط و انتخاب میان چند اقدام نیاز داشته باشد، استفاده از عامل هوش مصنوعی میتواند منطقی باشد. اگر همان کار با چند قانون ثابت و اتوماسیون ساده حل میشود، معمولاً نیازی به پیچیدهتر کردن سیستم با عامل هوش مصنوعی نیست.
