நிறுவன அளவிலான AI சூழல் மாறியுள்ளது. சில ஆண்டுகளுக்கு முன்பு, இயந்திரக் கற்றலை (machine learning) சோதனை செய்யக் கூட தலைமையினரைச் சம்மதிக்க வைப்பது ஒரு கடினமான போராட்டமாக இருந்தது. இப்போது பட்ஜெட்டுகள் உள்ளன. சோதனைத் திட்டங்களுக்கு (Pilots) அனுமதி கிடைக்கிறது. பயன்பாட்டுத் தேவைகள் (Use cases) திட்டங்களில் குவிந்து கொண்டே இருக்கின்றன. இருப்பினும், இந்தத் திட்டங்களில் பல விலையுயர்ந்த சோதனைகளாகவே முடிந்துவிடுகின்றன, அவை வணிகம் உண்மையில் இயங்கும் முறையை ஒருபோதும் மாற்ற முடிவதில்லை. மாடல்கள் சரியாக உள்ளன. பிரச்சனை மற்ற அனைத்திலும் உள்ளது.

சோதனைத் திட்டங்கள் தோல்வியடையும் இடங்கள்

டெமோக்களை (demo) அனைவரும் விரும்புகிறார்கள். மாதிரி வடிவம் (prototype) வாடிக்கையாளர் வெளியேற்றத்தை (churn) வியக்கத்தக்க துல்லியத்துடன் கணிக்கிறது. இயக்குநர்கள் குழு தலையசைக்கிறது. நிதி கிடைக்கிறது. பிறகு அமைதி. கருத்தியல் நிரூபணம் (proof of concept) அங்கீகரிக்கப்படுகிறது, ஆனால் முன்னேற்றம் தடைபடுகிறது. என்ன நடந்தது?

வணிகக் குழுவினர் ஒரு டேஷ்போர்டைப் பார்த்துவிட்டு, அது அவர்களின் அன்றாடப் பணிப்பாய்வோடு (workflow) எப்படிப் பொருந்துகிறது என்று புரியாமல் தவிக்கிறார்கள். மாடலுக்குத் தரவுகளை வழங்கும் தரவுப் பாதை (data pipeline) ஒருமுறை மட்டும் எடுக்கப்பட்ட கைமுறைத் தரவாகும், அதை யாரும் நிர்வகிப்பதில்லை. இணக்க விதிகள் (Compliance rules) இடையில் மாறுகின்றன. CRM இதுவரை வழங்காத சுத்தமான உள்ளீடுகளை (clean inputs) இந்த அமைப்பு கோருகிறது. AI ஒரு நோட்புக்கில் (notebook) வேலை செய்கிறது. அதை வைத்து நிறுவனம் என்ன செய்வது என்று தெரியவில்லை.

இது ஒரு விநியோகத் தோல்வி (delivery failure). 95 சதவீதத் துல்லியத்தைக் கொண்ட ஒரு மாடல் ஒரு ஹேக்கத்தானில் வெற்றி பெறலாம். ஆனால் மீதமுள்ள ஐந்து சதவீதம் தணிக்கை சிக்கல்களையோ அல்லது பாதுகாப்பு விதிமீறல்களையோ ஏற்படுத்தினால், செயல்பாட்டுத் துறை அதை நிறுத்திவிடும். பொறியாளர்கள் தொழில்நுட்ப மைல்கற்களைக் கொண்டாடுகிறார்கள். வணிகப் பிரிவுகள் வராத முடிவுகளுக்காகக் காத்திருக்கின்றன. இவ்விரண்டிற்கும் இடையிலான இடைவெளியில்தான் திட்டங்கள் தோல்வியடைகின்றன.

புரிதலுக்கான இடைவெளி

இதை அப்படியே சொல்லலாம். நிர்வாகிகள் வருவாய் வளர்ச்சி அல்லது செலவுக் குறைப்பை விரும்புகிறார்கள். செயல்பாட்டுத் துறை குழப்பமில்லாத வேகத்தை விரும்புகிறது. தரவுக் குழுக்கள் அர்த்தமுள்ள ஸ்கீமாக்களை (schemas) விரும்புகின்றன. பொறியாளர்கள் இயங்கும் நேரம் (uptime) மற்றும் சுத்தமான APIs-களை விரும்புகிறார்கள். இந்த விருப்பங்கள் எதுவும் இயல்பாக ஒன்றிணைவதில்லை.

தனித்தனியாக விடப்பட்டால், ஒவ்வொரு குழுவும் வெவ்வேறு விஷயங்களை மேம்படுத்த முயல்கிறது. ஒரு பொறியாளர் லேட்டன்சியைக் (latency) குறைக்க வாரக்கணக்கில் செலவிடலாம், அதே நேரத்தில் விற்பனைத் குழு இன்னும் எக்செல் (Excel) கோப்பையே பயன்படுத்துகிறது, ஏனெனில் அதன் UI அவர்களைக் குழப்புகிறது. ஒரு தரவு விஞ்ஞானி AUC-ன் நான்காவது தசம இடத்தைப் பற்றி கவலைப்படலாம், அதே நேரத்தில் கிடங்குத் குழு (warehouse team) முக்கியமான ஒரு புலத்தில் (field) ஆறு மாதங்களாகத் தவறான தரவுகளைப் பதிவு செய்து கொண்டிருக்கலாம். யாரும் தவறு செய்யவில்லை. அவர்கள் வெவ்வேறு மொழிகளில் பேசுகிறார்கள்.

