Model o‘zgarishi tufayli test muhiti yo‘qoldi

Kirish

So‘nggi bir necha oy davomida men ishlagan loyihalarimda LLM agentlaridan foydalandim. Foydalanuvchi tabiiy tilda so‘rov yuborganda, agent zarur so‘rov vositalarini tanladi, natijalarni tekshirdi va keyin javob yaratdi yoki qo‘shimcha mulohaza talab qilinganda boshqa savol berdi. Ushbu maqolada modelni o‘rab, vositalarga qo‘ng‘iroqlar va suhbat oqimini boshqaradigan agent harnessini yaratish hamda bir nechta turli modellarni sinab ko‘rish davomida o‘rganganlarim jamlangan.

Dastlab harnessni ulangan har qanday modelni ishonchli ishlatishga qodir bo‘lgan universal boshqaruv qatlami deb tasavvur qildim. Shuning uchun mahalliy model sxemani buzganida yoki noto‘g‘ri vosita chaqirig‘ini amalga oshirganida, parserlar, qayta urinishlar va mulohaza yuritish qoidalarini qo‘shdim. O‘sha paytda bu oqilona yechimdek tuyuldi, chunki xatolarni birma-bir to‘sib borayotgan edim.

Biroq, faqat modelni o‘zgartirgan holda bir xil harnessni qayta-qayta ishga tushirganimda, natijalar farq qildi. Mahalliy ochiq modellar format xatolarini, noto‘g‘ri argumentlarni, bo‘sh javoblarni va umumiy vazifani yakunlashdan oldingi ortiqcha kechikishlarni qayta-qayta keltirib chiqardi. Aksincha, gpt-5.6 bir xil vositalar va bir xil so‘rov bilan vazifani boshidan oxirigacha eng ishonchli tarzda bajardi. Farq arzimas emas edi; u tizimdan amalda foydalanish mumkin yoki mumkin emasligini belgilaydigan darajada katta edi.

Kompensatsion harness universal xavfsizlik tarmog‘i emas, balki men kuzatgan modellar xatolarining taqsimotiga moslab yozilgan kod edi. Model yaxshilangani sari bu kod keraksiz bo‘lib boradi. Bundan ham yomoni, avvalgi modelga moslab yozilgan kompensatsiyalar yangi modelning to‘g‘ridan-to‘g‘ri bajarilish yo‘liga xalaqit berishi mumkin.

Bu butun harness yo‘qolib ketadi degani emas. Model kamchiliklarini qoplaydigan kompensatsion harness bilan tasdiqlashlar, ruxsatlar, byudjetlar va audit kabi tizim darajasidagi masalalar uchun javob beradigan harnessni farqlashimiz kerak. Ushbu maqolada men amalda yaratgan kompensatsion kodni qayta ko‘rib chiqaman va yaxshi model tanlash shunchaki koddan tashqaridagi xarajat masalasi emas, balki arxitekturaga oid qaror ekanini tushuntiraman.

1. Nega mahalliy modellarni tanladim va harness qanday boshlandi

Loyiha boshida mahalliy modellarni ustuvor qilish uchun aniq sabablar bor edi. Bizga biznes ma’lumotlari tashkilotdan tashqariga chiqmaydigan konfiguratsiya kerak edi, ichki inference serverimiz allaqachon mavjud edi va chaqiruv xarajatlarini kamaytirishimiz mumkin edi. Agar model va provayderni konfiguratsiya orqali almashtirish mumkin bo‘lsa, ilova kodi o‘zgarmasdan qoladi, deb hisobladim.

Tashqariga oshkor qilib bo‘lmaydigan loyiha identifikatorlarini chiqarib tashlab soddalashtirilganda, konfiguratsiya quyidagicha ko‘rinishga ega edi:

Provayder va modelni almashtirish konfiguratsiyasi

agent:
  provider: ${LLM_PROVIDER:local}
  endpoint: ${LLM_ENDPOINT}
  model: ${LLM_MODEL}
  capabilities:
    tool-calling: true
    structured-output: false

Faqat konfiguratsiyaga qaraganda, modellarni almashtirish bitta satrni o‘zgartirishdek oddiy ko‘rinadi. Amalda esa unday bo‘lmadi. Birinchi mahalliy model sxemada e’lon qilingan maydonlar nomlarini boshqa so‘zlarga almashtirdi, ikkinchi model esa zarur so‘rovlarni yakunlashdan oldin javob yaratdi yoki javob berish uchun juda ko‘p vaqt sarfladi. Yana bir model noto‘g‘ri vosita argumentlaridan foydalandi yoki na mazmuni, na vosita chaqiruvlari bo‘lgan bo‘sh navbatni qaytardi.

Har safar xato yuz berganida, model keyingi urinishda muvaffaqiyat qozonishi uchun kod qo‘shdim. Maydon nomlari uchun sinonimlarni qabul qildim, variantlar soniga qarab noto‘g‘ri turlarni aniqladim, bo‘sh javoblar uchun qayta urinishni yo‘lga qo‘ydim va bitta modelning chaqiruv odatlariga moslashish uchun qadamlar sonini oshirdim. Alohida xatolar kamaydi, ammo harnessda modelga xos bilimlar tobora ko‘payib bordi.

