GPT aləti çağırmağa necə qərar verir: tool-call modeli və təsvirlərin rolu

1. Niyə ümumiyyətlə tool-call-u anlamaq lazımdır

Sadələşdirsək, adi veb tətbiq “istifadəçi düyməni sıxdı — biz funksiyanı çağırdıq” sxemi ilə işləyir. ChatGPT Apps dünyasında isə mənzərə fərqlidir: istifadəçi nəsə deyir, model fikir yürüdür və lazım bildikdə alət çağırışı (tool-call) üçün strukturlaşdırılmış nəticə formalaşdırır.

Yəni, siz yazmırsınız:

onClick={() => callSuggestGiftsApi(formData)}

əvəzində isə:

1. suggest_gifts alətini təsvir edirsiniz (ad, təsvir, arqument sxemi).
2. Modelə system-prompt-da bu alətin nəyə görə faydalı olduğunu izah edirsiniz.
3. İdarəni modelə verirsiniz: onu nə vaxt və necə çağıracağını özü qərar verir.

Buradan iki şeyi erkən anlamaq vacibdir:

1. GPT sizin backend kodunuzu görmür. O yalnız alətin “başlığını” görür: ad, təsvir və parametr sxemi.
2. Modelin tətbiqinizi nə dərəcədə “ağıllı” istifadə edəcəyi, demək olar ki, birbaşa təsvirləri necə yazdığınızdan asılıdır. Yaxşı təsvirlər — alət üçün sizin “prompt”unuzdur.

Bu günkü mühazirə məhz istifadəçi ilə serveriniz arasında olan bu “beyin” haqqındadır.

2. tool-call üçün zehni model: nə baş verir

Gəlin mənzərəni bütöv götürək. GiftGenius üçün tipik ssenari:

1. İstifadəçi: “30 yaşlı dost üçün hədiyyə seç, büdcə 100 dollar, videooyunları sevir”.
2. GPT bu mesajı oxuyur və hansı alətlərin mövcud olduğuna baxır. Məsələn, bizim App-də suggest_gifts var.
3. GPT qərar verir: “Yaxşı cavab vermək üçün bu aləti çağırmalıyam”.
4. Adi mətn cavabı əvəzinə alətin adı + JSON arqumentləri olan struktur yaradır.
5. ChatGPT müştərisi bunu görür: “Aha, bu tool-call”, və onu sizin MCP/serverinizə göndərir.
6. Serveriniz biznes məntiqini icra edir və structured output qaytarır.
7. GPT nəticəni alır, oxuyur və alətin cavabına əsasən istifadəçiyə anlaşılan cavab formalaşdırır və/və ya vidceti yeniləyir.

OpenAI API baxımından bu, eyni LLM-function-calling mexanizmidir: modelin cavabında adi mətn əvəzinə alətin name-i və arguments-u olan obyekt görünür, finish_reason isə tool_calls kimi işarələnir. Model özü kod işlətdirmir — o, yalnız hansı alətin çağırılmalı olduğunu təklif edir, real çağırışı isə müştəri (ChatGPT/Apps SDK) edir.

Təxminən belə görünür (sadələşdirilmiş ardıcıllıq):

sequenceDiagram
    participant U as İstifadəçi
    participant G as GPT (model)
    participant C as ChatGPT müştərisi
    participant S as Sizin MCP/Backend

    U->>G: "Dosta hədiyyə seç..."
    G->>C: tool-call: { name: "suggest_gifts", args: {...} }
    C->>S: HTTP /mcp tools/call (suggest_gifts, args)
    S-->>C: Nəticə (hədiyyələrin siyahısı olan JSON)
    C-->>G: tool result
    G-->>U: Cavab + yenilənmiş vidcet

Əsas nəticə: siz if (userAskedAboutGifts) callSuggestGifts() yazmırsınız. Siz alət və onun təsvirini yaradırsınız, qərarı isə model verir.

3. Model nə görür: System Prompt + alətlərin siyahısı

GPT-nin nə edəcəyinə necə qərar verdiyini anlamaq üçün, seçimin edildiyi anda onun hansı məlumatlara malik olduğunu bilmək lazımdır.

Sadə şəkildə model görür:

