Özünü təkmilləşdirən App: təkmilləşdirmələrin qapalı dövrü

1. Niyə App‑ə təkmilləşdirmələrin qapalı dövrü lazımdır

Hər bir LLM‑App dəyişən dünyada yaşayır. Sizdə yeni istifadəçilər və ssenarilər peyda olur, OpenAI yeni modellər və qoruma mexanizmləri buraxır, siz özünüz MCP‑serveri, Agents SDK, UI‑vidceti yeniləyirsiniz… Və kod ideal yazılsaydı belə (bəli‑bəli, bilirəm ki, siz demək olar belə edirsiniz), bir modelin və ya promptun dəyişməsi hiss olunmadan işlərin yarısını poza bilər.

Dövr olmadan həyat belə görünür. İstifadəçi dəstəyə yazır: «GiftGenius büdcədən baha hədiyyələr təklif etməyə başlayıb» və ya «15 saniyə fikirləşir». Siz loqları açır, system‑prompt‑da nəyisə düzəldir, modeli dəyişir, dərc edirsiniz. Bir həftə sonra hər şey təkrarlanır, amma başqa yerdə. Nəticədə — xroniki «yanğın» və heç kimin izah edə bilmədiyi bir yığın «sehrli» dəyişikliklər.

Dövr olduqda hər şey fərqlidir. Sizdə bunlar var:

• texnika, pul, məhsul və keyfiyyət üzrə aydın siqnallar dəsti;
• müntəzəm ritual: onlara baxmaq və hipotezlər seçmək;
• code/config‑də nəzarətli dəyişikliklər;
• avtomatik yoxlamalar: golden‑case‑lər + LLM‑evals + eksperimentlər.

Belədə App «donmuş prompt»dan canlı sistemə çevrilir və o:

• haranın «ağrıdığını» və niyə belə olduğunu göstərir;
• nəyi konkret yaxşılaşdırmaq olar, məsləhət verir;
• promptda «zərərsiz» dəyişiklikdən sonra sakit deqradasiyadan qoruyur.

Üstəlik bonus: belə dövr əvvəlki modullarda etdiklərinizin üzərinə çox yaxşı oturur. M17‑dən loqlar və SLO texniki siqnallar verir, M19‑dan cost‑instrumentasiya və AARRR — iqtisadi və produkt siqnallarını, M20.1–2‑dən golden‑case‑lər və LLM‑evals — keyfiyyət siqnallarını. Qalır bunları anlaşılan əməliyyat dövründə birləşdirmək.

2. Təkmilləşdirmələr üçün siqnallar xəritəsi

App‑ın hara yaxşılaşdırılmalı olduğunu özü göstərə bilməsi üçün ümumiyyətlə hansı siqnalların sizdə olduğunu və onların haradan gəldiyini dəqiq anlamaq lazımdır. Dörd qrupda düşünmək rahatdır.

Texniki siqnallar observability‑stack‑ınızdan gəlir: tool_invocation loqları, latency və error‑rate metrikləri, MCP/ACP health‑check‑ləri, OAuth xətaları. Onlar «servis yaşayırmı və nə dərəcədə stabildir» sualına cavab verir.

İqtisadi siqnallar cost‑instrumentasiyada və billingdə yaranır: cost_per_tool_call, cost_per_task, cost_per_user, konkret alətlər və ya ssenarilər üzrə xərclərdə gözlənilməz sıçrayışlar. Onlar deyir: «gözlənildiyindən daha çox token və pul yandırırıq» və ya əksinə, «ehtiyat var, keyfiyyəti artıra bilərik».

Produkt siqnalları app_opened, workflow_started, workflow_completed, checkout_* kimi hadisələrdən formalaşır. Bunlar activation‑rate, huni addımları arasındakı konversiyalar, kohortalar üzrə retention‑dur. Onlar real istifadəçi davranışında nə baş verdiyini göstərir.

Keyfiyyət və davranış siqnalları golden‑case‑lər üzrə LLM‑eval nəticələrini (correctness/helpfulness/style/safety balları), seçmə əl ilə dialoq rəyini, thumbs up/down, Store‑dakı şikayət və rəyləri əhatə edir. Bu, «App daha ağıllı/axmaq oldu» hissinə ən yaxın olanıdır.

Bunu cədvəldə toplamaq rahatdır:

