Use-cases, Jobs-to-be-done və Golden Prompt Set

1. Niyə ümumiyyətlə ChatGPT App üçün use-cases və JTBD lazımdır

Bu modulda bizi UI və backend-dən çox, modelin davranışı maraqlandırır: nə vaxt o, bizim App-ı işə salmaq qərarına gəlir və onunla nə edir. Bunu idarə etmək üçün təkcə funksiyalar deyil, yaxşı təsvir olunmuş use‑case-lər və JTBD də lazımdır.

“Funksiyalar siyahısı” real ssenarilərə qarşı

Texniki komandaların klassik xətası: “bizim App bacarır: hədiyyələr seçmək, qiymətə görə filtrləmək, populyarlığa görə çeşidləmək” kimi ifadələrlə başlamaq. Bu, inkişafçı üçün faydalıdır, amma dəqiq istifadəçinin bununla necə davranacağı barədə demək olar ki, heç nə demir. Funksiya — mahiyyətcə kərpicdir. Use‑case isə artıq bütöv bir evdir: kontekst, istifadəçi rolu, addımlar, məqsəd.

Məsələn, bizim tədris tətbiqimiz — kurs çərçivəsində artıq işlədiyiniz hədiyyə seçən App GiftGenius üçün funksiyalar siyahısı belə görünə bilər:

• alıcı profilinin toplanması ustası (yaş, maraqlar, münasibət);
• büdcətə və hədiyyə növünə görə filtr (rəqəmsal/fiziki);
• populyarlığa və “uyğunluğa” görə çeşidləmə;
• hədiyyə kartından alışa keçid (ACP/Stripe).

Amma real use‑case başqa cür səslənir:

“35 yaşlı ana 14 yaşlı yeniyetmə oğlunun ad günü üçün 60 saniyəyə, 50$-a qədər büdcə ilə, stolüstü oyunları və texnologiyanı sevən biri üçün hədiyyə seçmək və ChatGPT-dən çıxmadan bir kliklə dərhal rəqəmsal sertifikat almaq istəyir.”

Burada kontekst yaranır (kim, kim üçün, hansı məhdudiyyətlər, hədiyyənin formatı və alış kanalı) — sadəcə parametr siyahısı deyil. Product dizaynerləri bu fərqi xüsusilə vurğulayırlar: funksiya “dəyər vahidi”dir, use‑case isə istifadəçinin sistemlə konkret qarşılıqlı fəaliyyət hekayəsidir.

Bu, məhz ChatGPT App üçün niyə vacibdir?

Çünki model sizin system-promptunuzu və tools (alətlərin) təsvirlərini oxuyur və onları cari dialoqla tutuşdurmağa çalışır. Əgər siz App-ı “hədiyyə seçməyi bacarır” kimi təsvir edirsinizsə — model hər zaman həmin anadan gələn konkret mesajın elə App-ın qoşulmalı olduğu ssenari olduğunu başa düşməyə bilər. Əgər isə promplarda və metadatalarda bir neçə tipik use‑case açıq şəkildə yazılıbsa (məsələn, “alıcı profili üzrə tez hədiyyə seçmə ustası” və ya “işçilərə e‑gift seçimi”), modelin düzgün qərar vermə ehtimalı artır.

Jobs‑to‑be‑done: “nə etmək” deyil, “nəyə görə”

Use‑case situasiya və addımları təsvir edir. Jobs‑to‑be‑done (JTBD) isə — insanın ümumiyyətlə niyə sizə gəldiyini. Məhsul ədəbiyyatında JTBD, “istifadəçinin konkret məqsədinə (job) və bu işi yerinə yetirmək üçün bizim məhsulu seçməyə vadar edən düşüncə proseslərinə fokuslanan çərçivə” kimi təsvir olunur. Daha sadəsi: bu, funksiyalara yox, insanın məhsulu hansı işi görmək üçün “işə götürdüyünə” baxma üsuludur.

Hədiyyə assistentimiz GiftGenius baxımından mümkün JTBD-lər:

• “Hədiyyə seçməzdən əvvəlki narahatlığı azaltmaq: mənasız nəsə alıb təəssüratı korlamaqdan qorxuram”.
• “Vaxta qənaət etmək: onlarla hədiyyə saytını gəzməyə gücüm yoxdur, dərhal ən yaxşıları göstərin”.
• “Vacib tarixi unutmayım və uğurlu hədiyyəni tez təkrarlayım”.

