آموزش اتصال Make.com به API هوش مصنوعی درواره؛ ساخت اتوماسیون بدون کدنویسی

برای استفاده از هوش مصنوعی در یک فرایند کاری همیشه لازم نیست برنامه‌ای کامل با Python، JavaScript یا یک فریم‌ورک بک‌اند بنویسید. بسیاری از اتوماسیون‌های روزمره را می‌توان با ابزارهایی مانند Make.com طراحی کرد و تنها در مرحله پردازش متن، تصویر یا داده به API هوش مصنوعی متصل شد.

برای مثال، می‌توانید سناریویی بسازید که:

• اطلاعات یک فرم را دریافت کند.
• متن واردشده را برای API هوش مصنوعی بفرستد.
• پاسخ را به‌صورت ساختاریافته دریافت کند.
• نتیجه را در Google Sheets، پایگاه داده یا ابزار مدیریت پروژه ذخیره کند.
• پیش‌نویس تولیدشده را برای بررسی انسانی آماده کند.
• درخواست‌های جدید را از طریق Webhook دریافت و پردازش کند.
• بازخورد مشتریان را طبقه‌بندی و خلاصه کند.
• از متن‌های طولانی، عنوان، چکیده یا فهرست اقدامات استخراج کند.

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

Make.com چیست؟

Make.com یک پلتفرم اتوماسیون بصری است که با استفاده از آن می‌توان سرویس‌های مختلف را به یکدیگر متصل کرد. در Make، هر گردش کار خودکار یک Scenario یا سناریو نامیده می‌شود.

هر سناریو از چند Module یا ماژول تشکیل می‌شود. هر ماژول یک کار مشخص انجام می‌دهد؛ برای مثال:

• دریافت پاسخ یک فرم
• خواندن ردیف جدید Google Sheets
• ارسال درخواست HTTP
• پردازش JSON
• ذخیره اطلاعات
• ارسال ایمیل
• ایجاد وظیفه در ابزار مدیریت پروژه
• پاسخ‌دادن به Webhook

Make تنها به اتصال‌های آماده محدود نیست. ماژول HTTP آن اجازه می‌دهد تقریباً به هر سرویس دارای API متصل شوید. نسخه جدید ماژول HTTP همچنین از ساختارهای داده برای ایجاد بدنه JSON معتبر و نگهداری امن‌تر اطلاعات احراز هویت پشتیبانی می‌کند. جزئیات این قابلیت‌ها در مستندات HTTP در Make توضیح داده شده است.

چرا Make.com را به دروازه API هوش مصنوعی متصل کنیم؟

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

درواره دسترسی API به مدل‌های هوش مصنوعی را فراهم می‌کند. بنابراین می‌توانید درخواست را از Make به درواره بفرستید و پاسخ مدل را در ادامه همان سناریو استفاده کنید.

معماری کلی اتصال به این صورت است:

1. یک رویداد، سناریوی Make را فعال می‌کند.
2. Make داده ورودی را دریافت و اعتبارسنجی می‌کند.
3. ماژول HTTP درخواست را به API درواره می‌فرستد.
4. مدل هوش مصنوعی درخواست را پردازش می‌کند.
5. پاسخ JSON به Make برمی‌گردد.
6. Make محتوای پاسخ را استخراج می‌کند.
7. نتیجه برای بررسی، ذخیره‌سازی یا ادامه فرایند استفاده می‌شود.

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

اصطلاحات مهم Make.com

قبل از ساخت سناریو بهتر است با چند اصطلاح اصلی آشنا شوید.

برای مثال، اگر یک سناریو با دریافت ردیف جدید از Google Sheets شروع شود، ماژول Watch New Rows نقش Trigger را دارد. ماژول HTTP یک Action است و اطلاعات هر ردیف در قالب Bundle وارد مراحل بعدی می‌شود.

پیش‌نیازهای اتصال Make.com به درواره

برای اجرای آموزش به موارد زیر نیاز دارید:

• حساب کاربری Make.com
• حساب درواره
• کلید API درواره
• شناسه مدل موردنظر
• آشنایی مقدماتی با JSON
• یک متن آزمایشی برای پردازش

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

در تمام مثال‌ها از مقادیر نمونه زیر استفاده می‌کنیم:

YOUR_DARVAREH_API_KEY
YOUR_MODEL_ID

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

آدرس API موردنیاز