Bu jarayonda muhim bir tuzoq mavjud edi. Har bir o‘zgarish testlardan o‘tdi va haqiqiy xatoni bartaraf etdi. Shu sababli faqat kodga qaralganda, uning barchasi zarur himoya mantiqidek ko‘rindi. Biroq uning zarurligi mahsulot shartnomasidan emas, o‘sha paytda ishlatilgan modelning xatti-harakatidan kelib chiqardi. Bu model o‘zgargan zahoti asosini yo‘qotishi mumkin bo‘lgan kod edi.

2. Men amalda qo‘shgan kompensatsion harness

Men qo‘shgan kompensatsiya mantiqi turli shakllarda bo‘lgan bo‘lsa-da, barchasini bir xil jumla bilan ifodalash mumkin: “Model X tarzida xato qilgani uchun kod uni Y tarzida tuzatadi.” Men vakillik qiluvchi holatlarni tashqariga oshkor qilish mumkin bo‘lgan umumlashtirilgan kod shaklida tartibladim.

2.1 Sxema maydonlari nomlarini sinonim sifatida qabul qildim

Foydalanuvchilarga qo‘shimcha savollar yuborish vositasi questionId, question va inputType kabi maydonlarni talab qilardi. Biroq ayrim modellar questionId o‘rniga id yoki key, inputType o‘rniga esa type yoki kind yuborardi. Agar ular o‘z holicha tahlil qilinsa, butun savol tushirib qoldirilardi, shuning uchun bir nechta nomlarni ketma-ket o‘qiydigan funksiya yaratdim.

Maydon nomlaridagi variantlarni qabul qiluvchi parser

private String firstText(Map<String, Object> values, String... names) {
    for (String name : names) {
        String value = text(values.get(name));
        if (!value.isBlank()) {
            return value;
        }
    }
    return "";
}
 
String questionId = firstText(values, "questionId", "id", "key");

Muammo shundaki, sinonimlar ro‘yxati spetsifikatsiyadan kelib chiqmagan edi. U bajarilish jurnallarida ko‘ringan so‘zlarni birma-bir qo‘shish natijasi edi. Hatto bir xil model ham turli ishga tushirishlarda turli so‘zlarni yaratdi, modelni o‘zgartirish esa yanada ko‘proq variantlarni keltirib chiqardi. Parser kengaydi, ammo shartnoma yanada noaniq bo‘lib bordi.

2.2 Kod noto‘g‘ri kiritish turlarini aniqladi

Maydon nomlarini topganimizdan keyin ham qiymatlar muammo bo‘lib qoldi. Men Text, Radio va Select kabi yopiq qiymatlarga ruxsat berdim, ammo modellar multiple_choice, dropdown va checkbox kabi ifodalarni yaratdi. Savolni tashlab yubormaslik uchun satrlarni normallashtirdim va tur hali ham noma’lum bo‘lsa, variantlar soniga qarab UI turini aniqladim.

Model chiqish qiymatlarini normallashtirish va aniqlash mantiqi

String normalized = raw.toLowerCase(Locale.ROOT).replaceAll("[^a-z]", "");
QuestionType declared = switch (normalized) {
    case "text", "freetext", "string" -> QuestionType.Text;
    case "radio", "singlechoice", "choice" -> QuestionType.Radio;
    case "select", "dropdown", "list" -> QuestionType.Select;
    case "multiselect", "multiplechoice", "checkbox" -> QuestionType.MultiSelect;
    default -> null;
};
 
return declared != null ? declared : inferFrom(options);

Bu mantiq UIʼni ko‘rsatish imkonini berdi, ammo model yaratgan noaniqlikni ilova o‘zboshimchalik bilan talqin qilish xavfini keltirib chiqardi. Noto‘g‘ri aniqlash oddiy kiritish sifatida saqlanishi mumkin edi, yangi model to‘g‘ri qiymat yuborganida ham eski zaxira mantiqi saqlanib qolardi. Bu qisqa muddatli tiklanish uchun foydali, ammo uzoq muddatli shartnoma sifatida mos emas edi.

2.3 Strukturaviy chiqishdan foydalanish o‘rniga shartnomani promptda takrorladim

Ayrim mahalliy bajarilish muhitlarida strukturaviy chiqishni yoqish generatsiya odatdagidek yakunlangandek ko‘rinishiga, ammo tana bo‘sh qaytishiga sabab bo‘ldi. Oxir-oqibat, mahalliy formatni majburiy tekshirishni o‘chirib qo‘ydim, JSON sxemasi va “faqat JSON chiqaring” ko‘rsatmasini promptga qayta yozdim hamda natijani tekshirishni parserga topshirdim.

Prompt va parser yordamida formatni majburiy tekshirishni chetlab o‘tish misoli