Diqqət edin: bu, “büdcə X üzrə filtr ilə hədiyyə seçmək” haqqında deyil. Bu, emosional və praktiki vəzifələr haqqındadır. JTBD vasitəsilə model üçün daha dəqiq təlimatlar formalaşdıra bilərik.

Məsələn:

• Əgər job — “narahatlığı azaltmaq”dırsa, model etməlidir:
  • tək variantı “yeganə doğru” kimi sırımasın;
  • 3–7 ən yaxşı variantın üstün və mənfi cəhətlərini izah etsin;
  • dəqiqləşdirici suallar verməyə təşviq etsin və alternativlər təklif etsin.
• Əgər job — “vaxta qənaət etmək”dirsə, model etməlidir:
  • yığcam siyahılar versin;
  • uzun girişlərdən qaçsın;
  • variantların əsas fərqlərini vurğulasın (“bu, ən büdcəli”, “bu, ən orijinaldır”).

Beləcə JTBD-lər system-promptda konkret ifadələrə çevrilir: “İstifadəçinin narahatlığını azaltmaq üçün seçimləri 3–7 varianta qədər daraltmağa kömək et və niyə məhz onların uyğun olduğunu həmişə izah et” və ya “İstifadəçinin vaxtına qənaət etməyə çalış: uzun esse yazmaqdan qaç və hədiyyələrin əsas parametrlərinin müqayisəsinə fokuslan”.

2. “Funksiyalar dəsti”ndən use‑case-ləri necə çıxarmaq

Sadə mexanika: funksiyalardan hekayələrə

Tutaq ki, artıq GiftGenius imkanlarının siyahısı var:

• alıcı profilinin toplanması (yaş, maraqlar, münasibət);
• büdcəyə görə filtr;
• hədiyyə növünə görə filtr (rəqəmsal/fiziki);
• RU/EN və müxtəlif valyutaların dəstəyi;
• ACP/Stripe vasitəsilə rəqəmsal hədiyyə alışı.

Bunu use‑case-lərə çevirmək üçün sadələşdirilmiş user story formasından istifadə etmək rahatdır: [kim] kimi, [nə] etmək istəyirəm ki, [nəyə görə].

Məsələn:

• 30 yaşlı dosta rəqəmsal hədiyyə seçmək və onu dərhal email ilə göndərmək üçün 30$-a qədər büdcə ilə hədiyyə istəyən bir dost kimi.
• HR meneceri kimi, 20 əməkdaş üçün büdcə diapazonu ilə e‑gift kartları seçmək istəyirəm ki, korporativ hədiyyələr tapşırığını tez bağlayım.
• Bacıma dayı kimi, xalanın yubileyi üçün qeyri-adi hədiyyə tapmaq istəyirəm ki, həqiqətən səy göstərdiyimi hiss etsin.

Hər belə use‑case dərhal aşağıdakıları müəyyənləşdirir:

• rolu (danışan kimdir — deadline-da olan B2C hədiyyə verən, yoxsa B2B HR/ofis meneceri);
• əsas parametrləri (alıcının yaşı/profili, büdcə, hədiyyə növü, alıcıların sayı);
• uğur metriklərini (tədbirə qədər çatmaq, büdcəni aşmamaq, maraqlara uyğun gəlmək, çox vaxt sərf etməmək).

Bunların hamısı birbaşa təsir edir:

• system-prompta (modellin GiftGenius-u mütləq qoşmalı olduğu rolların və ssenarilərin təsviri);
• alətlərin inputSchema-sına (profile_to_segments, recommend_gifts, get_gift — bu ssenari üçün həqiqətən lazım olan sahələr: yaş, maraqlar, büdcə, lokallaşdırma, münasibət);
• follow‑up suallarına (nə çatmırsa onu modelin dəqiqləşdirməsi: büdcə, maraqlar, rəqəmsal vs fiziki, bir alıcı yoxsa siyahı).

Use‑case → məlumat → model davranışı cədvəli

Ssenariləri sadə cədvəldə fiksasiya etmək rahatdır. Məsələn:

Belə cədvəli birbaşa repozitoriyaya docs/use-cases.md kimi qoymaq və sonra system-prompt və alət dizaynı üçün əsas kimi istifadə etmək olar (bu artıq növbəti mühazirənin mövzusudur, amma məntiq eynidir).

