LLM avtomatik tarjima voqeaga asoslangan arxitektura

LLM avtomatik tarjimasiasinxron hodisa oqimini boshqarish

1. Kirish

So'nggiKo'p tilli matnlarni avtomatik tarjima qilish funksiyasini loyihalashtirayotganda, faqat LLMni chaqirib tarjima natijalarini olishdan ko'ra muhimroq muammo borligini his qildim. Bu LLM chaqiruvini mavjud xizmat so'rovi oqimida qanday hal qilish kerakligi edi. LLM asosidagi qayta ishlash odatiy ichki mantiqdan farq qiladi, chunki javob vaqti barqaror emas va tashqi model holati yoki tarmoq sharoitidan ta'sirlanadi. Shuning uchun saqlash API ichida LLM chaqiruvini birgalikda ishlov berish, foydalanuvchi so'rovining javob vaqtini oldindan bilishni qiyinlashtiradi.

Dastlab,Saqlash va tarjima jarayonini bir oqimda birlashtirish usuli haqida o'yladim. Faqat amalga oshirishga kelsak, saqlash so'rovi qabul qilinganidan so'ng asl matnni saqlash va darhol LLMni chaqirib, tarjima natijasini olishdan iborat tuzilma oddiy ko'rinadi. Ammo bu usul saqlash funksiyasining mas'uliyati va tarjima funksiyasining mas'uliyatini kuchli bog'laydi. Saqlash tez tugashi mumkin bo'lgan ish, lekin tarjima kechiksa, saqlash javobi ham kechikadi. Shuningdek, saqlash muvaffaqiyatli bo'lsa, lekin tarjima muvaffaqiyatsiz bo'lgan taqdirda buni bir so'rov ichida qanday ifodalashni aniqlash qiyin.keladi.

Shuning uchunUshbu ishda LLM chaqiruvini foydalanuvchi so'rov oqimidan ajratish va voqea asosidagi asinxron qayta ishlashni tanlashga qaror qildik. Asosiy narsa, tarjimani oddiy qo'shimcha funktsiya sifatida emas, balki kechikish ehtimoli bo'lgan tashqi operatsiyani xizmat ichki holatini qanday o'zgartirish oqimidan ajratishdir.

2. Nima uchun LLM chaqiruvini so'rov oqimiga ajratildi

LLM chaqiruvlari odatiy biznes mantiqidan farq qiladi. Ichki ma'lumotni tekshirish yoki DB saqlash nisbatan oldindan aytib bo'ladigan vaqt ichida tugaydi, ammo LLM chaqiruvi model yukiga, tarmoq holatiga, so'rov uzunligiga va maqsadli til soniga qarab javob berish vaqti o'zgaradi. Bunday jarayonlarni sinxron so'rov ichiga qo'shish, foydalanuvchilarni saqlash bilan bevosita bog'liq bo'lmagan ishlar tufayli javob kutishga majbur qiladi.

Shuningdek Xatolarni tarqatish nuqtai nazaridan ham muammo mavjud. Saqlash API to'g'ridan-to'g'ri LLM chaqiruviga tayanadigan bo'lsa, LLM xatosi saqlash funksiyasining xatosi kabi ko'rinishi mumkin. Foydalanuvchi ma'lumotlarni saqlamoqchi bo'lsa, tashqi model chaqiruvi muvaffaqiyatsizligi sababli saqlash so'rovi butunlay muvaffaqiyatsiz bo'lganidek tajriba qilishi mumkin. Aslida saqlash va tarjima bir-biridan farqli javobgarlikka ega vazifalar, ammo sinxron tuzilishda bu ikki javobgarlikning chegarasi bulg'angan bo'ladi.

АсинхронТузилиш бу муаммони енгиллаштиради. Сақлаш таклифлари фақат сақлаш вазифасини бажаради ва тез жавоб қайтаради. Кейинча таржимага эҳтиёж бор ҳолатларни воқеа сифатида ифодалаймиз, ва таржиманинг бажарилиши алоҳида оқимда амалга оширилади. Бу усул дарҳол мувофиқликка эмас, балки охирги мувофиқликка яқинлашади. Сақлашдан сўнг барча таржима қийматлари дарҳол тайёр бўлмаслиги мумкин, лекин фойдаланувчи таклифларига жавоб бериш ва тизимнинг хато ажратилиши яхшироқ бўлади.

[1-rasm. Xizmat javob vaqti taqqoslash: sinxron va asinxron ishlov berish]