• App-inizin system‑prompt-unu (5-ci modulda bunu detallı araşdıracağıq);
• dialoq tarixini: istifadəçi mesajlarını, öz cavablarını, əvvəlki tool-call nəticələrini;
• mövcud alətlərin siyahısını (tools) — adlar, təsvirlər və parametr sxemləri ilə;
• əlavə anotasiyalarını (readOnly/destructive və s.).

O görmür:

• funksiyaların reallaşdırılmasını;
• SQL sorğularını;
• cədvəllərinizin strukturunu;
• servisi olan private repozitoriyanın məzmununu.

MCP haqqındakı detalları bir az sonra danışacağıq. Hələlik bilmək kifayətdir ki, MCP səviyyəsində alətlər deskriptor kimi elan olunur: hər birində name, description və inputSchema (JSON Schema) var. Handshake zamanı ChatGPT MCP-serverdən alətlərin siyahısını soruşur və onları mövcud “fəaliyyətlər” kimi qəbul etməyə başlayır.

GiftGenius üçün belə bir deskriptorun nümunəsi (sadələşdirilmiş JSON):

{
  "name": "suggest_gifts",
  "description": "Yaşa, maraqlara və büdcəyə görə hədiyyə ideyalarını seçir",
  "inputSchema": {
    "type": "object",
    "properties": {
      "age": { "type": "integer" },
      "budget": { "type": "number" }
    },
    "required": ["age", "budget"]
  }
}

Model burada yalnız mətni və strukturu “oxuyur”: age nədir, budget nədir, alət ümumilikdə nə edir. Növbəti mühazirə inputSchema-nı düzgün təsvir etməyə həsr olunacaq. İndi isə bu təsvirin necə “gəlin suggest_gifts-i çağıraq” qərarına çevrildiyinə baxaq.

4. API baxımından tool-call necə görünür

ChatGPT, MCP-serverinizin alətlərini (tools) OpenAI Agent-in backend funksiyalarını çağırmasına bənzər şəkildə çağırır. ChatGPT Apps SDK-da bu bir qədər bükülmüşdür, amma baza mexanikası eynidir.

Təsəvvür edək ki, backend-də OpenAI API-yə adi sorğu edirik və modelin cavabında çağıra biləcəyi suggest_gifts alətini ötürürük:

const response = await openai.responses.create({
  model: 'gpt-5-mini',
  messages: [
    {
      role: 'user',
      content: '30 yaşlı dost üçün hədiyyə lazımdır, büdcə 100 dollar'
    }
  ],
  tools: [ // burada LLM-in "çağıracağı" funksiyaların siyahısını ötürürük
    {
      name: 'suggest_gifts',
      description: 'Yaşa, büdcəyə və maraqlara görə hədiyyələri seçir',
      parameters: {
        type: 'object',
        properties: {
          age: { type: 'integer' },
          budget: { type: 'number' }
        },
        required: ['age', 'budget']
      }
    }
  ]
});

Model aləti çağırmağa qərar verərsə, cavabda mətn deyil, təxminən belə bir assistant mesajı alacaqsınız:

{
  "role": "assistant",
  "tool_calls": [
    {
      "id": "call_1",
      "name": "suggest_gifts",
      "arguments": "{\"age\":30,\"budget\":100}"
    }
  ],
  "content": []
}

Beləliklə, LLM backendinizə bildirir ki, suggest_gifts(30,100) funksiyasını çağırmaq lazımdır.

Burada üç şey vacibdir:

1. Alətin adı (name) — model buraya ilk sorğuda tools təsvirində göstərdiyiniz sətri həqiqətən də qoyur.
2. Arqumentlər (arguments) — parameters/inputSchema əsasından yığılmış JSON sətiridir.
3. Adi mətn cavabının olmaması (hələlik) — onun əvəzinə alət çağırışı üçün struktur alırsınız.

ChatGPT tətbiqində də tam olaraq eyni şey baş verir: model “suggest_gifts-i bu parametrlərlə çağırmaq istəyir” deyə qaytarır, müştəri (ChatGPT) isə MCP/serverinizə alətin adı və arqumentlərlə tools/call HTTP sorğusu edir.

5. Model necə qərar verir: alət yoxsa mətn

