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

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

نمونه‌ها با سطح عمومی Chat Completions نوشته شده‌اند. نشانی سرویس، کلید و شناسه مدل باید از دسترسی معتبر حساب شما گرفته شوند؛ در متن، نشانی اجرایی یا شناسه مجاز ساختگی درج نشده است. قابلیت‌های اختیاری فقط وقتی ارسال می‌شوند که همان مدل و همان اتصال از آن‌ها پشتیبانی کنند. «OpenAI-compatible API surface» درباره بخش‌های سازگار رابط است و به معنی سازگاری صددرصدی همه امکانات و SDKها نیست.

۱. مسیر صحیح درخواست از مرورگر تا مدل

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

کلید سرویس را در JavaScript عمومی، اپلیکیشن قابل دانلود، HTML یا localStorage نگذارید. مخفی‌کردن مقدار در فایل minifyشده یا متغیر محیطیِ قابل انتشار به فرانت‌اند، از آن محافظت نمی‌کند. کاربر نهایی به کلید شما نیاز ندارد؛ او باید فقط به endpoint محدود برنامه شما دسترسی داشته باشد.

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

۲. قرارداد اتصال را پیش از نوشتن کد مشخص کنید

در این راهنما دو مسیر پایه را در نظر می‌گیریم: GET /v1/models برای فهرست مدل‌ها و POST /v1/chat/completions برای درخواست گفتگو. احراز هویت از هدر Authorization: Bearer <API_KEY> استفاده می‌کند. راهنمای مرجع و تغییرات قرارداد را در مستندات توسعه‌دهندگان IranNet AI API بررسی کنید.

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

۳. اولین درخواست با cURL

در نمونه زیر، IRANNET_AI_ORIGIN فقط مبدأ رسمی سرویس است و پسوند /v1 ندارد. متغیرهای محیطی باید در محیط خصوصی سرور تنظیم شده باشند. نمونه Chat Completions برای ساخت JSON از jq استفاده می‌کند تا نام مدل به شکل درست در بدنه قرار گیرد. این نمونه یک ابزار خط فرمان برای بررسی اتصال است، نه کدی که در مرورگر اجرا شود.

#!/usr/bin/env bash
# Requires curl with --fail-with-body and jq. Server-side only.
set -euo pipefail
: "${IRANNET_AI_ORIGIN:?Set the official HTTPS origin without /v1}"
: "${IRANNET_API_KEY:?Set the key privately on the server}"
: "${IRANNET_MODEL_ID:?Select a permitted model ID}"

curl --proto '=https' --fail-with-body --max-time 60 \
  "${IRANNET_AI_ORIGIN%/}/v1/models" \
  -H "Authorization: Bearer $IRANNET_API_KEY"

jq -n --arg model "$IRANNET_MODEL_ID" \
  '{model:$model,messages:[{role:"user",content:"یک سلام کوتاه فارسی بنویس."}]}' |
  curl --proto '=https' --fail-with-body --max-time 60 \
    "${IRANNET_AI_ORIGIN%/}/v1/chat/completions" \
    -H "Authorization: Bearer $IRANNET_API_KEY" \
    -H "Content-Type: application/json" --data-binary @-

اول پاسخ فهرست مدل‌ها را بررسی کنید، سپس شناسه مجاز را انتخاب کنید. موفقیت درخواست GET ثابت نمی‌کند هر مدل اجازه یا قابلیت یکسانی دارد. اگر POST خطا داد، قبل از تغییر پرامپت، مسیر، روش HTTP، Content-Type و مجوز مدل را کنترل کنید. خطای اتصال، مسئله زبانی مدل نیست.

کلید را در اسکرین‌شات، تیکت عمومی یا خروجی verbose منتشر نکنید. هنگام اشتراک‌گذاری خطا، مقدار Authorization و داده حساس را حذف کنید و فقط وضعیت HTTP، شناسه پیگیریِ غیرمحرمانه و شرح مرحله شکست را بدهید. خاموش‌کردن بررسی TLS، راه‌حل قابل قبول خطای گواهی در تولید نیست.

۴. نمونه Python با کتابخانه استاندارد

این نمونه به SDK اختصاصی وابسته نیست و از http.client استفاده می‌کند. درخواست بدون دنبال‌کردن redirect، با مهلت انتظار و محدودیت اندازه پاسخ خوانده می‌شود. در خطا، بدنه خام پاسخ چاپ نمی‌شود تا داده داخلی ناخواسته وارد لاگ نشود. مرجع رفتار کتابخانه، مستندات Python است. [۱]

# Python 3: server-side example. No third-party dependencies.
import http.client
import json
import os
from urllib.parse import urlsplit

origin = urlsplit(os.environ["IRANNET_AI_ORIGIN"])
key = os.environ["IRANNET_API_KEY"]
model = os.environ["IRANNET_MODEL_ID"]
if (origin.scheme != "https" or not origin.hostname or origin.username
        or origin.password or origin.path not in ("", "/")
        or origin.query or origin.fragment):
    raise ValueError("Use the official HTTPS origin without /v1")
