AI stock screener

แยกการเลือก candidate ออกจากคำแนะนำ

ใช้กฎที่ชัดเจนลด universe ที่กำหนดไว้ก่อน แล้วให้ AI ตรวจบริษัทที่ผ่าน เช่น คัดกรองความสัมพันธ์ที่บันทึกไว้ระหว่างการสร้างเงินสดกับกำไรทางบัญชี จากนั้นอ่าน filing ที่เกี่ยวข้องเพื่อเข้าใจความแตกต่าง กำหนด metric threshold และกฎเมื่อข้อมูลหายก่อนรัน screen ผลลัพธ์คือรายชื่อ candidate พร้อมเหตุผลสำหรับการตรวจต่อ เก็บ follow-up เชิงคุณภาพแยกจากการเลือกเชิงตัวเลข เพื่อให้ผู้รีวิวรู้ว่าบริษัทแต่ละแห่งปรากฏเพราะอะไรและยังต้องใช้หลักฐานใด

เลือกระหว่าง filter, semantic review และ experiment

เครื่องมือคัดกรองที่ต่างกันแก้ปัญหาต่างกัน structured filter ทำซ้ำได้ง่ายที่สุดเมื่อฟิลด์มีนิยามชัด semantic review ช่วยค้นหาคำอธิบายธุรกิจและความเสี่ยงที่เปิดเผยซึ่งฟิลด์ตัวเลขอาจพลาด learned signal ต้องมี evaluation framework และ point-in-time dataset ค่อยผสานตามลำดับนี้เมื่อ task ต้องใช้จริง อย่าใช้ ranking ที่ LLM สร้างแทนการกำหนด universe หรือแก้ฟิลด์การเงินที่ไม่มีข้อมูล

กำหนด universe ที่ตรวจย้อนหลังได้

บันทึก coverage ของตลาดหลักทรัพย์ ประเภทหลักทรัพย์ share class และวันที่กำหนด membership ตัดสินใจว่าจะจัดการ secondary listing, depositary receipt, instrument ที่ถูกระงับ และบริษัทที่ delist อย่างไร historical screen ที่สร้างจาก symbol ที่ยังอยู่ในปัจจุบันตอบคนละคำถามกับ point-in-time screen การคัดกรองระหว่างประเทศยังต้องมีกฎสำหรับสกุลเงินและ fiscal calendar เก็บ candidate ที่ถูกตัดออกพร้อม reason code เพื่อให้ผู้รีวิวแยกได้ว่าบริษัทไม่ผ่านกฎ หรือหายไปเพราะ provider ไม่มีข้อมูล

Normalize ฟิลด์ก่อนเปรียบเทียบบริษัท

map metric แต่ละตัวเข้ากับ source concept, period, currency และ unit เปรียบเทียบตัวชี้วัดทางบัญชีที่เหมือนกัน แทนการถือว่าทุกฟิลด์ที่ชื่อ earnings ใช้แทนกันได้ เก็บว่าค่านั้นรายงานแล้ว ปรับแล้ว หรือคำนวณต่อ และระบุว่า filing ภายหลัง restate หรือไม่ ratio ต้องมีกฎ denominator ค่าที่หาย denominator ติดลบ และงวดที่เปรียบเทียบไม่ได้ควรให้เป็นสถานะที่ชัดเจน เอกสาร XBRL ของ SEC อธิบาย aggregated company facts แต่ filing ต้นฉบับยังจำเป็นเมื่อ tag หรือ context ไม่ครอบคลุมความหมายทางธุรกิจที่ต้องการ

รันกฎในโค้ดด้วยสถานะผลลัพธ์ที่เสถียร

