எடையிடப்பட்ட பல-அளவுகோல் மதிப்பீட்டுடன் AI பயன்பாட்டு நிகழ்வுகளுக்கு மதிப்பெண் வழங்குதல்

அறிமுகம்

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

முக்கிய சொற்கள்

• Weighted Scoring Engine (எடையிடப்பட்ட மதிப்பெண் இயந்திரம்) — ஒவ்வொரு AI பயன்பாட்டு வழக்கையும் பெயரிடப்பட்ட பரிமாணங்களின் அடிப்படையில் மதிப்பிடும், ஒவ்வொரு பரிமாணத்தின் மதிப்பெண்ணையும் கட்டமைக்கப்பட்ட எடையால் பெருக்கும், அந்தப் பெருக்கற்பலன்களைக் கூட்டி ஒரே weighted_total float ஆக மாற்றும் ஒரு அமைப்பு; இது ஒரு கண்டறிதல் பட்டறையில் வெளிப்படும் அனைத்து வேட்பாளர்களையும் புறநிலையாக, ஒப்பிடக்கூடிய வகையில் தரவரிசைப்படுத்த உதவுகிறது.
• CriterionScore — ஒரு மதிப்பீட்டுப் பரிமாணத்தின் வெளியீட்டைக் குறிக்கும் Pydantic மாடல்: எல்லைக்குட்பட்ட எண் score (0–10), ஒரு confidence மதிப்பு (0–1), மற்றும் மதிப்பீட்டை விளக்கும் சுதந்திர-உரை reasoning சரம்; ஒவ்வொரு UseCaseEvaluation-க்குள்ளும் நான்கு CriterionScore உள்ளீடுகள் — ஒரு பரிமாணத்திற்கு ஒன்று — சேகரிக்கப்படுகின்றன.
• UseCaseEvaluation — ஒரு வேட்பாளருக்காக மதிப்பெண் இயந்திரம் திருப்பித் தரும் உயர்மட்ட Pydantic ஸ்கீமா; இதில் CriterionScore உள்ளீடுகளின் பட்டியல், ஒரு weighted_total float, ஒரு recommendation சரம், மற்றும் ஒரு risks பட்டியல் உள்ளன — உடனடித் தரவரிசைப்படுத்தலுக்குத் தயாரான முழுமையான கட்டமைக்கப்பட்ட தீர்ப்பு.
• ScoringCriteria — நான்கு கட்டமைக்கக்கூடிய பரிமாண எடைகளை (business_impact_weight, technical_feasibility_weight, data_readiness_weight, time_to_value_weight) வைத்திருக்கும் Pydantic மாடல்; இயல்புநிலை மதிப்புகள் (0.35 / 0.25 / 0.25 / 0.15) வணிகத் தாக்கத்திற்கு முன்னுரிமை அளிக்கின்றன, அதே நேரத்தில் தொழில்நுட்ப சாத்தியக்கூறையும் தரவுத் தயார்நிலையையும் சமச்சீராக நடத்துகின்றன.
• Instructor — instructor.from_openai() மூலம் ஒரு நிலையான OpenAI கிளையண்டைப் பேட்ச் செய்யும் Python நூலகம்; இது chat.completions.create()-க்கு ஸ்கீமா அமலாக்கத்தைச் சேர்க்கிறது, இதனால் LLM-இன் பதில் ஒரு response_model Pydantic வகுப்பிற்கு எதிராகச் சரிபார்க்கப்பட்டு, தவறான வடிவ வெளியீட்டில் தானாகவே மீண்டும் முயற்சிக்கப்படுகிறது — மூல உரைக்குப் பதிலாக ஒரு வகைப்படுத்தப்பட்ட Python ஆப்ஜெக்ட் திருப்பித் தரப்படுகிறது.

கருத்துகள்

மதிப்பெண்ணிடுதல் ஒரு பொறியியல் ஒழுங்குமுறையாக

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

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

நான்கு பரிமாணங்கள் மற்றும் இயல்புநிலை மதிப்புகள் ஏன் அவ்வாறு அமைக்கப்பட்டுள்ளன

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

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

Pydantic + Instructor ஒரு சரிபார்ப்பு வாயிலாக