Ushbu tuzilmani tanlayotganda muhim hisoblagan narsa shunchaki “tez javob beradi” emasdi. Eng muhimi, uzoq vaqt olishi mumkin bo'lgan ishlarni aniq ajratish va ularning muvaffaqiyati va muvaffaqiyatsizligini alohida hodisalar oqimida ko'rib chiqish imkoniyatidir.

3. Tadbir shartnomasini kichik saqlangАсинхронСтруктурада биринчи навбатда аниқлаш керак бўлган нарса - бу тадбир хужжати эди. Тадбирлар фақат маълумотларни узатувчи объект эмас, балки ҳар хил ишлаш юзасидан келишувдир. Сўровни эълон қилувчи томон ва сўровни ишловчи томон бир хил чақириш стекда бўлмагани учун, тадбирга қандай маълумотларни қўшишга қараб умумий структуранинг боғланиш даражаси ўзгаради.

Boshida Tadbirga imkon qadar ko'p ma'lumotlarni o'z ichiga olishi xavfsiz ko'rinardi. Ammo tadbir payloadi kattalashgani sayin, so'rov va qayta ishlash bosqichlarining majburiyatlari aralashdi. So'rov tadbiri tarjima qilish uchun minimal ma'lumotlar bilan cheklanishi kerak va tugallash tadbiri natijalarni aks ettirish uchun ma'lumotlarga e'tibor qaratishi lozim edi. Shuning uchun so'rov tadbiri va tugallangan tadbirning rollarini ajratdik.

So'rovVoqealar qanday xizmatlarning qanday ob'ektlari, qaysi maydonlari uchun tarjima zarurligini, asosiy til va ko'p tilli matn ma'lumotlarini, majburiy qayta tarjima zarurligini o'z ichiga oladi. Aksincha, tamomlangan voqealar tarjima natijalarini aks ettirish uchun zarur bo'lgan identifikatsiya ma'lumotlari va tarjima qilingan LangStringsni o'z ichiga oladi. Ushbu ajratish bilan so'rov voqeasi “nima tarjima qilinadi”ga e'tibor qaratadi, tamomlangan voqea esa “qanday natijani aks ettiradi”ga e'tibor qaratadi.

Tadbir Shartnoma kichik bo'lsa, o'zgarishlarga ham qulayroq bo'ladi. Tarjima ichki amalga oshirishMockdan haqiqiy LLM ga o'zgarganda ham so'rov voqeasi ma'nosi saqlanib qolishi mumkin. Tarjima natijalarini yaratish usuli o'zgarsa ham, tugallangan voqea tomonidan ifodalanadigan natija shartnomasi saqlanib qolsa, natijalarni aks ettiruvchi tarafning o'zgarish doirasini kamaytirish mumkin.

4. Barcha ma'lumotlar emas, balki patch bilan shug'ullanish

TarjimaNatijani qanday tasvirlash ham muhim qaror edi. Bir usul - tarjima tugagach, butun ko'p tilliBu matnni qayta qaytarishdir. Biroq bu usul asl ma'lumotlar va tarjima natijalari o'rtasidagi chegarani noaniq qilishi mumkin. Ayniqsa, avval odam tomonidan kiritilgan qiymatlar mavjud bo'lsa, butun ma'lumotni qayta aks ettirish, kutilmagan o'zgartirishlarga olib kelishi mumkin.

Shuning uchunTarjima natijalari butun ma'lumot emas, balki to'ldirilishi kerak bo'lgan qiymatlar to'plami, ya'ni patch(patch)Yaqinroq ko‘rib chiqish yo‘nalishi to‘g‘riroq deb qaror qildim. Bo‘sh til qiymatlari faqat tarjima maqsadi sifatida olinadi, allaqachon qiymatlari bo‘lgan tillar odatda chetga chiqariladi. Mavjud tarjimani qayta yaratish zarur bo‘lsa, alohida forceUpdate opsiyasi orqali ochiq ravishda qayta tarjima qilish talab qilindi.

BuSiyosat oddiy biznes shartlari emas, balki ma'lumotlarni o'zgartirishning xavfsizlik mexanizmi kabi edi. Avtomatik tarjima qulay, lekin inson tomonidan to'ldirilgan iboralarni mashina tarjima natijalari bilan o'zgartirish sifatni pasaytirishi mumkin. Shuning uchun, avtomatik tarjima natijalarini “har doim to'liq o'zgaradigan ma'lumot” sifatida emas, balki “hozirgi yetishmayotgan qiymatlarni to'ldiradigan ma'lumot” sifatida talqin qilish xavfsiz edi.

