Model tanlash

Oxir-oqibat, sizni qaysi model eng zo'r ekanligi unchalik qiziqtirmaydi. Sizni qaysi model aynan sizning dasturlaringiz uchun eng yaxshi ekanligi qiziqtiradi. Dasturingiz uchun mezonlarni aniqlab olganingizdan so'ng, siz modellarni aynan shu mezonlar asosida baholashingiz kerak.

Dasturni ishlab chiqish jarayonida, turli moslashtirish texnikalari orqali olg'a siljir ekansiz, model tanlashni qayta-qayta amalga oshirishingizga to'g'ri keladi. Masalan, prompt muhandisligi imkoniyatni baholash uchun umumiy hisobda eng kuchli modeldan boshlanishi, keyin esa kichikroq modellar ham ish berishini tekshirish uchun orqaga qarab yurishi mumkin. Agar siz finetuning qilishga qaror qilsangiz, kodingizni sinab ko'rish uchun kichik modeldan boshlashingiz va keyin qurilmangiz ta'minoti cheklovlariga (masalan, bitta GPU'ga) sig'adigan eng katta modelga o'tishingiz mumkin.

Umuman olganda, har bir texnika uchun tanlov jarayoni odatda ikki bosqichni o'z ichiga oladi:

1. Erishish mumkin bo'lgan eng yaxshi samaradorlikni aniqlash.
2. Modellarni xarajat-samaradorlik o'qlari bo'ylab joylashtirish va pulingizga arziydigan eng yaxshi samaradorlikni beradigan modelni tanlash.

Biroq, haqiqiy tanlov jarayoni ancha nozikroq. Keling, uning qanday ko'rinishda bo'lishini o'rganamiz.

Model tanlash ish oqimi

Modellarni ko'rib chiqayotganda, qat'iy atributlar (o'zgartirishingiz imkonsiz yoki amaliy jihatdan mumkin bo'lmagan xususiyatlar) va yumshoq atributlarni (o'zgartirishingiz mumkin bo'lgan va o'zgartirishga tayyor bo'lgan xususiyatlar) farqlash muhimdir.

Qat'iy atributlar ko'pincha model provayderlari tomonidan qabul qilingan qarorlar (litsenziyalar, o'qitish ma'lumotlari, model hajmi) yoki sizning o'zingizning siyosatingiz (maxfiylik, nazorat) natijasidir. Ba'zi ishlatilish senariylari uchun qat'iy atributlar potensial modellar ro'yxatini sezilarli darajada qisqartirishi mumkin.

Yumshoq atributlar — bu to'g'rilik, toksiklik yoki faktik izchillik kabi takomillashtirilishi mumkin bo'lgan atributlardir. Ma'lum bir atributni qanchalik yaxshilashingiz mumkinligini taxmin qilishda, optimistik bo'lish va realist bo'lish o'rtasidagi muvozanatni topish qiyin bo'lishi mumkin. Menda bir necha dastlabki promptlar uchun modelning to'g'riligi 20% atrofida bo'lgan holatlar bo'lgan. Biroq, vazifani ikki bosqichga ajratganimdan so'ng, to'g'rilik 70% ga sakragan. Shu bilan birga, bir necha hafta sozlashdan keyin ham model mening vazifam uchun yaroqsiz bo'lib qolgan va men o'sha modeldan voz kechishga majbur bo'lgan holatlarim ham bo'lgan.

Nimani qat'iy va nimani yumshoq atribut deb belgilashingiz ham modelga, ham sizning ishlatilish senariyingizga bog'liq. Masalan, agar siz modelni tezroq ishlashi uchun optimallashtirish imkoniga ega bo'lsangiz, kechikish yumshoq atributdir. Agar siz boshqa birovning serverida ishlaydigan modeldan foydalansangiz, u qat'iy atributdir.

Yuqori darajada, baholash ish oqimi to'rt bosqichdan iborat (4-5-rasmga qarang):

1. Qat'iy atributlari sizga to'g'ri kelmaydigan modellarni saralab tashlash. Sizning qat'iy atributlar ro'yxatingiz ko'p jihatdan o'zingizning ichki siyosatingizga, tijorat API'laridan foydalanishni yoki o'z modelingizni ishlatishni xohlashingizga bog'liq.
2. Tajriba o'tkazish uchun eng istiqbolli modellarni saralab olish maqsadida, ochiq mavjud bo'lgan ma'lumotlardan, masalan, benchmark natijalari va reyting jadvallari reytingidan foydalanish. Bunda model sifati, kechikish va xarajat kabi turli maqsadlarni muvozanatlash kerak.
3. Eng yaxshi modelni topish uchun o'zingizning shaxsiy baholash jarayonlari ketma-ketligingiz bilan tajribalar o'tkazish. Bu yerda ham barcha maqsadlaringizni muvozanatlash talab etiladi.
4. Nosozliklarni aniqlash va dasturingizni yaxshilash uchun fikr-mulohazalarni yig'ish maqsadida modelingizni real amaliyotda doimiy ravishda kuzatib borish.

Bu to'rt bosqich bir-birini takrorlab turuvchi, ya'ni iterativ jarayondir. Har bir keyingi bosqichda olingan yangi ma'lumotlar sizni avvalgi qadamdagi qaroringizni qayta ko'rib chiqishga undashi mumkin. Tasavvur qiling, siz dastlab ochiq manbali modellarni ishlatishga qaror qildingiz. Biroq, ochiq va xususiy baholashlardan so'ng, ochiq manbali modellar siz kutgan samaradorlik darajasini bera olmasligini anglab yetasiz va natijada tijorat API'lariga o'tishga majbur bo'lasiz.

Monitoring va foydalanuvchi fikr-mulohazalarini yig'ish masalalari 10-bobda batafsil ko'rib chiqiladi. Ushbu bobning qolgan qismida esa biz dastlabki uchta bosqichga e'tibor qaratamiz. Ishni aksariyat jamoalar qayta-qayta duch keladigan savoldan boshlaymiz: model API'laridan foydalangan ma'qulmi yoki modellarni o'z serverlarida ishlatgan afzalmi? Shundan so'ng, son-sanoqsiz ochiq benchmarklar olamida qanday adashib qolmaslik va nima uchun ularga ko'r-ko'rona ishonib bo'lmasligi haqida so'z yuritamiz. Bu muhokamalar bobning so'nggi, asosiy qismi uchun zamin yaratadi. Zero, ochiq benchmarklarga to'liq tayanish mumkin bo'lmagan sharoitda, siz o'zingiz ishonadigan promptlar va metrikalar asosida shaxsiy baholash jarayonlari ketma-ketligini loyihalashingizga to'g'ri keladi.

O'zi yaratishmi yoki sotib olishmi?

Har qanday texnologiyadan foydalanishda kompaniyalar uchun doimiy savol — uni o'zi yaratish kerakmi yoki sotib olish kerakmi. Aksariyat kompaniyalar fundamental modellarni noldan yaratmasligi sababli, savol quyidagicha qo'yiladi: tijoriy model API'laridan foydalanish kerakmi yoki ochiq manbali (open source) modelni o'zingiz ishlatishingiz kerakmi. Bu savolning javobi sizning nomzod modellar havzangizni sezilarli darajada qisqartirishi mumkin.

Keling, avval modellar haqida gap ketganda ochiq manbali deganda aynan nimani anglatishini ko'rib chiqamiz, so'ngra bu ikki yondashuvning afzalliklari va kamchiliklarini muhokama qilamiz.

Ochiq manbali, ochiq parametrli va model litsenziyalari

"Ochiq manbali model" atamasi bahsli bo'lib qoldi. Dastlab, bu atama odamlar yuklab olishi va ishlatishi mumkin bo'lgan har qanday modelni anglatardi. Ko'pgina ishlatilish senariylari uchun modelni yuklab olishning o'zi yetarli. Biroq, ba'zi odamlar model samaradorligi asosan u qanday ma'lumotlarda o'qitilganiga bog'liq bo'lgani uchun, model faqat uning o'qitish ma'lumotlari ham ommaga ochiq bo'lgandagina "ochiq" deb hisoblanishi kerak, deb ta'kidlashadi.