ஸ்கீமா அமலாக்கம் இல்லாமல், LLM-ஆதரவு மதிப்பெண் இயந்திரம் நம்பகமற்றது: மாடல் ஒரு மதிப்பெண்ணை ஒரு வாக்கியமாக வெளிப்படுத்தலாம், ஒரு பரிமாணத்தை முழுவதுமாக விட்டுவிடலாம், அல்லது confidence-ஐ 0–1 float-க்குப் பதிலாக ஒரு சதவீதச் சரமாக வடிவமைக்கலாம். தீர்வு என்னவென்றால், எதிர்பார்க்கப்படும் வெளியீட்டை ஒரு Pydantic ஸ்கீமாவாக வரையறுப்பது — CriterionScore ஒரு பரிமாணத்தைப் பிடிக்கிறது, UseCaseEvaluation முழுத் தீர்ப்பையும் ஒருங்கிணைக்கிறது — மற்றும் OpenAI கிளையண்ட் அதை அமல்படுத்த Instructor-ஐப் பயன்படுத்துவது.

instructor.from_openai() நிலையான கிளையண்டைப் பேட்ச் செய்கிறது, இதனால் chat.completions.create()-க்கு response_model=UseCaseEvaluation-ஐ அனுப்புவது உருவாக்கத்திற்குப் பிந்தைய சரிபார்ப்பானாகச் செயல்படுகிறது: மாடலின் JSON சரியான UseCaseEvaluation நிகழ்வாகப் பாகுபடுத்தப்படவில்லை என்றால், Instructor பிழையை வெளிப்படுத்துவதற்கு முன்பு தானாகவே மீண்டும் முயற்சிக்கிறது. இதன் பலன் என்னவென்றால், மற்ற வேட்பாளர்களுடன் உடனடியாக வரிசைப்படுத்தி ஒரு வாடிக்கையாளர் அறிக்கையாகச் சீரியலைஸ் செய்யக்கூடிய முழுமையாக வகைப்படுத்தப்பட்ட Python ஆப்ஜெக்ட் — regex இல்லை, சரம் பாகுபடுத்தல் இல்லை, சுதந்திர உரை உள்ளடக்கியிருக்கலாம் அல்லது இல்லாமலிருக்கலாம் என்ற புலங்களில் தற்காப்பு null-சோதனைகள் இல்லை (குறியீடு விளக்கம் பார்க்கவும்).

குறியீடு விளக்கம்

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

குழாய் இரண்டு பகுதிகளைக் கொண்டுள்ளது: மதிப்பீட்டு ஸ்கீமாவை வரையறுக்கும் Pydantic மாடல்களின் தொகுப்பு, மற்றும் சுதந்திர உரைக்குப் பதிலாக அந்த ஸ்கீமாவின் சரிபார்க்கப்பட்ட நிகழ்வை LLM திருப்பித் தர வற்புறுத்தும் Instructor-பேட்ச் செய்யப்பட்ட OpenAI கிளையண்ட்.

CriterionScore ஒரு பரிமாணத்தின் வெளியீட்டைப் பிடிக்கிறது — எல்லைக்குட்பட்ட மதிப்பெண் (0–10), நம்பிக்கை மதிப்பு (0–1), மற்றும் சுதந்திர-உரை reasoning புலம். UseCaseEvaluation இந்த அளவுகோல் மதிப்பெண்களை ஒரு weighted_total, ஒரு recommendation, மற்றும் risks பட்டியலாக ஒருங்கிணைக்கிறது. ScoringCriteria கட்டமைக்கக்கூடிய எடைகளை வைத்திருக்கிறது; இயல்புநிலை மதிப்புகள் (0.35 / 0.25 / 0.25 / 0.15) வணிகத் தாக்கத்திற்கு முன்னுரிமை அளிக்கின்றன, தொழில்நுட்ப சாத்தியக்கூறையும் தரவுத் தயார்நிலையையும் சமமாக எடையிடுகின்றன, மதிப்பை அடையும் நேரம் மிகக் குறைந்த எடையுள்ள காரணியாக உள்ளது.

