Free lesson · GenAI Solutions Architecture

ADR முடிவுகளை production telemetry-க்கு எதிராக சரிபார்த்தல்

ஏற்றுக்கொள்ளப்பட்ட ADR-களின் பின்னணியில் உள்ள அனுமானங்கள் (assumptions) இன்னும் செல்லுபடியாகின்றனவா என்பதை live production telemetry-உடன் ஒப்பிட்டு தொடர்ந்து சரிபார்க்கும் ஒரு DecisionValidator-ஐ நீங்கள் உருவாக்குவீர்கள். ADRAssumption-ஐ பின்வரும் fields கொண்ட ஒரு Pydantic model ஆக implement செய்யுங்கள்: assumption_id: str, adr_id: str, description: str, metric_name: str, operator: ComparisonOperator (LT, GT, LTE, GTE, EQ, BETWEEN), threshold: float, upper_bound: Optional[float] (BETWEEN operator-க்காக), measurement_window: timedelta, data_source: DataSource (PROMETHEUS, POSTGRESQL, LANGFUSE). ஏற்றுக்கொள்ளப்பட்ட ஒரு ADR-இன் context மற்றும் decision fields-ஐ litellm.completion() மற்றும் Instructor-ஐப் பயன்படுத்தி parse செய்து, சோதிக்கக்கூடிய அனுமானங்களை structured ADRAssumption objects ஆக பிரித்தெடுக்கும் extract_assumptions()-ஐ உருவாக்குங்கள்; இது assumptions: list[ADRAssumption], confidence: float, unextractable_claims: list[str] கொண்ட ExtractionResult-ஐ return செய்ய வேண்டும். ஒவ்வொரு அனுமானத்தின் metric_name-ஐயும் measurement_window காலத்திற்கு prometheus_api_client வழியாக Prometheus-இல் query செய்து, PromQL expressions-க்கு custom_query()-ஐப் பயன்படுத்தி, குறிப்பிடப்பட்ட operator-ஐ வைத்து முடிவை threshold-உடன் ஒப்பிட்டு, is_valid: bool, actual_value: float, deviation_pct: float, trend_direction: TrendDirection (IMPROVING, STABLE, DEGRADING) கொண்ட ValidationResult-ஐ return செய்யும் validate_assumptions()-ஐ implement செய்யுங்கள். validate_assumptions()-ஐ configure செய்யக்கூடிய ஒரு schedule-இல் (check_interval_hours: int வழியாக, default ஆக ஒவ்வொரு 6 மணி நேரத்திற்கும் ஒருமுறை) இயக்கும் check_staleness() கொண்ட StalenessDetector-ஐ உருவாக்குங்கள்; ஏதேனும் ஒரு அனுமானம் consecutive_failures_threshold (default 3) தொடர்ச்சியான checks-களில் validation-இல் தோல்வியடைந்தால், அந்த ADR-களை STALE என குறிக்க வேண்டும். consecutive_failures: int, last_valid_at: datetime, staleness_score: float ஆகியவற்றைக் கண்காணிக்கும் StalenessState-ஐ implement செய்யுங்கள். Validation history-ஐ PostgreSQL adr_validations table-இல் பின்வரும் columns-உடன் சேமியுங்கள்: validation_id VARCHAR(64) PRIMARY KEY, adr_id VARCHAR(64) REFERENCES architecture_decisions(adr_id), assumption_id VARCHAR(64), checked_at TIMESTAMPTZ, is_valid BOOLEAN, actual_value FLOAT, deviation_pct FLOAT, trend_direction VARCHAR(16). திறமையான history queries-க்காக idx_adr_validations_adr_id_checked_at index-ஐ உருவாக்குங்கள். பின்வரும் Prometheus metrics-ஐ emit செய்யுங்கள்: adr_validation_checks_total{adr_id,result}, adr_staleness_score{adr_id} (0-1 gauge; 1 என்றால் எல்லா அனுமானங்களும் செல்லுபடியானவை), adr_assumption_deviation_pct{adr_id,assumption_id}. adr_staleness_score 30 நிமிடங்களுக்கு மேல் 0.5-க்குக் கீழே இறங்கும்போது warning severity-உடன் ADRStale alert-ஐ fire செய்யும் Alertmanager rules-ஐ configure செய்யுங்கள். Validation history மற்றும் தற்போதைய staleness score-ஐ return செய்யும் GET /api/v1/adrs/{adr_id}/validation FastAPI endpoint-ஐ உருவாக்குங்கள். பிரித்தெடுக்கப்பட்ட எல்லா அனுமானங்களையும் அவற்றின் சமீபத்திய validation status-உடன் return செய்யும் GET /api/v1/adrs/{adr_id}/assumptions endpoint-ஐ உருவாக்குங்கள். எல்லா ADR-களிலும் உள்ள validation results-ஐ ஒருங்கிணைத்து, category வாரியான assumption pass rates, 30 நாட்களுக்கான staleness trends, மற்றும் அதிகம் செல்லுபடியற்றதாக்கப்பட்ட முடிவுகளின் ranked table ஆகியவற்றைக் காட்டும் ஒரு Grafana dashboard ஆக வழங்கும் DecisionEffectivenessScorecard-ஐ implement செய்யுங்கள்.

