Power BI, Microsoft tərəfindən hazırlanmış bir Business Intelligence (BI) platformudur. Xam, işlənməmiş məlumatları interaktiv hesabatlara və vizual panellərə (dashboard) çevirməyə imkan verir. Bir analitik kimi sənin vəzifən — müxtəlif mənbələrdən gələn datanı bir araya gətirib, biznes qərarlarına əsas olan aydın, dürüst vizuallar yaratmaqdır.

Power BI-ın gücü üç böyük sütun üzərindədir: Power Query (məlumatların yüklənməsi və təmizlənməsi), Data Model (cədvəllər arası əlaqələr), DAX (hesablamalar dili) və bunların hamısını bir araya gətirən Reporting qatı. Bu tutorial səni bu dörd sütunu başa düşmüş, real data üzərində işləyə bilən bir səviyyəyə çatdırmaq üçün yazılmışdır.

Bu tutorial boyunca işlədəcəyimiz data ssenarisi

Ssenari: Bir pərakəndə şirkətin 2022–2024-cü illərə aid satış datasını analiz edirik.
Cədvəllər: Sales (əsas satış faktları), Products (məhsul detalları), Customers (müştəri məlumatları), Regions (coğrafi məlumat), Date (tarix cədvəli)
Hədəf: Kateqoriya üzrə satış payı, aylıq trend, ən çox satılan məhsullar, il-üzrə artım faizini göstərən bir dashboard qurmaq.

Bölmə 1 — Power BI Desktop İnterfeysi

Power BI Desktop-u ilk açdığınızda sizi bir neçə əsas görünüş (view) qarşılayır. Bu görünüşləri tanımaq, işinizin hansı mərhələsində olduğunuzu bilmək üçün vacibdir.

1.1 Views

1.2 Ribbons — Ən Çox İstifadə Edilən Menyular

Bölmə 2 — Get Data & Power Query

Hər analitik iş məlumatı əldə etməkdən başlayır. Power BI, 100-dən çox məlumat mənbəyini dəstəkləyir: Excel faylları, SQL Server, PostgreSQL, SharePoint, Web saytları, JSON faylları, Google Sheets, Salesforce, REST API-lər və daha çoxu. Məlumatı daxil etmək prosesi — sadəcə bir klik deyil; düzgün mənbəni seçmək, sütunları, tipləri, filtirləri qərar vermək deməkdir.

2.1 Məlumat Yükləmə Prosesi

1. Home tab → Get Data düyməsini klikləyin.
2. Açılan pəncərədə mənbəni seçin. Bizim nümunəmizdə Excel Workbook seçirik, çünki satış datamız Excel-dədir.
3. Fayl yolunu seçin → Open düyməsini basın. Navigator pəncərəsi açılır — bu pəncərədə fayldakı bütün sheet-lər görünür. Hansılarını yükləmək istədiyinizi seçin.

Diqqət: Load düyməsini basmayın! Əvvəlcə Transform Data seçin. Bunun niyə vacib olduğunu aşağıda izah edirik.

2.2 Transform Data — Power Query Editor

Transform Data düyməsi sizə Power Query Editor açır. Bu, Power BI-ın daxilinə qurulmuş bir ETL (Extract, Transform, Load) alətidir. Burada məlumatları yükləmədən əvvəl təmizlər, dəyişdirir, birləşdirirsiz. Power Query-nin ən böyük üstünlüyü odur ki, etdiyiniz hər əməliyyat Applied Steps panelində yadda saxlanır — sanki makros yazırsınız. Data dəyişsə belə, siz sadəcə Refresh edirsiz və bütün addımlar avtomatik yenidən icra olunur.

2.3 Data Types — Sütun Tipləri

Power Query bəzən sütunların tipini yanlış təyin edir məsələn, qiymət sütununu Text kimi yükləyir. Bu, hesablamaları tamamilə səhv olmasına səbəb olur. Hər sütunun tipi düzgün olmalıdır.

Tipi necə dəyişirik? Sütun başlığının sol tərəfindəki kiçik ikonaya klikləyin (məsələn, ABC = Text, 123 = ədəd). Açılan menyudan düzgün tipi seçin. Yaxud sütun başlığını sağ klik → Change Type seçin.

2.4 Ən Çox İstifadə Edilən Power Query Əməliyyatları

2.4.1 Null Dəyərlərlə İş

Real dünyada datanın böyük hissəsi natamamdır. Null dəyərlər — yəni boş xanalar — hesablamalarınıza ciddi zərər vura bilər. Power Query bu məsələ ilə başa çıxmaq üçün bir neçə üsul təqdim edir:

• Remove Rows → Remove Blank Rows: Bütün sütunları boş olan sətirləri silir.
• Replace Values: Sütunu seçin → sağ klik → Replace Values → ‘null’ yerinə 0 və ya ‘Unknown’ yazın.
• Fill Down / Fill Up: Birləşdirilmiş xanalardakı kimi boşluqları yuxarıdakı və ya aşağıdakı dəyərlə doldurur.
• Remove Rows → Remove Rows with Errors: Tip uyuşmazlığından yaranan xətalı sətirləri çıxarır.

Bizim nümunə datamızda: CustomerCity sütununda bəzi müştərilərin şəhər məlumatı yoxdur. Bu null dəyərləri ‘Unknown’ ilə əvəz edirik ki, hesablamalarımız pozulmasın.

2.4.2 Sütunların Parçalanması — Split Column

Bəzən bir sütunda iki məlumat birlikdə saxlanır. Məsələn, FullName sütununda ‘Aytən Həsənova’ yazır. Bunu iki ayrı sütuna bölmək üçün: Sütunu seçin → Home → Split Column → By Delimiter → ayırıcı simvolu seçin (məsələn, boşluq). Power BI FullName.1 (ad) və FullName.2 (soyad) sütunları yaradır.

2.4.3 Custom Column

Add Column → Custom Column vasitəsilə mövcud sütunlara əsaslanaraq yeni bir sütun yaratmaq olar. Məsələn,

TotalRevenue = [Quantity] * [UnitPrice]

Bu düstur hər sətir üçün Quantity × UnitPrice hesablayır. DAX-da da bunu edə bilərsiniz (Calculated Column kimi), amma Power Query-də etmək daha səmərəlidir çünki data model-ə yüklənmədən əvvəl işlənir.

2.4.4 Unpivot Columns

Bu, imtahanlarda ən çox soruşulan mövzulardan biridir. Tutaq ki, datanız aşağıdakı kimi wide formatdadır:

Bu format pivot cədvəlinə bənzəyir — BI alətləri üçün ideal deyil, çünki hər yeni ay üçün yeni sütun əlavə edilməlidir. Bunun əvəzinə long (uzun) format lazımdır:

1. Sabit qalacaq sütunları seçin (məsələn, yalnız ‘Məhsul’ sütunu)
2. Digər (ay) sütunlarını seçin → sağ klik → Unpivot Columns
3. Power Query ‘Attribute’ (ay adları) və ‘Value’ (satış rəqəmləri) adlı iki yeni sütun yaradacaq. Bunları istədiyiniz kimi adlandırın.

2.4.5 Merge Queries — Cədvəlləri Birləşdirmək (JOIN)

Home → Merge Queries — iki cədvəli ortaq bir açar (key) sütun üzrə birləşdirir. SQL-dəki JOIN əməliyyatının ekvivalentidir. Məsələn, Sales cədvəlindəki ProductID ilə Products cədvəlini birləşdirməklə məhsul adını satış datanıza əlavə edirsiniz.

2.4.6 Append Queries — Cədvəlləri Alt-Alta Qoymaq (UNION)

Home → Append Queries — eyni strukturlu iki (və ya daha çox) cədvəli alt-alta birləşdirir. Məsələn, 2022, 2023 və 2024 illərinə aid ayrı-ayrı Excel sheet-lərimizdə saxlanmış satış datalarını bir cədvəldə toplamaq üçün Append istifadə edirik.

Merge vs Append
Merge = yeni sütunlar əlavə edir (JOIN) — kənar cədvəldən məlumat gətirirsən. Append = yeni sətirlər əlavə edir (UNION) — eyni tip datanı uzadırsın.

2.5 Close & Apply — Power Query-dən Çıxmaq

Bütün əməliyyatları tamamladıqdan sonra Home → Close & Apply düyməsini basın. Power Query kapanır, bütün əməliyyatlar icra edilir və data Power BI Data Model-ə yüklənir. Bu proses çox böyük datalar üçün bir neçə saniyə çəkə bilər.

Bölmə 3 — Data Modeling (Məlumat Modelləşdirmə)

Data Modeling, yüklənmiş cədvəllər arasında münasibətlər (Relationship) qurmaq deməkdir. Bu, Power BI-ın beynini formalaşdıran hissədir. Düzgün qurulmuş bir model olmadan DAX formullarınız yanlış nəticə verəcək, filterlər düzgün axmayacaq, vizuallar sizə yalan danışacaq.

3.1 Star Schema

Power BI-da data modelləşdirmənin qızıl standartı Star Schema-dır. Bu sxemdə mərkəzdə bir Fact Table (hadisə cədvəli), ətrafında isə bir neçə Dimension Table (kontekst cədvəli) var. Bu quruluş insan zehninin bir ulduzu tanıması qədər intuitiv olduğu üçün bu adı almışdır.

3.2 Fact Table vs Dimension Table

Prinsip sadədir: əgər bir sütunu SUM edəcəksinizsə — o sütun Fact Table-dadır. Əgər bir sütuna görə filter edəcəksinizsə — o sütun Dimension Table-dadır.

3.3 Relationship Qurmaq

Model View-ə keçin (sol paneldə şəbəkə ikonu). Bütün cədvəlləri görəcəksiniz. Bir cədvəldəki sütunu (məsələn, Dim_Product-dakı ProductID) tutub digər cədvəlin üzərinə (Sales-dakı ProductID) sürükləyin. Power BI avtomatik olaraq Relationship yaradır.

3.3.1 Cardinality

Relationship pəncərəsindəki Cardinality seçimi, iki cədvəl arasındakı münasibətin tipini müəyyən edir:

3.3.2 Cross-filter Direction — Filterin Axış İstiqaməti

Bu, imtahanlarda çox soruşulan bir mövzudur. Cross-filter direction, filterin hansı istiqamətdə axacağını müəyyən edir.

3.4 Active vs Inactive Relationships

İki cədvəl arasında birdən çox tarix sütunu ola bilər — məsələn, Sales cədvəlində həm OrderDate həm də ShipDate var. Power BI iki cədvəl arasında yalnız bir active relationship saxlaya bilər; digəri inactive (qırıq xətt ilə göstərilir) olur.

Inactive relationship-i istifadə etmək üçün DAX-da USERELATIONSHIP funksiyasını çağırırsınız:

ShipDate Sales = CALCULATE(SUM(Sales[TotalAmount]), USERELATIONSHIP(Sales[ShipDate], Dim_Date[Date]))

Bölmə 4 — DAX (Data Analysis Expressions)

DAX, Power BI-ın hesablama dilidir. Excel formullarına bənzər, amma cədvəl-əsaslı düşünür — hər hesablama bir filter kontekstinə görə icra olunur. DAX öyrənmək, yalnız funksiyaları əzbərləmək deyil; filter kontekstinin necə işlədiyini anlamaq-dır. Bu bölüm həm fundamental fərqləri, həm də vacib funksiyaları real nümunələrlə əhatə edir.

4.1 Calculated Column vs Measure

Bu fərqi bilmədən DAX yazmaq — gözünüzü bağlı sürücülük etmək kimidir. Hər ikisi DAX istifadə edir, amma tamamilə fərqli məntiqə malikdir.

İkincisi daha güclüdür — çünki slicer-də 2024-ü seçsəniz, Total Profit avtomatik yalnız 2024 məlumatları üzrə hesablanır. Calculated Column isə həmişə tam cədvəlin dəyərini göstərir.

4.2 Measure Yaratmaq

1. Modeling tab → New Measure klikləyin (və ya Fact cədvəlinə sağ klik → New Measure)
2. Formula bar-da DAX formulunuzu yazın
3. Enter basın
4. Measure-ı Fields panelindəki sütun kimi visual-a sürükləyə bilərsiniz

Tövsiyə: bütün Measure-larınızı ayrı bir boş cədvəldə (Measure Table) saxlayın. Modeling tab → New Table → _Measures = ROW(“x”, 1) yazın. Bu boş cədvəl yalnız Measure-larınızı qruplaşdırmağa kömək edir, heç bir hesablamaya qarışmır.

4.3 Əsas DAX Funksiyaları

4.3.1 SUM, MIN, MAX, AVERAGE, COUNT, DISTINCTCOUNT

Ən sadə aggregasiya funksiyalarıdır:

• Total Sales = SUM(Sales[TotalAmount]
• Avg Order Value = AVERAGE(Sales[TotalAmount])
• Max Sale = MAX(Sales[TotalAmount])
• Unique Customers = DISTINCTCOUNT(Sales[CustomerID])

DISTINCTCOUNT — xüsusilə vacibdir. Normal COUNT sütundakı dolu xanaları sayır; DISTINCTCOUNT isə unikal (təkrarlanmayan) dəyərləri sayır. Neçə fərqli müştərinin sifariş verdiyini öyrənmək üçün DISTINCTCOUNT lazımdır.

4.3.2 CALCULATE — DAX-ın Ən Güclü Funksiyası

CALCULATE bir hesablamani dəyişdirilmiş filter kontekstində icra edir. Yəni: ‘bu hesablamı apar, amma bu şərtlər daxilində’. Sintaksis:

CALCULATE ( ifadə, filter1, filter2, … )

Nümunələr:

• Yalnız 2024-ün satışı: Sales 2024 = CALCULATE(SUM(Sales[TotalAmount]), Sales[Year] = 2024)
• Yalnız ‘Electronics’ kateqoriyası: Electronics Sales = CALCULATE(SUM(Sales[TotalAmount]), Dim_Product[Category] = “Electronics”)
• Birdən çox şərt: Q1 Electronics = CALCULATE(SUM(Sales[TotalAmount]), Dim_Date[Quarter] = 1, Dim_Product[Category] = “Electronics”)

4.3.3 ALL — Filterləri Silmək

ALL funksiyası müəyyən bir cədvələ və ya sütuna tətbiq olunan bütün filter-ləri silir. Bu, ümumi toplam hesablamalarında — xüsusilə faiz payı hesablamalarında — həyati əhəmiyyət daşıyır:

Sales Share % = DIVIDE( SUM(Sales[TotalAmount]), CALCULATE(SUM(Sales[TotalAmount]), ALL(Dim_Product)) )

Bu formula: ‘cari məhsulun satışı ÷ bütün məhsulların ümumi satışı’ hesabını verir. Slicer-də hər hansı məhsulu seçsəniz belə, ALL(Dim_Product) sayəsində məxrəc həmişə bütün məhsulların cəmini göstərəcək.

4.3.4 FILTER — Şərtli Cədvəl Qaytarmaq

FILTER funksiyası bir cədvəl qaytarır — amma yalnız şərtə uyğun sətirləri. Tək başına nadir istifadə olunur; adətən CALCULATE içində işlənir:

High Value Sales = CALCULATE( SUM(Sales[TotalAmount]), FILTER(Sales, Sales[TotalAmount] > 1000) )

Bu formulda FILTER(Sales, Sales[TotalAmount] > 1000) ifadəsi yalnız 1000-dən böyük sifariş sətrlərini götürür; CALCULATE isə bu kiçik çalışma üzərindən SUM edir.

4.3.5 RELATED — Digər Cədvəldən Dəyər Gətirmək

RELATED — Calculated Column içində, qurulmuş Relationship üzərindən başqa cədvəlin sütunundan dəyər oxuyur. SQL-dəki JOIN əməliyyatına bənzər, amma yalnız bir sətir üçün:

ProductCategory = RELATED(Dim_Product[Category])

Bu sütun Sales cədvəlinə əlavə edilərsə, hər satış sətri üçün həmin məhsulun kateqoriyasını Dim_Product cədvəlindən oxuyacaq. RELATED yalnız Calculated Column-da işlənir, Measure-da işləmir.

4.3.6 DIVIDE

Sıfıra bölmə xətasının qarşısını almaq üçün DIVIDE istifadə edin:

Profit Margin % = DIVIDE( [Total Profit], [Total Sales], 0 )

Üçüncü arqument (burada 0) — məxrəc sıfır olarsa nə qaytarılsın? Adətən 0 istifadə olunur, bəzən BLANK() istifadə edilir.

4.3.7 IF, SWITCH

IF: Sadə şərtli ifadə. Sales Category = IF([Total Sales] > 50000, “High”, “Low”)
SWITCH: Çox şərtli vəziyyətlər üçün IF-IF-IF-in xoş alternatividir:
Region Zone = SWITCH( Dim_Region[Country], “Azerbaijan”, “Caucasus”, “Turkey”, “MENA”, “Germany”, “Europe”, “Other” )

4.3.8 RANKX — Sıralama

RANKX — bir ölçüyə (Measure) görə elementlərini sıralayır:
Product Rank = RANKX( ALL(Dim_Product[ProductName]), [Total Sales], , DESC, DENSE )
Bu formula hər məhsulu toplam satışına görə azalan sıra ilə rəqəmləndirir. DENSE seçimi bərabər dəyərlər olduqda sıralamada boşluq buraxmır.

Bölmə 5 — Time Intelligence

Biznes analizinin ən vacib suallarından biri zamana bağlıdır: ‘Bu ay keçən aydan necə fərqlənir? Bu il ötən illə müqayisədə necədir? İlin əvvəlindən bu günə qədər nə qədər satdıq?’ Bu suallara cavab vermək üçün DAX-da xüsusi Time Intelligence funksiyaları var. Lakin bu funksiyalar yalnız düzgün qurulmuş bir Date Table ilə işləyir.

5.1 Date Table (Calendar Table) — Niyə Vacibdir?

Power BI-ın Time Intelligence funksiyaları daxilən zaman boyu fasiləsiz bir tarix sırasına ehtiyac duyur — ilin hər gününü, satış olsun ya olmasın. Əgər Fact cədvəlinizdəki tarix sütununu birbaşa istifadə etsəniz, satış olmayan günlər modeldə yoxdur və hesablamalar yanlış çıxacaq.

5.1.1 Date Table Yaratmaq

Modeling → New Table seçin və aşağıdakı formulunu yazın:

Dim_Date = CALENDAR(DATE(2022, 1, 1), DATE(2024, 12, 31))
Bu, 2022-ci ilin 1 Yanvarından 2024-cü ilin 31 Dekabrına qədər hər günü içərən bir cədvəl yaradır. İndi bu cədvələ lazımi sütunları Calculated Column olaraq əlavə edirik:

• Year = YEAR(Dim_Date[Date])
• Quarter = QUARTER(Dim_Date[Date])
• Month = MONTH(Dim_Date[Date])
• MonthName = FORMAT(Dim_Date[Date], “MMMM”)
• MonthShort = FORMAT(Dim_Date[Date], “MMM”)
• Week = WEEKNUM(Dim_Date[Date])
• DayOfWeek = WEEKDAY(Dim_Date[Date], 2)
• IsWeekend = IF(WEEKDAY(Dim_Date[Date], 2) >= 6, TRUE, FALSE)

5.1.2 Date Table-ı Qeyd Etmək

Date Table yaratdıqdan sonra onu Power BI-a rəsmi olaraq tanıtmaq lazımdır. Dim_Date cədvəlini seçin → Table Tools tab → Mark as Date Table → Mark as Date Table → Açılan pəncərədə Date sütununu seçin → OK. Bu addım olmadan Time Intelligence funksiyaları düzgün işləməyəcək.

5.2 Time Intelligence Funksiyaları

5.2.1 TOTALYTD — Cari İlin Başından Bu Günə

TOTALYTD (Year-To-Date) — ilin 1 Yanvarından cari tarixə qədər kumulativ (birikən) cəm verir:
YTD Sales = TOTALYTD( SUM(Sales[TotalAmount]), Dim_Date[Date] )
Bu measure grafik üzərindəki hər ay üçün o ayın sonundakı kumulativ cəmi göstərir. Mart ayında görürsünüzsə — bu Yanvar + Fevral + Martın cəmidir. Bu tipli hesablama kumulativ büdcə izləmə üçün çox istifadə olunur.
Bunun quarterly versiyası da var: TOTALQTD( SUM(Sales[TotalAmount]), Dim_Date[Date] ) — rübün əvvəlindən bu günə kumulativ cəm.

5.2.2 SAMEPERIODLASTYEAR — Keçən İlin Eyni Dövrü

SAMEPERIODLASTYEAR — cari filterdə seçilmiş dövrdən tam bir il geriyə gedir:
LY Sales = CALCULATE( SUM(Sales[TotalAmount]), SAMEPERIODLASTYEAR(Dim_Date[Date]) )
Qrafik üzərindəki Mart 2024 üçün bu measure, Mart 2023-ün satışını göstərəcək. İki measure yanı-yana qoyanda istifadəçi birbaşa müqayisə görür.

5.2.3 YoY Growth — İllik Artım Faizi

İki yuxarıdakı measure-ı birləşdirərək illik artımı faizlə göstərə bilərsiniz:

YoY Growth % = DIVIDE( [Total Sales] — [LY Sales], [LY Sales] )

Bu measure müsbət rəqəm göstərirsə artım var, mənfi rəqəm göstərirsə azalma var. Sonra bu measure-ı conditional formatting ilə yaşıl/qırmızı rəngləndirib daha oxunaqlı edə bilərsiniz.

5.2.4 DATEADD

DATEADD — istənilən tarix intervalını irəli-geri hərəkət etdirməyə imkan verir:

• Prev Month Sales = CALCULATE(SUM(Sales[TotalAmount]), DATEADD(Dim_Date[Date], -1, MONTH))
• Prev Quarter Sales = CALCULATE(SUM(Sales[TotalAmount]), DATEADD(Dim_Date[Date], -1, QUARTER))
• Next Year Forecast = CALCULATE(SUM(Sales[TotalAmount]), DATEADD(Dim_Date[Date], 1, YEAR))

Bölmə 6 — Visualization

Güclü bir model qurmaq — işin yalnız yarısıdır. Digər yarısı, düzgün vizualı seçib, aydın, yanıltıcı olmayan bir şəkildə təqdim etməkdir. Bu bölmədə hansı vizualın hansı sual üçün uyğun olduğunu, slicer-lərin necə qurulduğunu və interaksiyanın necə idarə edildiyini öyrənəcəksiniz.

6.1 Əsas Vizuallar və İstifadə Halları

6.2 Visual Əlavə Etmək

1. Report View-də boş bir canvas sahəsinə klikləyin
2. Visualizations paneli-ndən istədiyiniz vizualı seçin (sağ paneldə ikonlar sırası)
3. Fields paneli-ndən sütunları vizualın Axis, Values, Legend kimi bölmələrinə sürükləyin
4. Məsələn, Line Chart üçün: Axis → Dim_Date[MonthName]; Values → [Total Sales] Measure-ı
5. Format paneli (fırça ikonu) ilə rəng, başlıq, lejand, ox etiketlərini nizamlayın

6.3 Slicer-lər — İnteraktiv Filter

Slicer vizualı, report-dakı bütün digər vizuallara filter tətbiq edən interaktiv bir elementdir. İstifadəçi özü datanı kəsib-biçə bilər.

6.3.1 Slicer Yaratmaq

1. Visualization panelindən Slicer ikonunu seçin
2. Fields panelindən filter etmək istədiyiniz sütunu (məsələn, Dim_Date[Year]) Slicer-ə sürükləyin
3. Slicer seçili ikən Format paneli → Slicer settings → Style bölməsindən görünüşü seçin: List (yuxarıdan aşağı siyahı), Dropdown (açılan menyü), Tile (düymə kimi), Between (tarix/rəqəm aralığı üçün sürgü)

6.3.2 Slicer Sync — Birdən Çox Səhifə

Əgər report-unuzda çox sayda səhifə (page) var və hər səhifədə eyni slicer-in seçimini görmək istəyirsinizsə: View tab → Sync Slicers. Açılan paneldə hər slicer-in hansı səhifələrə sinxron olacağını seçirsiniz.

6.4 Visual Interactions — Vizuallar Arası Əlaqəni İdarə Etmək

Default olaraq, bir visual-a klikləndikdə həmin vizual bütün digər vizualları filter edir. Bu bəzən istəmədiyiniz nəticə verə bilər. Edit Interactions funksiyası ilə bu əlaqəni tənzimləyirsiniz.

1. Filter etmək istədiyiniz visual-ı seçin (məsələn, Product Category bar chart)
2. Format tab → Edit Interactions düyməsini basın
3. Digər visual-ların yuxarısında üç kiçik ikon görünür:

• Huni ikonu (Filter): Bu visual, həmin digər visual-ı filter etsin
• Vurğulama ikonu (Highlight): Filter etmə yox, yalnız seçili hissəni vurğulasın
• Xaç ikonu (None): Heç bir əlaqə olmasın — bu visual o digərini etkiləməsin

Lazımi seçimi etdikdən sonra Edit Interactions düyməsini yenidən basaraq rejimdən çıxın

6.5 Conditional Formatting

Table və ya Matrix içindəki dəyərləri dəyərin böyüklüyünə görə rəngləndirib ‘heat map’ effekti yaratmaq mümkündür. Bunun üçün: Visual seçili ikən Format paneli → Cell elements → Background color → Conditional formatting açın. Minimum-maximum rəng aralığını seçin.

Bu xüsusilə Matrix visual-ında müxtəlif kateqoriyaların müqayisəsi üçün çox effektivdir — ən yüksək satışlı xanalar daha tünd görünür, ən aşağılar solğun.

6.6 Tooltips —Əlavə Məlumat

Hər vizualın üzərinə gedəndə görünən kiçik popup məlumat qutusuna Tooltip deyilir. Bunu özelleştirə bilərsiniz: Format paneli → Tooltips → Report page seçin, sonra ayrıca hazırladığınız bir səhifəni tooltip olaraq təyin edin. Bu, çox zəngin interaktiv detay göstərmək üçün güclü bir texnikadır.

Bölmə 7 — Düzgün Dashboard Qurmaq

Düzgün bir dashboard — yalnız gözəl görünmür; sualları cavablandırır, qərar qəbuletmə prosesini sürətləndirir. Bu bölmə, bizim nümunə ssenarisi üzrə tam bir dashboard-un necə qurulduğunu addım-addım izah edir.

7.1 Dashboard Dizayn Prinsipləri

7.2 Bizim Dashboard-un Quruluşu

Nümunə ssenarisi üzrə dashboard-umuzu üç səhifəyə bölürük:

Səhifə 1 — Executive Summary

• 4 Card visual (yuxarıda): Ümumi Satış, Ümumi Mənfəət, Unikal Müştəri Sayı, Orta Sifariş Dəyəri
• 1 Line Chart: Aylıq satış trendi (cari il vs keçən il — iki xətt)
• 1 Bar Chart: Kateqoriyaya görə satış (üst 5)
• 1 Donut Chart: Kateqoriya üzrə satış payı (%)
• 3 Slicer: Year, Region, Category — sol tərəfdə şaquli

Səhifə 2 — Product Analysis

• Matrix: Məhsul × Ay × Satış (conditional formatting ilə)
• Scatter Chart: Qiymət vs Satış miqdarı (hər məhsul bir nöqtə)
• Bar Chart: Ən çox satılan 10 məhsul (RANKX ile)
• Treemap: Kateqoriya → Alt-kateqoriya → Məhsul payı

Səhifə 3 — Regional & Time Analysis

• Filled Map: Ölkəyə görə satış rəngli xəritə
• Column Chart (Stacked): Rüblərə görə Region üzrə satış payı
• KPI Visual: YTD satış vs büdcə hədəfi
• Line Chart: YoY artım faizi — aylıq

Bölmə 8 — Publish & Power BI Service

Dashboard-unuzu tamamladıqdan sonra onu Power BI Service-ə (bulud versiyasına) yayımlamaq (publish) lazımdır. Beləliklə, komandanızdakı digər insanlar da bu hesabatı brauzerdən görə bilər, siz isə avtomatik yeniləmə (scheduled refresh) qura bilərsiniz.

8.1 Publish Etmək

1. Home tab → Publish düyməsini klikləyin
2. Hansı workspace-ə yayımlamaq istədiyinizi seçin (şirkətin workspace-i və ya şəxsi ‘My workspace’)
3. Select düyməsini basın. Yayımlama proses tamamlanır.
4. Verilən linkdən birbaşa Power BI Service-də hesabatı aça bilərsiniz

8.2 Scheduled Refresh — Avtomatik Yeniləmə

Data mənbəniz bir server, SharePoint, yaxud bulud xidməti dirsə, Power BI Service-dən avtomatik yeniləmə tənzimləyə bilərsiniz. Bunun üçün ilk öncə Data Gateway qurmaq lazım ola bilər (yerli server məlumatları üçün).

Power BI Service → dataset üzərinə klikləyin → Settings → Scheduled Refresh → günaşırı, hər gün, saatlıq kimi periodluğu seçin.

8.3 Row-Level Security (RLS)

Şirkətin müxtəlif region menecerlərinin yalnız öz regionlarının məlumatını görməsi lazımdırsa, Row-Level Security (RLS) qurun. Bunun üçün:

1. Modeling tab → Manage Roles klikləyin
2. Create → rol adı daxil edin (məsələn, ‘North Region Manager’)
3. Dim_Region cədvəlinə DAX filter tətbiq edin: [RegionName] = “North”
4. Sonra Power BI Service-də həmin rola istifadəçilər əlavə edin

Bölmə 9 — Praktik Məsləhətlər & Ümumi Səhvlər

9.1 Ən Çox Edilən Səhvlər

9.2 Performance — Sürəti Artırmaq Üçün

• Calculated Column-lardan mümkün qədər qaçın — bu sütunlar yaddaşı doldurur. Çox vaxt Measure ilə eyni nəticəyə nail olmaq mümkündür.
• Power Query-də lazımsız sütunları yükləməzdən əvvəl silin — sütun sayı azaldıqca model sürəti artır.
• Çox böyük string sütunlarını (açıqlamalar, uzun textlər) modeldən çıxarın — bunlar yaddaşda böyük yer tutur.
• Report-u yayımlamadan əvvəl View → Performance Analyzer ilə hər vizualın yüklənmə müddətini ölçün.
• DAX Studio-dan (pulsuz xarici alət) istifadə edərək yavaş measure-ları profil edin.

9.3 Klaviatura Qısayolları

Xülasə — Bütün Mərhələlər

Qubanın təmiz havası, 130 yaradıcı gənc, 29 komanda və fasiləsiz 48 saatlıq gərgin iş… “Urban Hackathon 2026” sadəcə bir yarışma deyil, həm də şəhərlərimizin gələcəyini daha dayanıqlı və rəqəmsal etmək üçün atılan mühüm bir addım idi. Azərbaycan Respublikasının Gənclər və İdman Nazirliyi, “Bir Könüllü” Tələbələrin Əməkdaşlığı İctimai Birliyi və SABAH.Hub-ın dəstəyi ilə keçirilən bu marafonun mərkəzində bizim üçün bir sual dayanırdı: Süni intellekt Bakı Metropolitenində və avtobuslarda sərnişin sıxlığını necə təxmin edə bilər, ictimai nəqliyyatı necə hər kəs üçün daha əlçatan edə bilərik?

Məhz bu sualın cavabı olaraq Kinetix AI layihəsini ərsəyə gətirdik.

Bu yazıda daha çox Bakı metropolitenində sərnişin sıxlığını necə təxmin etmək ola bilər bu suala fokuslanasıyıq, çünki AYNA avtobuslarla, onların gündəlik istifadəsi ilə bağlı hələlik hər hansı bir data paylaşmayıb. Ona görə indilik avtobus dataları ilə işləyə bilmirik.

Hər hansı bir Maşın Öyrənməsi (Machine Learning) modelini ərsəyə gətirmək üçün atılacaq ilk və ən həlledici addım doğru məlumatların tapılması və toplanmasıdır. Necə ki, bir avtomobilin hərəkət etməsi üçün yanacaq lazımdır, ML modellərinin də “öyrənməsi” və doğru qərarlar verə bilməsi üçün keyfiyyətli tarixçəyə (historical data) ehtiyacı var.

Hər hansı bir Maşın Öyrənməsi (Machine Learning) modelini ərsəyə gətirmək üçün atılacaq ilk və ən həlledici addım doğru məlumatların (data) tapılması və toplanmasıdır. Çünki necə ki, bir avtomobilin hərəkət etməsi üçün yanacaq lazımdır, ML modellərinin də “öyrənməsi” və doğru qərarlar verə bilməsi üçün keyfiyyətli tarixçəyə ehtiyacı var.

Bəs bu proses praktikada necə işləyir?

Maşın Öyrənməsi modelləri, əslində, illərin təcrübəsini qısa müddətdə analiz edə bilən yorulmaz bir mütəxəssis kimi davranır. Sistem işə düşdükdə aşağıdakı məntiqi ardıcıllığı izləyir:

• Keçmişdən öyrənmə: Model ilk olaraq əvvəlki aylara və illərə aid böyük həcmli sərnişin məlumatlarını oxuyur. O, bu rəqəmlər arasındakı gizli qanunauyğunluqları, təkrarlanan trendləri və statistik asılılıqları kəşf edir.
• Xüsusiyyətlərin (Features) təhlili: Sıxlıq sadəcə quru rəqəmlərdən ibarət deyil. Model öyrənir ki, həftənin günləri, saatlar, hava şəraiti, bayram və ya iş günləri sərnişin axınına necə təsir göstərir.
• Proqnozlaşdırma: Keçmişin “təcrübəsini” tam mənimsədikdən sonra model artıq bu günə fokuslanır. Mövcud vəziyyəti (hazırkı saatı, günü və s.) dəyərləndirərək, statistik hesablamalar əsasında real zamanlı bir nəticə çıxarır.

Məhz bu zəncirvari prosesin sayəsində sistem yüksək dəqiqliklə təxmin edə bilir ki: “Bu gün, bu saatda, filan stansiyada sərnişin sıxlığı və yüklənmə səviyyəsi necə olacaq?”

Kinetix AI layihəsi üzərində işə başlayarkən ilk və ən vacib addımımız doğru məlumatları (datanı) tapmaq idi. Bakı öz nəqliyyat infrastrukturu, sərnişin yüklənməsi və insanların nəqliyyat vərdişləri baxımından olduqca unikal bir şəhərdir. Buna görə də qlobalda mövcud olan hər hansı standart bir məlumat dəstini (dataset) götürüb layihəmizə tətbiq etmək effektiv olmazdı. Azərbaycan reallığında sərnişinlərin davranış modelini yalnız yerli və real məlumatlar dəqiq əks etdirə bilərdi.

Sırf Bakı Metropoliteninə uyğun məlumat axtarışımız uğurla nəticələndi. Belə ki, İnnovasiya və Rəqəmsal İnkişaf Agentliyinin idarə etdiyi opendata.az (Açıq Məlumatlar Portalı) üzərindən “Bakı Metropoliteni” QSC tərəfindən yerləşdirilmiş rəsmi məlumat dəstini əldə etdik. Bu məlumat dəsti 2025-ci ilin əvvəlindən 2026-cı ilin 1 mart tarixinədək olan dövrdə stansiyalar üzrə gündəlik sərnişin axınını tam əhatə edir.

Məlumatların Təbiəti və Toplanma Metodologiyası

Bəs bu rəqəmlər necə formalaşır və nələri ifadə edir?

Gediş sayları sərnişinlərin metro stansiyalarının giriş turniketlərində etdikləri ödənişlər — həm fiziki kartlar, həm də mobil cihazlar vasitəsilə edilən NFC əsaslı təmassız ödənişlər əsasında qeydə alınır. Lakin burada nəzərə alınmalı vacib bir nüans var: hazırda Bakı Metrosunun çıxış turniketlərində təkrar identifikasiya (kart oxudulması) aparılmır.

Bu səbəbdən, əlimizdəki məlumatlar sərnişinlərin tam səfər zəncirini (A nöqtəsindən B nöqtəsinə getdiyini) deyil, sırf stansiyalar üzrə giriş intensivliyini və formalaşan ilkin yüklənməni göstərir.

Məlumat Dəstinin (Dataset) Texniki Profili:

İstifadə etdiyimiz məlumat dəstinin əsas göstəriciləri bunlardır:

• Əhatə dairəsi: Bakı şəhəri
• İştirakçı / Mənbə: “K Group” MMC (BakıKart)
• Yenilənmə tezliyi: Ayda 1 dəfə
• Məlumatın strukturu (Sütunlar):
• Tarix: Gün.ay.il formatında qeyd olunmuş zaman.
• Stansiya: Bakı Metropoliteninə aid stansiyanın adı.
• Gündəlik gediş sayı: Verilmiş gün ərzində həmin stansiyadan daxil olan sərnişinlərin ümumi sayı.

Məlumatların İşlənməsi və Hazırlıq Mərhələsi (Data Preprocessing)

Uyğun məlumat mənbəyini müəyyən etdikdən sonra qarşımızda duran növbəti əsas məqsəd bu datanın işçi mühitə yüklənməsi, xətaların təmizlənməsi, manipulyasiyası və nəhayət, maşın öyrənməsi modeli üçün tam hazır hala gətirilməsi idi.

Açıq Məlumatlar Portalı məlumatları əldə etmək üçün bizə iki fərqli imkan təklif edirdi: API (Application Programming Interface) vasitəsilə sistemə birbaşa qoşulmaq və ya məlumatları ənənəvi CSV faylı şəklində yükləmək.

API-dən CSV-yə Keçid: Texniki Qərarımız İlkin yanaşma olaraq, məlumat axınını maksimal dərəcədə avtomatlaşdırmaq məqsədilə datanı API vasitəsilə birbaşa portaldan çəkdik və üzərində ilkin əməliyyatlara başladıq. Lakin layihənin daha mürəkkəb mərhələsi olan “Feature Engineering” (yeni xüsusiyyətlərin yaradılması) prosesinə keçdikdə, API-nin dinamik təbiəti bəzi ləngimələr və struktur uyğunsuzluqları yaratmağa başladı.

Modelimizin daha stabil, sürətli və tam nəzarət edilə bilən bir infrastrukturda öyrədilməsini təmin etmək üçün praktik bir addım atdıq. API bağlantısını kənara qoyaraq, datanı statik CSV formatında endirdik. Ardından, prosesi Jupyter Notebook mühitinə daşıyaraq Python-un məlumat analizi alətləri vasitəsilə faylı oxutduq və datanı asanlıqla manipulyasiya edə biləcəyimiz strukturlaşdırılmış bir DataFrame halına gətirdik. Artıq məlumat dəstimiz ən dərin analizlər və modelin qurulması üçün tam etibarlı vəziyyətdə idi.

Məlumatların Təmizlənməsi və Standartlaşdırılması (Data Cleaning)

Məlumatları (dataset) işçi mühitimizə yüklədikdən sonra dərhal model qurmağa keçə bilməzdik. Çünki xam (raw) məlumatlar adətən daxilində xətalar, boşluqlar və fərqli formatlar barındırır. Buna görə də, növbəti mərhələmiz Kinetix AI-ın başa düşəcəyi qüsursuz və standartlaşdırılmış bir struktur yaratmaq oldu.

Yazdığımız xüsusi alqoritm (kod) vasitəsilə bu təmizləmə prosesini bir neçə addımda avtomatlaşdırdıq:

1. Sütun Adlarının Standartlaşdırılması

• Nə etdik? Məlumat dəstindəki sütun adlarındakı böyük-kiçik hərfləri, lazımsız boşluqları və xüsusi simvolları təmizləyərək vahid bir formata (alt xəttli və kiçik hərflərlə) gətirdik. Həmçinin, sistemin sütun adlarını (İngilis və ya Azərbaycan dilində olmasından asılı olmayaraq) avtomatik tanıması üçün xüsusi axtarış məntiqi qurduq.
• Niyə etdik? Gələcəkdə portaldan yeni datalar çəkilərkən sütun adlarında ola biləcək hər hansı format dəyişikliyinin (məsələn, “Gediş Sayı” əvəzinə “gedis sayi” yazılması) sistemimizi çökdürməsinin qarşısını almaq üçün.

2. Data Tiplərinin Doğrulanması (Formatting)

• Nə etdik? Tarix sütununu sistemin anlaya biləcəyi rəsmi datetime (zaman) formatına çevirdik. Stansiya adlarının ətrafındakı görünməyən boşluqları kəsib atdıq. Sərnişin sayını isə sırf riyazi əməliyyatlar aparıla bilməsi üçün ədədi (numeric) formata keçirdik.
• Niyə etdik? Maşın öyrənməsi modelləri riyazi məntiqə əsaslanır. Tarixin mətn kimi yox, zaman kimi, sərnişin sayının isə sırf rəqəm kimi oxunması zaman oxu (time-series) üzrə analizlər aparmaq üçün ən vacib şərtdir.

3. Boşluqların Ağıllı Bərpası (Linear Interpolation)

• Nə etdik? Məlumatları əvvəlcə stansiyalar və tarixlər üzrə xronoloji ardıcıllıqla sıraladıq. Daha sonra əgər hər hansı bir stansiyada hansısa gün üzrə məlumat qeydə alınmayıbsa (boşluq varsa), bu boşluğu “Xətti İnterpolyasiya” (Linear Interpolation) metodu ilə doldurduq.
• Niyə etdik? Boş (NaN) dəyərlər süni intellekt modellərinin ən böyük düşmənidir və hesablamanı pozur. İnterpolyasiya vasitəsilə boş qalan günü sıfırla doldurmaq və ya silmək əvəzinə, sistemə həmin gündən əvvəlki və sonrakı günlərin sərnişin sayına baxaraq ən məntiqi rəqəmi riyazi olaraq təxmin edib yerinə yazmağı öyrətdik. Bu, datanın ümumi trendinin pozulmasının qarşısını aldı.

Nəticə etibarilə, bu təmizləmə əməliyyatından sonra əlimizdə Kinetix AI-ın öyrənmə prosesi (model training) və yeni xüsusiyyətlərin çıxarılması (feature engineering) üçün tam hazır, xətasız və riyazi cəhətdən dayanıqlı bir Dataframe formalaşdı.

Exploratory Data Analysis (EDA)

1. Məlumatların Strukturlaşdırılması (Canonicalization)

Kodun ilk hissəsində biz fərqli mənbələrdən gələ biləcək sütun adlarını (məsələn: “tarix”, “date”, “stansiya”, “station”) vahid bir formata gətirdik.

• Nə etdik? column_map vasitəsilə sütunları date, station_name və passenger_count olaraq standartlaşdırdıq.
• Niyə etdik? Kodun universal olması üçün. Datasetin sütun adları dəyişsə belə, bu məntiq onları tanıyır və analizi davam etdirir. Həmçinin, hour_of_day, day_name və month kimi yeni temporal sütunlar yaradaraq datanı daha detallı analiz üçün hazırladıq.

2. Basic Data Profiling (Statistik Xülasə)

Çıxışdakı statistik rəqəmlər bizə Bakı metrosunun ümumi mənzərəsini göstərir:

• Mean (23,014): Orta hesabla hər stansiyadan gündəlik 23 min sərnişin keçir.
• Max (77,392): Ən pik nöqtədə bir stansiyadan gün ərzində 77 mindən çox sərnişin daxil olub.
• Outlier Check: IQR (Interquartile Range) metodu ilə anomal sıçrayışları yoxladıq. Nəticədə 109 minlik limitdən yuxarı heç bir kəskin anomal sıçrayış tapılmadı, bu da datanın real və etibarlı olduğunu göstərir.

Bu iki qrafik sərnişin axınının həftəlik və aylıq ritmini izah edir.

• Sol tərəf (Day of Week): Ən çox yüklənmə Çərşənbə axşamı (Tuesday) müşahidə olunur. Bazar günü (Sunday) isə sərnişin sayı kəskin şəkildə azalır (təxminən 25 mindən 15 minə düşür).
• Sağ tərəf (Month): Oktyabr və Dekabr ayları ən gərgin aylardır. Avqust ayı isə ilin ən sakin ayıdır. Bu məlumat modelin seasonality trendlərini öyrənməsi üçün təməl bazadır.

Bu qrafik stansiyalar arasındakı “güc nisbətini” göstərir.

• Top 10 Busiest: Koroğlu, 28 May və 20 Yanvar stansiyaları şəhərin əsas yüklənmə mərkəzləridir. Koroğlu stansiyası gündəlik 55 min+ sərnişinlə liderdir.
• Bottom 10 Least Busy: Memar Əcəmi-2 və Bakmil stansiyaları ən az giriş edilən stansiyalardır.
• Məntiq: Bu fərqlilik modelə hər stansiya üçün fərdi çəki dərəcəsi (weight) təyin etməyə imkan verir.

1. Monthly Usage Trend (Yuxarı Sol: Bar Chart)

Bu qrafik metronun il ərzindəki makro-ritmini göstərir.

• Nəyi göstərir: Hər ay üzrə cəmi sərnişin sayını.
• Analiz: Qrafikdə “Summer Drop” (Yay düşüşü) və “Winter Peaks” (Qış zirvələri) aydın görünür. İyun, İyul və Avqust aylarında sərnişin sayı minimuma düşür. Bu, dərslərin bitməsi, insanların məzuniyyətə getməsi və şəhərin boşalması ilə izah olunur.
• Nəticə: Sentyabr ayından etibarən başlayan kəskin artım Academic Season (təhsil mövsümü) faktorunun model üçün nə dərəcədə həlledici olduğunu sübut edir.

2. Day of Week Usage (Yuxarı Sağ: Box Plot)

Bu qrafik həftənin günləri üzrə sərnişin paylanmasını və məlumatın variance (dəyişkənlik) dərəcəsini göstərir.

• Nəyi göstərir: Hər gün üzrə sərnişin sayının medianını, kvartillərini və kənar sapmalarını (outliers).
• Analiz: İş günləri (Bazar ertəsi — Cuma) bir-birinə çox yaxın və yüksək yüklənmə ilə xarakterizə olunur. Lakin Şənbə və xüsusilə Bazar günü sərnişin sayı kəskin aşağı düşür.
• Nəticə: Qrafikdəki “qutuların” (boxes) ölçüsü bizə göstərir ki, iş günlərində sərnişin axını daha stabil və proqnozlaşdırıla biləndir, həftəsonları isə bir az daha fərqli (müxtəlif) ola bilir.

3. Average Passenger Density: Month vs. Day of Week (Aşağı Sol: Heatmap)

Bu layihənin ən granular (detallı) vizuallaşdırmasıdır.

• Nəyi göstərir: Ayların və həftənin günlərinin kəsişməsində orta sərnişin sayını.
• Analiz: Rəng nə qədər tünd qırmızıdırsa, sıxlıq bir o qədər yüksəkdir. Göründüyü kimi, Dekabr və Noyabr aylarının iş günləri (təqvim üzrə 11 və 12-ci aylar) sistemin ən pik nöqtələridir (təxminən 30,000+ sərnişin/stansiya).
• Nəticə: Bu Heatmap bizə imkan verir ki, ilin hansı spesifik günlərində metronun ən yüksək təzyiq altında olduğunu dəqiq müəyyən edək. Məsələn, Avqust ayının Bazar günü ilin ən sakin vaxtıdır.

4. Anomaly Detection: Total Daily Passengers (Aşağı Sağ: Time-Series Line Chart)

Bu qrafik sistemin “sağlamlıq yoxlamasıdır”.

• Nəyi göstərir: Gündəlik sərnişin sayını, 7 günlük sürüşən ortalamanı (7-Day Rolling Avg) və Z-score əsaslı anomaliyaları.
• Analiz: Göy xətt kəskin dalğalanmaları, qırmızı qırıq xətt isə ümumi trendi göstərir. Qırmızı nöqtələr isə Z-score >= 2.5 olan günləri, yəni statistik olaraq gözlənilməz, qeyri-adi dərəcədə yüksək və ya aşağı sərnişin axını olan günləri işarələyir.
• Nəticə: Bu anomaliyalar adətən fövqəladə hallar, kütləvi tədbirlər və ya bayram tətilləri ilə üst-üstə düşür. Bu, Kinetix AI modelinə öyrədir ki, hansı günləri “normal” qəbul etməli, hansılarını isə “istisna” (special case) kimi dəyərləndirməlidir.

Yekun Nəticə

Bu EDA mərhələsi bizə sübut etdi ki, Bakı metrosunun datası həm temporal (zamanla bağlı), həm də spatial (stansiya ilə bağlı) çox güclü qanunauyğunluqlara malikdir. Biz artıq bilirik ki:

1. Yay və təhsil mövsümü arasındakı fərq kəskindir.
2. Bazar günü tamamilə fərqli bir rejimdir.
3. Koroğlu və 28 May kimi stansiyalar model üçün prioritetdir.

İndi biz tam əminliklə növbəti mərhələyə Feature Engineering və Model Training hissəsinə keçə bilərik, çünki datanın bizə nə demək istədiyini artıq vizual olaraq başa düşmüşük.

Feature Engineering

Təmizlənmiş data modelin işləməsi üçün yetərli olsa da, yüksək dəqiqlik (accuracy) əldə etmək üçün kifayət deyildi. Süni intellektə sərnişinlərin davranış modelini, şəhərin ritmini və təkrarlanan vərdişləri başa salmaq lazım idi. Bu məqsədlə xüsusi bir KinetixFeatureEngineer alqoritmi (sinfi) yazaraq datamızı aşağıdakı məntiqi amillərlə zənginləşdirdik:

1. Zaman və Təqvim Xüsusiyyətlərinin Çıxarılması (Temporal Features)

• Nə etdik? Sadə “Tarix” sütununu parçalayaraq yeni sütunlar yaratdıq: həftənin hansı günüdür, ayın neçəsidir, iş günüdür yoxsa həftəsonu.
• Niyə etdik? Çünki Bakı metrosunda bazar ertəsi səhər saatlarındakı axınla bazar gününün axını tamamilə fərqlidir. Model bu fərqi artıq riyazi olaraq görə bilir.

2. Yerli Kontekst və Təhsil Mövsümü (Local Context)

• Nə etdik? Kodun içinə xüsusi olaraq Azərbaycandakı rəsmi qeyri-iş günlərini (Novruz tətili, Yeni il və s.) və ölkəmizin akademik təqvimini (payız və yaz semestrləri) daxil etdik.
• Niyə etdik? Sərnişin axınının böyük bir qismi tələbələrdən ibarətdir. Modelin tətildə olan günlərlə dərs günlərini ayırd etməsi qəfil sıxlıq düşüşlərini və ya artışlarını doğru təxmin etməsi üçün kritik əhəmiyyət daşıyır.

3. Stansiyaların Xarakteristikası (Station Typology)

• Nə etdik? Bütün stansiyaları eyni tərəziyə qoymadıq. Alqoritmə öyrətdik ki, “28 May” və ya “Memar Əcəmi” tranzit/keçid (transfer hub), “Elmlər Akademiyası” və “Gənclik” isə tələbə mərkəzli (student hub) stansiyalardır.
• Niyə etdik? Bu təsnifat modelə hər stansiyanın spesifik yüklənmə səbəbini anlamağa və fərdi ssenarilər qurmağa kömək edir.

4. Keçmişin Yaddaşı və Gecikmə Xüsusiyyətləri (Lag & Rolling Features)

• Nə etdik? Ən vacib ML gedişlərimizdən birini edərək “Zaman Sıraları” (Time-Series) məntiqini tətbiq etdik. Modelə hər gün üçün 3 yeni sualın cavabını əlavə etdik:
• Dünən eyni vaxtda sərnişin sayı nə qədər idi? (lag_1_day)
• Düz 1 həftə əvvəl eyni gündə vəziyyət necə idi? (lag_7_days)
• Son 3 günün orta axın trendi nədir? (rolling_mean_3_days)
• Niyə etdik? Süni intellekt bu “keçmişə baxış” rəqəmlərini oxuyaraq bugünkü sərnişin sayını daha inamla proqnozlaşdırır. Məsələn, əgər son 3 gündə artım trendi varsa, model bugünü də o trendə uyğun hesablayır.

5. Maşın Dili üçün Rəqəmsallaşdırma (Encoding)

• Nə etdik? Modellər hərfləri və sözləri deyil, rəqəmləri anlayır. Ona görə də stansiya adlarını xüsusi kodlaşdırma (One-hot encoding) vasitəsilə sıfır və birlərdən (0, 1) ibarət riyazi matrislərə çevirdik.

Yekun Nəticə: Bu prosesin sonunda bizim əlimizdə sadəcə “Tarix” və “Gediş Sayı” olan kasıb bir cədvəl yox, Kinetix AI-ın hər bir sərnişinin addımını və şəhərin nəbzi ilə ayaqlaşan qaydalarını anlaya biləcəyi 14 fərqli xüsusiyyətdən ibarət çox zəngin bir “Öyrənmə Matrisi” (Feature Matrix) formalaşdı.

Chronological Train-Test Split

Süni intellekt modelinin (Kinetix AI) öyrənmə prosesinə başlamazdan əvvəl, əlimizdəki zənginləşdirilmiş məlumat dəstini iki hissəyə ayırmalı idik: Modelin keçmiş təcrübələrdən “öyrənməsi” üçün Təlim (Train) və öyrəndiklərini gələcək üzərində sınaması üçün Test məlumatları.

Bu mərhələdə standart təsadüfi bölünmə (random split) yerinə, sırf zaman ardıcıllığına əsaslanan çox qəti bir xronoloji bölünmə (Strict Chronological Split) arxitekturası qurduq:

1. Qəti Zaman Sıralaması (Strict Temporal Sorting)

• Nə etdik? Bütün məlumatları ilk gündən son günə (və saata) qədər xronoloji ardıcıllıqla düzdük.
• Niyə etdik? Zaman sıralı (Time-series) məlumatlarda keçmiş gələcəyə təsir edir. Məlumatların qarışmaması və ardıcıllığın qorunması sistemin düzgün trend tutması üçün şərtdir.

2. Hədəfin və Öyrənmə Matrisinin Ayrılması (Target & Feature Matrix)

• Nə etdik? Təxmin etmək istədiyimiz əsas hədəfi — sərnişin sayını (y) sistemdən ayırdıq. Yerdə qalan bütün məlumatlardan isə modelin riyazi olaraq anlaya bilməyəcəyi mətn tipli sütunları (orijinal tarix, stansiya adları) sildik və yalnız əvvəlki mərhələdə hazırladığımız rəqəmsal xüsusiyyətləri (X) saxladıq.
• Niyə etdik? Modelə “cavabı” (y) və "ipuçlarını" (X) ayrı-ayrı verməliyik ki, o, ipuçlarına baxaraq cavabı tapmağı öyrənsin. Həmçinin, alqoritmlər yalnız rəqəmlərlə işlədiyi üçün təmizlənmiş bir "riyazi matris" formalaşdırmaq məcburidir.

3. Xronoloji 80/20 Bölünməsi (Index-Based Splitting)

• Nə etdik? Məlumatları təsadüfi olaraq deyil, indeks (zaman) oxu üzrə kəsdik. İlk 80%-lik xronoloji hissəni modelin öyrənməsi (Train), son 20%-lik hissəni (gələcəyi) isə modelin imtahan edilməsi (Test) üçün ayırdıq.
• Niyə etdik? (Data Leakage-in qarşısının alınması): Əgər datanı təsadüfi bölsəydik, model gələcəkdəki bir hadisənin məlumatını alıb keçmişi proqnozlaşdırmaq üçün istifadə edə bilərdi. Buna Data Science-da “Məlumat sızması” (Data Leakage) deyilir. Xronoloji bölünmə ilə biz modelin qətiyyən “gələcəyə baxmasının” qarşısını aldıq. Kinetix AI yalnız keçmişi görərək gələcəyi təxmin etməyə məcbur edildi.

4. Validasiya və Yoxlanış (Validation Check)

• Nə etdik? Kodun sonuna xüsusi bir yoxlanış bloku əlavə etdik. Bu blok Təlim məlumatlarının bitdiyi tarixlə Test məlumatlarının başladığı tarixi müqayisə edərək aralarında heç bir kəsişmənin olmadığını (Strict non-overlap check) təsdiqlədi.

Yekun Nəticə: Artıq əlimizdə tam təhlükəsiz, zaman məntiqinə zidd olmayan, gələcəyə sızma ehtimalı sıfıra endirilmiş mükəmməl bir öyrənmə mühiti (Train) və görünməz sınaq mühiti (Test) var. Model artıq öyrədilməyə (Training) tam hazırdır.

Model Selection — Why XGBoost?

Preprocessing və Feature Engineering mərhələlərindən sonra qarşımızda duran ən kritik sual bu idi: Hansı alqoritm Bakı metrosunun bu mürəkkəb sərnişin axınını ən dəqiq şəkildə proqnozlaşdıra bilər? Müxtəlif klassik və müasir yanaşmaları analiz etdikdən sonra XGBoost (Extreme Gradient Boosting) modelini seçdik. Bu seçimin arxasında duran əsas səbəblər bunlardır:

1. Handling Non-linear Relationships Bakı metrosundakı sərnişin sıxlığı sadə, xətti bir artımla baş vermir. Məsələn, “Yağışlı hava + Monday + Academic Season” kombinasiyası sərnişin sayına qeyri-adi dərəcədə təsir edə bilər. XGBoost bu cür mürəkkəb və bir-biri ilə kəsişən faktorlar arasındakı non-linear əlaqələri tutmaqda dünyada ən uğurlu alqoritmlərdən biri hesab olunur.

2. Robust Performance for Time-Series Data XGBoost, bizim hazırladığımız lag features və rolling means xüsusiyyətlərini çox effektiv emal edir. O, keçmişdəki trendləri (məsələn, lag_7_days) indiki zamanla müqayisə edərək proqnozlarını maksimum dərəcədə stabilləşdirir.

3. Protection Against Overfitting Zəif modellər çox vaxt keçmiş məlumatları sadəcə “əzbərləyir” və yeni, görülməmiş məlumatlarda səhv proqnozlar verir. XGBoost isə daxili Regularization (L1 və L2) mexanizmləri sayəsində datanı əzbərləmir, onun məntiqini öyrənir. Bu da Kinetix AI-ın real dünyada, yəni test set üzərində daha stabil nəticələr göstərməsini təmin edir.

4. Speed and Resource Efficiency Metrodakı real-time sıxlıq proqnozları saniyələr içində hesablanmalıdır. XGBoost həm training, həm də inference sürətinə görə rəqib alqoritmlərdən (məsələn, Random Forest və ya Deep Learning modellərindən) qat-qat sürətlidir. Bu da tətbiqimizin gələcəkdə “real-time” işləməsi üçün bizə böyük üstünlük qazandırır.

5. Model Interpretability (Feature Importance) XGBoost-un bizə təqdim etdiyi ən böyük üstünlük şəffaflıqdır. Feature Importance analizi vasitəsilə o, bizə proqnoz verərkən hansı faktorun (məsələn, həftənin günü, yoxsa keçən həftəki sərnişin sayı) daha çox rol oynadığını göstərir. Bu, Kinetix AI-ın sadəcə bir “black box” deyil, hər qərarını izah edə bilən ağıllı bir sistem olmasını təmin edir.

Yekun Nəticə: XGBoost seçimi ilə biz Kinetix AI-ın həm accuracy, həm sürət, həm də reliability göstəricilərini sığortalamış olduq. Bu model Bakı metrosunun mürəkkəb sərnişin xəritəsini rəqəmlərlə oxuyan ən peşəkar analitik mexanizmdir.

(Burada bir şey qeyd edə bilərəm ki, Kinetix AI həmçinin anlıq hava haqqında proqnoza da baxaraq, hansı günlərdə, hansı hava şəraitlərində ictimai nəqliyyatda sıxlığın necə olduğunu predict edə bilsin)

Model Training & Intelligence Optimization

Hazırladığımız bütün datanı XGBoost modelinə təqdim etdik və ona Bakı metrosu üçün ən doğru təxminləri necə verəcəyini öyrətdik. Bu proses sadəcə bir düyməyə basmaq deyildi; biz modelin hər bir addımını, yəni Hyperparameter Configuration hissəsini xüsusi bir strategiya ilə qurduq:

1. “Tələsmədən Öyrən” Strategiyası (Learning Rate & Estimators)

Modelə 1000 fərqli qərar vermə imkanı (n_estimators=1000) tanıdıq, lakin ona bir tapşırıq verdik: “Hər bir addımda çox kiçik öyrənmə sürəti ilə hərəkət et (learning_rate=0.05)”.

• Niyə? Çünki süni intellekt tələsdikdə məlumatdakı təsadüfi “küy”ləri (noise) əsl trendlərlə qarışdırır. Kiçik addımlarla öyrənmək modelin daha dərindən düşünməsinə və sərnişin axınındakı incə detalları (məsələn, yağışlı bir bazar ertəsi ilə günəşli bir bazar ertəsi arasındakı fərqi) daha yaxşı tutmasına kömək edir.

2. Dərinlik və Sabitlik Balansı (Complexity Control)

Hər bir qərar ağacının dərinliyini 6 səviyyə ilə məhdudlaşdırdıq (max_depth=6). Eyni zamanda, modelə hər dəfə öyrənərkən məlumatın və xüsusiyyətlərin yalnız 80%-ni görməyə icazə verdik (subsample & colsample_bytree = 0.8).

• Nəticə: Bu, modelin “əzbərçi” olmasının qarşısını alır. O, eyni şeyi təkrar-təkrar görmək əvəzinə, fərqli ssenarilərə baxa-baxa daha dayanıqlı (Robust) bir məntiq inkişaf etdirir. Biz buna Data Science dilində Overfittingdən qorunmaq deyirik.

3. Early Stopping: Modelin “Pik” Nöqtəsini Tapmaq

Layihənin ən “ağıllı” addımlarından biri early_stopping_rounds=50 əmrini vermək oldu.

• Necə işlədi? Model öyrənməyə başladı və hər addımda özünü həm Train Set, həm də daha öncə görmədiyi Validation Set üzərində test etdi. O gördü ki, 116-cı addımdan (best_iteration=116) sonra artıq yeni bir şey öyrənmir, əksinə, datanı əzbərləməyə başlayaraq xəta payını artırır.
• Qərar: Sistem özü avtomatik olaraq orada dayandı. Bu, bizə həm zaman qənaəti təmin etdi, həm də modelin real həyatda səhv etmə ehtimalını minimuma endirdi.

4. Uğur Göstəricisi: 2,331 RMSE Nəyi İfadə Edir?

Nəticədə əldə etdiyimiz 2,331 RMSE (Root Mean Squared Error) skoru modelimizin “imtahan qiyməti”dir.

• Bu rəqəm bizə deyir ki, Kinetix AI hər bir stansiya üzrə minlərlə sərnişin axınını təxmin edərkən orta hesabla cəmi 2,331 nəfərlik bir sapma ilə işləyir.
• Metronun ümumi sərnişin həcmini nəzərə alsaq, bu, modelin olduqca yüksək dəqiqliklə (Accuracy) Bakı metrosunun nəbzini tutduğunu sübut edir.

Model artıq təkcə öyrədilməyib, həm də öz imtahanından uğurla keçib. Cəmi 1934 fərqli ssenari üçün proqnozlar (Predictions) artıq hazırdır. Kinetix AI artıq sadə bir proqram deyil, Bakı metrosundakı sərnişin sıxlığını saatlar, günlər öncədən hiss edə bilən peşəkar bir “analitik”dir.

Model Evaluation & Performance Analytics

1. Evaluation Metrics:

Modelin performansını ölçmək üçün istifadə etdiyimiz üç əsas metrik Kinetix AI-ın nə dərəcədə etibarlı olduğunu göstərir:

• MAE (Mean Absolute Error) — 1,170.431: Bu göstərici proqnozlaşdırılan sərnişin sayı ilə real sərnişin sayı arasındakı orta mütləq fərqi ifadə edir. Bakı metrosunun bəzi stansiyalarında gündəlik gediş sayının 60,000-dən çox olduğunu nəzərə alsaq, orta hesabla cəmi 1,170 sərnişin yanılma payı modelin High Precision (yüksək dəqiqlik) ilə işlədiyini sübut edir.
• RMSE (Root Mean Squared Error) — 2,331.786: RMSE böyük xətaları daha ağır cəzalandıran bir metrikdir. RMSE-nin MAE-dən yüksək olması o deməkdir ki, bəzi spesifik saatlarda (məsələn, gözlənilməz pik saatlarda) xəta payı ortalamadan bir qədər yüksək ola bilir. Lakin bu rəqəmin 2,300 ətrafında sabitlənməsi modelin Overfitting (əzbərləmə) etmədiyini və Generalization qabiliyyətinin yüksək olduğunu göstərir.
• R² (R-Squared) — 0.9859: Bu, modelin ən uğurlu göstəricisidir. 0.9859 o deməkdir ki, Bakı metrosundakı sərnişin axınındakı dəyişkənliyin (Variance) 98.6%-i Kinetix AI tərəfindən tam dəqiqliklə izah olunur. Bu, zaman sıraları proqnozlaşdırılmasında çox nadir və yüksək nəticə hesab olunur.

2. Feature Importance:

Bu qrafik bizə modelin sərnişin sayını təxmin edərkən hansı faktorlara üstünlük verdiyini göstərir:

• Əsas Faktor (rolling_mean_3_days): Model sərnişin sayını müəyyən edərkən 36.1% payla ən çox son 3 günün ortalama trendinə güvənir. Bu, sistemin qısamüddətli dinamikaya dərhal uyğunlaşdığını göstərir.
• Mövsümi Təsir (lag_7_days): 17.3% payla ikinci yerdə keçən həftənin eyni gününün göstəricisi gəlir. Bu, modelin həftəlik Seasonality (mövsümilik) trendini çox güclü şəkildə mənimsədiyini sübut edir.
• Spesifik Stansiya Təsiri (station_28_May): Maraqlıdır ki, “28 May” stansiyası özlüyündə bir faktor kimi 16.3% əhəmiyyət kəsb edir. Bu, modelin şəhərin mərkəzi tranzit qovşağındakı (Transfer Hub) spesifik yüklənmə modelini digər stansiyalardan fərqləndirdiyini göstərir.
• Local Context: Bayram günləri (is_holiday_az) və akademik mövsümün (is_academic_season) də modelin qərarlarına birbaşa təsir etməsi Kinetix AI-ın yerli reallıqları nəzərə alan bir Context-Aware model olduğunu təsdiqləyir.

3. Actual vs. Predicted:

Bu qrafik modelin real həyatdakı sınağını vizual olaraq əks etdirir:

• Göy (Actual) və narıncı (Predicted) xətlər demək olar ki, sinxron hərəkət edir. Model sərnişin sayındakı kəskin artışları (peaks) və azalma nöqtələrini (troughs) tam vaxtında tutur.
• Trend Analizi: Diqqət etsəniz, model hətta kəskin sıçrayışların baş verdiyi günlərdə belə trayektoriyanı itirmir. Bu, modelin Time-Series Alignment (zaman sırası düzləndirilməsi) məsələsini mükəmməl həll etdiyini və real-time rejimdə işləməyə hazır olduğunu göstərir.

4. Residual Analysis: Xətaların Paylanması

Xətaların analizi (Residuals Analysis) modelin “sağlamlığını” yoxlamaq üçün ən texniki üsuldur:

• Normal Distribution: Xətaların paylanması qrafiki tam bir “zəngvari” (Bell Curve) forma yaradır və mərkəzi “0” nöqtəsindədir.
• Unbiased Prediction: Xətaların mərkəzinin 0-da olması modelin Unbiased (qərəzsiz) olduğunu sübut edir. Yəni model nəticələri sistematik olaraq nə yuxarı, nə də aşağı yuvarlaqlaşdırmır; səhvlər tamamilə təsadüfidir və minimaldır.
• Error Density: Xətaların böyük əksəriyyətinin -2500 ilə +2500 aralığında sıxlaşması (minlərlə sərnişin axını daxilində) sistemin stabil işlədiyini təsdiq edir.

Bu texniki analizlər sübut edir ki, Kinetix AI artıq sadəcə bir proqnozlaşdırma aləti deyil, Bakı metrosunun sərnişin axınını 98.6% dəqiqliklə anlayan və təsvir edən güclü bir Analitik İnfrastrukturdur.

Növbəti mərhələdə bu proqnozları stansiya tutumları (Station Capacity) ilə kəsişdirərək, sərnişinlər üçün real-zamanlı “Sıxlıq Xəritəsi” (Density Heatmap) və “Komfort Səviyyəsi” (Comfort Band) hesabatlarını hazırlamağa tam hazırıq.

Bunlara baxın:

1. https://www.kaggle.com/models/qurbanlifeyzullayev/baku-metro-passenger-flow-forecasting-model
2. https://github.com/qurbaneliii/kinetix-flow/blob/main/Kinextix_AI_baku_metro.ipynb
3. https://opendata.az/en/@baki-metropoliteni/stansiyalar-uzre-gundelik-sernisin-gedislerinin-sayi
4. https://github.com/qurbaneliii/kinetix-flow
5. https://github.com/telebehub/kinetix
6. https://github.com/qurbaneliii

Of course, Copilot’s lineup isn’t only Claude. It also includes models like GPT-5, GPT-5.1, GPT-5.2, and even older options such as GPT-4.1, and I’ve used them on and off as well. But if I’m being honest, GPT inside Copilot never fully matched my expectations. I assumed it wasn’t a “the model is bad” problem it felt more like an implementation and integration problem.

An unexpected discovery

Today, I ran into something I didn’t expect. I installed the ChatGPT Codex extension for VS Code (available to ChatGPT Plus subscribers) and gave it a real test. At first, it looked ordinary: same GPT models, same VS Code environment, same kinds of tasks. Then the results hit differently.

Even though the GPT models I used in Copilot and the ones I selected in ChatGPT Codex were, on paper, the same, the performance gap was obvious. This wasn’t a tiny nuance. Codex’s GPT output was consistently, noticeably better than what I was getting from Copilot.

Quick experiment: Same prompt, same model, different result

I didn’t want to overreact to a one-off impression, so I ran a small experiment. I tested the same coding problem, the same prompt, and the same GPT model (GPT-5) on both platforms. The results were more interesting than I expected.

Test setup

• Same task: building a complex pandas data transformation + visualization pipeline in a Data Science context
• Same prompt: clear instructions and the same context
• Same model: GPT-5
• Different platforms: GitHub Copilot vs ChatGPT Codex

In GitHub Copilot, the solution leaned generic more like a template and sometimes drifted away from my actual context. The pandas operations it suggested were basic, and they didn’t line up cleanly with my dataset’s structure. ChatGPT Codex, on the other hand, produced code that felt more tailored, more optimized, and more aligned with how I’d actually use it in a data science workflow. Code quality, data-handling best practices, error handling, and even the style (matching a Jupyter notebook flow) were clearly stronger in Codex.

That pushed me to dig deeper and do a bit of investigation.

So what’s driving the performance gap?

Here are the main differences I ended up focusing on:

Model optimization and fine-tuning: It’s plausible that OpenAI tunes or configures models inside ChatGPT Codex more specifically for coding. In Copilot, the same models may be set up in a more general way. Because Codex runs inside OpenAI’s own product stack, they likely have more direct control over how the model behaves end-to-end.

API implementation and system architecture: The two platforms may differ in how they reach and run the model. Codex is part of OpenAI’s ecosystem, so it can interact with the model in a more “native” way. Copilot, operating inside Microsoft’s infrastructure, can introduce extra layers latency, routing, transformations; that can subtly affect how prompts and context are processed. Those layers can also introduce small context losses or prompt reshaping.

Context window and token management: One detail that stood out is context handling. Codex seems to manage context in a smarter way for understanding code and intent open files, project structure, and potentially even repo-level signals can be packaged more effectively. In Copilot, similar signals may reach the model in a more limited or compressed form.

Prompt engineering and system instructions: This may be the most important factor. The system-level instructions behind Codex appear geared specifically for coding: fewer hallucinations, better adherence to conventions, and stronger error handling. Inside Copilot, GPT may be operating under more general instructions, which can lead to more generic output.

Response behavior and caching: The way responses are produced and reused can matter. If Codex uses more aggressive or smarter caching and retrieval for similar contexts, it can improve perceived consistency and quality. Copilot’s approach may be more conservative.

Model versioning and deployment: Even under the same model name (for example, GPT-5.2), there can be different deployed variants. OpenAI may ship the freshest, most optimized deployments to Codex first. Copilot, due to partnership constraints and additional safety/compliance requirements, could sometimes be a step behind or run a slightly adjusted build.

Practical takeaways

My main conclusion is this: the same AI model can behave very differently across platforms, and the gap isn’t just “small implementation details” — it can come from the full stack.

A few lessons I’m taking with me:

Platform–model fit matters: Choosing the model matters, but how and where that model is deployed matters even more. When OpenAI runs its own models inside its own environment, it naturally has an advantage; technically and product-wise.

Abstraction layers have a cost: Copilot’s extra layers don’t just affect latency. They can influence context delivery, prompt shaping, and overall model behavior. Even if those layers are invisible, they show up in the output.

Why Claude feels so strong in Copilot: This experience also made one thing clearer: Claude’s success inside Copilot likely isn’t random. It may reflect stronger optimization between Anthropic and Microsoft or simply that Claude is more robust in this kind of IDE workflow.

After seeing these results, I’m going to lean even harder into a hybrid setup.

Recommendations

This isn’t just “which tool is better?” It’s a strategy question.

My current approach

• GitHub Copilot + Claude for my main workflow: the Microsoft ecosystem experience, GitHub integration, and Claude’s reliable code quality. For refactoring, architectural decisions, and complex problem solving, Claude is hard to replace.
• ChatGPT Codex + GPT-5/5.1 for specific situations: tasks where OpenAI models shine, experimental work, or very fast prototyping — Codex feels like the most natural home for GPT in those moments.

Practical advice for other developers

• Prefer “native” pairings when possible: OpenAI models on OpenAI’s platform; Claude in Copilot or directly via Claude.ai.
• Test the same model across platforms. Simple experiments can reveal surprising gaps. In practice, what looks best “on paper” often behaves differently in real workflows.
• Pay attention to context management. Understand what your tool actually sends: open files, project structure, workspace settings — all of it can shift output quality.
• Factor in tool-switching overhead. Switching costs time and mental energy. Sometimes 80% solved in one place beats switching; other times switching is worth it to land the full 100%.

Looking ahead
This space is moving fast, and these gaps may change. Copilot may improve GPT integration, and new model architectures will keep showing up.

Personally, I don’t think the future is one monolithic coding assistant. I think it’s smart orchestration systems that combine multiple models and select the right one based on context.

Conclusion

When choosing AI coding tools, “which model is stronger?” is not the whole question. In the real world, the equation looks more like this:

Model + Platform + Implementation = Performance

This experience showed me that even with the same prompt and the same model, outcomes can differ sharply between platforms. The stronger results I saw from GPT inside ChatGPT Codex compared to “the same GPT” inside Copilot suggest that invisible factors system architecture, prompt design, context management, and deployment strategy matter a lot.

My advice is simple: don’t get stuck on a single viewpoint. Instead of committing blindly to one tool or model, run small experiments in your real workflow, compare results, and stick with what actually performs best for you. Sometimes the best answer isn’t the most powerful model it’s the platform where that model is integrated and optimized the best.

As developers, our job isn’t only to write code. It’s also to choose the right tools, configure them well, and squeeze real value out of them. Tech is full of things that look great in a chart but behave differently in practice. That’s why the most reliable benchmark isn’t marketing or comparison tables, it’s real testing, real usage, and real experience.

References:

1. Supported AI models in GitHub Copilot — https://docs.github.com/copilot/reference/ai-models/supported-models
2. About Copilot auto model selection — https://docs.github.com/copilot/concepts/auto-model-selection
3. Changing the AI model for GitHub Copilot Chat — https://docs.github.com/en/copilot/how-tos/use-ai-models/change-the-chat-model
4. AI model comparison (Copilot) — https://docs.github.com/en/copilot/reference/ai-models/model-comparison
5. Hosting of models for GitHub Copilot Chat — https://docs.github.com/en/copilot/reference/ai-models/model-hosting
6. Provide context to GitHub Copilot — https://docs.github.com/en/copilot/how-tos/provide-context
7. Concepts for providing context to GitHub Copilot — https://docs.github.com/en/copilot/concepts/context
8. Adding repository custom instructions for GitHub Copilot — https://docs.github.com/copilot/customizing-copilot/adding-custom-instructions-for-github-copilot
9. Prompt files — https://docs.github.com/en/copilot/tutorials/customization-library/prompt-files
10. Use custom instructions in VS Code — https://code.visualstudio.com/docs/copilot/customization/custom-instructions
11. GitHub Changelog: Auto model selection GA — https://github.blog/changelog/2025-12-10-auto-model-selection-is-generally-available-in-github-copilot-in-visual-studio-code/
12. OpenAI Codex (developer docs) — https://developers.openai.com/codex/
13. Codex IDE extension (OpenAI docs) — https://developers.openai.com/codex/ide/
14. Codex extension (VS Code Marketplace) — https://marketplace.visualstudio.com/items?itemName=openai.chatgpt
15. OpenAI Help: install Work with Apps extension — https://help.openai.com/en/articles/10128592-how-to-install-the-work-with-apps-visual-studio-code-extension
16. SWE-bench (arXiv) — https://arxiv.org/abs/2310.06770
17. Introducing SWE-bench Verified (OpenAI) — https://openai.com/index/introducing-swe-bench-verified/
18. InstructGPT / RLHF paper — https://arxiv.org/abs/2203.02155
19. Attention Is All You Need (PDF) — https://papers.neurips.cc/paper/7181-attention-is-all-you-need.pdf

Əlbəttə ki, GitHub Copilot-un portfelində yalnız Claude yox, GPT-5, GPT-5.1, GPT- 5.2, və keçmiş versiya olan GPT-4.1 kimi modellər də mövcuddur. Mən bunlardan da vaxtaşırı istifadə edirdim. Lakin düzünü desəm, Copilot daxilində GPT modellərinin performansı məni tam qane etmirdi. Bu, modellərin özü ilə deyil, daha çox onların implementasiyası və inteqrasiyası ilə bağlı olduğunu güman edirdim.

Gözlənilməz kəşf

Ancaq bu gün gözlənilməz bir təcrübə yaşadım. ChatGPT Plus abunəçiləri üçün təqdim edilən ChatGPT Codex extension-unu VS Code-a yükləyib sınadım. İlk baxışda hər şey adi görünürdü; eyni GPT modelləri, eyni VS Code mühiti, eyni problemlər. Lakin nəticə məni heyrətə gətirdi.

GitHub Copilot daxilində istifadə etdiyim GPT modelləri ilə ChatGPT Codex-də seçdiyim GPT modelləri texniki cəhətdən eyni olsa da, performansda əhəmiyyətli fərq var idi. Bu fərq sadəcə kiçik nüanslar deyildi Codex-in GPT modelləri GitHub Copilot-dakına nisbətdə kəskin şəkildə daha yaxşı nəticələr verirdi.

Eksperiment: Eyni prompt, eyni model, fərqli nəticə

Təsadüfi müşahidə ilə kifayətlənmədim və kiçik bir eksperiment aparmağa qərar verdim. Eyni kod problemi, eyni prompt və eyni GPT modelini (GPT-5) hər iki platformada sınadım. Nəticə gözlədiyimdən də daha maraqlı çıxdı.

Testi aşağıdakı qaydalara uyğun olacaq şəkildə apardım:

• Eyni kod tapşırığı: Data Science kontekstində pandas ilə kompleks data transformation və visualization pipeline yaratmaq
• Eyni prompt məzmunu: dəqiq təlimat və kontekst
• Eyni model: GPT-5
• Fərqli platform: GitHub Copilot vs ChatGPT Codex

GitHub Copilot-da aldığım həll daha ümumi, şablon xarakterli və bəzən kontekstdən kənar idi. Təklif etdiyi pandas əməliyyatları bazis səviyyədə idi və mənim data strukturuma tam uyğun deyildi. ChatGPT Codex isə daha kontekstə uyğun, optimallaşdırılmış və mənim konkret data science istifadə halıma uyğun kod təklif etdi. Kod keyfiyyəti, data handling best practices-ə riayət, error handling və hətta kod stilinin layihəmdəki Jupyter notebook flow-una uyğunluğu Codex-də daha yüksək idi.

Bu eksperiment məni daha dərin araşdırmağa sövq etdi və kiçik bir tədqiqat apardım.

Niyə performans fərqi var?

Araşdırmam zamanı aşkar etdiyim əsas fərqlər aşağıdakılar kimidir:

Model optimizasiyası və fine-tuning: OpenAI, ChatGPT Codex üçün öz modellərini kod yazma tapşırıqlarına daha spesifik şəkildə optimallaşdırmış ola bilər. GitHub Copilot-da isə eyni modellər daha ümumi məqsədlər üçün konfiqurasiya edilmiş ola bilər. Araşdırmam zamanı aşkar etdim ki, Codex-in arxasında duran sistem OpenAI-ın birbaşa nəzarəti altında olduğu üçün model parametrlərinə və inference pipeline-a daha dərindən müdaxilə imkanı var.

API implementasiyası və sistem arxitekturası: Məlum oldu ki, hər iki platformanın modellərə müraciət etmə üsulu fundamental fərqlər daşıyır. ChatGPT Codex, OpenAI-ın öz ekosistemi olduğu üçün modellərlə daha native səviyyədə ünsiyyət qurur. GitHub Copilot isə Microsoft-un infrastrukturu üzərindən OpenAI API-na qoşulur ki, bu da əlavə latency və potensial data transformation layerləri yaradır. Bu aralıq təbəqələr bəzən kontekst itkisinə və ya prompt transformasiyasına səbəb ola bilir.

Context window və token idarəetməsi strategiyaları: Araşdırmam zamanı maraqlı bir nüans aşkar etdim: Codex, kod kontekstini və istifadəçi niyyətini anlamaq üçün daha ağıllı context management sistemi istifadə edir. VS Code-un açıq faylları, layihə strukturu və hətta Git tarixçəsi Codex tərəfindən daha effektiv şəkildə işlənir. GitHub Copilot-da isə eyni kontekst məlumatı daha məhdud şəkildə modelə çatdırılır.

Prompt engineering və system instructions: Ən maraqlı kəşfim bu oldu: ChatGPT Codex-in arxasında duran sistem promptları kod yazma üçün xüsusi optimallaşdırılıb. OpenAI-ın Codex üçün istifadə etdiyi system instructions modelə daha spesifik kod yazma davranışları öyrədir məsələn, daha az “hallucination”, daha çox kod konvensiyalarına riayət, daha yaxşı error handling. GitHub Copilot-da isə GPT modelləri daha ümumi system instructions ilə işləyir.

Response time və caching strategiyaları: İki platformanın caching və cavab təqdim etmə strategiyaları təkcə sürət deyil, keyfiyyət baxımından da fərqlidir. Codex daha agresiv və ağıllı semantic caching istifadə edir ki, bu da bənzər kontekstlərdə daha yaxşı nəticələr əldə etməyə imkan verir. Copilot-un caching strategiyası isə daha konservativdir.

Model versiyası və deployment pipeline: Digər vacib fərq: eyni model adı (məsələn, GPT-5.2) altında fərqli deployment versiyaları ola bilər. OpenAI, Codex üçün öz modellərinin ən son və ən optimallaşdırılmış versiyalarını birbaşa deploy edir. GitHub Copilot isə tərəfdaş münasibətinə görə bəzən bir neçə versiya geri qala bilər və ya Microsoft-un öz compliance və təhlükəsizlik tələblərinə uyğunlaşdırılmış versiyalar istifadə edə bilər.

Praktik nəticələr və texniki detallar

Bu təcrübə və araşdırmadan çıxardığım əsas nəticə budur: eyni AI modeli fərqli platformalarda fərqli performans göstərə bilər və bu fərq sadəcə implementasiya detallarına deyil, bütöv sistem arxitekturasına bağlıdır.

Mənim üçün bu kəşf bir neçə vacib dərsi özündə ehtiva edir:

Platform-model simbiozunun əhəmiyyəti: Model seçimi vacibdir, lakin həmin modelin hansı platformada necə işlədiyi daha da kritikdir. OpenAI-ın öz modellərini öz platformasında istifadə etməsi təbii üstünlük yaradır, bu sadəcə texniki deyil, həm də ekosistem üstünlüyüdür.

Abstraction layerlərin gizli dəyəri: GitHub Copilot-un Microsoft infrastrukturu üzərindən işləməsi sadəcə latency problemi deyil, həm də kontekst, prompt transformasiyası və model davranışı baxımından məhdudiyyətlər yaradır. Bu abstraction layerləri istifadəçidən gizli qalsa da, nəticəyə birbaşa təsir edir.

Claude-un Copilot-dakı uğuru: İndi daha yaxşı başa düşürəm ki, GitHub Copilot-da Claude modellərinin niyə bu qədər yaxşı performans göstərməsi təsadüfi deyil. Anthropic və Microsoft arasında daha yaxşı optimallaşdırma və ya Claude-un özünün daha robust arxitekturaya malik olması bu uğurun arxasında dayanır.

Bu araşdırma və əldə etdiyim bu nəticələrdən sonra çalışacam ki, daha hibrid şəkildə yanaşım.

Eksperimentdən sonra nə düşünürəm:

Developer kimi bizim üçün bu kəşf maraqlı və praktik bir seçim problemi yaradır. Sadəcə “hansı alət daha yaxşıdır?” sualı bəs eləmir, bu bilavasitə daha dərin bir strategiya məsələsidir.

Mənim hazırki strategiyam:

GitHub Copilot + Claude kombinasiyası əsas workflow üçün optimal qalır — Microsoft ekosisteminin verdiyi seamless təcrübə, GitHub inteqrasiyası və Claude-un etibarlı, yüksək keyfiyyətli kod təklifləri. Xüsusilə refactoring, arxitektura qərarları və kompleks problem həlli üçün Claude əvəzolunmazdır.

ChatGPT Codex + GPT-5/5.1 isə konkret hallar üçün: OpenAI modellərinə ehtiyac duyulan spesifik tapşırıqlar, eksperimental feature-lar və ya çox sürətli prototyping hallarında. Codex-in GPT-ləri burada məhz öz evində olur və maksimal performans göstərir.

Developer-lər üçün praktik tövsiyələr:

Platformaların native modellərinə üstünlük verin — OpenAI modellərini OpenAI platformasında, Claude modelini Copilot-da və ya birbaşa Claude.ai-da istifadə etmək daha yaxşı nəticələr verir.

Eyni modeli fərqli platformalarda test edin, mənim kimi sadə eksperimentlər sizi gözlənilməz kəşflərə apara bilər. Elmi praktikama əsaslanaraq rahatlıqla deyə bilərəm ki, “kağız üzərində” olan həll, real praktikada bir çox hallarda tamamilə fərqli nəticələr verir.

Kontekst idarəetməsinə diqqət yetirin, hansı platformadan istifadə edirsinizsə, o platformanın konteksti necə qəbul etdiyini başa düşmək kritikdir. VS Code-dakı açıq faylların, layihə strukturunun və workspace settings-in təsirini qiymətləndirin.

Tool switching overhead-ni hesablayın, iki alət arasında keçid etmək vaxt və mental enerji tələb edir. Bəzən 80% həll bir platformada, 100% həll üçün isə platform dəyişmək məntiqli ola bilər.

Gələcəyə baxış:

AI-powered coding tools bazarı sürətlə inkişaf edir və bu performans fərqləri zamanla dəyişə bilər. GitHub Copilot öz GPT implementasiyasını təkmilləşdirə bilər və ya tamamilə yeni model arxitekturaları meydana çıxa bilər.

Mənim fikrimdə, gələcək monolit AI coding assistant-lərdə deyil, smart orchestration-dadır müxtəlif modellərin güclü tərəflərini birləşdirən, kontekstə uyğun olaraq ən uyğun modeli seçən sistemlər.

Nəticə:

AI-powered coding tool-lar seçərkən sadəcə “hansı model daha güclüdür?” sualına cavab kifayət etmir. Real dünyada, model + platform + implementasiya = performans tənliyi işləyir.

Bu araşdırma mənə göstərdi ki, eyni prompt və eyni model ilə belə, fərqli platformalarda əldə etdiyiniz nəticə radikal şəkildə fərqli ola bilər. ChatGPT Codex-in GPT modelləri ilə əldə etdiyim superior performans, eyni GPT-nin GitHub Copilot-da göstərdiyi nəticədən kəskin şəkildə fərqlənirdi və bu fərqin kökündə sistem arxitekturası, prompt engineering, context management və deployment strategiyaları kimi görünməyən amillərin böyük rolu var imiş.

Mənim tövsiyəm sadədir: qəti fikrə ilişib qalmayın. Bir alətə və ya modelə kor-koranə bağlanmaq əvəzinə, öz real istifadə ssenarilərinizdə kiçik eksperimentlər edin, nəticələri müqayisə edin və sizin üçün ən yaxşı işləyən kombinasiyanı seçin. Bəzən “ən yaxşı” həll ən güclü model olmur, həmin modelin ən düzgün inteqrasiya edildiyi, ən yaxşı optimizasiya olunduğu platforma olur.

Developer kimi bizim işimiz təkcə kod yazmaq deyil. Eyni zamanda doğru alətləri seçmək, onları düzgün qurmaq və maksimum fayda çıxarmaq da işin bir parçasıdır. Bu təcrübə mənə bir daha göstərdi ki, texnologiya dünyasında kağız üzərində yaxşı görünən şeylər real şəraitdə fərqli nəticə verə bilər. Ona görə də ən etibarlı meyar reklam və müqayisə cədvəlləri deyil, real test, real istifadə və real təcrübədir.

Araşdırmaya davam etmək üçün bu mənbələrə baxın:

1. Supported AI models in GitHub Copilot — https://docs.github.com/copilot/reference/ai-models/supported-models
2. About Copilot auto model selection — https://docs.github.com/copilot/concepts/auto-model-selection
3. Changing the AI model for GitHub Copilot Chat — https://docs.github.com/en/copilot/how-tos/use-ai-models/change-the-chat-model
4. AI model comparison (Copilot) — https://docs.github.com/en/copilot/reference/ai-models/model-comparison
5. Hosting of models for GitHub Copilot Chat — https://docs.github.com/en/copilot/reference/ai-models/model-hosting
6. Provide context to GitHub Copilot — https://docs.github.com/en/copilot/how-tos/provide-context
7. Concepts for providing context to GitHub Copilot — https://docs.github.com/en/copilot/concepts/context
8. Adding repository custom instructions for GitHub Copilot — https://docs.github.com/copilot/customizing-copilot/adding-custom-instructions-for-github-copilot
9. Prompt files — https://docs.github.com/en/copilot/tutorials/customization-library/prompt-files
10. Use custom instructions in VS Code — https://code.visualstudio.com/docs/copilot/customization/custom-instructions
11. GitHub Changelog: Auto model selection GA — https://github.blog/changelog/2025-12-10-auto-model-selection-is-generally-available-in-github-copilot-in-visual-studio-code/
12. OpenAI Codex (developer docs) — https://developers.openai.com/codex/
13. Codex IDE extension (OpenAI docs) — https://developers.openai.com/codex/ide/
14. Codex extension (VS Code Marketplace) — https://marketplace.visualstudio.com/items?itemName=openai.chatgpt
15. OpenAI Help: install Work with Apps extension — https://help.openai.com/en/articles/10128592-how-to-install-the-work-with-apps-visual-studio-code-extension
16. SWE-bench (arXiv) — https://arxiv.org/abs/2310.06770
17. Introducing SWE-bench Verified (OpenAI) — https://openai.com/index/introducing-swe-bench-verified/
18. InstructGPT / RLHF paper — https://arxiv.org/abs/2203.02155
19. Attention Is All You Need (PDF) — https://papers.neurips.cc/paper/7181-attention-is-all-you-need.pdf

Mətn redaktoru nədir?

Mətn redaktoru adından da göründüyü kimi, mətn yazmaq üçün olan bir vasitədir. Notepad, Sublime Text, VS Code, Atom kimi vasitələr mətn redaktorlarıdır. Onların əsas vəzifəsi sadədir: sən kod yazırsan, o da onu qeyd edir.

Mətn redaktorları yüngüldür, tez işləyir və minimal resurs sərf edir. Sən sadəcə bir fayl açırsan, kodunu yazırsan və saxlayırsan. Bəzi müasir mətn redaktorları (məsələn, VS Code) artıq o qədər güclü “plugin”lərlə gəlir ki, demək olar IDE-yə çevrilib, ancaq hələ də əsasən mətn redaktoru minimalist bir yanaşmadır.

IDE Nədir?

IDE — Integrated Development Environment, yəni İnteqrasiya Olunmuş İnkişaf Mühiti. Burda açar söz “inteqrasiya olunmuş”dur. IDE sadəcə mətn redaktoru deyil, bütöv bir iş mühitidir.

IDE-də sən kod yazanda, o kodun sintaksisini yoxlayır, səhvləri dərhal göstərir, avtomatik tamamlama təklif edir, kodunu “debug” edir, testlər yazırsan, verilənlər bazasına qoşulursan və hətta proyekti yerləşdirmək (deploy) üçün alətlər verir. Bir sözlə, proqramçıya lazım olan hər şey bir yerdə toplanıb.

Visual Studio, IntelliJ IDEA, PyCharm, Eclipse; bunlar IDE-lərə misaldır.

Əsas Fərqlər

1. Funksionallıq

Mətn redaktoru “yalın” və sadədir - mətn yaz, saxla, get. IDE isə kompleksdir; kod yaz, test et, debug et, run et, deploy et. Hamısı bir yerdə.

2. Resurs istifadəsi

Mətn redaktorları “yüngüldür”, tez açılır. IDE-lər isə ağırdır, çoxlu RAM və CPU istifadə edir. Məsələn, IntelliJ IDEA-nı açanda kompüterin fanın səsi bütün otağı götürür, fanın səsi adamın başına düşür (One of those typical Windows user problems :) ), Notepad++ açanda heç nə olmur.

