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