Açar məqam: bu siqnalların hamısı konkret ssenariyə və App versiyasına bağlanmış halda loqlanır. Yəni hadisələrdə ən azı scenario, appVersion və experimentId iştirak edir. Belədə, golden‑case‑lər üzrə helpfulness 8.5‑dən 6.2‑yə düşəndə, sadəcə «pisləşdi» yox, «"gift_selection" ssenarisində, "1.3.0" buraxılışından sonra, eksperimentin "B" variantında pisləşdi» deyə bilərsiniz.

Kodda siqnalı təsvir etmək üçün sadə struktur da yarada bilərsiniz:

// lib/improvement/signals.ts
export type SignalKind = "slo" | "cost" | "product" | "quality";

export type ImprovementSignal = {
  kind: SignalKind;
  scenario: string;       // e.g. "gift_selection"
  metric: string;         // e.g. "p95_latency_ms", "cost_per_task"
  value: number;
  previous?: number;      // əvvəlki dəyər
};

Belə obyektləri həm dəsbordlara, həm də gələcək təkmilləşdirmə assistentinizə vermək rahatdır.

3. Kanonik feedback‑dövrü: 4 addım

İndi hər dəfə arxalana biləcəyiniz kanonik təkmilləşdirmə dövrünü yığaq. O, mümkün qədər praktiki və sadədir: dörd addım.

flowchart TD
  A[Siqnal: nəsə ağrıyır
və ya artım imkanı var] --> B[Hipotez:
nəyi və necə dəyişirik]
  B --> C[Nəzarətli dəyişiklik
code/config-də]
  C --> D[Yoxlama:
offline + online]
  D --> A

Addım 1. Problemi və ya imkanı aşkar et

Bu addımda «hara baxmalı» sualına cavab verirsiniz. Nümunələr:

• büdcəli golden‑case‑lər üzrə LLM‑eval helpfulnessin düşdüyünü göstərir;
• p95 latency "suggest_gifts" aləti üzrə 1.2 saniyədən 3.8 saniyəyə yüksəldi;
• cost_per_task "gift_selection" ssenarisində reasoning modelinə keçiddən sonra 40 % artdı;
• workflow_completed → checkout_success konversiyası UX wizard dəyişəndən sonra 5 faiz bəndi azaldı;
• Bir həftədə Store‑da «hədiyyələr göstərilən limiti aşır» mövzusunda 10 şikayət yarandı.

Vacib nüans: bəzən siqnal «pisdir» yox, «daha yaxşı ola bilər» deyir. Məsələn, cost_per_task nəzərəçarpacaq dərəcədə icazə verilən həddən aşağıdır, quality‑score isə artıq 9/10. Deməli, daha bahalı model və ya daha «ağıllı» ssenarini sınamaq olar — bəlkə konversiya artar.

Addım 2. Hipotezi formalaşdır

Hipotez — bu «promptu yenidən yazacağıq» deyil, «Y komponentində konkret X dəyişiklik Z metrikini yaxşılaşdıracaq, çünki…». «Çünki» olmadan bu hipotez deyil, istəkdir.

Nümunələr:

• «Əgər system‑prompt‑da büdcənin sərt şəkildə qorunması qaydasını etsək və büdcənin necə istifadə olunduğunu hər dəfə izah etməyi xahiş etsək, büdcəli case‑lərdə helpfulness ən azı 2 bal artacaq».
• «Əgər rerank addımında bahalı modeli "gpt-mini" ilə əvəz etsək, cost_per_task 30 % düşəcək, konversiya isə 1 faiz bəndindən çox azalmayacaq».
• «Əgər wizardı sadələşdirsək (iki addımı birləşdirib) və CTA‑nı yenidən yazsaq, activation‑rate 5 faiz bəndi artacaq».

Kodda belə hipotezi heç olmasa obyekt kimi açıq təsvir etmək rahatdır:

// lib/improvement/hypothesis.ts
export type ImprovementHypothesis = {
  id: string;
  scenario: string;
  description: string;   // "Nəyi dəyişirik və niyə"
  targetMetric: string;  // məsələn, "quality.helpfulness" və ya "conversion.checkout"
  successCriteria: string;
};

Bəli, bu demək olar ki, Jira tiketidir, amma heç olmasa tiplənmiş formadadır.

Addım 3. Nəzarətli dəyişiklik et

Burada iki söz vacibdir: nəzarətli və ayrı‑ayrı.