if not key or not model or any(c in key for c in "\r\n"):
    raise ValueError("Invalid account configuration")

def call(path, payload=None):
    body = json.dumps(payload, ensure_ascii=False).encode("utf-8") if payload is not None else None
    connection = http.client.HTTPSConnection(origin.hostname, origin.port or 443, timeout=60)
    try:
        connection.request("POST" if body is not None else "GET", path, body=body,
            headers={"Authorization": "Bearer " + key, "Content-Type": "application/json"})
        response = connection.getresponse()
        if not 200 <= response.status < 300:
            raise RuntimeError("API returned HTTP " + str(response.status))
        kind = response.getheader("Content-Type", "").split(";", 1)[0].strip().lower()
        if kind != "application/json":
            raise RuntimeError("Unexpected response type")
        raw = response.read(2_000_001)
        if len(raw) > 2_000_000:
            raise RuntimeError("Response exceeds application limit")
        try:
            return json.loads(raw)
        except (ValueError, UnicodeDecodeError):
            raise RuntimeError("Invalid JSON response") from None
    finally:
        connection.close()

# First inspect the permitted models; keep this output private.
models = call("/v1/models")
result = call("/v1/chat/completions", {
    "model": model,
    "messages": [{"role": "user", "content": "یک سلام کوتاه فارسی بنویس."}]
})
print(json.dumps(result, ensure_ascii=False))

برای اجرای نمونه، فایل را در محیط سرور با Python 3 اجرا کنید و سه متغیر لازم را تنظیم کنید. این کد آموزش اتصال و مدیریت اولیه پاسخ است؛ قبل از استفاده در یک سرویس پرترافیک، pooling اتصال، لغو درخواست، محدودیت هم‌زمانی و سیاست لاگ را متناسب با محیط اضافه کنید. Timeout اتصال را نیز با بودجه زمانی کل عملیات اشتباه نگیرید؛ یک کار چندمرحله‌ای باید سقف زمانی کلی داشته باشد.

۵. نمونه Node.js با fetch

در Node.js دارای fetch و AbortSignal.timeout بومی، می‌توان درخواست HTTP را بدون افزودن SDK ارسال کرد. کد زیر فقط برای سمت سرور است. پاسخ ابتدا از نظر وضعیت و نوع بررسی می‌شود و خواندن بدنه نیز محدود است. برای نسخه نصب‌شده Node، وجود این APIها را با مستندات همان نسخه تطبیق دهید. [۲]

// Node.js 20+ with native fetch. Server-side only.
const rawOrigin = process.env.IRANNET_AI_ORIGIN;
const key = process.env.IRANNET_API_KEY;
const model = process.env.IRANNET_MODEL_ID;
if (!rawOrigin || !key || !model || /[\r\n]/.test(key)) {
  throw new Error('Missing or invalid account configuration');
}
const origin = new URL(rawOrigin);
if (origin.protocol !== 'https:' || origin.username || origin.password ||
    origin.pathname !== '/' || origin.search || origin.hash) {
  throw new Error('Use the official HTTPS origin without /v1');
}

async function call(path, body) {
  const response = await fetch(new URL(path, origin), {
    method: body === undefined ? 'GET' : 'POST',
    redirect: 'error',
    headers: { Authorization: `Bearer ${key}`, 'Content-Type': 'application/json' },
    body: body === undefined ? undefined : JSON.stringify(body),
    signal: AbortSignal.timeout(60000)
  });
  if (!response.ok) {
    await response.body?.cancel();
    throw new Error(`API returned HTTP ${response.status}`);
  }
  const kind = response.headers.get('content-type')?.split(';')[0].trim().toLowerCase();
  if (kind !== 'application/json' || !response.body) {
    await response.body?.cancel();
    throw new Error('Unexpected response type');
  }
  const reader = response.body.getReader();
  const chunks = [];
  let bytes = 0;
  try {
    for (;;) {
      const { value, done } = await reader.read();
      if (done) break;
      bytes += value.byteLength;
      if (bytes > 2_000_000) throw new Error('Response exceeds application limit');
      chunks.push(Buffer.from(value));
    }
  } finally {
    await reader.cancel();
    reader.releaseLock();
  }
  try { return JSON.parse(Buffer.concat(chunks).toString('utf8')); }
  catch { throw new Error('Invalid JSON response'); }
}

const models = await call('/v1/models');
const result = await call('/v1/chat/completions', {
  model,
  messages: [{ role: 'user', content: 'یک سلام کوتاه فارسی بنویس.' }]
});
console.log(result); // Manual smoke check only; do not log private conversations.

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

۶. پارامترهای درخواست چه کاری انجام می‌دهند؟

