LLM’larga ishonishdan oldin, avval ularni shubha ostiga olishdan boshladim

Kirish

Loyihani amalga oshirish jarayonida odamlar tomonidan yozilgan ish hujjatlarini keyingi jarayonlarda foydalanish mumkin bo‘lgan tuzilmaviy ma’lumotlarga aylantirib, tartibga solishim kerak bo‘ldi. Hujjatlarda biznes maqsadlari, mas’ul shaxslar, qayta ishlash tartiblari, qoidalar va istisnolar tabiiy tilda bayon qilingan edi. Odamlar kontekstni o‘qib, tushuna oladi, biroq dasturlar hujjatlardan qidirish, tasniflash va ko‘rib chiqish kabi keyingi vazifalarda foydalanishi uchun ularni izchil maydonlar va formatlarga aylantirish kerak.

Dastlab hujjat va uni aylantirish bo‘yicha ko‘rsatmalarni LLM’ga berib, mazmunni JSON sifatida tartibga solishni so‘rashning o‘zi kifoya deb o‘yladim. Amalda LLM qisqa vaqt ichida tartibli ko‘rinadigan natijalarni yaratdi. Biroq asl matnda mavjud bo‘lmagan tartiblar ba’zan tabiiy tarzda qo‘shib yuborildi yoki muhim jumla natijadan sezdirmay tushib qoldi. Mas’ul shaxs bajargan harakatlar bilan qayta ishlash natijalari ham ba’zan aralashtirib yuborildi.

Masalan, asl matnda faqat “Tekshiruvchi so‘rovni tasdiqlashi yoki qo‘shimcha ma’lumot so‘rashi mumkin” deb yozilgan bo‘lishi mumkin, biroq LLM umumiy biznes amaliyotlariga asoslanib, “Jamoa rahbari yakuniy tasdiqni beradi” qoidasini qo‘shib yuborishi mumkin. Bu jumla tabiiy eshitiladi, ammo asl matnda mavjud emas. Agar JSON formati to‘g‘ri bo‘lgani uchungina ushbu natijadan foydalanilsa, modelning taxmini biznes faktiga aylanadi.

Shuning uchun maqsadni “LLM to‘liq ma’lumotlarni yaratsin”dan LLM tuzilmaviy nomzodlarni yaratsin, tizim tuzilma va asl matndagi dalillarni tekshirsin, natijadan foydalanish yoki foydalanmaslik haqida esa yakunda inson qaror qilsin.

Ushbu maqolada javoblarni belgilangan JSON formatida qabul qiluvchi Structured Output; chiqish shartnomasini belgilovchi JSON Schema; asl matndagi asosni ko‘rsatuvchi Evidence; hamda validatsiya xatolaridan foydalanadigan cheklangan Repair jarayoni tanishtiriladi. Asosiy masala — ehtimollik asosida yaratilgan natijalarni tekshirilishi mumkin bo‘lgan ma’lumotlar sifatida qanday ko‘rishdir.

Avval tekshiriladigan yakuniy tuzilma

1-rasm. Tuzilmagan ish hujjati Prompt va JSON Schema bilan birga berilib, natija deterministik tarzda validatsiya qilinadigan oqim

Avval biz tuzgan yakuniy tuzilmani ko‘rib chiqaylik. Tuzilmaviy nomzodlarni yaratish uchun asl matn, Prompt va JSON Schema birgalikda LLM’ga beriladi, so‘ng tizim tuzilmani, kiritilgan ma’lumotlarning qamrovini, asl matndagi dalillarni va yetishmayotgan ma’lumotlarni tekshiradi. Bu yerda deterministik validatsiya deganda bir xil qoidalar bir xil kiritilgan ma’lumotga qo‘llanganda har doim bir xil natija beradigan tekshiruv nazarda tutiladi. Agar validatsiya muvaffaqiyatsiz tugasa, tizim xatolarni ham qo‘shgan holda cheklangan tuzatishni amalga oshiradi. Agar u yana muvaffaqiyatsiz tugasa, natija avtomatik ravishda qo‘llanmaydi, balki qo‘lda ko‘rib chiqish uchun yuboriladi.

