از پایلوت تا بهره‌برداری؛ چرا سرعت پیش‌نویس برای سنجش هوش مصنوعی کافی نیست؟

گزارش سریع‌تر، با چه میزان بازبینی؟

دستیاری که پیش‌نویس گزارش را سریع تولید می‌کند، لزوماً زمان تهیه گزارش قابل اتکا را به همان نسبت کاهش نمی‌دهد. بازبینی اعداد، کنترل دوره‌های مالی، بررسی منابع و نگهداری اسناد، بخشی از کاری است که پس از تولید پاسخ باقی می‌ماند. فاصله میان این دو زمان، موضوع اصلی این گفت‌وگوست.

آرش دارابیان، مدیر توسعه کسب‌وکار آوین‌اَنس، تجربه اجرای یک سامانه مدیریت دانش و تحلیل رقبا را در سازمانی بزرگ روایت می‌کند که نام آن در پاسخ‌های ارسالی اعلام نشده است. به گفته او، قرارداد پروژه در زمستان ۱۴۰۴ منعقد شد و اجرای آن در بهار ۱۴۰۵، هم‌زمان با جنگ، آغاز شد. به گفته او، در سناریوهای بررسی‌شده زمان تهیه پیش‌نویس از حدود ۱۲ نفرساعت به ۲٫۵ نفرساعت رسیده، اما پس از احتساب بازبینی، زمان کار حدود ۵ تا ۶ نفرساعت بوده است. او همچنین از خطایی می‌گوید که مقایسه دو دوره مالی متفاوت را به نتیجه‌ای نادرست رساند و به توقف موقت ماژول تحلیل مقایسه‌ای انجامید.

شفافیت درباره جایگاه مهمان و شواهد

آوین‌اَنس در پروژه مورد بحث، پیمانکار طراحی محصول و مجری فنی بوده است؛ بنابراین مهمان درباره عملکرد پروژه‌ای صحبت می‌کند که شرکت متبوعش در اجرای آن ذی‌نفع است. آرش دارابیان در راه‌اندازی رسانه خرد نیز نقش دارد. این گفت‌وگو، روایت مجری پروژه است و ارزیابی مستقل عملکرد سامانه محسوب نمی‌شود.

متن بر پایه پاسخ‌های مکتوب و خلاصه توضیحات تکمیلی ارسالی مهمان، با ویرایش زبانی و حذف تکرارها تنظیم شده است. نام کارفرما، داده خام اندازه‌گیری، صورت‌جلسه پذیرش، لاگ‌ها و تأیید مستقیم کارفرما در اختیار تحریریه قرار نگرفته است. اعداد و نتایج، هرجا ذکر می‌شوند، گزارش مهمان‌اند و تأیید مستقل خرد را ندارند.

۱. پیش از شروع پروژه چه مسئله‌ای وجود داشت و مسئولیت شما چه بود؟

آرش دارابیان: مسئله در یک سازمان بزرگ، پراکندگی شدید دانش سازمانی و کندی تحلیل رقبا بود. مدیران ارشد به گزارش‌هایی از وضعیت رقبا، به‌ویژه داده‌های عمومی و اطلاعات بورسی آن‌ها، و تطبیق این اطلاعات با اسناد و دانش داخلی نیاز داشتند.

در روش قبلی، کارشناسان باید گزارش‌های مالی، صورت‌های مالی بورسی و اسناد داخلی را دستی می‌خواندند و مقایسه می‌کردند. این فرایند زمان‌بر بود و گزارش‌ها گاهی زمانی به دست مدیر می‌رسید که فرصت تصمیم‌گیری از دست رفته بود.

قرارداد پروژه در زمستان ۱۴۰۴ منعقد شد و اجرا در بهار ۱۴۰۵، هم‌زمان با جنگ، آغاز شد. آوین‌اَنس به‌عنوان طراح محصول و مجری وارد پروژه شد. مسئولیت من تعریف مسئله با ذی‌نفعان کارفرما، تبدیل نیازهای مدیریتی به مشخصات محصول، مدیریت انتظارات در پایلوت و طراحی شیوه حکمرانی و بهره‌برداری پس از استقرار بود.

