1. Ta'rif
RAG (Qayta olishga asoslangan yaratuvchi) modeli asosidagi Lakey AI tizimini ishlab chiqishda men birinchi navbatda “LLMning javoblariga qancha ishonish mumkin?” degan savolga o'yladim.
Dastlabki rivojlantirish bosqichida faqat hujjatlarni qidirish va LLMning javoblar yaratishini ta'minlash uchun sozlangan edi.
Lekin haqiqiy sinovlarni o‘tkazayotganda, bir qator muammolar paydo bo‘la boshladi.
Eng yaxshi muammo Hallucination hodisasi edi. LLM haqiqiy hujjatlarda mavjud bo'lmagan ma'lumotlarni tabiiy ravishda ishlab chiqarishi yoki ba'zi mazmunlarni ortiqcha ifoda etishi mumkin edi.
Ayniqsa, haqiqiy ish muhiti sharoitida noto'g'ri javoblar oddiy foydalanuvchi tajribasi muammosi bilan tugamaydi.
qaror qabul qilish jarayoniga ta'sir ko'rsatishi mumkin va noto'g'ri ish yuritishga olib kelishi mumkin edi.
masalan, ichki siyosat hujjatlaridan kelib chiqib javoblar ishlab chiqilganda, mavjud bo'lmagan siyosat tafsilotlarini javob berish yoki o'tgan siyosat ma'lumotlarini eng yangi ma'lumotlar kabi bayon etish muammosi yuzaga kelishi mumkin edi.
Shu sababdan loyihada oddiygina “javoblarni yaratish” jarayonidan tashqari yaratilgan javoblarni alohida tekshiradigan Verifier qatlamini qo'shishga qaror qilingan.
Ya'ni, LLM tomonidan yaratilgan natijalarni yana bir bor tekshirib, ishonchliligi past yoki noto'g'ri javoblarni filtrlash imkoniyatini beradigan tuzilma ishlab chiqilgan.
Loyihada AI Agent hamda Workflow avtomatlashtirish vositasi bo'lgan n8n dan foydalanib, ushbu tuzilmani amalga oshirdik.
Bu maqolada faqat “qanday amalga oshirildi”dan ko'ra, n8n ni nima uchun tanlaganimiz va haqiqiy ish sharoitida qanday afzalliklar va kamchiliklar bo'lganini markazida to'plamoqchiman.
2. Butun arxitektura tarkibi
Verifier tizimi asosan quyidagi oqimlar bo'yicha tashkil etilgan.
- Lakey AI tizimi
- Kafka asosidagi voqea yetkazib berish
- n8n ishchi jarayon
- tasdiqlovchi Sub ish jarayoni
- Xato Ish Jarayoni
- Natija qaytarish tuzilmasi
Agar Lakey tizimida javobni tasdiqlash kerak bo'lsa, Kafka orqali tasdiqlash so'rovi voqeasi chiqariladi.
Ushbu voqeada quyidagi ma'lumotlar mavjud.
- Foydalanuvchi savoli
- Qidirilgan kontekst hujjati
- LLM yaratish javobi
- so'rov identifikatori
- Tekshirish metadata
n8n da Kafka Consumer Workflow ushbu voqeani qabul qiladi va haqiqiy tasdiqlash mantiqini bajaruvchi Sub Workflow ni chaqirish uchun tuzilgan.
Tekshirish mantiqi mustaqil Sub Workflow shaklida ajratilgan.
Ushbu tuzilmani tanlash sababi, tekshirish standartlari doimiy ravishda o'zgarishi ehtimoli yuqori bo'lganidir.
Masalan, quyidagi tasdiqlash mantiqi mavjud bo'lishi mumkin.
- Javobning kontekstga asoslanganligini tasdiqlash
- Muayyan kalit so'zlarni o'z ichiga olishini tekshirish
- Ta'qiqlangan iboralarni aniqlash
- Siyosatga zidligini aniqlash
- Ishonchlilik ballini hisoblash
- JSON formatni tekshirish
Ushbu tekshirish jarayonlarini har birini alohida tugun va Sub Workflowga ajratish orqali qarovga olish imkoniyatini oshirdik.
Shuningdek, Error Workflowni alohida tuzdik.
LLM chaqiruvining muvaffaqiyatsizligi, Kafka ulanishidagi xato, Timeout, JSON parsing xatolari kabi turli xil istisno holatlari yuzaga kelishi mumkin edi.
n8n ish vosita sifatida xato ishlashni tashkil etish uchun sharbat tarzida qurilishi mumkin, shuning uchun nosozlik yuzaga kelganda alohida xato ish jarayoniga o'tishni va loglar qoldirishni va xabarnoma yuborishni tashkil etdik.
Oxir oqibat, tekshirish tugallangandan so'ng, natijani yana Kafka voqeasi shaklida e'lon qilamiz va Lakey tizimi buni iste'mol qilish uchun tashkil etilgan.
Ya'ni, umumiy tuzilma Event-Driven Architecture asosida loyihalashtirilgan.
3. Nima uchun n8n ni tanladingiz
Loyihalar boshlanishida Python asosida to'g'ridan-to'g'ri AI ish jarayonini amalga oshirish usuli ham ko'rib chiqildi.
Masalan, FastAPI asosida API serverini yaratish va ichki LangChain yoki to'g'ridan-to'g'ri yozilgan Python mantiqi orqali tasdiqlash jarayonini boshqarish usuli edi.
Ammo, lekin haqiqatan promp va tasdiqlash mezonlari juda tez-tez o'zgardi.
Xususan, boshqarish jarayonida quyidagi so'rovlar takroran yuzaga keldi.
- Taklifni tuzatish
- Tekshirish bosqichini qo'shish
- maxsus shartlar istisnosi
- jurnalni tekshirish
- Javob formatini o'zgartirish
- Workflow tartibini o'zgartirish
Agar buni hammasini kod asosida boshqarganimizda har safar quyidagi jarayonni takrorlashimiz kerak edi.
- Kodni o'zgartirish
- qurish
- tarqatish
- Serverni qayta ishga tushirish
- Sinov
Boshqa tomondan, n8n Workflow asosidagi tuzilma bo'ladi, shuning uchun UI-da tugmachalarni o'zgartirib, darhol amalga oshirish mumkin edi.
Bu nuqta juda katta afzallik sifatida tuyuldi.
Xususan, AI Agent asosidagi tizimlar hali talablar tez-tez o'zgaradigan hollarda ko'p uchraydi. Shuning uchun tezkor takroriy rivojlantirish va tajriba o'tkazish juda muhimdir.
n8n bunday talablar uchun juda mos keladigan vosita edi. Shuningdek, n8n turli tashqi tizimlar bilan bog'lanishni juda osonlashtiradi.
Kafka, HTTP API, Slack, Redis, Database, Webhook va boshqa ko'plab tugunlar asosiy taqdimotda mavjud bo'lganligi sababli, alohida Connector kodini yozish zarurati deyarli yo'q edi.
Haqiqiy loyihalarda Kafka hodisalarini qabul qilish va tarqatish juda tez tashkil etilishi mumkin edi.
Workflow-ni vizual tarzda ifoda etish mumkinligi ham foydalidir.
Murakkab AI ishlov berish oqimini tugunlar bo'yicha ifoda etish mumkinligi sababli, operatorlar yoki boshqa dasturchilar umummiy oqimni oson tushunishlari mumkin edi.
Xususan, AI ish jarayoni oddiy koddan ko'ra jarayonning o'zini tushunish muhim bo'lgani uchun vizualizatsiya ta'siri juda katta bo'ldi.
Natijada loyiha uchun 'tezkor takroriy rivojlanish' va 'ish faoliyati qulayligi' tufayli n8n tanlandi.
4. Haqiqatda ishlashda his qilingan afzalliklar
Haqiqiy ish jarayonida eng kuchli his qilingan afzalliklar xatoliklarni tuzatish va loglarni kuzatish funksiyasi edi.
Mavjud kodga asoslangan Workflowda ma'lum bir bosqichda qaysi ma'lumotlarning yaratilganini bilish qiyin bo'lgan hollarda ko'p bo'ldi.
Boshqa tomondan, n8nda har bir tugun uchun kirish va chiqish ma'lumotlarini to'liq ko'rish imkoniyati mavjud edi.
Ya'ni, Workflow bajarish jarayonining barcha bosqichlarini bosqichma-bosqich kuzatib borish imkoniyatiga ega edik.
Masalan, quyidagi holatda juda foydali bo'ldi.
- Maxsus prompt natijalarini tekshirish
- LLM javob ma'lumotlarini tasdiqlash
- JSON Parsing muvaffaqiyatsizligi sabablari tahlili
- Kafka xabarlarini tekshirish
- Shart shartlari natijasini tekshirish
- Maxsus tugunning Timeout tahlili
Xususan, AI tizimlarida natijalar har doim teng bo'lmaganligi sababli, o'rta ma'lumotlarni tekshirish imkoniyati juda muhim edi. Haqiqiy ishlash muhitida ham muammolar yuzaga kelganda ko'pincha n8n ishga tushirish loglari orqali sababini tezda aniqlash mumkin edi.
Shuningdek, kodni minimalizatsiya qilish tuzilmasi ham afzallik edi.
Agar eski usul bo'lsa, Kafka iste'molchi, HTTP mijoz, qayta urinish logikasi, xatolarni boshqarish kabi hamma narsalarni kodda yozish kerak edi.
Lekin n8n da ko'p hollarda faqat tugmalarning sozlanishi bilan amalga oshirilishi mumkin edi. Shukrki, rivojlanish tezligi juda oshdi va biznes mantiqiga ko'proq e'tibor qaratish imkoniyati bo'ldi.
Qo'shimcha ravishda Workflow qayta foydalanish qulay edi.
Masalan, ma'lum bir tekshirish mantiqini Sub Workflow shaklida ajratib qo'yish orqali bir nechta Workflow'da qayta foydalanish mumkin edi.
Bu, prompt asosidagi AI Workflow muhitida juda foydali bo'ldi.
Boshqaruv jihatidan ham katta afzalliklar bo'ldi. Workflow o'zgartirishdan keyin darhol amal qilish mumkin bo'lganligi sababli, shoshilinch javob berish tezligi juda tez bo'ldi.
Ayniqsa faqat so'rovni (Prompt) o'zgartirish talab qilingan hollarda alohida tarqatmasdan darhol o'zgartirish mumkinligi juda qulay edi.
5. Rivojlanish jarayonida his qilgan kamchiliklar
Albatta, n8n har qanday vaziyatda mukammal vosita bo'lmagan. Amaliy loyihalarni amalga oshirish jarayonida bir qator kamchiliklarni ham kuzatish mumkin edi.
Birinchi navbatda, men his qilgan kamchilik versiya boshqaruvining qiyinligi edi.
n8n ham o'zgarish tarixini saqlash imkoniga ega, lekin Java kodi kabi Git Diff asosida o'zgarishlarni intuitiv ravishda taqqoslash qiyin edi.
Xususan, Workflow tuzilishi murakkab bo'lgani sayin, qaysi tugun sozlamalari o'zgarganini birma-bir tekshirish kerak bo'ldi.
Ikkinchisi murakkab Workflow da yuzaga keladigan o'qish qulayligi muammosi edi.
Boshida tugunlarga asoslangan tuzilma juda intuitiv tuyuldi, lekin Workflow hajmi oshgan sari aksincha ekran murakkablashdi. Ayniqsa, shartli bo'linmalar va takrorlanuvchi mantiq ko'payganda, bog'lanish chiziqlari o'zaro murakkab tarzda bog'lanish muammosi mavjud edi.
Uchinchi test avtomatlashtirishning yo'qligi edi.
Ommaviy kod asosidagi muhitda JUnit kabi test freymvorklaridan foydalanib avtomatlashtirilgan testlarni tashkil etish mumkin. Lekin n8n asosan Workflow markazli vosita bo'lgani uchun kod darajasidagi test avtomatlashtirishni amalga oshirish qiyin edi.
Natijada, ko'pchilik qo'lda sinov o'tkazishga tayanishga majbur bo'lishdi. Bu operatsion miqdor oshgani sari yuk bo'lishi mumkin edi.
Yana bir muammo katta hajmdagi qayta tuzishning qiyinligi edi.
Masalan, ma'lum bir o'zgaruvchaning nomini yoki tugun nomini o'zgartirishda IDE Refactoring funksiyasi kabi avtomatik ravishda umumiy o'zgarishlar amalga oshirilmagan.
Ya'ni, bog'langan tugunlarni bevosita topib, tuzatish kerak edi. Workflow hajmi kattalashgan sari bunday ishlar juda noqulay bo'lib tuyuldi.
Natijada n8n “tez ishlab chiqish”da juda kuchli, lekin juda murakkab katta tizimlarda ma'lum darajada operatsion murakkablik paydo bo'lishi mumkinligini ham boshdan kechirdik.
6. Yakun
Ushbu loyiha orqali n8n oddiy avtomatlashtirish vositasidan tashqari AI Workflow platformasi sifatida ham katta imkoniyatlarga ega ekanligini tasdiqlash mumkin edi.
Ayniqsa, AI tizimlari talablar juda tez o'zgaradi.
Fikrni (Prompt) bitta o'zgartirish natija sifatini o'zgartirishi mumkin va tasdiqlash mezonlari ham doimiy ravishda o'zgartirilishi mumkin.
Bunday muhitda tezkor o'zgartirishlar va darhol aks ettirish juda muhimdir.
n8n ushbu talablar uchun juda mos keladigan tuzilmani taqdim etdi.
Xususan, quyidagi vaziyatlarda juda katta afzalliklarni his qildim.
- Takroriy targ'ishlarni o'zgartirish
- Tez tajriba muhitini yaratish
- Turli tizimlarni integratsiya qilish
- Tadbirga asoslangan ish jarayonini tuzish
- AI Agent oqim visualizatsiyasi
- operatsion jurnalni nazorat qilish
Albatta, murakkablik juda yuqori bo'lganda kod asosidagi tuzilma bilan ta'minlash qiyinlashishi mumkin. Ammo tezkor takroriy rivojlantirish va operatsion avtomatlashtirish muhim bo'lgan loyihalar uchun n8n juda kuchli tanlov bo'lishi mumkin deb o'ylayman.
Ushbu tajriba orqali AI tizimlarida oddiy model samaradorligi emas, balki operatsion tuzilma va tasdiqlash tizimi ham juda muhim ekanligini yana bir bor his qildim.
Xususan, Verifier qatlamining kelajakda AI tizimlarida tobora muhim rol o'ynashi kutilmoqda.
Kelajakda shunga o'xshash AI ish jarayonlari loyihalari bo'lsa, n8n'dan yana foydalanish imkoniyati yuqori darajada qoniqarlilikka ega bo'lgan tajriba bo'ldi.
sby