Quyidagi bo‘limlarda dastlabki yondashuvda yuzaga kelgan muammolar va ularni hal qilish uchun har bir validatsiya bosqichini qanday qo‘shganimiz ketma-ket tushuntiriladi.

Dastlab ko‘zda tutilgan tuzilma: Prompt va JSON Schema yetarlimi?

Dastlabki kiritilgan ma’lumot odam tomonidan yozilgan ish hujjati edi. Aylantirish jarayonini osonroq tushuntirish uchun ushbu maqolada “Vazifa so‘rovini ko‘rib chiqish tartibi” deb nomlangan sodda misoldan foydalaniladi. Quyidagi ma’lumot maydonlari ham hujjat bilan tuzilmaviy natija o‘rtasidagi bog‘liqlikni ko‘rsatish uchun ishlab chiqilgan.

Aylantiriladigan ish hujjati namunasi

작업 요청 검토 절차
 
배경
현재 작업 요청을 메일과 메신저로 전달하고 있어 요청 상태와 처리 이력을
일관되게 확인하기 어렵습니다.
 
목표
요청자는 작업 내용을 등록하고 검토 결과를 확인할 수 있어야 합니다.
검토자는 검토가 요청된 작업을 승인하거나 보완을 요청할 수 있어야 합니다.
 
담당자
- 요청자는 작업 내용을 작성하고 검토를 요청합니다.
- 검토자는 검토가 요청된 작업 내용을 확인합니다.
 
처리 절차
1. 요청자가 작업 내용을 작성합니다.
2. 요청자가 검토를 요청합니다.
3. 검토자는 요청을 승인하거나 보완을 요청합니다.
4. 검토자는 처리 결과와 검토 의견을 기록합니다.
 
업무 규칙
- 검토를 요청한 작업만 검토할 수 있습니다.
- 검토 결과에는 처리자와 처리 시각이 포함되어야 합니다.

Ushbu hujjatdan olinishi ko‘zlangan natija

Men istagan natija hujjatning qisqa xulosasi emas edi. Men hujjatda tasvirlangan mas’ul shaxslar va qayta ishlash tartiblarini o‘zaro bog‘lab, dastur qidirishi va ko‘rib chiqishi mumkin bo‘lgan tuzilmaviy nomzodlarni yaratmoqchi edim.

Namunaviy hujjat mazmuni	Istalgan tuzilmaviy natija
Kontekst va maqsad	Hujjat erishishni ko‘zlagan maqsad (documentPurpose)
So‘rov yuboruvchi va tekshiruvchi	Identifikatorlari ko‘rsatilgan ishtirokchilar ro‘yxati (participants)
Yozish, ko‘rib chiqishni so‘rash, tasdiqlash, qo‘shimcha ma’lumot so‘rash va natijani qayd etish	Mas’ul tomonlar va bajarilish tartibi ko‘rsatilgan qayta ishlash bosqichlari (processSteps)
Ko‘rib chiqish shartlari va qayd etiladigan bandlar	Alohida boshqariladigan biznes qoidalari (rules)
Hujjatda mavjud bo‘lmagan mas’ul shaxslarni tayinlash mezonlari	O‘zboshimchalik bilan nullqiymatiga to‘ldirilmaydi, balki tasdiqlash savollari beriladi (missingFields)
Natija manbasi	Tegishli qiymatga bog‘langan asl matndan iqtibos (evidence)

Boshqacha aytganda, istalgan chiqish quyidagilardan iborat: hujjat asosida tuzilmaga keltirilgan qiymatlar, faqat hujjatning o‘zidan aniqlab bo‘lmaydigan savollar, Har bir qiymat uchun asl manba asosini ham kiritish kerak edi.Faqat maqsadli chiqish aniqlangandagina manbadan nimalar olingani va nimalar yetishmayotganini izchil aniqlashimiz mumkin. Biz bu mezonni JSON Schema sifatida ifodaladik.

Chiqish shartnomasi sifatida ishlatiladigan oddiy JSON Schema

Bu umumiy jarayonni tushunish uchun zarur bo‘lgan elementlargina saqlab qolingan soddalashtirilgan Schema misolidir.