آدرس پایه API درواره:

https://api.darvareh.ir/v1

Endpoint مورد استفاده برای درخواست مکالمه:

https://api.darvareh.ir/v1/chat/completions

درخواست باید با متد POST ارسال شود و دو Header اصلی داشته باشد:

Authorization: Bearer YOUR_DARVAREH_API_KEY
Content-Type: application/json

ساختار پایه بدنه درخواست نیز به‌صورت زیر است:

{
  "model": "YOUR_MODEL_ID",
  "messages": [
    {
      "role": "system",
      "content": "شما یک دستیار دقیق برای خلاصه‌سازی متن‌های فارسی هستید."
    },
    {
      "role": "user",
      "content": "متن موردنظر کاربر"
    }
  ],
  "temperature": 0.2,
  "max_tokens": 800
}

سناریوی اول: دریافت متن با Webhook و خلاصه‌سازی خودکار

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

جریان سناریو چنین خواهد بود:

Custom Webhook → اعتبارسنجی ورودی → HTTP Request → استخراج پاسخ → Webhook Response

مرحله اول: ساخت Scenario جدید

وارد حساب Make شوید و یک Scenario جدید بسازید.

در صفحه طراحی سناریو:

1. روی علامت افزودن ماژول کلیک کنید.
2. برنامه Webhooks را جست‌وجو کنید.
3. ماژول Custom Webhook را انتخاب کنید.
4. روی Add کلیک کنید.
5. یک نام مانند Darvareh AI Input وارد کنید.
6. تنظیمات را ذخیره کنید.

Make یک URL اختصاصی برای Webhook ایجاد می‌کند. این آدرس را کپی کنید.

ساختار کلی آن شبیه نمونه زیر است:

https://hook.example.make.com/xxxxxxxxxxxxxxxx

آدرس واقعی Webhook مانند یک Endpoint عمومی عمل می‌کند. آن را در صفحه عمومی، فایل اشتراکی یا مخزن کد منتشر نکنید.

مرحله دوم: ارسال درخواست آزمایشی به Webhook

برای اینکه Make ساختار داده ورودی را تشخیص دهد، روی Run once کلیک کنید. سپس از یک ترمینال درخواست زیر را ارسال کنید:

curl -X POST "YOUR_MAKE_WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -d '{
    "request_id": "demo-001",
    "task": "summarize",
    "text": "هوش مصنوعی می‌تواند بخشی از فرایندهای تکراری سازمان را خودکار کند، اما پاسخ‌های تولیدشده باید متناسب با حساسیت کاربرد ارزیابی و در صورت لزوم توسط انسان بررسی شوند."
  }'

مقدار YOUR_MAKE_WEBHOOK_URL را با آدرسی که Make ساخته است جایگزین کنید.

پس از دریافت درخواست، Make فیلدهای زیر را شناسایی می‌کند:

• request_id
• task
• text

استفاده از request_id کمک می‌کند هر درخواست را ردیابی کنید و مانع پردازش ناخواسته یک درخواست تکراری شوید.

مرحله سوم: اعتبارسنجی ورودی

نباید هر داده‌ای را بدون بررسی به مدل ارسال کرد. بین Webhook و ماژول HTTP یک Filter ایجاد کنید.

برای نمونه، شرایط زیر را در Filter قرار دهید:

• فیلد text وجود داشته باشد.
• مقدار text خالی نباشد.
• طول متن از حد موردنظر شما بیشتر نباشد.
• مقدار task برابر summarize باشد.

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

اعتبارسنجی ورودی سه فایده دارد:

• درخواست‌های ناقص را متوقف می‌کند.
• مصرف غیرضروری توکن را کاهش می‌دهد.
• رفتار سناریو را قابل پیش‌بینی‌تر می‌کند.

مرحله چهارم: افزودن ماژول HTTP

پس از Filter یک ماژول جدید اضافه کنید:

1. برنامه HTTP را انتخاب کنید.
2. ماژول Make a request را اضافه کنید.
3. در صورت نمایش انتخاب نسخه، نسخه جدید HTTP یا نسخه 4 را انتخاب کنید.
4. متد را روی POST قرار دهید.
5. URL را برابر Endpoint درواره تنظیم کنید.

https://api.darvareh.ir/v1/chat/completions

مرحله پنجم: تنظیم Headerها

در قسمت Headers دو مقدار زیر را اضافه کنید:

