வாடிக்கையாளர் சார்ந்த AI அவதாரங்களை (avatars) உருவாக்கும் டெவலப்பர்கள் ஒரு முக்கியமான தடையை எதிர்கொள்கிறார்கள்: பெரிய மொழி மாதிரிகள் (LLMs) பிதற்றாமல் (hallucinating) தடுப்பது. ஒரு சரளமான குரல், ஒரு சாதாரணத் தவறை கூட நம்பகமான பொய்யாக மாற்றிவிடக்கூடும், இது பிராண்ட் மீதான நம்பிக்கையைச் சிதைப்பதோடு நிறுவனங்களை ஒழுங்குமுறை அபாயங்களுக்கும் (regulatory risk) உள்ளாக்கும்.
பிதற்றல்கள் (hallucinations) ஏன் முக்கியம்
ஒரு அடிப்படை சிஸ்டம் பிராம்ப்ட் (system prompt) இருந்தாலும் கூட, ஒரு நேரடி LLM அழைப்பு பெரும்பாலும் விலை, கொள்கை அல்லது தயாரிப்பு அம்சங்கள் குறித்த விவரங்களைத் தவறாகக் கற்பனை செய்து கூறுகிறது. ஒரு இயற்கையான குரல் கொண்ட அவதாரம் பதிலளிக்கும் போது, பயனர்கள் அதைச் சந்தேகிக்க வாய்ப்பு குறைவு. பிரச்சனை குரல் தொகுப்பு (voice synthesis) அல்லது காட்சித் தரத்தில் (visual rendering) இல்லை; மாறாக, தகவல்கள் இல்லாத இடங்களை நம்பிக்கையான தொனியில் அர்த்தமற்ற தகவல்களால் நிரப்பும் மாதிரியின் (model) பழக்கமே பிரச்சனை. வங்கிகள், காப்பீட்டு நிறுவனங்கள், தொலைத்தொடர்பு நிறுவனங்கள் மற்றும் துல்லியமான தகவல்களைச் சார்ந்திருக்கும் எந்தவொரு வணிகத்திற்கும், ஒரு தவறான பதில் புகார்கள், பணத்தைத் திரும்பப் பெறுதல் அல்லது சட்ட நடவடிக்கைகளுக்கு வழிவகுக்கும்.
மூன்று படிநிலை பாதுகாப்பு வழிமுறைகள் (guardrail)
1. கடுமையான Retrieval-Augmented Generation (RAG)
RAG என்பது LLM-ஐ ஒரு தொகுக்கப்பட்ட அறிவுத் தளத்துடன் (knowledge base) இணைத்து, மாதிரி ஒரு பதிலை உருவாக்குவதற்கு முன் தொடர்புடைய ஆவணங்களைப் பெறுகிறது. இதன் முக்கிய அம்சம் தெளிவான மாற்று வழிமுறைகளை (fallback instructions) கட்டாயப்படுத்துவதாகும்: யூகிக்காமல், "எனக்குத் தெரியாது" என்று பதிலளிக்க மாதிரியிடம் கூற வேண்டும். மாதிரியின் "உதவும்" (helpfulness) பழக்கத்தை மட்டுமே நம்பியிருக்கும் மறைமுகமான பிராம்ப்ட்கள் தோல்வியடைகின்றன, ஏனெனில் பெறப்பட்ட தரவு பொருத்தமற்றதாக இருந்தாலும் LLM பதிலளிக்கவே முயற்சிக்கும்.
2. நம்பிக்கைத் தரம் நிர்ணயித்தல் (Confidence thresholding)
பயனர் வினவலை LLM பார்ப்பதற்கு முன்பே, பெறப்பட்ட தகவல்களின் பொருத்தப்பாட்டை மதிப்பிடவும். அந்தப் பொருத்தம் முன்கூட்டியே நிர்ணயிக்கப்பட்ட நம்பிக்கை அளவை விடக் குறைவாக இருந்தால், பதிலைத் தயாரிக்கும் படிநிலையைத் தடுத்து நிறுத்தவும். பயனரை ஒரு மனித உதவியாளருக்கோ அல்லது லீட்-கேப்சர் (lead-capture) படிவத்திற்கோ மாற்றவும். இது தவறான தகவல்களைத் தடுப்பதோடு, தேவையற்ற LLM அழைப்புகளைத் தவிர்ப்பதன் மூலம் கணினிச் செலவையும் (compute costs) மிச்சப்படுத்துகிறது.
3. மென்மையான மாற்றங்கள் (Graceful handoffs)
வெற்றிகரமான பாதையைப் போலவே, தோல்விப் பாதையையும் நேர்த்தியாக வடிவமைக்கவும். குறைந்த நம்பிக்கையுடன் கூடிய பதில்களைக் கண்டறிந்து, அவற்றைச் சேமித்து (log), அறிவுத் தளத்தில் உள்ள இடைவெளிகளைக் கண்டறிய அந்தத் தரவைப் பயன்படுத்தவும். பின்னர், ஒரு மனித இயக்குநருக்குத் தெளிவான மேல்நிலை வழிமுறையை (escalation route) உருவாக்கவும். AI ஆல் பதிலளிக்க முடியாத சூழலிலும், ஒரு முறையான மாற்றம் (handoff) பயனர் அனுபவத்தைப் பாதுகாக்கிறது.
அவதார் தளங்களைச் சரிபார்க்கும் போது என்ன கேட்க வேண்டும்?
நீங்கள் HeyGen அல்லது D-ID போன்ற சேவைகளை ஒப்பிடும்போது, அவற்றின் பிதற்றல் பாதுகாப்பு வழிமுறைகளை (hallucination safeguards) ஆராயுங்கள்:
- இந்த அமைப்பு பதில்களை ஒரு குறிப்பிட்ட அறிவுத் தளத்திற்குள் மட்டுப்படுத்துகிறதா?
- நம்பிக்கை குறையும் போது இது எவ்வாறு செயல்படுகிறது—மௌனமாக இருக்கிறதா, பிதற்றுகிறதா அல்லது மனிதரிடம் மாற்றுகிறதா?
- குறைந்த நம்பிக்கையுடன் கூடிய உரையாடல்களைப் பதிவு செய்து மேம்படுத்த என்ன வழிமுறைகள் உள்ளன?
குரல் தரம் என்பது இனி ஒரு தனித்துவமான காரணியல்ல; அவதாரத்தை உண்மையாக வைத்திருக்கும் திறனே முக்கியமானது.
சுருக்கம் (Takeaway)
கேட்க மிகச் சிறப்பாக இருந்து, ஆனால் உண்மைகளைத் தவறாகக் கூறும் ஒரு AI அவதாரம் ஒரு சுமையாகும் (liability). மாதிரியைச் சரிபார்க்கப்பட்ட அறிவுத் தளத்துடன் இணைப்பதன் மூலமும், நம்பிக்கை குறைவாக இருக்கும்போது பதிலளிக்க மறுப்பதன் மூலமும், தோல்விகளை மனித உதவியாளர்களிடம் மாற்றுவதன் மூலமும், டெவலப்பர்கள் ஒரு வசீகரமான குரலை நம்பகமான ஒன்றாக மாற்ற முடியும். ஒரு அமைப்பின் பேச்சு எவ்வளவு இயற்கையாக இருக்கிறது என்பதிலல்ல, அது பிதற்றல்களை எவ்வளவு சிறப்பாகத் தடுக்கிறது என்பதில்தான் உண்மையான போட்டித்தன்மை உள்ளது.
