A chatbot in an enterprise setting is not a toy. It processes refunds, checks inventory, schedules appointments, and han

ஒரு நிறுவனச் சூழலில் (enterprise setting) பயன்படுத்தப்படும் சாட்பாட் (chatbot) என்பது ஒரு விளையாட்டுப் பொருள் அல்ல. இது ரீஃபண்டுகளை (refunds) செயலாக்குகிறது, இருப்புகளை (inventory) சரிபார்க்கிறது, சந்திப்புகளைத் திட்டமிடுகிறது மற்றும் முக்கியமான உரையாடல்களைப் பெரிய அளவில் கையாள்கிறது. ஒரு சாட் விண்டோவை (chat window) மேலே ஒட்டிய ஒரு வார இறுதித் திட்டத்தைப் போல நீங்கள் இதைக் கருதினால், உண்மையான பயனர்கள் வரும்போது இது முடங்கிவிடும். பெரிய நிறுவனங்களுக்கு, உரையாடல் இடைமுகங்களை (conversational interfaces) மற்ற முக்கியமான வணிக அமைப்புகளைப் போலவே கருதும் ஒரு உத்தி தேவை: அதாவது மாடுலர் (modular), ஒருங்கிணைந்த (integrated), பாதுகாப்பான (secure) மற்றும் நோக்கத்துடன் செயல்படுத்தப்பட்ட (deployed with purpose) அமைப்பாக இருக்க வேண்டும்.

உண்மையான சுமையைக் கையாளும் கட்டமைப்பு (Architecture)

மைக்ரோசர்வீஸ்களுடன் (microservices) தொடங்குங்கள். இயற்கை மொழி இயந்திரம் (natural language engine), வணிகத் தர்க்கம் (business logic) மற்றும் மூன்றாம் தரப்பு இணைப்பிகள் (third-party connectors) அனைத்தும் ஒரே கோட்பாட்டில் (codebase) இருக்கும் ஒரு மோனோலிதிக் (monolithic) சாட்பாட்டைப் புதுப்பிப்பது சாத்தியமற்றது. உங்கள் NLP குழு ஒரு புதிய இன்டென்ட் மாடலை (intent model) வெளியிட விரும்பும்போது, அவர்கள் உங்கள் ERP இணைப்பிகளைப் பராமரிக்கும் குழுவுடன் ஒருங்கிணைந்து செயல்பட வேண்டிய அவசியமில்லை. அமைப்பைத் தனித்தனி சேவைகளாகப் பிரிப்பது ஒவ்வொரு அங்கமும் சுதந்திரமாக வளர்ச்சியடைய அனுமதிக்கிறது.

APIs இந்தச் சேவைகளை ஒன்றாக இணைக்கின்றன. நீங்கள் REST, gRPC அல்லது நிகழ்வு சார்ந்த (event-driven) webhooks ஆகியவற்றைப் பயன்படுத்தினாலும், அதன் தத்துவம் ஒன்றுதான்: பாகங்களுக்கு இடையிலான தரப்படுத்தப்பட்ட ஒப்பந்தங்கள் (standardized contracts). ஆனால் மாடுலாரிட்டி (modularity) எவ்வளவு முக்கியமோ, அதே அளவு கன்கரன்சி (concurrency) க்கான வடிவமைப்பும் முக்கியமானது. நிறுவன சாட்பாட்கள் ஒரு சாதாரண வெப் சர்வரை முடக்கிவிடும் அளவுக்குப் போக்குவரத்து அதிகரிப்பை (traffic spikes) எதிர்கொள்ளும். திறந்த பதிவு காலத்தின் போது (open enrollment), ஒரு HR பாட் ஆயிரக்கணக்கான ஒரே நேரத்தில் நடக்கும் அமர்வுகளை (simultaneous sessions) சந்திக்கலாம். லோட் பேலன்சிங் (Load balancing) அந்தப் போக்குவரத்தை பல இன்ஸ்டன்ஸ்களுக்கு (instances) விநியோகிக்கிறது, அதே நேரத்தில் கேச்சிங் (caching) — அடிக்கடி கேட்கப்படும் தரவுகளுக்கு Redis போன்ற ஒன்றைப் பயன்படுத்துவது — ஒவ்வொரு முறையும் பேக்எண்ட் தரவுத்தளங்களை (backend databases) அணுகாமல் பொதுவான பதில்களை உடனடியாக வழங்குகிறது.

