AI स्टॉक स्क्रीनर

Candidate selection को recommendation से अलग रखें

स्पष्ट rules से defined universe को छोटा करें, फिर पास होने वाली companies की जांच AI से करवाएं। उदाहरण के लिए, cash generation और accounting earnings के बीच documented relationship के लिए screen करें, फिर relevant filings पढ़कर अंतर समझें। Screen चलाने से पहले metric, threshold और missing-data rule तय करें। Result आगे जांच के कारणों वाली candidate list है। Numeric selection को qualitative follow-up से अलग रखें, ताकि reviewer समझ सके कि हर company क्यों आई और अभी कौन-सा evidence चाहिए।

Filters, semantic review और experiments में चुनाव करें

अलग screening tools अलग समस्याएं हल करते हैं। जब fields की definitions स्पष्ट हों, structured filters को दोहराना सबसे आसान होता है। Semantic review उन business descriptions और disclosed risks को पहचान सकती है जो numeric field से छूट जाते हैं। Learned signals के लिए evaluation framework और point-in-time dataset चाहिए। Task की जरूरत हो तभी इन्हें उसी क्रम में जोड़ें। LLM-generated rank को universe define करने या unavailable financial fields resolve करने का विकल्प न बनाएं।

ऐसा universe परिभाषित करें जो historical review में टिके

Exchange coverage, security types, share classes और membership तय होने की तारीख दर्ज करें। Secondary listings, depositary receipts, suspended instruments और delisted companies को कैसे संभालेंगे, तय करें। आज बचे हुए symbols से बनाया historical screen उस point-in-time screen से अलग सवाल का उत्तर देता है। International screening को currencies और fiscal calendars के लिए भी policy चाहिए। Excluded candidates को reason codes सहित रखें, ताकि reviewer समझ सके कि company rule में fail हुई या provider के पास data न होने से अनुपस्थित थी।

Companies की तुलना से पहले fields normalize करें

हर metric को उसके source concept, period, currency और unit से map करें। समान accounting measures की तुलना करें; earnings नाम वाले हर field को interchangeable न मानें। यह सुरक्षित रखें कि value reported, adjusted या derived है और बाद की filing ने उसे restate किया है या नहीं। Ratios के लिए denominator policy चाहिए; missing values, negative denominators और noncomparable periods को explicit states बनना चाहिए। SEC का XBRL documentation aggregated company facts समझाता है, लेकिन जब tag या context आपकी जरूरत के business meaning को न पकड़ पाए तो original filing जरूरी रहती है।

Rules को code में stable result states के साथ चलाएं

यह उदाहरण जानबूझकर छोटा screening primitive है, complete investment strategy नहीं। यह दिए गए metric की दिए गए threshold से तुलना करता है और missing या nonfinite inputs को अस्वीकार करता है। Rule owner को metric परिभाषित करना और सही comparator चुनना फिर भी होगा। उस निर्णय को model से बाहर रखने पर candidate set reproducible रहता है। Result के साथ rule version और input references रखें, फिर पास हुई companies की actual disclosures से समीक्षा करें; model से missing values भरने को न कहें।

from math import isfinite

def minimum_metric(value, threshold):
    if value is None or threshold is None:
        return {"state": "unavailable", "code": "MISSING_INPUT"}
    if not isfinite(value) or not isfinite(threshold):
        return {"state": "unavailable", "code": "NONFINITE_INPUT"}
    return {
        "state": "pass" if value >= threshold else "fail",
        "code": "MINIMUM_METRIC",
    }

Candidate evidence की समीक्षा के लिए AI इस्तेमाल करें

हर candidate को rule result, input definitions और source passages दें। Model से accounting changes, one-off events, contradictory disclosures और human investigation वाले questions पहचानने को कहें। Qualitative prose को numeric rule से अलग रखें। Reviewer candidate status बदले तो decision और उसका evidence एक और layer के रूप में दर्ज करें। उपयोगी output में original pass reason, छोटा explanation, supporting source locators और unresolved questions शामिल होते हैं। Related questions को follow-up के लिए group करें, हर candidate से unrestricted research task न चलवाएं।

Exportable test packet से software की तुलना करें

हर candidate tool को वही authorized universe, data cutoff और rule definitions दें। देखें कि वे input fields, exclusion reasons और source links export करते हैं या केवल final rank। Hosted product के लिए पूछें कि custom data, historical membership और revisions export हो सकते हैं या नहीं। Local stack के लिए data mappings और dependencies बनाए रखने की लागत गिनें। OpenBB data-platform reference है और Qlib experiment reference; केवल इसलिए कि upper layer model call कर सकती है, किसी को complete tested APIsRouter screening product के रूप में advertise न करें।

Review volume का बजट बनाएं और failed coverage दर्ज करें

Long documents model को भेजने से पहले inexpensive filters चलाएं, फिर detailed review पाने वाले candidates की संख्या सीमित करें। Source revision के आधार पर extraction cache करें और screen snapshot को immutable रखें। Unchanged inputs पर repeated run को नए research event से अलग पहचाना जा सके। Unavailable candidates को model requests, data charges और review effort के साथ track करें। दो screening methods की तुलना same universe और cutoff पर करें और देखें कि कौन-से candidates अलग हैं और क्यों। Coverage और rule definitions देखे बिना final list length की तुलना कम उपयोगी है।

प्रमाण और दायरा

यह comparison official data और framework sources पर आधारित है। Code illustrative filter primitive है, current stock screen या tested strategy नहीं। कोई candidate results, returns या measured task costs नहीं दिए गए हैं। अपना screening case चलाते समय universe snapshot और reviewed rule set सुरक्षित रखें।

अक्सर पूछे जाने वाले प्रश्न