request.disableNativeSchema();
request.addInstruction("Respond with JSON only.");
request.addInstruction(renderSchema(responseSchema));
 
Response parsed = parser.parse(modelResponse);
validator.validate(parsed);

Bu yondashuv darhol ishladi, ammo shartnomani uchta joyda takrorladi. Vosita sxemasi, prompt matni va parserning himoya qoidalari bir xil mazmunni turli shakllarda ifodalardi. Ulardan istalgan birini o‘zgartirish qolganlarini ham o‘zgartirishni talab qilardi, model yaxshilanganda ham bu takrorlanish avtomatik ravishda yo‘qolmadi.

2.4 Bo‘sh navbatlar va takroriy xatolarni qayta urinishlar bilan qamrab oldim

Bir nechta vosita so‘rovlarini muvaffaqiyatli bajargandan so‘ng, tizim ba’zan mazmuni ham, vosita chaqiruvlari ham bo‘sh bo‘lgan javob qaytardi. Bitta yakuniy navbat sababli allaqachon olingan barcha kuzatuvlarni yo‘qotmaslik uchun bo‘sh javoblarni qayta yuboradigan va qolgan ma’lumotlardan foydalanib javobni yakunlaydigan yo‘l qo‘shdim.

Bo‘sh javobdan tiklanish va bajarish byudjeti

private static final int MAX_EMPTY_RESPONSE_RETRIES = 2;
 
if (response.hasNoContent() && response.hasNoToolCalls()) {
    retryOrFinishWithCollectedEvidence();
}
 
RunBudget budget = RunBudget.of(maxSteps, maxDuration, maxTokens);

Qayta urinishlarning o‘zi zarur himoya chorasi bo‘lishi mumkin. Biroq qayta necha marta urinish va bitta bajarishda nechta qadamga ruxsat berishni o‘sha paytdagi modelning xato chastotasi va chaqiruv odatlariga asoslanib belgiladim. Bir model uchun bu sonlar yetarli emasdi, boshqasi uchun esa ortiqcha edi; bundan tashqari, bir xil konstanta modelga qarab butunlay boshqa xarajatlarni anglatardi.

2.5 Prompt ham muayyan model xatolarining qaydnomasiga aylandi

Nafaqat kod, balki tizim prompti ham “identifikatorlarni aynan ko‘chiring”, “o‘rinbosar qiymatlar yaratmang” va “vosita natijalarini tekshirmasdan xulosa qilmang” kabi ko‘rsatmalarni o‘z ichiga ola boshladi. Bu ko‘rsatmalarning aksariyati bir marta yuz bergan haqiqiy xatodan kelib chiqqan edi.

Prompt uzaygani sari qaysi ko‘rsatmalar mahsulot siyosati, qaysilari esa muayyan model uchun kompensatsiya ekanini ajratish qiyinlashdi. Yangi model allaqachon yaxshi bajarayotgan xatti-harakatlarni ham qayta-qayta talab qilib, muhim siyosatlarning ustuvorligini noaniq qilib qo‘ydik. Bu ham harness modelga moslab yaratilganining dalili edi.

3. Bir xil harnessda faqat modelni almashtirganimda nima sodir bo‘ldi

3.1 Taqqoslash usuli

Gipotezani tekshirish uchun tizim prompti, vosita sxemasi, so‘rov ma’lumotlari va bajarish byudjetini o‘zgartirmagan holda faqat modelni almashtirdim. Haqiqiy amaliyotda ishlatiladigan murakkab so‘rovlarni qayta-qayta ishga tushirdim. Vazifa bir nechta vosita orqali zarur ma’lumotlarni tekshirish va foydalanuvchidan qaror talab qiladigan bandlar bo‘yicha savollar berishni o‘z ichiga olgan.

Umumiy vazifa boshidan oxirigacha uzilishlarsiz yakunlangan-yakunlanmaganini tekshirdim.

Vosita nomlari va argumentlari sxemaga mos kelgan-kelmaganini tekshirdim.

Javob formatidagi xatolar, bo‘sh navbatlar va takroriy qayta urinishlar sodir bo‘lgan-bo‘lmaganini tekshirdim.

Bir xil so‘rov qayta ishga tushirilganda natijalar sezilarli darajada o‘zgargan-o‘zgarmaganini tekshirdim.

Harness aralashuvisiz ham odatiy natijalar saqlangan-saqlanmaganini tekshirdim.

Men yozgan dastlabki loyihada ayrim quyi darajadagi ko‘rsatkichlarni sonlarda jamlagan edim. Biroq qayta ko‘rib chiqqanimda, bu qiymatlar haqiqiy tajriba yoki umumiy muvaffaqiyatni to‘g‘ri ifodalamasligini aniqladim. Masalan, bitta savolning JSON obyekti formatga mos kelgan bo‘lsa ham, avvalgi vosita chaqiruvi muvaffaqiyatsiz bo‘lgan va umumiy vazifa yakunlanmagan bo‘lsa, vazifani muvaffaqiyatli deb atash qiyin. Ushbu hujjatda xotiradan yangi raqamlar yaratish o‘rniga, faqat takroriy ishga tushirishlar orqali amalda qayta hosil qilingan natijalarni holatlar sifatida jamladim.

