Free lesson · GenAI Solutions Architecture

ADR નિર્ણયોને પ્રોડક્શન ટેલિમેટ્રી સામે માન્ય કરો

તમે એક DecisionValidator બનાવશો જે સ્વીકૃત ADRs પાછળની ધારણાઓ હજી પણ સાચી છે કે નહીં તે લાઇવ પ્રોડક્શન ટેલિમેટ્રી સાથે તુલના કરીને સતત તપાસે છે. ADRAssumption ને Pydantic મોડેલ તરીકે આ ફીલ્ડ્સ સાથે અમલમાં મૂકો: 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 ફીલ્ડ્સને litellm.completion() અને Instructor નો ઉપયોગ કરીને પાર્સ કરે, પરીક્ષણ કરી શકાય તેવી ધારણાઓને સ્ટ્રક્ચર્ડ ADRAssumption ઓબ્જેક્ટ્સ તરીકે કાઢે, અને assumptions: list[ADRAssumption], confidence: float, unextractable_claims: list[str] સાથે ExtractionResult પરત કરે. validate_assumptions() અમલમાં મૂકો જે દરેક ધારણાના metric_name માટે measurement_window દરમિયાન prometheus_api_client દ્વારા Prometheus ને ક્વેરી કરે, 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() હોય, જે કન્ફિગર કરી શકાય તેવા શેડ્યૂલ પર (check_interval_hours: int દ્વારા ડિફૉલ્ટ દર 6 કલાકે) validate_assumptions() ચલાવે અને જ્યારે કોઈ પણ ધારણા consecutive_failures_threshold (ડિફૉલ્ટ 3) સળંગ તપાસોમાં માન્યતામાં નિષ્ફળ જાય ત્યારે ADRs ને STALE તરીકે ચિહ્નિત કરે. consecutive_failures: int, last_valid_at: datetime, staleness_score: float ને ટ્રૅક કરતું StalenessState અમલમાં મૂકો. માન્યતા ઇતિહાસને PostgreSQL ના adr_validations ટેબલમાં આ કૉલમ્સ સાથે સંગ્રહો: 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). કાર્યક્ષમ ઇતિહાસ ક્વેરીઝ માટે idx_adr_validations_adr_id_checked_at ઇન્ડેક્સ બનાવો. Prometheus મેટ્રિક્સ ઉત્સર્જિત કરો: adr_validation_checks_total{adr_id,result}, adr_staleness_score{adr_id} (0-1 gauge જેમાં 1 નો અર્થ છે કે બધી ધારણાઓ માન્ય છે), adr_assumption_deviation_pct{adr_id,assumption_id}. Alertmanager નિયમો કન્ફિગર કરો જે adr_staleness_score 30 મિનિટથી વધુ સમય માટે 0.5 થી નીચે જાય ત્યારે warning severity સાથે ADRStale alert ફાયર કરે. માન્યતા ઇતિહાસ અને વર્તમાન staleness score પરત કરતો GET /api/v1/adrs/{adr_id}/validation FastAPI endpoint બનાવો. બધી કાઢેલી ધારણાઓને તેમની નવીનતમ માન્યતા સ્થિતિ સાથે પરત કરતો GET /api/v1/adrs/{adr_id}/assumptions endpoint બનાવો. DecisionEffectivenessScorecard અમલમાં મૂકો જે બધા ADRs ના માન્યતા પરિણામોને એક Grafana dashboard માં એકત્રિત કરે, જે કેટેગરી દીઠ ધારણા pass rates, 30 દિવસના staleness trends, અને સૌથી વધુ અમાન્ય ઠરેલા નિર્ણયોનું ક્રમાંકિત ટેબલ દર્શાવે.

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

Free to read — no subscription required.

Continue with Google

પરિચય

જે ટીમો RAG પાઇપલાઇન, હોસ્ટેડ-મોડેલ પસંદગી અથવા લેટન્સી બજેટ શિપ કરે છે તે સિસ્ટમ લાઇવ થયા પછી ભાગ્યે જ તે ADRs પર પુનર્વિચાર કરે છે — તેમ છતાં તેની નીચેનું પ્રોડક્શન વાતાવરણ દરરોજ બદલાતું રહે છે. છ મહિના પહેલાં અત્યાધુનિક ગણાતું મોડેલ હવે 40% ઓછા ખર્ચે મેળવી શકાય છે; લોન્ચ સમયે p99 લેટન્સીને આરામથી પૂરી કરતી એમ્બેડિંગ સેવા પ્રોવાઇડરના રીરાઉટ પછી શાંતિથી તેને ઓળંગી શકે છે. જ્યારે આર્કિટેક્ચર દસ્તાવેજ અને ચાલતી સિસ્ટમ અસંમત હોય, ત્યારે દસ્તાવેજ શાંતિથી હારી જાય છે, જ્યાં સુધી ખર્ચના ઓવરરન, જૂની મોડેલ પસંદગીઓ અથવા સંચિત થતી SLA ચૂક ડાઉનસ્ટ્રીમમાં સપાટી પર ન આવે. આ પાઠના અંત સુધીમાં તમે દરેક ADR અંદરની ધારણાઓને પરીક્ષણયોગ્ય પ્રેડિકેટ તરીકે એન્કોડ કરી શકશો, તેમને શેડ્યૂલ પર લાઇવ ટેલિમેટ્રી સામે મૂલવી શકશો, અને સ્થગિત થયેલી ધારણાઓને આર્કિટેક્ચરલ ઋણ તરીકે સંચિત થાય તે પહેલાં ગવર્નન્સ રિવ્યૂ લૂપમાં મોકલી શકશો.

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

