20 ஆண்டுகள் பழமையான ஒரு காப்பீட்டுத் தளத்தின் (insurance platform) ஆசிரியர், 108 ஆதரவு டிக்கெட்டுகளை (support tickets) ஒரு தனிப்பயனாக்கப்பட்ட AI-agent pipeline மூலம் இயக்கினார். இதன் விளைவாக, பல மணிநேரம் ஒரு மூத்த மென்பொருள் பொறியாளருக்கு (senior developer) தேவைப்படும் ஒரு பணி, சில நிமிடங்களிலேயே முடிந்துவிடும் ஒரு பணிப்பாய்வாக (workflow) மாறியுள்ளது. இது நிறுவனங்கள் தங்களின் பழைய குறியீடுகளை (legacy code) எவ்வாறு பராமரிக்கின்றன என்பதை மாற்றியமைக்கக்கூடிய ஒரு மாற்றமாகும்.
புதிய குறியீடுகளை விட பழைய அமைப்புகள் ஏன் முக்கியமானவை
இங்கு குறிப்பிடப்பட்டுள்ள காப்பீட்டுச் செயலி, 2.3 மில்லியன் வரிகள் கொண்ட குறியீடு மற்றும் சுமார் 1,000 PL/SQL தொகுப்புகளைக் (packages) கொண்ட ஒரு மாபெரும் அமைப்பாகும் (monolith). இதன் அளவே, ஒரு தனி நபரால் முழுமையான குறியீட்டுத் தொகுப்பையும் (codebase) கையாள முடியாதபடி செய்கிறது. அதோடு, வாடிக்கையாளர் சார்ந்த பல்வேறு கட்டமைப்பு அளவுருக்கள் (configuration parameters), சிதறிக்கிடக்கும் ஆவணங்கள் மற்றும் 2017 முதல் தொடரும் டிக்கெட் ஆவணங்கள் ஆகியவற்றைச் சேர்த்தால், உண்மையான சவால் குறியீடு எழுதுவது அல்ல, மாறாக "சூழலைத் தேடிப் பெறுவதுதான்" (finding context).
தற்போதைய நவீன AI குறித்த எதிர்பார்ப்புகள் பெரும்பாலும் புதிய திட்டங்களுக்கான (greenfield projects) புதிய குறியீடுகளை உருவாக்குவதிலேயே கவனம் செலுத்துகின்றன. ஆனால் இந்தச் சூழலில், கடினமான பகுதி PL/SQL-ன் தொடரியல் (syntax) அல்ல; மாறாக, சரியான தர்க்கப் பகுதி (logic), தொடர்புடைய கட்டமைப்பு (configuration) மற்றும் அந்தப் பிரச்சனையை முதலில் விவரித்த வரலாற்று ரீதியான டிக்கெட்டைத் தேடிக் கண்டுபிடிப்பதே ஆகும். ஒரு அனுபவம் வாய்ந்த மென்பொருள் பொறியாளர் GitLab, SVN, wikis மற்றும் பழைய ஆதரவு டிக்கெட்டுகளில் இருந்து தடயங்களைச் சேகரிக்க பல மணிநேரங்களைச் செலவிடக்கூடும். ஆனால் இந்த AI agent அதே வேலையை சில நிமிடங்களில் செய்துவிடுகிறது.
நடைமுறைப் பணிப்பாய்வு
ஒரு புதிய டிக்கெட் வரும்போது, ஆசிரியர் ஒரு கட்டளையை (command) மட்டும் இயக்குகிறார். அதன் பிறகு அந்த ஏஜென்ட்:
- ticket-system API மூலம் டிக்கெட் உரை மற்றும் இணைக்கப்பட்ட கோப்புகளைப் பெறுகிறது.
- கடந்த காலத் தீர்வைகளைக் கண்டறிய முழு டிக்கெட் ஆவணத்திலும் keyword மற்றும் vector search செய்கிறது.
- மீண்டும் பயன்படுத்தக்கூடிய SQL ஸ்கிரிப்ட்களின் தனிப்பட்ட நூலகத்திலிருந்து (personal library) தேடுகிறது.
- பதிப்புக் கட்டுப்பாட்டு அமைப்புகளில் (version-control systems - GitLab அல்லது SVN) குறியீட்டு வரலாற்றை ஆய்வு செய்கிறது.
அனைத்துக் கண்டுபிடிப்புகளும் ஒரே கோப்பாகத் தொகுக்கப்பட்டு, அடுத்த கட்டமாக என்ன செய்ய வேண்டும் என்பதையும் பரிந்துரைக்கும்—பொதுவாக ஒரு குறியீடு திருத்தம் (code fix), வாடிக்கையாளருக்கான பதில் வரைவு அல்லது கூடுதல் கண்டறிதலுக்கான (diagnostics) கோரிக்கை என இருக்கும்.
உள்ளமைக்கப்பட்ட திறன்கள்
ஆசிரியர் ஏஜென்ட்டிற்காக 24 "திறன்களை" (skills) வரையறுத்துள்ளார், அவை நான்கு வகைகளாகப் பிரிக்கப்பட்டுள்ளன:
- சூழல் அணுகல் (Context access) – தொடர்புடைய தகவல்களைப் பெற API-கள், கையேடுகள் மற்றும் தரவுத்தளங்களை (databases) வாசித்தல்.
- துறை சார்ந்த அறிவு (Domain knowledge) – காப்பீட்டு கணக்கியல் விதிகள் மற்றும் அமைப்பின் கட்டமைப்பை (architecture) விளக்குதல்.
- எழுதுதல் (Writing) – PL/SQL துணுக்குகளை (snippets) உருவாக்கி அவற்றை பயன்பாட்டிற்குத் தயார் செய்தல்.
- மெட்டா (Meta) – வடிவங்களைக் கண்டறிந்து தேவைப்படும்போது தானாகவே புதிய திறன்களை உருவாக்குதல்.
இந்தத் திறன்கள், ஏஜென்ட்டை ஒரு தூங்காத ஜூனியர் பொறியாளரைப் போலச் செயல்பட வைக்கின்றன; ஒரு டிக்கெட் எதைக் குறிப்பிடுகிறதோ, அந்தத் துல்லியமான குறியீடு அல்லது கட்டமைப்பைக் கண்டறிந்து தருகின்றன.
பணிச் சுழற்சியில் உள்ள பாதுகாப்பு வலைகள்
நேரடிச் செயல்பாட்டுச் சூழலில் (production environment) தானியங்கி முறையைப் பயன்படுத்தும்போது பாதுகாப்பு நடவடிக்கைகள் அவசியம். ஆசிரியர் இரண்டு எளிய விதிகளைப் பின்பற்றுகிறார்:
- நிலையான சரிபார்ப்பு (Static validation) – உருவாக்கப்பட்ட ஒவ்வொரு ஸ்கிரிப்ட்டும் நேரடி ஸ்கீமாவுக்கு (live schema) எதிராக
EXPLAIN PLANமூலம் இயக்கப்படுகிறது. இது குறியீட்டை உண்மையில் இயக்காமல், அதன் தொடரியல் அல்லது தர்க்கப் பிழைகளைச் சரிபார்க்கிறது. - இரட்டை மாதிரி உறுதிப்படுத்தல் (Dual-model confirmation) – அபாயகரமானதாகக் கருதப்படும் எந்தவொரு மாற்றத்தையும் இரண்டாவது, சுதந்திரமான AI ஏஜென்ட் ஆய்வு செய்கிறது. இரண்டு மாதிரிகளும் ஒரே முடிவுக்கு வந்தால், ஆசிரியர் தொடர்கிறார்; இல்லையெனில், அந்த டிக்கெட் மேனுவல் ஆய்விற்காக (manual review) மாற்றப்படுகிறது.
இந்தச் சரிபார்ப்புகள், ஒரு முக்கியமான காப்பீட்டுப் பரிவர்த்தனையைத் தெரியாமல் சிதைக்கக்கூடிய ஒரு "கருப்புப் பெட்டி" (black box) போல இந்தச் செயல்முறை மாறிவிடாமல் தடுக்கின்றன.
கூட்டுப் பயன்கள்
ஒவ்வொரு டிக்கெட்டின் வெளியீடும் மீண்டும் அந்த டிக்கெட் பதிவோடு இணைக்கப்படுகிறது, இது ஒரு வாழும் அறிவுத் தளத்தை (living knowledge base) உருவாக்குகிறது. பல மாதங்கள் அல்லது ஆண்டுகளுக்குப் பிறகு இதே போன்ற ஒரு பிரச்சனை மீண்டும் வரும்போது, ஏஜென்ட் முந்தைய தீர்வை மட்டுமல்லாமல், அந்தத் தீர்வுக்கு வழிவகுத்த காரணத்தையும் (reasoning) வாசிக்க முடியும். சொல்லப்போனால், தீர்க்கப்பட்ட ஒவ்வொரு டிக்கெட்டும் எதிர்கால டிக்கெட்டுகளுக்கான பயிற்சித் தரவாக (training data) மாறி, இந்தச் சுழற்சியை மேலும் வேகப்படுத்துகிறது.
நேர்மையான வரம்புகள்
- மேனுவல் சோதனை இன்னும் தேவை – ஆசிரியர் மாற்றங்களை பயன்பாட்டிற்கு கொண்டு வருவதற்கு முன்பு ஒரு சோதனைச் சூழலில் (test environment) அவற்றை இன்னும் சரிபார்க்கிறார்.
- துல்லியமான அளவீடுகள் இல்லை – சேமிக்கப்பட்ட நேரம் கணிசமாகத் தோன்றினாலும், மணிநேரங்களில் ஏற்பட்ட துல்லியமான குறைவை ஆசிரியர் அளவிடவில்லை.
- தனிப்பட்ட அமைப்பு – தற்போதைய அமலாக்கம் ஒரு ஒற்றை பணிநிலையத்தில் (workstation) உள்ளது; இதை ஒரு குழு முழுவதும் விரிவுபடுத்த கூடுதல் பொறியியல் தேவைப்படும்.
இந்தத் தடைகள் இந்த அணுகுமுறையை ஒரு முழுமையான தயாரிப்பாக (turnkey product) மாற்றுவதைத் தடுக்கின்றன, ஆனால் அதன் முக்கியக் கருத்தை அவை குறைக்கவில்லை: சூழலைத் திரட்டுவதில் பல மணிநேரங்கள் எடுக்கும் வேலையை AI சில நிமிடங்களாகக் குறைக்க முடியும்.
அடுத்து எதைக் கவனிக்க வேண்டும்
ஆசிரியரின் இந்தச் சோதனை ஒரு வணிகத் தயாரிப்பு என்பதை விட, ஒரு முன்மாதிரி (proof-of-concept) ஆகும். அடுத்தகட்டத் தர்க்கரீதியான நடவடிக்கைகள் பின்வருவனவற்றை உள்ளடக்கியது:
- அளவீடுகளை முறைப்படுத்துதல் – ஒரு வணிகத் திட்டத்தை (business case) உருவாக்க, AI பைப்லைனுக்கு முன்னும் பின்னும் டிக்கெட் தீர்க்கும் நேரத்தைக் கண்காணித்தல்.
- குழு பயன்பாடு – பல பொறியாளர்கள் ஒரே அறிவுத் தளத்திலிருந்து (knowledge base) பயனடைய ஏஜென்ட்டை ஒரு பகிரப்பட்ட சேவையாக (shared service) மாற்றுதல்.
- CI/CD உடன் ஒருங்கிணைத்தல் – சரிபார்க்கப்பட்ட ஸ்கிரிப்ட்களை நேரடியாக ஒரு continuous-integration பைப்லைனுக்குள் செலுத்துவதன் மூலம், மனிதத் தலையீடு இன்றி டிக்கெட்டில் இருந்து தயாரிப்பு நிலைக்கு (production) இடையிலான சுழற்சியை முழுமையாக்க முடியும்.
இந்த விரிவாக்கங்கள் வெற்றி பெற்றால், மிகப்பெரிய மற்றும் சிக்கலான codebases உடன் போராடும் பிற நிறுவனங்களுக்கு இந்த மாதிரி ஒரு முன்மாதிரியாக மாறக்கூடும்.
முக்கியக் கருத்து
பழைய கால மென்பொருள் சூழல்களில் (legacy environments) AI-ன் உண்மையான மதிப்பு புதிய குறியீடுகளைத் தானாக எழுதுவதில் இல்லை, மாறாக சரியான சூழலை (context) உடனடியாகக் கண்டறிவதில் உள்ளது. ஒரு மூத்த மென்பொருள் பொறியாளரின் பல மணிநேரத் தேடலை சில நிமிடங்களாக மாற்றுவதன் மூலம், ஒரு AI-agent பணிப்பாய்வு (workflow), பழைய அமைப்புகளைச் செயல்பாட்டில் வைத்திருக்கவும், ஆதரவுச் செலவுகளைக் குறைக்கவும் மற்றும் படிப்படியாக ஒரு சுய-வலுவூட்டும் அறிவுத் களத்தை (knowledge repository) உருவாக்கவும் உதவும். பழைய மென்பொருள்களுக்கு, புதிய குறியீடுகளை உருவாக்குவதிலிருந்து அல்லாமல், விடைகளுக்கான தேடலைக் குறைப்பதிலிருந்தே மிகப்பெரிய உற்பத்தித் திறன் அதிகரிப்பு கிடைக்கிறது என்பதை இந்த ஆய்வு காட்டுகிறது.