İndi ən maraqlısı: GPT alətlərinizi ümumiyyətlə nə vaxt yada salır?

Mexanika sadələşdirilmiş şəkildə belədir:

1. Model növbəti istifadəçi mesajını və mövcud konteksti görür.
2. Daxildə “assistant”ın növbəti mesajını generasiya edən qat var, amma model həmişə mətn vermək əvəzinə tamamlamanın bir variantını seçə bilər:
   • adi mətn cavabı (finish_reason: "stop");
   • bir və ya bir neçə tool-call (finish_reason: "tool_calls");
   • bəzən digər variantlar (məsələn, “istifadəçidən daha bir mesaj lazımdır”).
3. Bu seçiminə təsir edənlər:
   • istifadəçi sorğusunun alətlərinizdə təsvir olunan tapşırıqlara nə qədər oxşaması;
   • alətin təsvirində “məhz belə hallarda məni istifadə et” mesajının nə qədər aydın olması;
   • Apps SDK konfiqurasiyasında verilən app system prompt məlumatları.

Sadə dillə desək, model alətinizi cari sorğuya “ölçüb-biçir”. Təsvir “Yaşa və maraqlara görə hədiyyə seçir”dirsə, istifadəçi “dövlət büdcəsinin analizi” istəyirsə, model onu çağırmağa belə cəhd etməyəcək. Təsvir çox bulanıqdırsa — “süper şeylər edir” — model, ümumiyyətlə, nə vaxt istifadə olunmalı olduğunu anlamayacaq.

Maraqlı nüans: aləti təsvir etmiş olsanız belə, model onu çağırmağa borclu deyil. GPT belə qərar verə bilər: “Burada hər şey aydındır, alətsiz özüm cavab verərəm”. Ona görə də kursun davamında fəal məşq edəcəyik ki, model üçün alətin istifadəsini maksimum aydın və sərfəli edən təsvirlər yaza bilək.

6. Alətin adı: nə üçün tool1 pis fikirdir

Alətin adı, modelin çağırışlarında istifadə edəcəyi identifikatordur. Guya sırf texniki sahədir, amma praktikada ad modelin davranışına ciddi təsir edir.

Aləti tool1 adlandırsanız, model bundan heç nə anlamaz. Onun üçün bu, sadəcə simvollar dəstidir. suggest_gifts, search_products və ya fetch_user_orders kimi adlar isə özlüyündə alətin nədən bəhs etdiyini güclü siqnal kimi bildirir.

Özünüzü tanımadığınız kodu oxuyarkən düşünün. calculateCartTotal funksiyasını görən kimi ondan nə gözləmək lazım olduğunu təxmin edirsiniz. Modelə də belə “semantik lövbər” lazımdır.

GiftGenius üçün məntiqli alət adları belə ola bilər:

suggest_gifts
search_products
get_product_details
create_order

Yaxşı ad əgər:

• qısa, amma məzmunludursa;
• vahid üslubdadır (snake_case, latın qrafikası, fel_isim);
• bir konkret hərəkəti əks etdirirsə.

Pis fikir — bir alətdə müxtəlif hərəkətləri qarışdırmaq, məsələn do_all_gift_stuff. Model üçün onu nə vaxt istifadə etməyi anlamaq çətinləşir, növbəti mühazirələrdə bunun arqument sxemini necə pozduğunu və sazlamanı necə çətinləşdirdiyini görəcəyik.

7. Alətin təsviri: model üçün sizin prompt

Ad başlıqdırsa, description mini‑sənəddir, amma proqramçı üçün yox, məhz GPT üçün. Proqramçı kodu oxuyacaq; model — yox. O, aləti nə vaxt çağırmalı və hansı arqumentləri doldurmalı olduğunu seçərkən təsvir mətninə güvənir.

Vacibdir ki, təsviri “istifadə təlimatı” üslubunda yazasınız:

• aləti nə vaxt istifadə etmək;
• onun hansı məhdudiyyətləri var;
• nələri etməməlidir.

suggest_gifts üçün üç təsvir variantına baxaq.

Çox geniş:

"Hədiyyələr seçir."

Model kim üçün, nə münasibətlə, hansı parametrlərlə olduğuna aydınlıq gətirə bilməyəcək. Bu alət modelin hədiyyələr haqqındakı ümumi biliyi ilə “rəqabətə” girə bilər və çox vaxt model sadəcə mətnlə cavab verməyi seçəcək.