Nəzarətli o deməkdir ki, dəyişiklik PR/commit kimi rəsmiləşdirilib, hipotezə bağlanıb, changelog‑u var və imkan daxilində feature‑flag və ya versiya ilə gəlir. Siz sadəcə «prodda promptu düzəltdiniz» yox, məhz hansı relizin bunu gətirdiyini deyə bilirsiniz.

Ayrı‑ayrı o deməkdir ki, bir relizdə üç fərqli hipotezi eyni vaxtda qarışdırmamağa çalışırsınız. Eyni vaxtda:

• modeli dəyişsəniz,
• system‑prompt‑un yarısını yenidən yazsanız,
• və UX‑ə yeni addım əlavə etsəniz,

metriklər yaxşılaşsa belə, nəyin işə yaradığı aydın olmayacaq. Çox daha düzgünü kiçik porsiyalarla hərəkət etməkdir.

Texniki tərəfdən dəyişikliklər istənilən yerdə ola bilər:

• agentin system‑prompt‑u (lib/prompt/systemPrompt.ts);
• MCP‑tools təsvirləri (description, inputSchema, annotations);
• agent konfiqi (reasoning addımlarının limitləri, konkret alət üçün model seçimi);
• vidcet kodu (CTA, addımların sırası, xəta mətnləri).

Addım 4. Daha yaxşı olub‑olmadığını yoxla

Yoxlama offline və online bölünür.

Offline‑yoxlama — real istifadəçilər olmadan App‑ın yeni versiyasından golden‑case‑ləri keçirməkdir. Burada sizdə artıq var:

• LLM‑evals (modul 20.1);
• threshold/baseline məntiqi (modul 20.2).

Hədəf ssenarilər üzrə quality‑score necə dəyişib: artıb, düşüb, eyni qalıb — buna baxırsınız. Həmçinin safety‑case‑ləri yoxlayırsınız: hər hansı prompt düzəlişləri əvvəlcə safety dəstindən keçməlidir.

Online‑yoxlama — real trafikin üzərində eksperimentdir. Ən sadə variantda yeni versiyanı istifadəçilərin N %‑i üçün açır və müqayisə edirsiniz:

• hədəf hərəkətə konversiyanı (checkout, ssenarinin təkrar işə salınması);
• cost_per_task;
• şikayətlər/feedback.

Bundan sonra ya dövr bağlanır (hipotez təsdiqlənir/təkzib olunur və sənədləşdirilir), ya da yeni hipotez doğulur.

4. Daxili «təkmilləşdirmə assistenti» ayrıca agent kimi

İndi ən maraqlısı: LLM modelinə daha bir rol verək — təkcə istifadəçilərə cavab vermək yox, həm də sizə App‑ı yaxşılaşdırmaqda kömək etsin. Bu, istifadəçi GiftGenius‑dan ayrıca olan daxili agentdir.

Bu nədir

Bu assistent sizin daxili mühitinizdə yaşayır (eyni repoda, Dev Mode‑da, ayrıca ChatGPT App‑da). O:

• loqları və dialoqlardan seçmələri oxuyur;
• metriklərə baxır;
• system‑promptu və alət təsvirlərini analiz edir;
• problemləri və dəyişiklik təkliflərini formalaşdırmağa kömək edir.

Mahiyyətcə siz «virtual produkt meneceri/analitik» əldə edirsiniz ki, o:

• dialoqları oxumaqdan yorulmur;
• təkrarlanan nümunələri tez tapır;
• prompt və changelog qaralamaları yaza bilir.

O, hansı girişi qəbul edir

Agentə daha asan olsun deyə girişi formallaşdırmaq faydalıdır. Məsələn, tip:

// lib/improvement/assistant.ts
export type BadDialogExample = {
  id: string;
  userMessages: string[];
  appMessages: string[];
  qualityScore?: number;
};

export type ImprovementInput = {
  scenario: string;
  signals: ImprovementSignal[];      // əvvəlki bölmədən
  examples: BadDialogExample[];
  systemPrompt: string;
  toolsDescription: string;
};

"gift_selection" ssenarisi üzrə uğursuz 10–20 dialoqu loqlardan çıxarıb belə obyekt toplaya və cari system‑promptu, alət təsvirlərini əlavə edə bilərsiniz.

O, hansı çıxışı verməlidir

