AI-скринери акцій

Відокремте відбір кандидатів від рекомендації

Використовуйте явні правила, щоб звузити визначений універсум, а потім попросіть AI дослідити компанії, які пройшли. Наприклад, перевірте задокументований зв’язок між генерацією коштів і обліковим прибутком, а потім прочитайте відповідні подання, щоб зрозуміти різницю. До запуску скринінгу визначте показник, поріг і правило для відсутніх даних. Результатом є список кандидатів із причинами для подальшого дослідження. Якісне продовження тримайте окремо від числового відбору, щоб рецензент міг зрозуміти, чому з’явилася кожна компанія і які докази ще потрібні.

Оберіть між фільтрами, семантичною перевіркою та експериментами

Різні інструменти скринінгу розв’язують різні проблеми. Структуровані фільтри найлегше відтворити, коли поля мають чіткі визначення. Семантична перевірка може виявити описи бізнесу й розкриті ризики, які пропускає числове поле. Навчені сигнали потребують середовища оцінювання та набору даних у конкретний момент. Поєднуйте їх у такому порядку лише тоді, коли цього потребує завдання. Не використовуйте згенерований LLM рейтинг як заміну визначенню універсуму або вирішенню проблеми недоступних фінансових полів.

Визначте універсум, який витримує історичну перевірку

Запишіть охоплення бірж, типи цінних паперів, класи акцій і дату визначення складу. Вирішіть, як обробляти вторинні лістинги, депозитарні розписки, призупинені інструменти та делістинговані компанії. Історичний скринінг на основі символів, що вижили сьогодні, відповідає на інше питання, ніж скринінг у конкретний момент. Міжнародний скринінг також потребує політики валют і фінансових календарів. Зберігайте виключених кандидатів із кодами причин, щоб рецензент розрізняв порушення правила та відсутність компанії через нестачу даних у провайдера.

Нормалізуйте поля до порівняння компаній

Зіставте кожен показник із концептом джерела, періодом, валютою та одиницею. Порівнюйте однакові облікові показники, а не вважайте кожне поле з назвою earnings взаємозамінним. Зберігайте, чи є значення заявленим, скоригованим або похідним, і чи переглядається воно пізнішим поданням. Коефіцієнти потребують політики знаменника; пропущені значення, від’ємні знаменники та непорівнювані періоди мають створювати явні стани. Документація XBRL SEC пояснює агреговані факти компанії, але оригінальне подання все одно потрібне, коли тег або контекст не передає потрібного бізнес-значення.

Виконуйте правила кодом зі стабільними станами результату

Приклад є навмисно малим примітивом скринінгу, а не повною інвестиційною стратегією. Він порівнює наданий показник із наданим порогом і відхиляє відсутні або нечисленні входи. Власник правила все одно має визначити показник і обрати відповідний компаратор. Збереження цього рішення поза моделлю робить набір кандидатів відтворюваним. Зберігайте версію правила та посилання на входи поруч із результатом, а потім перевіряйте компанії, що пройшли, за фактичними розкриттями, а не просіть модель заповнити пропущені значення.

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",
    }

Використовуйте AI для перевірки доказів кандидатів

Для кожного кандидата надайте результат правила, визначення входів і уривки джерел. Попросіть модель визначити зміни обліку, одноразові події, суперечливі розкриття та питання, що потребують людського дослідження. Якісну прозу тримайте окремо від числового правила. Якщо рецензент змінює статус кандидата, запишіть рішення та його докази як ще один шар. Корисний результат містить початкову причину проходження, коротке пояснення, локатори підтверджувальних джерел і невирішені питання. Групуйте пов’язані питання для продовження, а не запускайте необмежене дослідження для кожного кандидата.

Порівнюйте програмне забезпечення за тестовим пакетом, який можна експортувати

Надайте інструментам-кандидатам той самий авторизований універсум, часову межу даних і визначення правил. Перевірте, чи експортують вони вхідні поля, причини виключення та посилання на джерела, а не лише фінальний рейтинг. Для хмарного продукту запитайте, чи можна експортувати користувацькі дані, історичний склад і ревізії. Для локального стека врахуйте обслуговування мапування даних і залежностей. OpenBB є орієнтиром платформи даних, а Qlib — орієнтиром експериментів; жоден не слід рекламувати як повністю перевірений продукт скринінгу APIsRouter лише тому, що верхній шар може викликати модель.

Плануйте обсяг перевірки та записуйте невдале охоплення

Виконуйте недорогі фільтри до надсилання довгих документів моделі, а потім обмежте кількість кандидатів для детальної перевірки. Кешуйте витяг за ревізією джерела й зберігайте знімок скринінгу незмінним. Повторний запуск на незмінених входах має відрізнятися від нової дослідницької події. Відстежуйте недоступних кандидатів разом із запитами до моделі, оплатою даних і зусиллями перевірки. Порівнюйте два методи скринінгу на тому самому універсумі й часовій межі, перевіряючи, які кандидати відрізняються і чому. Це практичніше, ніж порівнювати довжину фінальних списків без перевірки охоплення та визначень правил.

Докази та охоплення

Порівняння ґрунтується на офіційних джерелах даних і фреймворків. Код є ілюстративним примітивом фільтра, а не актуальним скринінгом акцій чи перевіреною стратегією. Результати кандидатів, дохідність і виміряні витрати завдань не надаються. Запускаючи власний кейс скринінгу, зберігайте знімок універсуму та перевірений набір правил.

Поширені запитання