Voice has become the feature every AI agent platform rushes to ship. The obvious move is to build it as a standalone cha

குரல் (Voice) என்பது ஒவ்வொரு AI ஏஜென்ட் தளமும் விரைவாக வெளியிடுவதற்குத் துடிக்கும் ஒரு அம்சமாகிவிட்டது. இதை உங்கள் வெப் ஆப் (web app), CLI கருவி அல்லது டெலிகிராம் பாட் (Telegram bot) ஆகியவற்றிற்குப் பக்கபலமாக ஒரு தனித்த சேனலாக (standalone channel) உருவாக்குவதே இயல்பான நகர்வாகத் தோன்றுகிறது. இது உள்ளுணர்வாகத் தோன்றலாம். குரல் அம்சத்தைக் கண்டால், ஒரு குரல் இடைமுகத்தை (voice interface) உருவாக்கிவிடலாம் என்று நினைக்கலாம். ஆனால் அந்த உள்ளுணர்வு ஒரு பலவீனமான கட்டமைப்பை (brittle architecture) உருவாக்குகிறது. இது வேலையை இரட்டிப்பாக்குகிறது, உங்கள் லாக்ஸ்களை (logs) சிதைக்கிறது மற்றும் மெதுவாக உங்கள் திட்டத்தின் சூழலை (project context) சிதறடிக்கிறது.

APC மற்றும் APX இல், நாங்கள் ஒரு மாறுபட்ட பாதையைத் தேர்ந்தெடுத்தோம். குரல் என்பது ஒரு சேனல் அல்ல. அது ஒரு முறை (mode). அது ஒரு சர்பேஸிற்கு (surface) மாற்றாக இல்லாமல், அதன் மேல் அமைகிறது. இந்த வேறுபாட்டைச் சரியாகப் புரிந்துகொள்வதே, சிஸ்டம் சிதறிப்போகாமல் தடுப்பதாகும்.

தவறான அருவமாக்கல் (The Wrong Abstraction)

குரலை ஒரு தனி சேனலாகக் கையாளும்போது, ஒரு ஏஜென்ட்டிடம் பேசுவது, அவரிடம் தட்டச்சு செய்வதிலிருந்து முற்றிலும் மாறுபட்ட உரையாடல் என்று நீங்கள் மறைமுகமாக ஊகிக்கிறீர்கள். இதற்குப் பொறியியல் குழுக்கள் கோட்பேஸை (codebase) பிரிப்பதன் மூலம் பதிலளிக்கின்றன. திடீரென்று ஒரு CLI சேனலும், ஒரு தனி வாய்ஸ்-CLI சேனலும் உருவாகின்றன. ஒரு வெப் சேனலும், அதற்கு இணையாக ஒரு வாய்ஸ்-வெப் சேனலும் உருவாகின்றன. ஒவ்வொன்றும் அதற்கெனத் தனித்த ப்ராம்ப்ட் மாறுபாடுகள் (prompt variations), வடிவமைப்புக் விதிகள் மற்றும் சூழல் கையாளுதல் தர்க்கங்களைக் (context handling logic) கோருகின்றன.

இங்கிருந்துதான் குழப்பம் தொடங்குகிறது. ஒரு ஏஜென்ட்டின் நடத்தையில் செய்யப்படும் ஒரு சிறிய மாற்றம், இப்போது பல ப்ராம்ப்ட் மரங்களில் (prompt trees) நகலெடுக்கப்பட வேண்டும். குழு ஒரு சர்பேஸைத் தவறவிட்டால், அனுபவம் துண்டு துண்டாகப் பிரியும். பயனர்கள் உரையாடலில் ஒரு தொனியையும், பேச்சில் சற்று மாறுபட்ட ஆளுமையையும் பெறுவார்கள். காலப்போக்கில், இந்தச் சிறிய முரண்பாடுகள் சிஸ்டம் விலகலுக்கு (system drift) வழிவகுக்கும். ஒரு கிளையில் குரல் வழி விநியோகத்தையும், மற்றொரு கிளையில் அமைதியான உரையைத் (silent text) தழுவிக்கொள்ள வேண்டியிருப்பதால், எளிதில் மாற்றக்கூடிய சூழல் அடுக்கு (portable context layer) அதன் தன்மையை இழக்கிறது. இந்த அப்ஸ்ட்ராக்ஷன் கசிகிறது (abstraction leaks), மேலும் உங்கள் ஒருகாலத்தில் ஒருங்கிணைந்திருந்த திட்ட வரையறை, சேனல் சார்ந்த தற்காலிகத் தீர்வுகளின் (hacks) தொகுப்பாகச் சிதறுகிறது.