۲. چرا هوش مصنوعی را انتخاب کردید؟ چه گزینه‌های دیگری بررسی شد؟

پیش از پیشنهاد هوش مصنوعی، راهکارهای مدیریت اسناد مبتنی بر برچسب‌گذاری، جست‌وجوی کلیدواژه‌ای و داشبوردهای هوش تجاری را بررسی کردیم. نیاز ما فقط پیدا کردن سند یا نمایش یک جدول نبود؛ باید بین اسناد متنی داخلی، گزارش‌های هیئت‌مدیره و یادداشت‌های توضیحی صورت‌های مالی ارتباط برقرار می‌شد.

دلیل انتخاب مدل زبانی همراه با بازیابی اسناد، توانایی کار روی این مجموعه متن و کمک به ترکیب اطلاعات آن بود. معماری مورد استفاده RAG، یا تولید پاسخ با کمک بازیابی اسناد، بود.

توضیح اصطلاح: در RAG، بخش‌های مرتبط اطلاعات ابتدا بازیابی و سپس برای تولید پاسخ در اختیار مدل قرار می‌گیرند. توضیح فنی این معماری در مستندات مایکروسافت آمده است. این منبع صرفاً برای توضیح اصطلاح است و عملکرد پروژه مصاحبه را تأیید نمی‌کند.

یادداشت تحریریه: مقایسه بالا ناظر به گزینه‌ها و نیازهای بررسی‌شده در این پروژه است. تعبیر کلی «سامانه‌های هوش تجاری فقط با اکسل کار می‌کنند» از نسخه انتشار حذف شده است؛ این تعمیم، نتیجه قابل استنتاج از تجربه یک پروژه نیست.

۳. موفقیت پایلوت را چگونه تعریف کردید و چرا معیارها تغییر کرد؟

در شروع پایلوت در بهار ۱۴۰۵، دو معیار اصلی داشتیم: سرعت بازیابی اطلاعات و دقت پاسخ به پرسش‌های آزمایشی. در ماه دوم، تأکید ما از دقت کلی پاسخ به قابلیت استناد و جلوگیری از خطای عددی تغییر کرد.

در تحلیل رقبا، ممکن است بخش عمده متن خوب باشد، اما جابه‌جایی یک عدد یا یک تاریخ، کل گزارش را برای مدیر بی‌اعتبار کند و کارشناس را به بررسی دوباره همه‌چیز وادارد. به همین دلیل «بدون خطا بودن اعداد» را هدف قرار دادیم.

یادداشت تحریریه: خطای عددی صفر در این پاسخ، هدف طراحی است. مهمان در توضیح معیار عبور از پایلوت، از خطای زیر ۲ درصد سخن می‌گوید؛ بنابراین این گفت‌وگو شواهدی برای اثبات خطای صفر ارائه نمی‌کند.

۴. بهبود را نسبت به چه مبنایی سنجیدید؟

عملکرد تیم تحلیل و مدیریت دانش کارفرما مبنای مقایسه بود. ۱۰ سناریوی واقعی تصمیم‌گیری، از جمله تهیه گزارش مقایسه‌ای عملکرد سه رقیب در یک فصل، بررسی شد. یک گروه با روش قبلی کار کرد و گروه دیگر از دستیار مدیریت دانش استفاده کرد.

بر اساس اندازه‌گیری‌های پروژه، زمان جمع‌آوری داده، استخراج شاخص‌ها و تدوین پیش‌نویس از میانگین ۱۲ نفرساعت به حدود ۲٫۵ نفرساعت کاهش پیدا کرد. این عدد، زمان تأیید نهایی مدیر واحد را شامل نمی‌شود.