model مدل مورد استفاده را تعیین می‌کند. messages تاریخچه پیام‌هاست؛ نقش و ترتیب پیام‌ها اهمیت دارند. پیام user را با دستور ثابت برنامه یکی نکنید. داده سند، نتیجه ابزار و دستور رفتاری نیز در طراحی برنامه نقش‌های متفاوت دارند؛ ساختار روشن، بررسی و عیب‌یابی را آسان‌تر می‌کند.

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

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

۷. JSON معتبر با داده درست فرق دارد

خروجی ساختاریافته کمک می‌کند پاسخ در قالب قابل پردازش تحویل داده شود. JSON mode بیشتر درباره معتبر بودن نحو JSON است؛ Structured Outputs در مدل و قرارداد پشتیبان، انطباق با Schema را هدف می‌گیرد. با این حال، انطباق قالب به‌تنهایی ثابت نمی‌کند شماره سفارش، قیمت یا دسته‌بندی استخراج‌شده درست است. [۳]

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

{
  "type": "object",
  "properties": {
    "topic": {"type": "string", "enum": ["delivery", "return", "other"]},
    "order_id": {"type": ["string", "null"]},
    "needs_review": {"type": "boolean"}
  },
  "required": ["topic", "order_id", "needs_review"],
  "additionalProperties": false
}

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

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

۸. Tool Calling؛ مدل پیشنهاد می‌دهد، برنامه اجرا می‌کند

در فراخوانی ابزار، مدل نام تابع و آرگومان‌های پیشنهادی را تولید می‌کند؛ کد برنامه آن‌ها را بررسی و اجرا می‌کند؛ سپس نتیجه به گفتگو برمی‌گردد. پاسخ بعدی ممکن است نتیجه نهایی یا فراخوانی دیگری باشد. این چرخه در مستندات سازندگان توضیح داده شده است، اما کنترل مجوز و اثر جانبی بر عهده برنامه مصرف‌کننده است. [۴]

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

۱. معرفی ابزار محدود و Schema آرگومان‌ها
۲. دریافت پیام assistant و tool_calls واقعی
۳. بررسی نام ابزار، ورودی، مجوز و سقف عملیات
۴. اجرای تابع مجاز در سرور
۵. افزودن نتیجه با tool_call_id متناظر
۶. ادامه گفتگو تا پاسخ نهایی یا رسیدن به سقف مراحل

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

ابزار پرداخت، حذف، انتشار یا تغییر دسترسی باید مرحله تأیید و کنترل مستقل داشته باشد. OWASP، اختیارات بیش‌ازحد ابزار و خودمختاری بیش‌ازحد را از ریسک‌های مهم سیستم‌های عامل‌محور می‌داند. [۵] برای هر ابزار، کمترین دسترسی لازم و سقف اجرای مشخص در نظر بگیرید. جمله «کاربر اجازه داده است» در متن تولیدشده توسط مدل، سند مجوز نیست.

۹. RAG؛ وقتی پاسخ باید از اسناد شما بیاید

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

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

مدل Embedding برای پیدا کردن نزدیکی معنایی استفاده می‌شود و مدل پاسخ‌دهنده متن نهایی را می‌سازد. [۶] در ارزیابی، دو سؤال جدا بپرسید: آیا سند درست پیدا شد؟ آیا پاسخ از آن سند پشتیبانی می‌شود؟ اگر پاسخ سؤال اول منفی است، تغییر پرامپت پاسخ‌دهنده مشکل بازیابی را حل نمی‌کند.

این بخش، معماری عمومی RAG را آموزش می‌دهد؛ وجود Embedding در کاتالوگ به‌تنهایی اعلام یک endpoint خاص یا سرویس کامل پایگاه دانش نیست. پیش از پیاده‌سازی، مسیر API و قابلیت مجاز را از مستندات همان محصول تأیید کنید.

۱۰. دستورهای داخل سند را با دستور برنامه اشتباه نگیرید

یک صفحه وب، فایل یا پیام می‌تواند عبارتی داشته باشد که مدل را به تغییر رفتار ترغیب کند. این همان مسئله Prompt Injection است؛ نوع غیرمستقیم آن از داده بیرونی وارد می‌شود. استفاده از RAG به‌تنهایی این خطر را حذف نمی‌کند. [۷]

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

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

۱۱. مدیریت خطا، Timeout و تلاش مجدد

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

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

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

۱۲. usage، قیمت و بودجه سه مفهوم متفاوت‌اند

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

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

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

۱۳. چه چیزهایی را پایش کنیم؟

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

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

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

۱۴. چک‌لیست قبل از اتصال کاربران واقعی

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

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

برای پروژه‌ای که به طراحی پایگاه دانش، اتصال ابزارها یا اجرای گردش‌کار نیاز دارد، خدمات هوش مصنوعی و اتوماسیون ایران‌نت مسیر بررسی نیاز و پیاده‌سازی است. یک شرح مسئله، نمونه داده غیرمحرمانه و معیار پذیرش مشخص، نقطه شروع بهتری از درخواست کلی «یک Agent بسازید» است.

۱۵. پرسش‌های متداول توسعه‌دهندگان