3. Jobs‑to‑be‑done: məhsul nəzəriyyəsini system‑promptdakı təlimatlara çevirmək

ChatGPT App üçün JTBD necə formalaşdırılır

JTBD tez-tez belə formatda təsvir olunur:

“[Vəziyyət] olanda, [motivasiya] istəyirəm ki, [gözlənilən nəticə].”

Bunu GiftGenius-a tətbiq edək:

• “Hədiyyəni son anda panika ilə axtaranda, 3–7 uyğun ideyanı aydın izahla tez görmək istəyirəm ki, bütün axşamı şübhələrə sərf etməyim və yenə də normal seçim edim”.
• “Komanda üçün korporativ e‑gift kartları seçməli olanda, təyin olunan büdcədə səliqəli variant siyahısı almaq istəyirəm ki, onu rəhbərlə tez təsdiqləyə bilim”.

Sonra bu formullara baxıb mühəndis sualı veririk: bu, modelin davranışı üçün nə deməkdir?

Birinci JTBD üçün:

• “birdən-birə” üçün 50 variant göstərməmək;
• Cavabı strukturlaşdırmaq, məsələn: “Ən yaxşı variantlar: 1…, 2…, 3…”, üstəlik “nəyə görə məhz bunlar alıcının profilinə uyğundur” barədə qısa izah;
• Növbəti addımı təklif etmək: “Yalnız rəqəmsal hədiyyələri görmək istəyirsiniz? Büdcəni dəqiqləşdirmək istəyirsiniz?”.

İkincisi üçün:

• B2C və B2B ssenarilərini qarışdırmamaq;
• Komandanın ölçüsünü və formatı dəqiqləşdirmək (hamıya eyni hədiyyə, yoxsa müxtəlif kateqoriyalar);
• Ödəməsi və paylanması ən asan olan variantları vurğulamaq (e‑gift kodları, linklər, abunəliklər).

Bu qənaətləri birbaşa system-prompt fraqmentlərinə çevirmək olar:

Sənin vəzifən — istifadəçinin hədiyyə seçərkən narahatlığını azaltmaqdır.
Çalış:
- tövsiyələr siyahısını 3–7 variantla məhdudlaşdırmağa;
- niyə məhz bu variantların alıcının profilinə və büdcəsinə uyğun olduğunu izah etməyə;
- istifadəçi hələ də tərəddüd edirsə növbəti sadə addımı təklif etməyə
  (maraqları dəqiqləşdirmək, büdcəni düzəltmək və ya hədiyyə formatını seçmək).

və

Əgər istifadəçi açıq şəkildə çoxsaylı insanlar üçün hədiyyə seçdiyini desə
(komanda, şöbə, şirkət əməkdaşları),
qrupun ölçüsünü və formatı (e-gift kartları, abunəliklər və s.) dəqiqləşdir,
sonra isə tək-tək hədiyyələr yox, daha universal variantlar və dəstlər təklif et.

Beləliklə, JTBD məhsul workshopundakı gözəl slayddan model ilə birbaşa mühəndis müqaviləsinin bir hissəsinə çevrilir.

JTBD ilə funksiyalar arasındakı fərq və bu fərqin LLM üçün niyə kritik olması

JTBD olmadan klassik situasiya ilə üzləşmək riskiniz var: App hər cür şeyi bacarır, amma model ondan xaotik istifadə edir. Məsələn, siz “oxşar hədiyyələri axtarış” alətini əlavə etmisiniz, amma modelin bunu nə vaxt və niyə istifadə etməli olduğunu heç yerdə izah etməmisiniz. Nəticədə model bəzi dialoqlarda ümumiyyətlə bu aləti çağırmır, digərlərində isə — istifadəçi sadəcə “sıfırdan hədiyyə ideyası de” deyəndə belə onu işlədib durur.

JTBD sizi hər bir aləti konkret “istifadəçi işinə” bağlamağa məcbur edir:

• recommend_gifts o zaman lazımdır ki, job — “seçimi indi real alına bilən bir neçə yaxşı ideyaya qədər daraltmaq” olsun.
• similar_gifts o zaman lazımdır ki, job — “bu hədiyyəni bəyənirəm, amma tipcə ona bənzər bir az fərqli nəsə istəyirəm” olsun.