ADR Assumption: Architecture Decision Record માંથી કાઢવામાં આવેલું સંરચિત, મશીન-ચકાસણીયોગ્ય પ્રેડિકેટ — મેટ્રિક નામ, તુલના શરત, થ્રેશોલ્ડ અને ટોલરન્સ બેન્ડ — જેને લાઇવ ટેલિમેટ્રી સામે મૂલવી શકાય.
Tolerance Band: થ્રેશોલ્ડની આસપાસનો ટકાવારી માર્જિન જેની અંદર અવલોકિત મેટ્રિકને VIOLATED ને બદલે DEGRADED તરીકે વર્ગીકૃત કરવામાં આવે છે, જે નાના ફેરફારોથી થતા ઘોંઘાટિયા ખોટા એલાર્મને અટકાવે છે.
Staleness Threshold (max_violations_before_stale): સળંગ માન્યતા નિષ્ફળતાઓની સંખ્યા જે ધારણાએ સંચિત કરવી પડે તે પહેલાં આસપાસના ADR ને સ્થગિત ચિહ્નિત કરીને ગવર્નન્સ રિવ્યૂ વર્કફ્લોમાં મોકલવામાં આવે.

વિભાવનાઓ

વ્યવહારુ ડિપ્લોયમેન્ટ વિચારણાઓ

પ્રોડક્શનમાં ટેલિમેટ્રી માન્યતા ડિપ્લોય કરતી વખતે, માન્યતા રન તમારી ટેલિમેટ્રી એગ્રિગેશન વિન્ડો સાથે સંરેખિત અંતરાલે શેડ્યૂલ કરો. જો તમારું મેટ્રિક્સ બેકએન્ડ 5-મિનિટના અંતરાલે એગ્રિગેટ કરે છે, તો દર મિનિટે માન્યતા ચલાવવાથી આંશિક વિન્ડો પર આધારિત ઘોંઘાટિયા પરિણામો મળે છે. 5-મિનિટના એગ્રિગેટેડ મેટ્રિક્સ સાથે 15-મિનિટની માન્યતા કેડન્સ સ્થિર રીડિંગ આપે છે અને સાથે સાથે ઝડપી ઘટાડાને પણ પકડે છે.

max_violations_before_stale પેરામીટરને દરેક ધારણા શ્રેણી માટે અલગ ટ્યુનિંગની જરૂર છે. મોડેલ ગુણવત્તાની ધારણાઓ (BLEU સ્કોર, માનવ પસંદગી રેટિંગ) વધુ સળંગ ઉલ્લંઘનો સહન કરવી જોઈએ—કદાચ 5 થી 7—કારણ કે ગુણવત્તા મેટ્રિક્સ સ્વાભાવિક રીતે વધુ ઘોંઘાટિયા હોય છે. ખર્ચની ધારણાઓએ 2 થી 3 ની નીચી થ્રેશોલ્ડ વાપરવી જોઈએ કારણ કે ખર્ચના ઓવરરન ઝડપથી સંચિત થાય છે અને ભાગ્યે જ આપમેળે સુધરે છે.

દરેક ValidationResult ને કાચી ટેલિમેટ્રી સાથે ટાઇમ-સિરીઝ ડેટાબેઝમાં સંગ્રહો. આ ઐતિહાસિક રેકોર્ડ રેકમેન્ડેશન એન્જિનને મોસમી પેટર્ન ઓળખવા સક્ષમ બનાવે છે—બેચ પ્રોસેસિંગ લોડને કારણે દર સોમવારે સવારે ઉલ્લંઘન કરતી ધારણા ખરેખર સ્થગિત નથી; તેને પીક વિન્ડો માટે અલગ થ્રેશોલ્ડની જરૂર છે. આ ઇતિહાસ વગર, ગવર્નન્સ ડેશબોર્ડ એવી રિવ્યૂ વિનંતીઓ ઉત્પન્ન કરે છે જેને આર્કિટેક્ટ અવગણવાનું શીખી જાય છે, જે સમગ્ર માન્યતા સિસ્ટમને નબળી પાડે છે.

અંતે, સ્થગિતતા એલર્ટને તમારી હાલની નિર્ણય ટેક્સોનોમી સાથે સંકલિત કરો. "model selection" શ્રેણી હેઠળની સ્થગિત ધારણા ML પ્લેટફોર્મ ટીમને મોકલવી જોઈએ, જ્યારે સ્થગિત "hosting strategy" ધારણા ઇન્ફ્રાસ્ટ્રક્ચર ટીમને મોકલવી જોઈએ. આ રાઉટિંગ, ગવર્નન્સ ડેશબોર્ડમાં એક્સપાયરી ટ્રેકિંગ સાથે મળીને, ખાતરી કરે છે કે સ્થગિત નિર્ણયો શેર કરેલી કતારમાં પડ્યા ન રહે પરંતુ તેમના પર કાર્ય કરવાની સત્તા અને સંદર્ભ ધરાવતા એન્જિનિયરો સુધી પહોંચે.

Loading diagram...

કોડ વોકથ્રૂ

હવે તમે જોયું કે માન્યતા કેડન્સ, ટોલરન્સ ટ્યુનિંગ અને સ્થગિતતા રાઉટિંગ આ સિસ્ટમના પ્રોડક્શન વર્તનને કેવી રીતે આકાર આપે છે, નીચેનો કોડ તે મિકેનિક્સને બે ભાગમાં વ્યક્ત કરે છે: એક ટાઇપ કરેલું ધારણા મોડેલ અને તેને ટેલિમેટ્રી સામે ગ્રેડ કરીને ગવર્નન્સ માટે 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.

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 →