3. Layihə idarəetməsi

IDE-də layihə konsepsiyası var. Sən bir proyekti açırsan və o proyektə aid olan bütün fayllar, strukturlar, ayarlar bir yerdə saxlanılır. Mətn redaktorunda isə sadəcə fayllar açırsan, proyektin mənası yoxdur (yaxud çox məhduddur).

4. Kod analizi

IDE kodunu davamlı analiz edir. Səhvləri göstərir, optimallaşdırma təklifləri verir, istifadə olunmayan dəyişənləri tapır. Mətn redaktorunda bu funksiyalar ya yoxdur, ya da plaginlərlə əlavə olunmalıdır.

5. Debugging

IDE-də inteqrasiya olunmuş debugger var. Breakpoint qoyursan, dəyişənlərin dəyərlərini görürsən, addım-addım kodu icra edirsən. Mətn redaktorunda debugging üçün ayrıca alətlərə ehtiyac var.

Hansını Seçməli?

Bu, tamamilə sənin ehtiyaclarından asılıdır.

Mətn redaktoru istifadə etməlisən əgər:

• Kiçik scriptlər yazırsansa
• Sürətli bir şey test etmək istəyirsənsə
• Yüngül və tez işləyən vasitə lazımdırsa
• Bir neçə müxtəlif dildə işləyirsən və universal redaktor istəyirsənsə.

