Kun meme'i

DNS qanday ishlashini bilasizmi?

Google Chrome dasturini ochdingiz. Search Bar'ga "otabek.io" deb yozib enter tugmasini bosganingizda nimalar sodir bo'ladi? Qanday sodir bo'ladi? Avvalroq yozgan dnsql dasturimni yaxshiladim va Open-Source qilib githubga yukladim.

U yerdagi kontentni o'qib siz ham DNS query resolver dastur yasab ko'rsangiz bo'ladi. Keyinroq bu haqda to'liqroq blog yozishga harakat qilaman.

Contribute uchun ochiqmiz:
Github: https://github.com/otabekswe/

#experience (1-qism)

Senior darajadan keyin sizda odatda 2ta yo'l bo'ladi (kompaniyaga qarab). Biri Management (odamlar bilan ishlash), boshqasi Staff (texnik liderlik). Ikkisida ham o'ziga yarasha qiyinchiliklari bor. Biz ushbu postda Staff Engineer yo'li haqida gaplashamiz.

Staff Engineer bizni kompaniyada 3ta eng asosiy narsaga qarab tanlanadi.
- U bog'liq tizimlarni yaxshi tushunadi (Ownership scope)
- U kompaniyaga nima foyda olib kelishini ko'ra oladi (Impact)
- U bir necha komandalar bilan ishlay oladi (Collabration)

Ishga ilk bor kirganimda onboarding jarayoni uchun 3 oy vaqt berilgandi. Shu 3 oyni men 2 qismga bo'lib chiqdim. 1-oy asosan onboarding bosqichini tugatish. 2 va 3-oy jamoamiz ishlaydigan tizimlarni arxitekturasini ko'rib, undagi komponentlarni o'rganib chiqish. Asosan bergan savolim "why" bo'lgan, "how" emas.

Nega "why"?
Tizmlar va undagi komponentlar nega mavjudligini bilish boshqa ishlardan ancha muhimroq. Nega aynan bu komponent yaratilgan? Nega u bunday algoritm asosida ishlaydi? Nega u error'larni bunday handle qiladi? Bu savollar ancha ko'proq qamrovda savollarga javob bera oladi. Agar shuni "how ...?" ga o'zgaritganimda men tizim qanday ishlashi va qanday handle qilishini bila olardim xolos. Bu faqat texnik savollarga javob beradi xolos, ammo qarorlarni kelib chiqish sababiga hech qachon javob topa olmaysiz. To'g'risini aytaman, tizimlarni qanday ishlashini bilish sizni qimmatbaho dasturchi qilmaydi, chunki bu yodlanadigan bilm, qayta ishlatiladigan bilm emas.

What makes you best engineer?
Men bilgan eng zo'r injinerlarni hammasida 2ta odatni ko'raman. Debugging va yozish. Debugging shunchaki koddagi xatolikni topish emas, balkim tizimni qanday ishlayotganini ko'ra olish degani. Katta tizmlarni yaratish oson bo'lishi mumkin, ammo ularni tuzatish ancha murakkabroq. Tizimni qayerida xatolik bo'layotganini topish va uni ertaroq oldini olish juda katta tajriba talab qiladi. Yaratishdan ko'ra debug qilishga ko'proq vaqtingiz ketadi odatda.

Debug qildingiz endichi? Endi ularni log qilib qo'ying. Ha biror daftaringizni oching va shu xatolik nimaga, qanday sodir bo'lgani va uni tuzatganingiz haqida to'liq yozib qo'ying. Bu juda muhim. Bilmlar xiralashadi. Bugun aniq detallarini ayta olasiz. Ammo kunlar o'tgan sari siz kam-kamdan mayda detallarni unutib boraverasiz. Yozganingizni ertaga o'qib oson yodga solasiz. Yozishni foydalari ko'p. Yozayotganda yaxshiroq yechimlar ham kelishi mumkin (shaxsan o'zimda shunday bo'lib turadi). Yozganingizni ulashish ham osonroq bo'ladi. Yozing.

#security

Yuqoridagi rasm bir ko'rishda Microsoft kompaniyasidan kelganga o'xshaydi. Logo, UI dizayn, hammasi deyarli bir xil.

Mobil telefonga email kelsa odatda kimdan, qanday domain'dan kelganini tekshirmaysiz. Ammo kompyuterdan email o'qisangiz bir qarab qo'yasiz domain'ga.