Çox dar:

"Yalnız kiçik qardaş üçün ad gününə hədiyyə seçir."

Burada aləti demək olar ki, hər zaman istifadə etməyi qadağan etdik. Başqa istənilən ssenari — ana, həmkar, ildönümü — artıq “uyğun deyil”, model isə çağırışdan qaçacaq.

Optimal:

"Bu aləti insan üçün hədiyyə seçmək lazım olanda istifadə et: yaş, münasibət tipi (dost, partnyor, həmkar və s.), büdcə və maraqlar üzrə.
Hədiyyələrlə bağlı olmayan suallar üçün (məsələn, siyasət və ya hava) onu çağırma."

Burada alətin nə etdiyini, bunun üçün hansı parametrlərin olduğunu və nə vaxt çağırılmalı olduğunu aydın qeyd etmişik, həmçinin mənfi şərt əlavə etmişik — hansı sorğular üçün ona toxunmamaq lazımdır.

Model belə aydın çərçivələri “sevir”. İstifadəçi formulyarlarının (intentlərin) hansılarında alətin yerində olduğunu nə qədər aydın göstərsəniz, App-in davranışı bir o qədər proqnozlaşdırıla bilən olacaq.

Kiçik tapşırıq

Elə indi, monitordan ayrılmadan, gələcək App-inizdən (bəlkə də hədiyyələr haqqında deyil) bir alət seçin və onun üçün üç təsvir fikirləşin: çox geniş, çox dar və balanslı. Sonra isə GPT-nin bu versiyalarla necə davrandığını test edin.

8. Arqument sxemi: qərara necə kömək edir

JSON Schema-nı növbəti mühazirədə detallı danışacağıq, amma tool-call-ları anlamaq üçün ən azı yüksək səviyyəli təsəvvür lazımdır.

Model aləti çağırmağa qərar verəndə ona gərəkdir ki:

1. Bu alətin hansı arqumentləri gözlədiyini anlasın.
2. Bu dəyərləri istifadəçi mətnindən (və ya kontekstdən) çıxarsın.
3. Bu arqumentlərlə JSON formalaşdırsın.

Bu məqsədlə alətin təsvirində parametr sxemi (inputSchema) var, o modelə bildirir:

• hansı sahələr var (age, budget, relationship_type, interests və s.);
• hansı sahələr məcburidir (required);
• hansı tiplər ola bilər (integer, number, string, massivlər və s.);
• bəzən — hansı dəyərlərin məqbuldur (enum) və sahələrə izahlar (description).

suggest_gifts üçün ən sadə TypeScript interfeysi belə görünə bilər:

interface SuggestGiftsParams {
  age: number;
  relationship_type: 'friend' | 'partner' | 'colleague';
  budget: number;
  interests?: string[];
}

Model səviyyəsində bu JSON Schema-ya çevrilir və model artıq hər sahənin adı və təsvirinə görə belə nəticə çıxarır ki:

• age “30 yaş”, “yeniyetmə üçün” kimi ifadələrdən götürülməlidir;
• budget “büdcə 100 dollar”, “50 avroya qədər” kimi ifadələrdən;
• relationship_type “dost”, “həmkar” kimi sözlərdən;
• interests — “videooyunları sevir” kimi ifadələrdən.

Əgər sxemi izahsız və abstrakt sahə adları ilə versəniz (a, b, c), model arqumentləri doldurarkən daha çox səhv edəcək. Lokalizasiya və UX ipucları barədə modulda buna qayıdacağıq. Buradakı əsas fikir sadədir: sxem təkcə backend-də yoxlama deyil, hər şeydən öncə modelə nəyi hara qoyacağını bildirən ipucudur.

Sxemin modelə arqumentləri düzgün yığmağa necə kömək etdiyini danışdıq. Amma “nəyi və necə çağırmaq”dan əlavə “bunu indi çağırmaq olar və nə dərəcədə təhlükəsizdir” sualı da var. Burada icazələr və alətlər haqda meta‑məlumat işə düşür.

9. İcazələr və kontekst: hər alət həmişə əlçatan deyil