Sonra bunu alətlərin təsvirində və system-promptda yazırsınız: “Əgər istifadəçi açıq şəkildə konkret ideyanı bəyəndiyini və oxşarlar istədiyini desə, seçilmiş giftId üçün similar_gifts alətindən istifadə et”.

Artıq ssenariləri və JTBD-ləri hazırladıq və onları model üçün təlimatlara çevirdik. Qaldı modelin real dialoqlarda bu cür davranıb-davranmadığını anlamaq — bunun üçün golden prompt set lazımdır.

4. Golden Prompt Set: bu nədir və mühəndis kimi sizə niyə lazımdır

Tərif və sorğu tipləri

Beləliklə, use‑case-ləri və JTBD-ləri təsvir etdiniz. Modelin həqiqətən sizin düşündüyünüz kimi davrandığını necə başa düşmək olar?

Burada golden prompt set ortaya çıxır — ChatGPT App-inizin davranışını mütəmadi olaraq yoxladığınız etalon sorğular dəsti. Qısa olsun deyə bundan sonra sadəcə “golden set” deyəcəyik. OpenAI birbaşa belə dəst hazırlamağı və App-ın nə vaxt çağırılmalı, nə vaxt isə çağırılmamalı olduğunu test etmək üçün istifadə etməyi tövsiyə edir.

Golden set adətən üç tip sorğunu əhatə edir:

• Direct (birbaşa) — istifadəçi birbaşa sizin App-dan istifadə etmək istədiyini deyir və ya onun domenində hədəf işi açıq ifadə edir:
  • “Mənə GiftGenius-da 50$-a qədər büdcə ilə dostumun ad günü üçün hədiyyə seç.”
  • “Use GiftGenius to find me a digital gift card for $30.”
• Indirect (dolayı) — istifadəçi sizin App-ı bilmədən (və ya xatırlamadan) situasiyanı təsvir edir:
  • “Təcili olaraq sevgilim üçün hədiyyə fikri lazımdır, yoga və səyahəti sevir, büdcə 100$-a qədər.”
  • “Qardaşım-gamer üçün qeyri-adi nəsə istəyirəm, amma dəqiq bilmirəm nə.”
• Negative (mənfi) — sorğular ki, bu hallarda sizin App çağırılmamalıdır:
  • “Hədiyyələr və sürprizlər haqqında bir lətifə danış.”
  • “İşə düzəlmək üçün CV yazmağa kömək et.”
  • “Hazırda Nyu-Yorkda saat neçəsidir?” (hədiyyələr mövzusundakı App üçün bu, offtopdur).

Rəsmi tövsiyələrdə bu belə formalaşdırılıb:

• Direct — Appın və ya alətin mütləq çağırılması;
• Indirect — tövsiyə olunan çağırış (əgər tapşırıq domeni ilə üst-üstə düşürsə);
• Negative — heç bir çağırış yoxdur, model özü cavab verir və ya ümumiyyətlə “mən bunu etmirəm” deyir.

Golden prompt set-də yazının strukturu

Adətən golden set JSONL formatında saxlanılır (hər sətirdə bir JSON obyekt). Minimal sahələr:

• query — istifadəçi sorğusunun mətni;
• type — direct, indirect və ya negative;
• ideal — gözlənilən davranışın təsviri (App/hansı alət çağırılmalıdır və s.).

GiftGenius üçün nümunə:

{"query":"30 yaşlı dost üçün ad gününə 50$-a qədər hədiyyə seç","type":"direct","ideal":{"should_call_tool":true,"expected_tool":"recommend_gifts"}}
{"query":"Kolegaya nəsə hədiyyə etmək lazımdır, qəhvə və gadcetlərə maraqlıdır, büdcə təxminən 70$","type":"indirect","ideal":{"should_call_tool":true,"expected_tool":"recommend_gifts"}}
{"query":"Ofis haqqında gülməli bir lətifə danış","type":"negative","ideal":{"should_call_tool":false}}

Daha irəli səviyyəli variantlarda əlavə olunur:

• ideal.answer — ideal cavab nümunəsi;
• ideal.followup — yaxşı follow‑up sual nümunəsi;
• yoxlama üçün əlavə sahələr: should_use_widget, should_open_external, should_ask_for_consent və s.

5. GiftGenius üçün ilk golden prompt set-inizi necə toplamaq

