AI केस स्टडी
लिगेसी प्रणालीलाई नयाँ प्लेटफर्ममा सार्दा, सबैभन्दा पहिले आउने कुरा संरचना अध्ययन हो। परम्परागत तरिकामा, जनशक्ति छुट्याएर करिब एक महिना। उत्पादन भनेको कागजी तुलना तालिका र अनुमानित लागत। समस्या यो हो — त्यस तुलना तालिकाको शुद्धताउत्पादन विकास सुरु नभएसम्म कसैले पुष्टि गर्न सक्दैनभन्ने कुरा। “रोजिएको संरचनाले वास्तवमा प्रदर्शन आवश्यकता पूरा गरेन” भन्ने कुरा प्रायः पछि फर्कन नसकिने अवस्था आइसकेपछि मात्र थाहा हुन्छ। यस परियोजनामा, हामीले यो तरिका त्यागिदियौं।
दुई दिनमा “चल्ने प्रोटोटाइप” बनाएर, वास्तविक मापनले निर्णय गर्ने।
- १. वर्तमान प्रणालीको विश्लेषण — AI एजेन्ट (Claude Code) ले वर्तमानका स्क्रिन, सुविधा र अनुमतिलाई पूर्ण रूपमा जाँचेर, १४ स्क्रिन, ४५ सुविधा, ५२७ वस्तुको भूमिका-अनुसार म्याट्रिक्स र प्रतिक्रिया-वर्गीकरणसहितको ४६ वटा समस्या-अभिलेखमा व्यवस्थित
- २. प्रोटोटाइप निर्माण (वास्तविक काम दुई दिन) — विचाराधीन संरचना जस्ताको तस्तै राखेर, API र डेमो स्क्रिनसहितको चल्ने प्रोटोटाइप निर्माण। परिमाण करिब ६६,००० लाइन (API करिब २७,००० लाइन + स्क्रिन करिब ३९,००० लाइन)
- ३. डेटा हालेर वास्तविक मापन — १०,००० रेकर्ड हालेर, सबै API र सबै स्क्रिनको प्रतिक्रिया मापन। “यो संरचनाले, यो परिमाणमा, यो गति दिन्छ” भन्ने कुरा अंकमा उतारिन्छ
वास्तवमा मापन गरेकाले, गिरावट होस् वा उपाय, दुवै “तथ्य”का आधारमा भन्न सकियो।
१०,००० रेकर्ड हाल्दाको पहिलो मापनमा, केही API २२ सेकेन्ड, स्क्रिन प्रदर्शन ९० सेकेन्ड नाघ्यो। कागजी अध्ययनमा भए यहीँ सुरुमै फर्किनुपर्थ्यो, तर वास्तविक वस्तु भएकालेकहाँ ढिलो भइरहेको हो भनी पहिचान गरी उपाय गर्न सकिन्छ। इन्डेक्स डिजाइनको पुनरावलोकनदेखि एक्सेस प्याटर्नको परिवर्तनसम्म, उपायलाई चार चरणमा विभाजन गरी लागू तथा पुनः मापन गरेको नतिजा —सबै API २२ सेकेन्ड → ३ सेकेन्डभित्र, सबै स्क्रिन ९० सेकेन्ड नाघेकोमा → २ सेकेन्ड कोटीमा। एकल फेच ६०० गुणा सुधार भएको वास्तविक मापनमा पुष्टि भयो। यही अंकसहित संरचना निश्चित गरेकाले, “उत्पादनमा प्रदर्शन नआउन सक्छ” भन्ने चिन्तासमेत हट्यो।
“अध्ययन”को सामान्य बुझाइ नै बदलिन्छ।
यस तरिकाको सार गति आफैं होइन।निर्णयका आधार “अनुमान”बाट “वास्तविक मापन”मा बदलिनेकुरा। कागजी तुलना तालिका चल्ने प्रोटोटाइप र मापन डेटामा, “सम्भवतः थेग्ला” भन्ने कुरा “यो परिमाणमा यो प्रतिक्रिया समय”मा, र समस्या थाहा हुने समय उत्पादन विकासको बीचबाट संरचना अध्ययनको बीच (= जति पटक पनि पुनः गर्न सकिने चरण) मा बदलिन्छ। प्रोटोटाइप फ्याँके पनि पछुतो नलाग्ने लागतमा बनाउन सकिने भयो। त्यसैले, बनाएपछि निर्णय गर्ने। संरचना अध्ययन, प्रविधि छनोट र PoC को तरिका, AI एजेन्टको आगमनसँगै जरैदेखि पुनर्लेखन भइरहेको छ।
के तपाईं पनि यस्तै अवस्थामा अल्झिनुभएको छ?
“नयाँ प्रणालीको संरचना निर्णय गर्न सकिरहेको छैन,” “भेन्डरको प्रस्ताव उपयुक्त छ कि छैन छुट्याउन सकिँदैन,” “PoC मा महिनौं खर्चिन चाहन्न” — त्यो अध्ययन,चल्ने वस्तु + वास्तविक मापनले अघि बढाऔं न।
हाम्रो कम्पनीले लिगेसी नवीकरणलाई “AI Re: Platform” (छोटकरीमा: AIR Platform) का रूपमा प्रदान गर्छ।
विद्यमान स्रोतको विश्लेषणसम्म निःशुल्क।परिणाम प्राविधिक ऋणको सूची र “पुनः बनाउने / बेर्ने” प्रारम्भिक रणनीति समेटिएकोसरल संस्करणको “AIR रिपोर्ट”का रूपमा हस्तान्तरण गर्छौं (NDA मा हस्ताक्षर गरेर सञ्चालन)।अहिले नै सम्पर्क गर्नुहोस्।
सम्पर्क फारम(“निःशुल्क विश्लेषण (AIR रिपोर्ट) चाहिन्छ” भनी लेखिदिनुहोस्) / info@flagship-ai.jp
निःशुल्क अनलाइन सेमिनार“लिगेसी to AI ― IT उद्योगको औद्योगिक क्रान्ति, र २० वर्ष पुरानो Java प्रणालीलाई पुनर्जीवित गरेको वास्तविक अभिलेख”आयोजना हुने योजना (मिति मिलाइँदै)।पूर्व-दर्ता चाँडै सुरु हुनेछ ― यही ब्लगमा सूचना दिनेछौं।
शृंखला “लिगेसी to AI वास्तविक अभिलेख”
- समग्र संस्करण: एउटै PC मा २२ प्रणाली र 246,000 लाइन ― AI विकासको ३.५ महिनाको मापन-अभिलेख
- वास्तविक अभिलेख①: २० वर्ष पुरानो Java लाई, करिब एक हप्तामा पूर्ण नवीकरण
- वास्तविक अभिलेख②: विद्यमान कोडमा ० लाइन परिवर्तनसहित, मूल प्रणालीमा नयाँ प्रवेशद्वार बनाउने
- वास्तविक अभिलेख③: एक महिना स्तरको संरचना अध्ययनलाई, दुई दिनमा प्रोटोटाइप + वास्तविक मापनले (यही लेख)
※ यस लेखका अंकहरू २०२६ जुलाई अन्त्यको वास्तविक मापन हुन्। विकास परिणाम प्रणालीको अवस्था र आवश्यकताअनुसार फरक हुन्छ।