சூழலையும் (Context) ரன்டைமையும் (Runtime) பிரித்தல்

இதைத் தடுக்க, நாங்கள் இரண்டு அடுக்குகளுக்கு இடையே பொறுப்புகளைத் துல்லியமாகப் பிரிக்கிறோம்.

APC திட்டத்தின் சூழலை (project context) வைத்திருக்கிறது. இது ஒரு திட்டத்தை உருவாக்கும் ஏஜென்ட்கள், விதிகள் மற்றும் திறன்களை வரையறுக்கிறது. இதை அமைப்பின் நிலையான பொருளாகக் கருதலாம். இது கட்டமைப்பு சார்ந்த கேள்விகளுக்குப் பதிலளிக்கிறது: இந்த ஏஜென்ட் என்ன জানে? அதற்கு என்ன செய்ய அனுமதி உண்டு? அது எந்தக் கருவிகளை அழைக்க முடியும்? ஒரு பதில் திரையில் காட்டப்படுகிறதா, சாட் API மூலம் அனுப்பப்படுகிறதா அல்லது ஸ்பீக்கர் வழியாகச் செல்கிறதா என்பது குறித்து APC முற்றிலும் நடுநிலையாக (agnostic) இருக்க வேண்டும்.

APX ரன்டைம் அடுக்கைக் கையாள்கிறது. நீங்கள் உண்மையில் பயன்படுத்தும் சர்பேஸ்களை இது நிர்வகிக்கிறது: CLI, வெப் அப்ளிகேஷன், டெஸ்க்டாப் இடைமுகம், டெலிகிராம் பாட் போன்றவை. ஒரு பயனர் கோரிக்கையை அனுப்பும்போது, அந்தப் பதிலை எங்கே மற்றும் எப்படி வழங்க வேண்டும் என்பதை APX தீர்மானிக்கிறது. ஒரு பதிலை வாசிப்பதற்கு ஏற்றவாறு வடிவமைப்பதா அல்லது பேசுவதற்கு ஏற்றவாறு மேம்படுத்துவதா என்பதைத் தீர்மானிப்பது ஒரு ரன்டைம் சார்ந்த விஷயம். அது APX-இல் இருக்க வேண்டுமே தவிர, APC-இல் அல்ல.

இந்தத் தனிப்பயனாக்கம், APC இல் வரையறுக்கப்பட்ட ஒரு திட்டம், APX எத்தனை சர்பேஸ்களை வெளிப்படுத்தினாலும் அப்படியே இருக்கும் என்பதை உறுதி செய்கிறது. ஒப்பந்தம் (contract) மாறாது. அதன் காட்சிப்படுத்தல் அடுக்கு (presentation layer) மட்டுமே மாறும்.

முறைகள் (Modes) உண்மையில் எவ்வாறு செயல்படுகின்றன

எங்களது செயல்பாட்டில், டெலிகிராம், CLI மற்றும் வெப் ஆப் போன்ற சர்பேஸ்கள் சேனல்கள் ஆகும். ஒரு சேனல் ஒரு உரையாடல் எங்கே நடந்தது என்பதை உங்களுக்குச் சொல்கிறது. குரல் என்பது சேனல் மெட்டாடேட்டா (metadata) மூலம் ஒரு முறையாக (mode) சேர்க்கப்படுகிறது. ஒரு முறை ஒரு பதில் எவ்வாறு செயல்பட வேண்டும் என்பதை உங்களுக்குச் சொல்கிறது.

