AI 주식 스크리너

후보 선택과 추천을 분리하세요

명시적인 규칙으로 정의된 모집단을 줄인 다음 통과한 기업을 AI로 조사하세요. 예를 들어 현금 창출과 회계상 이익 사이의 문서화된 관계를 선별한 뒤 관련 공시를 읽어 차이를 이해할 수 있습니다. 스크리닝 전에 지표, 기준, 누락 데이터 규칙을 정의하세요. 결과는 추가 조사를 해야 하는 이유가 있는 후보 목록입니다. 정성적 후속 검토를 수치 선택과 분리해 각 기업이 왜 나타났고 여전히 어떤 근거가 필요한지 검토자가 알 수 있게 하세요.

필터, 의미 검토, 실험 중에서 선택하세요

스크리닝 도구마다 해결하는 문제가 다릅니다. 필드 정의가 명확하면 구조화된 필터가 가장 재현하기 쉽습니다. 의미 검토는 수치 필드가 놓치는 사업 설명과 공시 위험을 식별할 수 있습니다. 학습된 신호에는 평가 프레임워크와 특정 시점 데이터셋이 필요합니다. 작업에 필요한 경우에만 이 순서로 결합하세요. LLM이 생성한 순위를 모집단을 정의하거나 이용할 수 없는 재무 필드를 해결하는 대체물로 사용하지 마세요.

과거 검토에도 견디는 모집단을 정의하세요

거래소 커버리지, 증권 유형, 주식 종류, 구성원을 정의하는 날짜를 기록하세요. 2차 상장, 예탁증서, 거래 정지 금융상품, 상장 폐지 기업을 처리할 방법을 결정합니다. 오늘 살아남은 종목으로 만든 과거 스크린은 특정 시점 스크린과 다른 질문에 답합니다. 국제 스크리닝에는 통화와 회계연도에 대한 정책도 필요합니다. 제외된 후보도 이유 코드와 함께 보존해 기업이 규칙에 실패했는지 아니면 제공업체의 데이터 부족으로 빠졌는지 검토자가 알 수 있게 하세요.

기업을 비교하기 전에 필드를 정규화하세요

각 지표를 소스 개념, 기간, 통화, 단위에 매핑하세요. earnings라는 이름이 있는 모든 필드를 교환 가능하게 취급하지 말고 같은 회계 측정값끼리 비교합니다. 값이 보고된 것인지 조정된 것인지 파생된 것인지, 이후 제출 자료에서 재작성되었는지 보존하세요. 비율에는 분모 정책이 필요합니다. 누락 값, 음수 분모, 비교할 수 없는 기간은 명시적인 상태를 만들어야 합니다. SEC의 XBRL 문서는 집계된 기업 사실을 설명하지만, 태그나 컨텍스트가 필요한 사업 의미를 담지 못하면 원래 제출 자료가 여전히 필요합니다.

안정적인 결과 상태로 코드를 통해 규칙을 실행하세요

이 예시는 의도적으로 작은 선별 기본 요소이지 완전한 투자 전략이 아닙니다. 제공된 지표와 제공된 기준을 비교하고 누락되거나 유한하지 않은 입력을 거부합니다. 규칙 소유자는 여전히 지표를 정의하고 적절한 비교 연산자를 선택해야 합니다. 이 결정을 모델 밖에 두면 후보 집합을 재현할 수 있습니다. 결과 옆에 규칙 버전과 입력 참조를 저장한 다음 모델에게 누락 값을 채우게 하지 말고 실제 공시로 통과한 기업을 검토하세요.

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 스크리닝 제품으로 광고해서는 안 됩니다.

검토량을 예산화하고 누락된 커버리지를 기록하세요

긴 문서를 모델에 보내기 전에 저렴한 필터를 계산하고 상세 검토를 받을 후보 수에 상한을 두세요. 소스 리비전별 추출을 캐시하고 스크린 스냅샷을 변경할 수 없게 유지합니다. 변경되지 않은 입력에 대한 반복 실행은 새로운 리서치 이벤트와 구분할 수 있어야 합니다. 이용할 수 없는 후보를 모델 요청, 데이터 요금, 검토 노력과 함께 추적하세요. 같은 모집단과 기준 시점으로 두 스크리닝 방법을 비교하고 어떤 후보가 왜 달라지는지 검사합니다. 커버리지와 규칙 정의를 살피지 않고 최종 목록 길이만 비교하는 것보다 훨씬 실행 가능한 방법입니다.

근거와 범위

이 비교는 공식 데이터 및 프레임워크 출처를 기반으로 합니다. 코드는 예시 필터 기본 요소이지 현재 주식 스크린이나 테스트된 전략이 아닙니다. 후보 결과, 수익률, 측정된 작업 비용은 제공하지 않습니다. 자체 스크리닝 사례를 실행할 때 모집단 스냅샷과 검토된 규칙 집합을 보존하세요.

자주 묻는 질문