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