Ochiq ma'lumotlar modeldan yanada moslashuvchan foydalanish imkonini beradi, masalan, modelni model arxitekturasi, o'qitish jarayoni yoki o'qitish ma'lumotlarining o'ziga o'zgartirishlar kiritib, noldan qayta o'qitish. Ochiq ma'lumotlar, shuningdek, modelni tushunishni osonlashtiradi. Ba'zi ishlatilish senariylari, shuningdek, audit maqsadlarida o'qitish ma'lumotlariga kirishni talab qiladi, masalan, modelning buzilgan yoki noqonuniy olingan ma'lumotlarda o'qitilmaganiga ishonch hosil qilish uchun.¹

Ma'lumotlarning ham ochiq yoki yo'qligini bildirish uchun, ochiq ma'lumotlar bilan birga kelmaydigan modellar uchun "ochiq parametrli" (open weight) atamasi, ochiq ma'lumotlar bilan birga keladigan modellar uchun esa "ochiq model" (open model) atamasi ishlatiladi.

Ushbu kitob yozilayotgan vaqtda, ochiq manbali modellarning aksariyati faqat ochiq parametrli (open weight) hisoblanadi. Model yaratuvchilari o'qitish ma'lumotlarini ataylab yashirishlari mumkin, chunki bu ma'lumotlar ularni jamoatchilik tanqidi va ehtimoliy sud da'volariga duchor qilishi mumkin.

Ochiq manbali modellarning yana bir muhim atributi — bu ularning litsenziyalaridir. Fundamental modellardan oldin ham, MIT, Apache 2.0, GNU General Public License (GPL), BSD (Berkely Software Distribution), Creative Commons va hokazo kabi turli xil litsenziyalar bilan ochiq manbalilik dunyosi yetarlicha chalkash edi. Ochiq manbali modellar litsenziyalash vaziyatini yanada yomonlashtirdi. Ko'pgina modellar o'zlarining noyob litsenziyalari ostida chiqariladi. Masalan, Meta Llama 2'ni Llama 2 Community License Agreement ostida va Llama 3'ni Llama 3 Community License Agreement ostida chiqardi. Hugging Face o'zining BigCode modelini BigCode Open RAIL-M v1 litsenziyasi ostida chiqardi. Biroq, umid qilamanki, vaqt o'tishi bilan hamjamiyat ba'zi standart litsenziyalarga yaqinlashadi. Google'ning Gemma va Mistral-7B modellari ham Apache 2.0 litsenziyasi ostida chiqarildi.

Har bir litsenziyaning o'z shartlari bor, shuning uchun har bir litsenziyani o'z ehtiyojlaringiz uchun baholash sizga bog'liq. Biroq, mana, menimcha, har kim so'rashi kerak bo'lgan bir nechta savollar:

• Litsenziya tijorat maqsadlarida foydalanishga ruxsat beradimi? Meta'ning birinchi Llama modeli chiqqanda, u notijorat litsenziyasi ostida edi.
• Agar u tijorat maqsadlarida foydalanishga ruxsat bersa, biror cheklovlar bormi? Llama-2 va Llama-3 litsenziyalari oylik 700 milliondan ortiq faol foydalanuvchiga ega bo'lgan dasturlar Meta'dan maxsus litsenziya talab qilishini belgilaydi.²
• Litsenziya model natijalaridan boshqa modellarni o'qitish yoki takomillashtirish uchun foydalanishga ruxsat beradimi? Mavjud modellar tomonidan generatsiya qilingan sintetik ma'lumotlar kelajakdagi modellarni o'qitish uchun muhim ma'lumot manbaidir (8-bobda boshqa ma'lumotlar sintezi mavzulari bilan birga muhokama qilinadi). Ma'lumotlar sintezining ishlatilish senariylaridan biri — bu model distillatsiyasi (model distillation): shogirdga (odatda ancha kichikroq model) ustozning (odatda ancha kattaroq model) xulq-atvorini taqlid qilishni o'rgatish. Mistral dastlab bunga ruxsat bermagan, ammo keyinroq o'z litsenziyasini o'zgartirgan. Ushbu kitob yozilayotgan vaqtda, Llama litsenziyalari hali ham bunga ruxsat bermaydi.³

Ba'zi odamlar cheklangan litsenziyalarga ega bo'lgan ochiq manbali modellarni nazarda tutib, "cheklangan parametrli" (restricted weight) atamasini ishlatishadi. Biroq, men bu atamani noaniq deb bilaman, chunki barcha oqilona litsenziyalarda cheklovlar mavjud (masalan, siz modeldan genotsid sodir etish uchun foydalana olmasligingiz kerak).

Ochiq manbali modellar va model API'larini taqqoslash

Model foydalanuvchilar uchun ochiq bo'lishi uchun, biror qurilma uni o'zida ishga tushirib, xizmat ko'rsatishi kerak. Modelni ishlatadigan, foydalanuvchi so'rovlarini qabul qiladigan, so'rovlar uchun javoblar generatsiya qilish uchun modelni ishga tushiradigan va bu javoblarni foydalanuvchilarga qaytaradigan xizmat inference xizmati (inference service) deb ataladi. Foydalanuvchilar ishlaydigan interfeys esa model API'si deb ataladi (4-6-rasm). Model API'si atamasi odatda inference xizmatining API'sini anglatadi, ammo boshqa model xizmatlari uchun ham API'lar mavjud, masalan, finetuning API'lari va baholash API'lari. 9-bobda inference xizmatlarini qanday optimallashtirish muhokama qilinadi.

Modelni ishlab chiqqandan so'ng, ishlab chiquvchi uni ochiq manbali qilishni, API orqali ochiq qilishni yoki ikkalasini ham tanlashi mumkin. Ko'plab model ishlab chiquvchilari ayni paytda model xizmatlari provayderlari hamdir. Cohere va Mistral ba'zi modellarni ochiq manbali qiladi va ba'zilari uchun API'lar taqdim etadi. OpenAI odatda o'zining tijoriy modellar bilan tanilgan, ammo ular ham ochiq manbali modellar chiqargan (GPT-2, CLIP). Odatda, model provayderlari zaifroq modellarni ochiq manbali qiladi va o'zlarining eng yaxshi modellarini pullik devorlar (paywalls) ortida, yo API'lar orqali, yo o'z mahsulotlarini quvvatlantirish uchun saqlaydi.

Model API'lari model provayderlari (OpenAI va Anthropic kabi), bulut xizmatlari provayderlari (Azure va GCP [Google Cloud Platform] kabi) yoki uchinchi tomon API provayderlari (Databricks Mosaic, Anyscale va hokazo) orqali mavjud bo'lishi mumkin. Bir xil model turli xil xususiyatlar, cheklovlar va narxlar bilan turli API'lar orqali mavjud bo'lishi mumkin. Masalan, GPT-4 ham OpenAI, ham Azure API'lari orqali mavjud. Turli API'lar orqali taqdim etilgan bir xil modelning samaradorligida biroz farqlar bo'lishi mumkin, chunki turli API'lar ushbu modelni optimallashtirish uchun turli texnikalardan foydalanishi mumkin, shuning uchun model API'lari o'rtasida o'tishda puxta testlar o'tkazganingizga ishonch hosil qiling.

Tijoriy modellar faqat ularning ishlab chiquvchilari tomonidan litsenziyalangan API'lar orqali ochiqdir.⁴ Ochiq manbali modellar esa istalgan API provayderi tomonidan qo'llab-quvvatlanishi mumkin, bu sizga o'zingiz uchun eng yaxshi ishlaydigan provayderni tanlash imkonini beradi. Tijoriy model provayderlari uchun modellar ularning raqobatbardosh ustunligidir. O'z modellariga ega bo'lmagan API provayderlari uchun esa, API'lar ularning raqobatbardosh ustunligidir. Bu shuni anglatadiki, API provayderlari yaxshiroq narxlar bilan yaxshiroq API'lar taklif qilishga ko'proq intilishi mumkin.

Kattaroq modellar uchun miqyoslanadigan inference xizmatlarini yaratish oson ish bo'lmagani uchun, ko'plab kompaniyalar ularni o'zlari yaratishni xohlamaydi. Bu ochiq manbali modellar ustiga qurilgan ko'plab uchinchi tomon inference va finetuning xizmatlarining yaratilishiga olib keldi. AWS, Azure va GCP kabi yirik bulut provayderlarining barchasi ommabop ochiq manbali modellarga API orqali kirishni ta'minlaydi. Ko'plab startaplar ham xuddi shunday qilmoqda.

Modelni o'zingiz ishlatish yoki model API'sidan foydalanish haqidagi savolning javobi ishlatilish senariysiga bog'liq. Shuningdek, bir xil ishlatilish senariysi vaqt o'tishi bilan o'zgarishi mumkin. Ushbu, ko'rib chiqilishi kerak bo'lgan yettita yo'nalish: ma'lumotlar maxfiyligi, ma'lumotlar shajarasi, samaradorlik, funksionallik, xarajatlar, nazorat va qurilmada joriy etish.

Ma'lumotlar maxfiyligi

Ma'lumotlarini tashkilot tashqarisiga chiqara olmaydigan va maxfiylikka oid qat'iy siyosatga amal qiladigan kompaniyalar uchun tashqi provayderlar tomonidan taqdim etiladigan model API'laridan foydalanish mutlaqo nomaqbuldir.⁵ Bunga yorqin misollardan biri sifatida Samsung xodimlarining kompaniyaga tegishli maxfiy ma'lumotlarni ChatGPT'ga kiritib, oqibatda tijoriy sirlarni bexosdan fosh qilib qo'ygan holatini keltirish mumkin.⁶ Samsung ushbu ma'lumot sizib chiqishini qanday aniqlagani va fosh bo'lgan axborot kompaniyaga qarshi qay tarzda ishlatilgani noma'lum. Shunga qaramay, voqea shu qadar jiddiy tus olganki, Samsung 2023-yil may oyida ChatGPT'dan foydalanishni taqiqlab qo'ydi.

Ba'zi mamlakatlarda muayyan turdagi ma'lumotlarni davlat chegarasidan tashqariga yuborishni taqiqlovchi qonunlar mavjud. Agar model API provayderi bunday mijozlarga xizmat ko'rsatishni istasa, u o'sha mamlakatlar hududida o'z serverlarini o'rnatishiga to'g'ri keladi.

Agar siz model API'sidan foydalansangiz, API provayderi sizning ma'lumotlaringizdan o'z modellarini o'qitish uchun foydalanishi xavfi mavjud. Garchi aksariyat model API provayderlari bunday qilmasliklarini da'vo qilishsa-da, ularning siyosati o'zgarishi mumkin. 2023-yil avgust oyida Zoom kompaniyasi o'zining foydalanish shartlarini bildirmasdan o'zgartirgani ma'lum bo'lgach, jiddiy noroziliklarga duch keldi. Yangi shartlarga ko'ra, Zoom foydalanuvchilar tomonidan yaratilgan ma'lumotlardan, jumladan, mahsulotdan foydalanish statistikasi va diagnostika ma'lumotlaridan o'zining SI modellarini o'qitish uchun foydalanish huquqini olgan edi.

Xo'sh, kimningdir sizning ma'lumotlaringizdan o'z modellarini o'qitish uchun foydalanishining nimasi yomon? Bu sohadagi tadqiqotlar hali kam bo'lsa-da, ba'zi ilmiy ishlar SI modellari o'zlarining o'qitish namunalarini "yodlab qolishi" mumkinligini ko'rsatmoqda. Masalan, Hugging Face kompaniyasining StarCoder modeli o'zining o'qitish to'plamining 8 foizini yodlab qolgani aniqlangan. Bunday yodlab qolingan namunalar 5-bobda ko'rsatib o'tilganidek, tasodifan boshqa foydalanuvchilarga sizib chiqishi yoki yomon niyatli shaxslar tomonidan ataylab suiiste'mol qilinishi mumkin.

Ma'lumotlarning kelib chiqishi va mualliflik huquqi

Ma'lumotlarning kelib chiqishi va mualliflik huquqi bilan bog'liq xavotirlar kompaniyalarni turli yo'nalishlarga undashi mumkin: ba'zilari ochiq manbali modellarga yuzlanadi, boshqalari xususiy modellarni tanlaydi, ayrimlari esa har ikkisidan ham voz kechadi.

Aksariyat modellar qanday ma'lumotlar asosida o'qitilgani haqida shaffoflik deyarli yo'q. Gemini'ning texnik hisobotida Google modelning samaradorligi haqida batafsil to'xtalgan, biroq uni o'qitishda ishlatilgan ma'lumotlar haqida “ma'lumotlarni boyitishga jalb qilingan barcha xodimlarga kamida mahalliy yashash uchun yetarli ish haqi to'lanadi” degan jumladan boshqa hech narsa demagan. OpenAI'ning texnik direktori (CTO) o'z modellarini o'qitish uchun qanday ma'lumotlardan foydalanilgani haqidagi savolga qoniqarli javob bera olmadi.

Bundan tashqari, SI sohasidagi Intellektual Mulk (IP) qonunchiligi faol rivojlanish bosqichida. Garchi 2024-yilda AQSh Patent va Savdo Belgilari Idorasi (USPTO) “SI yordamida yaratilgan ixtirolar to'g'ridan-to'g'ri patentlashdan mahrum etilmaydi” deb aniqlik kiritgan bo'lsa-da, SI ilovasining patentga loyiqligi “innovatsiyaga inson tomonidan qo'shilgan hissa patent olish uchun yetarlicha salmoqli ekanligiga” bog'liq. Shuningdek, agar model mualliflik huquqi bilan himoyalangan ma'lumotlar asosida o'qitilgan bo'lsa va siz bu modeldan o'z mahsulotingizni yaratishda foydalansangiz, o'z mahsulotingizning Intellektual Mulkini himoya qila olishingiz ham dargumon. Faoliyati o'z Intellektual Mulkiga bog'liq bo'lgan ko'plab kompaniyalar, masalan, o'yin va kino studiyalari, SI atrofidagi Intellektual Mulk qonunlariga aniqlik kiritilmaguncha, o'z mahsulotlarini yaratishda SI'dan foydalanishga ikkilanmoqda (James Vincent, The Verge, 2022-yil 15-noyabr).

Ma'lumotlarning kelib chiqishi bilan bog'liq xavotirlar ba'zi kompaniyalarni o'qitish ma'lumotlari ommaga e'lon qilingan to'liq ochiq modellarga yuzlanishga undadi. Buning sababi shundaki, bu yondashuv hamjamiyatga ma'lumotlarni tekshirish va ulardan foydalanish xavfsiz ekanligiga ishonch hosil qilish imkonini beradi, degan qarash mavjud. Bu nazariyada qanchalik jozibali eshitilmasin, amalda biror bir kompaniya uchun fundamental modellarni o'qitishda ishlatiladigan ulkan hajmdagi ma'lumotlar to'plamini sinchkovlik bilan tekshirib chiqish deyarli imkonsiz vazifadir.

Aynan shu xavotirlar sababli, ko'plab kompaniyalar buning o'rniga tijoriy modellarni tanlaydi. Ochiq manbali modellar, odatda, tijoriy modellarga qaraganda cheklangan huquqiy resurslarga ega bo'ladi. Agar siz mualliflik huquqini buzadigan ochiq manbali modeldan foydalansangiz, huquqi buzilgan tomon model ishlab chiquvchilarini emas, katta ehtimol bilan aynan sizni sudga beradi. Biroq, agar siz tijoriy modeldan foydalansangiz, model provayderlari bilan imzolaydigan shartnomalaringiz sizni ma'lumotlarning kelib chiqishi bilan bog'liq xatarlardan potensial himoya qilishi mumkin.⁷

Samaradorlik

Turli benchmarklar ochiq manbali va xususiy modellar o'rtasidagi farq qisqarib borayotganini ko'rsatmoqda. 4-7-rasmda MMLU benchmarki bo'yicha bu farqning vaqt o'tishi bilan qanday kamayib borayotganini ko'rish mumkin. Ushbu tendensiya ko'pchilikni kun kelib eng kuchli xususiy model bilan bir xil, balki undan ham yaxshiroq ishlaydigan ochiq manbali model paydo bo'lishiga ishonishga undadi.

Men ochiq manbali modellar xususiy modellarga yetib olishini qanchalik istasam-da, mavjud rag'batlantirish tizimi bunga yo'l qo'ymaydi deb o'ylayman. Tasavvur qiling, sizda eng kuchli model bor: siz uni boshqalar foyda ko'rishi uchun ochiq manbali qilarmidingiz yoki undan o'zingiz foyda ko'rishga harakat qilarmidingiz?⁸ Kompaniyalar uchun o'zlarining eng kuchli modellarini API'lar ortida saqlab, nisbatan kuchsizroq modellarini ochiq manbali qilish odatiy holdir.

Shu sababli, yaqin kelajakda eng kuchli ochiq manbali model eng kuchli xususiy modellardan ortda qolishi ehtimoli yuqori. Biroq, eng kuchli modellarni talab qilmaydigan ko'plab ishlatilish senariylari uchun ochiq manbali modellar yetarli bo'lishi mumkin.

Ochiq manbali modellarning ortda qolishiga sabab bo'lishi mumkin bo'lgan yana bir omil shuki, tijoriy modellardan farqli o'laroq, ochiq manbali model yaratuvchilari o'z modellarini takomillashtirish uchun foydalanuvchilardan fikr-mulohazalar ololmaydilar. Model ochiq manbali qilinganidan so'ng, uning yaratuvchilari modelning amalda qanday ishlatilayotgani va real sharoitlarda qanchalik yaxshi ishlayotgani haqida hech qanday ma'lumotga ega bo'lmay qoladilar.

Funksionallik

Modelni muayyan bir ishlatilish senariysida ishlashi uchun uning atrofida ko'plab qo'shimcha funksional imkoniyatlar yaratilishi kerak. Quyida shunday funksiyalarga bir nechta misollar keltirilgan:

• Kengayuvchanlik: Inference xizmatining ilovangiz yuklamasini (trafikni) maqbul kechikish va xarajatlarni saqlagan holda qo'llab-quvvatlay olishini ta'minlash.

• Funksiyalarni chaqirish: Modelga tashqi vositalardan foydalanish imkoniyatini berish. Bu, 6-bobda muhokama qilinganidek, RAG va agentga asoslangan yondashuvlar uchun juda muhim.

• Strukturalashgan natijalar: Masalan, modellardan natijalarni JSON formatida yaratishni so'rash.

• Natijalarni nazorat qilish mexanizmlari: Yaratilgan javoblardagi xatarlarni kamaytirish, masalan, javoblarda irqchilik yoki jinsiy kamsitish holatlari yo'qligiga ishonch hosil qilish.

Bu funksiyalarning ko'pini amaliyotga tatbiq etish ancha murakkab va ko'p vaqt talab qiladigan jarayon bo'lgani uchun, ko'plab kompaniyalar o'zlariga kerakli funksiyalarni tayyor holatida taqdim etadigan API provayderlariga murojaat qiladi.

Model API'sidan foydalanishning salbiy tomoni shundaki, siz API taqdim etadigan funksiyalar bilangina cheklanib qolasiz. Ko'plab ishlatilish senariylari uchun zarur bo'lgan funksiyalardan biri bu logprobs (tokenlarning logarifmik ehtimolliklari)'dir. Ular klassifikatsiya vazifalari, baholash va model xatti-harakatini tahlil qilish uchun juda foydalidir. Biroq, tijoriy model ishlab chiquvchilari boshqalarning logprobs'dan foydalanib o'z modellarini qayta yaratishidan (nusxalashidan) qo'rqib, bu ma'lumotni taqdim etishga ikkilanishi mumkin. Aslida, ko'plab model API'lari logprobs'ni umuman taqdim etmaydi yoki faqat cheklangan qisminigina ochib beradi.

Shuningdek, siz tijoriy modelni faqatgina model provayderi ruxsat bergan taqdirdagina finetuning qila olasiz. Tasavvur qiling, promptlar yordamida model samaradorligini maksimal darajaga olib chiqdingiz va endi uni finetuning qilmoqchisiz. Agar bu model xususiy bo'lsa va model provayderining finetuning API'si bo'lmasa, siz buni qila olmaysiz. Biroq, agar u ochiq manbali model bo'lsa, siz ushbu modelda finetuning xizmatini taklif qiladigan biror servis topishingiz yoki buni o'zingiz amalga oshirishingiz mumkin. Yodda tutingki, 7-bobda muhokama qilinganidek, finetuning'ning bir necha turlari mavjud, masalan, qisman finetuning va to'liq finetuning. Tijoriy model provayderi finetuning'ning barcha turlarini emas, balki faqat ayrimlarini qo'llab-quvvatlashi mumkin.

API va muhandislik xarajatlarini taqqoslash

Model API'lari har bir foydalanish uchun haq oladi, bu esa yuqori yuklamalarda ularning narxi imkonsiz darajada qimmatlashib ketishiga olib kelishi mumkin. Muayyan miqyosga yetganda, API'lar tufayli katta mablag' yo'qotayotgan kompaniya o'z modellarini o'zida joylashtirish haqida o'ylab ko'rishi mumkin.⁹

Biroq, modelni o'z serveringizda joriy etishingiz salmoqli vaqt, malakali mutaxassislar va muhandislik kuchini talab etadi. Siz modelni optimallashtirishingiz, inference xizmatini zaruratga qarab kengaytirishingiz va qo'llab-quvvatlashingiz, shuningdek, modelingiz uchun nazorat mexanizmlarini joriy qilishingiz kerak bo'ladi. API'lar qimmat, lekin muhandislik xarajatlari undan ham oshib tushishi mumkin.

Boshqa tomondan olib qaraganda, begona API'dan foydalanish ularning SLA'siga (xizmat ko'rsatish darajasi to'g'risidagi kelishuv) bog'liqlikni anglatadi. Agar bu API'lar ishonchli bo'lmasa — bu holat faoliyatini endi boshlagan startaplarda ko'p uchraydi — siz o'zingizning muhandislik kuchingizni ushbu API'ning beqaror ishlashiga qarshi himoya mexanizmlarini yaratishga sarflashingizga to'g'ri keladi.

Umuman olganda, siz foydalanish va sozlash uchun qulay bo'lgan modelni tanlaganingiz ma'qul. Odatda, xususiy modellar bilan ish boshlash va ularni kengaytirish osonroq, lekin ochiq modellarni moslashtirish osonroq bo'lishi mumkin, chunki ularning tarkibiy qismlaridan foydalanish imkoniyati kengroq.

Ochiq yoki xususiy model tanlashingizdan qat'i nazar, ushbu modelning standart API'ga amal qilishi muhim, bu esa kelajakda modellarni almashtirishni osonlashtiradi. Ko'pgina model ishlab chiquvchilari o'z modellarini eng mashhur modellarning API'siga taqlid qiladigan qilib yaratishga harakat qilishadi. Ushbu matn yozilayotgan vaqtda, ko'plab API provayderlari OpenAI'ning API'sidan andoza olmoqda.

Shuningdek, kuchli hamjamiyat tomonidan qo'llab-quvvatlanadigan modellarni tanlaganingiz afzal. Model qanchalik ko'p imkoniyatlarga ega bo'lsa, uning o'ziga xos nozik jihatlari va "qiliqlari" ham shuncha ko'p bo'ladi. Katta foydalanuvchilar hamjamiyatiga ega modelni tanlasangiz, siz duch kelgan har qanday muammoga boshqalar ham allaqachon duch kelgan va ehtimol o'z yechimlarini internetda e'lon qilgan bo'lishi mumkin.¹⁰

Nazorat, foydalanish imkoniyati va shaffoflik

"a16z"ning 2024-yildagi tadqiqoti shuni ko'rsatadiki, korxonalarning ochiq manbali modellarga qiziqishining ikki asosiy sababi bu — nazorat va moslashtirish imkoniyatidir (4-8-rasmga qarang).

Agar biznesingiz modelga bog'liq bo'lsa, uning ustidan ma'lum darajada nazoratga ega bo'lishni istashingiz tabiiy, va API provayderlari har doim ham siz xohlagan darajadagi nazoratni taqdim etmasligi mumkin. Boshqa birov tomonidan taqdim etiladigan xizmatdan foydalanganda, siz ularning foydalanish shartlariga va so'rovlar limitiga bo'ysunasiz. Siz faqat provayder tomonidan taqdim etilgan imkoniyatlardan foydalana olasiz va shu sababli modelni kerakli tarzda sozlay olmasligingiz mumkin.

Model provayderlari o'z foydalanuvchilarini va o'zlarini potensial sud da'volaridan himoya qilish uchun irqchilikka oid hazillarni aytish yoki real insonlarning suratlarini yaratish kabi so'rovlarni bloklaydigan himoya mexanizmlarini qo'llaydilar. Xususiy modellar bu borada haddan tashqari senzura qilishga moyilroq bo'ladi. Bu himoya mexanizmlari aksariyat ishlatilish senariylari uchun foydali bo'lsa-da, ayrim holatlar uchun cheklovchi omil bo'lishi mumkin. Masalan, agar ilovangiz real yuzlarni yaratishni talab qilsa (masalan, musiqiy klip ishlab chiqarishga yordam berish uchun), real yuzlarni yaratishdan bosh tortadigan model ish bermaydi. Men maslahat beradigan Convai kompaniyasi 3D muhit bilan muloqotga kirisha oladigan, jumladan, jismlarni ko'tara oladigan 3D SI personajlarini yaratadi. Tijoriy modellar bilan ishlashda ular shunday muammoga duch kelishdiki, modellar doimiy ravishda: “Sun'iy intellekt modeli sifatida menda jismoniy qobiliyatlar yo'q”, deb javob qaytaravergan. Oxir-oqibat, Convai ochiq manbali modellarni finetuning qilishga majbur bo'ldi.

Shuningdek, tijoriy modeldan foydalanish imkoniyatini yo'qotish xavfi ham mavjud, agar butun tizimingizni uning atrofida qurgan bo'lsangiz, bu juda jiddiy oqibatlarga olib kelishi mumkin. Siz ochiq manbali modellarda qila olganingiz kabi, tijoriy modelni biror versiyada "muzlatib qo'ya olmaysiz". Tarixiy jihatdan, tijoriy modellar o'zgarishlar, versiyalar va kelgusi rejalar borasida shaffoflikka ega emas. Modellar tez-tez yangilanadi, lekin barcha o'zgarishlar ham oldindan e'lon qilinmaydi yoki umuman e'lon qilinmasligi mumkin. Sizning promptlaringiz kutilmaganda ishlamay qolishi mumkin va siz buning sababini bilmay qolasiz. Oldindan aytib bo'lmaydigan o'zgarishlar, shuningdek, tijoriy modellarni qat'iy tartibga solinadigan sohalardagi ilovalar uchun yaroqsiz qilib qo'yadi. Biroq, menimcha, model o'zgarishlaridagi bu tarixiy shaffoflikning yo'qligi shunchaki tez rivojlanayotgan sohaning bexosdan yuzaga kelgan oqibati bo'lishi mumkin. Umid qilamanki, soha yetuklashgani sari bu holat o'zgaradi.

Afsuski, kamroq uchraydigan, ammo mavjud bo'lgan yana bir holat shuki, model provayderi sizning ishlatilish senariyingizni, sohangizni yoki mamlakatingizni qo'llab-quvvatlashni to'xtatishi mumkin, yoki sizning mamlakatingiz model provayderingiz faoliyatini taqiqlab qo'yishi mumkin, masalan, Italiya 2023-yilda OpenAI faoliyatini qisqa muddatga taqiqlagan edi. Shuningdek, model provayderi butunlay bankrot bo'lishi yoki faoliyatini to'xtatishi ham mumkin.

Qurilmaning o'zida joriy etish

Agar modelni bevosita qurilmaning o'zida ishga tushirishni maqsad qilgan bo'lsangiz, uchinchi tomon API'laridan foydalanish haqida gap bo'lishi ham mumkin emas. Ko'plab ishlatilish senariylarida modelni lokal ravishda ishlatish maqsadga muvofiqdir. Buning sababi, sizning ishlatilish senariyingiz ishonchli internet aloqasi mavjud bo'lmagan hududlarga mo'ljallangan bo'lishi mumkin. Yoki bu maxfiylik bilan bog'liq bo'lishi mumkin: masalan, siz sun'iy intellekt yordamchisiga barcha ma'lumotlaringizdan foydalanishga ruxsat berishni istaysiz, ammo bu ma'lumotlarning qurilmangizdan chiqib ketishini xohlamaysiz. 4-4-jadvalda model API'laridan foydalanish va modellarni mustaqil ravishda ishlatishning afzalliklari va kamchiliklari umumlashtirilgan.

Umid qilamizki, har bir yondashuvning afzallik va kamchiliklari sizga tijoriy API'dan foydalanish yoki modelni mustaqil ravishda ishlatish borasida qaror qabul qilishingizga yordam beradi. Bu qaror mavjud variantlar doirasini ancha qisqartiradi. Shundan so'ng, ommaga ochiq bo'lgan model samaradorligi ma'lumotlaridan foydalanib, tanlovingizni yanada aniqlashtirishingiz mumkin.

Ommaviy benchmarklarni tahlil qilish

Modellarning turli qobiliyatlarini baholash uchun mo'ljallangan minglab benchmarklar (standartlashtirilgan sinovlar to'plami) mavjud. Birgina Google'ning BIG-bench (2022) to'plamining o'zida 214 ta benchmark mavjud. SI'ning ishlatilish senariylari soni jadal o'sgani sari, benchmarklar soni ham shunga mos ravishda tez sur'atda ko'payib bormoqda. Bundan tashqari, SI modellari takomillashgani sari, eski benchmarklar o'z ahamiyatini yo'qotadi, bu esa yangi benchmarklarni joriy etish zaruratini tug'diradi.

Modelni bir nechta benchmarklar bo'yicha baholashga yordam beradigan vosita evaluation harness (baholash vositalari to'plami) deb ataladi. Ushbu matn yozilayotgan vaqtda, EleutherAI'ning lm-evaluation-harness vositasi 400 dan ortiq benchmarkni qo'llab-quvvatlaydi. OpenAI'ning evals vositasi esa mavjud 500 ga yaqin benchmarkning istalganini ishga tushirishga va OpenAI modellarini baholash uchun yangi benchmarklarni ro'yxatdan o'tkazishga imkon beradi. Ularning benchmarklari keng qamrovli qobiliyatlarni baholaydi: matematik amallarni bajarish va boshqotirmalarni yechishdan tortib, so'zlarni ifodalovchi ASCII san'atini aniqlashgacha.