Course: GenAI Architecture & Design Patterns · Chapter 1 · GenAI ADR Engine

Free to read — no subscription required.

Continue with Google

அறிமுகம்

ஒரு RAG பைப்லைன், ஒரு ஹோஸ்ட் செய்யப்பட்ட மாடல் தேர்வு, அல்லது ஒரு லேட்டன்சி பட்ஜெட்டை வெளியிடும் குழுக்கள், அமைப்பு நேரலையில் வந்த பிறகு அந்த ADR-களை அரிதாகவே மீண்டும் பார்க்கின்றன — ஆனால் அவற்றின் கீழே உள்ள உற்பத்தி சூழல் தினமும் மாறிக்கொண்டே இருக்கிறது. ஆறு மாதங்களுக்கு முன்பு அதிநவீனமாக இருந்த ஒரு மாடலை இப்போது 40% குறைந்த செலவில் சமன் செய்ய முடியும்; வெளியீட்டின் போது p99 லேட்டன்சியை வசதியாகப் பூர்த்தி செய்த ஒரு எம்பெடிங் சேவை, வழங்குநர் மறுவழிப்படுத்தலுக்குப் பிறகு அதை அமைதியாக மீறக்கூடும். கட்டமைப்பு ஆவணமும் இயங்கும் அமைப்பும் முரண்படும்போது, செலவு மிகைப்பாடுகள், பழையதாகிவிட்ட மாடல் தேர்வுகள், அல்லது கூட்டிக்கொண்டே போகும் SLA தவறுதல்கள் கீழ்நிலையில் வெளிப்படும் வரை ஆவணம் அமைதியாகத் தோற்றுப்போகிறது. இந்தப் பாடத்தின் முடிவில், ஒவ்வொரு ADR-க்குள் இருக்கும் அனுமானங்களைச் சோதிக்கக்கூடிய முன்னுரைகளாக (predicates) குறியாக்கம் செய்யவும், அவற்றை ஒரு அட்டவணையின்படி நேரலை டெலிமெட்ரிக்கு எதிராக மதிப்பிடவும், பழையதாகிவிட்டவை கட்டமைப்புக் கடனாகக் குவிவதற்கு முன்பே அவற்றை ஒரு நிர்வாக மதிப்பாய்வு சுழற்சிக்கு வழிநடத்தவும் உங்களால் முடியும்.

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

ADR Assumption: ஒரு Architecture Decision Record-இல் இருந்து பிரித்தெடுக்கப்பட்ட, கட்டமைக்கப்பட்ட, இயந்திரத்தால் சரிபார்க்கக்கூடிய ஒரு முன்னுரை — ஒரு மெட்ரிக் பெயர், ஒரு ஒப்பீட்டு நிபந்தனை, ஒரு வரம்பு (threshold), மற்றும் ஒரு சகிப்புத்தன்மை பட்டை — இதை நேரலை டெலிமெட்ரிக்கு எதிராக மதிப்பிட முடியும்.
Tolerance Band: ஒரு வரம்பைச் சுற்றியுள்ள சதவீத விளிம்பு; இதற்குள் ஒரு கவனிக்கப்பட்ட மெட்ரிக் VIOLATED என்பதற்குப் பதிலாக DEGRADED என வகைப்படுத்தப்படும், இதனால் சிறிய மாறுபாட்டால் ஏற்படும் இரைச்சலான தவறான எச்சரிக்கைகள் தடுக்கப்படுகின்றன.
Staleness Threshold (max_violations_before_stale): சுற்றியுள்ள ADR பழையதாகிவிட்டது எனக் குறிக்கப்பட்டு நிர்வாக மதிப்பாய்வு பணிப்பாய்வுக்கு வழிநடத்தப்படுவதற்கு முன், ஒரு அனுமானம் குவிக்க வேண்டிய தொடர்ச்சியான சரிபார்ப்புத் தோல்விகளின் எண்ணிக்கை.