Ad, təsvir və arqument sxemindən başqa, alətlərin təhlükəsizlik və çıxış imkanı ölçüsü də var. Real App-də alətlər “təhlükəlilik” səviyyəsinə görə fərqlənir. Publik kataloqda hədiyyə axtarmaq bir şeydir, istifadəçinin kartından vəsait silmək başqa.

Apps SDK və MCP bunu alət təsvirlərində və anotasiya olaraq əks etdirməyə imkan verir — məsələn, onları read-only və ya destructive kimi işarələmək.

İdeya belədir:

• Yalnız publik məlumatları oxuyan alətlər (search_products, get_weather) əlavə təsdiqlərsiz çağırıla bilər.
• Nəyisə dəyişən alətlər (create_order, cancel_order, charge_user) “destructive” kimi işarələnir. ChatGPT UI istifadəçidən əlavə təsdiq istəyə bilər (“Sifarişi rəsmiləşdirmək istədiyinizə əminsiniz?”), modelin özü də aydın sorğu olmadan onları təklif etməyə daha az meyilli olacaq.

Gələcək modullarda MCP-ni qurarkən, bu anotasiyaların (_meta, destructiveHint, readOnlyHint) real JSON deskriptorlarda necə göründüyünü, UX-ə və ChatGPT-nin çağırışdan əvvəl “Are you sure?” dialoqlarını necə formalaşdırdığına necə təsir etdiyini görəcəksiniz. İndi yalnız bunu başa düşmək kifayətdir:

• GPT təkcə təsvir mətnini yox, təhlükəsizliklə bağlı meta-məlumatı da nəzərə alır.
• Kimlik doğrulaması tələb edən alət, istifadəçi daxil olmayana qədər (və ya App lazımi tokeni almayana qədər) istifadə olunmayacaq.

Bu, “aləti işə salaq, ya yox” qərarına təsir edən daha bir faktordur: məna etibarilə alət uyğun olsa belə, icazələrə görə əlçatan olmaya bilər və model başqa yol seçəcək.

10. Alətlər ChatGPT-də haradan yaranır

Mimari nöqteyi-nəzərdən alət modelə iki əsas yolla çata bilər.

Birincisi, ChatGPT App konfiqurasiyasından. App-i qeydiyyatdan keçirəndə, ona hansı MCP-serverlərin (və onların alətlərinin) bağlandığını, yaxud tətbiqin özündə hansı daxili alətlərin olduğunu göstərirsiniz. Sessiya başlayanda ChatGPT bu konfiqurasiyanı alır və hansı alətlərin ümumiyyətlə əlçatan olduğunu anlayır.

İkincisi, birbaşa MCP-dən. MCP (Model Context Protocol) müştərinin (bizim halda ChatGPT/Apps SDK) serverinizin nəyə qadir olduğunu öyrənməsi üçün standart yolu müəyyənləşdirir: o, tools/list sorğusu edir, alətlərin təsvirləri olan JSON alır və onları capabilities kimi saxlayır. Detalları ayrıca MCP modulunda danışacağıq, indi ümumi ideyanı başa düşmək kifayətdir.

Sxematik:

flowchart LR
  A[ChatGPT Client] -->|handshake| B[MCP Server]
  B -->|tools/list| A
  A -->|siyahını ötürür| G[GPT Model]

Bundan sonra alətlərin siyahısı model üçün kontekstin bir hissəsinə çevrilir. Serverdə sxemi və ya alətin təsvirini dəyişsəniz və App-i yenidən başlatsanız, yeni deskriptor növbəti handshake zamanı ChatGPT-yə çatacaq və model çağırış barədə qərarları yeni qaydada verməyə başlayacaq.

Və vacib praktiki fikir: yalnız backend-i (alətin reallaşdırılmasını) düzəltdikdə, model bundan xəbərsizdir. Amma name/description/schema-nı dəyişəndə, siz həqiqətən App-in “beynini” dəyişirsiniz. Bəzən description-da bir sətiri düzəltmək, 200 sətir heuristika yazmaqdan daha faydalıdır.

11. GiftGenius-ə tətbiq edək: modelin çağırmaq istəyəcəyi aləti yaradaq