اگر نسخه مورد استفاده Make امکان تعریف Credential یا API Key در بخش امن اتصال را ارائه می‌کند، کلید را در همان بخش ذخیره کنید. در نسخه جدید HTTP، Make برای نگهداری و چرخش مستقل کلیدها قابلیت Keychain ارائه کرده است.

کلید API را در موارد زیر قرار ندهید:

• URL یا Query String
• فیلدهای Google Sheets
• متن پرامپت
• خروجی Webhook
• پیام‌های خطای عمومی
• فایل Blueprint عمومی
• مستندات قابل دسترسی برای کاربران

مرحله ششم: ساخت بدنه JSON

در بخش Body، نوع محتوا را روی application/json قرار دهید.

در نسخه جدید ماژول HTTP بهتر است روش Data Structure را انتخاب کنید. این روش احتمال تولید JSON نامعتبر را کاهش می‌دهد.

ساختار موردنیاز شامل این فیلدها است:

• model از نوع Text
• messages از نوع Array
• هر عضو messages از نوع Collection
• role از نوع Text
• content از نوع Text
• temperature از نوع Number
• max_tokens از نوع Number

برای تولید ساختار می‌توانید نمونه زیر را در بخش Generate وارد کنید:

{
  "model": "YOUR_MODEL_ID",
  "messages": [
    {
      "role": "system",
      "content": "شما یک دستیار دقیق برای خلاصه‌سازی متن فارسی هستید."
    },
    {
      "role": "user",
      "content": "متن ورودی"
    }
  ],
  "temperature": 0.2,
  "max_tokens": 800
}

پس از ساخته‌شدن Data Structure، مقدار content مربوط به پیام کاربر را به فیلد text ماژول Webhook متصل کنید. این همان Mapping بین ماژول اول و ماژول HTTP است.

برای پیام System می‌توانید از دستور زیر استفاده کنید:

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

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

استفاده از Raw JSON

اگر رابط Make شما از روش Data Structure پشتیبانی نمی‌کند، می‌توانید بدنه را در حالت Raw وارد کنید:

{
  "model": "YOUR_MODEL_ID",
  "messages": [
    {
      "role": "system",
      "content": "شما یک دستیار دقیق برای خلاصه‌سازی متن فارسی هستید. اطلاعاتی خارج از متن اضافه نکنید."
    },
    {
      "role": "user",
      "content": "INPUT_TEXT"
    }
  ],
  "temperature": 0.2,
  "max_tokens": 800
}

سپس INPUT_TEXT را با توکن Mapping فیلد text جایگزین کنید.

هنگام استفاده از Raw JSON باید مراقب نقل‌قول، خط جدید و کاراکترهای خاص باشید. چسباندن مستقیم متن کاربر داخل JSON ممکن است بدنه نامعتبر بسازد. اگر متن پویا شامل کاراکترهای مختلف است، استفاده از Data Structure یا تابع تبدیل معتبر به JSON انتخاب مطمئن‌تری است.

تنظیم پارامترهای مدل

دو پارامتر مهم این درخواست temperature و max_tokens هستند.

Temperature

پارامتر Temperature میزان تنوع پاسخ را کنترل می‌کند.

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

"temperature": 0.1

یا:

"temperature": 0.2

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

"temperature": 0.7

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

Max Tokens

پارامتر max_tokens حداکثر طول پاسخ مدل را کنترل می‌کند:

"max_tokens": 800

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

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

مرحله هفتم: اجرای درخواست و بررسی پاسخ

ماژول HTTP را ذخیره و Scenario را با Run once اجرا کنید. سپس دوباره یک درخواست آزمایشی به Webhook بفرستید.

پاسخ موفق API معمولاً ساختاری مشابه نمونه زیر دارد:

{
  "id": "response-id",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "خلاصه تولیدشده توسط مدل"
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 120,
    "completion_tokens": 85,
    "total_tokens": 205
  }
}

مهم‌ترین مقدار موردنیاز در ادامه سناریو، محتوای پیام مدل است:

choices[0].message.content

در رابط Mapping نرم‌افزار Make ممکن است اولین عضو آرایه با شماره 1 نمایش داده شود. بنابراین فیلد قابل انتخاب در رابط می‌تواند ظاهری شبیه این داشته باشد:

Choices[1] → Message → Content

