ChatGPT Desktop-dan Səmərəli İstifadə: Luna, Terra, Sol və Astra Arasındakı Fərqlər

ChatGPT Desktop-dan real proqramlaşdırma, araşdırma və layihə işlərində bir müddət istifadə etdikdən sonra model seçiminə baxışım dəyişdi.

Artıq məsələyə “Ən güclü model hansıdır?” kimi yanaşmıram.

Mənim üçün əsas sual budur:

Bu işi düzgün şəkildə görə biləcək ən sürətli və ən sərfəli model hansıdır?

Çünki hər iş üçün ən güclü modeli seçmək çox vaxt lazımsız resurs sərfidir. Digər tərəfdən, sırf daha ucuz olduğu üçün zəif modeli seçib eyni işi beş dəfə düzəltmək də səmərəli deyil.

Düzgün modeli seçmək, layihəni yaxşı izah etmək, söhbətləri lazımsız şəkildə uzatmamaq və mürəkkəb işlərdə əvvəlcə plan qurmaq ChatGPT Desktop-dan aldığım nəticəni xeyli yaxşılaşdırdı.

Əvvəlcə modellərin adlandırılmasını dəqiqləşdirək:

Luna, Terra və Sol GPT-5.6 ailəsinə daxildir. Astra isə GPT-6 modelidir.

2026-cı ilin sentyabrına olan vəziyyətə görə OpenAI Astra-nı xüsusilə daha çətin və genişmiqyaslı işlər üçün nəzərdə tutur.

Əslində dörd model dörd fərqli resurs büdcəsidir

Mən modellərə təxminən belə yanaşıram:

Praktikada bu fərq həqiqətən vacibdir.

Məsələn, 300 sətrlik siyahıdan SKU kodlarını çıxarmaq üçün Astra işlətmək mənə görə artıq resurs sərfidir.

Bu, bir neçə CSV sütununun adını dəyişmək üçün senior sistem memarı çağırmağa bənzəyir.

Amma production sistemində bir neçə servisin, verilənlər bazasının, tətbiq kodunun və yarımçıq stack trace-lərin birlikdə təhlili tələb olunan qəribə bir problem varsa, daha böyük reasoning büdcəsi istifadə etmək tam məntiqli ola bilər.

Benchmark fərqi qiymət fərqindən daha kiçik ola bilər

GPT-5.6 ailəsində diqqətimi çəkən məqamlardan biri budur:

Luna və Terra-nı Sol-un sadəcə “zəif versiyaları” kimi görmək düzgün deyil.

OpenAI tərəfindən yayımlanan bəzi benchmark nəticələrində modellər arasındakı fərq düşündüyümüz qədər böyük deyil.

Əlbəttə, bunlar benchmark nəticələridir. Sənin konkret layihəndə eyni nəticəni alacağına zəmanət vermir.

Amma gündəlik və nisbətən sadə işlərdə Luna və ya Terra istifadə etməyin niyə məntiqli olduğunu yaxşı göstərir.

Astra isə başqa nəsil model olduğuna görə onu köhnə test nəticələri ilə birbaşa müqayisə etmək doğru olmaz.

Astra və Sol-un eyni testlərdə müqayisə olunduğu daha yeni nəticələrdə fərq daha aydın görünür:

Xüsusilə tapşırıq proqramlarla qarşılıqlı işləməyi, uzun reasoning zəncirini, tanış olmayan mühitləri və ya bir neçə fərqli bacarığın eyni anda istifadəsini tələb edirsə, Astra-nın üstünlüyü daha aydın görünür.

Mənim burada tətbiq etdiyim qayda sadədir:

İstifadə etməyəcəyin əlavə ağıla görə resurs xərcləmə.

Reasoning səviyyəsi bəzən model qədər vacibdir

Model seçimi işin yalnız bir hissəsidir.

Digər vacib məsələ modelə nə qədər düşünmə imkanı verdiyindir.

Sol, Terra, Luna və Astra fərqli reasoning səviyyələri ilə işləyə bilir.

Ümumi məntiq belədir:

Daha yüksək reasoning səviyyəsi modelə çətin problemi həll etmək üçün daha çox hesablama imkanı verir.

Amma bunun qarşılığında daha çox resurs və istifadə limiti sərf oluna bilər.

Bu səbəbdən mən hər tapşırıqda avtomatik şəkildə High və ya Max seçmirəm.

Məsələn:

Luna / Low

Məlumat çevirmə, sahələrin adını dəyişmək, qeydləri kateqoriyalara bölmək və sadə mətn düzəlişləri üçün rahatlıqla kifayət edə bilər.