در توضیحات تکمیلی، دارابیان می‌گوید زمان‌ها از لاگ‌های سامانه و ارزیابی تیم کنترل کیفیت کارفرما استخراج شده و امتیازدهی خروجی‌ها را کارشناسان کارفرما انجام داده‌اند. ابزار اندازه‌گیری را شرکت مجری در سامانه قرار داده است.

یادداشت تحریریه: زمان عقد قرارداد و شروع اجرا، طبق اصلاحیه مهمان، زمستان ۱۴۰۴ و بهار ۱۴۰۵ است. تاریخ‌های قرارداد و اجرا، جایگزین تعریف دوره اندازه‌گیری نیستند؛ داده خام و جزئیات تقویمی خط مبنا در اختیار تحریریه قرار نگرفته است. تعداد اعضای دو گروه، شیوه تخصیص کارها و میزان هم‌ارزی سناریوها نیز در اطلاعات دریافتی مشخص نشده است.

۵. کیفیت داده کجا برنامه اولیه را تغییر داد؟

اسناد ورودی ترکیبی از PDFهای اسکن‌شده، جدول‌های پیچیده مالی و فایل‌های بدون ساختار بود. در هفته‌های اول دیدیم خواندن جدول‌های چندستونه صورت‌های مالی خطا دارد.

این مسئله حدود سه هفته برنامه را تغییر داد. به‌جای رفتن به سراغ مدل بزرگ‌تر، تمرکز مهندسی را بر پیش‌پردازش و استانداردسازی گذاشتیم؛ جدول‌ها و متن‌ها پیش از ورود به سامانه به قالب‌های ساختاریافته مانند Markdown و JSON تبدیل شدند.

نتایج عددی‌ای که در خلاصه پروژه آورده‌ایم، مربوط به اسناد دیجیتال و گزارش‌های مالی استاندارد است و اسناد دست‌نویس یا اسکن‌های بسیار کم‌کیفیت را شامل نمی‌شود.

۶. با احتساب بازبینی، چقدر در زمان صرفه‌جویی شد؟ چه هزینه‌ای کمتر دیده می‌شود؟

با وارد کردن زمان بازبینی و راستی‌آزمایی کارشناسان، کاری که قبلاً حدود ۱۲ نفرساعت طول می‌کشید، به حدود ۵ تا ۶ نفرساعت رسید. بنابراین کاهش زمان کار نهایی به حدود نصف نزدیک شد، نه کاهش حدود ۸۰ درصدی زمان پیش‌نویس.

هزینه‌ای که معمولاً کمتر دیده می‌شود، نگهداری و به‌روزرسانی پایگاه دانش است. اگر سندهای منسوخ کنار گذاشته نشوند، سامانه ممکن است بر پایه اطلاعات تاریخ‌گذشته تحلیل بدهد. این نگهداری مستمر، کار انسانی و هزینه دارد.

یادداشت تحریریه: کاهش از ۱۲ به ۲٫۵ نفرساعت، حدود ۷۹ درصد کاهش زمان مرحله پیش‌نویس است. کاهش از ۱۲ به ۵ تا ۶ نفرساعت، حدود ۵۰ تا ۵۸ درصد کاهش زمان کار گزارش‌شده است. این نسبت‌ها به‌تنهایی شاخص بازده مالی یا افزایش بهره‌وری کل سازمان نیستند. در خلاصه تکمیلی عدد میانی ۵٫۵ نفرساعت آمده است؛ دامنه احتساب تأیید مدیریتی و سایر هزینه‌ها در سنجش نهایی، مستند نشده است.

۷. یک خطای واقعی و مسیر اصلاح آن را شرح می‌دهید؟

در میانه پایلوت، سامانه فروش فصلی یکی از رقبای بورسی را با عملکرد تجمعی نه‌ماهه مقایسه کرد و به نتیجه‌ای نادرست درباره افت عملکرد رقیب رسید. دو عدد مربوط به بازه‌های زمانی متفاوت بودند.