این تفاوت به شیوه نمایش آرایه‌ها در رابط Make مربوط است؛ ساختار JSON همچنان از اندیس صفر استفاده می‌کند.

اگر ماژول HTTP پاسخ را به‌صورت خودکار تجزیه نمی‌کند، گزینه Parse response را فعال کنید. در غیر این صورت می‌توانید پس از HTTP از ماژول JSON و عملیات Parse JSON استفاده کنید.

مرحله هشتم: بازگرداندن نتیجه به فرستنده

پس از ماژول HTTP یک ماژول Webhook Response اضافه کنید.

Status را روی 200 قرار دهید و Header زیر را اضافه کنید:

Content-Type: application/json

بدنه پاسخ می‌تواند چنین ساختاری داشته باشد:

{
  "ok": true,
  "request_id": "MAPPED_REQUEST_ID",
  "result": "MAPPED_AI_CONTENT"
}

دو مقدار پویا را از ماژول‌های قبلی Map کنید:

• MAPPED_REQUEST_ID از Webhook
• MAPPED_AI_CONTENT از پاسخ ماژول HTTP

پاسخ نهایی نمونه:

{
  "ok": true,
  "request_id": "demo-001",
  "result": "هوش مصنوعی می‌تواند فرایندهای تکراری را خودکار کند، اما نتیجه باید متناسب با حساسیت کاربرد بررسی انسانی شود."
}

تست کامل Webhook

پس از تکمیل سناریو، آن را فعال کنید و درخواست زیر را بفرستید:

curl -X POST "YOUR_MAKE_WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -d '{
    "request_id": "demo-002",
    "task": "summarize",
    "text": "اتوماسیون فرایندهای متنی می‌تواند زمان انجام کارهای تکراری را کاهش دهد. با این حال، کیفیت ورودی، انتخاب مدل، طراحی پرامپت و کنترل خروجی بر نتیجه نهایی اثر مستقیم دارند."
  }'

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

سناریوی دوم: تحلیل بازخورد مشتریان در Google Sheets

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

فرض کنید یک فایل Google Sheets با ستون‌های زیر دارید:

جریان پیشنهادی سناریو:

Google Sheets Watch New Rows
→ Filter
→ HTTP Request
→ Parse Response
→ Google Sheets Update a Row

جلوگیری از پردازش تکراری

Filter را طوری تنظیم کنید که تنها ردیف‌هایی پردازش شوند که:

• ستون Feedback خالی نیست.
• ستون Status خالی یا برابر Pending است.
• ستون Summary هنوز مقدار ندارد.

پس از پردازش، مقدار Status را روی Processed قرار دهید.

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

پرامپت پیشنهادی برای تحلیل بازخورد

شما دستیار تحلیل بازخورد کاربران هستید.

متن ورودی را بررسی کن و موارد زیر را مشخص کن:

1. category:
یکی از مقادیر product، support، pricing، usability یا other

2. priority:
یکی از مقادیر low، medium یا high

3. summary:
خلاصه فارسی حداکثر در ۲ جمله

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

پیام User:

متن بازخورد:
{{Feedback}}

خروجی مطلوب:

{
  "category": "usability",
  "priority": "medium",
  "summary": "کاربر در پیداکردن گزینه خروجی گرفتن مشکل داشته و واضح‌ترشدن مسیر دسترسی را درخواست کرده است."
}

بعد از دریافت پاسخ، آن را با Parse JSON تجزیه کنید و هر فیلد را در ستون مرتبط Google Sheets قرار دهید.

چرا خروجی ساختاریافته بهتر است؟

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

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

• نمونه قالب دقیق ارائه کنید.
• مقدارهای مجاز را محدود کنید.
• Temperature را پایین نگه دارید.
• بعد از پاسخ از Parse JSON استفاده کنید.
• برای خطای تجزیه مسیر Error Handler بسازید.
• مقدارهای حساس را قبل از استفاده نهایی بررسی کنید.

سناریوی سوم: تولید پیش‌نویس محتوا با تأیید انسانی

می‌توانید Make را طوری تنظیم کنید که موضوع‌های آماده را از Google Sheets بخواند و برای هرکدام یک پیش‌نویس تولید کند.

ستون‌های پیشنهادی:

جریان سناریو:

Scheduler
→ Search Rows
→ Filter Status = Ready
→ HTTP Request
→ Update Row
→ Status = Needs Review

