Free lesson · GenAI Solutions Architecture
ADR నిర్ణయాలను production telemetry తో ధృవీకరించండి
మీరు ఒక DecisionValidator ను నిర్మిస్తారు, ఇది ఆమోదించబడిన ADRల వెనుక ఉన్న ఊహలు (assumptions) ఇప్పటికీ నిలుస్తున్నాయో లేదో live production telemetry తో పోల్చి నిరంతరం తనిఖీ చేస్తుంది. 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). extract_assumptions() ను నిర్మించండి, ఇది ఆమోదించబడిన ADR యొక్క context మరియు decision fields ను litellm.completion() ను Instructor తో ఉపయోగించి parse చేసి, పరీక్షించదగిన ఊహలను structured ADRAssumption objects గా సంగ్రహిస్తుంది, మరియు assumptions: list[ADRAssumption], confidence: float, unextractable_claims: list[str] తో ExtractionResult ను తిరిగి ఇస్తుంది. validate_assumptions() ను implement చేయండి, ఇది ప్రతి assumption యొక్క 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 ను తిరిగి ఇస్తుంది. StalenessDetector ను check_staleness() తో నిర్మించండి, ఇది validate_assumptions() ను configurable schedule లో నడుపుతుంది (check_interval_hours: int ద్వారా default గా ప్రతి 6 గంటలకు ఒకసారి) మరియు ఏదైనా assumption consecutive_failures_threshold (default 3) వరుస తనిఖీలలో validation విఫలమైతే ADRలను STALE గా గుర్తిస్తుంది. consecutive_failures: int, last_valid_at: datetime, staleness_score: float ను track చేసే StalenessState ను implement చేయండి. Validation చరిత్రను 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 అంటే అన్ని assumptions చెల్లుబాటు అవుతున్నాయని అర్థం), adr_assumption_deviation_pct{adr_id,assumption_id}. adr_staleness_score 30 నిమిషాల కంటే ఎక్కువ సేపు 0.5 కంటే తక్కువగా పడిపోయినప్పుడు warning severity తో ADRStale alert ను fire చేసే Alertmanager rules ను configure చేయండి. Validation చరిత్రను మరియు ప్రస్తుత staleness score ను తిరిగి ఇచ్చే GET /api/v1/adrs/{adr_id}/validation FastAPI endpoint ను నిర్మించండి. సంగ్రహించిన అన్ని assumptions ను వాటి తాజా validation status తో తిరిగి ఇచ్చే GET /api/v1/adrs/{adr_id}/assumptions endpoint ను నిర్మించండి. అన్ని ADRల validation ఫలితాలను ఒక Grafana dashboard లోకి సమీకరించే DecisionEffectivenessScorecard ను implement చేయండి, ఇది category వారీగా assumption pass rates, 30 రోజుల staleness trends, మరియు అత్యధికంగా చెల్లకుండా పోయిన నిర్ణయాల ranked table ను చూపిస్తుంది.
Course: GenAI Architecture & Design Patterns · Chapter 1 · GenAI ADR Engine
Free to read — no subscription required.
పరిచయం
RAG పైప్లైన్, హోస్టెడ్-మోడల్ ఎంపిక, లేదా లేటెన్సీ బడ్జెట్ను షిప్ చేసే టీమ్లు సిస్టమ్ లైవ్ అయిన తర్వాత ఆ ADRలను చాలా అరుదుగా మళ్లీ పరిశీలిస్తాయి — అయితే వాటి కింద ఉన్న ప్రొడక్షన్ పర్యావరణం రోజూ మారుతూ ఉంటుంది. ఆరు నెలల క్రితం అత్యాధునికంగా ఉన్న మోడల్ను ఇప్పుడు 40% తక్కువ ఖర్చుతో సరిపోల్చవచ్చు; లాంచ్ సమయంలో p99 లేటెన్సీని సౌకర్యంగా చేరుకున్న ఎంబెడ్డింగ్ సర్వీస్, ప్రొవైడర్ రీరూట్ తర్వాత నిశ్శబ్దంగా దాన్ని ఉల్లంఘించవచ్చు. ఆర్కిటెక్చర్ డాక్యుమెంట్ మరియు నడుస్తున్న సిస్టమ్ ఒకదానితో ఒకటి విభేదించినప్పుడు, ఖర్చు మితిమీరడం, పాతబడిన మోడల్ ఎంపికలు, లేదా పేరుకుపోయే SLA వైఫల్యాలు దిగువన బయటపడే వరకు డాక్యుమెంట్ నిశ్శబ్దంగా ఓడిపోతుంది. ఈ పాఠం ముగిసే సమయానికి, ప్రతి ADR లోపల ఉన్న ఊహలను పరీక్షించదగిన ప్రిడికేట్లుగా ఎన్కోడ్ చేయడం, వాటిని షెడ్యూల్ ప్రకారం లైవ్ టెలిమెట్రీతో మూల్యాంకనం చేయడం, మరియు పాతబడిన వాటిని ఆర్కిటెక్చరల్ డెట్గా పేరుకుపోయే ముందు గవర్నెన్స్ రివ్యూ లూప్లోకి పంపడం మీరు చేయగలుగుతారు.
కీలక పదజాలం
- ADR Assumption: ఆర్కిటెక్చర్ డెసిషన్ రికార్డ్ నుండి సంగ్రహించిన, నిర్మాణాత్మకమైన, మెషీన్-చెక్ చేయదగిన ప్రిడికేట్ — ఒక మెట్రిక్ పేరు, ఒక పోలిక షరతు, ఒక థ్రెషోల్డ్, మరియు ఒక టాలరెన్స్ బ్యాండ్ — దీన్ని లైవ్ టెలిమెట్రీతో మూల్యాంకనం చేయవచ్చు.
- Tolerance Band: థ్రెషోల్డ్ చుట్టూ ఉన్న శాతం మార్జిన్, దీని లోపల గమనించిన మెట్రిక్ VIOLATED కాకుండా DEGRADED గా వర్గీకరించబడుతుంది, చిన్న వైవిధ్యాల వల్ల వచ్చే గందరగోళ తప్పుడు అలారాలను నివారిస్తుంది.
- Staleness Threshold (
max_violations_before_stale): చుట్టూ ఉన్న ADR పాతబడినదిగా గుర్తించబడి గవర్నెన్స్ రివ్యూ వర్క్ఫ్లోలోకి పంపబడే ముందు ఒక ఊహ పేర్చుకోవాల్సిన వరుస ధృవీకరణ వైఫల్యాల సంఖ్య.
భావనలు
ఆచరణాత్మక డిప్లాయ్మెంట్ పరిగణనలు
ప్రొడక్షన్లో టెలిమెట్రీ ధృవీకరణను డిప్లాయ్ చేసేటప్పుడు, మీ టెలిమెట్రీ అగ్రిగేషన్ విండోలకు అనుగుణంగా ఉన్న వ్యవధుల్లో ధృవీకరణ రన్లను షెడ్యూల్ చేయండి. మీ మెట్రిక్స్ బ్యాకెండ్ 5-నిమిషాల వ్యవధుల్లో అగ్రిగేట్ చేస్తే, ప్రతి నిమిషం ధృవీకరణ నడపడం పాక్షిక విండోల ఆధారంగా గందరగోళ ఫలితాలను ఇస్తుంది. 5-నిమిషాల అగ్రిగేటెడ్ మెట్రిక్స్తో 15-నిమిషాల ధృవీకరణ కేడెన్స్ స్థిరమైన రీడింగ్లను అందిస్తూనే వేగవంతమైన క్షీణతను కూడా పట్టుకుంటుంది.
max_violations_before_stale పారామీటర్ను ప్రతి ఊహ వర్గానికి తగినట్లుగా ట్యూన్ చేయాలి. మోడల్ క్వాలిటీ ఊహలు (BLEU స్కోర్, మానవ ప్రాధాన్యత రేటింగ్లు) మరిన్ని వరుస ఉల్లంఘనలను సహించాలి—బహుశా 5 నుండి 7—ఎందుకంటే క్వాలిటీ మెట్రిక్స్ స్వతహాగా ఎక్కువ గందరగోళంగా ఉంటాయి. ఖర్చు ఊహలు 2 నుండి 3 అనే తక్కువ థ్రెషోల్డ్ను ఉపయోగించాలి, ఎందుకంటే ఖర్చు మితిమీరడం వేగంగా పేరుకుపోతుంది మరియు చాలా అరుదుగా తనంతట తానే సరిదిద్దుకుంటుంది.
ప్రతి ValidationResult ను ముడి టెలిమెట్రీతో పాటు టైమ్-సిరీస్ డేటాబేస్లో నిల్వ చేయండి. ఈ చారిత్రక రికార్డు రికమెండేషన్ ఇంజిన్కు కాలానుగుణ నమూనాలను గుర్తించడానికి వీలు కల్పిస్తుంది—బ్యాచ్ ప్రాసెసింగ్ లోడ్ కారణంగా ప్రతి సోమవారం ఉదయం ఉల్లంఘించే ఊహ నిజంగా పాతబడినది కాదు; దానికి పీక్ విండోల కోసం వేరే థ్రెషోల్డ్ అవసరం. ఈ చరిత్ర లేకుండా, గవర్నెన్స్ డాష్బోర్డ్ ఆర్కిటెక్ట్లు పట్టించుకోకుండా అలవాటు పడే రివ్యూ అభ్యర్థనలను సృష్టిస్తుంది, ఇది మొత్తం ధృవీకరణ సిస్టమ్ను బలహీనపరుస్తుంది.
చివరగా, పాతబడిన-స్థితి అలర్ట్లను మీ ప్రస్తుత నిర్ణయ వర్గీకరణతో అనుసంధానించండి. "మోడల్ ఎంపిక" వర్గం కింద పాతబడిన ఊహ ML ప్లాట్ఫారమ్ టీమ్కు వెళ్లాలి, అయితే పాతబడిన "హోస్టింగ్ వ్యూహం" ఊహ ఇన్ఫ్రాస్ట్రక్చర్ టీమ్కు వెళ్లాలి. గవర్నెన్స్ డాష్బోర్డ్లోని గడువు ట్రాకింగ్తో కలిపిన ఈ రూటింగ్, పాతబడిన నిర్ణయాలు ఒక షేర్డ్ క్యూలో నిరుపయోగంగా పడి ఉండకుండా, వాటిపై చర్య తీసుకునే అధికారం మరియు సందర్భం ఉన్న ఇంజినీర్లకు చేరేలా చూస్తుంది.
కోడ్ వాక్త్రూ
ధృవీకరణ కేడెన్స్, టాలరెన్స్ ట్యూనింగ్, మరియు పాతబడిన-స్థితి రూటింగ్ ఈ సిస్టమ్ యొక్క ప్రొడక్షన్ ప్రవర్తనను ఎలా రూపొందిస్తాయో ఇప్పుడు మీరు చూశారు కాబట్టి, కింద ఉన్న కోడ్ ఆ యంత్రాంగాలను రెండు భాగాలుగా వ్యక్తపరుస్తుంది: ఒక టైప్డ్ ఊహ మోడల్, మరియు దాన్ని టెలిమెట్రీతో గ్రేడ్ చేసి గవర్నెన్స్ కోసం ValidationResult ను విడుదల చేసే వాలిడేటర్.
ప్రతి ఆర్కిటెక్చర్ నిర్ణయం ఊహలపై ఆధారపడి ఉంటుంది. ఒక ADR ఫైన్-ట్యూనింగ్ కంటే 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 ను ముడి టెలిమెట్రీతో పాటు టైమ్-సిరీస్ డేటాబేస్లో నిల్వ చేయండి. టాలరెన్స్ బ్యాండ్ లోపల ఉన్న మెట్రిక్ DEGRADED ను తిరిగి ఇచ్చినప్పుడు, దానికి మించిన మెట్రిక్ VIOLATED ను తిరిగి ఇచ్చినప్పుడు, మరియు మూడు వరుస VIOLATED ఫలితాలు is_stale ను True కి మార్చి ADRను రివ్యూలోకి పంపినప్పుడు ఇది పనిచేస్తుందని మీకు తెలుస్తుంది.
విభాగ అనువర్తనం
చేయవలసినవి మరియు చేయకూడనివి
చేయవలసినవి
- ప్రతి ADR యొక్క కీలకమైన ఊహలను
ADRAssumptionప్రిడికేట్లుగా ఎన్కోడ్ చేయండి —metric_name,condition, మరియుthresholdను పేర్కొనడం "రిట్రీవల్ లేటెన్సీ 200ms కింద ఉంటుంది" లాంటి గద్యాన్నిvalidate()షెడ్యూల్ ప్రకారం లైవ్ టెలిమెట్రీతో ఆటోమేటిక్గా గ్రేడ్ చేయగల పరీక్షించదగిన వాస్తవంగా మారుస్తుంది, తద్వారా డ్రిఫ్ట్ ఆర్కిటెక్చరల్ డెట్గా పేరుకుపోయే ముందు బయటపడుతుంది. - ప్రతి ఊహకు
tolerance_pctను ఉద్దేశపూర్వకంగా ట్యూన్ చేయండి — డిఫాల్ట్ 10% ఒక 200ms థ్రెషోల్డ్కు ఉల్లంఘనగా లెక్కించే ముందుeffective_threshold()ద్వారా 220ms వరకు గమనించిన విలువలను సహించేలా చేస్తుంది; అధిక సహజ వైవిధ్యం ఉన్న RAG లేటెన్సీ ఊహలకు ఊహించదగిన బేస్లైన్లు ఉన్న ఖర్చు ఊహల కంటే విస్తృతమైన బ్యాండ్ అవసరం, కాబట్టి నిజమైన డ్రిఫ్ట్ను దాచకుండా సాధారణ హెచ్చుతగ్గులను శోషించుకునేలా ప్రతి ఒక్కదాన్ని క్యాలిబ్రేట్ చేయండి. - ప్రతి
ValidationResultను ముడి టెలిమెట్రీతో పాటు టైమ్-సిరీస్ డేటాబేస్లో నిల్వ చేయండి — నిజంగా పాతబడిన ఊహను,consecutive_violationsఅనేక మూల్యాంకన సైకిళ్లలో సహజంగా శోషించుకునే పునరావృత బ్యాచ్-విండో స్పైక్ నుండి వేరు చేయడానికి గవర్నెన్స్ రివ్యూ వర్క్ఫ్లోకు ధృవీకరణ స్థితి చరిత్ర మరియు అంతర్లీన మెట్రిక్ విలువలు రెండూ అవసరం.
చేయకూడనివి
- ఒకే ఒక
VIOLATEDఫలితంపై ADRను గవర్నెన్స్ రివ్యూలోకి పంపకండి —consecutive_violationsప్రత్యేకంగాis_staleకేవలంmax_violations_before_stale(డిఫాల్ట్ 3) నిరంతర ఉల్లంఘనల తర్వాతేTrueకి మారేలా ఉంది; ఒక అసాధారణ టెలిమెట్రీ నమూనాను పాతబడిన-స్థితి సంకేతంగా పరిగణించడం రివ్యూ క్యూను తప్పుడు పాజిటివ్లతో నింపి, టీమ్లు దాన్ని పట్టించుకోకుండా అలవాటు పడేలా చేస్తుంది. - 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.
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.
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