Bu yerda email microsoft.com dan emas, rnicrosoft.com dan kelgan (tushunmagan bo'lsangiz, yaxshilab o'qing). Mana shu kichik "rn" va "m" o'rtasidagi farq odamlarni oson aldanishiga sabab bo'ladi. Bu xujumni nomi "typosquatting attack" deyiladi.

Xujum qilaytogan odam shunaqa domain register qiladi. Qanchalik yaqinroq typo tanlay olsa unga yutish ehtimolini oshiradi.

Bunday xujumlar tarihda ko'proq HR, finans va shu kabi bo'limlarda ancha qo'l kelgan. Injinerlar jamoasida ham ba'zi muvaffaqiyatli hikoyalar bor ammo juda kam.

Yechim oddiy:
- Biror ish qilishdan oldin, doim domain'ni yaxshilab tekshiring
- Link ustiga bosishdan oldin, link qayerga jo'natayotganini o'qib ko'ring.
- Reply-to degan joyingizni ham tekshiring, ba'zan xabar va javob uchun alohida-alohida manzillar ishlatiladi
- So'ralmagan ishingiz uchun odatda sizga email kelmaydi.

Real hikoya:
2020-yil ilk o'qishga kirgan paytimda O'zbekistondagi va Xitoydagi kursdoshlarimni men ham shunday phishing qilganman. Faqat u yerda Facebook.com ga bo'lgan parollarni olgandim (45ta odamni bergan username va password'i ishlagan). Lekin, ularni sotmaganman shunchaki ularni ogohlikga chaqirganimni hali ham eslayman.

Ogoh bo'ling!

#networking

Nega UDP paketlar yo'qolib qoladi?

Networking bo'yicha bilmi borlar bilan gaplashsangiz TCP vs UDP haqida gapirishadi. Ular UDP haqida gapirishgan paytda uni "reliable" emas deyishadi. Ammo nega unday deyayotganini so'rasangiz javob yo'q. Bilganlar esa nega packet tushib qolishini aytib bera olishmaydi.

1. Tasavvur qiling siz juda ko'p UDP paketlarni bir manzildan ikkinchisiga yuborayabsiz. Har bir UDP socket'da socket sender buffer degan qismi mavjud. Ya'ni paketlar yuborilishdan oldin ayanan o'sha yerga jamlanadi (buffer bu bir vaqtinchalik xotira). Linux kernel bu paketlarni o'qish va yuborish bilan shug'ullanadi. Agar kompyuteringiz yoki serveringizdagi Network Card tezligi past bo'lsa, dasturni tezligiga tusha olmasligi va yuborish jarayonda paketlar yo'qolishi mumkin. Bu qanchalik odatiyligini bilmayman, ammo bunday holatlar bo'lgan.

2. UDP paketlarni internetga yubordingiz (kompyuteringizdan chiqib ketdi hammasi 100% muvaffaqiyatli), u yo'lda, bir router/switch'dan ikkinchisiga o'tish jarayonida yo'qolishi mumkin. Bu yerda router/switch queue limit tugab qolishi mumkin. TCP va UDP paket kelganda TCP paketlarni himoya qilish orqali UDP paketlarni tashlab yuborishi mumkin. Va yana ko'p boshqa sabablar ham bor.

3. Birinchi va ikkinchi bosqich muvaffaqiyatli bo'ldi ham deylik. Ya'ni yo'l yurib, barcha paketlar ohirgi nuqtaga yetib keldi. Endi sizni dasturingiz paketlarni kutib turibdi. Hammasi juda zo'r. Guess what, paketlar qayerga kelib tushadi? Yes, yana o'sha socket sender buffer ga kelishadi. U buffer hajmi qanchalik katta? U barcha paketlarni sig'dira oladimi? Bu savolga to'liqroq bu yerda o'qib ko'ring [link]. Meni kompyuterimda bunday ekan

# Macbook'da
# socket max buffer size
➜  ~ sysctl kern.ipc.maxsockbuf
kern.ipc.maxsockbuf: 8388608

# send/receive buffer size
➜  ~ sysctl net.inet.udp.recvspace
net.inet.udp.recvspace: 786896