உங்கள் உரையாடல் இயந்திரத்தை ஸ்டேட்லெஸ் (stateless) ஆக வடிவமைக்கவும். பயனரின் சூழல் (context) ஒரு மையப்படுத்தப்பட்ட செஷன் ஸ்டோரில் (central session store) இருக்க வேண்டுமே தவிர, ஒரு தனி சர்வர் இன்ஸ்டன்ஸின் நினைவகத்தில் (memory) இருக்கக்கூடாது. அவ்வாறு செய்வதன் மூலம், ஒரு நோட் (node) செயலிழந்தால், மற்றொரு நோட் தடையின்றி உரையாடலைத் தொடரும். ஸ்டேட்லெஸ் கட்டமைப்பு கிடைமட்ட அளவீட்டை (horizontal scaling) எளிதாக்குகிறது, ஏனெனில் நீங்கள் பெரிய இயந்திரங்களுக்கு மேம்படுத்துவதற்குப் பதிலாக, அதிக கன்டெய்னர்களை (containers) உருவாக்குவதன் மூலம் திறனை அதிகரிக்கலாம்.

முக்கியமான அமைப்புகளுடன் இணைக்கவும்

தனிமைப்படுத்தப்பட்ட ஒரு நிறுவன சாட்பாட் தனிமையிலேயே அழிந்துவிடும். பயனர்கள் “எனது ஆர்டர் நிலை என்ன?” என்று தட்டச்சு செய்து, அதற்குப் பதிலாக டிராக்கிங் பக்கத்திற்கான ஒரு பொதுவான இணைப்பைப் பெற விரும்பவில்லை. அது ஏற்கனவே உங்கள் ERP உடன் இணைக்கப்பட்டுள்ளதால், பாட் அவர்களின் ஆர்டர் வரலாற்றைத் தெரிந்து கொள்ள வேண்டும் என்று அவர்கள் விரும்புகிறார்கள். அது உங்கள் CRM-ஐப் படிக்க முடியும் என்பதால், அவர்களின் சப்போர்ட் லெவலை (support tier) அது புரிந்துகொள்ள வேண்டும் என்று அவர்கள் விரும்புகிறார்கள்.

ஒருங்கிணைப்புதான் (Integration) பெரும்பாலான உத்திகள் வெற்றி பெறுவதற்கும் அல்லது தோல்வியடைவதற்கும் காரணமாகிறது. உங்கள் SAP இன்ஸ்டன்ஸ் வாடிக்கையாளர் முதன்மைத் தரவை KUNNR என்ற புலத்தின் கீழ் சேமிக்கலாம், அதே சமயம் Salesforce அதே கருத்தை AccountId என்று அழைக்கிறது. டேட்டா மேப்பிங் (Data mapping) இந்த முரண்பாடுகளைத் தீர்க்கிறது, இதனால் தகவல்கள் அமைப்புகளுக்கு இடையே சீராகப் பாய்கின்றன. பலவீனமான பாயிண்ட்-டு-பாயிண்ட் (point-to-point) ஒருங்கிணைப்புகளை உருவாக்கும் தூண்டுதலைத் தவிர்க்கவும். அதற்குப் பதிலாக, சாட்பாட் அடுக்குக்கும் உங்கள் பேக்எண்ட் பயன்பாடுகளுக்கும் இடையே தரவை இயல்பாக்க (normalize) மிட்ல்வேர் (middleware) அல்லது ஒரு என்டர்பிரைஸ் சர்வீஸ் பஸ்சை (enterprise service bus) பயன்படுத்தவும்.