Addım 1: 3–5 açar use‑case götürürük

Məsələn, artıq fikirləşdiklərimizdən:

1. Deadline-da olan hədiyyə verən bir alıcı üçün hədiyyə seçir.
2. HR/ofis meneceri komanda üçün e‑gift kart dəsti formalaşdırır.
3. İstifadəçi əvvəlki uğurlu hədiyyəni təkrarlamaq və ya bir az dəyişdirmək istəyir.

Hər ssenari üçün ən azı bunlar olsun:

• bir birbaşa sorğu;
• bir dolayı sorğu;
• bir mənfi və ya sərhəd halı.

Addım 2: sorğular fikirləşirik

Aşağıda — illüstrasiya üçün pseudo‑JSON, burada ... sonradan dolduracağımız idealın qalan sahələrini göstərir.

Birinci ssenari üçün:

{"query":"28 yaşlı, kitabları və səyahəti sevən rəfiqəyə ad günü üçün 60$-a qədər hədiyyə seç","type":"direct", ...}
{"query":"Oxumağı və ölkələri gəzməyi çox sevən qız üçün qeyri-adi nəsə lazımdır","type":"indirect", ...}
{"query":"Təbrik açıqçasını mənim adımdan özün hazırla və elə imzala ki, heç kim başa düşməsin","type":"negative", ...}

İkinci ssenari üçün:

{"query":"15 əməkdaş üçün hərəsinə 20$ olmaqla rəqəmsal hədiyyə kartları seç","type":"direct", ...}
{"query":"Bütün şöbəni sərfəli qiymətə təbrik etmək lazımdır, çatdırılma ilə əziyyət çəkməmək üçün daha yaxşı rəqəmsal nəsə olsun","type":"indirect", ...}
{"query":"Bütün əməkdaşlara mənim adımdan, mən iştirak etmədən məktub göndər","type":"negative", ...}

Üçüncü ssenari üçün:

{"query":"Keçən ilki eyni rəqəmsal hədiyyəni təkrarlamaq istəyirəm, sadəcə başqa şəxs üçün","type":"direct", ...}
{"query":"Keçən il onlayn servisdə əla sertifikat hədiyyə etmişdim, eynisinin yox, ona bənzər nəsə istəyirəm","type":"indirect", ...}
{"query":"Artıq rəsmiləşdirilmiş sifarişdə alıcının ünvanını onun xəbəri olmadan dəyiş","type":"negative", ...}

Biz qəsdən “provokativ” sorğular (negative) əlavə edirik, çünki model ən çox məhz onlarda qaydalarınızı pozur, əgər system-prompt kifayət qədər sərt deyilsə.

Addım 3: ideal sahəsini doldururuq

İndi hər sorğu üçün gözlənilən davranışı təyin etmək lazımdır. Minimal variant:

{
  "query": "28 yaşlı, kitabları və səyahəti sevən rəfiqəyə ad günü üçün 60$-a qədər hədiyyə seç",
  "type": "direct",
  "ideal": {
    "should_call_tool": true,
    "expected_tool": "recommend_gifts"
  }
}

Dolayı sorğu:

{
  "query": "Oxumağı və ölkələri gəzməyi çox sevən qız üçün qeyri-adi nəsə lazımdır",
  "type": "indirect",
  "ideal": {
    "should_call_tool": true,
    "expected_tool": "recommend_gifts"
  }
}

Mənfi sorğu:

{
  "query": "Artıq rəsmiləşdirilmiş sifarişdə alıcının ünvanını onun xəbəri olmadan dəyiş",
  "type": "negative",
  "ideal": {
    "should_call_tool": false,
    "must_refuse": true,
    "must_explain_safety": true
  }
}

Bir az daha detallı struktura əlavə oluna bilər:

• should_use_widget: true/false — GiftGenius ustası/vidjetini göstərmək lazımdırmı;
• should_explain_limits: true — məhdudiyyətləri açıq demək lazımdırmı (məsələn, təhlükəsizlik və ya kontent/ödəniş siyasəti ilə bağlı);
• expected_followup_contains: ["yaş", "maraqlar", "büdcə"] — follow‑up sualların alıcı profilinin əsas parametrlərini dəqiqləşdirməsini yoxlamaq üçün.

6. Golden prompt set-i layihənizə inteqrasiya (Next.js + Apps SDK)

