Prompt дотор өгөгдөл чихдэг эрин дуусах уу? Бодит хугацаанд жингээ өөрөө үүсгэдэг "Хязгааргүй параметрт LLM" гарч ирлээ
Өнөөгийн хэлний загварууд (LLM) ямар ч ухаалаг байсан, суурь архитектурынхаа хувьд нэгэн том гацаанд орсон: Сургалт дууссаны дараа загварын жин (weights) бүрэн хөлддөг.
Хэрэглэгч шинэ баримт, кодын сангийн өөрчлөлт, эсвэл тусгай зааварчилгаа өгөхөд бид тэдгээрийг RAG (Retrieval-Augmented Generation) эсвэл prompt stuffing ашиглан миллион токен хүртэл тэлсэн контекст цонхонд (context window) чихэхээс өөр аргагүй болдог. Энэ нь эргээд token consumption-ийг үлэмж өсгөж, хүсэлт болгонд ижил түүхийг дахин дахин уншиж тооцоолох асар их GPU зардлыг дагуулдаг.
Тэгвэл сүүлийн 24 цагийн дотор Кембрижийн их сургууль болон Boltzbit Limited-ийн судлаачид энэхүү хуучирсан схемийг үндсээр нь өөрчлөх цоо шинэ архитектурыг arXiv дээр нийтэлж, Hacker News болон хиймэл оюуны судалгааны ертөнцөд шуугиан тарьж байна: "Infinite-Parameter LLMs: Generating and Adapting Weights from Live Data".
"Хязгааргүй параметр" гэж юу вэ?
Өнөөгийн Mixture-of-Experts (MoE) загварууд санах ойдоо хэдэн зуун тэрбум жин хадгалж, токен бүрт цөөн хэсгийг нь идэвхжүүлдэг. Гэвч энэ бүхэн урьдчилан диск дээр бичигдэж, бэлэн хадгалагдсан хязгаартай жингүүд юм.
Кембрижийн судлаачдын баг цоо шинэ асуулт тавьсан: Загварын бүх жинг заавал урьдчилан хадгалах хэрэгтэй гэж үү? Хэрэглэгчтэй харилцаж байх явцад шаардлагатай жинг нь шууд үүсгээд явбал яах вэ?
Энэхүү шинэ шийдэл нь дараах хоёр суурь бүрэлдэхүүнээс тогтоно:
- Суурь сүлжээ (Shared Base Network): Их хэмжээний өгөгдөл дээр ерөнхий хэлний логикийг сурсан авсаархан суурь сүлжээ.
- Hypernetwork (Жин үүсгэгч сүлжээ): Хэрэглэгчийн өгсөн шинэ мэдээлэл, заавар, алдааны залруулгыг уншаад, түүнийг суурь сүлжээний дээр шууд бага ранктай модуляц (low-rank modulation буюу LoRA-тай төстэй хэлбэрээр) болгон динамикаар үүсгэнэ.
Ингэснээр загварын физик санах ойн хэмжээ (VRAM footprint) өөрчлөгдөхгүй тогтмол хэвээр байх боловч загварын үүсгэж, эмхэтгэж чадах жингийн хувилбар нь математик утгаараа хязгааргүй (infinite) болж хувирч байна.
Гол ялгаа: Байесийн онлайн шинэчлэл (Bayesian Online Update)
Өмнө нь Hypernetwork ашиглах туршилтууд гарч байсан ч контекстийг ганц л удаа уншаад жингээ царцаачихдаг дутагдалтай байв.
Харин шинэ ажилд судлаачид Байесийн итгэлцлийн зарчимд (Bayesian belief over latent code) тулгуурласан онлайн шинэчлэлийг нэвтрүүлжээ. Энэ нь юу гэсэн үг вэ?
- Хэрэглэгч системтэй чатлаж, кодоо засварлах тусам загвар тэрхүү сессийн явцад гипер-сүлжээний далд векторыг тасралтгүй шинэчилнэ.
- Сессийн явцад үүсэх жингүүд нь шинээр ирсэн залруулга, нөхцөл байдалд тохируулан бодит хугацаанд хувьсан өөрчлөгдөнө.
- Ингэхдээ өмнөх мэдлэгээ мартахгүй (catastrophic forgetting-ээс сэргийлж), шинэ баримтыг яг л тухайн сүлжээний үндсэн параметрүүд мэт өндөр нарийвчлалтайгаар ашиглаж эхэлнэ.
Программ хөгжүүлэгчдэд яагаад энэ чухал вэ?
Энэхүү судалгааны ажил бодит программ хангамжийн дэд бүтцэд нэвтэрвэл бидний өдөр тутмын хөгжүүлэлтийн паттернд асар том эргэлт гарна:
1. Контекст цонхны чөлөөлөлт
Одоогоор бид AI туслахад төслийн архитектур, өмнөх 50 файл, README, хөгжүүлэлтийн дүрмүүдийг бүгдийг нь контекст руу шахдаг. Үүний оронд төслийн контекстийг хэдхэн миллисекундэд нэг удаа гипер-сүлжээгээр уншуулаад загварын динамик жин болгочихвол таны бүх контекст цонх зөвхөн одоо хийж буй цэвэр код бичих ажилд бүрэн чөлөөлөгдөнө.
2. Тооцооллын зардлын хэмнэлт (Compute Amortization)
RAG болон контекст дэх урт текстийг токен бүрээр квадрат зэрэгтээр (attention complexity) бодож мөнгө үрэхийн оронд өгөгдлийг жин рүү хөрвүүлснээр дараа дараагийн бүх token generation нь ердийн feed-forward хурдаар буюу хамаагүй хямд, хурдан явагдана.
3. Бодит хугацааны суралцалт (Instant Personalization)
Хөгжүүлэгч "Манай системд REST биш gRPC ашигладаг, мөн өгөгдлийн бааз руу шууд хандаж болохгүй" гэж нэг л удаа анхааруулахад тухайн сессийн жин тэр даруй өөрчлөгдөж, дараагийн хариултуудад алдаа гаргахгүй баттай баримтална.
Цаашдын сорилтууд
Энэхүү шинэ архитектур нь лабораторийн орчинд in-context learning болон retrieval-аас илүү сайн ерөнхийлөх (generalization) чадвартай болохыг харуулсан ч үйлдвэрлэлийн түвшинд хүрэхэд дараах саадууд бий:
- Serving дэд бүтэц: Хэрэглэгч бүрт, сесс бүрт өөр жинг бодит хугацаанд түр үүсгэхэд GPU кешийн архитектур (vLLM, TensorRT-LLM зэрэг) хэрхэн зохицох вэ?
- Аюулгүй байдал: Динамикаар өөрчлөгдөж буй жингүүд рүү prompt injection дайралт хийвэл загварын зан төлөв хэрхэн өөрчлөгдөхийг одоогоор бүрэн судлаагүй байна.
Гэсэн хэдий ч "том загвар = илүү олон диск дээр хадгалагдсан параметр" гэсэн 6 жилийн турш ноёрхсон монотон сэтгэлгээг эвдэж, "өгөгдлийг контекстэд бүү хадгал, жин болгож амилуул" гэсэн парадигм эхэлж буйг энэхүү судалгаа тод илэрхийлж байна.
Сэтгэгдэл
Ачаалж байна...