Gözlənilən cavabı da sabitləşdirmək rahatdır:

export type ImprovementSuggestion = {
  patterns: string[];     // təkrarlanan problemlər
  promptPatches: string[]; // system-prompt üçün fraqment təklifləri
  toolsPatches: string[];  // alət təsvirləri üzrə ideyalar
  uxCopyIdeas: string[];   // UX mətn variantları
  changelog: string[];     // "nəyi dəyişmək" üzrə qısa siyahı
};

Belə agent üçün meta‑prompt təxminən belə olacaq:

• «nümunələri və siqnalları analiz et»;
• «2–3 problem nümunəsi təsvir et»;
• «promptda, alət təsvirlərində və UX mətnlərində 1–2 dəyişiklik təklif et»;
• «hər şeyi sərt müəyyən edilmiş JSON formatında qaytar».

Sonra siz bu fraqmentləri əllə götürür, komandada müzakirə edir, koda daxil edir və eval‑lar və eksperimentlərdən keçirirsiniz. Vacib prinsip: bu assistent production‑da özü heç nəyi dəyişmir. O, ideya və mətn yaradır, commit yox.

5. Dəyişiklik tipləri: ümumiyyətlə nəyi «tüninq etmək» olar

Bu assistent və aydın dövr göründükdə hər şeyi «mənə system‑promptun yeni versiyasını at»a endirmək çox asandır. Əslində təkmilləşdirmə sahəsi xeyli genişdir.

Prompt və təlimatlar

System‑prompt rol, ton, prioritetlər və sərt qaydaları (məsələn, büdcə, safety, addımların ardıcıllığı) təyin edir. Onu:

• sadələşdirmək, ziddiyyətli və ya təkrarlanan təlimatları çıxarmaq;
• gücləndirmək, çatmayan qaydaları əlavə etmək (məsələn, büdcə ilə bağlı);
• fərqli ssenarilərə uyğunlaşdırmaq (ayrı alt‑promptlar: "gift_selection", "post_purchase_help" və s.).

Alət təsvirləri modelə hansı aləti nə vaxt çağıracağını və onun nə etdiyini başa düşməyə kömək edir. Burada təkmilləşdirmələr tez‑tez bunlara gəlir:

• daha aşkar «Use this when… / Do not use when…»;
• ifadələrin dəqiqləşdirilməsi (digər alətlərlə üst‑üstə düşmənin azaldılması);
• nəticələr barədə məlumatın əlavə edilməsi (destructiveHint, isConsequential).

Safety qaydaları — çətin domenlərdə davranışa cavabdeh olan prompt/təsvir hissəsidir. Onları ancaq yaxşı safety eval‑larından sonra dəyişmək daha doğrudur.

Davranış arxitekturası (behavior)

Bəzən problemi promptla həll etmək olmur: hərəkətlər ardıcıllığını dəyişmək lazımdır.

Nümunələr:

• baha aləti çağırmadan əvvəl parametrlərin mütləq dəqiqləşdirilməsi addımını əlavə etmək;
• hesablamanın bir hissəsini ayrıca, daha ucuz addıma çıxarmaq (məsələn, əvvəlcədən filterləmə backend‑də);
• bir ssenaridə ardıcıl alət çağırışlarının sayını məhdudlaşdırmaq.

Bu dəyişikliklər adətən yalnız promptda yox, agent və ya MCP qatının konfiqində təsvir olunur.

UX və copywriting

Bəli, düymələrdəki və xətalardakı mətnlər də keyfiyyətin bir hissəsidir. GiftGenius belə yazırsa:

«Xəta 500. Administratorla əlaqə saxlayın»,

tamamilə başqa təəssürat yaradır, nəinki belə yazanda:

«Mağazadan cavab ala bilmədik. Seçilmiş ideyalarınız itməyib, xahiş edirik, almanı bir az sonra yenidən sınayın».

Ara ekranlar, bələdçilər, ipucları, wizard strukturu — bunların hamısı sizin ölçdüyünüz activation‑rate və konversiyalara təsir edir.

İqtisadiyyat

Burada yaxşı tanış «keyfiyyət ↔ xərc» oyununu oynayırıq:

• model seçimi (reasoning‑li bahalı, sürətli/ucuz);
• reasoning/agent addımlarının dərinliyi (nə qədər iterasiya icazə verilir);
• dialoq limitləri (məsələn, bir sessiyada N‑dən çox seçim yenidən hesablaması yox);
• token/büdcə limitləri vurulanda «ucuz» fallback rejimləri.