ตัวอย่างนี้เป็น screening primitive ขนาดเล็กโดยตั้งใจ ไม่ใช่ investment strategy ฉบับสมบูรณ์ มันเปรียบเทียบ metric ที่ส่งเข้ามากับ threshold ที่ส่งเข้ามา และปฏิเสธ input ที่หายหรือไม่ finite เจ้าของกฎยังต้องนิยาม metric และเลือก comparator ที่เหมาะสม การเก็บการตัดสินใจนั้นไว้นอกโมเดลทำให้ candidate set ทำซ้ำได้ เก็บ rule version และ input reference ไว้ข้างผลลัพธ์ แล้วรีวิวบริษัทที่ผ่านด้วย disclosure จริง แทนการขอให้โมเดลเติมค่าที่หาย

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 รีวิวหลักฐานของ candidate

สำหรับ candidate แต่ละราย ให้ผลลัพธ์ของกฎ นิยาม input และข้อความจาก source ขอให้โมเดลระบุการเปลี่ยนแปลงทางบัญชี เหตุการณ์ครั้งเดียว disclosure ที่ขัดกัน และคำถามที่ต้องให้มนุษย์ตรวจ เก็บ prose เชิงคุณภาพแยกจากกฎตัวเลข หากผู้รีวิวเปลี่ยนสถานะ candidate ให้บันทึกการตัดสินใจและหลักฐานเป็นอีกชั้นหนึ่ง output ที่มีประโยชน์ควรมีเหตุผลที่ผ่านเดิม คำอธิบายสั้นๆ ตำแหน่ง source ที่รองรับ และคำถามที่ยังไม่คลี่คลาย จัดกลุ่มคำถามที่เกี่ยวข้องเพื่อ follow-up แทนการให้ candidate ทุกตัวเริ่ม research task แบบไม่จำกัด

เปรียบเทียบซอฟต์แวร์ด้วย test packet ที่ export ได้

ให้เครื่องมือ candidate ใช้ universe ที่ได้รับอนุญาต data cutoff และนิยามกฎชุดเดียวกัน ตรวจว่ามัน export input field เหตุผลการตัดออก และ source link ได้หรือไม่ ไม่ใช่แค่ rank สุดท้าย สำหรับผลิตภัณฑ์ hosted ให้ถามว่า export custom data, historical membership และ revision ได้หรือไม่ สำหรับ stack local ให้คิดรวมการดูแล data mapping และ dependency OpenBB เป็น reference ของ data platform และ Qlib เป็น reference ของ experiment ทั้งสองไม่ควรถูกโฆษณาว่าเป็น APIsRouter screening product ที่ทดสอบครบ เพียงเพราะชั้นบนเรียกโมเดลได้

กำหนดปริมาณการรีวิวและบันทึก coverage ที่ล้มเหลว

คำนวณ filter ที่ประหยัดก่อนส่งเอกสารยาวให้โมเดล แล้วจำกัดจำนวน candidate ที่ได้รับการรีวิวละเอียด cache extraction ตาม source revision และทำให้ screen snapshot เปลี่ยนไม่ได้ run ซ้ำบน input ที่ไม่เปลี่ยนควรแยกได้จาก research event ใหม่ เก็บ candidate ที่ใช้ไม่ได้ไว้คู่กับ model request ค่า data และแรงรีวิว เปรียบเทียบ screening method 2 แบบบน universe และ cutoff เดียวกัน แล้วตรวจว่าต่างกันที่ใดและเพราะอะไร วิธีนี้ใช้งานได้มากกว่าการเทียบความยาวของรายชื่อสุดท้ายโดยไม่ดู coverage และนิยามกฎ

หลักฐานและขอบเขต

การเปรียบเทียบนี้อิง source ทางการของข้อมูลและ framework โค้ดเป็น filter primitive ตัวอย่าง ไม่ใช่ stock screen ปัจจุบันหรือ strategy ที่ทดสอบแล้ว ไม่มี candidate result, return หรือ task cost ที่วัดได้ ให้เก็บ universe snapshot และ rule set ที่ผ่านการรีวิวเมื่อรันเคส screening ของคุณเอง

คำถามที่พบบ่อย