ભારિત બહુ-માપદંડ મૂલ્યાંકન સાથે AI ઉપયોગ-કેસોને સ્કોર કરો

પરિચય

જ્યારે તમે ક્લાયન્ટ ડિસ્કવરી વર્કશોપ ચલાવી રહ્યા હોવ, ત્યારે વીસ AI ઉપયોગ-કેસોની તુલના માત્ર અંતઃપ્રેરણાથી કરવાથી તકો ચૂકી જવાય છે અને રોકાણોની પ્રાથમિકતા ખોટી ગોઠવાય છે. સંસ્થાઓને દરેક ઉમેદવારને એવા પરિમાણો પર સ્કોર કરવા માટે એક પુનરાવર્તનીય, વસ્તુલક્ષી પદ્ધતિની જરૂર છે જે ખરેખર પ્રોડક્શન સફળતાની આગાહી કરે — માત્ર એક્ઝિક્યુટિવ ઉત્સાહ અથવા એન્જિનિયરિંગ નવીનતા નહીં. આ પાઠના અંત સુધીમાં, તમે એક ભારિત સ્કોરિંગ એન્જિન બનાવી શકશો જે દરેક ઉપયોગ-કેસનું બિઝનેસ પ્રભાવ, ટેકનિકલ શક્યતા, ડેટા તૈયારી અને મૂલ્ય-સુધીનો-સમય પર મૂલ્યાંકન કરે, અને સંરચિત LLM આઉટપુટ દ્વારા સમર્થિત એક ક્રમાંકિત શોર્ટલિસ્ટ બનાવે જેના પર તમારા ક્લાયન્ટો તરત જ કાર્ય કરી શકે.

મુખ્ય પરિભાષા

• Weighted Scoring Engine (ભારિત સ્કોરિંગ એન્જિન) — એક સિસ્ટમ જે દરેક AI ઉપયોગ-કેસનું નામાંકિત પરિમાણો પર મૂલ્યાંકન કરે છે, દરેક પરિમાણના સ્કોરને કન્ફિગર કરેલા વજન સાથે ગુણે છે, અને ગુણાકારોનો સરવાળો કરીને એક જ weighted_total ફ્લોટ બનાવે છે જે ડિસ્કવરી વર્કશોપમાં સામે આવેલા તમામ ઉમેદવારોનું વસ્તુલક્ષી, તુલનાત્મક ક્રમાંકન શક્ય બનાવે છે.
• CriterionScore — એક Pydantic મોડેલ જે એક મૂલ્યાંકન પરિમાણના આઉટપુટનું પ્રતિનિધિત્વ કરે છે: એક સીમિત સંખ્યાત્મક score (0–10), એક confidence મૂલ્ય (0–1), અને રેટિંગ સમજાવતી ફ્રી-ટેક્સ્ટ reasoning સ્ટ્રિંગ; દરેક UseCaseEvaluationની અંદર ચાર CriterionScore એન્ટ્રીઓ — દરેક પરિમાણ માટે એક — એકત્રિત કરવામાં આવે છે.
• UseCaseEvaluation — ટોપ-લેવલ Pydantic સ્કીમા જે સ્કોરિંગ એન્જિન એક ઉમેદવાર માટે પરત કરે છે, જેમાં CriterionScore એન્ટ્રીઓની યાદી, એક weighted_total ફ્લોટ, એક recommendation સ્ટ્રિંગ અને એક risks યાદી હોય છે — તાત્કાલિક ક્રમાંકન માટે તૈયાર સંપૂર્ણ સંરચિત નિર્ણય.
• ScoringCriteria — એક Pydantic મોડેલ જે ચાર કન્ફિગર કરી શકાય તેવા પરિમાણ વજન ધરાવે છે (business_impact_weight, technical_feasibility_weight, data_readiness_weight, time_to_value_weight); ડિફૉલ્ટ મૂલ્યો (0.35 / 0.25 / 0.25 / 0.15) બિઝનેસ પ્રભાવને પ્રાધાન્ય આપે છે જ્યારે ટેકનિકલ શક્યતા અને ડેટા તૈયારીને સમાન રીતે ગણે છે.
• Instructor — એક Python લાઇબ્રેરી જે instructor.from_openai() દ્વારા સ્ટાન્ડર્ડ OpenAI ક્લાયન્ટને પેચ કરે છે, 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 ફ્લોટને બદલે ટકાવારી સ્ટ્રિંગ તરીકે ફોર્મેટ કરે. ઉકેલ એ છે કે અપેક્ષિત આઉટપુટને Pydantic સ્કીમા તરીકે વ્યાખ્યાયિત કરવું — CriterionScore એક પરિમાણ દર્શાવે, UseCaseEvaluation સંપૂર્ણ નિર્ણયને એકત્રિત કરે — અને OpenAI ક્લાયન્ટને તેનો અમલ કરાવવા માટે Instructorનો ઉપયોગ કરવો.