3.2 Amaldagi kuzatuvlar

1-jadval. Bir xil harnessda faqat model o‘zgartirilgan takroriy ishga tushirishlardan kuzatilgan natijalar

Kuzatuv bandi	gpt-oss:120b	gemma4:31b	qwen3.6:35b	gpt-5.6
Vazifa to‘liq bajarildi	Bajarish jarayonidagi takroriy xatolar barqaror yakunlashni qiyinlashtirdi.	Vosita chaqiruvlari xatolari va bo‘sh javoblar qayta-qayta yuz berdi.	Javob kechikishlari va format xatolari sababli nosozliklar qayta-qayta yuz berdi.	Takroriy ishga tushirishlar orasida vazifani boshidan oxirigacha eng izchil tarzda bajardi.
Vosita chaqiruvlari	Sxemaga mos keladigan chaqiruvlarni amalga oshirishda davom etdi.	Ko‘pincha zarur chaqiruvlarni bajarmadi.	To‘liq bo‘lmagan yakunlanishlar kuzatildi.	Sxemaga mos keladigan chaqiruvlarni amalga oshirishda davom etdi.
Javob formati	Ba’zan formatni tekshirish zarur bo‘ldi.	Bo‘sh javoblardan tiklanish zarur bo‘ldi.	Qayta urinishlar va formatni tekshirish zarur bo‘ldi.	Javoblar bir yoki ikki marta qayta urinilgach barqaror bo‘ldi.
Bajarilishdagi farqlanish	Natijalar va bajarilish jarayonida nisbatan kam farqlanish kuzatildi.	Javob formatida farqlanish mavjud edi.	Javob formatida farqlanish mavjud edi.	Natijalar va bajarilish jarayonida eng kam farqlanish kuzatildi.
Umumiy baholash	Amaldagi sharoitlarda uni ishlab chiqarish muhitiga joriy etish qiyin bo‘ldi.	Amaldagi sharoitlarda uni ishlab chiqarish muhitiga joriy etish qiyin bo‘ldi.	Amaldagi sharoitlarda uni ishlab chiqarish muhitiga joriy etish qiyin bo‘ldi.	Amaliy joriy etish mezonlariga izchil javob bergan yagona model bo‘ldi.

Har bir ishga tushirish bo‘yicha miqdoriy jurnallar o‘sha paytda barcha modellar uchun bir xil formatda saqlanmagani sababli, noaniq bo‘lishi mumkin bo‘lgan yangi muvaffaqiyat ko‘rsatkichlari yoki o‘rtacha vaqtlarni yaratmadim. Jadvalda faqat qayta-qayta kuzatilgan nosozlik namunalari va amaliy joriy etish bo‘yicha xulosalar qayd etilgan.

Natijalar gpt-5.6 modelini yaqqol ma’qulladi. Boshqa model bir sohada tuzatilganida, boshqa joyda yana xato yuz berdi va nosozlik namunasi har bir ishga tushirishda o‘zgardi. Aksincha, gpt-5.6 ayni sinov muhitida vosita chaqiruvlaridan tortib yakuniy savolgacha bo‘lgan jarayonni eng ishonchli tarzda bajardi. Natijalarga men yozgan mukofot kodining miqdoridan ko‘ra, modelning o‘z vositalaridan foydalanish va shartlarga rioya qilish qobiliyati ko‘proq ta’sir ko‘rsatdi.

Ayniqsa muhim farq uning formatga mos javobni bir yoki ikki marta bera olishi emas, balki butun vazifani qayta-qayta yakunlay olishi edi. Mahalliy modellar ham qisman muvaffaqiyatga erishdi. Biroq foydalanuvchilarga taqdim etiladigan funksiya butun jarayonning yakunlanishini talab qiladi. Shu mezon asosida qaralganda, modellar o‘rtasidagi farqlar ancha ravshanlashdi.

Sinov qobig‘i kuchsizroq modellarni ma’lum darajaga olib chiqdi, ammo nosozliklar taqsimotini yo‘q qilmadi. Sinonimlar qo‘shilganda yangi sinonimlar paydo bo‘ldi; qayta urinishlar soni oshirilganda vaqt va xarajat ko‘paydi; qadamlar budjeti oshirilganda esa noto‘g‘ri chaqiruvlar uzoqroq takrorlandi. Mukofot mantig‘i samarali bo‘ldi, ammo uning cheklovlari ham aniq ko‘rindi.

3.3 Sinov qobig‘ining modelga mos kelishi nimani anglatadi

Kompensatsion sinov qobig‘ining kirish ma’lumotlari mahsulot talablari emas, balki modelda kuzatilgan nosozliklardir. Bu kuzatuvlar muayyan model, muayyan versiya, muayyan prompt va muayyan inferensiya serveridan kelib chiqadi. Shu sababli, bu kuzatuvlarni kodga aylantiradigan mukofot mantig‘i ham ayni sharoitlarga bog‘langan bo‘ladi.