کارشناس ارشد تحلیل بازار کارفرما هنگام بازبینی پیش‌نویس، خطا را تشخیص داد و از مسیر بازخورد به تیم ما گزارش کرد. با بررسی لاگ‌ها دیدیم دو جدول، بدون حفظ عنوان بالای آن‌ها و بازه زمانی، کنار هم قرار گرفته‌اند.

ظرف ۷۲ ساعت ساختار بخش‌بندی اسناد را اصلاح کردیم تا اطلاعات بازه زمانی همراه عدد حفظ شود. در دستور سامانه نیز تأکید کردیم که بدون تطبیق واحد و دوره زمانی، دو عدد با هم مقایسه نشوند.

۸. چه کسی اختیار توقف داشت و آیا از آن استفاده شد؟

اختیار توقف یا محدود کردن استفاده، به‌صورت مشترک در اختیار مدیر پروژه کارفرما و سرپرست فنی تیم ما قرار داشت. کنترل انسانی از ابتدا در قرارداد و طراحی محصول پیش‌بینی شده بود.

در همان خطای مقایسه اطلاعات بورسی، ماژول تحلیل مقایسه‌ای خودکار را چهار روز غیرفعال کردیم و سامانه را در حالت جست‌وجو و استخراج منبع نگه داشتیم تا اصلاحات و آزمون انجام شود. در این مورد، خطا پیش از ارسال گزارش به مدیران ارشد تشخیص داده شد.

۹. کار کارکنان و نیاز آموزشی آن‌ها چگونه تغییر کرد؟

جست‌وجو در آرشیو، انتقال دستی اعداد و خلاصه‌نویسی اولیه کمتر شد. در مقابل، طرح پرسش دقیق و راستی‌آزمایی تحلیلی سهم بیشتری پیدا کرد.

در ماه اول پایلوت، فشار کاری بیشتر شد؛ کارکنان هم از سامانه استفاده می‌کردند و هم به دلیل نگرانی از خطا، کار را دوباره دستی انجام می‌دادند. برای مواجهه با این وضعیت، کارگاهی برگزار کردیم که تمرکزش بازبینی ارجاع‌ها و بررسی بخش مرتبط از سند اصلی بود. بر اساس تجربه ما، این تغییر به کاهش زمان بازبینی و نگرانی کاربران کمک کرد.

یادداشت تحریریه: ادعای کاهش فشار کاری با مقیاس سنجش، تعداد پاسخ‌دهندگان یا داده مستقل همراه نیست. همچنین بررسی منبع هر ادعا با بررسی کامل‌بودن تحلیل، انتخاب درست مقایسه‌ها و مطالب حذف‌شده از پاسخ یکسان نیست؛ خطای دوره مالیِ شرح‌داده‌شده در همین گفت‌وگو، اهمیت این تفاوت را نشان می‌دهد.

۱۰. چه چیزی به تصمیم ادامه پروژه انجامید؟

پس از پایلوت سه‌ماهه، کارفرما بر اساس شاخص‌های توافق‌شده وارد بهره‌برداری شد. شرط عبور، رسیدن خطای عددی گزارش‌های تحلیلی به زیر ۲ درصد و رضایت بالای ۷۰ درصدی کارشناسان از کاهش کار تکراری بود. در ارزیابی پروژه، هر دو شرط محقق شد.

از نگاه ما، گزارش‌ها یکدست‌تر شد و پاسخ‌گویی واحد مدیریت دانش به درخواست‌های فوری مدیران سرعت گرفت. هزینه اشتراک و نگهداری هم، بر اساس مقایسه‌ای که در پروژه داشتیم، کمتر از استخدام یک تحلیل‌گر ارشد جدید بود.

اگر در پایان ماه دوم خطای استخراج اعداد بالای ۵ درصد باقی می‌ماند و کارشناسان مجبور بودند کل گزارش را از نو بنویسند، خودمان توقف یا تغییر رویکرد را پیشنهاد می‌کردیم.