BuQarashdan koʻra, patch usuli voqealar asosida ishlov berishga juda mos keladi. Soʻrov voqeasi asl holatga asoslanib tarjima maqsadini hisoblaydi va tugatish voqeasi esa faqat amalga oshirilishi mumkin boʻlgan natijalarni yetkazadi. Natijalarni aks ettiruvchi tomoni esa butun holatni qayta talqin qilish oʻrniga, yetkazilgan tarjima natijalarini kerakli joylarda qoʻllasa boʻladi.

5. LLM javoblari tasdiqlanuvchi ma'lumot emas

haqiqiyLLMni ulashganda eng katta his qildim shuki, LLM javoblarini aynan ishonish kerak emas. LLM tabiiy tilni ishlab chiqarishda kuchli, ammo xizmat ma'lumotlari talab qiladigan formatni har doim aniq saqlamaydi. Tarjima o'zi tabiiy ko'rinishi mumkin, lekin ma'lumot tuzilmasi nuqtai nazaridan buzilgan javob bo'lishi mumkin.

ko'rinadi“Salom, {{name}} jan.” jumlasi bo'lsa, {{name}} tarjima qilinmaydi. Foydalanuvchi nomi joyiga kelayotgani uchun, tarjima natijasida ham shunday qolishi kerak. URL, elektron pochta manzillari, HTML teglar, format tokenlari ham shunday. Bunday qiymatlar yo'qolsa yoki o'zgarsa, bu tarjima sifat muammosi emas, balki xizmat ma'lumotlari xatosi bo'ladi.

Qatorni uzish hamBu muhim tasdiqlash obyekti edi. Ekranda ko'rsatiladigan label matni oddiy bir qator jumlalar bilan birga ko'plab qator ko'rsatmalarni o'z ichiga olishi mumkin. Asl matnda qator bo'yicha ajratilgan ma'no birliklari bor, agar tarjimada qator bo'yilishlari yo'q bo'lsa, ekran tuzilishi yoki konteksti o'zgarishi mumkin. Shuning uchun asl matn va tarjima matni orasidagi qator bo'yilishlari sonini taqqosladim, agar farq bo'lsa, tuzilish buzilgan javob sifatida ko'rib chiqildi.

tilga qarabMatn tizimini alohida ko'rib chiqish kerak edi. Masalan, o'zbek tilida lotin va kiril alifbosi ikkalasini ham hisobga olish kerak. Faqat 'Uzbek' deb tarjima qilish kerak bo'lsa, kerakli alifbo tizimidan boshqa natija chiqishi mumkin. Shuning uchun uz-Latn, uz-Cyrl kabi alifbo tizimini o'z ichiga olgan til kodlari belgilanadi.promptLabel ga aylantirib, javobda ham ushbu belgi tizimi to'g'ri ekanligini tasdiqladim.

BuMen LLM funktsiyalarini o'rganish jarayonida muhim bo'lgan narsa, faqat yaxshi takliflar emas, balki xizmat kodi ham ushbu natijalar haqiqiy ma'lumotlar qoidalariga muvofiq kelishini tasdiqlashi kerakligini his qildim. LLM javoblari to'g'ridan-to'g'ri ishonchli ma'lumotlar emas, balki tekshiruvdan o'tishi kerak bo'lgan taklif qilingan ma'lumotlarga yaqinroqdir.

6. muvaffaqiyatsizlikni tasniflash va qayta urinish mezonlarini ajratish

AsinxronTuzaqni qanday boshqarish ham muhimdir. Agar u sinkron API bo'lsa, muvaffaqiyatsizlikni HTTP javobi sifatida qaytarish mumkin, lekin voqea asosida ishlov berish jarayonida so'rov qilingan vaqt va ishlov berilgan vaqt ajratiladi. Shuning uchun, muvaffaqiyatsizlik voqea oqimida ifodalanishi kerak edi.

HammasiMuvaffaqiyatsizlikni bir xil tarzda hal qilish operatsiyani qiyinlashtiradi. Tarmoq muammosi yoki LLM vaqtni tugatish Ushbu kabi vaqtinchalik tashqi uzilishlar qayta urinish orqali muvaffaqiyatga erishishi mumkin. Biroq, agar asosiy til yo'q bo'lsa yoki asl matn bo'sh bo'lsa yoki LLM javobi tuzilish nazoratidan o'tmasa, oddiy qayta urinishlar bilan bu muammoni hal qilish qiyin. Shuning uchun muvaffaqiyatsizliklar Qayta urinish mumkinqaytadan urinib ko'rish mumkin)Xatolar vaQayta urinib bo'lmaydigan xato(qayta urinmaydigan)Xato bo'lib ikkiga bo'ldik.