IDE istifadə et əgər:

• Böyük proyektlər üzərində işləyirsənsə
• Komanda halında işləyirsənsə
• Kod keyfiyyəti və refactoring vacibdirsə
• Debug prosesi mühümdürsə
• Framework və kitabxanalarla çox işləyirsənsə.

Mənim fikrim:

Mən şəxsən hər iki yanaşmanı istifadə edirəm. Kiçik işlər, konfiqurasiya faylları, markdown yazıları üçün VS Code istifadə edirəm. Devoloperlər çox vaxt böyük Java və ya Python proyektləri üçün IntelliJ IDEA və ya PyCharm-a keçir. Hərəsinin öz yeri var.

Əvvəllər “əsl proqramçılar” Vim və ya Emacs istifadə edərdilər, IDE istifadə etməyi “tənbəllik” sayırdılar, amma bu anlayış artıq köhnəlib. Müasir proqramlaşdırma mühiti o qədər mürəkkəbdir ki, IDE-nin təklif etdiyi avtomatlaşdırma və yardım funksiyaları vaxt qazandırır və səhvləri azaldır.

Nəticə

IDE və mətn redaktoru arasındakı fərq; Ferrari ilə Toyota Corolla arasındakı fərq kimidir. Hər ikisi səni məqsədə çatdırır, amma fərqli vəziyyətlər üçün nəzərdə tutulub. Gərək biləsən, hansı alət hansı iş üçün uyğundur.

