خودکارسازی کسب‌وکار با وب‌سرویس هوش مصنوعی؛ چهار جریان واقعی

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

این‌ها دقیقاً همان کارهایی هستند که وب‌سرویس (API) هوش مصنوعی برایشان ساخته شده: ورودی مشخص، خروجی مشخص، تکرار زیاد. در این راهنما چهار جریان واقعی را باز می‌کنیم؛ برای هرکدام شکل دستور، قالب خروجی و یک برآورد صادقانه از مصرف توکن به‌ازای هر هزار مورد. عدد ریالی نمی‌نویسیم، چون نرخ‌ها تغییر می‌کنند و برآورد توکن همیشه معتبر می‌ماند.

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

جریان اول: دسته‌بندی و اولویت تیکت پشتیبانی

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

system:
You are a support triage classifier for an online shop.
Return ONLY a JSON object with this exact shape:
{
  "category": "order | payment | delivery | account | refund | other",
  "priority": "low | normal | high",
  "needs_human": true,
  "confidence": 0.0,
  "summary": "one short Persian sentence"
}
Never answer the customer. Never invent order numbers.

user:
موضوع: پرداخت کردم ولی سفارش ثبت نشد
متن: سلام، دیروز مبلغ از حسابم کم شد ولی توی سفارش‌هام چیزی نیست…

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

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

جریان دوم: تولید توضیح محصول

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

system:
You write Persian product descriptions for an online shop.
Rules:
- 40 to 60 words, one paragraph, written (not spoken) Persian.
- Use only the attributes given. If an attribute is missing, do not mention it.
- Never promise delivery time, warranty, price or stock.
- No exclamation marks, no emoji, no superlatives.
Return ONLY: {"description": "…"}

user:
{"title":"کفش دویدن مردانه مدل X","material":"مش","sole":"فوم","weight":"۲۶۰ گرم","colors":["مشکی","خاکستری"]}

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

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

جریان سوم: استخراج داده از فاکتور و سند

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

system:
Extract fields from the invoice image. Return ONLY this JSON:
{
  "invoice_number": "string|null",
  "issued_at": "YYYY-MM-DD|null",
  "seller": "string|null",
  "total": "number|null",
  "currency": "IRR|USD|null",
  "line_items": [{"title":"string","qty":number,"unit_price":number}],
  "unreadable_fields": ["…"]
}
Use null for anything you cannot read. Never guess a number.

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

جریان چهارم: صلاحیت‌سنجی سرنخ فروش

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

system:
Score an inbound sales lead for a B2B software vendor.
Return ONLY:
{
  "score": 0,
  "budget_signal": "none | weak | clear",
  "timeline": "now | this_quarter | later | unknown",
  "decision_maker": true,
  "next_action": "call | email | nurture | reject",
  "reason": "one short Persian sentence"
}
Score 0-100. If information is missing, lower the score instead of guessing.

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

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

هزینه: برآورد توکن برای هر هزار مورد

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

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

سه قانونی که خروجی را قابل اتکا می‌کند

• همیشه JSON با شمای ثابت. خروجی آزاد برای خواندن آدم خوب است، نه برای خوردن به دیتابیس. قالب را در دستور بنویسید و در کد خودتان هم اعتبارسنجی کنید. روش‌های قابل اتکا در خروجی JSON قابل اعتماد از مدل آمده است.
• دمای پایین و سقف خروجی مشخص. برای کارهای طبقه‌بندی و استخراج، تنوع دشمن شماست. مقدار temperature نزدیک صفر و max_tokens متناسب با طول واقعی خروجی بگذارید.
• راه فرار برای مدل باز بگذارید. فیلدهایی مثل confidence، null و unreadable_fields باعث می‌شوند مدل به‌جای حدس زدن، اعلام کند که نمی‌داند. این تنها راه ساختن یک صف بازبینی انسانی کوچک و مفید است.

چه کاری را به مدل نسپارید

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

از نمونه تا خط تولید

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

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