Benchmarklarni tanlash va natijalarni umumlashtirish

Benchmark natijalari ishlatilish senariylaringiz uchun istiqbolli modellarni saralab olishga yordam beradi. Modellarning reytingini tuzish uchun benchmark natijalarini jamlab, umumlashtirish orqali reyting jadvali (leaderboard) yaratiladi. Bu jarayonda ikki muhim savol tug'iladi:

• Reyting jadvaliga qaysi benchmarklarni kiritish kerak?
• Modellarning reytingini tuzish uchun bu benchmark natijalarini qanday umumlashtirish kerak?

Mavjud benchmarklarning soni shu qadar ko'pki, ularning barchasini ko'rib chiqishning o'zi imkonsiz, eng yaxshi modelni aniqlash uchun ularning natijalarini umumlashtirish haqida esa gapirmasa ham bo'ladi. Tasavvur qiling, siz kod yaratish vazifasi uchun A va B modellarini solishtirayapsiz. Agar A model kodlashga oid benchmarkda B modeldan yaxshiroq, lekin toksiklik benchmarkida yomonroq natija ko'rsatsa, qaysi birini tanlaysiz? Xuddi shunday, bir model kodlashga oid bitta benchmarkda yaxshiroq, ammo boshqasida yomonroq natija ko'rsatsa, qaysi birini tanlaysiz?