Terra / Medium

Adi feature hazırlamaq, sənədləri oxumaq, bir faylı analiz etmək və nisbətən standart kod dəyişikliyi üçün yaxşı başlanğıcdır.

Sol / Medium və ya High

Arxitektura qərarları, ilk baxışdan görünməyən bug-lar, təhlükəsizlik riskləri və ya bir neçə sistemin bir-biri ilə əlaqəli olduğu tapşırıqlarda daha məntiqlidir.

Astra / Low və ya Medium

Onsuz da kifayət qədər güclü ola bilər.

High və ya Max səviyyəsini isə yalnız həqiqətən mürəkkəb problem olduqda istifadə etməyi üstün tuturam.

Çünki daha çox düşünmək hər zaman daha yaxşı nəticə demək deyil.

Bəzən problem sadədir.

Belə halda modelə daha çox reasoning büdcəsi vermək sadəcə daha çox resurs sərf etdirir.

Context window ilə istifadə limiti eyni şey deyil

Bu iki anlayış tez-tez qarışdırılır.

Müasir modellərin çox böyük context window-u var.

Amma bu, ChatGPT abunəliyinin hər söhbət üçün sənə həmin qədər token verdiyi anlamına gəlmir.

Context window modelin eyni tapşırıq daxilində nə qədər məlumatı nəzərə ala biləcəyini göstərir.

İstifadə limiti isə planın və işlədiyin rejimin sənə nə qədər hesablama resursu verdiyi ilə bağlıdır.

Məsələn, ChatGPT Work və Codex tərəfdə istifadə yalnız mesaj sayına görə hesablanmır. Görülən işin ağırlığı da ciddi rol oynayır.

Plus planında OpenAI tərəfindən verilən təxmini beş saatlıq mesaj aralıqları belədir:

Bu rəqəmləri sabit limit kimi qəbul etmək olmaz.

Bir funksiyanın adını dəyişməklə yüzlərlə fayldan ibarət repository-ni analiz etmək eyni resurs sərf etmir.

Reasoning səviyyəsi, input-un həcmi, çıxışın uzunluğu, tool istifadəsi və işin neçə addımdan ibarət olması sərfiyyata ciddi təsir edir.

Təkcə bu cədvəl belə niyə hər iş üçün Astra seçməyin düzgün olmadığını göstərir.

Modellərin real qiymət fərqi nə qədərdir?

ChatGPT abunəliyindəki istifadə ilə API qiymətləri eyni şey deyil.

Amma API qiymətləri modellər arasındakı hesablama xərcini müqayisə etmək üçün yaxşı göstəricidir.

Bir milyon token üçün standart mətn qiymətləri təxminən belədir:

Bunu daha anlaşıqlı etmək üçün sadə nümunə götürək.

Tutaq ki, eyni tapşırıq:

20.000 input token

və

5.000 output token

istifadə etdi.

Tool xərclərini və caching üstünlüklərini nəzərə almasaq, təxmini qiymət belə olar:

Amma bu o demək deyil ki, bütün modellər eyni işi eyni sayda token ilə görəcək.

Daha güclü model problemi ilk cəhddə həll edə bilər.

Daha ucuz modeldə isə bir neçə dəfə düzəliş etmək lazım gələ bilər.

Ona görə mən iki fərqli şeyə baxıram:

token başına xərc

və

tamamlanmış tapşırıq başına xərc.

Bunlar eyni şey deyil.

“Bu model işi orta hesabla neçə dəqiqəyə bitirər?” sualının dəqiq cavabı yoxdur

Əvvəlcə mən də belə sadə bir cədvəl hazırlamaq istəyirdim:

Luna = 30 saniyə / 5K token
Terra = 1 dəqiqə / 8K token
Sol = 3 dəqiqə / 20K token

Amma əslində belə rəqəmlər saxta dəqiqlik yaradar.

Çünki “bir tapşırıq” anlayışının standart ölçüsü yoxdur.

Bir tapşırıq bir cümlədən ibarət ola bilər.

Başqa biri 500 fayllıq repository ola bilər.

Birində heç bir tool istifadə olunmaz.

Digərində onlarla tool çağırışı lazım gələ bilər.

Reasoning səviyyəsi dəyişir.

Söhbət tarixçəsi böyüyür.

Model əvvəlcə səhv yanaşma seçib sonra geri qayıda bilər.

Bunların hamısı həm vaxtı, həm də istifadə olunan resursu dəyişir.