Əgər yeni başlayırsansa, sadə mətn redaktorundan başla, proqramlaşdırmanın əsaslarını öyrən. Sonra təbii olaraq IDE-yə ehtiyac duyacaqsan və keçid edəcəksən. Bu proses tamamilə normaldır.

Ən əsası hansı alətdən istifadə etməyin deyil, nə qədər yaxşı kod yazdığındır. Alətlər sadəcə vasitədir, əsil məharət sənin koduna aiddir.

Bildiyiniz kimi, kompüterlər yalnız 0 və 1-i başa düşür. Bizsə onlara ingiliscə sözlər yazırıq. Ortada nə baş verir?

Tərcüməçi

Təsəvvür edin ki, siz yalnız azərbaycan dilində danışırsınız, qarşınızdakı isə yalnız çin dilində bilir. Söhbət etmək üçün tərcüməçi lazımdır, elədi? Ya da süni intellekt…

Proqramlaşdırma dilləri məhz bu tərcüməçi rolunu oynayır. Biz normal danışıq dilinə yaxın bir şey yazırıq, o isə bunu kompüterin anladığı dilə çevirir. Bu qədər sadədi əslində hər şey. (sözdə sadədi, əməldə çətin)

Səviyyə söhbəti var

“Dillərin müxtəlif səviyyələri olur”.