پرامپت پیشنهادی:

شما دستیار تولید پیش‌نویس محتوای فارسی هستید.

بر اساس اطلاعات ورودی یک پیش‌نویس اولیه تهیه کن.

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

پیام User:

موضوع: {{Topic}}
مخاطب: {{Audience}}
کلمات کلیدی: {{Keywords}}

خروجی را در ستون Draft ذخیره و Status را روی Needs Review قرار دهید.

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

زمان‌بندی اجرای سناریو

در Make می‌توانید سناریو را در فاصله‌های زمانی مختلف اجرا کنید؛ برای مثال:

• هر ۱۵ دقیقه
• هر یک ساعت
• روزانه
• در روزهای مشخص هفته
• در تاریخ تعیین‌شده
• بلافاصله پس از دریافت Webhook

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

برای Webhook، سناریو به‌صورت آنی با دریافت درخواست اجرا می‌شود. اگر چند درخواست هم‌زمان وارد شوند، ممکن است اجراهای موازی ایجاد شود. در فرایندهایی که ترتیب اهمیت دارد، گزینه Process data in order را در تنظیمات Scenario بررسی کنید.

مدیریت خطاها در Make

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

Make برای این کار Error Handler ارائه می‌کند. طبق راهنمای مدیریت خطا در Make، می‌توان مسیرهای متفاوتی برای ردکردن، ادامه‌دادن، ذخیره اجرای ناقص یا تلاش مجدد تعریف کرد.

خطاهای رایج اتصال به API

چه خطاهایی را دوباره تلاش کنیم؟

Retry برای خطاهای موقت مناسب است؛ مانند:

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

Retry برای خطاهای دائمی مناسب نیست؛ مانند:

• کلید API اشتباه
• JSON نامعتبر
• Endpoint نادرست
• شناسه مدل نامعتبر
• نبودن فیلد اجباری

تلاش مجدد برای خطای دائمی فقط تعداد عملیات و زمان رفع مشکل را افزایش می‌دهد.

Make یک Retry Error Handler دارد که می‌تواند اجرای ناقص را ذخیره و بعداً به‌صورت دستی یا خودکار دوباره اجرا کند. تنظیمات و رفتار آن در مستندات Retry Error Handler توضیح داده شده است.

الگوی پیشنهادی Retry

برای خطاهای موقت می‌توانید الگویی مانند این در نظر بگیرید:

• تلاش اول: اجرای عادی
• تلاش دوم: پس از یک دقیقه
• تلاش سوم: پس از پنج دقیقه
• تلاش نهایی: پس از پانزده دقیقه
• در صورت شکست نهایی: ثبت خطا و ارسال هشدار به مدیر سناریو

تعداد و فاصله تلاش‌ها را متناسب با اهمیت عملیات، ظرفیت API و محدودیت‌های حساب Make تنظیم کنید.

کنترل هزینه استفاده از هوش مصنوعی

هر درخواست به مدل می‌تواند بر اساس تعداد توکن‌های ورودی و خروجی هزینه داشته باشد. بنابراین سناریو باید فقط در مواقع ضروری API را فراخوانی کند.

استفاده از Filter قبل از HTTP

ابتدا بررسی کنید که:

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

محدودکردن خروجی

با max_tokens طول پاسخ را کنترل کنید:

"max_tokens": 500

برای یک دسته‌بندی ساده، تولید چند هزار توکن منطقی نیست.

کوتاه و مشخص‌کردن پرامپت

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

انتخاب مدل متناسب با وظیفه

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

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

ثبت میزان مصرف

اگر پاسخ API شامل بخش usage باشد، این مقادیر را ثبت کنید:

usage.prompt_tokens
usage.completion_tokens
usage.total_tokens

می‌توانید آن‌ها را در Google Sheets یا پایگاه داده ذخیره کنید تا میانگین مصرف هر سناریو مشخص شود.

جلوگیری از اجرای تکراری

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

برای جلوگیری از آن:

1. برای هر درخواست یک request_id یکتا تعریف کنید.
2. شناسه‌های پردازش‌شده را در Data Store یا پایگاه داده ذخیره کنید.
3. پیش از فراخوانی API بررسی کنید شناسه قبلاً وجود نداشته باشد.
4. پس از موفقیت، وضعیت رکورد را به Processed تغییر دهید.
5. عملیات ذخیره نتیجه را طوری طراحی کنید که به‌روزرسانی انجام دهد، نه ایجاد بی‌قیدوشرط رکورد جدید.