கருத்துகள்

நடைமுறை வரிசைப்படுத்தல் பரிசீலனைகள்

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

max_violations_before_stale அளவுருவை ஒவ்வொரு அனுமான வகைக்கும் ஏற்ப சரிசெய்ய வேண்டும். மாடல் தர அனுமானங்கள் (BLEU மதிப்பெண், மனித விருப்ப மதிப்பீடுகள்) அதிக தொடர்ச்சியான மீறல்களை—ஒருவேளை 5 முதல் 7 வரை—பொறுத்துக்கொள்ள வேண்டும், ஏனெனில் தர மெட்ரிக்குகள் இயல்பாகவே அதிக இரைச்சல் கொண்டவை. செலவு அனுமானங்கள் 2 முதல் 3 வரையிலான குறைந்த வரம்பைப் பயன்படுத்த வேண்டும், ஏனெனில் செலவு மிகைப்பாடுகள் விரைவாகக் கூட்டிக்கொண்டே போகின்றன மற்றும் அரிதாகவே தாமாகத் திருத்திக்கொள்கின்றன.

ஒவ்வொரு ValidationResult-ஐயும் மூல டெலிமெட்ரியுடன் சேர்த்து ஒரு time-series தரவுத்தளத்தில் சேமிக்கவும். இந்த வரலாற்றுப் பதிவு, பரிந்துரை இயந்திரம் பருவகால வடிவங்களை அடையாளம் காண உதவுகிறது—batch செயலாக்கச் சுமையின் காரணமாக ஒவ்வொரு திங்கட்கிழமை காலையிலும் மீறப்படும் ஒரு அனுமானம் உண்மையில் பழையதாகிவிட்டது அல்ல; அதற்கு உச்ச சாளரங்களுக்கான வேறு வரம்பு தேவை. இந்த வரலாறு இல்லாமல், நிர்வாக டாஷ்போர்டு, கட்டமைப்பாளர்கள் புறக்கணிக்கக் கற்றுக்கொள்ளும் மதிப்பாய்வு கோரிக்கைகளை உருவாக்குகிறது, இது முழு சரிபார்ப்பு அமைப்பையும் பலவீனப்படுத்துகிறது.

இறுதியாக, பழைமை எச்சரிக்கைகளை உங்கள் தற்போதைய முடிவு வகைப்பாட்டுடன் (decision taxonomy) ஒருங்கிணைக்கவும். "model selection" வகையின் கீழ் உள்ள ஒரு பழைய அனுமானம் ML தள குழுவுக்கு வழிநடத்தப்பட வேண்டும், அதே நேரத்தில் ஒரு பழைய "hosting strategy" அனுமானம் உள்கட்டமைப்புக் குழுவுக்கு வழிநடத்தப்படும். நிர்வாக டாஷ்போர்டில் உள்ள காலாவதி கண்காணிப்புடன் இணைந்த இந்த வழிநடத்தல், பழைய முடிவுகள் ஒரு பகிரப்பட்ட வரிசையில் தேங்கிப்போகாமல், அவற்றின் மீது செயல்படுவதற்கான அதிகாரமும் சூழலும் கொண்ட பொறியாளர்களை அடைவதை உறுதி செய்கிறது.

Loading diagram...

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

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

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

Code snippetpython
1from dataclasses import dataclass
2from enum import Enum
3
4class MetricCondition(Enum):
5    LESS_THAN = "less_than"
6    GREATER_THAN = "greater_than"
7    WITHIN_RANGE = "within_range"
8
9class AssumptionStatus(Enum):
10    CONFIRMED = "confirmed"
11    DEGRADED = "degraded"
12    VIOLATED = "violated"
13    UNKNOWN = "unknown"
14
15@dataclass
16class ADRAssumption:
17    assumption_id: str
18    adr_id: str
19    metric_name: str
20    condition: MetricCondition
21    threshold: float
22    tolerance_pct: float = 0.10
23    status: AssumptionStatus = AssumptionStatus.UNKNOWN
24    consecutive_violations: int = 0
25    max_violations_before_stale: int = 3
26
27    @property
28    def is_stale(self) -> bool:
29        return self.consecutive_violations >= self.max_violations_before_stale
30
31    def effective_threshold(self) -> float:
32        return self.threshold * (1.0 + self.tolerance_pct)