ப்ராம்ப்ட் பில்டர் (prompt builder) இந்த எல்லையை மதிக்கிறது. அது APC இல் உள்ள திட்டச் சூழலில் இருந்து தகவல்களைப் பெற்று, பின்னர் சேனல் மெட்டாடேட்டாவைப் பரிசோதிக்கிறது. டெஸ்க்டாப் சர்பேஸ் வாய்ஸ் மோடில் இயங்கினால், பில்டர் அந்தத் தருணத்தில் மட்டும் இலக்கு வைக்கப்பட்ட அறிவுறுத்தல்களைச் சேர்க்கிறது. ஒருவேளை அது மாடலுக்குக் குறுகிய வாக்கியங்கள், தெளிவான நிறுத்தற்குறிகள் அல்லது பேசும் எண் முறைகளைப் பயன்படுத்த அறிவுறுத்தலாம். அதே டெஸ்க்டாப் சர்பேஸ் டெக்ஸ்ட் மோடில் இயங்கினால், அந்த குரல் வழி அறிவுறுத்தல்கள் ப்ராம்ப்ட்டிற்குள் வராது.

இதன் முடிவு ஒரு சர்பேஸிற்கு ஒரு தனி ப்ராம்ப்ட் மரம் மட்டுமே. தனியான வாய்ஸ்-டெஸ்க்டாப் கிளை என்று எதுவும் இல்லை. தனியான whisper-web மாறுபாடு என்று எதுவும் இல்லை. ரன்டைம் கேட்கும்போது மட்டுமே, கடைசித் தருணத்தில் மட்டும் இந்தத் திருத்தம் (modifier) பயன்படுத்தப்படுகிறது. முக்கிய ப்ராம்ப்ட் மாறாமல் இருக்கும்.

நீங்கள் எதைப் பெறுகிறீர்கள்

இந்தக் கட்டமைப்பு மூன்று உறுதியான வழிகளில் பலன் அளிக்கிறது.

குறைந்த பராமரிப்புச் செலவு. குரல் என்பது ஒரு தனி சேனலாக இருந்தால், ஒவ்வொரு சர்பேஸிற்கும் ஒரு இரட்டைச் சர்பேஸ் தேவைப்படும். நீங்கள் ஒரு CLI சேனலையும் ஒரு வாய்ஸ்-CLI சேனலையும், ஒரு டெலிகிராம் சேனலையும் ஒரு வாய்ஸ்-டெலிகிராம் சேனலையும் என ஒவ்வொன்றையும் பராமரிக்க வேண்டியிருக்கும். ஒவ்வொரு முறையும் நீங்கள் ஒரு சிஸ்டம் ப்ராம்ப்ட்டை மாற்றும்போதோ, ஒரு வடிவமைப்புக் பிழையைச் சரிசெய்யும்போதோ அல்லது ஒரு திறனின் விளக்கத்தை மேம்படுத்தும்போதோ, அந்த மாற்றத்தை இரண்டு மரங்களிலும் நீங்கள் கொண்டு செல்ல வேண்டும். ஒன்றைச் செய்யத் தவறினால், பயனர்கள் அந்த இடைவெளியைக் கண்டறிந்துவிடுவார்கள். ஒரு முறையைப் (mode) பயன்படுத்துவதன் மூலம், நீங்கள் ஒரு சர்பேஸிற்கு ஒரு ப்ராம்ப்ட் மரத்தை மட்டுமே வைத்திருக்கிறீர்கள். குரல் என்பது ஒரு புதிய பாதையாக இல்லாமல், ஒரு நிபந்தனைக்குட்பட்ட மேலடுவாக (conditional overlay) மாறுகிறது, எனவே நீங்கள் புதிய தொடர்பு முறைகளைச் சேர்க்கும்போது உங்கள் வேலைப்பளு நேரியல் முறையில் (linear) இருக்கும்.

