Markdown பதிப்பு

AI-translated from English; not yet reviewed by a fluent editor.

# Jev-இன் பெரிய பந்தயம்: நாம் ஏற்கெனவே பயன்படுத்தும் மென்பொருளுக்குள் AI முடிவுகள்

> சிறிய முடிவுகளை மையமாகக் கொண்டு மென்பொருளுக்குள் AI-ஐ உருவாக்குவதே நோக்கம் என TypeSafe தலைமை நிர்வாகி Diogo Almeida வாதிடுகிறார். Jev-இன் அறிமுகம், அதன் வரம்புகள், பொருளுள்ள மாற்றத்தை எது நிரூபிக்கும் என்பவற்றை ஆராய்கிறோம்.

By BIG CHANGE Editorial

Published: 2026-09-22T00:45:03.943Z
Updated: 2026-09-22T00:45:03.943Z
Canonical: https://bigchange.ai/blog/jev-typesafe-ai-decisions-software-diogo-almeida

![Pencil sketch of document cards passing through a small decision switch, constrained by a checklist, into two output trays.](https://bigchange.ai/api/media/file/jev-interview-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. A decision switch inside a larger workflow; not a depiction of Jev’s internal architecture.

ஒரு வாடிக்கையாளர் ஆர்டரிலுள்ள முகவரியை மாற்றுகிறார். அந்தச் செய்தியில் பணத்தைத் திருப்பிக் கேட்பதும், பொதியின் சேதத்தைக் குறிப்பிடுவதும், ஏதோ தவறு நடப்பது இது மூன்றாவது முறை என்ற மறைமுகச் சுட்டும் உள்ளன. அந்தச் செய்திக்குப் பயனுள்ள பதிலை உருவாக்குவது ஒரு பணி. எந்தப் பதிவுகளைப் புதுப்பிப்பது, எந்தக் குழு தலையிட வேண்டும், எந்தச் செயலுக்கு அனுமதி தேவை என்பதை முடிவுசெய்வது மற்றொரு பணி.

2026 செப்டம்பர் 15 அன்று ஆரம்ப அணுகலில் TypeSafe AI அறிமுகப்படுத்திய மாதிரியான Jev, இத்தகைய முடிவுகளை இலக்காகக் கொண்டுள்ளது. மென்பொருளுக்காகக் கட்டுப்படுத்தப்பட்ட, கட்டமைக்கப்பட்ட பதில்களை இது உருவாக்குகிறது. பொதுப் பயன்பாட்டு மாதிரியுடனான நீண்ட உரையாடலைச் சார்ந்து ஒரு செயலி இருக்க வேண்டியது எவ்வளவு என்பதைக் மறுபரிசீலிக்க இந்த அறிமுகம் அழைக்கிறது. [TypeSafe அறிமுக அறிவிப்பு](https://typesafe.ai/blog/introducing-system-one-models-and-jev)

TypeSafe இணை நிறுவனர் மற்றும் தலைமை நிர்வாகி Diogo Almeida, swyx தொகுத்து நடத்திய செப்டம்பர் 21 Latent Space நேர்காணலில் இந்த வாதத்தை மிக விரிவாக முன்வைக்கிறார். இரண்டு மணி 22 நிமிட உரையாடலின் முழு ஆங்கில வசனங்களையும் ஆய்ந்து, தயாரிப்பு ஆவணங்களையும் சரிபார்த்தோம். இந்தப் பகுப்பாய்வு அந்த நேர்காணலையும் பொதுவில் உள்ள ஆதாரத்தையும் அடிப்படையாகக் கொண்டது; Jev-க்கான அளவுகோல் சோதனையை நாங்கள் தனியாக நடத்தவில்லை. [அசல் நேர்காணலைப் பாருங்கள்](https://www.youtube.com/watch?v=cFx9Z3ZXca0)

Jev-இன் மிக முக்கியமான முன்மொழிவு, தானியக்கத்தின் அலகைப் பற்றியது என்பது எங்கள் வாசிப்பு. முழுச் செயல்முறையையும் பொறுப்புடன் ஒப்படைக்க முடிவதற்கு முன்பே, ஏற்கெனவே உள்ள செயல்முறைக்குள் வரையறுக்கப்பட்ட ஒரு முடிவை நிறுவனம் தானியக்கமாக்க முடியும். அதை மீண்டும் மீண்டும் செய்யும் அளவுக்கு மலிவாகவும் அளவிடும் அளவுக்கு தெளிவாகவும் ஆக்கினால், ஒவ்வொரு தொடர்பும் உரையாடலாக மாறாமல், பரிச்சயமான வணிக மென்பொருள் பயனுள்ள திறன்களைப் பெறலாம்.

இது பணிப்பாய்வுகளை வடிவமைப்போரையும் பயன்படுத்துவோரையும் பாதிக்கும். எந்தச் செயல்கள் அனுமதிக்கப்படுகின்றன, எது பிழையாகக் கருதப்படும், விதிவிலக்குகளை யார் கையாள்வார்கள் என்பதை ஒருவர் இன்னும் முடிவு செய்ய வேண்டும். அந்த முடிவுகளின் தரமே இந்த அணுகுமுறை நம்பகமான சேவைகளை உருவாக்குமா அல்லது தவறுகளை வேகப்படுத்துமா என்பதைத் தீர்மானிக்கும்.

## TypeSafe உண்மையில் அறிமுகப்படுத்தியது என்ன

Jev-இன் ஆவணப்படுத்தப்பட்ட இடைமுகம், ஓர் நிலையும் வகை குறிப்பிடப்பட்ட கேள்விகளின் தொகுப்பும் கொண்டு செயல்படுகிறது. இதில் மூன்று அடிப்படைச் செயல்கள் உள்ளன: குறிப்பிட்ட விருப்பங்களில் ஒன்றைத் தேர்வுசெய்யும் Choice; மதிப்பீட்டு அளவுகோலுக்கு எதிராக மதிப்பிடும் Score; ஒரு கூற்றின் நிகழ்தகவை பூஜ்ஜியத்துக்கும் ஒன்றுக்கும் இடைப்பட்ட அளவில் தெரிவிக்கும் Noul. Choice மற்றும் Score, பகிர்வையும் நம்பிக்கைப் புலத்தையும் வழங்குகின்றன. Noul-க்கு அந்தத் தனி நம்பிக்கைப் புலம் இல்லை. வழங்கப்பட்ட நிலையைப் பல கேள்விகள் பகிர்ந்து, அதேநேரம் தனித்தனியாக மதிப்பிடப்படலாம். [TypeSafe இடைமுக ஆவணங்கள்](https://docs.typesafe.ai/introduction)

வாடிக்கையாளர் சேவைச் செயலியில், முகவரி மாற்றக் கோரிக்கையை ரத்துசெய்தலிலிருந்து வேறுபடுத்தவும், அவசரத்தை மதிப்பிடவும், சேதத்துக்கான ஆதாரம் செய்தியில் உள்ளதா எனச் சரிபார்க்கவும் உருவாக்குநர் இவ்வடிப்படைச் செயல்களைப் பயன்படுத்தலாம். இவை விளக்கத்துக்கான கற்பனை எடுத்துக்காட்டுகள்; Jev செயலாக்கத்தின் முடிவுகள் அல்ல. பதில்களைக் கொண்டு அடுத்து என்ன செய்ய வேண்டும் என்பதைச் செயலியே தீர்மானிக்கும்.

விளக்கமும் அதிகாரமும் வெவ்வேறு பொறுப்புகள் என்பதால் இந்தப் பிரிவு பயனுள்ளது. வாடிக்கையாளர் பணத்திருப்பம் விரும்புகிறார் என AI ஊகிக்கலாம். அந்த முடிவுக்கு வந்தது என்பதற்காக மட்டும் பணத்தைத் திருப்பிவிடும் அனுமதி அதற்குக் கிடைக்கக் கூடாது. செயலி ஆர்டரைச் சரிபார்த்து, பணத்திருப்ப வரம்பை அமல்படுத்தி, தேவையான இடத்தில் ஒப்புதலைக் கோரலாம்.

வேகமான, உள்ளுணர்வு சார்ந்த சிந்தனையைக் குறிக்கும் System One என்ற பெயரை TypeSafe இந்த மாதிரி வகைக்குப் பயன்படுத்துகிறது. நோக்கப்பட்ட பணிச்சுமையின் விளக்கமாகவே அந்தப் பெயரை எடுத்துக்கொள்ளுங்கள். இது மனிதனைப் போன்ற சிந்தனைக்குச் சான்றிதழ் அளிக்கவோ எளிய மற்றும் கடினமான பணிகளுக்கிடையே தெளிவான எல்லையை நிறுவவோ இல்லை. தேவையான தகவல் இல்லாதபோது, சிறிய கேள்விகூட சிக்கலான முடிவை மறைக்கலாம்.

## பொறியியல் மாற்றம்: சிறிய, ஆய்வு செய்யக்கூடிய முடிவுகள்

குறுகிய வரம்புள்ள கேள்விகளைக் கேட்டு, அவற்றின் பதில்களை நிரல்குறியீட்டில் இணைக்கும் கூறுபடுத்தல் முறையை Almeida வலியுறுத்துகிறார். [நேர்காணல், 1:03:02](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=3782s)

சேதமடைந்த ஆர்டர் எடுத்துக்காட்டுக்குத் திரும்புவோம். புகாரைக் கையாளும் ஒற்றை அறிவுறுத்தல், பல முடிவுகளை ஒரே பதிலுக்குள் மறைக்கிறது. அதிகம் ஆய்வு செய்யக்கூடிய வடிவமைப்பு, கோரப்பட்ட செயலைத் தனியே கண்டறிந்து, ஆர்டரை அடையாளம் காண முடியுமா எனச் சரிபார்த்து, கிடைக்கும் ஆதாரம் சேதக் கூற்றை ஆதரிக்கிறதா என்பதையும் தனித்தனியாக நிறுவும். கொள்கை விதிகளை அந்த முடிவுகளுக்கு வெளியே வைத்திருக்கும்.

இதனால் தோல்வியை விசாரிப்பது எளிதாகிறது. முகவரி மாற்றக் கோரிக்கையை அமைப்பு திருப்பியனுப்பும் குழுவுக்கு அனுப்பினால், செயல்பாட்டாளர் அந்த வழிமாற்று முடிவை ஆராயலாம். சேத மதிப்பீடு தவறாக இருந்தால், முந்தைய நிகழ்வுகளைக் கொண்டு அந்தக் கூறைச் சோதிக்கலாம். பரந்த அறிவுறுத்தலை மாற்றி, மாதிரி அதை ஒரே மாதிரியாகப் புரிந்துகொள்ளும் என நம்புவதற்குப் பதிலாக, கொள்கை மாற்றம் வெளிப்படையான விதியை மாற்றலாம்.

இதற்கும் செலவுகள் உண்டு. அதிகக் கூறுகள் என்றால் பராமரிக்க வேண்டிய இடைமுகங்களும் அதிகம். பதிலைத் தெளிவாக்கும் சூழலைக் கேள்விகள் தவறுதலாக விடக்கூடும். ஒன்றுக்கொன்று சார்பில்லாதவைபோல் தோன்றும் இரண்டு முடிவுகளும் ஒரே தவறாக வழிநடத்தும் ஆதாரத்தைச் சார்ந்திருக்கலாம். தனித்தனியாக ஏற்றுக்கொள்ளத்தக்க கூறுகளால் அமைக்கப்பட்ட பணிப்பாய்வும் ஏற்றுக்கொள்ள முடியாத முடிவைத் தரலாம்.

ஒன்றாகப் பல கேள்விகளைக் கேட்பது, மதிப்பெண்களை இணைப்பது, நிச்சயமற்ற வழக்குகளை கூடுதல் கையாளுதலுக்கு அனுப்புவது ஆகியவற்றை ஆவணப்படுத்தப்பட்ட வடிவங்களில் TypeSafe சேர்த்துள்ளது. இவை கட்டமைப்புத் தேர்வுகளின் விளக்கங்கள்; குறிப்பிட்ட வாடிக்கையாளர் செயல்முறை கண்காணிப்பின்றி இயங்கத் தயாராக உள்ளது என்பதற்கான ஆதாரம் அல்ல. [TypeSafe-இன் வடிவங்கள்](https://docs.typesafe.ai/patterns)

கூறுபடுத்தல், தோல்வியறிதலையும் முடிவுகளையும் மேம்படுத்துகிறதா என்பதே பயனுள்ள சோதனை. எந்தப் படி தோல்வியுற்றது என விளக்க முடிவது மதிப்புடையது. அந்தத் தோல்விகளின் அடிக்கடியையும் விளைவையும் குறைப்பதே வணிக வாதம்.

![Pencil diagram: an input document branches into three parallel questions, whose answers enter a rules box before action or review.](/api/media/file/jev-interview-inline-v1.png)

## சரியான வடிவிலான பதிலும் தவறாக இருக்கலாம்

Jev “மாயத்தோற்றம் உருவாக்க முடியாது” என்ற அறிமுகக் கூற்றை வரையறுக்கப்பட்ட பொருளில் படிக்க வேண்டும். அனுமதிக்கப்பட்ட வெளியீட்டு வடிவத்துடன் பொருந்துவதற்கே தனது உத்தரவாதம் பொருந்தும் என TypeSafe கூறுகிறது. தேர்ந்தெடுக்கப்பட்ட பதில் உண்மை என்பதை அது நிறுவாது. வடிவமைப்பு உத்தரவாதத்தையும் அனுபவப்பூர்வ மதிப்பீட்டையும் நிறுவனத்தின் சொந்த அறிவிப்பே வேறுபடுத்துகிறது. [வகைப் பாதுகாப்பு குறித்த TypeSafe விளக்கம்](https://typesafe.ai/blog/introducing-system-one-models-and-jev)

ஒரு செயலி மதிப்புகளுக்கு அனுமதி அளிக்கிறது என வைத்துக்கொள்வோம்: `damaged`, `late` மற்றும் `other`. `damaged` என்பது பொதியாளர் தாமதித்தபோது திருப்பும் முற்றிலும் செல்லுபடியாகும் பதில். நான்காவது வகையை உருவாக்க முடியாத மாதிரியும் தவறானதைத் தேர்ந்தெடுக்கலாம். உண்மையில் தேவைப்படும் வகையைப் பட்டியல் விலக்கினால், வகை வரையறையே பிரச்சினையின் ஒரு பகுதியாகிவிடும்.

கட்டமைக்கப்பட்ட வெளியீடு என்பது ஏற்கெனவே உள்ள பொறியியல் முறையும் ஆகும். பதிலளிக்கப்பட்ட மதிப்புகளுக்குள் மாதிரி இன்னும் தவறு செய்யலாம் என்று வெளிப்படையாகக் குறிப்பிட்டு, 2024 ஆகஸ்டில் schema-வால் கட்டுப்படுத்தப்படும் Structured Outputs-ஐ OpenAI அறிமுகப்படுத்தியது. ஆகவே, எல்லா கட்டமைக்கப்பட்ட AI வெளியீட்டையும் கண்டுபிடித்த பெருமை Jev-க்குரியது எனக் கருதாமல், முடிவுத் தரம், நிச்சயமின்மை அறிக்கை, தாமதம், செலவு ஆகியவற்றின் தனித்துவமான சேர்க்கையைக் கொண்டு அதை மதிப்பிட வேண்டும். [OpenAI-யின் அசல் அறிவிப்பும் வரம்புகளும்](https://openai.com/index/introducing-structured-outputs-in-the-api/)

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

## அளவுத்திருத்தமே நேர்காணலின் முக்கியச் சவால்

1:09-இல், முழுமையான அளவுத்திருத்தம் என்ற கருத்தை Almeida நிராகரித்து, மாதிரிப் பிழைகளை ஒப்புக்கொள்கிறார். [நேர்காணல், 1:08:50](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=4130s)

கணிக்கப்பட்ட நிகழ்தகவுகள், பல கணிப்புக் குழுக்களில் காணப்பட்ட முடிவுகளுடன் எவ்வாறு ஒப்பிடப்படுகின்றன என்பதையே அளவுத்திருத்தம் குறிக்கிறது. ஒவ்வொரு உயர் நிகழ்தகவு வழக்கிலும் சரியாக இல்லாவிட்டாலும், நிச்சயமின்மையைச் சுட்டுவதில் மாதிரி பயனுள்ளதாக இருக்கலாம். TypeSafe-இன் அறிமுக வழிகாட்டி இந்த வேறுபாட்டை வெளிப்படையாகத் தக்கவைக்கிறது. [அளவுத்திருத்தம் குறித்த TypeSafe விளக்கம்](https://docs.typesafe.ai/introduction/machine-learning-primer)

API-யிலுள்ள நம்பிக்கைப் புலத்தையும் வேறுபடுத்திப் புரிந்துகொள்ள வேண்டும். பதில் பகிர்விலிருந்து கணக்கிடப்படும் புள்ளிவிவரமாக இதை TypeSafe விவரிக்கிறது. தேர்ந்தெடுக்கப்பட்ட பதில் சரியாக இருப்பதற்கான சுயாதீனமாக அளவிடப்பட்ட நிகழ்தகவுக்கு இது இணையானதல்ல. பணியையும் அதன் விளைவுகளையும் பொறுத்து வரம்புகளைத் தேர்ந்தெடுக்க ஆவணம் பரிந்துரைக்கிறது. [TypeSafe-இன் நம்பிக்கை ஆவணம்](https://docs.typesafe.ai/confidence)

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

ஆகவே, தகவல் இல்லாத நிலைகள், அறிமுகமில்லாத சொற்றொடர்கள், திட்டமிட்டு குழப்பும் உள்ளீடுகள் உட்பட வரவிருக்கும் வழக்குகளை ஒரு குழு மதிப்பிட வேண்டும். வகைவாரியான பிழைகளை ஆய்ந்து, மறுஆய்வுக்கு அனுப்பும் செலவையும் தவறாகச் செயல்படுவதால் ஏற்படும் செலவையும் ஒப்பிட வேண்டும். செயல்விளக்கத்திலிருந்து நகலெடுத்த எண்களாக அல்லாமல், ஆதாரத்தின் அடிப்படையிலான செயல்பாட்டு முடிவுகளாக வரம்புகள் அமையும்.

Jev-க்கு முன்பே அளவுத்திருத்த ஆய்வுகள் நீண்டகாலமாக நடைபெறுகின்றன. நவீன நரம்பியல் வலைப்பின்னல்களில் மோசமான அளவுத்திருத்தத்தையும் அதை மேம்படுத்தும் முறைகளையும் Chuan Guo மற்றும் சக ஆசிரியர்கள் எழுதிய பரவலாக மேற்கோள் காட்டப்படும் 2017 ஆய்வு ஆராய்ந்தது. அந்தப் பணி பிரச்சினைக்கான பின்னணியை அளிக்கிறது; TypeSafe மாதிரியை அது சரிபார்க்கவில்லை. [நவீன நரம்பியல் வலைப்பின்னல்களின் அளவுத்திருத்தம்](https://arxiv.org/abs/1706.04599)

## சேவை மாறும்போது என்ன நடக்கிறது என்பதும் நம்பகத்தன்மையின் ஒரு பகுதி

உரையாடல், உறுதிப்பாட்டிலிருந்து வேறுபாட்டையும், பதிப்புகளின் நிலைத்தன்மையையும் விவரிக்கிறது; ஆனால் பொதுவான நீண்டகால ஆதரவு உறுதிமொழி இல்லை. [நேர்காணல், 41:24](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=2484s) மற்றும் [49:40](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=2980s)

இவை தனித்தனியான கொள்முதல் கேள்விகள். ஒரே மாதிரியான உள்ளீடுகள் ஒரே மாதிரியான வெளியீடுகளை உருவாக்குகின்றனவா என்பதே நிர்ணயத்தன்மை. தொடர்பற்ற மாற்றம்—எடுத்துக்காட்டாக வேறு பதிவுக் குறியீடு—நியாயமற்ற நடத்தையை உருவாக்குகிறதா என்பதே வலுவுத்தன்மை. அதே தவறான பதிலை முடிவில்லாமல் மீண்டும் கூறும் மாதிரியும் நிர்ணயமானதாக இருக்கலாம். சுற்றியுள்ள பணிப்பாய்வு நம்பகமாக இருக்கும் போதும் அது சற்றே மாறக்கூடும்.

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

பிரதிநிதித்துவமான வழக்குகளைப் பாதுகாத்து, பதிப்புகளைப் பதிவு செய்து, விளைவுள்ள பணியை இடமாற்றுவதற்கு முன் மாற்றுப் பதிப்புகளை ஒப்பிடுவதே நியாயமான பதில். மாற்றுவழியும் முக்கியம்: மற்றபடி துல்லியமான முடிவுச் சேவை கூட கிடைக்காமல் போகலாம். நிறுத்தவோ வேறு வழிக்கு அனுப்பவோ பாதுகாப்பான முறை இல்லாத செயலியில், செயல்நேரமும் நடைமுறையில் அதன் முடிவுத் தரத்தின் ஒரு பகுதியாகிறது.

கவர்ச்சிகரமான API, இங்குதான் செயல்பாட்டு சார்பாக மாறுகிறது. மாதிரி வேகமானது என்பதால் கொள்முதல், கண்காணிப்பு, இடமாற்றத் திட்டமிடல் ஆகியவை மறைவதில்லை. ஒவ்வொரு அழைப்பும் மிகவும் எளிமையாகத் தோன்றுவதால் அவற்றைப் புறக்கணிப்பது எளிதாகலாம்.

## வேகமும் விலையும் குறித்த எண்களுக்கு ஏன் சூழல் தேவை?

TypeSafe-இன் தலைப்புச் செய்தி பணிப்பாய்வு முடிவுகளில் 193.6 மடங்கு வேகமும் 444.6 மடங்கு செலவுக் குறைப்பும் அடங்கும். நிறுவனமே எழுதிய பணிப்பாய்வுகளில் கிடைத்த உயர்நிலைப் பலன்கள் என அறிவிப்பு அவற்றை அடையாளப்படுத்துகிறது. குறிப்பு பதில்கள், தனியாகச் சரிபார்க்கப்பட்ட உண்மை நிலைகளுக்குப் பதிலாக, பிற மாதிரிகளின் நிகழ்தகவு மதிப்பீடுகளிலிருந்து பெறப்பட்டன. நிறுவனமே தனது குறுகிய செயல்விளக்கம் Jev-க்கு சாதகமானது என்றும், நீடித்த நீண்டகால விலை இன்னும் நிறுவப்பட வேண்டும் என்றும் எச்சரிக்கிறது. [TypeSafe மதிப்பீட்டின் வரம்புகள்](https://typesafe.ai/blog/introducing-system-one-models-and-jev)

இந்த வரம்புகளும் எண்களுடன் சேர்த்தே தெரிவிக்கப்பட வேண்டும். குறிப்பு மாதிரியுடன் உடன்படுவது தகவலளிக்கலாம்; ஆனால் தீர்க்கப்பட்ட வாடிக்கையாளர் வழக்கின் உண்மைத்தன்மையுடன் ஒப்பிடும் அளவீட்டிலிருந்து அது வேறுபட்டது. விற்பனையாளர் வடிவமைத்த பணிப்பாய்வு வாங்குபவருக்குப் பொருந்தலாம்; ஆனால் அந்த வாங்குபவரின் கோரிக்கைப் பகிர்வை பிரதிநிதித்துவப்படுத்த வேண்டியதில்லை.

முழுப் பணியையும் ஒப்பீடு உள்ளடக்க வேண்டும்: சூழலைச் சேகரித்தல், முடிவெடுத்தல், விதிகளைப் பயன்படுத்துதல், விதிவிலக்குகளைக் கையாளுதல், தோல்வியிலிருந்து மீளுதல். மலிவான மாதிரி அழைப்பு, மதிப்பாய்வாளர்களிடம் அதிகப் பணியை அனுப்பினால் மொத்தச் செலவு உயர்ந்திருக்கலாம். மெதுவான அழைப்பு, அதிகச் செலவுள்ள மறுபணியைத் தவிர்த்தால் சிக்கனமாக இருக்கலாம்.

செயலி இயங்கும் உண்மையான பகுதியிலிருந்து தாமதத்தையும் அளவிட வேண்டும். சேவையின் உள்கட்டமைப்புக்கு அருகிலான செயல்விளக்கம், வேறு இடத்திலுள்ள பயனரின் அனுபவத்துக்கு உத்தரவாதமல்ல. ஊடாடும் அமைப்புகள் சராசரியுடன் மெதுவான கோரிக்கைகளையும் ஆராய வேண்டும்; பின்னணி செயலாக்கத்துக்கு மொத்தச் செயல்திறனும் செலவும் முக்கியமாக இருக்கலாம்.

செயல்திறன் அதிகரித்தால் பயன்பாடும் விரிவடையலாம் என்ற கருத்தை Jev-இன் பெயர் நினைவூட்டுகிறது. தனி வணிகத்துக்கு இது வரவுசெலவுக் கேள்வியை எழுப்புகிறது: புதிதாக எந்த முடிவுகளை மதிப்பிடுவது பயனுள்ளதாக மாறுகிறது; தேவையில்லாமலேயே மதிப்பிடும் அளவுக்கு எவை மலிவாகின்றன? அதிகமான மாதிரி அழைப்புகள் மட்டும் முடிவல்ல.

## வெவ்வேறு ஆய்வு நோக்கம்; இன்னும் முடிக்கப்படாத ஆதாரம்

ஆராய்ச்சித் தரவு, பணி தேர்வு, RLCD ஆகியவற்றை, விருப்ப உகப்பாக்கம் குறித்த தனது விமர்சனத்துடன் Almeida இணைக்கிறார். [நேர்காணல், 7:23](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=443s) மற்றும் [22:12](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=1332s)

அளவுத்திருத்தப்பட்ட முடிவுகளுக்கான வலுவூட்டல் கற்றல் என்பதே RLCD-யின் விரிவாக்கம். மனித விருப்பம் மற்றும் சரிபார்க்கக்கூடிய வெகுமதி அணுகுமுறைகளுடன் ஒப்பிடுகையில், பயன்படுத்தக்கூடிய முடிவுகளையும் நிகழ்தகவுகளையும் நோக்கிப் பயிற்றுவிப்பதாக TypeSafe இதை முன்வைக்கிறது. அதன் நோக்கம் குறித்த நிறுவன விளக்கம் இது; முழுப் பயிற்சி முறைக்கான சுயாதீனச் சரிபார்ப்பாகப் புரிந்துகொள்ளக் கூடாது. [TypeSafe AI அறிமுக வழிகாட்டி](https://docs.typesafe.ai/introduction/machine-learning-primer)

முறையை மதிப்பிடும் போதும் பரந்த கேள்வியைத் தொடர்வது பயனுள்ளது: பயிற்சி நோக்கம் எந்த நடத்தைக்கு வெகுமதி அளிக்கிறது? நம்ப வைக்கும் விளக்கத்துக்காக உகப்பாக்கப்பட்ட மாதிரி பயன்படுத்த இனிமையாக இருக்கலாம்; ஆனால் நிரல்குறியீடு செயல்படுத்தக்கூடிய வடிவில் நிச்சயமின்மையை வெளிப்படுத்தாமல் போகலாம். முடிவை மையப்படுத்திய இடைமுகம் நிச்சயமின்மையைக் கையாள எளிதாக்கலாம்; இருப்பினும் அதன் வெளியீடுகளை நிஜத்துடன் ஒப்பிட்டு வெளிப்புறமாகச் சரிபார்க்க வேண்டும்.

விருப்ப உகப்பாக்கம், சாத்தியமான வெளியீடுகளின் வரம்பை மக்கள் பாராட்டும் பதில்களை நோக்கிச் சுருக்கலாம் என்பதுடன் இந்தக் கவலையை TypeSafe இணைக்கிறது; இதையே அது mode dropping என்கிறது. விருப்ப அடிப்படையில் பயிற்றுவிக்கப்பட்ட ஒவ்வொரு மாதிரியும் முடிவெடுக்கப் பயனற்றது என்று கண்டறிந்ததாக இதைப் புரிந்துகொள்ளக் கூடாது; தோல்வி முறைக்கான நிறுவன விளக்கம் இது. [விருப்ப உகப்பாக்கம் குறித்த TypeSafe விவாதம்](https://docs.typesafe.ai/introduction/machine-learning-primer)

இந்த வாதத்தை இன்னும் சுவாரசியமாக்குவது Almeida-வின் பின்னணி. மனிதக் கருத்தைப் பயன்படுத்தி மொழி மாதிரிகளை அறிவுறுத்தல்களைப் பின்பற்றப் பயிற்றுவித்த InstructGPT ஆய்வின் இணை ஆசிரியர் அவர். அந்த ஆசிரியர் பங்களிப்பைச் சரிபார்க்க முடியும்; ஒவ்வொரு ஆய்வகமும் தவறு செய்கிறது போன்ற பரந்த கூற்றுகள் வேறொரு விஷயம். [InstructGPT ஆய்வுக் கட்டுரை](https://arxiv.org/abs/2203.02155)

முன்பயிற்சிச் செலவுக்கும் திசையற்ற புதிய ஆய்வகங்களுக்கும் எதிரான அவரது மறுப்புகள், பயனுள்ள பணிகளைத் தேர்ந்தெடுப்பது குறித்த அதே வாதத்தின் பகுதிகள். [நேர்காணல், 1:49:32](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=6572s) மற்றும் [2:03:10](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=7390s)

வாங்குபவருக்குப் பொருத்தமான பாடம், வரையறுக்கப்பட்ட ஒரு செயல்முறைக்காக தயாரிப்பு என்ன செய்ய முடியும் என்று கேட்பதே. ஆய்வுப் பின்னணி, கணினிச் செலவு, தனித்துவமான மாதிரிக் கட்டமைப்பு ஆகியவை நிறுவனம் இந்தச் சேவையை எப்படியடைந்தது என்பதை விளக்கலாம். வேறொருவரின் வணிகத்தில் அதைப் பயன்படுத்துவதற்கான பொருளாதாரப் பலனை அவை நிறுவ முடியாது.

Almeida-வின் OpenAI விலகல், தொடக்கத் தத்தெடுப்பின் சிரமம், உருவாக்குநர் வழிநடத்தும் வளர்ச்சி ஆகியவற்றையும் நேர்காணல் பேசுகிறது. [நேர்காணல், 1:31:27](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=5487s) மற்றும் [1:56:48](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=7008s)

இந்த நினைவுகள் நிறுவனத்தின் முன்னுரிமைகளை விளக்குகின்றன; தணிக்கை செய்யப்பட்ட தத்தெடுப்பு ஆதாரம் அல்ல. இறுதியில், உருவாக்குநர் தளத்தை மதிப்பிடுவது நீடித்த பயனுள்ள பணிச்சுமைகளையும் அவை தோல்வியடையும்போது வழங்கப்படும் ஆதரவையும் வைத்தே இருக்க வேண்டும். அறிமுகத்துக்குப் பிந்தைய உற்சாகம் விசாரிக்கக் காரணம்; பதிவுக்குப் பதிலாகாது.

## புதிய உரையாடல் சாளரத்தைவிட ஏற்கெனவே உள்ள மென்பொருள் அதிகப் பலன் பெறலாம்

வலுவான SaaS தயாரிப்புகளையும் பின்னணியில் மறையும் AI-யையும் Almeida எதிர்பார்க்கிறார். [நேர்காணல், 1:19:57](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=4797s)

பயனுள்ள முடிவு அடுத்த படியை மாற்றக்கூடிய இடங்கள் மென்பொருளில் ஏற்கெனவே இருப்பதால், இது ஆராயத்தக்க நம்பகமான திசை. முன்பதிவு செய்வதற்கு முன் திட்டமற்ற கோரிக்கையை முன்பதிவு செயலி கண்டறியலாம். ஆய்வாளருக்காக ஊடகக் காப்பகம் பொருள்களை ஒழுங்குபடுத்தலாம். கவனம் தேவைப்படும் புகாரையும் வழக்கமான புதுப்பிப்பையும் சேவை மையம் வேறுபடுத்தலாம். இவை சாத்தியமான வடிவமைப்புகள்; Jev-ஐப் பயன்படுத்தியதாக அறிவிக்கப்பட்ட எடுத்துக்காட்டுகள் அல்ல.

இடைமுகம் பெரிதாக மாறாமலிருக்கலாம். குறைவான தவறுகள், மீண்டும் மீண்டும் செய்யும் வகைப்படுத்தல் குறைவு அல்லது சரியான நபருக்குக் குறைந்த காத்திருப்பு ஆகியவற்றை பயனர்கள் கவனிப்பார்கள். பணிப்பாய்வைப் புரிந்துகொண்டு சிறந்த முடிவுகளை அதில் இணைக்கக்கூடிய நிறுவனங்களுக்கு வணிக அனுகூலம் சேரலாம்.

ஏற்கெனவே உள்ள மென்பொருள் வணிகங்களும் போட்டியை எதிர்கொள்ளும். அதே முடிவை பல உருவாக்குநர்கள் எடுக்க முடிந்தால், மாதிரி அழைப்பு மட்டும் வேறுபாட்டை ஏற்படுத்தாது. பயனுள்ள தரவு அணுகல், கவனமாக வடிவமைக்கப்பட்ட தொடர்பு, வேலையை முடிக்க நம்பகமான வழி ஆகியவற்றைச் சுற்றிய தயாரிப்பு வழங்க வேண்டும்.

வேலைவாய்ப்பு குறித்த கூற்றுகளில் கூடுதல் எச்சரிக்கை தேவை. ஒரு பணியில் முயற்சியைக் குறைப்பது பணியாளர் எண்ணிக்கையை மாற்றலாம், சேவை அளவை உயர்த்தலாம் அல்லது வேலைகளை விதிவிலக்குகளுக்குத் திருப்பலாம். அந்த விளைவுகள் நிறுவனத்தையும் அதன் சேவைக்கான தேவையையும் பொறுத்தவை. குறிப்பிட்ட எண்ணிக்கையில் வேலைகள் பாதுகாக்கப்படும், நீக்கப்படும் அல்லது உருவாக்கப்படும் என்பதை நேர்காணலோ ஆரம்ப அணுகல் வெளியீடோ நிறுவவில்லை.

BIG CHANGE-இன் துறை மேலோட்டத்துக்கு, அளவிடக்கூடிய நிகழ்வு என்பது முடிவெடுப்புத் தானியக்கத்துக்கான மற்றொரு அணுகுமுறை கிடைப்பதே. பரவலான தத்தெடுப்பு, உற்பத்தித்திறன் உயர்வு, தொழிலாளர் சந்தை விளைவுகள் ஆகியவை வேறுவகை ஆதாரம் தேவைப்படும் பிந்தைய கேள்விகள்.

## இருண்ட தரவு, நிகழ்நேர மென்பொருள், செயல்விளக்கத்தின் வரம்புகள்

சேமிக்கப்பட்ட தரவு, ஊடாடும் செயலிகள், சரிபார்ப்பு, கணினிப் பயன்பாட்டுச் செயல்விளக்கங்கள் ஆகியவற்றை நேர்காணல் விவாதிக்கிறது. [நேர்காணல், 1:34:50](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=5690s)

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

கணினிப் பயன்பாட்டில், ஒரு செயலைத் தேர்ந்தெடுப்பது அமைப்பின் ஒரு பகுதி மட்டுமே. இடைமுகத்தின் துல்லியமான பிரதிநிதித்துவமும், செயலை நிறைவேற்றும் வழியும், எதிர்பார்த்த மாற்றம் நடந்ததா என்பதைச் சரிபார்ப்பதும் தேவை. ஒரு தொடர் செயல் ஒருமுறை நடந்தது என நேர்த்தியான செயல்விளக்கம் நிறுவலாம்; நம்பகமான தானியக்கத்துக்கு மீண்டும் மீண்டும் சோதிப்பதும் குறுக்கீட்டிலிருந்து மீளுவதும் அவசியம்.

விளையாட்டுகளுக்கும் அதே எச்சரிக்கை பொருந்தும். மாதிரி வழிநடத்தும் கதாபாத்திரம் அதிகத் தகவலுள்ள நிலைக்கு எதிர்வினையாற்றலாம்; சாத்தியமான செயல்களை விளையாட்டு இயந்திரம் தொடர்ந்து கட்டுப்படுத்தலாம். அது விளையாட்டை மேம்படுத்துமா என்பது பதிலளிப்பு வேகம், நிலைத்தன்மை, அனுபவ வடிவமைப்பு ஆகியவற்றைப் பொறுத்தது. ஒவ்வொரு சட்டகத்திலும் கணிப்பைச் சேர்ப்பதால் மட்டும் விளையாட்டு சுவாரசியமாகிவிடாது.

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

நுணுக்கப் பயிற்சி, பார்வைத்திறன், கூடுதல் மாதிரி வடிவங்கள் ஆகிய சாத்தியங்களை நேர்காணல் முன்வைக்கிறது. [நேர்காணல், 1:10:27](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=4227s) மற்றும் [1:26:23](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=5183s)

வெளியீட்டுத் திட்டம் குறித்த உரையாடலை, அறிமுகத் திட்டத்தின் சார்பாக மாற்றக் கூடாது. கிடைக்கும் இடைமுகத்தை மையமாக வைத்து உருவாக்குங்கள்; தனிக் கூறு எதை வழங்க வேண்டும் என அடையாளம் காணுங்கள்; புதிய திறன் உண்மையில் வந்த பிறகே அதை மதிப்பிடுங்கள். ஊகத்தைத் தயாரிப்பு அம்சமாகக் காட்டாமல், எதிர்கால மேம்பாட்டிலிருந்து பயனடைய இவ்வழி இடமளிக்கிறது.

## குறியீட்டு முகவர்கள் வேறு விதமாக வேலையைப் பிரிக்கலாம்

ஒற்றை மாதிரி சுழற்சிக்கு அப்பால், மலிவான நிலைக் கையாளுதலையும் பகிரப்பட்ட சூழலையும் குறியீட்டு முகவர்களுக்கு Almeida முன்மொழிகிறார். [நேர்காணல், 1:40:17](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=6017s) மற்றும் [2:09:29](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=7769s)

ஒரு சாத்தியமான கட்டமைப்பில், திறன்வாய்ந்த குறியீட்டு மாதிரி மாற்றத்தை உருவாக்கலாம்; தொடர்புடைய கோப்புகளை வகைப்படுத்த சிறிய முடிவு அழைப்புகள் பயன்படலாம்; அதன் பின் உருவாகும் பணிகளை வழக்கமான மென்பொருள் நிர்வகிக்கலாம். இறுதித் திருத்தத் தொகுப்பைத் தனியான மதிப்பாய்வாளர் ஆய்வு செய்யலாம். இது வடிவமைப்பு முன்மொழிவு; அளவுகோல் சோதனையில் உறுதிப்படுத்தப்பட்ட பரிந்துரையோ ஏற்கெனவே உள்ள குறியீட்டு முகவரை Jev மாற்றுகிறது என்பதற்கான ஆதாரமோ அல்ல.

தேர்ந்தெடுத்த சூழலே இதன் கவர்ச்சிகரமான பகுதி. ஒரு துணைப் பணிக்கு ஓர் இடைமுகமும் சில கட்டுப்பாடுகளும் மட்டுமே தேவைப்பட்டால், முழு உரையாடலையும் அனுப்புவது வீணாக இருக்கலாம். எந்த உண்மைகள் முக்கியம், ஏற்கெனவே எது முடிவானது, இன்னும் எந்த மாற்றங்கள் நிலுவையில் உள்ளன என்பதைத் தெளிவான பணி பதிவுகள் எளிதில் கண்டறியச் செய்யலாம்.

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

அதேபோல், முந்தைய வேலையை மலிவாக மீட்டெடுப்பது நினைவக மேலாண்மையை மேம்படுத்தலாம்; ஆனால் தொடர்ச்சியான கற்றல் என்று அழைக்கப்படும் ஒவ்வொரு பிரச்சினையையும் தீர்க்காது. முந்தைய முயற்சியை நினைவில் வைத்தல், அது ஏன் தோல்வியுற்றது என்பதைப் புரிந்துகொள்ளுதல், புதிய சூழலுக்குத் தன்னை நம்பகமாக மாற்றிக்கொள்ளுதல் ஆகியவை தனித்தனி திறன்கள். நம்பவைக்கும் மதிப்பீடு, முகவர்கள் அல்லது அழைப்புகளை எண்ணுவதற்குப் பதிலாக, முடிக்கப்பட்ட பணிகள், பின்விளைவுத் தவறுகள், முரண்பாடுகள், மனிதத் தலையீடு ஆகியவற்றைப் பார்ப்பது வேண்டும்.

## பாதுகாப்பு அமைப்பு முழுவதும் பயணிக்க வேண்டும்; மறைந்துவிடாது

மாதிரியின் மறுப்புகளைவிட செயலி மட்டத்திலான பாதுகாப்புக் கட்டுப்பாடுகளுக்கு Almeida முன்னுரிமை அளிக்கிறார்; அதன் விளைவுகளை swyx கேள்விக்குட்படுத்துகிறார். [நேர்காணல், 13:11](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=791s) மற்றும் [1:42:29](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=6149s)

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

மாதிரி நோக்கமிட்ட செயலைச் சரியாக அடையாளம் கண்டாலும், செயலி அணுகல் அனுமதிகளை அமல்படுத்த வேண்டும். ஒரு பதிவை நீக்கச் சொல்லும் கோரிக்கை தெளிவாகப் புரிந்தாலும் அனுமதியற்றதாக இருக்கலாம். தொழில்நுட்ப ரீதியாகச் செல்லுபடியாகும் கோரிக்கையும் செயல்பாட்டாளரின் கொள்கையை மீறலாம். பொருத்தமான சூழல் இல்லாமல் முடிவுச் சேவை இந்தக் கேள்விகளுக்கு பொறுப்புடன் பதிலளிக்க முடியாது; செயலி நடவடிக்கையின் மீதான கட்டுப்பாட்டைத் தக்கவைத்திருக்க வேண்டும்.

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

## பெரிய மாற்றத்தை நிரூபிப்பது எது?

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

தலையீடின்றிச் சரியாக முடிக்கப்பட்ட வழக்குகளின் விகிதம், மதிப்பாய்வைத் தாண்டிச் செல்லும் பிழைகள், மக்களிடம் அனுப்பப்படும் பணிச்சுமை, முடிக்கப்பட்ட ஒவ்வொரு வழக்கிற்குமான மொத்தச் செலவு ஆகியவற்றை அளவிடுங்கள். முடிவு ஏன் ஏற்கப்பட்டது என்பதை மதிப்பாய்வாளர் ஆராய அசல் ஆதாரத்தை வைத்திருங்கள். மாதிரி, கொள்கை அல்லது உள்ளீட்டு மக்கள்தொகை மாறும்போது ஒப்பீட்டை மீண்டும் செய்யுங்கள்.

செயல்முறையின் ஒரு பகுதி மட்டுமே தயாராக உள்ளது என்பதை இந்த மதிப்பீடு காட்டலாம். அதுவும் பயனுள்ள முடிவே. தெளிவற்ற வழக்குகளை அனுபவமுள்ள செயல்பாட்டாளரிடம் வைத்தபடி வழக்கமான வகைப்படுத்தலை மட்டும் தானியக்கமாக்குவது, பரந்த தன்னாட்சியை நியாயப்படுத்தாமலேயே பயனளிக்கலாம்.

AI பொருளாதாரத்துக்குள் நுழையும் விதம் குறித்த இலட்சியமிக்க கருதுகோளை Jev அறிமுகமும் Almeida நேர்காணலும் முன்வைக்கின்றன: மீண்டும் மீண்டும் நடைபெறும், வரையறுக்கப்பட்ட முடிவுகள், மக்கள் ஏற்கெனவே சார்ந்திருக்கும் மென்பொருளைத் திறன்வாய்ந்ததாக்கலாம். காலப்போக்கில் அந்த வேலையைச் செய்யும் அமைப்புகளிலிருந்தே அடுத்த ஆதாரம் வர வேண்டும்; கணக்கில் பிழைகளும் விதிவிலக்குகளும் சேர்க்கப்பட வேண்டும். சுவாரசியமான மாதிரிக் கட்டமைப்பு, வாசகர்கள் நேரில் காணக்கூடிய மாற்றமாக மாறுவது அங்குதான்.

## Sources

- [அசல் Latent Space நேர்காணல்](https://www.youtube.com/watch?v=cFx9Z3ZXca0) — 2026 செப்டம்பர் 21 அன்று வெளியான Diogo Almeida-வுடனான Latent Space நேர்காணல். இந்தப் பகுப்பாய்வு முழுவதும் நேரம்குறிக்கப்பட்ட இணைப்புகள் இடம்பெறுகின்றன.
- [System One Models & Jev அறிமுகம்](https://typesafe.ai/blog/introducing-system-one-models-and-jev) — 2026 செப்டம்பர் 15. Jev-க்கான TypeSafe-இன் ஆரம்ப அணுகல் அறிவிப்பு; அதன் செயல்திறன் கூற்றுகளும் மதிப்பீட்டு வரம்புகளும் அடங்கும்.
- [அறிமுகம்](https://docs.typesafe.ai/introduction) — மாதிரியின் உள்ளீட்டு நிலையையும் Choice, Score, Noul கேள்விகளையும் TypeSafe ஆவணம் விளக்குகிறது.
- [நம்பிக்கை](https://docs.typesafe.ai/confidence) — நம்பிக்கையையும் நிகழ்தகவையும் வேறுபடுத்தி, செயலிகள் வரம்புகளை எவ்வாறு பயன்படுத்தலாம் என்பதை TypeSafe ஆவணம் விளக்குகிறது.
- [AI அறிமுக வழிகாட்டி](https://docs.typesafe.ai/introduction/machine-learning-primer) — பயிற்சி நோக்கத்தையும் கணிப்புக் குழுக்களுக்கிடையிலான அளவுத்திருத்தத்தையும் TypeSafe விளக்குகிறது.
- [வடிவங்கள்](https://docs.typesafe.ai/patterns) — மாதிரி முடிவுகளை செயலி தர்க்கத்துடன் இணைப்பதற்கான எடுத்துக்காட்டுகளை TypeSafe வழங்குகிறது.
- [API-யில் கட்டமைக்கப்பட்ட வெளியீடுகளை அறிமுகப்படுத்துதல்](https://openai.com/index/introducing-structured-outputs-in-the-api/) — 2024 ஆகஸ்ட் 6. Schema-வால் கட்டுப்படுத்தப்பட்ட வெளியீடுகளையும் அவற்றின் வரம்புகளையும் OpenAI அறிமுகப்படுத்திய அறிவிப்பு.
- [நவீன நரம்பியல் வலைப்பின்னல்களின் அளவுத்திருத்தம்](https://arxiv.org/abs/1706.04599) — நரம்பியல் வலைப்பின்னல்களின் அளவுத்திருத்தம் குறித்த Chuan Guo மற்றும் சக ஆசிரியர்களின் 2017 ஆய்வு. இந்தக் கட்டுரை Jev-ஐ மதிப்பிடவில்லை.
- [மனிதக் கருத்தைப் பயன்படுத்தி அறிவுறுத்தல்களைப் பின்பற்றும் மொழி மாதிரிகளுக்குப் பயிற்சி அளித்தல்](https://arxiv.org/abs/2203.02155) — மனிதக் கருத்தைப் பயன்படுத்தி அறிவுறுத்தல்களைப் பின்பற்றுவது குறித்த Diogo Almeida இணை எழுதிய 2022 InstructGPT ஆய்வுக் கட்டுரை.