Ommaviy benchmarklar asosida o'z reyting jadvalingizni yaratishda ilhom olish uchun, mavjud ommaviy reyting jadvallarining qanday ishlashini o'rganish foydalidir.

Ommaviy reyting jadvallari

Ko'pgina ommaviy reyting jadvallari modellarni ma'lum bir benchmarklar to'plamidagi jamlanma samaradorligiga qarab tartiblaydi. Bu reyting jadvallari juda katta yordam beradi, biroq ularni har tomonlama qamrovli deb bo'lmaydi. Birinchidan, compute (hisoblash quvvatlari) cheklovi tufayli — ya'ni modelni biror benchmarkda baholash uchun hisoblash quvvatlari kerak bo'ladi — aksariyat reyting jadvallari o'z ichiga faqat oz sonli benchmarklarni ola oladi. Ba'zi reyting jadvallari muhim, lekin ko'p resurs talab qiladigan (qimmat) benchmarkni chetlab o'tishi mumkin. Masalan, HELM (Holistic Evaluation of Language Models) Lite versiyasi uni ishga tushirish qimmat bo'lgani uchun ma'lumot qidirishga oid benchmarkni (MS MARCO — Microsoft Machine Reading Comprehension) o'z ichiga olmagan. Hugging Face esa katta hisoblash quvvatlarini talab qilgani sababli HumanEval'dan voz kechgan — bu benchmark uchun juda ko'p completion (matnni yakunlash variantlari) yaratish kerak bo'ladi.