Gəlin indi hər şeyi tədris tətbiqimiz GiftGenius ilə bağlayaq. Tutaq ki, artıq alətləri qeydiyyatdan keçirdiyimiz MCP-server və ya backend qatımız var. Gəlin server.registerTool(...) ilə suggest_gifts alətini qeydiyyatdan keçirək.

TypeScript-də primitiv eskiz (hələ real məntiqsiz):

// pseudo-mcp-server/tools/suggestGifts.ts
server.registerTool(
  'suggest_gifts', // alətin adı
  {
    title: 'Hədiyyələrin seçimi',
    description:
      'Bu aləti yaşa, ' +
      'münasibət tipinə və büdcəyə görə hədiyyə ideyaları seçmək üçün istifadə et. Hədiyyələrlə bağlı olmayan suallar üçün çağırma.',
    inputSchema: { // alətin parametrlərinin təsviri
      type: 'object',
      properties: {
        age: { type: 'integer', description: 'Qəbul edənin yaşı (illə)' },
        relationship_type: {
          type: 'string',
          description: 'Münasibət tipi: friend, partner, colleague'
        },
        budget: {
          type: 'number',
          description: 'Hədiyyə üçün maksimal büdcə (istifadəçinin valyutasında)'
        }
      },
      required: ['age', 'budget']
    }
  },
  async ({ age, relationship_type, budget }) => { // funksiyanın/alətin kodu
    // Həqiqi məntiq sonra olacaq
    return { suggestions: [] };
  }
);

Hələ “stub” olsa da, bu mərhələdə düşündüyümüz detallara diqqət edin:

• Ad: suggest_gifts, tool1 deyil.
• Təsvir: alətin nə vaxt çağırılmalı, nə vaxt çağırılmamalı olduğunu açıq şəkildə izah edir.
• Sahə izahları: modelə istifadəçi mətnini arqumentlərə düzgün xəritələməyə kömək edir.

Nəticədə, istifadəçi “Həmkar üçün 50 dollara hədiyyə seç” yazanda, model görəcək ki:

• suggest_gifts adlı alət və hədiyyə seçimi haqqında təsviri var;
• onda age, relationship_type, budget sahələri mövcuddur;
• budget — “hədiyyə üçün maksimal büdcə”, relationship_type — “münasibət tipi: friend, partner, colleague”.

İstifadəçilər qeyri-dəqiq ifadə etsələr belə (“50-yə qədər”, “layihə yoldaşı üçün”), modelin arqument JSON-unun toplanmasına səy göstərə bilməsi üçün kifayət qədər kontekst olacaq.

Alətimiz həqiqətən işləməyə başlayanda (backend və MCP haqqında modulda), siz artıq mövzunu yaxşı mənimsəmiş olacaqsınız: GPT onu proqnozlaşdırıla bilən şəkildə çağıracaq, çünki interfeysi və təsviri yaxşı layihələndirmişik.

12. Kiçik praktika

Mövzu yalnız nəzəri qalmasın deyə, mühazirədən dərhal sonra kiçik bir eksperiment etməyi məsləhət görürəm.

Əvvəlcə GiftGenius ssenarilərinizdən birini götürün və ya yeni App fikirləşin. Modelə açıq şəkildə vermək istədiyiniz bir funksiyanı yazın — məsələn, search_products, find_hotels, calculate_shipping.

Sonra həmin alət üçün üç “ad + təsvir” cütü fikirləşin:

1. Çox abstrakt ad və təsvir.
2. Həddindən artıq konkret (demək olar ki, special-case).
3. Yaxşı balanslaşdırılmış ad + təsvir: alətin nə vaxt çağırılacağı və nə etməməli olduğu aydın yazılıb.

Daha sonra — istəyə bağlı — adi OpenAI SDK-dan istifadə edərək bu variantlarla sadə sorğu edə və modelin davranışının necə dəyişdiyinə baxa bilərsiniz: alət çağırılırmı, arqumentləri necə doldurur. Bu mövzu üzrə araşdırmada məhz suggest_gifts üçün belə bir tapşırıq göstərilir.

13. tool-call və təsvirləri layihələndirərkən tipik səhvlər