Buradan gələn siqnallar cost_per_task, cost_per_user, marja və s. şəklində quality‑score ilə birgə izlənir.

6. Guardrails: LLM‑ə etibar etməmək lazım olanlar

Sistemdə «təkmilləşdirmə assistenti» və rahat dövr peyda olanda «Avto‑optimallaşdırma» düyməsinə basıb çıxmaq çox cazibədardır. Gəlin dərhal razılaşaq, bu düymənin qadağan olduğu yerlər hansılardır.

İcazələrdə dəyişikliklər (OAuth scopes, MCP alətləri, məlumatlara çıxışlar) — bunlar həmişə human‑in‑the‑loop zonasındadır. Heç bir model App‑ın sifarişləri oxuya, ödənişlərə toxuna və ya istifadəçilərə məktub göndərə biləcəyinə özü qərar verməməlidir. Eyni şey commerce flow‑a da aiddir: ACP/Stripe, limitlər, ödəniş tipləri və qaytarmalar ətrafındakı istənilən dəyişiklik insan revi̇yudan və testdən keçir.

App‑ın safety profili (hansı domenlərdə məsləhət verə bilər, harada mütləq imtina etməlidir) — LLM‑ə həvalə ediləsi bir şey deyil. Model qaydaların mətnini formalaşdırmağa kömək edə bilər, amma hansı mövzulara App‑a etibar edəcəyinizə qərarı siz verirsiniz.

Məlumat və loglama siyasəti (nələri loqlayırıq, nə qədər saxlayırıq, silmə tələblərinə necə cavab veririk) — eyni siyahıdadır. LLM Privacy Policy strukturunu təklif edə bilər, amma sizin iştirakınız olmadan koddakı saxlanma müddətini dəyişməməlidir.

Nələri yarımavtomatlaşdırmaq olar? Promptların ifadələri və wording, alət təsvirləri və UX mətnləri, alətlərin prioritetləri (ağlabatan hədlərdə), əlavə dəqiqləşdirici suallar. Bunların hamısını assistentə ideya mənbəyi kimi həvalə etmək olar, amma son söz və yoxlama insanda və eval skriptlərindədir.

7. End‑to‑end təkmilləşdirmə dövrü nümunəsi (GiftGenius)

Qəhrəmanımıza qayıdaq.

Problem

İstifadəçi büdcəni göstərir, amma GiftGenius tez‑tez bu limiti aşan hədiyyələr təklif edir. Loqlarda «yox, bu çox bahadır» və «daha ucuz et» kimi davamların çox olduğu görünür.

Siqnallar

Əvvəlcə keyfiyyəti görürsünüz: «50$‑dək hədiyyə seç» tipli golden‑case‑lər üzrə LLM‑eval helpfulness təxminən 6/10 verir. Hakim reason sahəsində mütəmadi «hədiyyələr büdcəni aşır» və ya «büdcənin necə nəzərə alındığı izah olunmayıb» yazır.

Eyni zamanda produkt və iqtisadi siqnallar gəlir:

• limiti olan ssenarilər üzrə checkout_success konversiyası limitsizlərdən aşağıdır;
• bəzi istifadəçilər çox baha variantları görəndən sonra ssenarini tərk edir;
• bu ssenarilər üçün cost_per_task daha yüksəkdir, çünki App «daha ucuz et» xahişinə görə bir neçə dəfə yenidən hesablayır.

Təkmilləşdirmə assistenti ilə analiz

İstifadəçilərin qiymətə şikayət etdikləri 20 dialoq toplayır və ImprovementInput formalaşdırırsınız:

• scenario = "gift_selection_with_budget";
• signals — helpfulness və konversiyanın düşməsi ilə;
• examples — dialoqlarla;
• cari system‑prompt və alət təsvirləri.

Bunu daxili təkmilləşdirmə agentinə verirsiniz. Cavabda, məsələn, o belə çıxarır:

• Nümunələr/pattern‑lər:
  • «təxminən 50$‑dək» kimi formalaşdırılan büdcə çox sərbəst qəbul olunur;
  • system‑prompt «heç vaxt limiti aşan hədiyyə təklif etmə» tələbinə açıq şəkildə malik deyil;
  • cavablar büdcənin necə nəzərə alındığını istifadəçiyə izah etmir.