Hugging Face 2023-yilda o'zining Ochiq LLM reyting jadvalini ilk bor ishga tushirganda, u to'rtta benchmarkdan iborat edi. Yil oxiriga kelib, ular bu sonni oltitaga yetkazishdi. Oz sonli benchmarklar to'plami fundamental modellarning keng qamrovli imkoniyatlari va turli zaif tomonlarini to'liq aks ettirish uchun mutlaqo yetarli emas.

Bundan tashqari, reyting jadvali ishlab chiquvchilari odatda benchmarklarni tanlashga puxta yondashsalar-da, ularning qaror qabul qilish jarayoni foydalanuvchilar uchun har doim ham tushunarli bo'lavermaydi. Turli reyting jadvallari ko'pincha turlicha benchmarklarga ega bo'ladi, bu esa ularning reytinglarini solishtirish va tahlil qilishni qiyinlashtiradi. Masalan, 2023-yil oxirida Hugging Face o'zining Ochiq LLM reyting jadvalini yangilab, modellarni tartiblash uchun oltita turli benchmarkning o'rtacha ko'rsatkichidan foydalanishni boshladi:

• ARC-C (Clark va boshq., 2018): Boshlang'ich sinf darajasidagi murakkab ilmiy savollarni yechish qobiliyatini o'lchash.

• MMLU (Hendrycks va boshq., 2020): 57 ta fanni, jumladan, elementar matematika, AQSh tarixi, informatika va huquqni o'z ichiga olgan sohalardagi bilim va mantiqiy fikrlash qobiliyatlarini o'lchash.

• HellaSwag (Zellers va boshq., 2019): Gapni yoki hikoya/videodagi sahnani yakunlashni prognoz qobiliyatini o'lchash. Maqsad — sog'lom fikr va kundalik faoliyatni tushunishni sinash.

• TruthfulQA (Lin va boshq., 2021): Modelning faktlarni tushunishiga e'tibor qaratgan holda, nafaqat aniq, balki haqiqatga mos va chalg'itmaydigan javoblar yaratish qobiliyatini o'lchash.

• WinoGrande (Sakaguchi va boshq., 2019): Til modellari uchun qiyin bo'lishi mo'ljallangan, yuqori darajadagi sog'lom fikrlashni talab qiluvchi, olmoshlarning bog'liqligiga oid murakkab muammolarni yechish qobiliyatini o'lchash.

• GSM-8K (Grade School Math, OpenAI, 2021): Boshlang'ich sinf o'quv dasturlarida uchraydigan turli xil matematik masalalarni yechish qobiliyatini o'lchash.

Taxminan o'sha vaqtlarda, Stanford'ning HELM reyting jadvali o'nta benchmarkdan foydalangan, ulardan faqat ikkitasi (MMLU va GSM-8K) Hugging Face reyting jadvalida mavjud edi. Qolgan sakkizta benchmark quyidagilar edi:

• Musobaqa darajasidagi matematika uchun benchmark (MATH)
• Huquq (LegalBench), tibbiyot (MedQA) va tarjima (WMT 2014) sohalarining har biri uchun bittadan benchmark
• O'qib tushunish uchun ikkita benchmark — kitob yoki uzun hikoya asosida savollarga javob berish (NarrativeQA va OpenBookQA)
• Umumiy savol-javob uchun ikkita benchmark (Natural Questions, ikki xil shartda: kiritilayotgan ma'lumotda Vikipediya sahifalari bilan va ularsiz)

Hugging Face bu benchmarklarni tanlash sababini shunday izohlagan: "ular turli sohalarda keng qamrovli mantiqiy fikrlash va umumiy bilimlarni sinovdan o'tkazadi".¹¹ HELM veb-saytida esa ularning benchmarklar ro'yxati Hugging Face reyting jadvalining "soddaligidan ilhomlangani", biroq kengroq doiradagi senariylarni qamrab olishi aytilgan.

Ommaviy reyting jadvallari, umuman olganda, qamrov va benchmarklar soni o'rtasidagi muvozanatni saqlashga harakat qiladi. Ular odatda mantiqiy fikrlash, faktlarga moslik hamda matematika va fan kabi sohaga xos qobiliyatlarni o'z ichiga olgan keng imkoniyatlarni qamrab oladigan kichik bir benchmarklar to'plamini tanlashga intiladi.

Yuzaki qaraganda, bu to'g'ri yondashuvdek tuyuladi. Biroq, "qamrov" nima ekanligi yoki nima uchun u aynan oltita yoki o'nta benchmark bilan cheklanishi haqida aniqlik yo'q. Masalan, nima uchun tibbiyot va huquqqa oid vazifalar HELM Lite'ga kiritilgan-u, umumiy fan kiritilmagan? Nima uchun HELM Lite'da ikkita matematika testi bor-u, kodlash bo'yicha hech qanday test yo'q? Nega ikkalasida ham matnni qisqartirish, vositalardan foydalanish, toksiklikni aniqlash, rasm qidirish va hokazolar uchun testlar mavjud emas? Bu savollar ommaviy reyting jadvallarini tanqid qilish maqsadida emas, balki modellarni reytinglash uchun benchmarklarni tanlash vazifasi qanchalik murakkab ekanligini ko'rsatish uchun berilmoqda. Agar reyting jadvali ishlab chiquvchilari o'z benchmarklarini tanlash jarayonini tushuntirib bera olmayotgan bo'lsa, buning sababi shunchaki bu ishning haqiqatan ham murakkabligida bo'lishi mumkin.

Benchmark tanlashda ko'pincha e'tibordan chetda qoladigan muhim jihat — bu benchmarklar korrelyatsiyasidir. Bu muhim, chunki agar ikkita benchmark bir-biri bilan to'liq korrelyatsiyada bo'lsa, ularning ikkalasini ham qo'shishning hojati yo'q. Bir-biriga kuchli bog'liq bo'lgan benchmarklar mavjud noxolisliklarni bo'rttirib ko'rsatishi mumkin.¹²

4-5-jadvalda Hugging Face reyting jadvalida qo'llanilgan oltita benchmark o'rtasidagi o'zaro bog'liqlik (korrelyatsiya) ko'rsatkichlari keltirilgan. Bu ko'rsatkichlar 2024-yil yanvar oyida Balázs Galambosi tomonidan hisoblangan. WinoGrande, MMLU va ARC-C benchmarklari bir-biri bilan kuchli bog'liqlikka ega, bu mantiqan to'g'ri, chunki ularning barchasi mantiqiy fikrlash qobiliyatini sinaydi. TruthfulQA esa boshqa benchmarklar bilan o'rtacha darajada bog'liq, bu esa modelning mantiqiy fikrlash va matematik qobiliyatlarini yaxshilash uning haqiqatga mosligini har doim ham oshirmasligini ko'rsatadi.

Modellarni reytinglash uchun tanlangan barcha benchmarklarning natijalari umumlashtirilishi kerak. Ushbu matn yozilayotgan vaqtda, Hugging Face modelning yakuniy reyting ballini olish uchun uning barcha benchmarklardagi natijalarining o'rtacha arifmetigini hisoblaydi. O'rtacha arifmetikni hisoblash barcha benchmark ballarini bir xil deb hisoblashni anglatadi, ya'ni TruthfulQA bo'yicha 80% natijaga erishish GSM-8K bo'yicha 80% natijaga erishishdan ancha qiyinroq bo'lishi mumkin bo'lsa ham, ikkala 80% lik natijaga bir xil qaraladi. Bu, shuningdek, barcha benchmarklarga bir xil vazn berishni anglatadi, vaholanki, ba'zi vazifalar uchun ishonchlilik boshlang'ich sinf matematik masalalarini yecha olishdan ancha muhimroq bo'lishi mumkin.

HELM mualliflari esa, aksincha, o'rtacha arifmetikdan voz kechib, buning o'rniga "o'rtacha g'alaba koeffitsienti"ni tanlashgan. Ular buni "bir modelning boshqa modeldan yaxshiroq natija ko'rsatgan holatlarining senariylar bo'yicha o'rtacha ulushi" deb ta'riflashgan.

Ommaviy reyting jadvallari modellarning umumiy samaradorligi haqida tasavvur olish uchun foydali bo'lsa-da, reyting jadvali aynan qanday qobiliyatlarni o'lchashga harakat qilayotganini tushunish muhim. Ommaviy reyting jadvalida yuqori o'rinni egallagan model, katta ehtimol bilan, lekin har doim ham emas, sizning ilovangiz uchun yaxshi natija ko'rsatadi. Agar sizga kod yaratish uchun model kerak bo'lsa, tarkibida kod yaratish benchmarki bo'lmagan ommaviy reyting jadvali sizga unchalik yordam bera olmasligi mumkin.

Ommaviy benchmarklar asosida shaxsiy reyting jadvallarini tuzish

Muayyan bir ilova uchun modellarni baholayotganda, siz aslida modellarni o'zingizning baholash mezonlaringiz asosida tartiblaydigan shaxsiy reyting jadvalini yaratayotgan bo'lasiz. Birinchi qadam — ilovangiz uchun muhim bo'lgan qobiliyatlarni baholaydigan benchmarklar ro'yxatini tuzishdir. Agar kodlash agentini yaratmoqchi bo'lsangiz, kodlashga oid benchmarklarni ko'rib chiqing. Agar yozuvchi yordamchisini yaratsangiz, ijodiy yozishga oid benchmarklarni o'rganing. Yangi benchmarklar doimiy ravishda joriy etilib, eskilarining o'z ahamiyatini yo'qotib borishi sababli, siz eng so'nggi benchmarklarni izlashingiz lozim. Benchmarkning qanchalik ishonchli ekanligini baholashga ishonch hosil qiling. Har kim benchmark yaratishi va e'lon qilishi mumkinligi sababli, ko'plab benchmarklar siz kutgan narsani o'lchamasligi mumkin.

OpenAI modellarining sifati pasayib boryaptimi?

Har safar OpenAI o'z modellarini yangilaganida, odamlar ularning sifati yomonlashib borayotgandek tuyulayotganidan shikoyat qilishadi. Masalan, Stanford va UC Berkeley (Chen va boshq., 2023) tomonidan o'tkazilgan tadqiqot shuni ko'rsatdiki, 4-9-rasmda ko'rsatilganidek, 2023-yil mart va iyun oylari oralig'ida ko'plab benchmarklar bo'yicha ham GPT-3.5, ham GPT-4 modellarining samaradorligi sezilarli darajada o'zgargan.

GPT-3.5 va GPT-4 modellarining 2023-yil mart va iyun oylari orasida ayrim benchmarklardagi samaradorligining o'zgarishi (Chen va boshq., 2023).

OpenAI ataylab yomonroq modellarni chiqarmaydi deb faraz qilsak, bu kabi tasavvurning sababi nima bo'lishi mumkin? Buning bir ehtimoliy sababi shundaki, baholashning o'zi murakkab va hech kim, hatto OpenAI'ning o'zi ham, model yaxshilanayotganini yoki yomonlashayotganini aniq bilmaydi. Baholash haqiqatan ham murakkab bo'lsa-da, men OpenAI butunlay ko'r-ko'rona harakat qilishiga shubha qilaman.¹⁵ Agar ikkinchi sabab to'g'ri bo'lsa, bu umuman olganda eng yaxshi model sizning ilovangiz uchun eng yaxshi model bo'lmasligi mumkin degan fikrni yanada mustahkamlaydi.

Barcha modellarning ham hamma benchmarklardagi natijalari ommaga ochiq emas. Agar sizni qiziqtirayotgan modelning siz tanlagan benchmarkdagi natijasi ommaga e'lon qilinmagan bo'lsa, baholashni o'zingiz amalga oshirishingizga to'g'ri keladi.¹⁶ Yaxshiyamki, bu ishda sizga evaluation harness (baholash vositalari to'plami) yordam berishi mumkin. Benchmarklarni ishga tushirish qimmatga tushishi mumkin. Masalan, Stanford o'zining to'liq HELM to'plamida 30 ta modelni baholash uchun taxminan $80,000–$100,000 sarflagan.¹⁷ Siz qancha ko'p modelni baholamoqchi bo'lsangiz va qancha ko'p benchmarkdan foydalansangiz, xarajatlar shuncha ortib boradi.

Bir to'plam benchmarklarni tanlab olib, sizni qiziqtirgan modellarning ushbu benchmarklardagi natijalarini qo'lga kiritganingizdan so'ng, modellarni reytinglash uchun bu natijalarni umumlashtirishingiz kerak bo'ladi. Barcha benchmark natijalari ham bir xil o'lchov birligi yoki shkalada bo'lmaydi. Bir benchmark to'g'rilik'dan foydalansa, boshqasi F1 ko'rsatkichidan, yana biri esa BLEU bahosidan foydalanishi mumkin. Har bir benchmark siz uchun qanchalik muhim ekanligini o'ylab ko'rishingiz va ularning natijalariga shunga yarasha vazn berishingiz kerak bo'ladi.

Ommaviy benchmarklar yordamida modellarni baholar ekansiz, yodda tutingki, bu jarayonning maqsadi — o'zingizning shaxsiy benchmarklaringiz va metrikalaringiz yordamida yanada chuqurroq tajribalar o'tkazish uchun modellarning kichik bir guruhini saralab olishdir. Buning sababi nafaqat ommaviy benchmarklarning sizning ilovangiz ehtiyojlarini mukammal darajada aks ettira olmasligi, balki ularning katta ehtimol bilan "ifloslangan" (contaminated) bo'lishidadir. Ommaviy benchmarklar qanday qilib "ifloslanishi" va ma'lumotlarning "ifloslanishi" bilan qanday kurashish kerakligi keyingi bo'limning mavzusi bo'ladi.

Ommaviy benchmarklarda ma'lumotlarning ifloslanishi

Ma'lumotlarning ifloslanishi shu qadar keng tarqalgan hodisaki, uning "ma'lumotlarning sizib chiqishi", "test to'plamida o'qitish" yoki shunchaki "firibgarlik" kabi ko'plab nomlari mavjud. Ma'lumotlarning ifloslanishi model o'zi baholanadigan ma'lumotlarning aynan o'zida o'qitilganda yuz beradi. Bunday holda, model shunchaki o'qitish paytida ko'rgan javoblarini yodlab olgan bo'lishi mumkin, bu esa uning baholashda haqqoniy natijasidan yuqoriroq ball to'plashiga olib keladi. Masalan, MMLU benchmarkida o'qitilgan model, amalda foydali bo'lmasa-da, yuqori MMLU ballarini qo'lga kiritishi mumkin.

Stenford universiteti doktoranti Rylan Schaeffer buni o'zining 2023-yilda chop etilgan “Pretraining on the Test Set Is All You Need”(“Test to'plamida dastlabki o'qitish — sizga kerak bo'lgan yagona narsa”) nomli hajviy maqolasida ajoyib tarzda namoyish etgan. Faqatgina bir nechta benchmark ma'lumotlarida o'qitish orqali, uning bir million parametrli modeli deyarli mukammal natijalarga erisha oldi va bu benchmarklarning barchasida o'zidan ancha katta modellardan ustun keldi.

Ma'lumotlarning ifloslanishi qanday yuz beradi