ஒருங்கிணைப்பு முறைகளை (integration patterns) கவனமாகப் பரிசீலிக்கவும். கணக்கு இருப்பைச் சரிபார்ப்பது போன்ற விரைவான தேடல்களுக்கு சின்க்ரோனஸ் (Synchronous) கோரிக்கைகள் வேலை செய்யும். ஒரு இணக்க அறிக்கையை (compliance report) உருவாக்குவது போன்ற நீண்ட நேரம் எடுக்கும் செயல்முறைகளுக்கு அசின்க்ரோனஸ் (Asynchronous) மெசேஜிங் சிறந்தது. உங்கள் பாட் மெதுவாகப் பதிலளிக்கும் ஒரு லெகசி மெயின்பிரேமிலிருந்து (legacy mainframe) தரவை எடுக்க வேண்டியிருந்தால், உரையாடலின் போது பதிலுக்காகக் காத்திருப்பது பயனர்களை விரக்தியடையச் செய்யும். கோரிக்கையை வரிசையில் (queue) வைக்கவும், பாட் அதை ஏற்றுக்கொண்டதை உறுதிப்படுத்தவும், பணி முடிந்ததும் ஒரு அறிவிப்பை (notification) அனுப்பவும்.

சூழல், இன்டென்ட் மற்றும் உரையாடல் ஓட்டம்

பயனர்கள் துண்டு துண்டான சொற்களில் பேசுகிறார்கள். அவர்கள் “எனது வியாழக்கிழமை விஷயத்தை வெள்ளிக்கிழமைக்கு மாற்ற வேண்டும்” என்று தட்டச்சு செய்து, பாட் அதைப் புரிந்துகொள்ள வேண்டும் என்று எதிர்பார்க்கிறார்கள். இயற்கை மொழி செயலாக்கம் (Natural Language Processing) இன்டென்ட்டை (intent) — அதாவது ஒரு சந்திப்பை மறுசீரமைத்தல் — கண்டறிவதன் மூலமும், தேதிகள் மற்றும் நிகழ்வின் பெயர்கள் போன்ற என்டிட்டிகளை (entities) பிரித்தெடுப்பதன் மூலமும் இதைச் செய்கிறது. ஆனால் இன்டென்ட் அங்கீகாரம் (intent recognition) மட்டும் போதாது. ஒரு வங்கி பாட் “எனது இருப்பைச் சரிபார்க்கவும்” மற்றும் “எனது இருப்பை மாற்றவும்” ஆகியவற்றிற்கு இடையே வேறுபாட்டைக் கண்டறிய வேண்டும். உரையாடலின் முந்தைய பகுதியிலிருந்து கிடைக்கும் சூழல் (context) குழப்பத்தைத் தவிர்க்க உதவுகிறது.

மெஷின் லேர்னிங் (Machine Learning) காலப்போக்கில் செயல்திறனை மேம்படுத்துகிறது, ஆனால் நீங்கள் ஃபீட்பேக் லூப்பை (feedback loop) மூடினால் மட்டுமே அது சாத்தியம். பாட் தவறாகப் புரிந்துகொண்ட உரையாடல்களைப் பதிவு செய்து (log), அவற்றை ஆய்வு செய்து, உங்கள் மாடல்களை மீண்டும் பயிற்றுவிக்கவும் (retrain). உங்களிடம் வலுவான பாதுகாப்பு வழிமுறைகள் (guardrails) இல்லையென்றால், தானாக உருவாக்கப்பட்ட பதில்களை (autogenerated responses) மட்டுமே நம்பியிருக்க வேண்டாம். நிறுவனப் பயன்பாட்டிற்கு, ஒரு கலப்பு அணுகுமுறை (hybrid approach) பெரும்பாலும் சிறப்பாகச் செயல்படும்: ஒழுங்குபடுத்தப்பட்ட தலைப்புகளுக்குத் தரவு மீட்டெடுப்பு அடிப்படையிலான பதில்கள் (retrieval-based responses) மற்றும் படைப்பாற்றல் பாதுகாப்பான இடங்களில் கட்டுப்படுத்தப்பட்ட உருவாக்கும் திறன்கள் (constrained generative capabilities) ஆகியவற்றைப் பயன்படுத்தலாம்.