Code snippetpython
1from pydantic import BaseModel, Field
2from typing import List
3
4class CriterionScore(BaseModel):
5    criterion: str
6    score: float = Field(ge=0, le=10)
7    confidence: float = Field(ge=0, le=1)
8    reasoning: str
9
10class UseCaseEvaluation(BaseModel):
11    use_case_name: str
12    scores: List[CriterionScore]
13    weighted_total: float
14    recommendation: str
15    risks: List[str]
16
17class ScoringCriteria(BaseModel):
18    business_impact_weight: float = 0.35
19    technical_feasibility_weight: float = 0.25
20    data_readiness_weight: float = 0.25
21    time_to_value_weight: float = 0.15

ஸ்கீமா தயாரானவுடன், instructor.from_openai() நிலையான OpenAI கிளையண்டைப் பேட்ச் செய்கிறது, இதனால் chat.completions.create() திருப்பித் தருவதற்கு முன்பு மாடலின் பதிலை response_model=UseCaseEvaluation-க்கு எதிராகச் சரிபார்க்கிறது. மாடல் தவறான வடிவ வெளியீட்டை உருவாக்கினால், Instructor தானாகவே மீண்டும் முயற்சிக்கிறது. இதன் முடிவு, மற்ற வேட்பாளர்களுடன் உடனடியாக வரிசைப்படுத்தக்கூடிய வகைப்படுத்தப்பட்ட UseCaseEvaluation ஆப்ஜெக்ட் — கைமுறை உரை பாகுபடுத்தல் தேவையில்லை.

Code snippetpython
1import instructor
2import openai
3
4proxy_url = "http://openai-proxy:8080"
5scoring_prompt = (
6    "Evaluate this AI use case across Business Impact, Technical Feasibility, "
7    "Data Readiness, and Time-to-Value. Score each dimension 0–10 with reasoning."
8)
9use_case_description = (
10    "Automate invoice extraction from scanned PDFs using a vision model."
11)
12
13client = instructor.from_openai(
14    openai.OpenAI(api_key="student-token", base_url=proxy_url)
15)
16
17evaluation = client.chat.completions.create(
18    model="gpt-4o",
19    response_model=UseCaseEvaluation,
20    messages=[
21        {"role": "system", "content": scoring_prompt},
22        {"role": "user", "content": use_case_description},
23    ],
24)
25
26print(evaluation.use_case_name, evaluation.weighted_total, evaluation.recommendation)
27for s in evaluation.scores:
28    print(f"  {s.criterion}: {s.score}/10 (confidence {s.confidence:.2f}) — {s.reasoning}")

ஸ்கிரிப்டை இயக்கி, evaluation.scores-இல் நான்கு CriterionScore உள்ளீடுகள் — ஒவ்வொரு எடையிடப்பட்ட பரிமாணத்திற்கும் ஒன்று — இருப்பதையும், evaluation.weighted_total 0 மற்றும் 10-க்கு இடையிலான float ஆக இருப்பதையும் உறுதிப்படுத்தி சரிபார்க்கவும்.

துறைசார் பயன்பாடு

செய்ய வேண்டியவை மற்றும் செய்யக்கூடாதவை

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

செய்ய வேண்டியவை