{
  "type": "object",
  "additionalProperties": false,
  "required": [
    "documentPurpose",
    "participants",
    "processSteps",
    "rules",
    "assignmentRule",
    "missingFields",
    "evidence"
  ],
  "properties": {
    "documentPurpose": { "type": "string" },
    "participants": {
      "type": "array",
      "items": { "type": "object", "required": ["id", "name"] }
    },
    "processSteps": {
      "type": "array",
      "items": { "type": "object", "required": ["order", "actorId", "action"] }
    },
    "rules": { "type": "array" },
    "assignmentRule": {
      "type": ["string", "null"],
      "description": "원문에 배정 기준이 없으면 null"
    },
    "missingFields": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["fieldPath", "question"]
      }
    },
    "evidence": { "type": "array" }
  }
}

Bu jarayonda Schema, Prompt va Validator vazifalarini quyidagicha taqsimladik.

Schema    : 필수 필드와 데이터 형식을 제한합니다.
Prompt    : 원문에 없는 값은 추측하지 않고 null과 확인 질문으로 반환하게 합니다.
Validator : 참조 관계, 원문 근거, null과 확인 질문의 대응 여부를 검사합니다.

Masalan, Schema assignmentRule maydonini majburiy deb belgilaydi, lekin null qiymatiga ham ruxsat beradi. Namuna hujjatida faqat reviewer so‘rovni tasdiqlashi yoki qo‘shimcha ma’lumot so‘rashi mumkinligi tushuntirilgan; bir nechta reviewer orasida kim mas’ul ekanini aniqlash mezoni berilmagan. Shuning uchun Prompt bu qiymatni taxmin qilmasdan, aniqlashtiruvchi savol bilan birga null qiymatini qaytaradigan qilib ishlab chiqiladi, Validator esa bu ikki qiymat haqiqatan ham birgalikda mavjudligini tekshiradi.

Hujjatdan yaratilgan strukturaviy nomzodlar

Yuqoridagi hujjat dastur o‘qiy oladigan strukturaviy nomzodlarga aylantirilganda, u quyidagi ko‘rinishga ega bo‘ladi. Bu ma’lumotlar tuzilmasi maqolani tushuntirish uchun yaratilgan misoldir; u yakuniy javob emas, balki validatsiya va inson tomonidan ko‘rib chiqishdan o‘tishi kerak bo‘lgan oraliq natijadir.

{
  "documentPurpose": "작업 요청의 진행 상황과 처리 이력을 일관되게 확인한다.",
  "participants": [
    { "id": "requester", "name": "요청자" },
    { "id": "reviewer", "name": "검토자" }
  ],
  "processSteps": [
    {
      "order": 1,
      "actorId": "requester",
      "action": "작업 내용을 작성한다."
    },
    {
      "order": 2,
      "actorId": "requester",
      "action": "검토를 요청한다."
    },
    {
      "order": 3,
      "actorId": "reviewer",
      "action": "승인하거나 보완을 요청한다."
    },
    {
      "order": 4,
      "actorId": "reviewer",
      "action": "처리 결과와 검토 의견을 기록한다."
    }
  ],
  "rules": [
    "검토를 요청한 작업만 검토할 수 있다.",
    "검토 결과에는 처리자와 처리 시각을 포함한다."
  ],
  "assignmentRule": null,
  "missingFields": [
    {
      "fieldPath": "assignmentRule",
      "question": "여러 검토자 중 담당자는 어떤 기준으로 정합니까?"
    }
  ],
  "evidence": [
    {
      "fieldPath": "processSteps[1]",
      "sourceExcerpt": "요청자가 검토를 요청합니다."
    }
  ]
}

Bu natijadan qidiruv va ko‘rib chiqish kabi keyingi jarayonlarda foydalanish uchun faqat to‘g‘ri JSON sintaksisi yetarli emas. Bundan tashqari, manbadagi hech bir mas’ul shaxs yoki jarayon tushirib qoldirilmaganini, Evidence haqiqatan ham manba matnida mavjudligini va model aniqlanmagan siyosatni o‘zboshimchalik bilan o‘ylab topmaganini tekshirishimiz kerak.