• Təkliflər:
  • system‑prompt‑a limitin sərt qorunması təlimatını əlavə etmək;
  • modeldən həmişə «bütün variantlar ≤ X» olduğunu deməsini xahiş etmək;
  • büdcə qeyri‑müəyyən səslənəndə («təxminən», «təqribən») dəqiqləşdirici sual əlavə etmək.

Hipotez və dəyişiklik

Hipotezi formalaşdırırsınız:

«Əgər limiti sərt qorumağı açıq şəkildə sabitləsək və büdcənin necə istifadə olunduğunu izah etməyi istəsək, büdcəli case‑lər üzrə helpfulness ən azı 8/10 olacaq, alışa konversiya isə 3 faiz bəndi artacaq».

System‑prompt‑a belə fraqment daxil edirsiniz:

export const budgetRule = `
Əgər istifadəçi büdcə göstərirsə (məsələn, "50$-dək" və ya "təxminən 30€"),
bu məbləği SƏRT yuxarı hədd kimi qəbul et.

Heç vaxt bu limiti aşan variantlar təklif etmə.
Hər cavabında bütün variantların büdcəyə uyğun olduğunu
və necə uyğun olduğunu açıq de (məsələn: "bütün hədiyyələr 45$-dan baha deyil").
`.trim();

Və budgetRule‑u GiftGenius‑un ümumi system‑prompt‑una əlavə edirsiniz.

Offline‑valida­siya

«Büdcəli hədiyyələr» golden‑case dəstini yeni versiyadan keçirirsiniz:

• LLM‑eval helpfulness 6.0‑dan 8.5‑ə qalxır;
• correctness də artır: büdcə qorunur;
• safety pisləşmir (heç olmasa).

Əksinə olsa — helpfulness artmırsa və ya safety düşürsə — dəyişiklik keçmir və hipotez yenilənir.

Online‑test

Sonra eksperiment işə salırsınız:

• istifadəçilərin 10 %‑i yeni prompt variantını alır (variant B);
• qalan 90 % — köhnəsini (variant A).

Bir həftə sonra baxırsınız:

• workflow_completed → checkout_success konversiyası B üçün, tutalım, 13 % oldu, A üçün 10 % idi;
• cost_per_task demək olar dəyişməyib;
• «çox baha» şikayətlərinin payı azalıb.

Eksperiment uğurlu sayılır.

Möhkəmləndirmə

Bundan sonra:

• yeni promptu trafikin 100 %‑nə yayır;
• regressiya dəstinə «50$‑dək yumşaq büdcə» adlı yeni golden‑case əlavə edir;
• nəticəni changelogda və bəlkə də tex‑notes‑da sabitləşdirirsiniz: ki, altı aydan sonra promtda niyə bu qədər sərt büdcə formulu olduğunu başa düşmək olsun.

Dövr bağlandı. Növbəti iterasiya, məsələn, çox nadir hobbiləri olan insanlar üçün tövsiyələr və ya seçim dəyərinin optimallaşdırılması ilə bağlı ola bilər.

8. Özünü təkmilləşdirən App üçün mini yol xəritəsi

Bu «üstə gələn daha 100500 tapşırıq» kimi görünməsin deyə, minimum nələr lazımdır ki, App artıq özünü təkmilləşdirən sayılsın, və sonra nələri əlavə etmək olar — bunu görmək faydalıdır.

Versiya 1.0: minimal improvement‑loop

Birinci addımda üç şey kifayətdir.

Birincisi, strukturlaşdırılmış loqlar və baza SLO‑lar. Siz artıq tool_invocation, workflow_completed, checkout_* hadisələrini requestId, userId, scenario, appVersion, costEstimateUsd ilə loglamağı bacarırsınız. Bunun üzərində SLO‑lar qurulur: latency, error‑rate, checkout uğuru.

İkincisi, 10–20 golden‑case və LLM‑eval skripti. Kiçik, amma yaxşı seçilmiş əsas ssenarilər üzrə nümunələr + safety‑case‑lər dəsti. Bir CLI skripti — App və hakimin üzərindən keçirdir və JSON qiymətlər çıxarır.

Üçüncüsü, 2 həftədən bir sadə ritual. Oturub (tək və ya komanda ilə) açın:

• SLO, cost, produkt metrikləri üzrə 2–3 dəsbord;
• golden‑case‑lər üzrə LLM‑eval hesabatı;

və növbəti dövr üçün 1–2 hipotez seçin. Formalaşdırın, sənədləşdirin, kiçik reliz edin, yoxlayın.

Versiya 2.0: «ağıllı» improvement‑loop

Növbəti səviyyədə bunlar yaranır:

Daxili təkmilləşdirmə assistenti. Bu, ayrıca təsvir olunmuş agentdir (və ya ChatGPT App) ki, ImprovementInput qəbul edir və ImprovementSuggestion qaytarır. O, dialoqları əl ilə süzməyə saatlar sərf etməməyə kömək edir.

Avtomatlaşdırılmış hesabatlar. Loqlar və eval‑lar əsasında aşağıdakılar generasiya oluna bilər:

• problemli case klasterləri (məsələn, büdcəni istifadəçinin yenidən yazdığı bütün hallar);
• prompt və alət təsvirləri üzrə istifadəyə hazır qaralamalar;
• qısa changelog.

CI hook‑lar. Promptlarda, agent konfiqlərində, alət təsvirlərində istənilən dəyişiklik avtomatik işə salır:

• funksional golden‑suite;
• safety‑suite.

Əgər safety‑case‑lər düşürsə və ya əsas ssenarilərdə keyfiyyət hədləri keçmir — build qırmızıdır, reliz yoxdur.

9. Praktika

Tapşırıq 1. Öz App‑ınız üçün mini feedback‑loop

Tətbiqinizin bir əsas ssenarisini götürün. GiftGenius üçün artıq «hədiyyə seçimi və alış»ı seçmişik, siz oxşar ssenarini və ya öz ssenarinizi götürə bilərsiniz.

Sərbəst formada təsvir edin (və ya kiçik improvement-plan.md yaradın):

Hansıları izləyəcəksiniz. Hər kateqoriya üzrə bir dənə:

• texniki: məsələn, əsas işi görən alət üzrə p95 latency;
• iqtisadi: həmin ssenari üzrə cost_per_task;
• produkt: workflow_started → workflow_completed konversiyası və ya hədəf hərəkətə qədər;
• keyfiyyət: bu ssenari üzrə bir neçə golden‑case üçün orta quality_score.

Daha sonra deqradasiya saydığınız hədləri sabitləşdirin. «Nə vaxtsa baxarıq» yox, konkret:

• p95 > 5 saniyə — pisdir;
• cost_per_task gəlir artmadan 30 %‑dən çox yüksələrsə — həyəcan;
• quality_score 7‑dən aşağı düşərsə — araşdırmaq lazımdır.

Və ilk hipotezi formalaşdırın. Məsələn:

«Şübhələnirəm ki, çox dəqiqləşdirici sual veririk. Əgər wizardı bir addım qısaltsaq və sualları bir qədər ümumiləşdirsək, activation‑rate artacaq, helpfulness isə demək olar ki, zərər görməyəcək. Bunu kiçik UX dəyişiyi və A/B eksperimentlə yoxlayacağam».

Bu artıq sadəcə «UX‑i yaxşılaşdıraq» deyil, dövr daxilində kifayət qədər konkret addımdır.

Tapşırıq 2. Təkmilləşdirmə assistenti üçün meta‑prompt

Öz App‑ınız üçün daxili təkmilləşdirmə agentinin prompt mətnini cızmağa çalışın. Sadədən başlaya bilərsiniz:

• Onun kim olduğunu təsvir edin: «Sən App N‑in keyfiyyət analitiki‑sən, hansı ki…».
• Alacağı girişi sadalayın: dialoqlar, siqnallar, system‑prompt, descriptions.
• Tapşırıqları formalaşdırın:
  • 2–3 problem nümunəsi tap;
  • prompt, alətlər və UX mətnləri üzrə 1–2 dəyişiklik təklif et;
  • qısa changelog topla.
• Cavab formatını təsvir edin: patterns, suggestions, changelog sahələri olan strukturlaşdırılmış JSON.

Bu agenti hələ koddan çağırmasanız belə, tək bir belə prompt artıq App‑ı necə yaxşılaşdırdığınız barədə düşüncələrinizi daha yaxşı strukturlaşdırmağa kömək edəcək.

10. Təkmilləşdirmə dövrünü qurarkən tipik səhvlər