instructor.from_openai() સ્ટાન્ડર્ડ ક્લાયન્ટને એવી રીતે પેચ કરે છે કે chat.completions.create()માં response_model=UseCaseEvaluation પસાર કરવું જનરેશન-પછીના વેલિડેટર તરીકે કાર્ય કરે છે: જો મોડેલનું JSON માન્ય UseCaseEvaluation ઇન્સ્ટન્સમાં પાર્સ ન થાય, તો Instructor ભૂલ બતાવતા પહેલાં આપમેળે ફરી પ્રયાસ કરે છે. ફાયદો એ છે કે તમને સંપૂર્ણ ટાઇપ કરેલો Python ઑબ્જેક્ટ મળે છે જેને તમે તરત જ અન્ય ઉમેદવારો સાથે સૉર્ટ કરી શકો અને ક્લાયન્ટ રિપોર્ટમાં સિરિયલાઇઝ કરી શકો — કોઈ regex નહીં, કોઈ સ્ટ્રિંગ પાર્સિંગ નહીં, અને ફ્રીફોર્મ ટેક્સ્ટમાં હોય કે ન હોય તેવા ફીલ્ડ પર કોઈ રક્ષણાત્મક null-ચેક નહીં (કોડ વૉકથ્રૂ જુઓ).

કોડ વૉકથ્રૂ

હવે જ્યારે તમે ચાર ભારિત સ્કોરિંગ પરિમાણો સમજી ગયા છો, ચાલો એવું એન્જિન અમલમાં મૂકીએ જે વર્કશોપમાં સામે આવતા દરેક ઉપયોગ-કેસ પર તેમને વ્યવસ્થિત રીતે લાગુ કરે.

પાઇપલાઇનના બે ભાગ છે: મૂલ્યાંકન સ્કીમાને વ્યાખ્યાયિત કરતા Pydantic મોડેલોનો સમૂહ, અને Instructor-પેચ કરેલો OpenAI ક્લાયન્ટ જે LLMને ફ્રીફોર્મ ટેક્સ્ટને બદલે તે સ્કીમાનું માન્ય ઇન્સ્ટન્સ પરત કરવા મજબૂર કરે છે.

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 વચ્ચેનો ફ્લોટ છે.

શિસ્ત-વિશિષ્ટ ઉપયોગ

શું કરવું અને શું ન કરવું

ઉપરની સામગ્રીમાંથી પસાર થયા બાદ, નીચેના "શું કરવું" અને "શું ન કરવું" તેને વ્યવહારમાં સંક્ષિપ્ત કરે છે.

શું કરવું

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 એન્ટ્રીઓ અથવા None જેવા weighted_total સાથે અપૂર્ણ 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 અગાઉના ઉપયોગ-કેસના ડેટાથી દૂષિત થાય છે, જે ગેરમાર્ગે દોરતી શોર્ટલિસ્ટ બનાવે છે.