Generics से सीखें: PropTech AI को कैसे स्पेशलाइज़ करें

Real estate और PropTech में AI की सबसे बड़ी दिक्कत अक्सर मॉडल नहीं होता—“एक ही मॉडल से हर property, हर city, हर tenant type के लिए सही output” निकालने की उम्मीद होती है। Most companies get this wrong. वे AI को one-size-fits-all बना देते हैं, फिर complain करते हैं कि price estimates drift कर रहे हैं, lead scoring inconsistent है, या building automation alerts noisy हैं।

Programming languages में generics का core idea इस problem का बहुत साफ जवाब देता है: एक common logic लिखो, लेकिन concrete context मिलते ही behavior को specialize कर दो। Axe programming language में generics का implementation इसी सोच को explicit बनाता है—compile time पर type information के आधार पर सही branch चुनना। और यही मानसिक मॉडल PropTech AI systems पर भी apply होता है: shared pipeline + domain-specific specialization.

इस पोस्ट में मैं Axe के generics design से कुछ practical lessons निकालूँगा और उन्हें AI in real estate में map करूँगा—property valuation models, demand forecasting, और smart building management के workflows के लिए।

Axe generics का असली मतलब: “एक function, कई behaviors”

Axe में generic function एक type parameter ले सकता है (जैसे T) और फिर when T is ... clauses से type-specific logic चुन सकता है। निर्णायक बात यह है कि decision runtime पर नहीं, type info के आधार पर compile time पर होता है। यानी performance predictable रहती है और behavior explicit रहता है।

Source से simplified example:

def some_function[T](arg: T): T {
    when T is float {
        return arg * 2.0;
    }
    when T is i32 {
        return arg + 1;
    }
    return arg;
}

यह design philosophy PropTech में एक powerful lens देता है:

Generic logic = आपकी core product pipeline.
Type-specific branches = आपकी market/domain specialization.

AI teams अक्सर specialization को model अलग करके solve करते हैं (हर city के लिए अलग model), जिससे maintenance explode हो जाता है। Generics वाला approach कहता है: एक pipeline रखो, पर specialization points clearly define करो।

Compile-time specialization बनाम runtime hacks

Axe में when/is से compiler पहले ही तय कर देता है कि कौन सा branch चलेगा। PropTech AI में analog यह है:

• runtime पर “अगर city=Delhi तो ये rule” जैसी hardcoded if-else नहीं
• बल्कि training/serving configuration में pre-decided specialization
  • segment-specific feature sets
  • calibrated post-processing
  • policy constraints

इससे compliance, auditability, और reproducibility बेहतर होती है—real estate जैसे regulated/contract-heavy domain में यह बहुत काम आता है।

when/is clauses से PropTech segmentation का बेहतर तरीका

Axe का दूसरा example nested type interactions दिखाता है—दो type parameters के combination पर logic बदलता है:

def list_contains[T, T2](lst: T, value: T2): bool {
    for mut i = 0; i < lst.len; i++ {
        when T2 is i32 and T is IntList {
            if lst.data[i] == cast[i32](value) { return true; }
        }
        when T2 is string and T is StringList {
            if compare(lst.data[i], cast[string](value)) == 0 { return true; }
        }
    }
    return false;
}

PropTech में यही pattern “segment x input type” combinations पर लागू होता है। उदाहरण:

• Property type (apartment, villa, commercial) + market liquidity (high/low)
• Tenant profile (student, family, enterprise) + lease duration (short/long)
• Building system (HVAC, lifts, water) + sensor quality (high/low)

Practical mapping: AI valuation में explicit specialization points

Property valuation, automated property appraisal, और AVM (automated valuation model) में सबसे common गलती यह है कि features सब जगह same रख दिए जाते हैं। लेकिन reality यह है:

• apartments में floor, society amenities, maintenance fees ज्यादा predictive होते हैं
• villas में plot size, frontage, road access ज्यादा matter करता है
• commercial में footfall proxies, zoning, parking ratio critical है

Generics lens कहता है: core valuation function generic रखो, लेकिन property type के हिसाब से feature transformations और constraints specialize करो। जैसे:

• when property_type is apartment → comparable selection radius tighter, floor premium curve apply
• when property_type is villa → land-rate baseline + structure depreciation split
• when property_type is commercial → rent multiple + vacancy risk adjustment

यह “एक model per type” से ज्यादा maintainable है, क्योंकि आप shared backbone + explicit branches maintain कर रहे हैं।

“Type-driven behavior” AI systems में कैसे लाएँ (without chaos)

Axe में behavior type-driven है, पर source code में साफ दिखता है। AI systems में type-driven specialization लाने का सही तरीका architectural discipline है। मैंने teams को 3-layer approach में बेहतर perform करते देखा है:

1) Generic pipeline: वही हर जगह चलता है

यह आपका default path है:

• data validation
• missing value strategy
• base feature store joins
• model inference
• basic monitoring metrics

इस layer को boring होना चाहिए। Stable. Predictable.

2) Specialization registry: “when/is” का AI version

यहाँ आप explicit declare करते हैं कि कौन से contexts में क्या बदलेगा:

• segment-specific feature transforms
• calibration per geography
• confidence thresholds per use case
• business constraints (e.g., price can’t jump > X% without explanation flags)

Axe के when की तरह, goal है conditions explicit हों और safe transforms हों—unchecked hacks नहीं।

3) Safe casting: AI में “cast” का equivalent

Axe में cast तभी safe है जब when ने type relationship establish किया हो। AI में safe casting का मतलब:

• input schema guarantees (strict contracts)
• segment labeling rules with audit logs
• fallback behavior defined (default branch)

PropTech में यह बहुत जरूरी है क्योंकि data messy होता है: broker-entered data, incomplete listings, sensor dropouts। आपका system तब भी deterministic तरीके से behave करे—यही production reliability है।

Generics as a training ground: AI को polymorphism कैसे सिखाता है

Startup ecosystem में AI teams अक्सर “prompt + model” से आगे नहीं सोचतीं। लेकिन real estate AI products को polymorphism चाहिए: same intent, different execution.

Axe generics से AI को सीखने वाली two big ideas:

“Single interface, multiple implementations” = product velocity

• आपकी sales टीम एक ही feature बेचती है: “AI-based property valuation”
• पर backend में valuation logic property type, city tier, और liquidity के हिसाब से specialized है

User experience consistent रहता है, पर accuracy बढ़ती है। और engineering teams “100 forks” में फँसती नहीं।

“Fallback path” = trust

Axe में अगर कोई when match नहीं हुआ तो function fallback कर देता है। AI में fallback design trust बनाता है:

• low confidence पर “estimate range” show करना
• missing features पर “human review” route
• sensor anomaly पर “maintenance suggestion” instead of “alarm spam”

Good AI systems don’t pretend they know everything. They route uncertainty.

PropTech use cases जहाँ specialization सबसे ज्यादा ROI देता है

Answer-first: valuation, demand forecasting, और smart building management—इन तीनों में context-specific behavior accuracy और cost दोनों पर असर डालता है।

1) AI property valuation: ranges, not just point estimates

अगर आप single global model चला रहे हैं, तो major failure modes दिखेंगे:

• luxury pockets में underestimation
• low-liquidity markets में overconfidence
• new micro-markets में stale comps

Specialized “when/is” points:

• when market_liquidity is low → wider prediction intervals, comp recency weighting
• when property_age > 20 years → renovation proxy features, depreciation curve change
• when listing_source is broker → stronger fraud/duplication checks

2) Demand analysis: city tier और seasonality पर specialization

December 2025 context: year-end में budgets, job switches, और festive/holiday travel patterns की वजह से demand signals noisy हो सकते हैं। Demand forecasting में generic model अक्सर seasonality और policy shocks को blur कर देता है।

Specialization points:

• when city_tier is tier-1 → metro connectivity, office occupancy proxies
• when city_tier is tier-2 → new supply pipeline, infra announcements weighting
• when season is year_end → shorter lookback + anomaly filters

3) Smart building management: sensor quality is a “type”

Smart building AI में सबसे underrated segmentation है sensor fidelity. एक building में high-grade BMS है, दूसरे में cheap IoT sensors. Same anomaly model दोनों पर चलाने से false positives बढ़ते हैं।

Specialization points:

• when sensor_quality is low → smoothing, conservative thresholds
• when system is HVAC → temperature + power draw correlation checks
• when system is elevator → vibration spikes + trip count pattern checks

Startup teams के लिए implementation checklist (practical)

अगर आप PropTech startup में AI बना रहे हैं और “generics mindset” अपनाना चाहते हैं, तो यह checklist अपनाइए:

1. अपने product में 3-6 “types” define करें: property type, city tier, liquidity, source, sensor quality, tenant segment.
2. हर type के लिए allowed transformations लिखें: कौन सा feature adjust होगा, कौन सा threshold बदलेगा.
3. Fallback behavior document करें: unknown segment या low confidence पर क्या होगा.
4. Specialization को config-driven रखें: code में scattered if-else नहीं, centralized registry.
5. Monitoring per type चलाएँ: overall MAE अच्छा होने से segment-level failure छिप जाता है.

यह approach lead generation पर भी असर डालता है: जब आपका product consistently explainable और reliable outputs देता है, enterprise buyers (developers, brokers, facility managers) faster trust करते हैं।

Real estate AI का अगला कदम: “compile-time thinking” in product design

Axe generics का message simple है: behavior को explicit और predictable बनाओ, specialization को first-class citizen बनाओ। PropTech AI में यही सोच आपको brittle automation से निकालकर dependable systems की तरफ ले जाती है—चाहे आप property valuation AI बना रहे हों, demand analysis कर रहे हों, या smart building management.

अगर आप इस series “रियल एस्टेट और प्रॉपटेक में AI” में आगे बढ़ रहे हैं, तो अगला logical step यह है: अपने AI product के लिए एक specialization map बनाइए—कौन से contexts में behavior अलग होना चाहिए, और किन contexts में common pipeline ही सही है।

आपकी AI टीम के लिए सवाल: आपने अपने product में कौन से “types” पहचाने हैं—और क्या आपका system उन्हें explicit तरीके से handle करता है, या बस runtime पर patch करता रहता है?