டயலாக் மேனேஜ்மென்ட் (Dialogue management) பல சுற்றுகள் கொண்ட உரையாடல்களைத் தர்க்கரீதியாக வைத்திருக்கிறது. பாட் ஒரு தேதியைக் கேட்டால் மற்றும் பயனர் “உண்மையில், அடுத்த வாரம் செய்வோம்” என்று பதிலளித்தால், ஏற்கனவே சேகரிக்கப்பட்டதை மறக்காமல் சிஸ்டம் அந்த ஸ்லாட்டை (slot) புதுப்பிக்க வேண்டும். தடையின்றி அடுத்த நிலைக்குச் செல்லும் (escalate gracefully) மாற்று வழிகளை (fallbacks) உருவாக்கவும். நம்பிக்கைப் புள்ளிகள் (confidence scores) ஒரு குறிப்பிட்ட அளவை விடக் குறையும் போது, பயனரை ஒரு மனித முகவரிக்கு (human agent) மாற்றவும் மற்றும் உரையாடல் வரலாற்றைப் (transcript) பாதுகாக்கவும், இதனால் அந்த மாற்றம் தடையின்றித் தொடர்ச்சியாக உணரப்படும், அதிர்ச்சியாக இருக்காது.

வடிவமைப்பிலேயே பாதுகாப்பு மற்றும் இணக்கம்

நிறுவன சாட்போட்கள் (Enterprise chatbots) தனிப்பட்ட அடையாளத் தகவல்கள், கட்டண விவரங்கள், சுகாதாரப் பதிவுகள் மற்றும் உரிமம் பெற்ற வணிகத் தரவுகளைக் கையாளுகின்றன. சேமிக்கப்பட்டிருக்கும் (at rest) உரையாடல் விவரங்கள் மற்றும் அமர்வுத் தரவுகளை (session data) AES மூலம் குறியாக்கம் (encrypt) செய்யவும். பரிமாற்றத்தின் போது (in transit) தரவுகளை TLS மூலம் பாதுகாக்கவும், தேவைப்படும் இடங்களில் சாவி பரிமாற்றத்திற்கு (key exchange) RSA-வைப் பயன்படுத்தவும். இவை அடிப்படைத் தேவைகளே தவிர, மேம்பட்ட அம்சங்கள் அல்ல.

ஒழுங்குமுறை இணக்கம் (Regulatory compliance) என்பது தவிர்க்க முடியாதது. நீங்கள் ஐரோப்பாவில் செயல்படுகிறீர்கள் என்றால், GDPR-ன் படி பயனர்கள் தங்கள் உரையாடல் வரலாற்றை நீக்கக் கோரலாம், மேலும் அந்தத் தரவு சரியாக எங்குள்ளது என்பதை நீங்கள் அறிந்திருக்க வேண்டும். சுகாதாரத் துறையில், HIPAA இணக்கத்திற்கு தணிக்கைப் பதிவுகள் (audit trails), அணுகல் கட்டுப்பாடுகள் (access controls) மற்றும் சம்பந்தப்பட்ட விற்பனையாளர்களுடன் வணிகக் கூட்டாளர் ஒப்பந்தங்கள் (business associate agreements) தேவைப்படுகின்றன. பின்னர் மாற்றியமைப்பதற்குப் பதிலாக, முதல் நாளிலிருந்தே கட்டமைப்பிலேயே (architecture) தனியுரிமையை (privacy) இணைத்து உருவாக்குங்கள்.

பங்கு அடிப்படையிலான அணுகல் கட்டுப்பாடு (Role-Based Access Control) அமைப்பிற்குள் யார் எதைப் பார்க்க வேண்டும் என்பதைத் தீர்மானிக்கிறது. ஒரு வாடிக்கையாளர் சேவைப் பிரதிநிதி டிக்கெட் வரலாற்றைப் பார்க்கலாம், ஆனால் அவர்கள் HR அமைப்பிலிருந்து சம்பளத் தரவுகளைப் பார்க்கக்கூடாது. சாட்போட் அணுகும் ஒவ்வொரு API endpoint-க்கும் 'குறைந்தபட்ச அதிகாரக் கொள்கையை' (principle of least privilege) பயன்படுத்தவும்.