Dastlab, yetarlicha batafsil Prompt va JSON Schema taqdim etish orqali barqaror natijalarga erishamiz deb kutgandik. Schema yordamida majburiy maydonlar, ma’lumot turlari va obyekt tuzilmalarini chekladik hamda Structured Output funksiyasidan foydalanib, javoblarni JSON shaklida oldik.

Bu yondashuv ko‘plab asosiy muammolarni hal qildi. JSON oldidan yoki keyin tushuntirishlar qo‘shilishi, Markdown kod bloklarining aralashtirib yuborilishi va maydon nomlarining turli ishga tushirishlarda o‘zgarishi kabi muammolar sezilarli darajada kamaydi. Schema yetkazib berilishi, javoblarni tahlil qilish va xatolarni qayta ishlash yo‘llarini avtomatlashtirilgan testlar orqali takroran tekshirish ham mumkin bo‘ldi.

Biroq tuzilma barqarorlashgach, yanada muhimroq muammo yaqqol namoyon bo‘la boshladi. JSON to‘g‘ri bo‘lishi bilan biznes mazmunining aniq bo‘lishi butunlay boshqa masalalardir.

Birinchi muammo: format to‘g‘ri bo‘lsa ham, mazmun noto‘g‘ri bo‘lishi mumkin

Baholash jarayonida tez-tez aniqlangan muammolardan biri mas’ul shaxs, harakat va qayta ishlash natijasining chalkashtirilishi edi. Manbada “Reviewer so‘rovni tasdiqlaydi yoki qo‘shimcha ma’lumot so‘raydi” deb yozilgan bo‘lsa ham, ayrim javoblarda manbada mavjud bo‘lmagan approver nomli yangi ishtirokchi yaratilgan yoki “review completed” deb nomlangan yangi bosqich qo‘shilgan.

Bu natija JSON Schema tekshiruvidan ham o‘tishi mumkin. Buning sababi participants va processSteps massivlar bo‘lib, ularning qiymat turlari to‘g‘ri ekanidir. Biroq manbada mavjud bo‘lmagan shaxs yoki jarayon qo‘shilgani sababli biznes mazmuni o‘zgargan.

Yana bir muammo reference munosabatlaridagi nomuvofiqlik edi. Qayta ishlash bosqichining actorId qiymati participants ichida mavjud bo‘lmasligi yoki bir xil ishtirokchi turli IDlar bilan ifodalanishi mumkin edi. Har bir obyekt alohida qaralganda to‘g‘ri ko‘rinadi, ammo obyektlar o‘rtasidagi munosabatlar buzilgan bo‘ladi. Identifikator formatlarini shunchaki me’yorlashtirish noto‘g‘ri talqin qilingan ma’noni tuzatmaydi.

Shu nuqtadan boshlab validatsiyani ikki qatlamga ajratdik.

구조 검증
  - JSON 문법
  - 필수 필드
  - 타입
  - enum
  - key 형식
 
의미 보존 검증
  - 원문 항목 누락 여부
  - 참여자와 처리 단계의 참조 일관성
  - 처리 순서의 중복과 역전 여부
  - 원문 근거 존재 여부
  - 원문에 없는 값의 임의 생성 여부

Schema muhim bo‘lib qoldi, ammo biz uni faqat zaruriy shart sifatida ko‘rdik. Uning ustiga bir xil kiritish uchun har doim bir xil xulosa chiqaradigan qoidalarga asoslangan Validator qo‘shdik va manba bilan natija o‘rtasidagi farqlarni alohida baholash ma’lumotlari sifatida saqlab qoldik.

Ikkinchi muammo: model o‘qimagan gaplarni qanday topish mumkin?

LLM javobida ayrim natijalar yetishmaganda, ma’lumot manbada haqiqatan ham mavjud emasmi yoki model uni e’tibordan chetda qoldirdimi — buni ajratish qiyin edi. Bu farqni faqat chiqishni tekshirish orqali aniqlab bo‘lmaydi.

Buni hal qilish uchun kiritilgan hujjatni bo‘sh bo‘lmagan gap birliklariga ajratdik va ularga identifikatorlar tayinladik. Har bir gap bir yoki bir nechta natija maydoniga bog‘lanishi yoki nima sababdan o‘zgartirilmagani ko‘rsatilishi kerak edi.