Model X kabi ishlamay qoldi. → Sinov qobig‘i Y orqali kompensatsiya qiladi. → Sinov qobig‘i X nosozligini namoyon qilgan modelga mos keladi.

Nodeterministik chiqishlarni deterministik kod bilan o‘rash tizimni barqaror ko‘rsatishi mumkin. Biroq model o‘zgarganda chiqishlar taqsimoti ham o‘zgaradi. Eski modelda tez-tez uchragan xatolar yangi modelda yuz bermasligi mumkin, yangi modelning chaqiruv namunalari esa eski mukofot mantig‘i nazarda tutgan ketma-ketlikdan farq qilishi mumkin. Oxir-oqibat, umumiy maqsadli qatlam deb o‘ylangan kod muayyan model xatti-harakatini yaqinlashtirib ifodalovchi empirik modelga aylanadi.

Shu nuqtayi nazardan, modelni almashtirish shunchaki provayderni o‘zgartirish emas. Bu sinov qobig‘i va model o‘rtasidagi bog‘liqlikni qayta baholash jarayonidir. Agar yangi model ulanib, mavjud mukofot kodi o‘zgartirilmasa, keraksiz zaxira yo‘llar to‘g‘ri qiymatlarni o‘zgartirishi yoki keraksiz qayta urinishlar kechikishlarga sabab bo‘lishi mumkin. Model yangilangandan so‘ng, qo‘shimcha kod qo‘shishdan oldin kodni o‘chirish masalasini ko‘rib chiqish kerak.

4. gpt-5.6 modeliga o‘tgandan so‘ng nimalar yo‘qoldi

gpt-5.6 modeliga o‘tgandan keyingi eng katta o‘zgarish uning mavjud sinov qobig‘idan shunchaki samaraliroq o‘tganida emas edi. Kompensatsiyani talab qiladigan holatlarning o‘zi sezilarli darajada kamaydi. Modelning aniq maydon nomlari va argument formatlarini saqlab qolishi, zarur vositalarni tanlashi va butun vazifani yakunlashi ko‘rsatkichi oshgani sari, umumiy sikldagi tiklash kodiga bo‘lgan asos zaiflashdi.

2-jadval. Model almashtirilishidan oldin va keyin kompensatsion sinov qobig‘idagi o‘zgarishlar

Kompensatsiya bandi	Takroriy xatolarga ega modellar	gpt-5.6 qo‘llangandan keyin
Maydon nomlari sinonimlari	Bir nechta taxalluslarni ketma-ket sinab ko‘rdi.	Belgilangan sxema nomlarini o‘z holicha ishlatdi, shu sababli bu ko‘p hollarda keraksiz bo‘lib qoldi.
Kirish turini aniqlash	Noma’lum qiymatlarni satr qoidalari va variantlar soni asosida aniqladi.	Ruxsat etilgan turlardan foydalandi, shu sababli aniqlash uchun zaxira yo‘lni olib tashlash mumkin bo‘ldi.
Promptda sxemani takrorlash	Shartnomani uzun jumlalar bilan qayta tushuntirdi.	Shartnomani bevosita vosita va javob sxemalariga qaratish mumkin bo‘ldi.
Bo‘sh javobni tiklash	Qayta urinish va kuzatuvni saqlab qolish yo‘llari tez-tez ishga tushdi.	Oddiy yo‘l barqarorlashdi va bu ularni faqat istisno tariqasidagi xatolarni qayta ishlashga qisqartirish imkonini berdi.
Modelga xos qadamlarni moslashtirish	Chaqiruv namunalariga mos kelishi uchun konstantalarni oshirdik.	Keraksiz chaqiruvlar kamaydi va bu bizga soddaroq budjet siyosatini qo‘llash imkonini berdi.

Bu yerda biror narsa “endi zarur emas” deyish kodning barchasi darhol o‘chirildi degani emas. Uni haqiqatda o‘chirishdan oldin yangi model bilan regressiya testlarini ishga tushirishimiz va kompensatsiya mantiqini birma-bir o‘chirgan holda natijalar barqaror qolishini tekshirishimiz kerak. Muhim o‘zgarish tekshiruv yo‘nalishining o‘zgarganidir — ko‘proq kompensatsiya qo‘shish tomon emas, balki mavjud kompensatsiyani olib tashlash mumkinligini tekshirish tomon.

Yaxshi model faqat javoblarning aniqligini oshirmaydi. U parser tarmoqlarini, qayta urinishlar sonini, modelga xos sozlamalarni, xatolar jurnallarini tahlil qilishni va regressiya testlari kombinatsiyalarini ham kamaytiradi. Faqat har bir chaqiruv narxiga qarasangiz, lokal model arzonroq bo‘lishi mumkin, ammo xatolarni tekshirish va kompensatsiya kodini qo‘llab-quvvatlash uchun ketadigan ishlab chiqish xarajatlarini ham hisobga olsangiz, xulosa o‘zgaradi. Haqiqiy loyihada gpt-5.6 ni tanlash umumiy xarajat va xatarni kamaytirdi.