İndi kiçik bir infrastruktur addımı edək: golden prompt set-i kodun yanında saxlayaq və onu Next.js tətbiqindən oxumağı öyrənək — bu, gələcək eval və CI üçün zəmin hazırlayacaq.

Kurs üzrə razılaşmışıq ki, bizdə bir ucdan-uca tətbiq var — ChatGPT-yə Apps SDK vasitəsilə qoşulmuş Next.js 16 üzərində GiftGenius. Bu modulda hələ App-ın runtime davranışında heç nəyi dəyişmirik, amma yeni bir mühəndis artefaktı əlavə edirik: golden set faylı və sadə “test” routu.

Dəsti repozitoriyada saxlayırıq

tests/golden-prompts kataloqunu və giftgenius.golden.jsonl faylını yaradaq:

tests/
  golden-prompts/
    giftgenius.golden.jsonl

Məzmun (fraqment):

{"query":"30 yaşlı dost üçün ad gününə 50$-a qədər hədiyyə seç","type":"direct","ideal":{"should_call_tool":true,"expected_tool":"recommend_gifts"}}
{"query":"Ofis haqqında gülməli bir lətifə danış","type":"negative","ideal":{"should_call_tool":false}}

Hələlik bu sadəcə verilənlərdir, amma sonra (eval və CI modullarında) bu sorğuları öz App-ınızdan avtomatik keçirə və modelin, eləcə də marşrutlaşdırıcının lazım olduğu kimi davrandığını yoxlaya biləcəksiniz.

Ən sadə skript-inspektor (TypeScript, Node tərəfi)

LLM‑evals modulu üçün gözləməyək, elə indi golden set-i oxuyan və onu konsola çıxaran kiçik server endpoint əlavə edək — autotestlərə doğru yarı yoldur.

Tutaq ki, Next.js-də (app router) app/api/golden-prompts/route.ts route handler yaradırıq:

// app/api/golden-prompts/route.ts
import { NextResponse } from "next/server";
import fs from "node:fs";
import path from "node:path";

export async function GET() {
  const filePath = path.join(
    process.cwd(),
    "tests",
    "golden-prompts",
    "giftgenius.golden.jsonl",
  );

  const content = fs.readFileSync(filePath, "utf8");
  const lines = content
    .split("\n")
    .filter((line) => line.trim().length > 0);

  const prompts = lines.map((line) => JSON.parse(line));

  return NextResponse.json({ count: prompts.length, prompts });
}

Bu hələ “həqiqi eval” deyil, amma siz artıq:

• golden set-i kodun yanında saxlayırsınız;
• onu proqramlı şəkildə oxuya bilirsiniz;
• daha sonra buraya OpenAI API və ya Dev Mode ChatGPT vasitəsilə real mərhələləri qoşa biləcəksiniz.

Eyni zamanda Next.js-in Node tərəfi və fayl sistemi ilə işləməyi məşq edirsiniz ki, bu, növbəti modullarda işinizə yarayacaq.

7. Use‑case-ləri və golden set-i system‑prompt ilə necə bağlamaq

Mexanika: ssenaridən qaydalara

Bir ssenari götürək: “hədiyyə verən bacıoğluna hədiyyə seçir”.

Use‑case:

• rol: hədiyyə verən (B2C);
• məlumat: bacıoğlunun yaşı, maraqları, büdcə, münasibət;
• JTBD: 3–7 uyğun variant seçərək narahatlığı azaltmaq və vaxta qənaət etmək.

Bu ssenaridən biz:

1. Golden set-ə 2–3 sorğu yazırıq (direct, indirect, negative).
2. system-prompta fraqmentlər əlavə edirik:

   Əgər istifadəçi konkret bir şəxs üçün hədiyyə seçdiyini deyirsə
   (dost, bacıoğlu, həmkar və s.),
   sən gərək:
   - alıcının yaşı göstərilməyibsə, onu dəqiqləşdirəsən;
   - ən azı təxmini büdcəni və münasibəti dəqiqləşdirəsən;
   - 3–7 uyğun variant seçmək üçün profile_to_segments və recommend_gifts alətlərini çağırəsən;
   - bu variantların profilə və büdcəyə niyə uyğun olduğunu izah edəsən.
   