Xəta №1: yalnız bir metrikaya görə optimizasiya.
Tək bir şeyə fokuslanmaq cazibədardır. Təkcə cost arxasınca qaçıb OpenAI hesabının düşməsinə sevinə bilərsiniz — və quality‑score, konversiyalar, retention aşağı düşdüyünü görməyə bilərsiniz. Əksinə də ola bilər: reasoning modellərində keyfiyyəti 10/10‑a fırladıb, hər ssenarinin dollarla ölçülən dəyərə çatdığını unutmaq. Təkmilləşdirmə dövrü metrik paketinə baxmalıdır: keyfiyyət ↔ pul ↔ istifadəçi davranışı.

Xəta №2: ölçməsiz «sehrli» prompt dəyişiklikləri.
«System‑promptu yenidən yazdım, indi daha yaxşı olmalıdır» cümləsi golden‑case və evals olmadan — bir neçə həftə sonra özünüzə sürpriz etmək üsuludur. Promptda istənilən dəyişiklik — xüsusən production‑da — anlaşılan pipeline‑dan keçməlidir: case dəsti, əvvəl/sonra LLM‑eval, lazım olsa — online eksperiment. Yoxsa siz App‑ı yaxşılaşdırmırsınız, keyfiyyəti təsadüfi istiqamətdə səpirsiniz.

Xəta №3: LLM assistentindən auto‑deploy dəyişikliklər.
Təkmilləşdirmə assistenti heyrətamiz dərəcədə gözəl prompt fraqmentləri və inandırıcı alət təsvirləri yazsa belə, bu onları reviewsuz prod‑a push etmək üçün səbəb deyil. Model bütün biznes məhdudiyyətlərini, safety risklərini, metrik kontekstinizi görə bilməz. Onun rolu — məsləhətçidir, reliz hüquqlu DevOps deyil.

Xəta №4: dəyişikliklərin hipotez və siqnallarla əlaqəsinin olmaması.
Bəzən komandalar «hisslərə görə» düzəlişlər edir və hansı siqnalın dəyişiklik gətirdiyini, hansı hipotezi yoxladıqlarını qeyd etmir. Nəticədə bir ay sonra promptda qəribə bir abzasın niyə peyda olduğu və kimə lazım olduğu yadlardan çıxır. Keyfiyyət üzrə yaxşı PR minimum üç suala cavab verməlidir: «nə ağrıyırdı?», «nəyi dəyişirik?», «nəyə görə daha yaxşı olduğunu necə anlayacağıq?».

Xəta №5: təkmilləşdirmələrdə safety‑ni unutmaq.
Faydalılıq arxasınca qaçarkən safety məhdudiyyətlərini zəiflətmək, promtdan «artıq imtinaları» çıxarmaq və ya safety‑case‑ləri keçirməyi unutmaq asandır. System‑prompt, alət təsvirləri və agent behavioru üzrə istənilən dəyişiklik əvvəlcə safety eval dəstindən keçməlidir. Əgər əvvəllər keçən hər hansı bir case indi yıxılırsa — bu, qırmızı siqnaldır, qalan metriklər nə qədər gözəl görünsə də.

Xəta №6: «hər şeyi eyni anda optimizasiya etmək» istəyi.
Promtun yarısını yenidən yazmaq, modeli dəyişmək, daha bir MCP aləti və yeni wizard əlavə etmək — hamısı bir relizdə — məhsuldar səslənir, amma effekti verən dəyişiklikləri anlamağı tam məhv edir. Təkmilləşdirmə dövrü yalnız iterativ və fokuslu olduqda effektivdir: bir‑iki hipotez, kiçik dəyişiklik dəsti, aydın rollback planı.

Xəta №7: təkmilləşdirmə dövrünü nadir «ümumi təmizlik gününə» çevirmək.
Əgər siz yarım ildən bir möhtəşəm «keyfiyyət günü» keçirir, qalan aylarda eval və metrik analizsiz yaşayırsınızsa, App vaxtın çox hissəsində «axınla gedəcək». Həftəlik/iki həftəlik kiçik, amma müntəzəm ritual daha faydalıdır: siqnallara baxmaq, hipotezləri yeniləmək və kiçik addımlar atmaq. Məhz bu cür sizin ChatGPT App statik olmaqdan çıxır və həqiqətən özünü təkmilləşdirməyə başlayır.