Garchi ayrimlar chalg'ituvchi darajada yuqori ballarga erishish uchun benchmark ma'lumotlarida ataylab o'qitishsa-da, aksariyat ma'lumotlarning ifloslanishi bexosdan yuz beradi. Bugungi kunda ko'plab modellar internetdan yig'ilgan (scraped) ma'lumotlar asosida o'qitiladi va bu ma'lumot yig'ish jarayoni ommaga ochiq benchmarklardan tasodifan ma'lumotlarni tortib olishi mumkin. Modelni o'qitishdan oldin e'lon qilingan benchmark ma'lumotlari, katta ehtimol bilan, modelning o'qitish ma'lumotlari tarkibiga kirib qolgan bo'ladi.¹⁸ Mavjud benchmarklarning bunchalik tez o'z ahamiyatini yo'qotishining va model ishlab chiquvchilarining o'z yangi modellarini baholash uchun yangi benchmarklar yaratish zaruratini his qilishlarining sabablaridan biri ham shudir.

Ma'lumotlarning ifloslanishi bilvosita ham yuz berishi mumkin, masalan, baholash va o'qitish ma'lumotlari bir xil manbadan olinganda. Masalan, siz modelning matematik qobiliyatlarini yaxshilash uchun o'qitish ma'lumotlariga matematika darsliklarini kiritishingiz mumkin, boshqa birov esa modelning qobiliyatlarini baholash uchun benchmark yaratishda aynan o'sha darsliklardagi savollardan foydalangan bo'lishi mumkin.

Ma'lumotlarning ifloslanishi yaxshi niyatlarda ataylab ham amalga oshirilishi mumkin. Aytaylik, siz foydalanuvchilaringiz uchun imkon qadar eng yaxshi modelni yaratmoqchisiz. Dastlab, siz modelning o'qitish ma'lumotlaridan benchmark ma'lumotlarini chiqarib tashlaysiz va shu benchmarklar asosida eng yaxshi modelni tanlab olasiz. Biroq, yuqori sifatli benchmark ma'lumotlari modelning samaradorligini oshirishi mumkinligi sababli, siz tanlab olingan eng yaxshi modelingizni foydalanuvchilarga taqdim etishdan oldin uni benchmark ma'lumotlarida o'qitishni davom ettirasiz. Natijada, taqdim etilgan model "ifloslangan" bo'ladi va foydalanuvchilaringiz uni ifloslangan benchmarklarda baholay olmaydilar, lekin bu baribir to'g'ri qaror bo'lishi mumkin.

Ma'lumotlarning ifloslanishi bilan ishlash

Ma'lumotlarning ifloslanishining keng tarqalganligi baholash benchmarklarining ishonchliligiga jiddiy putur yetkazadi. Modelning advokatlik imtihonlarida yuqori natija ko'rsatishi uning yuridik maslahat berishga usta ekanligini anglatmaydi. Buning sababi shunchaki ushbu modelning ko'plab advokatlik imtihoni savollarida o'qitilgani bo'lishi mumkin.

Ma'lumotlarning ifloslanishi muammosini hal qilish uchun avval ifloslanishni aniqlash, so'ngra esa ma'lumotlaringizni tozalash kerak. Ifloslanishni n-gram overlapping va perplexity kabi evristik usullar yordamida aniqlash mumkin:

• N-gram overlapping (ketma-ket kelgan n-ta so'z yoki belgilardan iborat qismlarning mos tushishi): Masalan, agar baholash namunasidagi 13 ta tokendan iborat ketma-ketlik o'qitish ma'lumotlarida ham mavjud bo'lsa, model bu baholash namunasini o'qitish paytida ko'rgan bo'lishi ehtimoli yuqori. Bunday baholash namunasi ifloslangan deb hisoblanadi.

• Perplexity (model uchun matnni prognoz qilish qanchalik kutilmagan yoki qiyin ekanligini o'lchovchi ko'rsatkich): Eslatma uchun, perplexity model uchun berilgan matnni prognoz qilish qanchalik qiyin ekanligini o'lchaydi. Agar modelning baholash ma'lumotlaridagi perplexity'si g'ayrioddiy darajada past bo'lsa, ya'ni model matnni osonlik bilan bashorat qila olsa, model bu ma'lumotni avval o'qitish paytida ko'rgan bo'lishi mumkin.

N-gram overlapping yondashuvi aniqroq, lekin uni ishga tushirish ko'p vaqt talab qiladigan va qimmat bo'lishi mumkin, chunki siz har bir benchmark namunasini butun o'qitish ma'lumotlari bilan solishtirib chiqishingiz kerak. Shuningdek, o'qitish ma'lumotlaridan foydalanish imkoni bo'lmasa, bu usulni qo'llab bo'lmaydi. Perplexity yondashuvi esa unchalik aniq emas, lekin ancha kam resurs talab qiladi.

Ilgari ML darsliklarida baholash namunalarini o'qitish ma'lumotlaridan olib tashlash tavsiya etilardi. Maqsad — turli modellarni solishtirish imkoniyatiga ega bo'lish uchun baholash benchmarklarini standartlashtirilgan holda saqlash edi. Biroq, fundamental modellar davrida aksariyat odamlar o'qitish ma'lumotlarini nazorat qila olmaydi. O'qitish ma'lumotlarini nazorat qila olgan taqdirimizda ham, barcha benchmark ma'lumotlarini olib tashlashni xohlamasligimiz mumkin, chunki yuqori sifatli benchmark ma'lumotlari modelning umumiy samaradorligini oshirishga yordam beradi. Bundan tashqari, modellar o'qitilganidan keyin yaratiladigan benchmarklar doim bo'ladi, shuning uchun ifloslangan baholash namunalari ham doim mavjud bo'ladi.

Model ishlab chiquvchilari orasida keng tarqalgan amaliyot — o'z modellarini o'qitishdan avval, ular uchun muhim bo'lgan benchmarklarni o'qitish ma'lumotlaridan olib tashlashdir. Ideal holda, modelning biror benchmarkdagi samaradorligi haqida hisobot berilganda, ushbu benchmark ma'lumotlarining qancha foizi o'qitish ma'lumotlari tarkibida borligini hamda modelning ham umumiy benchmarkda, ham uning faqat toza (ifloslanmagan) namunalaridagi natijalarini ko'rsatib o'tish maqsadga muvofiqdir. Afsuski, ifloslanishni aniqlash va bartaraf etish zahmat talab qilgani bois, ko'pchilik bu bosqichni shunchaki o'tkazib yuborishni ma'qul ko'radi.

OpenAI GPT-3'ning keng tarqalgan benchmarklar bilan ifloslanishini tahlil qilar ekan, o'qitish ma'lumotlari tarkibida kamida 40% qismi mavjud bo'lgan 13 ta benchmarkni aniqladi (Brown va boshq., 2020). Faqat toza namunalar yordamida baholash va butun benchmark yordamida baholash o'rtasidagi samaradorlikning nisbiy farqi 4-10-rasmda ko'rsatilgan.

Ma'lumotlarning ifloslanishiga qarshi kurashish maqsadida, Hugging Face kabi reyting jadvallarini yurituvchilar keskin farq qiluvchi natijalarni (outliers) aniqlash uchun modellarning muayyan benchmarkdagi samaradorligining standart og'ishlarini grafikda ko'rsatadilar. Ommaviy benchmarklar o'z ma'lumotlarining bir qismini maxfiy saqlashi va model ishlab chiquvchilariga modellarni ushbu maxfiy, nazorat uchun ajratilgan ma'lumotlar (private hold-out data) asosida avtomatik baholash imkonini beradigan vositani taqdim etishi lozim.

Ommaviy benchmarklar yomon modellarni saralab tashlashga yordam beradi, lekin ular sizning ilovangiz uchun eng yaxshi modellarni topishga yordam bermaydi. Ommaviy benchmarklar yordamida nomzodlarni istiqbolli modellar to'plamigacha qisqartirgandan so'ng, ilovangiz uchun eng munosibini topish maqsadida o'zingizning shaxsiy baholash jarayonlar zanjiringizni (evaluation pipeline) ishga tushirishingiz kerak bo'ladi. Shaxsiy baholash jarayonlar zanjirini qanday loyihalash keyingi mavzumiz bo'ladi.

Izohlar