LLM so'rovining muvaffaqiyatsizligi yoki timeout qayta urinish xatosi sifatida ko'rib chiqildi va xabarlarni qayta ishlash tizimining qayta urinish oqimiga topshirildi. Aksincha, zarur qiymatlarning yo'qolishi, asl matnning yo'qligi, javob shakli xatosi kabi ma'lumotlar yoki shartnoma o'zining noto'g'ri bo'lgan hollari muvaffaqiyatsizlik voqeasi sifatida chiqarildi. Buni bo'lish, vaqtinchalik tashqi muammolar va ma'lumotlar shartnomasi muammolarini boshqarishning boshqa usulini taqdim etadi.

MuvaffaqiyatsizlikVaqtni qoldirsangiz, keyingi jarayon ham aniq bo'ladi. Muvaffaqiyatsizlikka uchragan entitiy va maydon, xatolik kodi, qayta urinish imkoniyati kabi ma'lumotlarni voqeaga qoldirish mumkin va keyinchalik operatsion vositalar yoki alohida tuzatish jarayonlarida buni ishlatish mumkin. Asinxron tuzilmada muvaffaqiyatsizlikni oddiy log qoldirishdan ko'ra, tizim tushunadigan hodisa sifatida ifodalashning ko'proq barqaror ekanini his qildim.

7. Mock tasdiqlashdan Live LLM tasdiqlashgacha

Boshlang'ich bosqichda haqiqiy LLMni bevosita ulash o'rniga Mock asosida voqealar oqimini avval tasdiqladik. Amaldagi modelni bevosita ulaganda voqea shartlari muammosi, javobni tahlil qilish muammosi yoki modelni chaqirish muammosi ekanligini bir paytda ajratish qiyin. Shuning uchun avval MMen mock orqali so'rov hodisalari oqimi uzatilayotganini, tugatish hodisasi tarqatilayotganini va tarjima maqsadlari hisoblashning niyatga muvofiq ishlayotganini tasdiqladik.

Keyin Men haqiqiy LLMni ulab, tarjima sifatini va javobni tekshirish mexanizmini sinab ko'rdim. Ushbu paytda, oddiygina tarjima natijalari bo'sh emasligini ko'rmaganman. Playseholder saqlanadimi, qatordan chiqarish saqlanadimi, yozuv tizimi to'g'rimi, baseLangCode o'chirilganda defaultLangCode asosiy til sifatida ishlatiladimi va forceUpdate eski qiymatning qayta tarjimaga ta'sir qiladimi, bularni ham birga tekshirdim.

BuUshbu sinov jarayoni orqali “LLM javob berdi” va “xizmat ma'lumotlarini xavfsiz qayd etish mumkin” boshqacha muammolar ekanligini yana bir bor tasdiqladik. LLM integratsiya sinovi faqat model chaqiruvi muvaffaqiyatini ko'rish uchun emas, balki tizim talab qilgan ma'lumot shartnomasini natijalar qondirishi kerakligini ham tekshirish uchun bo'lishi kerak edi.

8. Yakun

Bu safarLLM funksiyalarini xizmatga qo'shishda muhim bo'lgan narsa faqat modelni chaqiradigan kod emasligini angladim. Uzun kechikish vaqtiga ega bo'lgan vazifalarni so'rov oqimidan ajratish, voqea shartnomasini kichik saqlash, LLM javobini tekshiriladigan ma'lumotga aylantirish va muvaffaqiyatsizliklarni qayta urinish mumkin va mumkin emas deb ajratish jarayoni birga zarur edi.

NihoyatLLM avtomatik tarjima funksiyasining asosiy maqsadi “LLMni tarjima qilishga majbur qilish” emas, balki LLM natijalarini xizmat ma'lumotlari oqimida xavfsiz ishlashini ta'minlaydigan tuzilmani yaratish edi. Ushbu dizayn LLM chaqiruvlarini voqea asosidagi asinxron oqimga ajratish va muqarrar bo'lmagan javoblarni tasdiqlash, muvaffaqiyatsiz ishlash va kuzatuvchanlik ichida ko'rish bo'yicha urinish bo'ldi.

jyyou

[manba]

Microsoft Learn, asinxron so‘rov-javob naqshi

https://learn.microsoft.com/ko-kr/azure/architecture/patterns/asynchronous-request-reply

IBM, Voqeaga asoslangan arxitektura nima?

https://www.ibm.com/kr-ko/think/topics/event-driven-architecture

KakaoPay texnologiya blogi, Voqealar asosida mos joylarda ishlatish

https://tech.kakaopay.com/post/event-driven-architecture/