tolerance_pct புலம் இயல்பாக 10% ஆக உள்ளது, எனவே 200ms வரம்பு ஒரு மீறலாகக் கணக்கிடப்படுவதற்கு முன் 220ms வரையிலான கவனிக்கப்பட்ட மதிப்புகளைப் பொறுத்துக்கொள்கிறது, மேலும் is_stale என்பது max_violations_before_stale தொடர்ச்சியான தோல்விகளுக்குப் பிறகே செயல்படுகிறது — ஒரு தனி மோசமான தரவுப் புள்ளி மதிப்பாய்வைத் தூண்டுவதைத் தடுக்கிறது.

அனுமானங்கள் தரவாக மாடல் செய்யப்பட்ட பிறகு, DecisionValidator ஒரு டெலிமெட்ரி மதிப்பைப் பெற்று, அதை confirmed, degraded, அல்லது violated மண்டலத்தில் வைத்து, கவுண்டரைப் புதுப்பித்து, நிர்வாக அடுக்கு சேமிப்பதற்காக ஒரு ValidationResult-ஐத் திருப்பித் தருகிறது.

Code snippetpython
1from dataclasses import dataclass
2
3@dataclass
4class ValidationResult:
5    assumption_id: str
6    observed: float
7    status: AssumptionStatus
8
9def validate(assumption: ADRAssumption, observed: float) -> ValidationResult:
10    if observed <= assumption.threshold:
11        status = AssumptionStatus.CONFIRMED
12        assumption.consecutive_violations = 0
13    elif observed <= assumption.effective_threshold():
14        status = AssumptionStatus.DEGRADED
15    else:
16        status = AssumptionStatus.VIOLATED
17        assumption.consecutive_violations += 1
18    assumption.status = status
19    return ValidationResult(assumption.assumption_id, observed, status)

ஒவ்வொரு ValidationResult-ஐயும் மூல டெலிமெட்ரியுடன் சேர்த்து ஒரு time-series தரவுத்தளத்தில் சேமிக்கவும், இதனால் நிர்வாக பணிப்பாய்வு உண்மையிலேயே பழையதாகிவிட்ட ஒரு அனுமானத்தை, மீண்டும் மீண்டும் வரும் திங்கட்கிழமை காலை batch உச்சத்திலிருந்து வேறுபடுத்தி அறிய முடியும். சகிப்புத்தன்மை பட்டைக்குள் உள்ள ஒரு மெட்ரிக் DEGRADED-ஐத் திருப்பித் தரும்போதும், அதற்கு அப்பால் உள்ள ஒரு மெட்ரிக் VIOLATED-ஐத் திருப்பித் தரும்போதும், மூன்று தொடர்ச்சியான VIOLATED முடிவுகள் is_stale-ஐ True ஆக மாற்றி ADR-ஐ மதிப்பாய்வுக்கு வழிநடத்தும்போதும், அது வேலை செய்கிறது என்பதை நீங்கள் அறிந்துகொள்வீர்கள்.

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

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

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

ஒவ்வொரு ADR-இன் முக்கியமான (load-bearing) அனுமானங்களையும் ADRAssumption முன்னுரைகளாகக் குறியாக்கம் செய்யுங்கள் — metric_name, condition, மற்றும் threshold ஆகியவற்றைக் குறிப்பிடுவது, "மீட்டெடுப்பு லேட்டன்சி 200ms-க்குக் கீழே இருக்கும்" போன்ற உரையை, validate() நேரலை டெலிமெட்ரிக்கு எதிராக ஒரு அட்டவணையின்படி தானாகத் தரப்படுத்தக்கூடிய சோதிக்கக்கூடிய உண்மையாக மாற்றுகிறது, இதனால் மாற்றம் (drift) கட்டமைப்புக் கடனாகக் குவிவதற்கு முன்பே வெளிப்படுகிறது.
ஒவ்வொரு அனுமானத்திற்கும் tolerance_pct-ஐ வேண்டுமென்றே சரிசெய்யுங்கள் — இயல்புநிலை 10%, ஒரு மீறலைக் கணக்கிடுவதற்கு முன் effective_threshold() மூலம் 200ms வரம்பு 220ms வரையிலான கவனிக்கப்பட்ட மதிப்புகளைப் பொறுத்துக்கொள்ள அனுமதிக்கிறது; அதிக இயற்கையான மாறுபாடு கொண்ட RAG லேட்டன்சி அனுமானங்களுக்கு, கணிக்கக்கூடிய அடிப்படைகள் கொண்ட செலவு அனுமானங்களை விட அகலமான பட்டை தேவை, எனவே உண்மையான மாற்றத்தை மறைக்காமல் இயல்பான ஏற்ற இறக்கத்தை உள்வாங்கும் வகையில் ஒவ்வொன்றையும் அளவீடு செய்யுங்கள்.
ஒவ்வொரு ValidationResult-ஐயும் மூல டெலிமெட்ரியுடன் சேர்த்து ஒரு time-series தரவுத்தளத்தில் நிலைநிறுத்துங்கள் — நிர்வாக மதிப்பாய்வு பணிப்பாய்வுக்கு, உண்மையிலேயே பழையதாகிவிட்ட ஒரு அனுமானத்தை, பல மதிப்பீட்டு சுழற்சிகளில் consecutive_violations இயற்கையாகவே உள்வாங்கும் மீண்டும் மீண்டும் வரும் batch-சாளர உச்சத்திலிருந்து வேறுபடுத்த, சரிபார்ப்பு நிலை வரலாறு மற்றும் அடிப்படை மெட்ரிக் மதிப்புகள் இரண்டும் தேவை.

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

