1. Giriş
Bəzən prompt‑mühəndisliyi kurslarında sehrli bir cümlə göstərirlər:
"Faktları uydurma və informasiya yoxdursa, "bilmirəm" de."
Təəssüf ki (və ya xoşbəxtlikdən), ChatGPT App üçün bu, gümüş güllə kimi işləmir. Səbəb sadədir: model yalnız sizin system‑prompt-unuzu deyil, həm də bunları görür:
- alətlərin siyahısı, onların təsvirləri və sxemləri;
- bu alətlərin nəticələri;
- dialoq tarixçəsi, o cümlədən əvvəlki follow‑up-lar.
Əgər bu üç qat — system‑prompt, alətlərin təsvirləri, follow‑up pattern-ləri — bir-birinə ziddirsə və ya “asılı” qalırsa, model klassik “junior” kimi davranmağa başlayır: səy göstərir, amma uydurma etməyə meylli olur.
Kurs daxilində biz “hallüsinasiyalara qarşı üçsəviyyəli müdafiə” (defense in depth) ideyasından istifadə edirik:
- səviyyə 1 — system‑prompt-da qlobal qaydalar;
- səviyyə 2 — hər alətin tərifində lokal məhdudiyyətlər;
- səviyyə 3 — səhvlərin, boş nəticələrin və follow‑up-ların işlənməsi.
Bu dərsdə öyrədici tətbiqimiz GiftGenius üçün hər üç səviyyəni vahid, uzlaşmış bir kontrakta yığacağıq.
Insight
ChatGPT Apps-in yeni memarlığında system-prompt üçün sahə yox oldu — formal olaraq artıq yoxdur. Amma bu, model üçün qlobal təlimatlardan imtina etməli olduğunuz demək deyil. Bir “lifehack” var: ChatGPT üçün alət təsvirləri — klassik system kimi eyni prompt mətnidir. Məhz bunun vasitəsilə tətbiqin “beyin firmware”ini geri qaytarmaq olar.
Xidmət aləti yaradın, məsələn, about və ya about_app. O, tez-tez çağırılmaq üçün nəzərdə tutulmayıb, amma onun description-unu model digər alətlərinki ilə yanaşı oxuyur. Ona görə də təsvirə tam system-prompt-u yerləşdirmək olar. Yaxşısı budur ki, onu alətin qısa texniki təsvirindən sonra verəsiniz. Nəticədə model başlanğıcda sizin system-prompt-u olduğu kimi alır və onu sonrakı dialoqa və alət çağırışlarına tətbiq edir.
Dəstəyi sadələşdirmək üçün system-prompt-un əvvəlinə açıq versiya əlavə etməyi tövsiyə edirəm, məsələn, SYSTEM_PROMPT_VERSION: v3. Bu, modelin niyə fərqli davrandığını tapmağa kömək edir: dərhal görürsünüz ki, o, məhz hansı təlimat dəsti ilə işləyir. Prod-da qəribə davranış yaranarsa, xətanın köhnə prompt versiyasına, yoxsa yenisinə aid olduğunu anlamaq asan olur.
Nümunə:
tool description
### Global assistant behavior for the entire GiftGenius App (ver 3.01)
*(system-level guidelines, not user-facing text)*
system prompt text
2. ChatGPT App-də hansı hallüsinasiyalar olur (hədiyyə kataloqu nümunəsində)
Nə ilə müalicə edəcəyimizi anlamaq üçün xəstəliyin adını qoymaq faydalıdır. Kataloq (hədiyyələr, mallar, tariflər) kontekstində ən çox rast gəlinən hallüsinasiyalar bunlardır.
İlk olaraq, uydurulmuş kataloq mövqeləri. İstifadəçi “müəyyən bir xidmətə illik abunə üçün rəqəmsal sertifikat” və ya kataloqunuzda olmayan çox ekzotik bir hədiyyə istəyir, model isə faydalı olmaq niyyətilə kataloqda heç vaxt olmayan “Super Space Flight 3000 — kosmosa uçuş” kimi şeyləri sevincək uydurur.
İkincisi, uydurulmuş atributlar. Hədiyyə kataloqda var, amma model reallığı “bəzəyir”: qiyməti, hədiyyə növünü (rəqəmsal vs fiziki), istifadəçinin ölkəsinə çatdırılmanın mövcudluğunu və ya sertifikatın etibarlılıq müddətini “belə məntiqlidir” və ya “belə daha yaxşı səslənir” deyə dəyişir.
Üçüncüsü, hallüsinasiyalı hərəkətlər. Model “artıq bu hədiyyəni aldım və kodu e‑mail ünvanınıza göndərdim, kartdan $49 silindi” yazır, halbuki sizin GiftGenius backend heç nə almağa cəhd etməyib və heç bir ACP/Stripe axını işə düşməyib.
Nəhayət, kombinə olunmuş hal var: alət boş siyahı qaytarıb (bu filtr və büdcə üçün hədiyyə yoxdur), amma model istifadəçini məyus etməmək üçün bir-iki “təxmini variant” uydurur və onların kataloqda olmadığını izah etmir.
Bizim vəzifəmiz — bu situasiyalarda modelin:
- kataloqda dəqiq uyğunluq olmadığını dürüst etiraf etməsi;
- yeni hədiyyələr uydurmaması və sahə dəyərlərini dəyişməməsi;
- nə baş verdiyini istifadəçiyə izah etməsi və aydın növbəti addım təklif etməsi.
Və bunu təsadüfi yerlərdə “sehrli sözlər”lə yox, əlaqəli system‑prompt ↔ tools ↔ follow‑ups kontraktı vasitəsilə etmək.
3. Səviyyə 1: system‑prompt-u hallüsinasiyalara qarşı gücləndiririk
Əvvəlki bölmədəki uydurma hədiyyələri, atributları və hərəkətləri dayandırmaq üçün əvvəlcə üst qatı — system‑prompt-u gücləndiririk: model üçün kataloqda ümumi “davranış fəlsəfəsi”ni təyin edirik.
Modulun birinci dərsində siz artıq bazaya system‑prompt yazmışdınız: “Sən — GiftGenius, hədiyyə seçməyə kömək edirsən…” və köməkçinin məsuliyyət sərhədlərini və alətlərlə işi sabitlədiniz.
İndi ora açıq anti‑hallüsinasiyaya dair qaydalar əlavə edək.
Məntiq belədir: system‑prompt ümumi fəlsəfəni təyin edir. O, hər alətin detallarını bilmir, amma bunları edə bilər:
- kataloqdan kənar hədiyyələri / qiymətləri / mövcudluğu uydurmağı qadağan etmək;
- alətlər boş nəticə və ya səhv qaytaranda davranışı yazmaq;
- hədiyyə kataloqu məlumatları ilə modelin “ümumi bilikləri”ni açıq şəkildə fərqləndirməyi tələb etmək.
system‑prompt-un fraqmentinə nümunə (Next.js layihəmizdə TypeScript sabiti, məsələn, config/systemPrompt.ts):
// config/systemPrompt.ts
export const SYSTEM_PROMPT = `
# Rol
Sən — tətbiqimizin hədiyyə kataloqu əsasında
hədiyyə seçməyə kömək edən GiftGenius köməkçisisən.
# Məlumatlar və məhdudiyyətlər
- Kataloqda və ya alət cavablarında olmayan hədiyyələr uydurma.
- Qiymətləri, mövcudluğu, hədiyyə növünü (rəqəmsal/fiziki),
çatdırılma regionlarını və digər atributları uydurma.
- Alət lazımi məlumatları qaytarmayıbsa və ya səhv baş veribsə,
bunu dürüst de və dəyərləri təxmin etməyə çalışma.
# Alətlərlə iş
- Bütün faktiki məlumatlar üçün hədiyyə kataloqu alətlərindən istifadə et:
hədiyyə siyahısı, qiymətlər, növlər, mövcudluq, SKU.
- Alət boş nəticə qaytarırsa, hazırkı şərtlərlə
uyğun hədiyyə olmadığını de və filtrləri yüngülləşdirməyi
(büdcəni, kateqoriyanı, hədiyyə növünü dəyişməyi) təklif et.
`;
Burada bir neçə mühüm məqam var.
Birincisi, biz modelin “ümumi bilikləri” ilə “tətbiq məlumatlarını” ayırırıq. Model hələ də rəqəmsal hədiyyə ilə fiziki hədiyyə arasındakı fərqi və ya adətən hansı münasibətlər olduğunu izah edə bilər, amma konkret hədiyyələr, qiymətlər və SKU yalnız GiftGenius alətlərindən gəlməlidir.
İkincisi, səhv/boş cavab halında nə etmək lazım olduğunu açıq təsvir edirik: susmaq, “yaradıcı olmaq” yox, dürüstcə istifadəçiyə heç nə tapılmadığını deyib parametrləri dəyişməyi təklif etmək.
Üçüncüsü, abstrakt “hallüsina etmə” deyil, domenimizə (hədiyyə kataloqu və rəqəmsal/fiziki SKU-ların alınması) bağlı konkret davranış tiplərinə fokuslanırıq.
Bu qat təkbaşına çox kömək edir, amma onu alətin diqqətsiz təsviri asanlıqla “üstələyə” bilər. Alət təsvirlərinə keçək.
4. Səviyyə 2: alət təsvirləri (tool descriptions) və sxemlər kontraktın formal hissəsi kimi
Model alətin nə zaman və necə çağırılacağını əsasən bunlara görə qərar verir:
- alətin adına;
- alətin description-ına;
- inputSchema / outputSchema-a (sahələri təsvir edən JSON Schema).
Yəni alətin təsviri (tool description) “insanlar üçün sənəd” deyil, eyni dərəcədə formallaşdırılmış prompt hissəsidir. Bir çox hallüsinasiyalar məhz burada yaranır.
Backend tərəfindən GiftGenius kataloqundan hədiyyə seçimi kimi reallaşdırılan recommend_gifts alətimizi təsəvvür edək.
Pis təsvir variantı belə görünə bilər:
// PİS: həddən artıq qeyri-müəyyəndir
const recommendGiftsTool = {
name: "recommend_gifts",
description: "İstifadəçi üçün hədiyyələr seçir",
inputSchema: {
type: "object",
properties: {
profile: { type: "string" }
}
}
};
Formal olaraq hər şey düzgündür, amma model bundan bunları anlamır:
- alətin sərhədləri haradadır;
- hədiyyələr tapılmadıqda nə etmək lazımdır;
- kataloqdan kənar hədiyyələr və qiymətlər uydurmağın qadağan olduğu.
Yaxşı təsvir bir neçə şeyi eyni vaxtda edir: domeni dəqiq müəyyənləşdirir, aləti nə zaman çağırmağı izah edir və nəticələri uydurmağı qəti şəkildə qadağan edir.
Nümunə (GiftGenius kontraktına uyğunlaşdırılıb, segments, budget, locale, occasion ilə):
// config/tools.ts
export const recommendGiftsTool = {
name: "recommend_gifts",
description: `
GiftGenius kataloqu üzrə hədiyyə seçimi.
Bu aləti istifadə et, konkret alıcı profili seqmentləri, büdcə, lokal və
münasibət üzrə real hədiyyələrin siyahısını almaq lazım olduqda.
Alət yalnız GiftGenius kataloqunda həqiqətən olan hədiyyələri qaytarır.
Kataloq nəticələrindən kənar hədiyyələri və onların atributlarını UYDURMA.
Alət boş siyahı qaytarırsa, alternativ uydurma,
əksinə dialoqa keç: büdcəni, hədiyyə növünü,
münasibəti və ya digər parametrləri dəyişməyi təklif et.
`.trim(),
inputSchema: {
type: "object",
properties: {
segments: {
type: "array",
description:
"Alıcının profil seqmentləri, məsələn ['tech', 'fitness'].",
items: { type: "string" }
},
budget: {
type: "object",
description: "Hədiyyə üçün büdcə diapazonu.",
properties: {
min: {
type: "number",
description: "Minimum məbləğ, mənfi ola bilməz.",
minimum: 0
},
max: {
type: "number",
description: "Maksimum məbləğ, 0-dan böyük olmalıdır.",
exclusiveMinimum: 0
},
currency: {
type: "string",
description: "Üçhərfəli valyuta kodu, məsələn 'USD' və ya 'RUB'.",
minLength: 3,
maxLength: 3
}
},
required: ["min", "max", "currency"]
},
locale: {
type: "string",
description:
"İstifadəçinin lokalı (dil/region formatı), məsələn 'ru-RU' və ya 'en-US'.",
minLength: 2
},
occasion: {
type: "string",
description:
"Hədiyyə üçün münasibət: məsələn 'birthday', 'anniversary', 'new_year'."
}
},
required: ["segments", "budget", "locale", "occasion"]
}
};
Burada description bir neçə faydalı işi görür.
O, alətin yalnız GiftGenius hədiyyə kataloqu ilə işlədiyini açıq deyir və konkret hədiyyələr və qiymətlərin yalnız onun nəticəsindən götürülməli olduğunu bildirir.
O, aləti nə zaman istifadə etməyi izah edir: alıcı parametrlərinə görə konkret hədiyyələr siyahısı lazım olduqda, yoxsa hədiyyələr haqqında ümumi nəzəriyyə deyil.
O, boş nəticə zamanı davranışı təyin edir: uydurmamaq, dialoqa keçmək (sonra follow‑up-larda sabitləyəcəyik).
inputSchema isə modelə istifadəçi sorğusundan entitiləri daha etibarlı çıxarmaqda kömək edir: seqmentlər, büdcə, lokal və münasibət. Sahələr üçün açıq struktur və məhdudiyyətlərin (min, max, sabit uzunluqda currency) göstərilməsi də qəribə kombinasiya və parse səhvlərinin ehtimalını azaldır.
Geri tərəfini də əlavə etmək olar — yalnız “nə vaxt çağırmalı” deyil, həm də nə vaxt çağırmamalı. Məsələn, sorğu aydın şəkildə nəzəri xarakterlidirsə:
description: `
...
İstifadəçi konkret şəxsin hədiyyə seçimi üçün deyil,
hədiyyələr barədə ümumi sual verirsə, bu aləti istifadə etmə
(məsələn, "ümumilikdə Yeni il üçün hansı populyar hədiyyələr var").
Belə hallarda çatda özün cavab ver.
`.trim()
Beləcə, alətin təsvirini system‑prompt-dakı “nəzəri” vs “praktik” sorğular qaydaları ilə sinxronlaşdırırsınız.
5. Səviyyə 3: follow‑up-lar UX‑ və təhlükəsizlik qatı kimi
Hətta system‑prompt və alət təsvirləri ideal yazılsa da, həyat ideal deyil:
- backend səhv qaytara bilər;
- kataloq — boş siyahı;
- nəticələr — qeyri‑müəyyən və ya həddən artıq çox ola bilər.
Əgər aləti çağırandan sonra nə demək yazılmayıbsa, model improvizasiya edəcək: bəzən yaxşı, bəzən isə uydurma faktlarla.
2-ci dərsdə artıq əsas UX‑təlimatlarını görmüşdünüz: model App-i necə elan edir, ssenarini necə bitirir və istifadəçiyə “çıxışda” nə deyir. İndi isə hallüsinasiyaları azaldan follow‑up pattern-lərini əlavə edək.
Bu pattern-lər adətən elə system‑prompt-un içində ayrıca blokda təsvir olunur, məsələn “Alətlərlə işdən sonra dialoq”.
Fraqment nümunəsi:
// SYSTEM_PROMPT-un davamı
export const SYSTEM_PROMPT = `
# ... əvvəlki bölmələr ...
# Alətlərlə işdən sonra dialoq
- Hədiyyə seçimi aləti boş siyahı qaytardısa:
1) hazırkı filtrlərlə uyğun hədiyyə tapılmadığını dürüst de;
2) istifadəçiyə 1–2 əsas parametri dəyişməyi təklif et
(büdcə, hədiyyə növü, alıcının maraqları, münasibət).
- Alət həddən artıq çox variant qaytardısa:
1) 3–7 ən uyğununu seç;
2) onları hansı meyarlara görə seçdiyini açıq de
(maraq uyğunluğu, büdcəyə düşməsi, reyting).
- Alətdə texniki səhv baş verdikdə:
1) məlumat uydurma;
2) texniki səhv baş verdiyini de və
sonra yenidən cəhd etməyi və ya sorğunu sadələşdirməyi təklif et.
`.trim();
Beləliklə, modelə nümunəvi follow‑up cümlələri “yazırıq”. O, onları öz sözləri ilə formalaşdıracaq, amma verilmiş struktura uyğun:
- faktın konstatasiya edilməsi (boş / çox / səhv);
- məhdudiyyətin dürüst etirafı;
- səliqəli növbəti addım təklifi.
Hədiyyə kataloqu üçün bu kritikdir: boş nəticə halında model “hər şey qaydasındadır, buyurun üç hədiyyə” deməkdənsə, belə deyəcək:
"Sizin hazırkı şərtlərinizlə (kosmos mövzusunda yalnız ABŞ-a çatdırılan $5‑dək rəqəmsal hədiyyə) kataloqumuzda heç nə yoxdur. İstəsəniz, büdcəni artırım və ya başqa kateqoriyalar təklif edim?"
Və diqqət edin: bu artıq alət kodu deyil, məhz gözlənilən UX-i təyin edən prompt təlimatlarıdır.
6. Hər şeyi birlikdə bağlayaq: GiftGenius-un evolyusiyası
Tətbiqimizin kiçik bir evolyusiyasına baxaq və hallüsinasiyaların səviyyəsini tədricən azaldaq.
İlkin versiya: problemlər harada yaranır
Tutaq ki, çox minimalist system‑prompt-umuz var idi:
export const SYSTEM_PROMPT = `
Sən — hədiyyə seçimi üzrə köməkçisən.
İstifadəçiyə uyğun ideyaları tapmağa kömək et.
`;
Alət belə təsvir olunmuşdu:
export const recommendGiftsTool = {
name: "recommend_gifts",
description: "İstifadəçi üçün hədiyyələr seçir",
inputSchema: { type: "object" }
};
Follow‑up təlimatları yoxdur.
Praktikada nə baş verəcək:
- istifadəçi “gamer olan dosta $10-dək rəqəmsal hədiyyə” istəsə və bazada bu filtrə heç nə düşməsə, model ya:
- ümumiyyətlə aləti çağırmayıb özbaşına hədiyyələr uyduracaq;
- ya da aləti çağırıb boş siyahı alacaq, amma bunu deməyib variantlar uyduracaq;
- backend səhv qaytaranda model “nəsə olmalıdır” deyə düşünüb təxmin etməyə başlaya bilər.
Beləcə klassik vəziyyət yaranır: chat-da gözəl cavab, bazada isə onun tayı-bənzəri yoxdur.
system‑prompt-un yeni versiyası
Üç səviyyəli müdafiəni nəzərə alaraq system‑prompt-u yenidən yazacağıq. Bir hissəsini yuxarıda gördünüz, gəlin onu bütöv yığaq:
// config/systemPrompt.ts
export const SYSTEM_PROMPT = `
# Rol
Sən — tətbiqimizin hədiyyə kataloqu əsasında
hədiyyə seçməyə kömək edən GiftGenius köməkçisisən.
# Məsuliyyət sahəsi
- Sənin vəzifən — istifadəçiyə kataloqdan uyğun hədiyyələri
seçməkdə kömək etmək, variantların üstün və zəif tərəflərini izah etməkdir.
- Faktiki alış və ya hədiyyənin göndərilməsi barədə vədlər vermə —
sən yalnız seçməyə və müqayisə etməyə kömək edirsən.
Alış və kod/link təqdimatı istifadəçinin açıq razılığından sonra backend tərəfindən edilir.
# Məlumatlar və məhdudiyyətlər
- Kataloqda və ya alət cavablarında olmayan hədiyyələri uydurma.
- Qiymətləri, hədiyyə növünü, mövcudluğu və çatdırılma regionlarını uydurma.
- Alət məlumat qaytarmayıbsa və ya səhv baş veribsə,
təxmin etmə, bunu bildir.
# Alətlərlə iş
- Faktiki məlumatlar üçün hədiyyə kataloqu alətlərindən istifadə et
(məsələn, profile_to_segments, recommend_gifts, get_gift):
hədiyyə siyahısı, qiymətlər, növlər, SKU, təsvirlər.
- Sual nəzəri xarakterlidirsə və konkret hədiyyə seçimi tələb etmirsə,
alətsiz özün cavab ver.
# Alətlərlə işdən sonra dialoq
- Boş nəticə olduqda: hazırkı şərtlərlə heç nə tapılmadığını
dürüst izah et və 1–2 parametri dəyişməyi təklif et.
- Variantlar çox olduqda: 3–7 ən uyğunu seç
və seçim meyarlarını izah et.
- Alət səhvi olduqda: məlumat uydurma, nasazlığa görə üzr istə
və yenidən cəhd etməyi və ya sorğunu sadələşdirməyi təklif et.
`.trim();
İndi model dəqiq bilir:
- harada hədiyyə üzrə məsləhətçidir, harada “back‑office” (bizdə alətlərin arxasındadır);
- hansı məlumatların uydurulması qadağandır;
- tipik qeyri‑ideal hallarda necə davranmalıdır.
recommend_gifts üçün yeni description və sxem
Sistem promptunu gücləndirdik, indi aləti də düzəldək və 4-cü bölmədəki ideyalara əsaslanaraq onun təsvirinin yekun versiyasını toplayaq.
// config/tools.ts
export const recommendGiftsTool = {
name: "recommend_gifts",
description: `
GiftGenius kataloqu üzrə hədiyyə seçimi.
Bu aləti istifadə et, lazım olduqda:
- real hədiyyələrin aktual qiymətləri, növü
(digital/physical) və teqləri ilə siyahısını almaq;
- seçimləri maraq seqmentləri, büdcə, lokal və münasibət üzrə daraltmaq.
ALƏTDƏN İSTİFADƏ ETMƏ:
- istifadəçi konkret şəxs üçün seçim istəmədən
hədiyyələr haqqında ümumi nəzəri sual verirsə;
- kataloqda olmayan hədiyyələr uydurmaq üçün.
Nəticə boşdursa, hədiyyələri ÖZÜN UYDURMA,
dialoqa idarəni qaytar (system-prompt təlimatlarına əməl et).
`.trim(),
inputSchema: {
type: "object",
properties: {
segments: {
type: "array",
description:
"Alıcının profil seqmentləri: məsələn, 'tech', 'sport', 'books'.",
items: { type: "string" }
},
budget: {
type: "object",
description:
"İstifadəçinin valyutasında hədiyyə büdcəsi diapazonu (min/max).",
properties: {
min: { type: "number", minimum: 0 },
max: { type: "number", exclusiveMinimum: 0 },
currency: {
type: "string",
minLength: 3,
maxLength: 3,
description: "ISO 4217 valyuta kodu, məsələn 'USD' və ya 'RUB'."
}
},
required: ["min", "max", "currency"]
},
locale: {
type: "string",
description: "İstifadəçinin lokalı, məsələn 'ru-RU' və ya 'en-US'."
},
occasion: {
type: "string",
description:
"Hədiyyə üçün münasibət: 'birthday', 'anniversary', 'new_year' və s."
}
},
required: ["segments", "budget", "locale", "occasion"]
}
};
Burada bir neçə incə məqam var.
Alətin davranışını system‑prompt ilə açıq bağlayırıq: “system‑prompt təlimatlarına əməl et” ifadəsi modelə xatırladacaq ki, “boş nəticə = dürüst söhbət, yoxsa yaradıcılıq yox”.
Mənfi şərtləri (“istifadə etmə…”, “uydurma…”) veririk ki, praktika göstərir — bunlar müsbət təsvirlər qədər vacibdir.
inputSchema-nı semantik cəhətdən zəngin edirik: normal təsvirlər və məhdudiyyətlər modelə hələ aləti çağırmazdan əvvəl sorğunu sahələrlə düzgün uyğunlaşdırmağa kömək edir və “səhv ehtimallarını” azaldır.
Widget kodunda follow‑up pattern-ləri və cavab formatı
Mətn təlimatlarından əlavə başqa bir rıçağımız da var — alətin cavab formatının özü. Onun vasitəsilə də modelə nə baş verdiyini göstərə və “fantaziya” üçün sahəni daralda bilərik.
Formal olaraq follow‑up-lar system‑prompt-da mətnlə verilir, amma Next.js widgetinizdə əlavə olaraq ToolOutput-u normallaşdıra bilərsiniz ki, modelin işi asanlaşsın və fantaziyaya yer azalsın.
Məsələn, backend-i recommend_gifts üçün həmişə belə qaytarmağa razılaşaq:
// backend-də alətin cavab tipi
export type RecommendGiftsResult = {
items: Array<{
id: string;
title: string;
price: number;
currency: "USD" | "EUR" | "RUB";
tags: ("digital" | "physical" | "education" | "fitness" | "tech")[];
}>;
// modelə nə baş verdiyini açıq demək üçün backend tərəfindən doldurulan sahə
status: "ok" | "empty" | "error";
errorMessage?: string;
};
Widget bunu gözəl göstərə bilər, model isə cavabı formalaşdırarkən status-a arxalana bilər. Apps SDK-də çox vaxt alətin ToolOutput-unu modelə JSON obyekt kimi qaytarırsınız və o, bu sahəni görür.
system‑prompt-a kiçik bir blok əlavə etmək olar:
# Alətin statusunun şərhi
- Əgər status = "empty"dirsə: "Alətlərlə işdən sonra dialoq" bölməsinə bax
və hədiyyələr uydurma.
- Əgər status = "error"dırsa: texniki səhv barədə məlumat ver və
kataloqun məzmununu təxmin etməyə çalışma.
Bəli, model bunu onsuz da anlaya bilərdi, amma açıq təlimat ehtimal “təxmin”lərini azaldır.
7. Təcrübə: öz App-inizi təkmilləşdirin
“Bu hamısı slaydlarda gözəldir” hissi olmasın deyə, hazırkı App-inizlə (bizim halda — GiftGenius) edə biləcəyiniz konkret məşqi təsvir edək. Müdafiənin üç səviyyəsi üzrə kiçik refaktor edirik: system‑prompt, alət təsvirləri və nəticələrin işlənməsi.
Birincisi, system‑prompt səviyyəsində birinci dərsdəki system‑prompt-unuzu götürün və orada məsuliyyət sahəsi və alətlərlə işin təsvir olunduğu yeri tapın. Ora əlavə edin:
- kataloq/bazada olmayan entitiləri uydurmağa (hədiyyələr, SKU, qiymətlər) qadağa;
- boş nəticə və alət səhvi üçün qaydalar;
- “Alətlərlə işdən sonra dialoq” bölməsi — 2–3 ssenari ilə (boş, çox, səhv).
İkincisi, alət təsvirləri səviyyəsində əsas alətin (sizde bu recommend_gifts, search_gifts, search_tariffs, calculate_quote və s. ola bilər) təsvirini açın. description-u elə yenidən yazın ki:
- alətin yalnız öz məlumat mənbəyinizlə (hədiyyə kataloqu, tariflər və s.) işlədiyini açıq desin;
- nə zaman lazım olduğunu, nə zaman lazım olmadığını izah etsin;
- açıq mənfi məhdudiyyətlər olsun: “uydurma…”, “bunun üçün istifadə etmə…”.
Üçüncüsü, alətin cavab struktur səviyyəsində, əgər alətin cavabında statusu açıq təsvir edən sahə (status, resultType, hasMore) hələ yoxdursa — backend tipinə və ToolOutput-a əlavə edin. Sonra system‑prompt-da modelin bu statusu dialoqda necə şərh etməli olduğunu yazın.
Sonda Dev Mode-da bir neçə sorğunu işə salın, o cümlədən nəticələri bilərəkdən boş və ya sərhəd halları olanları. Diqqət edin, model uydurma etməyi dayandırdımı və məhdudiyyətlər barədə istifadəçiyə nə qədər dürüst məlumat verir.
Növbəti dərsdə bu cür sorğuları golden prompt set deyilən formal obyektə salıb təkrarlana bilən test artefaktına çevirəcəksiniz, amma hələlik bizim üçün əhəmiyyətlisi — fərqi əllərinizlə hiss etməyinizdir.
8. Promplar və alətlər vasitəsilə hallüsinasiyalara qarşı mübarizədə tipik səhvlər
Səhv №1: system‑prompt-da bir sehrli “hallüsina etmə” cümləsi.
Tərtibatçı promptun sonunda “Məlumat uydurma” yazır — və məsələnin həll edildiyini düşünür. Praktikada model uydurma etməyə davam edir, çünki alət təsvirləri və follow‑uplar alternativ davranışı təyin etmir. “Uydurmaq əvəzinə nə etməli” (boş nəticəni etiraf etmək, filtrləri dəyişməyi təklif etmək, səhv barədə məlumat vermək) kimi konkret qaydalar olmadan belə cümlə demək olar ki, kömək etmir.
Səhv №2: system‑prompt və alətin description-u arasında ziddiyyət.
system‑prompt-da deyirsiniz: “Kataloqda olmayan hədiyyələri uydurma”, alət təsvirində isə — “Uyğun hədiyyələr seçir, əgər tapmasa — öz mülahizəsinə görə oxşar variantlar təklif edə bilər”. Nəticədə model iki həqiqət mənbəyi arasında çaşır və təəssüf ki, adətən daha konkret olan (çox vaxt alət təsviri) “qalib gəlir”. Hər iki qat eyni şeyi deməlidir: əgər oxşar variantlar məqbuldursa, bunu da formallaşdırmaq (və mütləq istifadəçiyə bu barədə — dəqiq uyğunluq olmadığını — izah etmək) lazımdır.
Səhv №3: alət təsvirləri həddən artıq qeyri‑müəyyəndir.
“Tətbiqçinin tapşırıqlarını həll etməyə kömək edən alət” kimi təsvir modelə alətin sərhədləri barədə demək olar ki, heç nə demir. Bu halda model ya ümumiyyətlə alətdən istifadə etməyəcək, ya da hər fürsətdə onu çağıracaq — sonra isə alət az və ya heç nə qaytardıqda “dolduracaq”. Yaxşı description diskriminativ olmalıdır: alətin nə etdiyini və nə vaxt çağırılmamalı olduğunu açıq desin.
Səhv №4: boş və səhv nəticələr üçün strategiyanın olmaması.
Tərtibatçı qayğı ilə backend yazır, o da { items: [], status: "empty" } qaytarır, amma modelə bunun nə demək olduğunu heç yerdə izah etmir. Nəticədə model boş massivi görüb qərara gəlir: “yəqin ki, ümumi biliyimdən nəsə təklif etməliyəm”. system‑prompt-da belə statusların necə şərh olunacağını və istifadəçiyə nə deyiləcəyini izah edən bölmə çatmır. Boş/səhv nəticə üçün bir neçə aydın qaydanın əlavə edilməsi isə keyfiyyəti böyük ölçüdə artırır.
Səhv №5: hallüsinasiyaları yalnız widget kodu səviyyəsində “müalicə etmək” cəhdi.
Bəzən hər şeyi frontend-ə yükləmək istəyirlər: “siyahı boşdursa — plaseholder göstərəcəyəm və modelin mətn cavabını istifadəçiyə göstərməyəcəyəm”. Bu UX-i bir az yumşalda bilər, amma modelin özü uydurma entitilərə inanmağa davam edir və sonrakı replikalarda da elə davranır. Düzgün yanaşma — əvvəlcə təlimatları dəyişməkdir (system‑prompt, alət təsvirləri, follow‑uplar), sonra isə bunu UI-dəki müdafiələrlə tamamlayın.
Səhv №6: metadatların və sxemlərin model davranışına təsirini görməzdən gəlmək.
Bəzi tərtibatçılar JSON Schema və sahə təsvirlərini “yalnız forma və validasiya üçün” hesab edirlər. Əslində isə ChatGPT üçün bu, promptun mühüm hissəsidir: model bu təsvirlərə görə sorğudan hansı parametrləri çıxarmalı olduğunu və düzgün cavabın necə göründüyünü anlayır. Zəif və ya uyğunsuz sahə təsvirləri (description, enum) səhv ehtimalını artırır və dolayı yolla hallüsinasiyaları təhrik edir.
Səhv №7: alternativsiz həddən artıq sərt qadağalar.
Bəzən prompt bütövlüklə “bunu etmə, onu etmə” siyahısına çevrilir, amma çətin hallarda nə etmək lazım olduğu heç yerdə deyilmir. Məsələn, uydurma hədiyyələri qadağan etdik və özümüzü yalnız kataloqla məhdudlaşdırdıq, amma nəzəri suallar barədə heç nə demədik. Nəticədə model bəzən sadəcə “bilmirəm” deyir, halbuki o, hədiyyə seçiminin ümumi prinsiplərini faydalı şəkildə izah edə bilərdi. Həmişə təkcə qadağan etməyə yox, həm də icazə verilən yolları açmağa çalışın: “kataloqda hədiyyə tapa bilmirsənsə — bunu dürüst de və sorğunu necə dəyişmək olar təklif et” və ya “sual nəzəri xarakterlidirsə — alətsiz özün cavab ver”.
GO TO FULL VERSION