Bu raqamlar byte emas, balkim page degani (bu haqda ko'proq keyinroq yozaman). Meni xolatimda har bir page 16KB degani ekan. Demak mendagi max buffer size 8388608 => 8MB ga to'g'ri kelar ekan (8 388 608 / 1024 / 1024 = 8). Standart receive buffer kengligi esa 0.75MB ekan. Demak agar menga katta miqdorda paketlar kirib kelsa va buffer to'lib qolsa 8MB dan buyog'ini tashlab yuborar ekan. Bu yerda application tezligiga ham bog'liq paketlarni saqlab qolish yoki tashlab yuborilishi. Shu paytgacha kompyuterim qancha paketlarni tashlab yuborgan ekan deb qizdim va natija shunday:

➜  ~ netstat -s -p udp
udp:
 141545183 datagrams received
  0 with incomplete header
  0 with bad data length field
  0 with bad checksum
  1048 with no checksum
  45648 checksummed in software
   31046 datagrams (20030730 bytes) over IPv4
   14602 datagrams (3553616 bytes) over IPv6
  159392 dropped due to no socket
  101590 broadcast/multicast datagrams undelivered
  0 IPv6 multicast datagram undelivered
  0 time multicast source filter matched
  9244 dropped due to full socket buffers
  0 not for hashed pcb
  141274957 delivered
 38752867 datagrams output
  415727 checksummed in software
   8977 datagrams (3238427 bytes) over IPv4
   406750 datagrams (117958647 bytes) over IPv6
 40 open UDP sockets

Facebook'da ishlaydigan do'stim bir hikoya aytib bergandi. Facebook’ning “Live” funksiyasi ham UDP'dan foydalanar ekan (RTCP/UDP). 2018-yilda ular serverda recv buffer limiti to‘lganida, Linux kernel UDP paketlarni tashlab yuborish muammosiga duch kelishgan ekan. Monitoringda bu drop’larni faqat server metrikalari orqali ko‘rishganda, foydalanuvchi tarafida video ‘pause’ bo'lishi kuzatilgan ekan. Muammoni sababi net.core.rmem_max juda past bo'lgan ekan. "Live session burst" ya'ni ko'p foydalanuvchilar live ga kirganida socket buffer to'lib ketgan. Yechim sifatida Facebook SRE jamoasi "dynamic UDP buffer autotuning" qo'shishganini aytgandi. Ya'ni kernel sysctl parametrlarini runtime’da trafikga qarab oshirish mumkinligini topishgan. Metrikalarni esa Prometheus bilan qattiq kuzatishgan ekan.

Katta tizmlarda ishlasangiz har bir qarich siz uchun muhimligini sezib borar ekansiz.

#experience

Bir qiziq bug'ni tuzadim. Bizda code base monorepo holida saqlanadi. Ya'ni hamma kodlar bitta repo'da saqlanadi. Bu holda kodlarni test qilish, build qilish, va hokazo operatsiyalarni qo'lda bajarish yoki ularga pipeline yozib ularni boshqarish qiyinlashib boradi. Bunga yechim incremental build systems ishlatish.

Incremental build system ham oddiy dasutr, faqat u kodlaringizni o'zgarishini, dependency control, qaysi qismda o'zgarish bo'lsa faqat o'sha qismni build, test qilishni belgilay oladi. Tasavvur qiling Google, Meta, Dropbox kabi tizmlarda hamma dasturlarni kodlari bitta joyda (monorepo holida) saqlanadi.

Build System alohida Linux machine'larda ishlab turadi. O'zgarishlar bo'lsa kodlar o'sha mashinaga boradi, test, build qilinadi va keyin shunga qarab natijalar bizga ko'rinadi. Bir kun build system service OOM (out of memory) bo'lib qoldi. Memory swap qilishni boshladi. Lekin biz u servislar uchun ajratgan resurslarimiz yetishi kerak edi. Borib tahlil qilishni boshladim. 64GM RAM umumiy xisobda. Hammasi yaxshi. 48GB ram qaysidir process tomonidan ishlatilayotganini ko'rdim. Va yana 16GB OS filesystem cache ham bor edi. OS filesystem cache ni doim tozalay oladi. Lekin bu holatda nimaga swap qilayotganini tushuna olmadim.

swappiness degan narsa haqida google qilib o'rgandim. Agar swappiness qiymati baland bo'lsa swap qilishni boshlar ekan. Bizdagi config 2 ko'rsatayotgan edi va men uni sysctl vm.swappiness=1 ga set qildim. Lekin shunda ham swap qilishda davom etaverdi. Swapni o'chirib qo'ydik, ancha ahvol yomonlashdi. Process'lar OOM berishni boshladi. OOM berganda Linux uni kill qiladi (to'xtatadi). O'zimga "why? why?" deb bir idea kelib qoldi.

Esingizda bo'lsa docker minimal versiyasini yasab ko'rganim haqida aytgandim. Ha o'sha tajriba qo'l keldi. Hamma gap cgroup da edi. Buni rostligini tekshirish uchun dmesg ni tekshirdim, voila javob topildi. Bug topildi. Aynan bizga kerakli ishlab turgan process'lar limiti past bo'lgan cgroup ga tushib qolganini ko'rib ich-ichimdan xursand bo'lib ketdim. I wanted to scream like "Technologia, I found the bug".

Ba'zan qilgan eksperimentlarim ko'p azq otadi. Peace!

Updated: Bu voqeaga ancha bo'lgan lekin hozir yozgim kelib qoldi. Balkim shu ham promoga yordam bo'lgandir, who knows

Har qanday loyiha ma'lumotlar bilan ishlaydi. Va ma'lumotlar omborini tushunish tizimni eng kerakli qismini tushunishdan iborat.

Shu paytgacha topishgan ba'zi kompaniyalarimda ma'lumotlar ombori haqida qiziq muhokamalar olib borganmiz. Ba'zilarida men intervyu oluvchiga o'rgatganman. Ya'na ba'zilarida intervyu oluvchidan o'rganganman (ya'ni uni savoliga javob bera olmay, keyingi intervyuga javob topib borganman).

Ulardan ba'zilar:
- Siz biror table'ni index qildingiz, ammo undan ma'lumot olmoqchi bo'lganingizda index'dan qidirmayabdi? Bunda nima qilasiz?
- Tasavvur qiling siz ko'p tranzaksiyalar bajaruvchi tizmda ishlaysiz. Ikki va undan ko'p tranzaksiya bir vaqtda bitta row'ni yangilashga urinsa (update) nima qilasiz? Qaysi qiymatni qabul qilishni qanday qaror qilasiz?
- Trazaksiya paytida biror xodisa yuz bersa, ammo ma'lumotlar ombori COMMIT qilganizni tasdiqlasayu ammo ma'lumotlar yo'qligiga guvoh bo'lsangiz nima qilasiz?
- Primary Key va Secondary Key o'rtasida nima farq bor? Ularni qachon ishlatmagan bo'lardingiz?
- Database recover qilgan paytingiz haqida gapirib bering? Qanday backup qilgansiz? Nima uchun unday qilgansiz? Va recover process qanday bo'lgandi? Zarar nimada bo'lgandi?
- Izolyatsiya darajasi REPEATABLE READ'da bo'lsa ham, siz PHANTOM READ'dagi o'zgarishlarni ko'ra olasiz. Ammo nega ekanligni tushuntirib bering?
- Column vs Row DBlar o'rtasidagi farq nimada?
- Sizda 1 millardlik jadval bor. U tez-tez yangilanib turadi. Qatorlar sonini xisoblash uchun nima qilasiz? (Materialized View va denormalization o'rtasidagi trade-offs)

Bu savollarga javob topish uchun ba'zi ochiq va yopiq darslarni ko'rib chiqishingiz mumkin:
42.uz/course/express-database

To’liq kurs 1 Dekabr oyida chiqadi. Hozir ulgurib qoling, keyin narx o’zgaradi.

Build Your First Model

O'zingizni ilk Machine Learning modelingizni yaratib ko'rishni o'ylaganmisiz? Unda ushbu blog siz uchun. Nimalarni o'rganamiz?

· Machine Learning ortidagi Matematika siz o'ylaganchalik qiyin emasligini
· Modelni 0dan, hech qanday kutubxonalarsiz qurishni (kodingizni otabek.io da sahifada ishlatib ko'rsangiz bo'ladi)
· Va weight ni topishni turli xil yo'llarini ko'rib o'tamiz.

Ushbu blogdan keyin biror yaxshiroq erkin loyiha qila olishingizga ishonaman. Sinab ko'ring

Batafsil: otabek.io/blogs/build-your-first-model

#shortBlog

Isolation ma'lumotlar omborini go'zal tamoyillaridan biri deb bilaman. Bir nechta tranzaksiya bir-birini blok qilib qo'ymasligi uchun ajoyib yechimlar qilingan. Sezganingizdek Pessimistic Locking va Optimistic Locking mexanizmlari haqida gap ketayabdi.

Pessimistic Locking

Tranzaksiya A obyektni o'qishi yoki yozishidan oldin. Unga (Lock) qulf qo'yadi. Agar Tranzaksiya B o'sha obyektni ustida biror ish qilmoqchi bo'lsa, uni tugashini va qulfni olib tashlashini kutishi kerak bo'ladi. Bu yechimni yomon tomoni, agar ko'p tranzaksiyalar bir-birini kutib qolsa (Deadlock), tizim qotib qolishi mumkin.

Optimistic Locking

Multi-Version Concurrency Control mehanizmi yuqoridagi muammoni yanada yaxshiroq yechish uchun qilingan. Men uni Time Travel deb atayman. Nega unday? Chunki biz multi dimension olamda yashaybamiz (quantum physics aytishi bo'yicha). Bu yechimdagi go'zallik, DB barcha tranzaksiyalar qilgan o'zgarishlarni saqlab boradi. Qachonki Tranzaksiya A boshlansa, DB hozirgi holatidan "Snapshot" oladi. Tranzaksiya B ham boshlanib, biror qiymatni o'zgartirsa, u ham o'zidagi versiyani o'zgartirgan bo'ladi. Tranzaksiya A ga hech qanday zarar o'tmaydi. Read qilayotganlar ham, Write qilayotganlar ham bir-birini blok qilmaydi.

Bu ikkisi ham trade-off. Pessimistic Locking'da tizimni qotirib qo'yishingiz mumkin bo'lsa, Optimistic Locking'da juda ko'p xotira ishlatishni boshlaysiz. Undan tashqari Timestamp Ordering, 2PL, SSI, DCC, Token-Based / Lease-Based kabi yechimlar ham bor. O'rganishni maslahat beraman. System Design intervyularda o'qigan kitoblaringiz emas, texnik bilmlaringiz va ularni ishlata olishingiz ko'proq azq otadi.

Internet ortidagi mo'jizani o'zingiz tushunib, va o'rgangan bilmlar asosida ularni qayta ixtiroq qilishni istaysiz. Ammo qayerdan boshlashni bilmaysizmi?

- DNS query
- HTTP protokoli
- Xavfsiz va tezkor API
- Sniffing tool (hacking uchun)
- Speedbumper
- Proxy (Nginx ga o'xshagan)
- Ngrok (Tunneling service)
- Real-time tizimlar (oz resurs, ko'p connection)
- ... va h.k.z larni 0dan quramiz (kutubxonalarsiz)

Bu yerdan boshlasangiz bo'ladi: 42.uz/course/express-networking

Hacking va Security bo'limida o'rgatilgan barcha bilm va amaliyotlarni faqat yaxshi yo'lda sarflaysiz deb umid qilaman

#experience

Yillar davomida o’rgangan ba’zi bilmlarimdan:

- Abstraksiya funksiya yoki servis qanday ishlashiga emas, nima bersangiz nima olishingiz mumkinligiga diqqatingizni qaratadi. Bu ba’zan sizga tizimni murakkabligini soddaroq tushinb qurishga yordam qilsa, ba’zan sizga qimmatga tushishi mumkin. On-call, o’zbek tilida navbatchilik deymiz. Infra, cloud jamoalarda ishlaydiganlar odatda buni yaxshi bilishadi. Aynan navbatchilik paytida bizga yoqmaydigan fundamental “algoritmlar”, “data structure”, “low-level”, “matematika”, “networking”, “database”, “operating systems” va h.k.z bilmlar juda kerak bo’lishini ko’p guvohi bo’lasiz. Insonlar mukammallikdan uzoq bo’lgani kabi, ular yozgan dasturlar, kodlar, kitoblar va asarlar ham huddi shunday ekan.

- Kod yozishdan ko’ra ko’proq kodni o’chirish qiyinroq va ko’proq xavfsizlik keltirar ekan. Shu paytgacha 20 238 qator kod o’chirdim. Jamoa bu ishimdan juda hursand bo’ldi. Pul, asab va energiya tejadik. Qanday? Endi bu servis hech qachon buzilmaydi, biz uni soatlab “nima bo’ldi ekan?” deb kuzatmaymiz/tuzatmaymiz. Ota-bobolarimiz aytganidek “eng yaxshi kod bu yozilmagan kod”.

- Yiqilishdan qo’rqmaydiganlar ko’p yutar ekan. Qiziqishlarim menga juda qimmatga tushgan. Dadam olib bergan o’sha $500 lik kompyuterni chuqalab $50 ga sotganimiz, startup quraman deb cloudga to’lagan oxirgi $4000 pulim, system dizayni amaliyot qilib o’rganaman deb ketkazilgan vaqt (20ta kitob o’qib yodlash mumkin edi bu vaqtga), production’da qilingan xatolik va eksperimentlar, ehh gapirsa tugamaydigandek. Lekin barchasi Otabekni shu yergacha kelishiga o’z xissasini qo’shgan. Dastur muammosiz ishlasa o’smaysiz. Istalgan kompaniya ham shuncha odamni bekorga ishlatmaydi. Xatolar va muammolar bizni bor qilib turibdi, buzishdan qo’rqmang. Ammo buzg’unchi bo’lmang.

- Yaxshi do’stlar ortdiring va qiymat bering. Blog yozib ham do’st orttirish mumkin ekan. Hozirda minglab do’slarim (sizlar) shu blogimni foydasi bor deb o’qishadi. Ba’zilar “qiziqshim oshadi sizni blogizni o’qisam” desa, yana ba’zilar “senior bo’lishda/ishga kirishimda yordam qildi blogingiz” deydi. Ha “nima deyabsan o’zing tushunayabsanmi?” deydiganlar ham topiladi. Ammo foydasi tegayabdi, shunisidan xursandman.

Xullas qisqacha shular.

Oddiy dasturchi emas, o’z ishini maromiga yetkazib, oshig’i bilan qiladigan inson sifatida shakllaning. Mavzularni “ish topish” uchun emas, sohaga yangilik qilish va katta muammolarni tushunish, ularni yecha olish uchun o’rganing.

Faqat gap yoki taklif emas, sizga darslik ham bermoqchiman. HTTP ni ishlatib serverlar qurasizu lekin, uni ostidagi jarayonni tushunmasligingiz mumkin. Ammo bugundan bular o’zgarishini va bunga o’z xissam qo’shilishini istayman.

Hech bir qurgan loyiham cho’ntagim uchun qilinmagan. Bo’lmasa bu blogni ham tekinga o’qimasdingiz, men otabek.io ni palon pulga sotib olmasdim. Tajribalar oddiydir lekin bular men uchun bir qiyinchilik ortidagi hikoyalar. (Siz shunday emassiz lekin shunday fikrlaydiganlar yetarlicha ekan)

• HTTPni 0dan quramiz - Go dasturlash tilida
• HTTPni 0dan quramiz - Python dasturlash tilida

yoki

• otabek.io/lectures

Faqat Java/Node.js yo’q ekan demang. O’rganing va qiling, omad : )

Bu bilmni ulashing, zora ko’plab dasturchilarga qiziqish uyg’otishda foydamiz tegsa

Build your first model postidan keyin AI/ML o’rganish bo’yicha savollar va maslahat so'rashlar yanada ko'paydi. Hozir trendda bo'lgani uchun bo'lsa kerak. Qisqacha tajribam haqida aytib beray.

2-yil oldin o’sha ilmiy ishni (research paper) o’qib hech narsa tushunmagandim. Bu ilmiy ish haqida Andrej Karpathy juda zo’r video darslik chiqargan. Yaqinda (o’tgan yili) amaliy tarzda, videolarga qaramasdan kichik progress qila oldim.

Generative Pre-trained Transformers (GPT) qurishni va transformer’lar hozirgi LLMlarni kengaya olishidagi o’rnini, attention mexanizmi haqida ko’plab o’rganasiz.

Bundan oldin Recurrent Neural Network (RNN) va LSTM degan modellardan foydalanishgan. Muammo, ular juda sekin, kengayishga qiyin va unutuvchan bo’lgan. Model promptni so’zma-so’z o'qiydigan bo'lgan, agar gap uzun bo’lsa gapni boshini unutib qo’yardi.

Transformer’lar esa bunga ajoyib yechim berishadi. Ular so’zma-so’z o’qish o’rniga butun gapni bittada o’qiydi. Va Self-Attention mexanizmi orqali gapdagi so’zlar bir-biriga qanday bog’liqligi borligini xisoblab ko’radi.

Misol uchun “I didn't eat the food on the table because it wasn’t delicious” gapidagi “it” nimani bildirayotganini bilishingiz kerak. Bu yerda u ovqatga "food"ga nisbatan kelayabdi, "table" so'ziga emas.

Xullas bu model tezroq LLMlarni train qilishga va kengaya olishiga sababchi bo’lgan. Xullas qisqasi transformer gapni “Attention” mexanizmi orqali outputga aylantirishini yaxshilab tushunib olasiz. Balkim keyingi eng zo'r GPT modellarni siz qurarsiz, who knows.

Attention is all you need

Flow - Stay in your flow

Maqsadlaringizga erishishingiz uchun yordamchi.

Tez kunda