Python, JavaScript kimi dillərdə biz demək olar ki, adi danışıq dili kimi yazırıq. Məsələn, “if age > 18” — oxuduqca başa düşülür. Bunlara yüksək səviyyəli dillər deyil, çünki bizim düşüncə tərzimizə yaxındır.

Amma aşağıda başqa dillər də var. Məsələn, Assembly dilində eyni şeyi yazmaq üçün yaddaş ünvanları, registrlər və s. haqqında düşünməlisən, bir sözlə kompüter kimi düşünməlisən. Bu daha çətindir, amma kompüterə daha yaxındır.

Hərdən maraq üçün “C++” a filan baxıram. Pythona şükür edirəm. Yaxşı ki, python var, python olmasa mən nə edərdim.

Kodumu kompüter necə başa düşür?

İndi ən maraq doğuran hissə. Siz kod yazırsınız, enter basırsınız, nəsə baş verir, amma işin arxa fonunda nə baş verir?

Bəzi dillər (məsələn, C++) bütün kodunuzu bir dəfə oxuyur, başdan-sona tərcümə edir və “maşının” dilinə çevirir. Sonra o hazır tərcümə işə düşür. Buna kompilyasiya deyirlər. elə bil ki, kitabı bir dəfə tərcümə edirsən, sonra istədiyin qədər oxuyursan.

Python və JavaScript kimi dillərsə fərqlidir. Onlar sətir-sətir oxuyub icra edir. Hər dəfə proqramı işə salanda kod yenidən tərcümə olunur. Sanki sinxron tərcüməçi danışanı danışdıqca tərcümə edir.

İkisinin də yaxşı və pis tərəfləri var. Birinci sürətlidir, ikincisi çevik.

Pythonun sirri

Maraqlı bir şey var. Python faylınız yanında bəzən pycache qovluğu və .pyc faylları yaranır. Nədir bunlar?

Python əslində tamamilə sətir-sətir tərcümə etmir. Əvvəlcə kodu aralıq bir formata çevirir bytecode deyilən bir şeyə. Sonra onu icra edir. Bu .pyc faylları məhz o bytecode-dur. Mən bunu hər dəfə yeni dataset yükləyəndə görürəm, ilk yükləmə bir az gec olur, amma sonrakılar daha sürətli işləyir. Səbəb məhz bu bytecode cache-ləməsidir.

İkisinin qarışığı

Son illərdə yeni bir üsul çıxıb: Just-In-Time kompilyasiya. Qısa adı JIT. Julia dilində və ya Python-un PyPy implementasiyasında bu texnologiya istifadə olunur. Kod işləyə-işləyə təhlil edilir və tez-tez istifadə olunan hissələr “maşın” koduna çevrilir.

Bu nədir? Təsəvvür edin ki, proqram işləyir və özü özünü müşahidə edir. Görür ki, bu hissə çox işlənir. Deyir: “Yaxşı, bu hissəni indi “maşın” dilinə çevirirəm ki, daha sürətli işləsin”.

Yaddaş məsələsi

Python-da dəyişən yaradanda “x = 5” yazırsan və qurtarır, amma arxada çox şey baş verir.

Python avtomatik yaddaşa qoyur, istifadə edəndə götürür, lazım olmayanda təmizləyir. Buna Garbage Collection deyirlər. Bizim əlimizdən nə götürür? Çox şey.

C dilində isə öz əlinlə yaddaşı idarə etməlisən. Yaddaş ayır, işin bitəndə azad et. Unutsan, problem yaranar. Unutdunsa proqram get-gedə yaddaşı yeyir, axırda kompüter donur.

Azadlıq?

Python-da yaza bilərsən:

x = 5
x = "salam"
x = [1, 2, 3]

Eyni dəyişənə istədiyin tip yaza bilərsən. Buna dinamik tipləndirmə deyirlər, amma Java və ya C++ kimi dillərdə belə olmur. Əvvəlcədən elan etməlisən ki, bu dəyişən rəqəmdir, bu mətndir. Sonra dəyişə bilməzsən.

Hansı daha yaxşıdır? Hər ikisinin öz yeri var. Python çevikdir, tez yazırsan. Java və C++ isə daha etibarlıdır, böyük layihələrdə xətaları erkən görür.

Niyə Bu Qədər Çox Dil Var?

Düşünmüsünüzmü, niyə bir dil yoxdur, yüzlərlə var?

