सारांश:
- केवल पारंपरिक LLM benchmarks से टूल उपयोग और multi-step reasoning करने वाले 'AI agents' की performance को सटीक रूप से मापना कठिन है।
- एजेंट evaluation में software testing की तरह unit tests और integration tests दोनों को मिलाकर उपयोग करना चाहिए।
- deterministic code grading और LLM-आधारित model grading को मिलाकर उपयोग करना प्रभावी है।
- एजेंट development lifecycle के अनुसार 'Capability Evals' से 'Regression Evals' की ओर शिफ्ट करना ज़रूरी है।
विस्तृत सारांश:
-
AI एजेंट evaluation कठिन क्यों है
साधारण chatbot (single-turn) के विपरीत, agents tools का उपयोग करते हैं, environment की state बदलते हैं, और कई चरणों (multi-turn) में काम पूरा करते हैं। इसलिए केवल अंतिम उत्तर देखना पर्याप्त नहीं है; यह भी समग्र रूप से आकलन करना होता है कि एजेंट ने सही tool का उपयोग किया या नहीं, प्रक्रिया कितनी efficient थी, आदि। -
एजेंट eval की संरचना
एक प्रभावी evaluation system निम्नलिखित मुख्य तत्वों से बनता है।
- Task: परिभाषित input और success criteria वाला एक single test case।
- Grader: एजेंट के execution result को score करने वाला logic।
- Transcript: एजेंट की reasoning process, tool calls, intermediate results आदि सहित पूरा execution record।
- Outcome: एजेंट execution के बाद environment की अंतिम state में हुए बदलाव (उदाहरण: क्या वास्तविक DB में reservation बनाया गया?).
- Grader प्रकारों की तुलना
Anthropic तीन प्रकार के graders को मिलाकर उपयोग करने की सिफारिश करता है।
| प्रकार | विवरण | फायदे | नुकसान |
|---|---|---|---|
| Code-based | string matching, regex, static analysis, unit test execution आदि | तेज़, सस्ता, objective, reproducible | जटिल nuances छूट सकते हैं, flexibility कम |
| Model-based | LLM को judge की तरह उपयोग करके rubric-आधारित scoring | flexible, nuances समझ सकता है, open-ended questions के लिए उपयुक्त | non-deterministic हो सकता है, महंगा, human calibration की ज़रूरत |
| Human | expert review, crowd sourcing | quality का 'gold standard' | बहुत धीमा और बहुत महंगा |
- Coding agent evaluation का उदाहरण (YAML configuration)
Coding agent का मूल्यांकन करते समय केवल यह देखना पर्याप्त नहीं कि code चलता है या नहीं (deterministic test); coding style या security violations हैं या नहीं (static analysis/LLM grading) यह भी साथ में देखना चाहिए। नीचे 'security vulnerability fix' task के लिए एक काल्पनिक evaluation setting का उदाहरण है।
task:
id: "fix-auth-bypass_1"
desc: "비밀번호 필드가 비어있을 때 발생하는 인증 우회 취약점 수정"
graders:
# 1. 결정론적 테스트: 실제 테스트 코드가 통과하는지 확인
- type: deterministic_tests
required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]
# 2. LLM 루브릭 채점: 코드 품질 및 스타일 평가
- type: llm_rubric
rubric: prompts/code_quality.md
# 3. 정적 분석: 린터(Linter) 및 보안 도구 실행
- type: static_analysis
commands: [ruff, mypy, bandit]
# 4. 상태 확인: 보안 로그가 제대로 남았는지 확인
- type: state_check
expect:
security_logs: {event_type: "auth_blocked"}
# 5. 도구 사용 확인: 필요한 파일을 읽고 수정했는지
- type: tool_calls
required:
- {tool: read_file, params: {path: "src/auth/*"}}
- {tool: edit_file}
- {tool: run_tests}
# ट्रैक किए जाने वाले metrics
tracked_metrics:
- type: transcript
metrics:
- n_turns # turns की संख्या
- n_toolcalls # tool calls की संख्या
- n_total_tokens # token usage
- type: latency
metrics:
- time_to_first_token
- मूल्यांकन metrics
एजेंट की non-deterministic प्रकृति को संभालने के लिए केवल accuracy के अलावा निम्न metrics भी उपयोग किए जाते हैं।
- pass@k: k प्रयासों में कम-से-कम एक बार सफल होने की probability (exploration ability मापने के लिए)।
- pass^k: k प्रयासों में सभी प्रयास सफल होने की probability (consistency/reliability मापने के लिए)।
- Tools और frameworks
Evaluation system बनाने के लिए Harbor (container environment execution), Promptfoo (YAML-आधारित test configuration), Braintrust, LangSmith जैसे tools का उपयोग करने या टीम के workflow के अनुरूप अपना framework बनाने का सुझाव दिया गया है। महत्वपूर्ण framework स्वयं नहीं, बल्कि high-quality test cases सुनिश्चित करना है।
अभी कोई टिप्पणी नहीं है.