یادداشت تحریریه: مخرج محاسبه خطای عددی، اندازه مجموعه آزمون و روش سنجش رضایت در اطلاعات دریافتی مشخص نیست. عدد ۹۸٫۵ درصد در خلاصه تکمیلی به «تطابق ارجاع به پاراگراف‌ها و جدول‌ها» مربوط است و نباید معادل دقت تمام اعداد یا صحت نتیجه‌گیری نهایی تلقی شود. برای مقایسه هزینه نیز صورت هزینه کامل و اجزای هزینه نیروی انسانی ارائه نشده است؛ بنابراین امکان تأیید مستقل این مقایسه وجود ندارد.

۱۱. تعویض مدل یا تأمین‌کننده را چگونه آزمودید؟

طراحی ما به‌گونه‌ای بود که پایگاه داده برداری، اسناد استانداردشده، اطلاعات توصیفی اسناد و رابط کاربری از مدل زبانی جدا باشند و داده‌ها متعلق به کارفرما بمانند.

در همین پروژه به دلیل محدودیت دسترسی و هزینه، مدل پردازش زبانی را عوض کردیم. انتقال در کمتر از دو روز کاری انجام شد و بر اساس بررسی تیم پروژه، دانش ذخیره‌شده حفظ شد.

یادداشت تحریریه: تجربه اعلام‌شده، تعویض مدل زبانی در معماری موجود است. این تجربه به‌تنهایی انتقال کامل به پیمانکار دیگر، تغییر مدل بردارسازی یا حفظ کیفیت همه پاسخ‌ها پس از مهاجرت را اثبات نمی‌کند؛ برای این موارد آزمون‌های جداگانه لازم است.

۱۲. اگر از ابتدا شروع کنید، چه تغییری می‌دهید و توصیه شما به مدیر خریدار چیست؟

از روز اول، قالب‌های استاندارد پرسش و تحلیل را در اختیار کاربران می‌گذاشتم. آزادی بیش‌ازحد در ابتدای پایلوت، هم خطا را افزایش داد و هم آموزش را دشوار کرد.

توصیه من برای چنین کاربردی این است که سامانه در هر پاسخ، منبع دقیق و قابل کلیک، تا سطح صفحه و بخش مرتبط سند، ارائه کند. معیار موفقیت پایلوت هم به‌جای عنوان کلی «هوشمند بودن»، کاهش زمان تولید گزارش نهایی با احتساب بازبینی باشد. به‌عنوان یک هدف قراردادی، کاهش حداقل ۳۰ درصدی این زمان را پیشنهاد می‌کنم.

پرسشی که پس از این تجربه باقی می‌ماند

این روایت، سه موضوع قابل بررسی برای مدیران دارد: اندازه‌گیری زمان تا رسیدن به خروجی قابل استفاده، حفظ زمینه اعداد در بازیابی اسناد و اختیار واقعی توقف بخشی از سامانه. ارزش این موضوع‌ها به ارقام ادعاشده محدود نیست؛ می‌توان آن‌ها را در طراحی پایلوت و قرارداد ارزیابی به پرسش‌های قابل سنجش تبدیل کرد.

در عین حال، شواهد فعلی برای تعمیم اندازه صرفه‌جویی یا دقت این پروژه به سازمان‌های دیگر کافی نیست. دریافت تعریف دقیق شاخص‌ها، دوره قطعی خط مبنا، نمونه گزارش‌های ناشناس‌شده و تأیید مستقیم کارفرما می‌تواند امکان ارزیابی کامل‌تری فراهم کند.

درباره تنظیم این گفت‌وگو

منبع: پاسخ‌های مکتوب آرش دارابیان و خلاصه توضیحات تکمیلی ارسالی او. نام کارفرما اعلام نشده است. عکس همراه مطلب از سوی مهمان ارسال شده است. متن با کمک ابزار هوش مصنوعی ویرایش و برای انتشار تنظیم شده؛ یادداشت‌های تحریریه از پاسخ‌های مهمان جدا شده‌اند. برای این گفت‌وگو پاسخ یا نقل‌قول تازه‌ای ساخته نشده است.