பயனர் உள்ளீட்டை (user input) ஒருபோதும் நம்பாதீர்கள். ஒரு சாட் விண்டோ என்பது மற்றொரு தாக்குதல் வழி (attack vector) ஆகும். இன்ஜெக்ஷன் தாக்குதல்களைத் (injection attacks) தடுக்க ஒவ்வொரு சரத்தையும் (string) சரிபார்க்கவும் மற்றும் தூய்மைப்படுத்தவும் (sanitize). “Show me my balance; DROP TABLE users--” என்று ஒரு பயனர் கேட்டால், அது ஒரு பதிவு செய்யப்பட்ட பிழையாக (logged error) இருக்க வேண்டுமே தவிர, தரவுத்தளப் பேரழிவாக (database disaster) இருக்கக்கூடாது. பிழைத்திருத்தம் (debugging) தரவு கசிவாக மாறாமல் இருக்க, உங்கள் பதிவுகளில் (logs) PII-ஐ மறைக்கவும் (mask).

பயனர்கள் இருக்கும் இடத்திலேயே அவர்களைச் சந்தியுங்கள்

உங்கள் ஊழியர்களும் வாடிக்கையாளர்களும் ஒரே திரையுடன் மட்டும் நின்றுவிடுவதில்லை. அவர்கள் நிறுவனத்தின் Slack workspace-இல் உரையாடலைத் தொடங்கி, மொபைல் செயலியில் தொடரலாம், மேலும் டெஸ்க்டாப் பிரவுசர் மூலம் அதை முடிக்கலாம். உங்கள் பேக்எண்ட் கட்டமைப்பு (backend architecture), அனுபவத்தைப் பிரிக்காமல் (fragmenting) இந்த அனைத்து சேனல்களுக்கும் சேவை செய்ய வேண்டும்.

ஒருமைப்பாடு (Consistency) என்பது ஒரே மாதிரியான இடைமுகங்களைக் (interfaces) குறிப்பதல்ல. WhatsApp விரைவான பதில் பொத்தான்கள் (quick reply buttons) மற்றும் வரையறுக்கப்பட்ட ரிச் மீடியாவை (rich media) ஆதரிக்கிறது. ஒரு இணையத் தளம் (web portal) கேரௌசல்கள் (carousels), உட்பொதிக்கப்பட்ட படிவங்கள் (embedded forms) மற்றும் தனிப்பயன் ஸ்டைலிங் ஆகியவற்றைக் காட்டலாம். உரையாடல் தர்க்கம் (conversation logic) ஒன்றாகவே இருக்க வேண்டும், ஆனால் சேனல் அடாப்டர்கள் (channel adapters) பொருத்தமான வடிவத்தில் அதைக் காட்ட வேண்டும். பயனர் iOS செயலியில் இருந்து இணைய டேஷ்போர்டிற்கு மாறும்போது, அவர்கள் எதைப் பற்றி விவாதித்துக் கொண்டிருந்தார்கள் என்பதை சாட்போட் அறியும் வகையில், அமர்வு நிலையை (session state) மையமாகப் பராமரிக்கவும்.

வரும் செய்திகளைத் புத்திசாலித்தனமாக வரிசைப்படுத்தவும் (Queue). இணையத் தொடர்பு மெதுவாக இருப்பதால் ஒரு பயனர் மொபைலில் மூன்று விரைவான செய்திகளை அனுப்பினால், உங்கள் அமைப்பு அவற்றை வரிசைப்படி கையாள வேண்டும் மற்றும் முரண்பட்ட பதில்களைத் தவிர்க்க வேண்டும்.

உத்தியைச் செயல்பாட்டிற்கு கொண்டு வருதல்

குறுகிய எல்லையுடன் தொடங்குங்கள். கடவுச்சொல் மீட்டமைப்பு (password resets), ஆர்டர் கண்காணிப்பு (order tracking) அல்லது உள் ஐடி உதவி மையம் (internal IT help desk) கோரிக்கைகள் போன்ற ஒரு உயர் மதிப்புள்ள பயன்பாட்டுச் சூழலைத் (use case) தேர்ந்தெடுத்து, அதை முழுமையாகத் தீர்க்கவும். ஒரே நேரத்தில் அனைத்தையும் செய்ய முயற்சிக்கும் ஒரு சாட்போட்டை பிழைத்திருத்தம் செய்வதை விட, ஒரு குறிப்பிட்ட இலக்கை நோக்கிச் செயல்படும் அமைப்பை விரிவுபடுத்துவது எளிது.