MAPPED    : 하나 이상의 결과 필드와 연결됨
UNMAPPED  : 현재 출력 구조에 대응하는 필드가 없음
EXCLUDED  : 변환 대상이 아닌 문장으로 명시적으로 제외됨

Majburiy maydonlarning to‘liqligi kiritilgan gaplarning holatidan alohida boshqarildi.

PRESENT      : 원문 근거를 가진 값이 존재함
NEEDS_INPUT  : 원문만으로 확정할 수 없어 사용자 확인이 필요함

Ularni shu tarzda ajratishning sababi shundaki, manbada butunlay mavjud bo‘lmagan ma’lumotni muayyan kiritilgan gapning holati sifatida ifodalab bo‘lmaydi. Kiritish qamrovi “qaysi gaplar qayta ishlanganini”, maydonlarning to‘liqligi esa “majburiy qiymatlar yetarlimi yoki yo‘qmi”ni kuzatadi.

Buni baholash hujjatiga qo‘llaganimizdan so‘ng, qayta ishlanmagan gaplarni darhol topish hamda model tomonidan tushirib qoldirilgan ma’lumotlarni chiqish tuzilmasining cheklovlaridan ajratish imkoniga ega bo‘ldik. Har bir mazmuniy qismni biror maydonga majburan joylashtirmasdan, gaplarning jimgina yo‘qolib ketishining oldini oldik.

Uchinchi muammo: dalilga o‘xshab ko‘ringan gapni ham model yaratgan bo‘lishi mumkin

O‘zgartirish natijalariga bo‘lgan ishonchni oshirish uchun har bir natija elementiga asl manba Evidence ma’lumotini biriktirdik. Dastlab model qaytargan sourceExcerpt qiymatini o‘zgartirmasdan saqladik. Biroq baholash shuni ko‘rsatdiki, Evidence ba’zan manbadagi gaplar o‘rniga model tomonidan umumlashtirilgan yoki qayta yozilgan gaplardan iborat bo‘lgan.

Masalan, manba matni quyidagicha bo‘lsin.

검토자는 요청을 승인하거나 보완을 요청할 수 있습니다.

Agar model quyidagi gapni Evidence sifatida qaytarsa, uning ma’nosi o‘xshash ko‘rinishi mumkin.

검토자는 모든 요청의 최종 처리 결과를 결정합니다.

Biroq ikkinchi gap manbada mavjud emas. U kuchliroq vakolatni anglatadi va model talqinini o‘z ichiga oladi. Agar uni dalil sifatida qabul qilsak, model o‘zi yaratgan da’voni o‘z natijasi uchun dalil sifatida ishlatadigan doiraviy holat yuzaga keladi.

Shuning uchun biz faqat bo‘sh joylarni me’yorlashtirdik va sourceExcerpt ruxsat berilishidan oldin uning kiritilgan hujjatda haqiqatan ham mavjud bo‘lishini talab qildik. Bu model tomonidan umumlashtirilgan yoki qayta yozilgan gaplarning Evidence sifatida tasdiqlanishiga yo‘l qo‘ymadi.

Biroq Exact Match faqat gapning manbada mavjudligini kafolatlaydi. Ushbu gap o‘zi bog‘langan maydonni haqiqatan ham qo‘llab-quvvatlaydimi yoki yo‘qmi — bu alohida masala. Shuning uchun Evidence validatsiyasini quyidagicha ajratdik.

1단계: 원문성 검증
  sourceExcerpt가 입력 문서에 실제로 존재하는가?
 
2단계: 연결 검증
  Evidence가 가리키는 fieldPath가 실제 결과 항목과 일치하는가?
 
3단계: 의미 정합성 검증
  이 문장이 해당 결과를 충분히 뒷받침하는가?

Matn manbadan olingan-o olinmaganini qoidalar orqali tekshirish mumkin, ammo semantik muvofiqlik inson tomonidan ko‘rib chiqilishini talab qiladi. Validator kafolatlaydigan doirani matnning manbada mavjud yoki mavjud emasligini tekshirish bilan aniq chekladik.

Noma’lum qiymatlarni to‘ldirmang; modelni savol berishga majburlang

