ساختن قابلیت‌های هوش مصنوعی که کاربران واقعاً می‌خواهند

الگویی هست که مدام در پروژه‌هایی که روی میزم می‌آیند می‌بینم: «می‌خواهیم به محصولمان هوش مصنوعی اضافه کنیم.»

وقتی می‌پرسم منظورشان دقیقاً چیست، یکی از چند پاسخ را می‌شنوم: یک چت‌بات، یک خلاصه‌ساز خودکار، یا «یک چیزی شبیه کاری که ChatGPT می‌کند اما برای کاربرد ما.»

هیچ‌کدام این‌ها اشتباه نیستند، اما راه‌حل‌هایی‌اند که دنبال مسئله می‌گردند. و این دقیقاً برعکس ترتیب درست است.

سه پرسش

پیش از ساختن هر قابلیت هوش مصنوعی، به این‌ها پاسخ دهید:

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

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

۳. جایگزین چیست؟ اگر جایگزین قابلیت هوش مصنوعی شما این است که «کاربر آن را دستی انجام می‌دهد»، باید بپرسید چند وقت یک‌بار این کار را می‌کنند، چقدر طول می‌کشد، و چقدر حاضرند بپردازند تا آن را انجام ندهند. اگر جایگزین «هیچ‌چیز» است — یعنی این کار پیش‌تر اصلاً وجود نداشته — احتمالاً دارید چیزی می‌سازید که کاربران استفاده‌اش نمی‌کنند.

کجا هوش مصنوعی واقعاً کار می‌کند

نقاط طلایی‌ای که در محصولات واقعی پیدا کرده‌ام:

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

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

جست‌وجو و بازیابی در داده‌ی بدون‌ساختار. خط‌لوله‌های RAG (تولید تقویت‌شده با بازیابی) به کاربران اجازه می‌دهند روی مجموعه‌ای از اسناد به زبان طبیعی پرسش بپرسند. این کاری است که واقعاً بدون هوش مصنوعی به‌سختی قابل‌تکرار است.

پرچم‌گذاری ناهنجاری. «این چیزی است که غیرعادی به‌نظر می‌رسد — باید نگاهش کنید.» اگر مدل گاهی اشتباه کند ریسک پایینی دارد، و وقتی چیزی را که انسان از دستش در می‌رفت می‌گیرد، ارزش بالایی خلق می‌کند.

یک نمونه‌ی حل‌شده

یک کارفرمای حوزه‌ی legal-tech با نسخه‌ای از همان مسئله‌ی دسته‌بندی بالا سراغم آمد: یک تیم بیش از ۴۰ ساعت در هفته را صرف استخراج دستی بندها و ابرداده از قراردادهایی می‌کرد که فرمت و زبانشان به‌شدت متفاوت بود. یک سیستم مبتنی‌بر قاعده قبلاً یک‌بار شکست خورده بود. راه‌حل یک پرامپت هوشمند تکی نبود — بلکه شکستن کار به مراحلی بود که یک مدل واقعاً می‌توانست قابل‌اعتماد انجام دهد: اول نوع سند را دسته‌بندی کن، بعد ساختارش را تشخیص بده، بعد فقط درون همان ساختار استخراج کن. هر مرحله کار محدودتر و نرخ خطای پایین‌تری نسبت به تلاش برای انجام همه‌چیز در یک عبور دارد. این دقیقاً همان «دسته‌بندی کسل‌کننده در مقیاس» بالاست، به‌شکل واقعی: هزینه‌ی خطا پایین می‌ماند چون هیچ پرامپت تکی هرگز مجبور نیست پنج کار را همزمان انجام دهد.

تله‌ی چت‌بات

چت‌بات‌ها اغلب پاسخ اشتباه‌اند. نه چون نمی‌توانند کار کنند — می‌توانند — بلکه چون تلاش و نگهداری بالایی می‌طلبند و کل بار فرموله‌کردن یک پرسش خوب را روی دوش کاربر می‌گذارند.

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

چت‌بات‌ها زمانی منطقی‌اند که فضای مسئله واقعاً باز است، نیازهای کاربر به‌شدت متغیرند، و گزینه‌های رابط کاربری ساختاریافته را قبلاً امتحان کرده‌اید.

شکاف قابلیت‌اطمینان

چیزی که هیچ‌کس هنگام شروع ساخت قابلیت‌های هوش مصنوعی به شما نمی‌گوید این است: تحمل کاربران برای خطای هوش مصنوعی بسیار کمتر از انتظار مهندسان است.

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

برای حالت شکست به‌طور صریح طراحی کنید. سطح اطمینان را نشان دهید. پرامپت‌های «این را بررسی کن» اضافه کنید. گزارش مشکلات را آسان کنید. برای تصمیم‌های پرریسک، انسان را در چرخه نگه دارید.

همین انضباط را در پروژه‌های هوش مصنوعی خودم هم اعمال می‌کنم. Cognitive Edge، خط‌لوله‌ی محتوایی که ساختم و روزانه اخبار روان‌شناسی، کسب‌وکار و فناوری را جمع‌آوری و خلاصه می‌کند، منبع اصلی هر آیتمی را که منتشر می‌کند حفظ و ذکر می‌کند — نه به‌عنوان یک فکر بعدی، بلکه به‌عنوان یک قاعده‌ی سخت در خط‌لوله. اگر مدل چیزی را اشتباه خلاصه کند، منبع همان‌جاست تا خواننده بررسی کند. این همان پرامپت «این را بررسی کن» بالاست، که به‌جای این‌که به‌عنوان یک سلب‌مسئولیت چسبانده شود، در خودِ محصول ساخته شده.

// فقط خروجی هوش مصنوعی را نمایش ندهید
const Summary = ({ aiOutput, confidence }: Props) => (
  <div>
    <p>{aiOutput}</p>
    {confidence < 0.8 && (
      <p className="text-amber-600 text-sm">
        ⚠ این خلاصه ممکن است دقیق نباشد. لطفاً سند منبع را بررسی کنید.
      </p>
    )}
  </div>
);

درس فراگیر

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

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

فناوری بخش سخت کار نیست. تفکر محصول است.

پرسش‌های پرتکرار

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

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

می‌خواهید ببینید یک قابلیت هوش مصنوعی برای محصول شما منطقی است یا نه؟ خدمات هوش مصنوعی و اتوماسیون من را ببینید، یا تماس بگیرید.