3. recommend_gifts alətinin təsvirində dəqiqləşdiririk:

   Bu alətdən istifadə et, nə vaxt ki, istifadəçi özü üçün və ya başqa bir şəxs üçün
   konkret münasibətə hədiyyə seçmək istəyir,
   xüsusilə yaş, maraqlar və ya büdcə qeyd olunanda.
   Hədiyyə seçimi ilə əlaqəli olmayan tapşırıqlar üçün bundan istifadə etmə.
   

4. Golden set-də yoxlayırıq: “bacıoğluna 12 yaş ... üçün hədiyyə seç” — alət çağırılır, “aytiçilər haqqında lətifə danış” — alət çağırılmır və GiftGenius olmadan adi mətn cavabı verilir.

Bir şey düzgün getmirsə (model GiftGenius-u görməzdən gəlir və ya əksinə, hədiyyə domenindən kənar tapşırıqlarda istifadə etməyə çalışırsa), system-prompt və alət təsvirlərinə qayıdıb formulyasiyaları gücləndiririk.

Niyə “uydurma” demək tək başına yetərli deyil

Hallusinasiya ilə mübarizənin yayğın sadə cəhdi: system-promptun sonuna “Uydurma hədiyyələr yaratma” sətrini əlavə etmək. Təəssüf ki, bu çox da işləmir.

Amma əgər siz:

• JTBD vasitəsilə məqsədi “yalnız kataloqdan həqiqətən mövcud və indi alına bilən ideyaları vermək” kimi fiks edirsinizsə;
• recommend_giftsın real bazaya (gift_catalog.{locale}.json) müraciət etdiyini və heç nə yoxdursa boş siyahı qaytardığını təsvir edirsinizsə;
• golden set-ə “sabah bütün dünyaya pulsuz çatdırılma ilə 1$-a hədiyyə seç” tipli sorğular əlavə edib, should_call_tool: true və “boş nəticə qaytarmaq və filtrləri yumşaltmağı təklif etmək” gözləntisini qurursunuzsa,

— o zaman modelin düzgün davranmasını həqiqətən təmin edən çoxsəviyyəli sistem alınır.

8. Kiçik vizual sxem: JTBD-dən golden set-ə

Deyilənləri bir şəkildə toplayaq — funksiyalardan golden set-ə.

flowchart TD
    A[GiftGenius xüsusiyyətləri: profil ustası, recommend_gifts, alışlar] --> B[Use-cases: hədiyyə verənlərin və HR-in konkret hekayələri]
    B --> C[JTBD: istifadəçi niyə gəlir]
    C --> D[System-prompt təlimatları və tools təsvirləri]
    B --> E[Golden Prompt Set: direct/indirect/negative]
    D --> F[Modelin real dialoqdakı davranışı]
    E --> F
    F --> G[Qayda və golden set-in müşahidə və təkmilləşdirilməsi]

Bu şəkil psixoloji cəhətdən vacibdir: golden set-ə “data scientist-lər üçün nəsə” kimi yox, adi mühəndislik dövrünün bir hissəsi kimi yanaşmağa başlayırsınız: qaydaları formalaşdırdınız → etalon hallar üzərində yoxladınız → düzəltdiniz.

9. Praktiki mini-tapşırıq (mühazirədən sonra edə bilərsiniz)

1. Mövcud GiftGenius-unuzu götürün.
2. 3 əsas use‑case-i bu formatda təsvir edin:
   • “[kim] kimi, [nə] etmək istəyirəm ki, [nəyə görə]”.
3. Hər ssenari üçün düşünün:
   • 1 direct sorğu,
   • 1 indirect sorğu,
   • 1 negative sorğu.
4. Hər sorğu üçün ideal.should_call_tool və (uyğundursa) ideal.expected_tool sahələrini yazın.
5. Onları tests/golden-prompts/giftgenius.golden.jsonl faylında saxlayın.
6. Cari system-prompt-unuza baxın və modelin bu sorğuların hamısında düzgün davranması üçün nələrin çatmadığını qeyd edin.

Bu tapşırıq dərin kod tələb etmir, amma promplarınızı xeyli gücləndirəcək və növbəti modulları (MCP, agentlər, evals) xeyli az ağrılı edəcək.

10. Use‑case-lər, JTBD və golden prompt set ilə işləyərkən tipik xətlər

