Free lesson · GenAI Solutions Architecture
ADR ನಿರ್ಧಾರಗಳನ್ನು ಪ್ರೊಡಕ್ಷನ್ ಟೆಲಿಮೆಟ್ರಿಯ ವಿರುದ್ಧ ಪರಿಶೀಲಿಸಿ
ಸ್ವೀಕರಿಸಿದ ADR ಗಳ ಹಿಂದಿನ ಊಹೆಗಳು ಇನ್ನೂ ಸರಿಯಾಗಿವೆಯೇ ಎಂದು ಲೈವ್ ಪ್ರೊಡಕ್ಷನ್ ಟೆಲಿಮೆಟ್ರಿಯೊಂದಿಗೆ ಹೋಲಿಸಿ ನಿರಂತರವಾಗಿ ಪರಿಶೀಲಿಸುವ DecisionValidator ಅನ್ನು ನೀವು ನಿರ್ಮಿಸುತ್ತೀರಿ. 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). ಸ್ವೀಕರಿಸಿದ ADR ನ context ಮತ್ತು decision ಫೀಲ್ಡ್‌ಗಳನ್ನು Instructor ಜೊತೆಗೆ litellm.completion() ಬಳಸಿ ಪಾರ್ಸ್ ಮಾಡಿ, ಪರೀಕ್ಷಿಸಬಹುದಾದ ಊಹೆಗಳನ್ನು ರಚನಾತ್ಮಕ ADRAssumption ಆಬ್ಜೆಕ್ಟ್‌ಗಳಾಗಿ ಹೊರತೆಗೆದು, assumptions: list[ADRAssumption], confidence: float, unextractable_claims: list[str] ಒಳಗೊಂಡ ExtractionResult ಅನ್ನು ಹಿಂತಿರುಗಿಸುವ extract_assumptions() ಅನ್ನು ನಿರ್ಮಿಸಿ. ಪ್ರತಿ ಊಹೆಯ metric_name ಅನ್ನು measurement_window ಅವಧಿಯಲ್ಲಿ prometheus_api_client ಮೂಲಕ Prometheus ನಿಂದ ಕ್ವೆರಿ ಮಾಡುವ, PromQL ಎಕ್ಸ್‌ಪ್ರೆಶನ್‌ಗಳಿಗಾಗಿ custom_query() ಬಳಸುವ, ಫಲಿತಾಂಶವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ operator ಬಳಸಿ threshold ನೊಂದಿಗೆ ಹೋಲಿಸುವ, ಮತ್ತು is_valid: bool, actual_value: float, deviation_pct: float, trend_direction: TrendDirection (IMPROVING, STABLE, DEGRADING) ಒಳಗೊಂಡ ValidationResult ಅನ್ನು ಹಿಂತಿರುಗಿಸುವ validate_assumptions() ಅನ್ನು ಇಂಪ್ಲಿಮೆಂಟ್ ಮಾಡಿ. ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದಾದ ವೇಳಾಪಟ್ಟಿಯಲ್ಲಿ (ಡೀಫಾಲ್ಟ್ ಆಗಿ check_interval_hours: int ಮೂಲಕ ಪ್ರತಿ 6 ಗಂಟೆಗಳಿಗೊಮ್ಮೆ) validate_assumptions() ಅನ್ನು ರನ್ ಮಾಡುವ ಮತ್ತು ಯಾವುದೇ ಊಹೆಯು consecutive_failures_threshold (ಡೀಫಾಲ್ಟ್ 3) ಸತತ ಪರಿಶೀಲನೆಗಳಲ್ಲಿ ವಿಫಲವಾದಾಗ ADR ಗಳನ್ನು STALE ಎಂದು ಗುರುತಿಸುವ check_staleness() ಹೊಂದಿರುವ StalenessDetector ಅನ್ನು ನಿರ್ಮಿಸಿ. 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 ಗೇಜ್, ಇಲ್ಲಿ 1 ಎಂದರೆ ಎಲ್ಲಾ ಊಹೆಗಳು ಮಾನ್ಯವಾಗಿವೆ), adr_assumption_deviation_pct{adr_id,assumption_id}. adr_staleness_score 30 ನಿಮಿಷಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ 0.5 ಕ್ಕಿಂತ ಕೆಳಗೆ ಇಳಿದಾಗ warning severity ಯೊಂದಿಗೆ ADRStale ಅಲರ್ಟ್ ಅನ್ನು ಫೈರ್ ಮಾಡುವ Alertmanager ನಿಯಮಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ. ಪರಿಶೀಲನೆ ಇತಿಹಾಸ ಮತ್ತು ಪ್ರಸ್ತುತ staleness score ಅನ್ನು ಹಿಂತಿರುಗಿಸುವ GET /api/v1/adrs/{adr_id}/validation FastAPI ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ಹೊರತೆಗೆದ ಎಲ್ಲಾ ಊಹೆಗಳನ್ನು ಅವುಗಳ ಇತ್ತೀಚಿನ ಪರಿಶೀಲನೆ ಸ್ಥಿತಿಯೊಂದಿಗೆ ಹಿಂತಿರುಗಿಸುವ GET /api/v1/adrs/{adr_id}/assumptions ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ಎಲ್ಲಾ ADR ಗಳಾದ್ಯಂತ ಪರಿಶೀಲನೆ ಫಲಿತಾಂಶಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸಿ, ವರ್ಗವಾರು ಊಹೆ ಪಾಸ್ ದರಗಳು, 30 ದಿನಗಳ staleness ಪ್ರವೃತ್ತಿಗಳು, ಮತ್ತು ಅತಿ ಹೆಚ್ಚು ಅಮಾನ್ಯಗೊಂಡ ನಿರ್ಧಾರಗಳ ಶ್ರೇಣೀಕೃತ ಟೇಬಲ್ ಅನ್ನು ತೋರಿಸುವ Grafana ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಆಗಿ ರೂಪಿಸುವ DecisionEffectivenessScorecard ಅನ್ನು ಇಂಪ್ಲಿಮೆಂಟ್ ಮಾಡಿ.
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% ಉಲ್ಲಂಘನೆ ಎಣಿಸುವ ಮೊದಲುeffective_threshold()ಮೂಲಕ 200ms ಥ್ರೆಶ್‌ಹೋಲ್ಡ್‌ಗೆ 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