Yana bir saboq shundan iborat bo‘ldiki, modelni baholash bitta javob sifati bilan yakunlanmasligi kerak. Agentlar uchun vositani tanlash, argumentlarning aniqligi, bir nechta navbat davomida holatni saqlash, xatodan keyin tiklanish va yakuniy javob birgalikda unumdorlikni tashkil etadi. gpt-5.6 ning ustunligi shunchaki yaxshiroq jumlalar yozganida emas, balki butun ijro grafigini oxirigacha bajarganida edi.

5. Shunga qaramay qolishi kerak bo‘lgan harnesslar

Yaxshi model kompensatsiya beruvchi harnesslarni kamaytirsa ham, tizimning mas’uliyatini o‘z zimmasiga olmaydi. Model qanchalik aniq bo‘lmasin, u ruxsatsiz ma’lumotlarni o‘qimasligi, tasdiqsiz qaytarish qiyin bo‘lgan o‘zgarishlarni bajarmasligi yoki foydalanilgan dalillar va ijro natijalarini kuzatish imkonini to‘smasligi kerak.

5.1 Kompensatsiyani mas’uliyatdan ajratish uchun savollar

Kodni tasniflashda men quyidagi savoldan foydalandim: “Agar model shartnomaga mukammal amal qilsa, bu kod baribir zarur bo‘ladimi?” Javob “yo‘q” bo‘lsa, u kompensatsiya beruvchi harness edi; javob “ha” bo‘lsa, u tizim mas’uliyatiga yaqinroq edi.

3-jadval. Kompensatsiya beruvchi harnesslar va mas’uliyatni ta’minlovchi harnesslar o‘rtasidagi chegara

Toifa	Kompensatsiya beruvchi harness	Mas’uliyatni ta’minlovchi harness
Yuzaga kelish asosi	Muayyan modelda kuzatilgan xato.	Mahsulot siyosati, xavfsizlik va operatsion mas’uliyat.
Modelga bog‘liqlik	Yuqori. U model va versiyaga qarab o‘zgaradi.	Past. Provayder o‘zgarganda ham u saqlanib qoladi.
Namunaviy misollar	Sinonimlarni tahlil qilish, qiymatlarni taxmin qilish, bo‘sh navbatlar uchun qayta urinishlar va modelga xos konstantalar.	Avtorizatsiya tekshiruvlari, tasdiqlash bosqichlari, budjet cheklovlari va audit yozuvlari.
Yaxshi modelni qo‘llagandan so‘ng	Regressiya tekshiruvidan keyin o‘chirish yoki adaptergacha qisqartirish.	O‘z holicha qoldirish va testlarni kuchaytirish.
Xatolarni qayta ishlash	Imkon bo‘lsa, uni yashirincha tuzatmang; sababini aniq ko‘rsating.	Siyosat buzilganda, ijroni to‘xtating va sababini qayd eting.

5.2 Foydalanuvchi tasdig‘i va o‘zgarish chegaralari saqlanishi kerak

Faqat o‘qish uchun mo‘ljallangan so‘rovlar va haqiqiy o‘zgarishlarni teng vosita chaqiruvlari deb hisoblamadik. Agent ma’lumotni tekshiradigan va o‘z rejasini tushuntiradigan bosqichgacha jarayonni avtomatlashtirdik, ammo ma’lumotlar o‘zgartiriladigan yoki natijalar tashqi tomonda e’lon qilinadigan nuqtada foydalanuvchining aniq tasdig‘ini talab qildik. Bu chegara model unumdorligiga aloqador emas.

Ichki nomlarni olib tashlash orqali umumlashtirilgan tasdiqlash oqimi

사용자 요청
  -> 읽기 전용 조회
  -> 변경 계획과 영향 제시
  -> 사용자 승인
  -> 실제 변경 실행
  -> 결과와 근거 기록

Shuningdek, model ularni qayta yozishi o‘rniga, tizim savollar yoki tasdiqlash so‘rovlarini belgilangan tuzilma asosida foydalanuvchiga yetkazishi amaliyotini saqlab qoldik. Bu shunchaki model maydon nomlarini xato kiritishi ehtimolini bartaraf etuvchi kompensatsiya emas; bu foydalanuvchi qarorlarini generatsiya qilingan matndan ajratib turadigan mahsulot tamoyilidir.

5.3 Budjetlar, ruxsatlar va audit yozuvlari saqlanishi kerak

Bitta ijro foydalanishi mumkin bo‘lgan qadamlar, vaqt va tokenlar soniga cheklov qo‘yadigan tuzilma zarur. Biroq raqamlarning o‘zi model tezligi va chaqiruv usuliga qarab o‘zgarishi mumkin, shuning uchun ularni konfiguratsiyaga ajratish kerak. Cheklov mavjud bo‘lishi haqidagi siyosat mas’uliyatni ta’minlovchi harness, muayyan modelga moslashtirilgan qiymat esa kompensatsiya sozlamasidir.