Çünki hər iş üçün yaxşı alət fərqlidir. Bıçağında fərqli növləri varda, buna oxşayır. Meyvə bıçağıyla ət doğramaq olur?
Mən data ilə işləyirəm, mənim üçün Python idealdır pandas, numpy və digər kitabxanalar çox güclüdür.

Amma vebsayt quranda JavaScript lazımdır. Mobil tətbiq yazmaqda Swift və ya Kotlin. Oyun yazmaqda C++. Hər dil müəyyən problemləri həll etmək üçün yaradılıb.

Nəticələr

Proqramlaşdırma dilləri əslində inanılmaz mühəndislik əsərləridir. Onlar bizim düşüncələrimizi kompüterin başa düşəcəyi formata çevirirlər. Hər dəfə “import pandas as pd” yazdığımda, arxada minlərlə sətir kod işə düşür, yüzlərlə funksiya hazır vəziyyətə gəlir.

Əgər siz də mənim kimi kod yazmağı sevirsinizsə, bəzən bir anlığa dayanıb arxada baş verənləri düşünün. Bu, sizə kodunuzu daha yaxşı başa düşməyə və daha effektiv proqramlar yazmağa kömək edəcək.

Unutmayın, hər bir “Hello World” arxasında insan zehininin və mühəndislik düşüncəsinin onilliklərinin əməyi var və bu, həqiqətən, möhtəşəmdir.

Oxumağa davam et:

• How Python Runs Programs: https://www.oreilly.com/library/view/learning-python-5th/9781449355722/
• Understanding JIT Compilation: https://www.ibm.com/docs/en/sdk-java-technology/8
• Stack Overflow Developer Survey: https://survey.stackoverflow.co/

Here’s a spoiler: your Spotify playlists are datasets. The posts that appear in your social media feeds are datasets. These platforms’ algorithms know what and how much you’ll engage with, so they create custom, specific datasets for you, and you spend hours scrolling. Now let’s break it down and really understand it.

What is a Dataset?

To understand the term, let’s start with the word itself. “DataSet” is clearly a compound word made up of “Data” and “Set.” Let’s figure out what each part means and how they come together.

Data — This is simply raw information or facts. Here’s the key distinction many people miss: “data” and “information” aren’t the same thing. Data is the raw material — like individual letters on a page. Information is what you get when that data becomes meaningful to you. For example, I’m writing this using letters from the English alphabet. Each letter by itself is just a symbol (data), but when you read and understand what these symbols spell out together, that becomes information for you. If you tried to read Chinese characters without knowing Chinese, you’d see the data (the visual symbols) but gain no information from them — at most, you might notice their artistic shapes. So “data” is essentially raw facts or elements, regardless of whether they mean anything to you personally.

Set — This is a mathematical concept you probably remember from elementary school — those Venn diagrams with circles and intersections. In mathematics, a “set” is simply a collection of distinct objects or elements that share some common characteristic. Think of it like a group: the set of all students in your class, the set of all red cars in a parking lot, or the set of all songs in your music library.

I’ve seen “Dataset” sometimes called “Data Collection,” but I think this can create confusion with “Database.” A database is an organized collection of data that’s stored and accessed electronically using management systems. Small databases live in file systems, while large ones are housed in computer clusters or cloud storage.

So what exactly is a dataset? A dataset is a collection of information gathered, stored, and processed through various methods for a specific purpose. This information is presented in a unified format and can contain various types of data — numbers, text, images, audio, you name it. A dataset is essentially structured information organized for analysis, modeling, or other data-driven processes.

You might be thinking, “Okay, but what does this actually mean?” Fair point. A dataset is basically a pile of information collected about some topic for a specific reason. Don’t overthink it — you don’t even need to create one yourself to see them in action.

Take Instagram Reels, where many of us spend hours scrolling. Instagram analyzes your behavior and serves up a dataset of reels you’re likely to watch, essentially saying “here, scroll endlessly through these.” When you create a Spotify playlist, that’s the same process — you’re categorizing songs based on your current mood or situation. Maybe you have a “sad songs” playlist or a “workout mix.” That’s your personal dataset right there.

Think about a grocery store: all the product names, prices, expiration dates, and manufacturers together form a dataset. Each product is a “data point,” and its characteristics (price, brand, etc.) are its “attributes.”

Imagine you want to teach AI to recognize the color red. You’d need to show it pictures of red objects — tomatoes, strawberries, red apples, red cars, and so on. Each image is a data point, and its properties (color, shape, name) are the attributes.

Creating a Dataset

Creating a dataset is actually easier than you might think. There are two main approaches:

1. Data Collection

Data collection is the first and most crucial step in creating any dataset. You can do this several ways:

Manual collection is the most straightforward approach. You go out and talk to people, conduct surveys, do library research. If you’re studying education trends, you might survey people from different age groups and record their responses. You’ve probably seen those stress-level questionnaires for college students — that’s manual data collection. It works great for smaller projects.

Web scraping means automatically gathering information using the internet’s power. Say you want to compare phone prices across different retailers. Instead of visiting each website individually, you can write programs to automatically collect this information and build your dataset. This is invaluable for handling large volumes of data.

Using existing datasets is often the most practical route. Frequently, the information you need has already been collected and shared by someone else. Platforms like Kaggle and Google Dataset Search offer thousands of datasets covering everything from economics to medicine. This saves tremendous time and effort.

Sensor and device collection is increasingly common today. Weather stations collecting temperature and humidity data, fitness trackers monitoring your steps and heart rate, even your phone’s GPS data — all of these create valuable datasets. This data flows in continuously and automatically.

2. Data Cleaning and Formatting

Once you’ve collected your data, the next step is getting it into working condition. This process is crucial because, as they say, “garbage in, garbage out.”

The cleaning process involves fixing all the problems in your dataset. For instance, in an online store’s product catalog, some prices might be entered incorrectly, some product names might be missing, or the same item might be listed multiple times. You need to find and fix or remove these issues. Otherwise, your analysis will produce unreliable results.

Formatting means standardizing all your information. Let’s say you’ve gathered date information from various sources — some use 3/15/2024, others use March 15, 2024, and still others use 2024–03–15. You need to convert everything to one consistent format (like MM/DD/YYYY). The same goes for text — it’s usually better to standardize everything as either uppercase or lowercase.

Skipping these steps and trying to analyze messy data will give you seriously flawed results. That’s why investing proper time in this stage is absolutely essential.

The Bottom Line

As you can see, datasets are everywhere in our daily lives and play a fundamental role in technological advancement. They’re the foundation that allows computers to understand our world and offer us smarter solutions. I hope this brief explanation helped clarify what datasets are all about.

Next time you see an app recommending something to you, remember there’s a massive dataset and lots of hard work behind that suggestion. And once you understand this, you’ll probably realize just how much information these platforms collect about you to make those recommendations — what you look at, for how long, what you like, what you comment on. Social media algorithms know us better than we know ourselves.

Their main goal? Keep you glued to your screen, which helps them show advertisers that people are highly engaged. How do they prove this? By showing data: “Look how interested people are, look how much time they spend on our platform.” Remember the golden rule: if a product is free, you’re probably the product being sold. Social networks are free, but the companies paying for ads are the real customers, and they’re buying your time, attention, and focus.

Now that I’ve shared that wake-up call, I’ll wrap this up. Thanks for reading!

References:

• National University LibGuides. (2025). Datasets — The Research Process.
• University of Michigan Library Citation Help & Oregon State University Research Data Services.
• Wikipedia contributors. (2025). Data set. In Wikipedia, The Free Encyclopedia.
• Kim, H., et al. (2024). A Reference Paper Collection System Using Web Scraping. Electronics, 13(14), 2700.
• Renear, A. H., Sacchi, S., & Wickett, K. M. (2010). Definitions of dataset in the scientific and technical literature. Proceedings of the American Society for Information Science and Technology, 47(1), 1–4.
• University of Wisconsin-Madison Research Data Services. (2019). An Introduction to Web Scraping for Research.
• Gregory, K., et al. (2023). How and Why Do Researchers Reference Data? A Study of Rhetorical Features and Functions of Data References in Academic Articles. Data Science Journal, 22(1).

Dataset Nədir?

Termini başa düşmək üçün, məncə ilk növbədə sözün özündən danışmaq lazımdı, “DataSet” görünür ki, bu mürəkkəb sözdü. Hissələrə ayırdığımız zaman ingiliscə iki sözlə qarşılaşırıq, “Data” və “Set” sözləri ilə. Gəlin ilk növbədə başa düşməyə çalışaq ki, data nədi, set nədi və onların birləşib yaratdığı dataset nədi.
Data — sözünü Azərbaycan dilində məlumat, informasiya və ya verilən olaraq ifadə edirlər. Əslində Dataset termininin tərkibində olan data sözü informasiya, məlumat yox, “Data” sözünü Azərbaycan dilində “verilən” kimi ifadə etmək daha uyğundur. Çox vaxt “verilən” ilə “informasiya” qarışdırılır. Halbuki fərq ondadır ki, verilən sadəcə faktlar və ya simvollardır, informasiya isə insana məna və dəyər çatdıran verilənlərdir. Məsələn, mən burda müxtəlif simvollardan istifadə edərək yazıram. Bu yazını oxuyan Azərbaycanlı üçün bu — informasiya, amma latın qrafikasını bilməyən ərəb üçün isə sadəcə veriləndir.

“Set” sözünü “Çoxluq” termini kimi tərcümə etmək olar. “Çoxluq” bildiyimiz riyaziyyatdakı çoxluq, 4–5-ci siniflərdə, birləşmə və kəsişmə işarələrini qarışdırdığımız həmin mövzu. Termin olaraq “Çoxluq” sözünə belə izah verilir: riyaziyyatın əsas anlayışlarından biri; elementləri adlandırılan və hamı üçün ümumi xarakterik bir xüsusiyyətə sahib olan hər hansı bir obyektin dəsti, çoxluğu, toplusu olan riyazi bir obyektdir. Dərsə gedən uşaqlar çoxluğu, evdə yatan uşaqlar çoxluğu, Fransız dili bilən müəllimlər çoxluğu bilirikdə bu nümunələri.

“Dataset” sözünün bir-iki yerdə “Verilənlər toplusu” olaraq istifadə edildiyini gördüm, məncə bu istifadə qarışıqlıq yarada bilər. “Database” termini “Verilənlər Bazası” olaraq tərcümə olunur. Bu tərcümə bəzən qarışıqlıq yaradır, insanlar verilənlər toplusu və verilənlər bazası terminlərini həm hərfi həm məna olaraq oxşarlığına görə qarışdırır. Dataset — verilənlər toplusu, Database — verilənlər bazasıdır. Dataset adətən bir tədqiqat, analiz və ya model üçün konkret seçilmiş məlumat dəstini ifadə edir, database isə müxtəlif dataset-ləri də saxlayan geniş sistemdir.

Axır ki, gəlib çıxdım dataset nədir sualına. “Dataset” — müəyyən strukturda saxlanılan verilənlər toplusudur. Bu toplular analiz, modelləşdirmə və ya süni intellekt sistemlərində öyrənmə prosesi üçün əsas baza rolunu oynayır.
Deyəcəksiniz a bala mən burdan nə başa düşüm? Düz deyirsiniz, bu dataset dedik, hansısa mövzu haqqında müəyyən məqsədlə toplanan məlumat yığınıdı. Bilirsiniz səhv etmədən, ən yaxşı misalı düşündüm. Ağlıma sosial media gəldi, səbəbi birazda bu yaxınlarda baxdığım bir sənədli filmdi, “The Social Dilemma”. Sosial şəbəkələr istifadəçi davranışları haqqında çox böyük datasetlər yaradır və bu datasetlər sayəsində uğurlu alqoritmlər inkişaf etdirə nəticə də bizi ekrandan aslı vəziyyətə sala bilirlər.

Bir marketdəki bütün məhsulların adları, qiymətləri, son istifadə tarixləri, istehsalçıları bunların hamısı bir datasetdir. Hər bir məhsul bir “data nöqtəsi”, onun xüsusiyyətləri isə “atributlar”dır.

Təsəvvür edin ki, siz süni intellektə qırmızı rəngi öyrətmək istəyirsiniz. Bunun üçün ona qırmızı rəngdə olan obyektlərin şəkillərini göstərməlisiniz. Bu datasetdə pomidorlar, çiyələklər, qırmızı almalar, qırmızı maşınlar və s. kimi qırmızı obyektlərin şəkilləri olacaq. Hər bir şəkil bir data nöqtəsi, onun rəngi, forması, adı isə atributları olacaq.

Dataset yaratmaq, əslində düşündüyünüzdən daha asandır. Əsasən iki əsas yanaşma var:

1. Məlumatların Toplanması

Məlumat toplama hər hansı bir dataset yaratmağın ilk və ən mühüm mərhələsidir. Bunu müxtəlif üsullarla edə bilərik:

Əl ilə toplama ən sadə və birbaşa yoldur. Sadəcə özünüz çıxıb insanlarla danışır, sorğular keçirir, kitabxanalarda araşdırma aparırsınız. Məsələn, təhsil haqqında bir tədqiqat aparırsınızsa, müxtəlif yaş qruplarından insanlara suallar verərək onların cavablarını qeyd edirsiniz. Bəlkə universitet tələbələri üçün stress səviyyəsini ölçən anketlər görmüsünüz — bunlar da bu kateqoriyaya aiddir. Kiçik layihələr üçün kifayət qədər effektivdir.

Veb-skrapinq isə internetin gücündən istifadə edərək avtomatik məlumat toplamaq deməkdir. Tutaq ki, müxtəlif mağazalarda telefon qiymətlərini müqayisə etmək istəyirsiniz. Hər saytı tək-tək gəzməkdənsə, xüsusi proqramlar yazaraq bu məlumatları avtomatik toplayıb öz datasetinizi yarada bilərsiniz. Böyük həcmli məlumatlar üçün çox faydalıdır.

Hazır datasetlərdən istifadə ən praktik yoldur. Çox vaxt ehtiyacınız olan məlumatlar artıq kimsə tərəfindən toplanmış və paylaşılmış olur. Kaggle, Google Dataset Search kimi platformalarda minlərlə müxtəlif mövzuda dataset tapa bilərsiniz — iqtisadiyyatdan tutmuş tibbə qədər. Bu, vaxtınıza qənaət edir.

Sensor və cihazlardan toplama müasir dövrdə getdikcə daha çox yayılır. Hava stansiyalarının temperatur və rütubət məlumatları, smart saatlarınızın addım sayğacı və ürək ritmi ölçüləri, hətta telefonunuzdakı GPS məlumatları — bunların hamısı dəyərli datasetlər yaradır. Bu məlumatlar davamlı və avtomatik toplanır.

2. Məlumatların Təmizlənməsi və Formatlanması

Məlumatları topladıqdan sonra növbəti mərhələ onları işlək vəziyyətə gətirməkdir. Bu proses həqiqətən çox önəmlidir, çünki atalar demişkən, “Nə əkərsən, onu da biçərsən”.

Təmizləmə prosesi datasetinizdəki bütün problemləri həll etmək deməkdir. Məsələn, bir onlayn mağazanın məhsul siyahısında bəzi qiymətlər səhv yazılıb, bəzi yerlərdə məhsulun adı eksikdir, ya da eyni məhsul bir neçə dəfə qeyd olunub. Bunların hamısını tapıb düzəltmək və ya silmək lazımdır. Əks halda analiz zamanı yanlış nəticələr əldə edərsiniz.

Formatlama isə bütün məlumatları vahid standarda gətirmək deməkdir. Tutaq ki, müxtəlif mənbələrdən tarix məlumatları toplamısınız — bəziləri 15/03/2024, bəziləri 15 Mart 2024, bəziləri isə 2024–03–15 formatındadır. Bunları hamısını eyni formata (məsələn, GG.AA.İİİİ) çevirməlisiniz. Eyni şəkildə mətnlərlə işləyirsinizsə, hər şeyi ya böyük hərflə, ya kiçik hərflə yazmaq daha yaxşıdır.

Bu addımlar olmadan məlumatlarınızı analiz etməyə çalışsanız, çox səhv nəticələr əldə edə bilərsiniz. Ona görə də bu mərhələyə lazımınca vaxt ayırmaq çox vacibdir.

Nəticə

Gördüyünüz kimi, datasetlər gündəlik həyatımızın hər yerindədir və texnologiyanın inkişafında əvəzsiz rol oynayır. Onlar, kompüterlərin dünyanı öyrənməsi və bizə daha ağıllı həllər təklif etməsi üçün əsas təməldir. Ümid edirəm ki, bu qısa yazı datasetlər haqqında əsas anlayışları sizə çatdıra bildi. Növbəti dəfə bir tətbiqin sizə nəyisə tövsiyə etdiyini görəndə, bilin ki, arxasında böyük bir dataset və onun üzərində aparılan zəhmətli iş dayanır. Birdə ki, başa düşdünüz də yəqin o tövsiyyələr üçün nə qədər sizin haqqınızda məlumat toplamalıdılar, nəyə nə qədər baxdınız, nəyi bəyəndiniz, nəyə fikir bildirdiniz. Sosial media alqoritmləri bizi bizdən yaxşı tanıyır. Tək məqsədləri bizi ekrandan aslı vəziyyətə salmaqdı, hansı ki, onlar reklam üçün pul ödəyən şirkətlərdə bir növ etibar hissi yaratmalıdı axı. Necə yaradırlar, əllərində ki, dataları göstərirlər ki, baxın insanlar bu qədər maraqlanır, bu qədər vaxt məndən istifadə edir falan-filan. Unutmayın, əgər nəsə pulsuzdursa, yəqin ki, orda satılan sizsiniz. Sosial şəbəkələr də pulsuzdu. Pulunu ödəyən reklam verən şirkətlərdi, alınansa bizim vaxtımız, diqqətimiz, qayğımızdı.