LLMlar bo‘sh joyga duch kelganda, uni tabiiy ravishda to‘ldirishga moyil bo‘ladi. Bu umumiy yozuvda afzallik hisoblanadi, ammo biznes hujjatlarini strukturaga solishda xavflidir. Manbada biznes maqsadi yoki mas’uliyat chegaralari bo‘lmasa, model odatiy soha amaliyotlarini yozsa, natija tabiiy eshitilishi mumkin, ammo baribir haqiqatga mos kelmasligi ehtimol.

Buning oldini olish uchun shartnomani o‘zgartirdik: majburiy qiymatni manbada tasdiqlab bo‘lmasa, model qiymatni yaratish o‘rniga savol qaytaradi.

{
  "missingFields": [
    {
      "fieldPath": "documentPurpose",
      "question": "이 업무가 최종적으로 달성해야 하는 결과는 무엇입니까?"
    }
  ]
}

Bu dizaynda savol xato xabari emas. U o‘zgartirish jarayonining odatiy natijasidir. U manba ma’lumoti yetarli bo‘lmagan holatlarni model mazmunni e’tibordan chetda qoldirgan holatlardan ajratadi va foydalanuvchiga keyingi bosqichda ma’lumotni to‘ldirish imkonini beradi.

Haqiqiy baholashlarda foydalanuvchiga beriladigan aniqlashtiruvchi savollar kutilganidan ko‘ra tez-tez yaratilgan holatlar bo‘ldi. Dastlab savollar sonini kamaytirish kerak deb o‘yladik, ammo ularning mazmunini tekshirganimizda, ko‘pchiligi model ilgari jimgina taxmin qilib kelgan noaniqliklarni ifodalashini aniqladik. Savollar sonini shunchaki kamaytirishdan ko‘ra, takroriy savollarni birlashtirish va haqiqiy qarorlar uchun zarur bo‘lgan savollarga ustuvorlik berish ma’qulroq edi.

Repair Loop qayta urinish emas, balki validatsiya natijalari asosidagi tuzatish edi

Agar validatsiya muvaffaqiyatsiz tugaganidan so‘ng ayni so‘rov o‘zgartirilmasdan yana yuborilsa, natija boshqacha bo‘lishi mumkin, ammo model nimani tuzatish kerakligini bilmaydi. Shuning uchun biz ko‘pi bilan bitta Repair so‘roviga ruxsat berdik va ikkinchi so‘rovga quyidagi ma’lumotlarni kiritdik.

- 최초 사용자 요청
- 최초 모델 응답
- Schema 및 결정적 Validator 오류
- 누락되거나 원문과 일치하지 않은 항목

Qayta ishlash jarayoni quyidagicha.

Result first = generate(request);
Validation check = validate(first);
if (check.isValid()) return first;
 
Result repaired = repair(request, first, check.errors());
return validateOrSendToManualReview(repaired);

Cheksiz qayta urinishlarga ruxsat bermadik. Takroriy chaqiruvlardan so‘ng tasodifan tekshiruvdan o‘tgan natija sifat muammolarini yashirishi mumkin. Agar ikkinchi natija ham muvaffaqiyatsiz bo‘lsa, avtomatlashtirilgan qayta ishlashni to‘xtatdik va asl javob hamda xatoni qayd etdik.

Baholashlardan birida kiritilgan gaplarning aksariyati to‘g‘ri qayta ishlandi, ammo ayrim Evidence elementlari manbani biroz qayta yozgan edi. Umumiy natija juda yaxshi ko‘ringan bo‘lsa ham, tizim uni tasdiqlash mumkin bo‘lgan natija deb qabul qilmadi va Repair yo‘liga yubordi. Bu tajriba “asosan to‘g‘ri” natijani tizim muvaffaqiyati deb hisoblash kerakmi degan mezonni qayta ko‘rib chiqishimizga sabab bo‘ldi.

Joriy etilgandan keyin nima o‘zgardi

Validatsiya tuzilmasini qo‘llagandan keyingi o‘zgarishlarni quyidagicha umumlashtirish mumkin.