Ona görə mən daha çox bu göstəriciyə baxıram:

Düzgün nəticəyə çatmaq üçün ümumilikdə nə qədər vaxt və model resursu sərf olundu?

Ucuz modelə eyni işi altı dəfə düzəltdirəcəksənsə, Sol-un bir dəfə edib düzgün nəticə verməsi sonda daha sərfəli ola bilər.

Uzun söhbətlər hiss etdirmədən baha başa gələ bilər

ChatGPT ilə işləyərkən mənim üçün ən vacib müşahidələrdən biri də bu oldu.

Biz ekranda mesajlar görürük.

Model tərəfində isə onların böyük hissəsi context olur.

Söhbət böyüdükcə modelin qarşısında daha çox:

• əvvəlki təlimat,

• kod,

• cavab,

• log,

• uğursuz sınaq,

• izah,

• tool nəticəsi

toplanır.

Və sonrakı tapşırıqlarda bunların müəyyən hissəsini yenidən nəzərə almaq lazım gəlir.

Bu səbəbdən artıq bütöv layihəni bir dənə sonsuz söhbət pəncərəsində aparmağa çalışmıram.

Məsələn, belə işlərim olduğunu düşünək:

• ödəniş inteqrasiyası,

• Shopify OAuth,

• məhsul ötürülməsi,

• stok sinxronizasiyası,

• təhlükəsizlik auditi.

Lazım olduqda bunları ayrı tapşırıqlara və ayrı söhbətlərə bölmək daha səmərəlidir.

Bunun iki əsas üstünlüyü var:

Model əlaqəsi olmayan köhnə məlumatları boş yerə analiz etmir.

Mən də hər tapşırığın məqsədini daha təmiz şəkildə izah edə bilirəm.

Amma burada həddindən artıq parçalamaq da düzgün deyil.

Əgər yeni iş həqiqətən əvvəlki reasoning və nəticələrdən asılıdırsa, sırf token qənaət etmək üçün söhbəti ayırmağın mənası yoxdur.

Yeni pəncərə açıb köhnə söhbətin hamısını ora yapışdırmaq da problemi həll etmir.

Əsas prinsip budur:

Context-i sıfırlamaq yox, lazımsız context-i azaltmaq.

İşə başlamazdan əvvəl layihəni README ilə tanıt

Proqramlaşdırma layihələrində ən çox faydasını gördüyüm şeylərdən biri modelə işi verməzdən əvvəl düzgün layihə təsviri təqdim etməkdir.

Burada README faylı həqiqətən vacibdir.

Yaxşı README heç olmasa bu suallara tez cavab verməlidir:

• Bu layihə nə edir?

• Hansı texnologiyalar istifadə olunur?

• Repository necə qurulub?

• Layihə necə başladılır?

• Testlər necə işə salınır?

• Pozulmamalı olan qaydalar hansılardır?

• Hansı servis və API-lərlə işləyir?

• Hansı hissələr xüsusilə həssasdır?

Bu, xeyli vaxt qazandıra bilər.

Model layihəni tanımırsa, eyni anda iki iş görməyə çalışır:

Əvvəlcə arxitekturanı anlamağa çalışır.

Sonra sənin problemini həll edir.

Yaxşı README verdikdə isə bir neçə addım irəlidən başlayır.

Təbii ki, burada təhlükəsizlik tərəfini də unutmaq olmaz.

Modele kömək etmək üçün README faylına şifrə, API secret, private key və ya production giriş məlumatları yazmayın.

Hansı sahənin mütəxəssisi kimi yanaşmalı olduğunu bildir

Vacib tapşırıqların əvvəlində modelə hansı baxış bucağı ilə işləməli olduğunu göstərmək mənim üçün faydalı olub.

Bu, sadəcə:

“Sən çox yaxşı mütəxəssissən.”

yazmaqla modelin birdən-birə daha ağıllı olması demək deyil.

Əsas faydası onun nəyə diqqət etməli olduğunu müəyyənləşdirməkdir.

Məsələn, belə bir təlimatdan istifadə edə bilərəm:

Senior Laravel/PHP developer və tətbiq təhlükəsizliyi üzrə mütəxəssis kimi işləyirsən.

Dəyişiklik etməzdən əvvəl layihənin README faylını oxu.

Məqsəd:
Mövcud public API davranışını pozmadan Shopify sinxronizasiya problemini həll et.

Kod dəyişdirməzdən əvvəl:

1. Əlaqəli kodu araşdır.
2. Problemin ehtimal olunan səbəbini müəyyən et.
3. Qısa icra planı hazırla.
4. Geriyə uyğunluğu və təhlükəsizlik risklərini nəzərə al.