Sosial mesajımıda verdiyimə görə bitirə bilərəm, oxuduğunuz üçün təşəkkürlər!

Ədəbiyyat:

1. National University LibGuides. (2025). Datasets — The Research Process.
2. University of Michigan Library Citation Help & Oregon State University Research Data Services.
3. Wikipedia contributors. (2025). Data set. In Wikipedia, The Free Encyclopedia.
4. Kim, H., et al. (2024). A Reference Paper Collection System Using Web Scraping. Electronics, 13(14), 2700.
5. Renear, A. H., Sacchi, S., & Wickett, K. M. (2010). Definitions of dataset in the scientific and technical literature. Proceedings of the American Society for Information Science and Technology, 47(1), 1–4.
6. University of Wisconsin-Madison Research Data Services. (2019). An Introduction to Web Scraping for Research.
7. Gregory, K., et al. (2023). How and Why Do Researchers Reference Data? A Study of Rhetorical Features and Functions of Data References in Academic Articles. Data Science Journal, 22(1).

Token nədir?

LLM-lər üçün mətn sadəcə hərflərdən ibarət deyil. Böyük Dil Modelləri (LMM) böyük təxmin modelləridir, ancaq burda təxmin etdikləri şey sözlər yox, “token” adlanan xüsusi hissələrdi. Bu modellər buna görə mətni “token” adlanan kiçik hissələrə bölürlər. Token tam bir söz (“kitab”), sözün bir hissəsi (“-lar” şəkilçisi) və ya hətta tək hərf, rəqəm, hətta hər hansı durğu işarəsi belə ola bilər. Məsələn, “oxuyuram” sözü bəzən “oxu” və “yuram” kimi iki tokenə parçalanır. Bu, modelin necə öyrədilməsindən asılıdır.

Niyə məhz token? Çünki bu üsul modelin həm “oxumaq”, həm “oxuyuram”, həm də “oxumuşam” sözlərində eyni kökü tanımasına imkan verir. Bu da ona dilin strukturunu daha yaxşı başa düşməyə kömək edir.

Sözlərdən rəqəmlərə

İnsan beyni sözləri anlayır, kompüterlər isə yalnız rəqəmlərlə işləyir. LLM hər tokeni çoxölçülü bir vektora çevirir. Bu vektorlar sözün mənasını, kontekstini və digər sözlərlə əlaqəsini daşıyır. Məsələn, “it” və “pişik” tokenlərinin vektorları bir-birinə yaxın olur, çünki hər ikisi ev heyvanıdır. “Maşın” sözünün vektoru isə bu sözlərin vektorlarından tamamilə fərqli olmalıdı.

Hansı söz vacibdir?

LLM-lərin ən güclü mexanizmlərindən biri “diqqət mexanizmi”dir (attention mechanism). Bu sistem modelə cümlədə hansı sözlərin bir-biri ilə daha çox əlaqəli olduğunu müəyyən etməyə imkan verir. Məsələn, “Alma bahadır” cümləsində “alma” sözünün meyvə, yoxsa “alma” felinin əmr forması olduğunu digər sözə, yəni “bahadır” sözünə baxaraq təyin edir.

Model hər tokeni işləyərkən bütün əvvəlki tokenlərə “baxır” və onların hər birinə fərqli dərəcədə diqqət yetirir. Bu, insanın oxuyarkən vacib sözləri xatırlamasına bənzəyir.

LLM-in əsas işi növbəti tokeni proqnozlaşdırmaqdır. “Bakı Azərbaycanın…” yazdığınız zaman model düşünür: statistik olaraq bu kontekstdə ən çox hansı söz gələ bilər? “Paytaxtıdır” cavabı 85% ehtimalla, “şəhəridir” 10% ehtimalla, başqa sözlər daha az ehtimalla. Model bu ehtimallardan birini seçir və prosesi davam etdirir.

Bu proses token-token davam edir. Hər yeni token əvvəlki bütün tokenlərə əsasən seçilir. Beləliklə, model uzun, mənalı cavablar yarada bilir

LLM-lər internetdən, kitablardan və məqalələrdən toplanmış nəhəng mətn korpusları üzərində təlim keçir. Təlim zamanı model milyardlarla cümlə görür və dilin qanunauyğunluqlarını öyrənir: qrammatika qaydaları, faktlar, üslublar, hətta zarafatlar belə.

Maraqlısı odur ki, heç kim modelə birbaşa “feil budur, isim budur” demir. Model bunları özü kəşf edir, uşağın danışmağı öyrənməsi kimi. Milyonlarla nümunə görəndən sonra “yazmaq” sözündən sonra çox vaxt ya obyekt, ya da feil forması gəldiyini “anlayır”.

Siz sual verəndə model əslində düşünmür; sadəcə mürəkkəb statistik hesablamalar aparır. Sualınızdakı tokenlər onun “yaddaşındakı” milyardlarla qanunauyğunluqla müqayisə olunur və ən uyğun cavab token-token qurulur.

Bəs necə? Gəlin bunu uyğun nümunə ilə izah edək:

“Python neçənci ildə buraxılıb?” sualını nümunə olaraq götürək. Model bu sualı başa düşüb, bu sualdı, mən buna cavab verməliyəm demir. Elədiyi şey bu məqalənində əvvəlində danışdığımız kimi, tamamlamaqdı. Modelə belə bir sual ünvanlananda o “düşünür” belə bir mətnə insanlar nə kimi cavablar yazıb və ya insanlar necə cavab yazardı? Modelin datasetində əzbər olaraq bu sualın cavabı olmasa belə, internetdən əldə etdiyi bu tip məlumatlar var. “1991-ci ildə buraxılıb”, “1991-ci ildə Van Rossum tərəfindən buraxılıb”, “Van Rossum tərəfindən 1991-ci ildə buraxılıb”, “1991-də buraxıldı”. Model bunlardan yola çıxaraq ilk statistik təxminini edir. Göründüyü kimi hər 3 cümlə 1991-lə başlayır, bu suala cavab olaraq yazıla biləcək ən yüksək ehtimallı token 1991 olduğu üçün model öz cavabına 1991-lə başlayır. Model sonrakı tokeni təxmin edir, bu çox vaxt boşluq (space) olur, sonrakı token isə ildə sözü olur, çünki datasetində olan cavablarda daha çox “ildə” sözü işlənib, həmçinin bayaqda qeyd etdiyimiz kimi, model dilin tendensiyalarınıda öyrənmiş olur, minlərlə mətndə tarixlərdən sonra “ildə” (və ya “ilində”) sözünün işləndiyini o artıq öyrənib. Yəni bu öyrənmə təkcə pythonla əlaqəli cavablardan yox, həm də dil miqyasındakı nümunələrlə də bağlıdı. Bu modelin təkcə əzbərləmədiyini, ümumiləşdirdiyini də göstərir. Modelin verəcəyi cavab nəticədə “1991-ci ildə buraxıldı” olardı.

Bu prosesdə “temperatur” adlanan parametr də var — bu, modelin nə qədər “yaradıcı” olacağını müəyyən edir. Aşağı temperaturda model təhlükəsiz, gözlənilən cavablar verir. Yüksək temperaturda isə daha riskli, maraqlı, bəzən də qəribə cavablar yaranır.

LLM-lər heyrətamizdir, amma onlar “başa düşmür”. Onların “biliyi” statistik qanunauyğunluqlardır, real dünya təcrübəsi deyil. “Alma qırmızıdır” deyəndə model qırmızı rəngin necə göründüyünü bilmir sadəcə bu sözlərin tez-tez birlikdə işləndiyini “bilir”.

Burada önəmli bir nöqtə var bu modellər; niyətini və hisslərini anlamır. Sadəcə bu sualdan sonra insanlar nə yazardı sualına statistiki bir cavab istehsal edir. Buna görə hər dəfəsində bir sonrakı ən yaxşı tokeni təxmin edir, başa düşmür, əsas vermir, sorğulamır, amma çox yaxşı ümumiləşdirir və ona görədə biz bunu sanki “ağıl yürüdür” kimi başa düşürük.

Buna baxmayaraq, bu texnologiya insan dilini emal etmək və yaratmaq sahəsində inqilabi addımdır. Hər keçən gün daha da təkmilləşir və yeni imkanlar açır. Kim bilir, bəlkə bir gün bu modellər həqiqətən də “anlayacaqlar” — amma hələlik onlar sadəcə çox, çox yaxşı statistiklərdir.

Beləliklə, LLM-lər milyardlarla mətn nümunəsindən öyrənmiş, sözləri rəqəmlərə çevirən və statistik proqnozlar əsasında cavab yaradan mürəkkəb sistemlərdir. Onlar bizim dilimizi “başa düşmürlər”, amma o qədər yaxşı təqlid edirlər ki, fərqi hiss etmək çətindir. Bu isə süni intellektin gücünü bizə göstərməyə bəs edir.

İstinadlar:

1. Vaswani, A. et al. (2017). “Attention Is All You Need”
2. Devlin, J. et al. (2018). “BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding”
3. Brown, T. et al. (2020). “Language Models are Few-Shot Learners”
4. Sennrich, R. et al. (2016). “Neural Machine Translation of Rare Words with Subword Units”
5. Kudo, T. & Richardson, J. (2018). “SentencePiece: A simple and language independent subword tokenizer”
6. Jurafsky, D. & Martin, J.H. “Speech and Language Processing” (3rd Edition)
7. OpenAI Tokenizer Tool
8. Jay Alammar’s Blog — “The Illustrated Transformer”
9. Google’s Multilingual BERT

İnsanların gübrələr haqqında bir çox müxtəlif fikirlərə sahibdir. Bəziləri gübrələrlə pestisidləri qarışdırır, bəziləri mineral gübrələri “kimyəvi gübrə” adlandırır və sanki bunların istifadəsinin dünyanın sonuymuş kimi qələmə verir, bəziləri də deyir düzünə “peyin”. Bu haqda ümumiyyətlə bir çox fikirlər mövcuddur, bir çox fermer onların əvəz olunmaz olduğunu düşünür, bəziləri zərərli olduğunu, bəziləri istifadəsinin heç nəyi dəyişmədiyini. Gəlin doğru cavabı tapmaq üçün, mineral gübrələrin nə olduğunu elmi aspektdən izah edək. Həm də bir bioloqun səpgisindən. Könül istəyərdi Qarabağ nəğməsiylə, “gübrə meşoğunun” tanıtım çarxıyla başlasın bu yazı. Ancaq bir elm adamına yaraşan istinadlar verərək, statistikanı ortaya qoyaraq şəffaf şəkildə öz araşdırmasını, elmi işini, elmi nəticəsini ortaya qoymaqdı. Ancaq bu səfər konsepti biraz dəyişməli oldum. Elə yazacam ki, nə statistika olsun, nə də termin sıxlığı olacaq, elə ki, eşşək oxusa oda başa düşsün. Yenə də bu yazı, yarım-yapalaq oxunmuş, 6-cı sinif biologiya dərsliyindən öyrənilmiş məlumatları satmağa çalışan, onuda düzgün bacarmayan insanların yazdığı ssenaridən daha çox şey ehtiva edəcək. Gəvəzəlik edərək diqqətinizi çəkdimsə gəlin izah verək;

Mineral gübrə nədir?

Mineral gübrələr torpağın məhsuldarlığını artırmaq üçün istifadə olunan qida maddələridir. Onların əsas tərkibində azot, fosfor və kalium olur. Bu elementlərsə öz sırasında təkcə gübrələrdə deyil təbiətin hər yerdə var, Azot nəfəs aldığımız havanın həcmcə 78%-ini təşkil edir. Kalium, fosfor, azot hər üçü onsuzda torpaqda, suda hətta insan orqanizmində də var. Hətta bu elementlər “makroelementdir” və insan orqanizmimizdə baş verən bir çox həyati funksiyanın mərkəzində dayanır; Azot canlılıq üçün ən təməl üzvi maddə olan proteinlərin tərkib hissəsidir. Proteinlər, idmanla məşğul olanların ağlına bu sözü oxuyan saniyə əzələ inkişafı üçün vacib olan “sintetik” məhsul ağıla gəldi. Proteinlərin nə qədər vacib olduğunu dərk etmək üçün gərək bioloq olasan. Azot həm də “DNA və RNA”-nında tərkibində var, (azotlu əsaslar: Adenin, quanin, sitozin, urasil, timin.) bu maddələr olmasa, ümumiyyətlə bu gün nə mən bu mövzunu izah edə bilirdim, nə də siz bunu oxuya bilirdiniz. Kalium elementi olmasaydı, bu mətni nə oxuya bilərdiniz, nə də dərk edə, çünki bu element olmadan sinir impulslarının ötürülməsi mümkün deyil, nə impuls ötürməke, heç nəfəs belə alanmazsınız. Bu element olmadan yaşayanmazsınız. Eynisi Fosfor üçündə keçərlidi, “Hüceyrələrimizin enerji valyutası” hesab olunan ATF-in (Adenozin trifosfat) adından da göründüyü kimi tərkibində fosfor var, əsas məsələ elə fosfordu. Bir sözlə bu elementlər təbiətin hər yerindədir. Başqa sözlə, mineral gübrə tamamilə təbii elementlərin konsentrat halıdır. Yuxarıdan da göründüyü kimi, bu elementlərin nəinki, zərəri var, hətta xeyri var. Əlbəttə hər şey qədərində gözəldi, xeyirlidi. Nizami Gəncəvi demişkən; “Bir inci saflığı varsa da suda, Artıq içiləndə dərd verir o da.”

Niyə zərərsizdi?

Əksər insanlar mineral gübrəni kimyəvi dərman və ya zəhər kimi təsəvvür edir. Halbuki, onlar sadəcə bitkinin qidasıdır. Necə ki, insan sağlam qalmaq üçün vitamin və minerallara ehtiyac duyur, bitkilər də böyümək, məhsul vermək üçün əlbəttə müəyyə maddələrə ehtiyac duyur. Bunlarda yuxarıda qeyd etdiyimiz kimi, azot, fosfor və kalium elementləridir və bu elementləri bitki mineral gübrələrdən rahatlıqla mənimsəyə bilir.

Ən önəmlisi isə budur: düzgün miqdarda istifadə olunduqda mineral gübrələrin nə torpağa, nə məhsula, nə də insan sağlamlığına heç bir mənfi təsiri yoxdur.

Yanlış düşüncələr haradan yaranır?

Bəzən televiziyada, sosial şəbəkələrdə, Enactusun finalında filan, “gübrələnmiş məhsullar zərərlidir” kimi məlumatlar yayılır. Əslində, bu iddiaların kökü daha çox yanlış istifadəyə dayanır. Məsələn, əgər fermer ehtiyacdan artıq gübrə verərsə, torpaqda qalıq maddələr arta bilər. Bu isə artıq aqrotexniki səhvdir, gübrənin özündən qaynaqlanan problem deyil. Düzgün normada istifadə edildikdə isə belə bir risk mövcud olmur. Azərbaycan bazarında düzgün gübrələmə prosesi ilə texnoloji həllər təqdim edən bir çox startap var. Məsələn: https://aqrosphere.com/az/

Mineral gübrələrin faydaları

• Məhsuldarlığı artırır, fermerin zəhmətinin qarşılığını almasına kömək edir.
• Bitkiləri gücləndirir, xəstəliklərə qarşı daha davamlı edir.
• Məhsulun dad və keyfiyyət göstəricilərini yaxşılaşdırır.
• Qida təhlükəsizliyi baxımından insanların kifayət qədər məhsul əldə etməsinə imkan yaradır.

Nəticə

Mineral gübrələr haqqında deyilən mənfi fikirlərin çoxu mifdən ibarətdir. Onlar təbiətdə onsuz da mövcud olan elementlərin sadəcə bitkiyə əlçatan formada təqdim edilməsidir. Elmi araşdırmalar da göstərir ki, normaya uyğun tətbiq edildikdə mineral gübrələrin insan sağlamlığına heç bir ziyanı yoxdur.

Əslində, gübrələrsiz kənd təsərrüfatını təsəvvür etmək çətindir. Onlar həm fermerin, həm də istehlakçının dostudur — çünki sağlam məhsulun arxasında məhz düzgün gübrələmə dayanır.

Uzun sözün qısası, “Qarabağın küləyi güclü, gübrəsi keyfiyyətli olur.”

İstinadlar:

1. Qarabağ küləyi.

2. Enactus Azərbaycan Milli Çempionatının final mərhələsi.

3. Nizami Gəncəvi, Leyli və Məcnun, Az danışmağın gözəlliyi.

Gərək Nizami vaxtında yazardı ki, Bilmirsənsə danışma dinmə, burnun girməyəsi yerə bütün bədəninlə girmə.