1. CriterionScore மற்றும் UseCaseEvaluation-ஐ எல்லைக்குட்பட்ட Field கட்டுப்பாடுகளுடன் Pydantic மாடல்களாக வரையறுக்கவும் — score-இல் ge=0, le=10 எல்லையும் confidence-இல் ge=0, le=1 எல்லையும் பாகுபடுத்தும் நேரத்தில் பொருள்சார் செல்லுபடித்தன்மையை அமல்படுத்துகின்றன, இதனால் 15 என்ற மாயத்தோற்ற மதிப்பெண் அல்லது 2.0 என்ற நம்பிக்கை மதிப்பு, தவறான மதிப்பு உங்கள் தரவரிசைத் தர்க்கத்தை அடைவதற்கு முன்பே சரிபார்ப்புப் பிழையை எழுப்புகிறது.
2. OpenAI கிளையண்டை instructor.from_openai() மூலம் பேட்ச் செய்து response_model=UseCaseEvaluation-ஐ அனுப்பவும் — இது சுதந்திர உரைக்குப் பதிலாக கட்டமைக்கப்பட்ட, வகைப்படுத்தப்பட்ட நிகழ்வை LLM திருப்பித் தர வற்புறுத்துகிறது, கைமுறை JSON பாகுபடுத்தலை நீக்குகிறது, மேலும் தவறான வடிவ மாடல் வெளியீட்டிலிருந்து தானாக மீள Instructor-க்குத் தேவையான மீள்முயற்சி ஹூக்கை வழங்குகிறது.
3. ஒரு பட்டறையை நடத்துவதற்கு முன் ScoringCriteria எடைகளை வேண்டுமென்றே சீரமைக்கவும் — இயல்புநிலை மதிப்புகள் (0.35 / 0.25 / 0.25 / 0.15) வணிகத் தாக்கம் மதிப்பை அடையும் நேரத்தை விட அதிக முக்கியத்துவம் பெறுகிறது என்ற வெளிப்படையான முன்அனுமானத்தைப் பொதிந்து வைக்கின்றன; வாடிக்கையாளர் அடிப்படைக் காரணம் இல்லாமல் அவற்றை மாற்றுவது தரவரிசைப்படுத்தப்பட்ட சுருக்கப்பட்டியலை அமைதியாக மாற்றி, இயந்திரம் வழங்க வடிவமைக்கப்பட்ட மீண்டும் செய்யக்கூடிய தன்மையைக் குலைக்கிறது.

செய்யக்கூடாதவை

1. response_model ஆர்குமெண்டை விட்டுவிட்டு LLM-இன் உரைப் பதிலைக் கைமுறையாகப் பாகுபடுத்த வேண்டாம் — அவ்வாறு செய்வது Instructor-இன் சரிபார்ப்பு-மற்றும்-மீள்முயற்சி சுழற்சியைத் தவிர்க்கிறது, அதாவது ஒரே ஒரு தவறான வடிவ முடிவு, scores உள்ளீடுகள் இல்லாத அல்லது weighted_total None ஆக உள்ள முழுமையற்ற UseCaseEvaluation-ஐ அமைதியாக உருவாக்கி, பிழையை எழுப்பாமலே தரவரிசைப்படுத்தப்பட்ட வெளியீட்டைச் சிதைக்கிறது.
2. ScoringCriteria எடைகளைப் பயன்படுத்தாமல் மூல CriterionScore.score மதிப்புகளைக் கூட்டி கிளையண்ட் பக்கத்தில் weighted_total-ஐக் கணக்கிட அனுமதிக்க வேண்டாம் — 0.35 / 0.25 / 0.25 / 0.15 பெருக்கிகளைப் புறக்கணிப்பது நான்கு பரிமாணங்களையும் சம முக்கியத்துவத்திற்குச் சுருக்குகிறது; இது தொழில்நுட்ப ரீதியாக எளிதான ஆனால் குறைந்த மதிப்புள்ள வேட்பாளர்களை விட மிகப்பெரிய வணிகத் தாக்கமுள்ள பயன்பாட்டு வழக்குகளை வெளிப்படுத்தும் மாடலின் திறனைத் தோற்கடிக்கிறது.
3. ஒரே UseCaseEvaluation நிகழ்வை அதன் புலங்களை மாற்றியமைத்து பல பயன்பாட்டு வழக்கு விளக்கங்களுக்கு மீண்டும் பயன்படுத்த வேண்டாம் — client.chat.completions.create()-க்கான ஒவ்வொரு அழைப்பும் புதிய use_case_description-ஐப் பெற்று புதிய UseCaseEvaluation ஆப்ஜெக்டைத் திருப்பித் தர வேண்டும்; வேட்பாளர்களுக்கிடையே மதிப்பீட்டு ஆப்ஜெக்ட்களை மீண்டும் பயன்படுத்துவது அல்லது நகலெடுப்பது risks பட்டியலையும் recommendation-ஐயும் முந்தைய பயன்பாட்டு வழக்கின் தரவால் சிதைத்து, தவறாக வழிநடத்தும் சுருக்கப்பட்டியலை உருவாக்குகிறது.