ஒரே ஒரு VIOLATED முடிவின் அடிப்படையில் ஒரு ADR-ஐ நிர்வாக மதிப்பாய்வுக்கு வழிநடத்த வேண்டாம் — max_violations_before_stale (இயல்புநிலை 3) நீடித்த மீறல்களுக்குப் பிறகே is_stale True ஆக மாறும் என்பதை உறுதி செய்வதற்காகவே consecutive_violations உள்ளது; ஒரு ஒழுங்கற்ற டெலிமெட்ரி மாதிரியை பழைமைச் சமிக்ஞையாகக் கருதுவது மதிப்பாய்வு வரிசையைத் தவறான நேர்மறைகளால் நிரப்பி, குழுக்கள் அதைப் புறக்கணிக்கப் பழக்கப்படுத்துகிறது.
ADR அனுமானங்களை முடிவுப் பதிவில் உரை வாக்கியங்களாக விட்டுவிட வேண்டாம் — அவற்றை வெளிப்படையான metric_name மற்றும் condition புலங்களுடன் ADRAssumption நிகழ்வுகளாகக் கட்டமைக்காவிட்டால், validate()-க்கு மதிப்பிட எதுவும் இல்லை, எனவே செலவு 40% உயர்ந்த ஒரு மாடல் அல்லது தனது p99 பட்ஜெட்டை அமைதியாக மீறிய ஒரு எம்பெடிங் சேவை, கீழ்நிலை செலவு மிகைப்பாடு அல்லது SLA தவறுதல் அதை வெளிப்படுத்தும் வரை கண்ணுக்குத் தெரியாமலே இருக்கும்.
ஒரு DEGRADED முடிவை CONFIRMED-க்குச் சமமாகக் கருத வேண்டாம் — கவனிக்கப்பட்ட மதிப்பு threshold மற்றும் effective_threshold() இடையே விழும்போது consecutive_violations-ஐ மீட்டமைப்பதை சரிபார்ப்பான் வேண்டுமென்றே தவிர்க்கிறது; degraded மண்டலத்தில் தொடர்ந்து தங்கியிருக்கும் ஒரு மெட்ரிக் பழைமையை நோக்கிய பாதையில் உள்ளது, மேலும் கவுண்டரைச் செயற்கையாக அழிப்பது, தொடர்ந்து மோசமாகச் செயல்படும் ஒரு அனுமானத்தை நிர்வாகத்திலிருந்து காலவரையின்றி தப்பிக்க அனுமதிக்கும்.

3 hands-on labs come with this lesson — real code, in a cloud IDE. Create a free account to run them. No card.

Continue with Google Use email or company SSO instead →

Free account · no card · straight to the labs

Or get the full path — from

Listen to this lesson

Audio overviews of this lesson's labs and its chapter, from GenBodha Bytes.

Build decision validation framework comparing ADR assumptions to metricsLab6 min
Implement ADR staleness detection with drift alertsLab6 min
Create decision effectiveness scorecard with measured outcomesLab6 min
GenAI ADR EngineChapter overview23 min

More free lessons in GenAI Architecture & Design Patterns

Ch 1Build ADR schema and decision taxonomy for GenAI technology choices
Ch 1Validate ADR decisions against production telemetryYou are here
Ch 1Implement ADR recommendation engine using historical outcomes
Ch 1Create ADR governance dashboard and compliance audit
Ch 4Build eval gate component with pluggable evaluator registry
Ch 4Measure eval gate effectiveness with precision-recall tracking
Ch 4Create eval architecture audit report with coverage analysis

All free lessons in GenAI Solutions Architecture →