Oldin	Joriy etilgandan keyin
Biror narsa tushirib qoldirilgan-qoldirilmaganini aniqlash uchun manba va chiqishni qo‘lda taqqoslardik.	Qayta ishlanmagan kiritish gaplarini darhol aniqladik.
Model qaytargan dalildan o‘zgartirishsiz foydalanardik.	Manba matnida mavjud bo‘lmagan Evidence bloklandi.
Hujjatda mavjud bo‘lmagan qiymatlar ham tabiiy tarzda to‘ldirildi.	Qiymatni yakunlash o‘rniga, aniqlashtiruvchi savol berishga o‘tdim.
Tekshiruv muvaffaqiyatsiz tugagach, xuddi shu so‘rovni takrorladim.	Aniq xatoni bayon qildim va cheklangan tuzatish kiritdim.
Muvaffaqiyatsiz javobni bekor qildim.	Uni tekshiruv xatosi bilan birga regressiv baholash ma’lumotlari sifatida saqlab qoldim.

Bajarilish yozuvlarini tekshirilgan ma’lumotlardan ajratdim

Bir xil hujjat va ko‘rsatmalarni bir nechta modelga qo‘llaganimda, ularning barchasi JSON qaytardi, biroq xatoga uchragan nuqtalari turlicha bo‘ldi. Ayrim modellar qoidalarni tushirib qoldirdi, boshqalari manba matnida bo‘lmagan izohlarni qo‘shdi, yana boshqalari esa havolalar o‘rtasidagi munosabatlarda xatolarga yo‘l qo‘ydi. Shu sababli faqat yakuniy natijalarni saqlash orqali muammolarning sabablarini kuzatish qiyin edi.

Bajarilish yozuvlarida foydalanilgan model, Prompt versiyasi, kiritilgan hujjat, xom javob, ajratib olish natijalari, tekshiruv holati va muvaffaqiyatsizlik sabablari saqlab qolindi. Bu yozuvlar yakuniy biznes ma’lumotlari emas, balki nosozliklarni tuzatish va regressiv baholash uchun materiallar edi. Faqat tekshiruvdan o‘tgan va inson tomonidan ko‘rib chiqilgan natijalar foydalanish mumkin bo‘lgan ma’lumotlarga aylantirildi.

Asosiy jihatlar xulosasi

• LLMlardan yakuniy ma’lumotlar manbai sifatida emas, balki tuzilgan nomzodlarni yaratish roli bilan cheklangan holda foydalanish kerak.

• Structured Output ajratib olishdagi xatolarni kamaytiradi, biroq tushirib qoldirishlar yoki noto‘g‘ri talqinlarning oldini olmaydi.

• Tushirib qoldirishlarni aniqlash uchun natijalar sonini emas, har bir kiritilgan jumlaning qayta ishlanish holatini kuzatish kerak.

• Manba matnida Evidence mavjud yoki mavjud emasligi va uning tegishli maydonni qo‘llab-quvvatlashi alohida baholanishi kerak.

• Prompt, Schema yoki Validator o‘zgartirilgandan keyin regressiv baholashni amalga oshirish uchun muvaffaqiyatsiz javoblar va tekshiruv xatolari birgalikda saqlanishi kerak.

Xulosa

Bu ishni boshlaganimda, uni tabiiy tildagi hujjatlarni JSON formatiga o‘tkazish deb o‘ylagandim. Amalga oshirish jarayoni davomida haqiqiy muammo JSON yaratish emas, balki noaniq talqinlarga qanchalik yo‘l qo‘yish, nimani mexanik tarzda tekshirish va qachon yana odamga murojaat qilish.

Yakuniy tuzilma formatni JSON Schema yordamida cheklash, kiritilgan ma’lumotlarning qamrovini va Evidence’ni tekshirish, noma’lum ma’lumotlarni esa savollar ko‘rinishida qoldirish uchun ishlab chiqildi. Generativ sun’iy intellektni biznes operatsiyalariga qo‘llashda eng muhimi eng tabiiy javobni olish emas, balki noto‘g‘ri natijalarning keyingi bosqichga o‘tishining oldini olishdir.

Bu ish asosida qilgan xulosam shuki, LLMlarni ishonchli qiladigan narsa kuchliroq prompt emas, balki ularning chiqishini savolga tutadigan va tekshiradigan tizimdir.

Brown