در Google Sheets می‌توانید از ترکیب ستون‌های ID و Status استفاده کنید. در یک سیستم بزرگ‌تر، استفاده از یک جدول با Unique Constraint انتخاب مطمئن‌تری است.

پردازش چند رکورد

اگر یک ماژول چندین Bundle ایجاد کند، ماژول HTTP برای هر Bundle یک‌بار اجرا خواهد شد.

برای مثال، اگر Search Rows تعداد ۱۰۰ ردیف برگرداند، ممکن است ۱۰۰ درخواست API ارسال شود.

برای کنترل آن:

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

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

طراحی پرامپت پویا در Make

در Make می‌توانید اطلاعات چند ماژول را در یک پرامپت قرار دهید.

برای مثال:

نقش: دستیار خلاصه‌سازی گزارش

عنوان گزارش:
{{Title}}

تاریخ:
{{Date}}

متن:
{{Body}}

خروجی موردنیاز:
- خلاصه حداکثر ۱۵۰ کلمه
- سه نکته مهم
- فهرست اقدامات پیشنهادی موجود در خود متن

با این حال، بهتر است دستورهای اصلی در پیام System ثابت باشند و داده‌های کاربر در پیام User قرار گیرند.

ساختار پیشنهادی:

{
  "role": "system",
  "content": "دستور ثابت و قواعد مدل"
}

{
  "role": "user",
  "content": "داده پویا دریافت‌شده از فرم یا سرویس دیگر"
}

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

چند پرامپت آماده برای اتوماسیون

خلاصه‌سازی متن

متن ورودی را در حداکثر ۵ نکته خلاصه کن.

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

استخراج اقدامات

از متن ورودی فقط اقداماتی را استخراج کن که انجام آن‌ها صریحاً درخواست یا تعیین شده است.

برای هر اقدام این فیلدها را برگردان:
- action
- owner
- deadline

اگر مسئول یا مهلت مشخص نیست، مقدار null قرار بده.
پاسخ فقط JSON معتبر باشد.

دسته‌بندی درخواست پشتیبانی

درخواست را در یکی از دسته‌های زیر قرار بده:

technical
billing
account
feature_request
other

خروجی فقط شامل JSON زیر باشد:

{
  "category": "...",
  "summary": "...",
  "needs_human_review": true
}

بازنویسی متن رسمی

متن ورودی را با لحن رسمی، شفاف و محترمانه بازنویسی کن.

قواعد:
- مفهوم متن تغییر نکند.
- اطلاعات جدید اضافه نشود.
- نام‌ها و اعداد حفظ شوند.
- عبارت‌های مبهم به شکل قطعی بازنویسی نشوند.

تولید عنوان

برای متن ورودی ۱۰ عنوان فارسی پیشنهاد بده.

قواعد:
- عنوان‌ها طبیعی و دقیق باشند.
- از ادعاهای اغراق‌آمیز استفاده نشود.
- هر عنوان حداکثر ۶۵ کاراکتر باشد.
- عنوان‌ها تکراری نباشند.

طراحی مسیر بررسی انسانی

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

یک جریان مناسب می‌تواند چنین باشد:

دریافت ورودی
→ پردازش با مدل
→ ذخیره به‌عنوان Draft
→ اطلاع به مسئول بررسی
→ تأیید یا اصلاح
→ استفاده نهایی

برای پیاده‌سازی آن، فیلد Status را با مقادیر زیر نگه دارید:

• Pending
• Processing
• Needs Review
• Approved
• Rejected
• Failed

پس از تولید پاسخ، وضعیت را روی Needs Review قرار دهید. تنها رکوردهای Approved باید وارد مرحله بعد شوند.

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

ثبت گزارش اجرای سناریو

برای عیب‌یابی و کنترل مصرف، اطلاعات زیر را ثبت کنید:

• شناسه درخواست
• زمان شروع
• زمان پایان
• نام سناریو
• شناسه مدل
• نوع عملیات
• وضعیت پاسخ
• تعداد توکن ورودی
• تعداد توکن خروجی
• تعداد کل توکن‌ها
• پیام خطای خلاصه‌شده
• وضعیت بررسی انسانی

اطلاعات حساس مانند کلید API، متن Authorization و داده‌های محرمانه را در Log ذخیره نکنید.