துல்லியமான பதிவேற்றம். சேனல்கள் (Channels) ஒரு உரையாடல் எங்கு நடந்தது என்பதைப் பதிவு செய்கின்றன. முறைகள் (Modes) பதில் எவ்வாறு வழங்கப்பட்டது என்பதைப் பதிவு செய்கின்றன. பயனர் அதை வாசித்தாலும் அல்லது கேட்டாலும், டெஸ்க்டாப் உரையாடல் என்பது டெஸ்க்டாப் உரையாடலாகவே இருக்கும். உங்கள் குழு ஒரு பிழையைத் (bug) தேடும்போது அல்லது பகுப்பாய்வுகளை (analytics) ஆய்வு செய்யும்போது, அவை வெவ்வேறு தயாரிப்பு தளங்களாகக் கருதி "desktop-voice" மற்றும் "desktop-text" ஆகியவற்றை ஒப்பிட்டுச் சரிசெய்ய வேண்டிய அவசியமில்லை. சேனல் அடையாளம் (channel identifier) தெளிவாக இருக்கும், மேலும் முறைக் குறியீடு (mode flag) மெட்டாடேட்டாவில் (metadata) அதன் அருகில் நேர்த்தியாக இருக்கும். இடம் மற்றும் செயல்பாடு ஆகியவை ஒன்றோடொன்று கலக்காததால், உங்கள் பதிவுகள் உண்மையாக இருக்கும் மற்றும் பிழைத்திருத்தம் (debugging) எளிமையாக இருக்கும்.

தெளிவான திட்டச் சூழல். APC ஒப்பந்தத்தை (contract) வரையறுக்கிறது. பதில் பேசப்பட்டதா, கிசுகிசுக்கப்பட்டதா அல்லது மோனோஸ்பேஸ் (monospace) எழுத்துருவில் காட்டப்பட்டதா என்பதை அது கவலைப்படத் தேவையில்லை. அவை ரன்டைம் (runtime) சார்ந்த விஷயங்கள். குரல் வடிவமைப்பை (voice formatting) APX-க்குள் வைத்திருப்பதன் மூலம், APC-இன் இடமாற்றத் திறனை (portability) நாங்கள் பாதுகாக்கிறோம். குரல் சார்ந்த வடிவமைப்பு அனுமானங்கள் அல்லது பேச்சு-மேம்படுத்தல் தேவையற்ற சிக்கல்களை (speech-optimization cruft) இழுத்துச் செல்லாமல், ஒரு APC திட்ட வரையறையை எடுத்து முற்றிலும் புதிய ரன்டைம் சூழலில் பயன்படுத்த முடியும். எல்லை மாறாமல் இருக்கும், மேலும் திட்டத்தின் பொருள் நிலையாக இருக்கும்.

டெஸ்க்டாப்பில் உள்ள சான்று

எங்களது சொந்த டெஸ்க்டாப் வழிமுறை இதை அன்றாடப் பயன்பாட்டில் நிரூபிக்கிறது. டெஸ்க்டாப் என்பது ஒரு தளம் (surface). ஒரு பயனர் பேச்சை (speech) இயக்கும்போது, கணினி அதே டெஸ்க்டாப் தளத்தை குரல் முறையில் (voice mode) இயக்குகிறது. குரல் என்பது முறைக் அடுக்கில் (mode layer) இருப்பதால், டெஸ்க்டாப் சேனல் அதன் முழுமையான சூழலையும் நடத்தையையும் தக்க வைத்துக் கொள்கிறது. அது வெவ்வேறு விதிகளுடன் கூடிய ஒரு வேறுபட்ட தயாரிப்பாக மாறிவிடாது. பிராம்ட் பில்டர் (prompt builder) அந்தத் குறியீட்டைக் கவனித்து, தேவைப்படும்போது மட்டும் குரல் வழிமுறைகளைச் சேர்க்கிறது. பயனர் மீண்டும் உரையாக (text) மாற்றும்போது, அந்த வழிமுறைகள் முற்றிலும் மறைந்துவிடும். அடிப்படையான திட்டச் சூழல் ஒருபோதும் மாறவில்லை. டெஸ்க்டாப் எப்போதும் டெஸ்க்டாப்பாகவே இருந்தது.

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

இதன் முக்கியக் கருத்து எளிமையானது. APC நிலையான திட்டப் பொருளை விவரிக்கிறது. APX ரன்டைம் செயல்பாட்டை விவரிக்கிறது. குரல் என்பது ஒரு தளத்தின் மாற்றி (modifier) மட்டுமே, அதற்கு மாற்றானது அல்ல. அதை அவ்வாறே அணுகினால், உங்கள் பிராம்ட்கள் (prompts) சிறியதாக இருக்கும். உங்கள் பதிவுகள் தெளிவாக இருக்கும். உங்கள்