Vositalar uchun ruxsat berilgan ro‘yxatlar yoki avtorizatsiya tekshiruvlarini ham model zimmasiga qoldirmaymiz. Foydalanuvchida so‘rov yuborish ruxsati yo‘qligi bilan so‘rov natijasi bo‘sh bo‘lgan vaziyat foydalanuvchi uchun mutlaqo boshqa ma’nolarga ega. Model farqni yaxshi tushuntirsa ham, chaqiruvga ruxsat berilgan-berilmaganini aniqlaydigan subyekt tizim bo‘lishi kerak.

Nihoyat, qaysi so‘rov uchun qaysi vositalar chaqirilgani va qaysi natijalar javobga asos bo‘lganini qayd etishimiz kerak. Ishlab chiqarish muhitida muammo yuzaga kelib, faqat modelning yakuniy jumlasi qolsa, sababni qayta tiklay olmaymiz. Model sifati yaxshilangani sayin audit yozuvlari ahamiyatini yo‘qotmaydi; haqiqiy foydalanish ko‘lami kengaygani sari ular yanada muhimlashadi.

6. Model tanlovi va harnesslarni birgalikda loyihalash

Bu tajribadan so‘ng avval kuchsiz modelni tanlab, uni harness yordamida kompensatsiya qilish jarayonini o‘zgartirdik. Avval nomzod modellarni faqat minimal shartnoma va xavfsizlik mexanizmlariga ega bo‘lgan yupqa ijrochi bilan baholaymiz, so‘ng namunaviy ssenariylarni oxirigacha bajara oladigan modelni tanlaymiz. Shundan keyingina takroriy ravishda davom etayotgan xatolarni ajratilgan adapter ichida kompensatsiya qilamiz.

6.1 Avval umumiy vazifa muvaffaqiyatini o‘lchang

Agar faqat JSON ni bir marta tahlil qilish yoki bitta vosita chaqiruvini muvaffaqiyatli bajarish ko‘rsatkichiga qarasak, haqiqiy foydalanish qulayligini ortiqcha baholash oson. Foydalanuvchi istagan natijaga erishilgan-erishilmagani, ayni so‘rov takrorlanganda natija izchil qolishi va xato yuz berganda uning sababi aniq bo‘lish-bo‘lmasligini birgalikda hisobga olishimiz kerak.

Namunaviy ish ssenariylarini qisqa bo‘laklarda emas, boshidan oxirigacha bajaring.

Har bir model uchun bir xil prompt, vositalar, ma’lumotlar va budjetdan foydalaning.

Yakuniy muvaffaqiyat holati bilan birga vosita argumentlaridagi xatolarni, bo‘sh navbatlarni, qayta urinishlarni va o‘tgan vaqtni qayd eting.

Harness yoqilgan holatdagi natijani kompensatsiya mantiqi o‘chirilgan holatdagi natija bilan yonma-yon taqqoslang.

Modellarni o‘zgartirgandan so‘ng, yangi kompensatsiya qo‘shishdan oldin mavjud kompensatsiyani o‘chirish mumkinligini tekshiring.

6.2 Kompensatsiya kodini adapter ichida cheklang

Modelga xos kompensatsiya mantiqi umumiy bajarish sikliga joylashtirilsa, kod qaysi model uchun mavjudligini aniqlash qiyinlashadi. Kompensatsiyani provayder yoki model adapteri ichida saqlab, umumiy sikl aniq shartnoma bajarilayotganini nazarda tutgani ma’qul. Shartnomani bajarib bo‘lmaganda, yechimni jimgina taxmin qilishdan ko‘ra, tashxis qo‘yish mumkin bo‘lgan xato bilan ishlashni to‘xtatish uzoq muddatda xavfsizroqdir.

Kompensatsiya qo‘shishdan qochib bo‘lmaganda, model nomi, versiyasi, qayta tiklash shartlari va olib tashlash shartlari izohlar hamda testlarda qayd etilishi kerak. Shunda keyingi modelga o‘tganda, olib tashlash uchun mos qismlarni darhol aniqlash mumkin bo‘ladi. Kompensatsiya kodi nafaqat uning vazifasi tavsifiga, balki qancha vaqt davomida amal qilishini aniqlash uchun asosga ham ega bo‘lishi kerak.

6.3 Model xarajatlariga texnik xizmat ko‘rsatish xarajatlarini ham qo‘shing

Model tanlash jadvalida odatda faqat token narxlari va inferensiya serveri xarajatlari ko‘rsatiladi. Biroq haqiqiy loyihalarda nosozliklarni tahlil qilish, kompensatsiya kodini ishlab chiqish va sinash uchun sarflangan vaqt, qayta urinishlar sababli yuzaga keladigan kechikishlar hamda operatsion hodisalar ehtimoli ham xarajat hisoblanadi. Mahalliy modeldan foydalanish narxi past bo‘lsa ham, uning xatolarini doimiy ravishda tozalab borish kerak bo‘lsa, umumiy xarajat yuqoriroq bo‘lishi mumkin.

