เอเจนต์วิจัย AI stock watchlist

กำหนดว่าอะไรนับเป็น update ที่มีความหมาย

watchlist agent ควรตอบว่าอะไรเปลี่ยนไปตั้งแต่ research packet ล่าสุดที่ผ่านการรีวิว กำหนด event ที่มีความสำคัญ เช่น filing ใหม่ disclosure ที่แก้ไข earnings call หรือหลักฐานที่กระทบคำถามวิจัยที่ยังเปิดอยู่ เก็บคำถามวิจัยและ coverage ของ source ของ issuer แต่ละรายไว้คู่กับ identifier วิธีนี้ทำให้โมเดลมีงานที่มีขอบเขต และทำให้ผู้รีวิวมีเหตุผลว่าได้รับ update เพราะอะไร อย่าตั้งเวลาวิเคราะห์บริษัทแบบไม่จำกัดเพียงเพราะ timer ทำงาน input ที่ไม่เปลี่ยนโดยปกติควรคืนสถานะเดิม แทนการสร้างรายงานยาวอีกฉบับ

แยก collection ออกจากการสร้างงานวิจัย

ใช้ source feed หรือ polling ที่ได้รับอนุญาตเก็บ metadata ก่อน แล้วจึงตัดสินว่า material ใหม่ควรใช้โมเดลหรือไม่ SEC developer resources อธิบาย filing feed และ index ที่ช่วยเก็บข้อมูลผู้ออกหลักทรัพย์ในสหรัฐฯ ได้ ตลาดอื่นต้องใช้ source ทางการของตนเอง เก็บ publication time, retrieval time และ source revision แยกกัน wrapper ของเว็บที่เปลี่ยนไม่ควรถูกถือว่าเป็น disclosure ใหม่ สร้าง content identity จากเอกสารหรือ event ที่เกี่ยวข้อง และเก็บ source error แยกจากข้อสรุปว่าไม่มีอะไรเปลี่ยน

ตั้งเวลาตามตลาดและ source ไม่ใช่นาฬิกาเดียว

เก็บ exchange timezone และ holiday calendar ไว้กับหลักทรัพย์แต่ละตัว ใช้ disclosure timestamp เป็นตัวบอก availability ของข้อมูล และใช้ schedule แยกสำหรับเวลาที่ผู้รีวิวต้องการสรุป issuer อาจเผยแพร่นอกเวลาตลาดหรือจดทะเบียนหลายตลาด อย่าขยับทุก event ไปเป็นวันที่เดียวจนลำดับหาย สำหรับ job ที่เกิดซ้ำ ให้บันทึก window ที่ตั้งใจและเวลาที่รันจริง run ที่พลาดควรกลับมาทำต่อจาก collection watermark ล่าสุดที่เสร็จ แทนการข้ามช่วงอย่างเงียบๆ หรือ replay ประวัติทั้งหมด

ใช้ job state และ notification state ที่ชัดเจน

state machine ขนาดเล็กทำให้งานที่เกิดซ้ำดูแลได้ง่ายขึ้น แยก unchanged, new evidence, source unavailable, research pending และ review required ออกจากกัน record ตัวอย่างด้านล่างเป็นการออกแบบ application ไม่ใช่ configuration ของ scheduler product เก็บ event key ที่เสถียรและ source-manifest hash เพื่อให้ retry job เดิมไม่สร้างงานซ้ำหรือ notification ซ้ำ persist artifact ก่อนทำเครื่องหมาย event ว่าเสร็จ การส่ง notification ควรมี acknowledgment state ของตัวเอง ไม่ควรอนุมานจากการสร้างรายงานสำเร็จ

{
  "issuer_id": "REQUIRED",
  "event_key": "REQUIRED_STABLE_KEY",
  "source_manifest_hash": "REQUIRED",
  "collection_status": "pending",
  "research_status": "not_started",
  "review_status": "pending",
  "notification_status": "not_sent"
}

สร้าง change note จาก packet ปัจจุบันและก่อนหน้า

ส่ง source ใหม่ โน้ตที่รีวิวแล้วก่อนหน้า และคำถามที่ยังเปิดให้โมเดล ขอ change log สั้นๆ พร้อม source locator และคำอธิบายชัดเจนว่า statement เดิมใดต้องอัปเดต เก็บโน้ตเดิมเป็น revision แทนการเขียนทับ disclosure ใหม่อาจทำให้การตีความแข็งแรงขึ้น อ่อนลง หรือไม่เปลี่ยน อย่าฝืนให้ทุก event กลายเป็น stock signal ทิศทางเดียว หาก packet ก่อนหน้าหาย ให้สร้างสถานะวิจัยเริ่มต้นแทนการสร้าง historical comparison ขึ้นเอง

กำหนดงบประมาณและ retry policy ของงานที่เกิดซ้ำ

กำหนดขีดจำกัดต่อ run สำหรับจำนวน issuer ปริมาณ source ความพยายามของโมเดล และเวลาทำงานก่อนตั้ง schedule ใช้ model contract ปัจจุบันวางแผน และเก็บ usage จริงตาม event กับ job แยก source retry ออกจาก model retry เพื่อไม่ให้ filing outage ชั่วคราวกระตุ้นการวิเคราะห์ข้อมูลเก่าซ้ำ ใช้ document และ parser version เป็น key ของ extraction cache หยุดสร้างงานใหม่เมื่อ budget หมด เก็บ event ที่อยู่ในคิว และแสดงสถานะที่ยังไม่คลี่คลาย ความถี่ของ notification ควรเป็นอิสระจากความถี่ collection เพื่อลดภาระรีวิวที่ไม่จำเป็น

ทดสอบ operational miniflow ขนาดเล็ก

ก่อนเปิดการส่งซ้ำแบบ recurring ให้ทดสอบเอกสารที่ไม่เปลี่ยน revision ใหม่ source ที่ใช้ไม่ได้ชั่วคราว และ notification ที่ retry ตรวจ stable event identity, research status ที่ถูกต้อง และ notification ที่ตั้งใจไว้เพียง 1 ครั้งสำหรับ event เดิมที่เสร็จแล้ว จากนั้นตรวจ change note ฉบับเต็มกับหลักฐานต้นฉบับ เก็บ collector และ research tools เป็น read-only และใช้ authorization ชัดเจนสำหรับปลายทางการส่งข้อความ การอนุมัติ research ไม่ใช่การอนุมัติ order watchlist workflow ไม่ควรได้ broker permission เพียงเพราะทำงานแบบ unattended

หลักฐานและข้อจำกัด

คู่มือนี้เป็นการออกแบบ workflow ที่ได้ข้อมูลจาก filing resource ทางการและ research application ที่รีวิว source แล้ว ไม่มี watchlist job แบบ recurring การส่ง notification หรือเคส usage ที่วัดจริงถูกรันสำหรับหน้านี้ deployment record ควรระบุ scheduler ที่ใช้จริง coverage ของ source โมเดล สถานะ event ที่ persist และการทดสอบ notification ก่อนอ้างว่า workflow ที่เกิดซ้ำทำงานได้จริง

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