نمونه رکورد:

{
  "request_id": "demo-002",
  "scenario": "feedback-summary",
  "model": "YOUR_MODEL_ID",
  "status": "success",
  "total_tokens": 287,
  "review_status": "pending"
}

نکات نگهداری کلید API

برای کاهش احتمال افشای کلید:

• دسترسی ویرایش Scenario را محدود کنید.
• از Credential یا Keychain داخلی ماژول HTTP استفاده کنید.
• کلید را در Google Sheets ذخیره نکنید.
• کلید را داخل پرامپت قرار ندهید.
• کلید را در خروجی Webhook برنگردانید.
• در تصاویر آموزشی، مقدار کلید را مخفی کنید.
• در صورت احتمال افشا، کلید را تعویض کنید.
• برای محیط آزمایشی و عملیاتی تنظیمات جداگانه داشته باشید.

جداسازی محیط آزمایش و محیط اصلی

برای سناریوهای مهم بهتر است دو نسخه داشته باشید:

محیط آزمایش

• ورودی نمونه
• تعداد محدود درخواست
• مدل و تنظیمات آزمایشی
• ذخیره نتیجه در Sheet آزمایشی
• Scenario غیرفعال یا دارای زمان‌بندی محدود

محیط عملیاتی

• Webhook و Data Store مستقل
• دسترسی محدود
• مدیریت خطا
• ثبت مصرف
• محدودیت تعداد رکورد
• مسیر تأیید انسانی
• هشدار برای شکست‌های متوالی

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

عیب‌یابی اتصال Make به درواره

خطای Unauthorized دریافت می‌کنم

موارد زیر را بررسی کنید:

• Header با نام دقیق Authorization ساخته شده باشد.
• مقدار با Bearer و یک فاصله شروع شود.
• کلید API کامل باشد.
• کلید حذف یا غیرفعال نشده باشد.
• فاصله یا خط جدید اضافی در ابتدا و انتهای کلید وجود نداشته باشد.

ساختار صحیح:

Bearer YOUR_DARVAREH_API_KEY

پاسخ HTTP موفق است اما Content نمایش داده نمی‌شود

احتمالاً پاسخ JSON هنوز Parse نشده است.

• گزینه Parse response را فعال کنید.
• ماژول را یک‌بار اجرا کنید تا ساختار پاسخ شناسایی شود.
• در صورت نیاز از JSON > Parse JSON استفاده کنید.
• مسیر choices → message → content را انتخاب کنید.

JSON ورودی نامعتبر است

این خطا معمولاً زمانی رخ می‌دهد که متن پویا مستقیماً داخل Raw JSON قرار گرفته و شامل نقل‌قول یا خط جدید است.

راه‌حل پیشنهادی:

• از Data Structure استفاده کنید.
• نوع Body را روی JSON قرار دهید.
• متن را به‌صورت Mapping در فیلد تعریف‌شده قرار دهید.
• اگر از Raw استفاده می‌کنید، مقدار پویا را به JSON معتبر تبدیل کنید.

پاسخ مدل JSON نیست

اگر برای مرحله بعد به JSON نیاز دارید:

• در پرامپت صریحاً بگویید پاسخ فقط JSON معتبر باشد.
• قالب کامل خروجی را نشان دهید.
• مقدارهای مجاز را مشخص کنید.
• Temperature را کاهش دهید.
• یک مرحله Parse JSON اضافه کنید.
• برای Parse Error مسیر خطا تعریف کنید.

سناریو چند بار اجرا می‌شود

موارد زیر را بررسی کنید:

• آیا به‌روزرسانی Google Sheets دوباره Trigger را فعال می‌کند؟
• آیا Status پس از پردازش تغییر می‌کند؟
• آیا request_id یکتا است؟
• آیا چند Schedule هم‌زمان تعریف شده است؟
• آیا برنامه فرستنده Webhook در صورت تأخیر، درخواست را دوباره ارسال می‌کند؟

پاسخ دیر برمی‌گردد

علل احتمالی:

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

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

چک‌لیست آماده‌سازی برای استفاده واقعی

پیش از فعال‌کردن Scenario، این موارد را بررسی کنید:

• Endpoint درواره درست است.
• کلید API در محل امن نگهداری می‌شود.
• شناسه مدل معتبر است.
• Body درخواست JSON معتبر تولید می‌کند.
• ورودی خالی یا بیش از حد طولانی رد می‌شود.
• max_tokens متناسب با خروجی است.
• درخواست‌ها شناسه یکتا دارند.
• پردازش تکراری کنترل شده است.
• خطاهای موقت مسیر Retry دارند.
• خطاهای دائمی بی‌دلیل Retry نمی‌شوند.
• پاسخ مدل قبل از استفاده حساس بررسی می‌شود.
• وضعیت هر رکورد ثبت می‌شود.
• مصرف توکن قابل گزارش‌گیری است.
• تعداد رکوردهای هر اجرا محدود شده است.
• سناریوی آزمایشی از سناریوی اصلی جدا است.
• خروجی تولیدی بدون بررسی انسانی منتشر یا ارسال نمی‌شود.

پرسش‌های متداول

آیا اتصال Make.com به درواره به برنامه‌نویسی نیاز دارد؟

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

آیا می‌توان Make را به هر مدل درواره متصل کرد؟

در صورتی که مدل موردنظر از Endpoint و قابلیت مورد استفاده پشتیبانی کند، می‌توانید شناسه آن را در فیلد model قرار دهید. فهرست مدل‌ها و قیمت‌ها در صفحه مدل‌های درواره ارائه می‌شود.

آیا می‌توان ورودی را از فرم دریافت کرد؟

بله. می‌توانید از Webhook یا اتصال آماده سرویس فرم‌ساز استفاده کنید. سپس فیلدهای فرم را به ماژول HTTP Map کنید.

آیا می‌توان نتیجه را در Google Sheets ذخیره کرد؟

بله. پس از دریافت پاسخ API، ماژول Google Sheets و عملیات Add a Row یا Update a Row را اضافه و محتوای پاسخ را به ستون موردنظر متصل کنید.

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

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

چگونه هزینه سناریو را کاهش دهیم؟

از Filter پیش از HTTP استفاده کنید، متن‌های تکراری را حذف کنید، max_tokens را محدود نگه دارید، مدل متناسب با وظیفه انتخاب کنید و میزان مصرف توکن را ثبت کنید.

تفاوت Webhook با Schedule چیست؟

Webhook سناریو را هنگام دریافت یک رویداد فعال می‌کند. Schedule سناریو را در زمان‌های تعیین‌شده اجرا می‌کند. Webhook برای پردازش آنی و Schedule برای پردازش دوره‌ای مناسب‌تر است.

آیا Make پاسخ JSON را به‌صورت خودکار می‌خواند؟

اگر Parse response فعال باشد و پاسخ با Content-Type مناسب برگردد، فیلدها معمولاً قابل Mapping می‌شوند. در غیر این صورت می‌توانید از ماژول Parse JSON استفاده کنید.

برای هر درخواست چند Operation مصرف می‌شود؟

تعداد Operation به تعداد ماژول‌های اجراشده و Bundleهای پردازش‌شده بستگی دارد. اگر یک سناریو پنج ماژول داشته باشد و ۲۰ Bundle پردازش کند، مصرف عملیات می‌تواند به‌طور محسوسی افزایش یابد. Filter کردن داده‌ها پیش از ماژول‌های پرهزینه اهمیت زیادی دارد.

جمع‌بندی

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

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

برای شروع:

1. در درواره حساب کاربری ایجاد کنید.
2. کلید API خود را دریافت کنید.
3. مدل متناسب با کاربردتان را از صفحه مدل‌ها انتخاب کنید.
4. در Make یک Scenario آزمایشی بسازید.
5. اتصال را با یک Webhook و متن نمونه آزمایش کنید.
6. پس از بررسی پاسخ، مدیریت خطا و کنترل هزینه را اضافه کنید.
7. سناریو را ابتدا با حجم محدود فعال کنید.

مقالات مرتبط

• آموزش اتصال n8n به درواره
• آموزش اتصال API هوش مصنوعی به اپلیکیشن
• آموزش API درواره با Postman
• آموزش API درواره با cURL
• آموزش دریافت کلید API هوش مصنوعی
• API سازگار با OpenAI چیست؟
• راهنمای توکن در API هوش مصنوعی
• روش‌های کاهش هزینه API هوش مصنوعی

برای مطالعه شرایط استفاده و محدودیت‌های مسئولیت، صفحه «سلب مسئولیت» را مشاهده کنید.