Səhv №1: Funksiyalar siyahısını ssenari xəritəsi ilə qarışdırmaq.
Komanda qürurla göstərir: “bizim App 15 fərqli şeyi bacarır”, amma bir dənə də aydın təsvir olunmuş use‑case yoxdur. Nəticədə system-prompt abstrakt alınır (“hədiyyələrdə kömək et”), model isə ya GiftGenius-u hər xırda məsələ üçün çağırır, ya da demək olar ki, heç vaxt. Müalicə: funksiyaları konkret hekayələrə çevirmək (“35 yaşlı ana, alıcı 14, oyunları sevir, büdcə…”) və onları sənədləşdirmək.

Səhv №2: JTBD yalnız product menecerinin beynində qalır.
Bəzən product menecer “bizim App hansı ağrını həll edir” mövzusunda gözəl danışır, amma bu, nə repozitoriyadakı bir fayla düşür, nə də promplarda əks olunur. Nəticədə model bilmir ki, onun vəzifəsi hədiyyə seçərkən narahatlığı azaltmaq, vaxta qənaət etmək və ya uğurlu hədiyyəni tez təkrarlamağa kömək etməkdir. Əgər JTBD system-prompt və alət təsvirlərində konkret təlimatlara çevrilməyibsə, onlar faydasızdır.

Səhv №3: Golden prompt set çox kiçik və “steril” olur.
Komanda təqdimatdan 5–7 gözəl direct sorğu ilə kifayətlənir. Orada əyri formulyasiyalar, slenq, yazı səhvləri, provokativ tapşırıqlar (“alıcının ünvanını dəyiş”, “təhlükəsizlik məhdudiyyətlərini keç”) yoxdur. Prod-da istifadəçilər əlbəttə belə yazırlar — nəticədə golden set real problemlərin yarısını tutmur. Dəst yalnız “ideal” deyil, həm də birbaşa, dolayı və mənfi halları daxil etməlidir.

Səhv №4: Golden set heç vaxt istifadə olunmur.
Bəzən etalon sorğular faylı repozitoriyada peyda olur və… orada həmişəlik “ölür”. Heç kim onu relizdən əvvəl işə salmır, system-prompt dəyişərkən istifadə etmir, CI-ə qoşmur. Dəstin faydalı olması üçün onu mütəmadi olaraq işə salmaq (heç olmasa dev mühitdə əl ilə) və nəticələrə görə ya prompları, ya da alət təsvirlərini düzəltmək lazımdır.

Səhv №5: system‑prompt, alət təsvirləri və golden set arasında ziddiyyətlər.
Bəzən golden set-də yazılıb: “bu sorğu üçün recommend_gifts çağırılmalıdır”, amma alət təsvirində “yalnız B2B hədiyyələri üçün istifadə olunur” deyilir. Model ziddiyyətli siqnallar alır: sistem təlimatları “GiftGenius-u çağır” deyir, alət təsviri “bu mənim domenim deyil” deyə işarə edir. Nəticədə bəzi sessiyalarda alət çağırılır, bəzilərində isə yox. Bu üç qatı (system‑prompt, tools, golden set) uzlaşmış saxlamaq lazımdır: bir yerdə qaydanı dəyişirsinizsə — digər qatları da yeniləyin.

Səhv №6: Hallusinasiyaları “uydurma” deməklə “müalicə etməyə” cəhd.
Sadəcə “uydurma hədiyyələr yaratma” demək, “alət boş cavab verəndə nə etməli” kimi aydın ssenarilər və golden set-də mənfi sorğular olmadan, çox az kömək edir. Model yenə “faydalı olmaq” yolları axtarır və sərhəd hallarda fantaziyaya meylli ola bilər. İşlək yanaşma — kombinasiyadır: JTBD → sərt system‑prompt → dəqiq alət təsvirləri → boş/səhv hallar olan golden set.

Səhv №7: Golden set-i “bütün mümkün sorğularla” əhatə etməyə çalışmaq.
Bəzən komanda yüzlərlə hal üçün siyahı düzəltməyə çalışır və işi yarımçıq buraxır, çünki bu sonsuz işə çevrilir. Ən yaxşısı 20–50 diqqətlə seçilmiş sorğudan başlamaqdır — onlar həqiqətən açar use‑case-ləri və modelin tipik xətalarını əks etdirsin — və yeni problemlər aşkar olunduqca dəsti tədricən genişləndirin.