1. Kirish
O'tgan ishda LLM avtomatik tarjima funksiyasini asinxron voqea oqimi orqali ajratishga oid tuzilmani muhokama qildik. Saqlash so'rovida LLM ni to'g'ridan-to'g'ri chaqmadan, tarjima talab etiladigan vaziyatni voqea sifatida e'lon qilib, alohida oqimda tarjima amalga oshiriladigan tarzda tuzilgan.
Mavjud tuzilma, shuningdek, entity to'g'ridan-to'g'ri ega bo'lgan ko'p tilli maydonlarni tarjima qilishga qaratilgan edi. Biroq, haqiqiy domen modeli shuni ko'rsatadiki, ko'p tilli satrlar har doim entityning to'g'ridan-to'g'ri maydonlarida mavjud emas. Entity ichidagi qiymat ob'ektida (Value Object) ko'p tilli maydonlar bo'lishi mumkin yoki qiymat ob'ekti ro'yxat shaklida mavjud bo'lishi juda ko'p.
Ushbu maqolada LLM avtomatik tarjima ob'ektlarini ichki ob'ektlarga va ro'yxat tuzilmalariga kengaytirish paytida yuzaga kelgan texnik muammolarni tartibga solamiz. Asosiy masala, faqat oson tarjima qilinadigan joylarni ko'paytirish emas, identifikatorsiz ro'yxat tuzilmalarini qanday xavfsiz boshqarish va umumiy funksiyalarning foydalanuvchi API sini qanday soddalashtirishdir.
2. Mavjud tuzilmadagi cheklovlar
Mavjud avtomatik tarjima so'rov usuli nisbatan oddiy edi. Xizmat tarjima ob'ekti bo'lgan entity va maydon nomini Helperga uzatadi, Helper esa bular asosida tarjima so'rov voqeasini e'lon qiladi. Masalan, requestTranslation(entity, "title") singari.
Ushbu usul title, description kabi entity to'g'ridan-to'g'ri ega bo'lgan maydonlarga yaxshi mos keladi. Tugallanish voqeasi yetib kelganda, entity nomi, entity ID, maydon nomiga asoslanib, maqsadli entityni qidirish va ushbu maydonga tarjima natijalarini aks ettirish mumkin bo'ladi.
Muammo tarjima ob'ekti detail.name yoki items[0].name kabi chuqur joyda bo'lganida yuzaga keladi. Faqatgina satr yo'lini bevosita foydalanuvchiga uzatish mumkin, ammo bu usul umumiy funksiyalarning foydalanish qulayligini pasaytirishi mumkin. Foydalanuvchi ichki field path qoidalarini bilishi kerak va ro'yxat tuzilmasida indeksni ko'rsatishi shart.
Xususan, ro'yxatning indeksi barqaror identifikator sifatida qaralishi qiyin. So'rov paytidagi items[0] tugallanish voqeasi aks etganda ham xuddi shu ob'ekt ekanligiga kafolat bo'lmasa, noto'g'ri ob'ektda tarjima natijalari aks etishi mumkin. Shunday qilib, mavjud fieldName ga nuqta notatsiyasi va indeks notatsiyasini shunchaki yoqlash usuli yaroqsiz qoldirildi.
[Rasm 1. Bevosita maydonni tarjima qilish va ichki ob'ekt/ro'yxat tarjima qilishni taqqoslash]
3. Ichki ob'ektlar va ro'yxat tuzilmasida yuzaga kelgan fikrlar
Ichki ob'ektlarni tarjima qilishni kengaytirish paytida birinchi navbatda qiymat ob'ektining identifikatsiya masalasi haqida o'yladim. Entity odatda o'ziga xos IDga ega bo'ladi, shuning uchun tugallanish voqeasi kelganda qaytadan qidirish mumkin. Biroq, entity ichidagi qiymat ob'ekti ko'pincha mustaqil identifikatorlarga ega emas.
Yagona qiymat ob'ekti nisbatan oddiy. Masalan, article.detail.name kabi bitta yo'l orqali ifodalanishi mumkin. Ammo qiymat ob'ekti ro'yxati haqida ko'proq ehtiyot bo'lish kerak. article.items[0].name, article.items[1].name kabi indekslar ichiga qatnashganda.
Ro'yxatning ma'lum bir indeksini tarjima qilish uchun API taqdim etish mumkin. Biroq, bu holda foydalanuvchi indeksni bevosita uzatishi kerak va ro'yxat tartibi o'zgarganda tarjima natijasi boshqa elementda aks etishi mumkin. Agar qiymat ob'ekti uchun alohida kalit bo'lmasa, indeks texnik jihatdan qulay joylashuv ma'lumoti, lekin barqaror identifikator bo'lishi qiyin.
Shuning uchun ushbu doirada faqat ma'lum indeksni tarjima qilish uchun API taqdim etmaslik tomonini tanladik. Ro'yxat maydoni kelganda, ushbu ro'yxatni to'liq tarjima ob'ekti deb hisoblaymiz va ichkarida har bir elementni aylanib chiqib, tarjima ob'ektlarini hisoblashga majbur bo'ldik.
Yana bir muammo – bir nechta til maydonlarini boshqarish edi. Haqiqiy qiymat ob'ekti faqat bir name emas, balki name, description, summary kabi bir nechta til maydonlariga ega bo'lishi mumkin. Shunday qilib, yagona ichma-ich ob'ekt va ro'yxat tuzilmasi ichida bitta maydon emas, balki bir nechta maydonni so'rash imkoniyatini belgiladik.
-
Yagona ichma-ich ob'ektdagi bitta til maydoni
-
Yagona ichma-ich ob'ektdagi bir nechta til maydonlari
-
Ro'yxat tuzilmasidagi bitta til maydoni
-
Ro'yxat tuzilmasidagi bir nechta til maydonlari
4. Foydalanuvchi API'sini soddalashtirish
Bu funksiyada muhim deb hisoblangan narsa foydalanuvchi API'sining soddaligi edi. Umumiy funksiyalar bir nechta xizmatlarda ishlatilgani sababli, foydalanayotgan dasturchi ichki tadbir tuzilishini yoki Reflection yo'l qoidalarini batafsil bilishi kerak bo'lsa, yaxshi API deb hisoblanmaydi.
Shunday qilib, ichma-ich ob'ekt tarjimasi uchun alohida so'rov usulini kiritdik. Foydalanuvchi ob'ekt va ichki maydon nomi, shuningdek, ichidagi til maydon nomini taqdim etadi. Masalan, requestNestedTranslation(entity, "items", "name") kabi chaqirish kerak.
Bu API'ning asosi foydalanuvchi items[0].name kabi ichki yo'lni bevosita yaratmasligidir. Foydalanuvchi ob'ektning maydon nomi bo'lgan items va ichki ob'ektning til maydon nomi bo'lgan name'ni taqdim etadi.
Yagona ob'ekt yoki ro'yxat ekanligi Helper tomonidan aniqlanadi. Helper taqdim etilgan ob'ektga asoslanib, maqsad maydonni o'qiydi va agar bu maydon yagona ob'ekt bo'lsa, ichki til maydonini bitta tarjima maqsadi sifatida hisoblaydi. Agar ro'yxat bo'lsa, ro'yxatdagi har bir elementning ichki til maydonlarini tarjima maqsadi sifatida hisoblaydi.
Bunday bo'lganda, ichki jarayonlar murakkab bo'lib qoladi, lekin foydalanish tomonidagi kod oddiy bo'lib qoladi. Umumiy funksiyaning murakkabligi ichki darajada qaytariladi va foydalanuvchidan faqat zarur minimum kirishni talab qiladigan tuzilma hosil qilinadi.
5. Vaqtinchalik shartnoma va natijalarni aks ettirish usulini kengaytirish
Foydalanuvchi API'sini soddalashtirish uchun ichki vaqtinchalik shartnomani ham kengaytirish zarur edi. Mavjud tarjima so'rov tadbirlari ob'ektda to'g'ridan-to'g'ri maydonlarga asoslangan tarzda loyihalashtirilgan edi. So'rov tadbiri qanday xizmatning qanday ob'ekti, qaysi maydonni tarjima qilishini ifodalaydi.
Biroq, ichma-ich ob'ektlar va ro'yxat tuzilmalarida bitta so'rov bir nechta tarjima maqsadlariga kengaytirilishi mumkin. Masalan, items ro'yxatining name va description'ini tarjima qilganda, ichki teste items[0].name, items[0].description, items[1].name, items[1].description kabi bir nechta maqsadlar yaratiladi.
Shunday qilib, ichma-ich tarjima so'rovini faqat bir maydon nomi bilan ifodalash qiyin. So'rov ichida bir nechta tarjima maqsadlarini saqlash imkoniyati bo'lishi kerak va har bir maqsad qaysi o'rinda qaysi til maydoni ekanligini bilishimiz kerak. Buning uchun ichma-ich tarjima so'rov tadbirlari va maqsad ob'ektlarini alohida yaratilgan.
Tugatish hodisalarini qanday boshqarish haqida o'ylashimiz kerak edi. Chuqurlashtirilgan tarjima natijalarini xizmat to'g'ridan-to'g'ri qabul qilib, aks ettirishini ta'minlash mumkin, lekin mavjud avtomatik tarjima tuzilmasida muvaffaqiyat hodisalarini xizmat o'zi to'g'ridan-to'g'ri boshqarmasdan, umumiy kutubxona avtomatik ravishda aks ettiradi. Chuqurlashtirilgan ob'ekt tarjimasi alohida hodisa boshqaruvchisini talab qilsa, foydalanish usuli bir xil bo'lmaydi.
Shuning uchun chuqurlashtirilgan ob'ekt tarjimasi ham mavjud muvaffaqiyatni boshqarish bilan bir xil tarzda avtomatik aks ettiriladigan qilib tartibga solindi. Tarjima xizmati tugatish hodisasini tarqatadi va umumiy kutubxona ushbu hodisani qabul qilgandan so'ng, aks ettirish orqali asl entitiyadagi maqsad joyiga tarjima natijasini aks ettiradi.
Boshqasidan muvaffaqiyatsizlikni xizmat to'g'ridan-to'g'ri boshqarish formatida saqlab qolindi. Muvaffaqiyatsizlikdan keyingi siyosat har bir xizmatda farq qilishi mumkin. Ba'zi xizmatlar oddiygina jurnal qoldirishi mumkin, ba'zilari esa boshqaruvchi oynasida muvaffaqiyatsizlik tarixini ko'rsatishi yoki qayta so'rov funksiyasini taklif qilishi mumkin. Shuning uchun muvaffaqiyatsizlik hodisasi umumiy tarzda taqdim etilsa ham, keyingi boshqarish har bir xizmatning domen siyosatiga topshirilishini maqbul deb hisobladik.
6. Xulosa
Ushbu ish LLM avtomatik tarjima maqsadini entitining to'g'ridan-to'g'ri maydonlaridan chuqurlashtirilgan ob'ektlar va ro'yxat tuzilmalarigacha kengaytirish tajribasi edi. Dastlab, ichki ob'ektning ko'p tilli maydonlarini ham tarjima qilishi uchun tayyorlash ishlari kabi ko'rinardi, lekin aslida foydalanuvchi API, ro'yxat indeksining barqarorligi, hodisa shartnomasi, natijani aks ettirish usuli, muvaffaqiyat va muvaffaqiyatsizlik javobgarligi chegarasi kabi narsalarni ham o'ylashimiz kerak edi.
Xususan, ro'yxat tuzilmasida ma'lum indeksni API orqali ochish muhim qaror nuqtasi edi. Indeksni implementatsiya qilish qulay, ammo qiymat ob'ekti ro'yxatida barqaror identifikator sifatida ko'rish qiyin. Shunisi uchun ma'lum indeks tarjima funksiyasini chiqarib tashlab, ro'yxatning hammasiga tarjima qilish yo'nalishini tanladik.
Bundan tashqari, foydalanuvchi API ni sodda tutish ham muhim maqsad edi. Foydalanuvchilar ichki yo'lni to'g'ridan-to'g'ri yaratmasdan, chuqurlashtirilgan maydon nomlari va ichki ko'p tilli maydon nomlarini birga yetkazish imkoniyatiga ega bo'lishdi. Yagona ob'ekt yoki ro'yxat mavjudligini, ichki tarafda qanday tarjima maqsadi yaratilayotgani Helper tomonidan belgilanishi kerak.
Ushbu ishdan yana bir narsani his qildim, LLM funksiyasining asosi faqat model chaqiruvining o'zida emas. Amaliy xizmatda qaysi ma'lumotlarni tarjima maqsadi sifatida ko'rish, natijani qayerga va qanday aks ettirish, muvaffaqiyatsizlikni kim boshqarishi, foydalanuvchilar funksiyalarni qanchalik oddiy ishlata olishlari kabi narsalarni ham birga loyihalash kerak.
Umumiy funktsiya ichidan ko'p hollarda ishlov berishi kerak, lekin foydalanuvchiga oddiy ko'rinishi kerak. Ushbu ish LLM avtomatik tarjima funksiyasini amaliy xizmat domen modeliga yaqinroq kengaytirishda, ushbu tamoyilni yana bir bor tasdiqlash jarayoni bo'ldi.
7. Kelajakda ko'riladigan joylar
Ushbu kengayish bilan tarjima so'rovi va natija aks ettirish doirasi kengaydi, ammo ish yuritish nuqtai nazaridan hali ham yanada o'ylash kerak bo'lgan joylar qolmoqda. Masalan, tarjima holatini qayerda boshqarish? Oddiygina qiymat bo'sh holatda to'ldirilganda, birinchi tarjima tugallanganligini taqqoslash oson. Lekin allaqachon tarjima qiymati mavjud bo'lsa, qayta tarjima bo'lsa, maydon qiymati yordamida jarayon va tugallanganligi farq qilish qiyin bo'lishi mumkin.
Bunday holat ma'lumotlar, ko'p tilli satr qadri emas, balki tarjima so'rovi tarixiga yoki ish jarayoni bilan bog'liqdir. Shuning uchun satr ob'ekti ichiga holatni to'g'ridan-to'g'ri qo'shishdan ko'ra, alohida tarjima tarixi yoki holat modeli bilan boshqarish yanada aniqroq bo'lishi mumkin. Muvaffaqiyatsiz qayta so'rov funksiyasi ham xuddi shunday kontekstdan oddiy LLM qayta chaqirish emas, balki hozirgi ma'lumot holati va xizmat siyosatini birga ko'rib chiqadigan ish yuritish funksiyasi sifatida ko'rib chiqilishi kerak.
[Manba]
Martin Fowler, Qiymat Ob'ekti
https://martinfowler.com/bliki/ValueObject.html
Microsoft Learn, asinxron soʻrov-javob shabloni
https://learn.microsoft.com/ko-kr/azure/architecture/patterns/asynchronous-request-reply
IBM, voqea asosidagi arxitektura nima?
https://www.ibm.com/kr-ko/think/topics/event-driven-architecture
jyyou