உங்கள் ஆப்பில் AI அம்சங்களைச் சேர்ப்பது எப்படி
ஆப்பில் AI அம்சங்களைச் சேர்க்க, உங்கள் server-இலிருந்து ஒரு large language model (LLM) API-ஐ அழையுங்கள்: அதற்குத் தெளிவான அறிவுறுத்தல்களையும் தொடர்புடைய டேட்டாவையும் அனுப்பி, திரும்ப வருவதைப் பயன்படுத்துங்கள். பயனுள்ள அம்சங்கள் பெரும்பாலானவை நான்கு வடிவங்களில் ஒன்று — சுருக்குதல், chat, கட்டமைக்கப்பட்ட டேட்டா extraction, மற்றும் classification — ஒவ்வொன்றும் சில டஜன் வரிகள் code, அதை ஒரு AI builder எழுதித் தரும். அம்சம் நல்லதா இல்லையா என்பதை முடிவு செய்யும் வேலை, அழைப்பைச் சுற்றியுள்ளதுதான்: API key-ஐ server-இல் வைத்திருப்பது, ஒரு பயனருக்கான செலவைக் கட்டுப்படுத்துவது, நம்புவதற்கு முன் வெளியீட்டைச் சரிபார்ப்பது.
பெரும்பாலான AI அம்சங்களின் பின்னணியில் உள்ள நான்கு வடிவங்கள்
| வடிவம் | அது என்ன செய்கிறது | எடுத்துக்காட்டு அம்சங்கள் | பொதுவான வெளியீடு |
|---|---|---|---|
| சுருக்குதல் | நீண்ட உரையைக் குறுகிய உரையாக மாற்றும் | கூட்டக் குறிப்புகளின் சுருக்கம், ticket சுருக்கம், ஒரு ஆவணத்தின் "என்ன மாறியது" | ஒரு பத்தி அல்லது bullet பட்டியல் |
| Chat | உரையாடலில் கேள்விகளுக்குப் பதில் சொல்லும், பெரும்பாலும் உங்கள் டேட்டா பற்றி | உதவி assistant, "உங்கள் docs-ஐக் கேளுங்கள்", onboarding வழிகாட்டி | Streaming உரை |
| Extract | குழப்பமான உரை அல்லது படங்களில் இருந்து கட்டமைக்கப்பட்ட fields-ஐ எடுக்கும் | PDF-இல் இருந்து invoice விவரங்கள், email கையொப்பத்திலிருந்து தொடர்புகள், ஒரு வேலை விளம்பரத்திலிருந்து வேலைத் தரவு | ஒரு schema-உடன் பொருந்தும் JSON |
| Classify | நிலையான labels தொகுப்பிலிருந்து ஒன்றைத் தேர்ந்தெடுக்கும் | Support tickets-ஐ அனுப்புதல், கருத்துகளை தலைப்பின்படி குறித்தல், அவசரச் செய்திகளைக் கொடியிடுதல், மொழி கண்டறிதல் | ஒரு label, ஒருவேளை நம்பிக்கை குறிப்பு |
Extraction மற்றும் classification பெரும்பாலும் மிக மதிப்புள்ளவை, ஆனால் குறைவாகவே கவனிக்கப்படுபவை. ஒவ்வொரு பதிவுக்கும் யாரோ ஒருவரின் சில நிமிடங்களை அமைதியாக மிச்சப்படுத்துகின்றன, வெளியீட்டின் வடிவம் நிலையானது என்பதால் அதை தானாகச் சரிபார்க்கலாம். Chat மிகவும் தெரியும் அம்சம், ஆனால் சரியாகச் செய்வது கடினம்; அதற்கென தனி வழிகாட்டி உள்ளது: AI chatbot ஆப் உருவாக்குவது எப்படி.
இது உங்கள் ஆப்பில் எப்படிப் பொருந்துகிறது
ஒவ்வொரு வடிவத்துக்கும் ஒரே அமைப்பு:
- பயனர் செயல்படுகிறார் — "சுருக்கு" என்பதை அழுத்துகிறார், ஒரு கோப்பைப் பதிவேற்றுகிறார், ஒரு செய்தியை அனுப்புகிறார்.
- உங்கள் front end உங்கள் சொந்த server-ஐ அழைக்கிறது, AI வழங்குநரை அல்ல.
- உங்கள் server request-ஐ உருவாக்குகிறது: system அறிவுறுத்தல்கள், பயனரின் உள்ளீடு, மற்றும் மாதிரிக்குத் தேவையான உங்கள் டேட்டாபேஸிலிருந்து வரும் டேட்டா — இந்தப் பயனர் பார்க்க அனுமதிக்கப்பட்ட டேட்டா மட்டும்.
- உங்கள் server LLM APIயை அழைக்கிறது, key ஒரு environment variable-இல் சேமிக்கப்பட்டுள்ளது.
- உங்கள் server பதிலைச் சரிபார்க்கிறது — சரியான JSON, அறியப்பட்ட label, நியாயமான நீளம் — பின்னர் சேமிக்கிறது அல்லது திருப்பித் தருகிறது.
- Front end அதைக் காட்டுகிறது, நீண்ட பதில்களுக்கு உரை வரும்போதே streaming செய்கிறது.
படி 4-இல் key server-இல் இருக்கும், ஒருபோதும் browser-ஐ அடையாது. API என்ற கருத்து புதிதென்றால், API என்றால் என்ன ஒரு சிறிய அறிமுகம்; LLM APIகளை எப்படிப் பயன்படுத்துவது tokens, models மற்றும் keys பற்றி ஆழமாக விளக்குகிறது.
வழங்குநரையும் மாதிரியையும் தேர்ந்தெடுத்தல்
OpenAI, Anthropic, Google மற்றும் பிற முக்கிய வழங்குநர்கள் அனைவரும் ஏறக்குறைய ஒத்த வடிவங்களில் உரை APIகளை வழங்குகின்றனர். தேர்ந்தெடுக்கும்போது பயனுள்ள கேள்விகள்:
- உங்கள் பணியில் தரம். உங்கள் ஆப்பிலிருந்து சில உண்மையான உதாரணங்களை இரண்டு அல்லது மூன்று மாதிரிகளில் முயலுங்கள். பொது benchmarks-ஐவிட உங்கள் டேட்டாவில்தான் வேறுபாடுகள் அடிக்கடி தெளிவாகத் தெரியும்.
- அளவு மற்றும் செலவு. வழங்குநர்கள் பெரிய, திறன்மிக்க மாதிரிகளையும், சிறிய, மலிவான, வேகமான மாதிரிகளையும் தருகின்றனர். Classification மற்றும் எளிய extraction பெரும்பாலும் சிறிய மாதிரியிலேயே நன்றாக வேலை செய்யும்; நீண்ட நியாயப்படுத்தல் அல்லது நுட்பமான எழுத்துக்கு பெரியது தேவைப்படலாம்.
- கட்டமைக்கப்பட்ட வெளியீடு. Extraction மற்றும் classification-க்கு, இலவச உரையைப் பகுப்பதை விட, நீங்கள் கொடுக்கும் schema-வுடன் பொருந்தும் JSON-ஐ மாதிரி திருப்பித் தரும் API அம்சத்தை விரும்புங்கள்.
- டேட்டா கையாளுதல். API உள்ளீடுகள் சேமிக்கப்படுகின்றனவா அல்லது பயிற்சிக்குப் பயன்படுத்தப்படுகின்றனவா என்பதை வழங்குநரின் விதிமுறைகளில் படியுங்கள்; அது உங்கள் பயனர்கள் தரும் டேட்டாவுக்குப் பொருந்துமா என்று பாருங்கள்.
- வரம்புகள். புதிய accounts-க்கு பெரும்பாலும் குறைந்த rate limits இருக்கும்; launch-க்கு முன் அவற்றைச் சரிபாருங்கள்.
மாதிரிகளின் பெயர்களும் விலைகளும் அடிக்கடி மாறும், எனவே code மாதிரியின் பெயரை பல இடங்களில் நேரடியாக எழுதாமல், configuration-இலிருந்து படிக்க வேண்டும்.
ஒரு அம்சத்தைப் படிப்படியாகச் சேர்ப்பது
ஒரு உறுதியான உதாரணம்: ஒவ்வொரு தொடர்புக்கும் நீண்ட குறிப்பு வரலாறு உள்ள ஒரு சிறிய CRM.
1. Key-ஐ சேமியுங்கள். வழங்குநரின் dashboard-இல் ஒரு key உருவாக்கி, அதை server-side secret ஆக வையுங்கள், எடுத்துக்காட்டாக OPENAI_API_KEY அல்லது ANTHROPIC_API_KEY.
2. ஒரே ஒரு குறுகிய அம்சத்தைக் கேளுங்கள்:
தொடர்பு பக்கத்தில் ஒரு "சுருக்கு" பொத்தானைச் சேர்க்கவும். Server-இல், தொடர்பின் கடைசி 20 குறிப்புகளை [PROVIDER]-க்கு [ENV_NAME] secret-ஐப் பயன்படுத்தி அனுப்பவும், மூன்று bullet புள்ளிகள் எழுதச் சொல்லும் அறிவுறுத்தலுடன்: தற்போதைய நிலை, திறந்த கேள்விகள், அடுத்த படி. உள்நுழைந்த பயனர் பார்க்கக்கூடிய குறிப்புகளை மட்டும் சேர்க்கவும். Loading நிலையைக் காட்டவும், சுருக்கத்தை நேரமுத்திரையுடன் சேமிக்கவும், அழைப்பு தோல்வியுற்றால் "இப்போது சுருக்க முடியவில்லை" என்று காட்டவும். Key-ஐ ஒருபோதும் browser-க்கு அனுப்பாதீர்கள்.
3. தட்டச்சு மிச்சப்படுத்தும் இடத்தில் extraction சேர்க்கவும்:
ஒரு பயனர் "Quick add" பெட்டியில் email கையொப்பத்தை ஒட்டும்போது, server-இல் [PROVIDER]-ஐ அழைத்து, பெயர், நிறுவனம், பதவி, email, தொலைபேசி கொண்ட JSON-ஐ வழங்குநரின் கட்டமைக்கப்பட்ட வெளியீட்டு அம்சத்தைப் பயன்படுத்தித் திருப்பித் தரவும். JSON-ஐ server-இல் சரிபார்த்து, புதிய தொடர்பு படிவத்தை அதனுடன் நிரப்பவும், சேமிப்பதற்கு முன் பயனர் திருத்த அனுமதிக்கவும். யூகிப்பதற்குப் பதிலாக fields-ஐ வெறுமையாக விடவும்.
"சேமிப்பதற்கு முன் பயனர் திருத்த அனுமதிக்கவும்" என்பதே முக்கியமான பகுதி: மாதிரி பரிந்துரைக்கும், முடிவு செய்வது மனிதர்.
4. பின்னணியில் classify செய்யுங்கள்:
புதிய support ticket வரும்போது, அதை billing, bug, feature request, account access, other ஆகிய சரியாக ஒன்றில் வகைப்படுத்தவும். சிறிய, குறைந்த செலவு மாதிரியைப் பயன்படுத்தவும். பதில் அந்த labels-இல் ஒன்றாக இல்லையென்றால் "other" என்று சேமிக்கவும். Label-ஐ திருத்தக்கூடிய tag ஆகக் காட்டவும்.
5. குழப்பமான உண்மையான டேட்டாவில் சோதியுங்கள் — நீண்ட குறிப்புகள், வெற்றுக் குறிப்புகள், வேறு மொழிகள், தொலைபேசி எண் இல்லாத கையொப்பம் — அனுப்புவதற்கு முன் இருபது வெளியீடுகளை அருகருகே பார்க்கவும்.
வேலை செய்யும் அறிவுறுத்தல்களை எழுதுவது
ஒவ்வொரு request-உடனும் அனுப்பும் அறிவுறுத்தல்கள் (பெரும்பாலும் system prompt என்று அழைக்கப்படும்) தரம் வரும் இடம்.
- அது யாருக்கானது, நல்லது எப்படி இருக்கும் என்று சொல்லுங்கள். "விற்பனையாளர் அழைப்புக்கு முன் 10 வினாடிகளில் சுருக்கத்தைப் படிப்பார்" என்பது மாதிரிக்கு ஒரு இலக்கைத் தருகிறது.
- வடிவத்தை நிர்ணயியுங்கள். சரியான bullet எண்ணிக்கை, நீள வரம்பு, fields, labels.
- உறுதியில்லாதபோது என்ன செய்வது என்று சொல்லுங்கள். "குறிப்புகளில் அடுத்த படி குறிப்பிடப்படவில்லையென்றால், 'அடுத்த படி பதிவு செய்யப்படவில்லை' என எழுதவும்." இது கண்டுபிடித்த பதில்களைக் குறைக்கிறது.
- Extraction மற்றும் classification-க்கு இரண்டு அல்லது மூன்று நல்ல உள்ளீடு-வெளியீடு உதாரணங்கள் கொடுங்கள்.
- அறிவுறுத்தல்களை பயனர் உள்ளடக்கத்திலிருந்து தனியாக வையுங்கள், பயனர் உள்ளடக்கத்தைத் தெளிவாக குறியிடுங்கள், அதனால் மாதிரி இரண்டையும் வேறுபடுத்த முடியும்.
Prompts-ஐ உங்கள் codebase-இல் கோப்புகளாக வையுங்கள், அதனால் மற்ற code போலவே versioned ஆகவும் மதிப்பாய்வு செய்யக்கூடியதாகவும் இருக்கும்.
செலவைக் கட்டுப்படுத்துதல்
LLM APIகள் நீங்கள் அனுப்பும் மற்றும் திரும்பப் பெறும் இரண்டுக்கும் tokens — சிறிய உரைத் துண்டுகள் — அடிப்படையில் கட்டணம் வசூலிக்கின்றன. செலவு, ஒரு request-இல் உள்ள context அளவை, அது எத்தனை முறை இயங்குகிறது என்பதால் பெருக்கியதற்கு ஏற்ப உயரும். நடைமுறைக் கட்டுப்பாடுகள்:
- தேவையானதை மட்டும் அனுப்புங்கள். முழு வரலாறு அல்ல, கடைசி 20 குறிப்புகள் மட்டும். நீண்ட ஆவணங்களைச் சுருக்குங்கள் அல்லது பிரிக்கவும்.
- வேலையைச் செய்யும் சிறிய மாதிரியைப் பயன்படுத்துங்கள். பெரியதை இயல்புநிலையாக்குவதற்கு முன் சோதியுங்கள்.
- வெளியீட்டின் நீளத்தை வரம்பிடுங்கள், API-இன் அதிகபட்ச tokens அமைப்பைக் கொண்டு.
- முடிவுகளை cache செய்யுங்கள். சுருக்கத்தைச் சேமித்து, மூலம் மாறும்போது மட்டும் மீண்டும் உருவாக்குங்கள், ஒவ்வொரு பக்கப் பார்வையிலும் அல்ல.
- ஒரு பயனருக்கு வரம்பு வையுங்கள். ஒரு கணக்குக்கு அல்லது திட்டத்துக்கு தினசரி வரம்பு, ஒரு கனமான பயனர் அல்லது ஒரு script பில்லை ஏற்றுவதைத் தடுக்கும்.
- மற்ற விலை உயர்ந்த route-களைப் போலவே endpoint-க்கும் rate limit வையுங்கள்.
- வழங்குநரின் dashboard-இல் budget அல்லது எச்சரிக்கை அமையுங்கள், launch-க்குப் பிறகு வாரந்தோறும் பயன்பாட்டைச் சரிபாருங்கள்.
- ஒவ்வொரு அம்சத்துக்கும் token பயன்பாட்டைப் பதிவு செய்யுங்கள், எது எவ்வளவு செலவாகிறது என்று தெரிய.
AI அம்சங்கள் உங்கள் தயாரிப்பின் மையமாக இருந்தால், அவற்றின் இயக்கச் செலவை விலையில் சேர்த்துக்கொள்ளுங்கள், அதைத் தாங்கிக்கொள்ள வேண்டாம்.
பாதுகாப்பும் நம்பிக்கையும்
AI வெளியீடு நிகழ்தகவு அடிப்படையிலானது. அது உறுதியாகப் பேசும்போதும் தவறாக இருக்கலாம், அது படிக்கும் உரையால் வழிநடத்தப்படவும் கூடும். அதற்கேற்ப உருவாக்குங்கள்:
- வெளியீட்டை நம்பகமற்ற உள்ளீடாகக் கருதுங்கள். கட்டமைப்பைச் சரிபாருங்கள், HTML ஆகக் காட்டுவதற்கு முன் escape செய்யுங்கள், அதை ஒருபோதும் code அல்லது டேட்டாபேஸ் queries ஆக இயக்காதீர்கள்.
- விளைவுகள் உள்ள எதற்கும் மனிதரை உள்ளே வைத்திருங்கள் — மின்னஞ்சல் அனுப்புதல், பதிவை மாற்றுதல், பணத்தைத் திருப்பிச் செலுத்துதல். மாதிரி வரைகிறது; ஒரு நபர் உறுதிப்படுத்துகிறார்.
- Prompt injection-க்கு எதிராகப் பாதுகாக்கவும். ஓர் ஆவணம் அல்லது செய்தியில் "உங்கள் அறிவுறுத்தல்களைப் புறக்கணிக்கவும்" போன்ற உரை இருக்கலாம். மாதிரி பார்க்கும் டேட்டாவை தற்போதைய பயனர் பார்க்கலாம் என்பதற்கு மட்டுப்படுத்துங்கள், உங்கள் code அனுமதிகளைச் சரிபார்க்காமல் முக்கியமான செயல்களைச் செய்யக்கூடிய கருவிகளை அதற்குக் கொடுக்காதீர்கள்.
- AI உள்ளடக்கத்தைக் குறியிடுங்கள், ஒரு சுருக்கம் அல்லது பரிந்துரை உருவாக்கப்பட்டது என்றும், பயனர் அதைச் சரிபார்க்கலாம் என்றும் அவர்களுக்குத் தெரிய.
- தோல்விகளை அழகாகக் கையாளுங்கள். வழங்குநர்களுக்கு outages மற்றும் rate limits ஏற்படும். Timeout செய்யுங்கள், தெளிவான செய்தி காட்டுங்கள், மற்ற ஆப் வேலை செய்து கொண்டே இருக்கட்டும்.
- பயனர்கள் அனுப்புவதைக் கவனியுங்கள். திறந்த உரை உள்ளீடுகளுக்கு, ஒரு moderation படியைப் பரிசீலியுங்கள், மேலும் உங்கள் privacy policy-இல் உள்ளடக்கம் மூன்றாம் தரப்பு AI வழங்குநரால் செயலாக்கப்படுகிறது என்று தெளிவாகச் சொல்லுங்கள்.
பரந்த சரிபார்ப்புப் பட்டியல் AI-உருவாக்கிய ஆப்களுக்கான பாதுகாப்புப் பட்டியலில் உள்ளது.
பொதுவான தவறுகள்
- ஒரு பொதுவான chatbot-இலிருந்து தொடங்குவது, அதற்குப் பதிலாக ஒரு எளிய "சுருக்கு" அல்லது "வகைப்படுத்து" பொத்தான் அதிக மக்களுக்கு உதவும்போது.
- Key-ஐ front-end code-இலோ பொது repository-இலோ வைப்பது.
- முழு டேட்டாபேஸையும் context ஆக அனுப்புவது, இது மெதுவானது, செலவு மிக்கது, மற்ற பயனர்களின் டேட்டாவையும் வெளிப்படுத்தும் அபாயம் கொண்டது.
- இலவச உரை வெளியீட்டை நம்புவது, schema அல்லது நிலையான label தொகுப்பு அதைச் சரிபார்க்கக்கூடியதாக ஆக்கியிருக்கும் இடத்தில்.
- ஒரு பயனருக்கு வரம்பு இல்லாமை, முதல் பில் வரும்போது கண்டுபிடிக்கப்படுவது.
Mythex-இல் AI அம்சங்களைச் சேர்ப்பது
Mythex-இல் உங்கள் சொந்த ஆப்பிற்குள் AI-ஐ, உங்கள் சொந்த வழங்குநர் key-ஐப் பயன்படுத்தி, chat-இல் கேட்பதன் மூலம் சேர்க்கிறீர்கள். Key-ஐ project secret ஆக சேமியுங்கள் — agent ஒன்று தேவைப்படும்போது, Mythex chat-இல் ஒரு secrets அட்டையைக் காட்டும், அதனால் key-ஐ உரையாடலில் ஒட்ட வேண்டியதில்லை — agent server route, prompts மற்றும் இடைமுகத்தை எழுதும். உங்கள் ஆப்பின் AI பயன்பாடு, நீங்கள் உருவாக்கச் செலவிடும் Mythex credits-இலிருந்து தனியாக, உங்கள் வழங்குநரால் பில் செய்யப்படும். Docs-இல் உங்கள் சொந்த API keys-உடன் AI அம்சங்களைச் சேர்ப்பது என்பதில் ஒரு தொடக்க prompt உள்ளது.
கேள்விகள்
ஏற்கனவே உள்ள ஆப்பில் AI சேர்ப்பது எப்படி?
LLM வழங்குநரிடமிருந்து ஒரு API key பெற்று, அதை server-side secret ஆக சேமியுங்கள். பிறகு ஒரு server route சேர்க்கவும்: அது வழங்குநருக்கு prompt மற்றும் தொடர்புடைய டேட்டாவை அனுப்பி, முடிவை உங்கள் front end-க்குத் திருப்பித் தரும். பொது chat-ஐ உருவாக்கும் முன், ஒரு பதிவைச் சுருக்குவது போன்ற ஒரு குறுகிய அம்சத்தில் தொடங்குங்கள்.
AI அம்சங்களை இயக்குவதற்கு எவ்வளவு செலவாகும்?
LLM APIகள் token அடிப்படையில் கட்டணம் வசூலிக்கின்றன — அனுப்பும் மற்றும் பெறும் உரையின் பகுதி அளவுக்கு ஏற்ப — மாதிரிக்கு மாதிரி கட்டணங்கள் பெரிதும் வேறுபடும். ஒவ்வொரு request எவ்வளவு உரையை எடுத்துச் செல்கிறது, அது எத்தனை முறை இயங்குகிறது என்பதைப் பொறுத்தது. எனவே உங்கள் சொந்த பயன்பாட்டிலிருந்து மதிப்பிடுங்கள், வழங்குநரின் dashboard-இல் வரம்பு அமையுங்கள், உங்கள் ஆப்பில் ஒவ்வொரு பயனருக்கும் பயன்பாட்டு வரம்பு வையுங்கள்.
என் OpenAI அல்லது Anthropic key-ஐ front end-இல் வைக்கலாமா?
வைக்கக்கூடாது. Front-end code-ஐ பக்கத்தைத் திறக்கும் யாரும் படிக்கலாம், கசிந்த key வேறு யாருக்காவது உங்கள் பில்லை ஏற்றும். வழங்குநரை உங்கள் server-இலிருந்து அழையுங்கள், அங்கே key ஒரு environment variable-இல் இருக்கும்.
Prompt injection என்றால் என்ன?
மாதிரி படிக்கும் உரையில் — ஒரு பயனர் செய்தி, பதிவேற்றிய ஆவணம், ஒரு web பக்கம் — உங்கள் அறிவுறுத்தல்களை மீறுவதற்கான கட்டளைகள் இருப்பதுதான் இது. மாதிரியின் வெளியீட்டை நம்பகமற்றதாகக் கருதுங்கள், சரிபார்ப்பின்றி முக்கியமான செயல்களைத் தூண்ட விடாதீர்கள், மாதிரி பார்க்கும் டேட்டாவை பயனர் பார்க்க அனுமதிக்கப்பட்டதற்கு மட்டுப்படுத்துங்கள்.