Səhv №1: Alətləri tool1, handler, doStuff kimi adlandırmaq.
Belə adlandırma model üçün tamamilə faydasızdır. GPT “proqramçının niyyətini” fayl adından təxmin etmir; ona semantik olaraq anlaşılan ad lazımdır. Əgər siz təsvirlərsiz tool1, tool2, tool3 dəsti versəniz, alət demək olar ki, çağırılmayacaq: model hər birinin nə etdiyini anlamayacaq və ya onları görməzlikdən gələcək, ya da təsadüfi seçəcək.

Səhv №2: description sahəsinə insanlar üçün şərh kimi yanaşmaq.
Bir çoxları təsvirə “Hədiyyə seçimi funksiyası” kimi formal bir cümlə yazır, “detallar onsuz da koddan bəllidir” düşünür. Amma model kodu görmür, yalnız təsvir mətnini və arqument sxemini görür. Qeyri‑dəqiq təsvir halüsinasiyalara çevrilir: GPT ya alət lazım olanda belə özü cavab verməyə çalışır, ya da aləti qəribə situasiyalarda çağırır.

Səhv №3: Təsviri çox geniş və ya çox dar yazmaq.
“Gözəl şeylər edir” yazsanız, model tətbiq sahəsini anlamır. “Yalnız kiçik qardaş üçün 18 yaşa hədiyyə seçir” yazsanız, aləti demək olar ki, hər zaman qadağan edirsiniz. Optimal təsvir tapşırıq sahəsini (bir sıra parametrlərə görə hədiyyə seçimi) aydın müəyyənləşdirir, açar parametrləri (yaş, münasibətlər, büdcə, maraqlar) sadalayır və hansı sual siniflərində alətdən istifadə etməmək lazım olduğunu bildirir.

Səhv №4: Arqument sxemini “prompt”ın bir hissəsi kimi görməmək.
Bəzi proqramçılar JSON Schema-nı yalnız serverdə doğrulama vasitəsi kimi qəbul edir. Əslində model, istifadəçi mətnindən hansı məlumatı çıxarmalı olduğunu anlamaq üçün sahə adlarını, tipləri və izahları aktiv təhlil edir. x adlı izahsız və opsional sahə qoysanız, GPT onu xaotik dolduracaq və ya ümumiyyətlə doldurmayacaq. Aydın adlar və qısa izahlarla düzgün sxem tool-call səhvlərini ciddi azaldır.

Səhv №5: Modelin aləti “mütləq” çağıracağını gözləmək.
Bəzən belə sual yaranır: “Niyə GPT alətimi çağırmadı, axı o var?” Cavab demək olar ki, həmişə eynidir: təsvir və ya system‑prompt-dan məhz bu sual üçün alətin lazım olduğu nəticəsi çıxmır və ya sorğu elə zonaya düşüb ki, modelə alətsiz cavab vermək daha rahat görünür.

Səhv №6: Bir alətdə bir neçə fərqli hərəkəti qarışdırmaq.
Bəzən universal manage_orders etmək istəyirik: həm sifarişləri axtarsın, həm yenisini yaratsın, həm də köhnəni ləğv etsin. İnsan üçün bəlkə izah etmək olar, amma model üçün bu, sərhədləri qeyri‑müəyyən alətə çevrilir. GPT onu nə vaxt çağıracağını daha pis anlayır, arqumentləri doldurmaq da çətinləşir — çünki içəridə bir yığın opsional sahə yaranır. Belə əməliyyatları bir neçə dar alətə (get_order, create_order, cancel_order) bölmək, aydın təsvir və sxemlərlə təqdim etmək daha yaxşıdır.

Səhv №7: Tool dizaynında icazələr və təhlükəsizliyi nəzərə almamaq.
Əgər dağıdıcı əməl (vəsait silmək, məlumatları silmək) edə bilən aləti destructive kimi işarələməsəniz və təsvirində istifadəni məhdudlaşdırmasanız, risk yaradırsınız. ChatGPT UI artıq təsdiq istəməyəcək, model isə “sərhəd” ssenarilərində belə aləti çağırmağa cəhd edə bilər. Düzgün anotasiyalar və diqqətli təsvir (“yalnız istifadəçinin açıq razılığından sonra istifadə et”) belə riskləri elə tool‑call səviyyəsində azaltmağa kömək edir.