Mening holatimda gpt-5.6 model xarajatlarini kamaytirishdan ko‘ra, ishlab chiqish jarayonini soddalashtirish orqali ko‘proq ta’sir ko‘rsatdi. Har safar nosozlik qayta yuzaga kelganda yangi tarmoq qo‘shish zarurati kamaydi va men asosiy siyosatlar hamda vosita shartnomalariga e’tibor qarata oldim. Yuqori samaradorlikka ega modelni tanlash shunchaki sifatni yaxshilash emas, balki kod va operatsion murakkablikni kamaytirish tanloviga aylandi.

7. Ilovadan foydalanishdan so‘ng tuzilgan amaliy tekshiruv ro‘yxati

Hozirda modelni joriy etish yoki almashtirishda quyidagilarni ketma-ket tekshiraman.

Nomzod model namunaviy ssenariylarni boshidan oxirigacha ishonchli tarzda bajara olishini tasdiqlang.

Nosozliklarni chiqish formati, vosita tanlovi, argumentlarning aniqligi, holatni saqlash va kechikish toifalariga ajratgan holda qayd eting.

Modelning o‘ziga xos muammolarini umumiy biznes mantiqida kompensatsiya qilmang.

Kompensatsiya mantiqini modelga xos adapterlar va konfiguratsiyada ajrating hamda olib tashlash shartlarini uning yonida qayd eting.

Tasdiqlash, avtorizatsiya, bajarish budjetlari va audit yozuvlarini modeldan mustaqil siyosatlar sifatida saqlang.

Modelni yangilashda funksionallik qo‘shishdan avval keraksiz harness kodini o‘chirish imkoniyatini ko‘rib chiqing.

Miqdoriy jurnallar mavjud bo‘lmaganda, xotiraga asoslanib raqamlarni o‘ylab topmang; faqat qayta tiklash mumkin bo‘lgan hodisalarni ulashing.

Ushbu tekshiruv ro‘yxatining maqsadi harnessni yo‘q qilish emas. U model nimaga mas’ul ekanini tizim nimaga mas’ul ekanidan ajratib ko‘rsatish uchun mo‘ljallangan. Agar kodga model nuqsonlarini cheksiz ravishda o‘ziga singdirishga ruxsat berilsa, harness tobora qalinlashib boradi va hech bir model uchun optimal bo‘lmagan oraliq qatlamga aylanadi.

Xulosa

Dastlab, yaxshi harness modellar o‘rtasidagi farqlarni yo‘q qila oladi deb o‘ylagan edim. Aslida esa harnessning sezilarli qismi bitta modelning nuqsonlarini ko‘chirib yozgan koddan iborat edi. Bu kod o‘sha paytda muammolarni hal qilgan, ammo boshqa modellarda ham zarur bo‘lib qoladigan umumiy qoida emas edi.

Bir xil harnessni bir nechta modelga ulaganimda, gpt-5.6 samaradorligi juda yuqori bo‘ldi, boshqa modellarda esa xatolar yuz berishda davom etdi. Bu tajriba menga model samaradorligi shunchaki komponent spetsifikatsiyasi emasligini; u harnessning hajmi va shaklini belgilashini anglatishini anglatdi. Kuchsiz modelni qoplash uchun qancha ko‘p kod to‘plansa, tizim shunchalik kuchli ravishda aynan shu modelga moslashib boradi.

Yaxshi model butun harnessni yo‘q qilmaydi. U model nuqsonlarining o‘rnini to‘ldirib kelgan kompensatsion harness kodini kamaytiradi va faqat tizim oxirigacha o‘zi mas’ul bo‘lib qolishi kerak bo‘lgan harness qismini — masalan, tasdiqlash, avtorizatsiya, budjetlashtirish va auditni — qoldiradi.

Shuning uchun model tanlashda faqat chaqiruv xarajatlarini taqqoslamaslik kerak. Shuningdek, vazifaning umumiy muvaffaqiyat darajasi, xatolarning takrorlanuvchanligi, kompensatsiya kodining hajmi, operatsion xatarlar va ishlab chiquvchilarning muammolarni tozalashga sarflaydigan vaqtini ham hisobga olish lozim. Loyiha uchun gpt-5.6 ni tanlash sababi xuddi shu mezonlar asosida tushuntirilishi mumkin. Yuqori samaradorlikka ega modeldan foydalanish nafaqat natijalarni yaxshiladi, balki tizimni soddaroq va tushuntirish osonroq qildi.

Kelajakda model yana o‘zgarsa ham, avval o‘zimga shu savolni berishni rejalashtiryapman: men hozir qo‘shmoqchi bo‘lgan kod tizimning mas’uliyatimi yoki joriy modelning kamchiliklari uchun vaqtinchalik kompensatsiyami? Ushbu farqni hujjatlashtirib borish keyingi modelga o‘tganda nimani o‘chirish va nimani saqlab qolish kerakligini menga eng tez ko‘rsatadigan mezonga aylandi.

IAN