Dediklərimi mexaniki şəkildə yerinə yetirmək məcburiyyətində deyilsən.

Mənim gözdən qaçırdığım riskləri, çatışmayan tələbləri, ziddiyyətləri
və ya daha yaxşı həll yollarını da tapmağa çalış.

Daha düzgün yol görürsənsə, bunu izah et və planı ona uyğun dəyiş.

İşin tamamlanmış sayılması üçün:

Problem həll olunmalıdır,
mövcud davranış pozulmamalıdır
və əlaqəli testlər uğurla keçməlidir.

Burada mənim üçün ən vacib hissə budur:

Sadəcə dediklərimi etmə. Mənim görmədiklərimi də görməyə çalış.

Mən modelin yanlış fərziyyəmi kor-koranə həyata keçirməsini istəmirəm.

Məqsədim yalnız tapşırığı yerinə yetirən süni intellekt deyil.

Nə etmək istədiyimi anlayıb lazım gəldikdə:

“Burada daha təhlükəsiz yol var.”

və ya

“Bu dəyişiklik başqa sistemi poza bilər.”

deyə bilən bir iş ortağı əldə etməkdir.

Məncə peşəkar nəticə ilə sadəcə verilən əmri yerinə yetirən nəticə arasındakı əsas fərqlərdən biri də budur.

Mürəkkəb işlərdə əvvəlcə plan, sonra icra

Balaca CSS margin dəyişikliyi üçün ayrıca plan hazırlatmağın mənası yoxdur.

Amma production verilənlər bazasına toxunan böyük migration üçün vəziyyət tamam başqadır.

Tapşırıq:

• böyükdürsə,

• tanış deyilsə,

• risklidirsə,

• bir neçə sistemə toxunursa,

mən əvvəlcə modeldən plan hazırlamasını üstün tuturam.

Model ilk olaraq bunları müəyyən etsin:

1. Nələri araşdırmaq lazımdır?

2. Problemin əsas səbəbinin nə olduğunu düşünür?

3. Hansı fayl və sistemlər təsirlənəcək?

4. Nəyi dəyişmək istəyir?

5. Nə poza bilər?

6. Nəticənin düzgün olduğunu necə yoxlayacaq?

Yalnız bundan sonra icraya başlasın.

Xüsusilə Sol və Astra kimi modellərdə planlama daha çox məna daşıyır, çünki onsuz da bu modellərdən əsasən mürəkkəb tapşırıqlarda istifadə edirik.

Planlamanın başqa vacib üstünlüyü də var:

Model 20 faylı dəyişdirməzdən əvvəl səhv istiqamətə getdiyini görmək şansın olur.

Mənim praktik model seçmə qaydam

Bir müddət bu cür işlədikdən sonra model seçimi mənim üçün xeyli sadələşdi.

İş mexanikidirsə, Luna ilə başla.

Adi anlayış və qərar vermə tələb olunursa, Terra istifadə et.

Reasoning-in düzgün olması resurs qənaətindən daha vacibdirsə, Sol-a keç.

Problem həqiqətən çətin, qeyri-adi, uzunmüddətli və ya səhv edilməsinin baha başa gələcəyi işdirsə, Astra istifadə et.

Amma modeli dəyişməzdən əvvəl özümə başqa bir sual da verirəm:

Mən tapşırığı doğrudan da düzgün izah etmişəm?

Çünki daha güclü model vermədiyin tələbi sehrli şəkildə bilə bilməz.

Əlçatan olmayan faylı oxuya bilməz.

Çatışmayan context-i daha çox reasoning verməklə tamamlamaq mümkün deyil.

Bəzən Luna-dan Sol-a keçməkdənsə yaxşı README hazırlamaq daha böyük fərq yaradır.

Bəzən problem modeldə deyil, tapşırığın necə yazılmasındadır.

Bu səbəbdən mənim indiki ChatGPT Desktop iş axınım təxminən belədir:

Düzgün context ver → tapşırığı aydın izah et → işi görə biləcək ən sərfəli modeli seç → lazım olduqda reasoning səviyyəsini artır → tapşırıqları fokuslu saxla → problem həqiqətən tələb edirsə daha güclü modelə keç.

Mənim təcrübəmdə bu yanaşma həm daha sürətli, həm də daha qənaətlidir.

Amma ən vacibi budur ki, ortaya çıxan işi yoxlamağı və nəticəyə güvənməyi xeyli asanlaşdırır.