இந்தத் தவறான ஒருங்கிணைப்பே (misalignment) சோதனைத் திட்டத்திற்குப் பிறகு AI தேக்கமடைவதற்குப் பெரிய காரணமாகும். இது GPU பற்றாக்குறையல்ல. இது PhD பட்டதாரிகளின் பற்றாக்குறையல்ல. இந்தக் குழுக்களுக்கு இடையே அமர்ந்து ஒரு பொதுவான புரிதலை உருவாக்கக்கூடிய ஒருவரின் இல்லாமையே இதற்குக் காரணம்.

Forward Deployed Engineers உண்மையில் என்ன செய்கிறார்கள்

Forward Deployed Engineers அந்தப் பாலமாகச் செயல்படுகிறார்கள். அவர்கள் உங்கள் தரவு விஞ்ஞானிகளையோ அல்லது பிளாட்ஃபார்ம் பொறியாளர்களையோ மாற்றீடு செய்வதில்லை. தொழில்நுட்பம் பயன்பாட்டிற்கு வரும் முன்பே அதைத் தடுக்கும் நிறுவன ரீதியான தடைகளைச் சரிசெய்ய அவர்கள் வணிகம், பொறியியல், தரவு மற்றும் தயாரிப்புக் குழுக்களுடன் இணைந்து பணியாற்றுகிறார்கள்.

ஒரு FDE ஒரு திட்டத்திற்குள் நுழையும்போது, அவர் கடினமான கேள்விகளைக் கேட்டுத் தொடங்குகிறார். இந்தக் கருவியைப் பயன்படுத்துபவருக்கு ஒரு வெற்றிகரமான செவ்வாய்க்கிழமை காலை எப்படி இருக்கும்? இந்தத் தரவு ஓட்டத்திற்கு உண்மையில் எந்த மூன்று பழைய அமைப்புகள் (legacy systems) தரவுகளை வழங்குகின்றன? மாடல் தவறாக இருந்தால் செயல்முறைக்கு என்னவாகும்? அவர்கள் பதில்களைத் தொழில்நுட்ப முடிவுகளாக மாற்றுகிறார்கள், இதனால் குழுக்கள் தவறான தீர்வை உருவாக்க மாதக்கணக்கில் நேரத்தை வீணடிக்க மாட்டார்கள்.

ஒரு வழக்கமான பணியின் போது, ஒரு FDE:

  • தெளிவற்ற உத்தரவுகளை ஏற்றுக்கொள்வதற்குப் பதிலாக, பங்குதாரர்களுடன் (stakeholders) இலக்குகளைத் தெளிவுபடுத்துவார்
  • எந்தவொரு Jira டிக்கெட்டிலும் விவரிக்கப்படாத தடைகளைக் கண்டறிய செயல்முறைத் தளத்திற்குச் சென்று ஆய்வு செய்வார்
  • தற்போதைய ஆவணங்கள் விடுபட்ட தரவுத் தொடர்புகளைக் (data dependencies) கண்டறிவார்
  • அந்தத் தேவைகளைத் தெளிவான தொழில்நுட்ப முடிவுகளாக மாற்றுவார்
  • முடிவுகளைப் பயன்படுத்தப் போகும் செயல்பாட்டுத் குழுவுடன் இணைந்து, ஆரம்பத்திலேயே அனுமானங்களைச் சரிபார்ப்பார்

FDE-கள் தொழில்நுட்பப் பிரச்சினைகளை மட்டுமல்லாமல், நிறுவன ரீதியான பிரச்சினைகளையும் தீர்க்கிறார்கள். ஒரு செயல்பாட்டு மேலாளர் பயிற்சித் தரவைத் தேர்ந்தெடுப்பதில் சேர்க்கப்படாததால் மாடலை நம்பாமல் இருப்பதை அவர்கள் கவனிக்கலாம். எனவே அவர் புரிந்துகொள்ளக்கூடிய ஒரு பின்னூட்டச் சுழற்சியை (feedback loop) அவர்கள் உருவாக்குகிறார்கள். ஒரு பணிப்பாய்விற்கு இரண்டு ஒப்புதல்கள் தேவைப்படுவதையும், புதிய அமைப்பு அதைத் தவிர்க்கிறதையும் அவர்கள் கண்டறியலாம், மேலும் அவர்கள் ஒரு தவறான செயல்முறையில் கருவியைத் திணிக்காமல், அந்தப் பரிமாற்ற முறையை (handoff) மறுவடிவமைப்பு செய்கிறார்கள்.

துல்லியத்தை மட்டுமல்ல, பயன்பாட்டையும் அளவிடுங்கள்

மிகவும் வெற்றிகரமான AI திட்டங்கள் ஒரு மாறுபட்ட மதிப்பீட்டு முறையைப் பின்பற்றுகின்றன. மாடல் அளவீடுகள் (metrics) இன்னும் முக்கியம்தான், ஆனால் உண்மையான குறிகாட்டிகள் அதன் அடுத்தடுத்த நிலைகளில் உள்ளன. மக்கள் பயன்படுத்துகிறார்களா...