விற்பனையாளர்களை (vendors) மதிப்பீடு செய்வதற்கு முன் தொழில்நுட்பக் கட்டமைப்பை வடிவமைக்கவும். உங்கள் ஒருங்கிணைப்புப் புள்ளிகள் (integration points), உங்கள் விரிவாக்க இலக்குகள் (scaling targets) மற்றும் உங்கள் தரவு எல்லைகளைத் (data boundaries) தெரிந்து கொள்ளுங்கள். ஒரு கவர்ச்சிகரமான தளத்தைச் சுற்றி உங்கள் நிறுவனத்தை மாற்றியமைப்பதற்குப் பதிலாக, அந்த வடிவமைப்பிற்குப் பொருந்தக்கூடிய கருவிகளைத் தேர்ந்தெடுக்கவும்.

உங்கள் CRM மற்றும் ERP உடன் ஆரம்பத்திலேயே ஒருங்கிணைக்கவும். உங்கள் சாட்போட் நேரடித் தரவை (live data) எவ்வளவு விரைவாகப் பெறுகிறதோ, அவ்வளவு விரைவாக அது உண்மையான மதிப்பை வழங்கும். பாதுகாப்பை வெறும் பயன்பாட்டுப் பட்டியல் (deployment checklist) உருப்படியாக மட்டும் கருதாதீர்கள். RBAC, குறியாக்கம் (encryption) மற்றும் இணக்க விதிகளை உருவாக்கப்படும் நிலையிலேயே (build phase) செயல்படுத்தவும், இதனால் அவை தானியங்கி சோதனைகளில் (automated tests) ஒருங்கிணைக்கப்படும்.

தொடங்குவதற்கு முன் யதார்த்தமான போக்குவரத்துத் தரவுகளுடன் (traffic profiles) லோட் டெஸ்ட் (load test) செய்யவும். திங்கட்கிழமை காலை நெரிசல் அல்லது காலாண்டுப் பயன்கள் பதிவுச் சரிவு போன்றவற்றைச் செயற்கையாக உருவாக்கிச் சோதிக்கவும். பயன்பாட்டிற்குப் பிறகு, உரையாடல் நிறைவு விகிதங்கள், சராசரி பதிலளிப்பு தாமதம் (latency) மற்றும் பிழை சதவீதங்களைக் கண்காணிக்கவும். செயல்திறன் தடைகள் (Performance bottlenecks) அரிதாகவே முன்னறிவிக்கப்படும்; அவை சிக்கலான, பல நோக்கங்களைக் கொண்ட கேள்விகளைக் கேட்கும் பயனர்களுக்குத் தாமதமான பதில்களை வழங்குவதன் மூலம் வெளிப்படும்.

உண்மையான முடிவுரை

ஒரு நிறுவன சாட்போட் அதன் பின்னால் உள்ள உத்தியைப் பொறுத்தே வலிமையானது. உரையாடலின் கவர்ச்சி என்பது பலவீனமான கட்டமைப்பு, கசிவு உள்ள ஒருங்கிணைப்புகள் அல்லது புறக்கணிக்கப்பட்ட இணக்க விதைகளுக்கு ஈடாகாது. முதலில் அடிப்படை கட்டமைப்பை (plumbing) உருவாக்குங்கள். அதை உண்மையான தரவுகளுடன் இணைக்கவும். அதை ஒரு வணிக ரீதியாக முக்கியமான அமைப்பு போலப் பாதுகாக்கவும். பின்னர் உரையாடலைச் செம்மைப்படுத்தவும். அடித்தளத்தைச் சரியாக அமைத்துவிட்டால், சாட்போட் அதன் வேகத்தைக் குறைக்காமல் அளவிடுதல் (scale), சிக்கல்தன்மை மற்றும் பயனர் எதிர்பார்ப்புகளைக் கையாண்டுவிடும்.