การวิเคราะห์ Earnings Call ด้วย AI

กำหนดการเปรียบเทียบก่อนสรุปสายสนทนา

ตัดสินใจก่อนว่าคุณต้องการ brief ของสายเดียว การเปลี่ยนแปลงของ guidance หรือการเปรียบเทียบคำอธิบายของฝ่ายบริหารข้ามงวด แต่ละแบบต้องใช้ชุดแหล่งข้อมูลต่างกัน หากต้องเปรียบเทียบ guidance ให้รวบรวมทั้งสองสายและ earnings release ที่เกี่ยวข้อง ระบุงวดรายงานและจุดตัดข้อมูลไว้ในงาน ผลลัพธ์ที่มีประโยชน์ควรบอกว่าอะไรเปลี่ยน ใครเป็นผู้พูด และหลักฐานอยู่ที่ใด หลีกเลี่ยงการขอป้าย bullish หรือ bearish เพียงป้ายเดียว เพราะจะซ่อนความแตกต่างรายหัวข้อที่นักวิเคราะห์ต้องตรวจสอบจริง

ใช้ transcript ที่ระบุแหล่งที่มาได้และเคารพสิทธิ์การใช้งาน

ควรใช้ transcript ที่ผู้ออกหลักทรัพย์เผยแพร่เอง หรือสำเนาจากผู้ให้บริการที่ได้รับอนุญาตอย่างถูกต้อง หน้าอีเวนต์ไตรมาสที่ 4 ของ FY25 อย่างเป็นทางการของ Microsoft เป็นตัวอย่างที่ผู้ออกหลักทรัพย์เผยแพร่เอกสารของสายสนทนา โดยเป็นเพียงตัวอย่างตำแหน่งแหล่งข้อมูล ไม่ใช่ผลวิเคราะห์ที่นำมาทำซ้ำในหน้านี้ บันทึกวันที่อีเวนต์ เวอร์ชันของ transcript ภาษาต้นฉบับ และ URL หากสร้าง transcript จากเสียง ให้เก็บ timestamp และทำเครื่องหมายคำหรือการระบุผู้พูดที่ไม่แน่ใจ การมีสิทธิ์รับฟังไม่ได้หมายความว่ามีสิทธิ์เผยแพร่ transcript ฉบับเต็มโดยอัตโนมัติ จึงต้องตรวจสอบสิทธิ์ก่อนจัดเก็บหรือเผยแพร่แพ็กเกจที่สร้างต่อยอด

แบ่งตามผู้พูดและบริบทของบทสนทนา

แยกคำกล่าวที่เตรียมไว้ คำถาม และคำตอบให้เห็นชัด คำถามเรื่องอุปสงค์ไม่ใช่การเปิดเผยของฝ่ายบริหารว่าอุปสงค์เปลี่ยนแล้ว ต้องรักษาความสัมพันธ์ระหว่างคำถามกับคำตอบที่ตามมา รวมถึงเงื่อนไขและข้อจำกัด แบ่งข้อความยาวตามหัวข้อที่สอดคล้องกัน ไม่ใช่ใช้ความยาวแบบสุ่มเพียงอย่างเดียว ส่งต่อ offset ของแหล่งข้อมูลหรือ timestamp ไปกับแต่ละชิ้น และเก็บข้อความข้างเคียงไว้ให้รีวิวได้ สำหรับสายหลายภาษา ให้เก็บต้นฉบับคู่กับคำแปล เพื่อให้ผู้รีวิวตรวจสอบคำที่ความหมายทางการเงินอาจเปลี่ยนระหว่างภาษาได้

ดึง claims ออกมาก่อนขอให้เขียนเรื่องราว

สร้างตาราง claim ที่มีผู้พูด หัวข้อ ประเภท claim งวด และตำแหน่งอ้างอิง แยกผลลัพธ์ที่เกิดขึ้นแล้ว guidance ล่วงหน้า คำอธิบายเชิงคุณภาพ และคำถามที่ยังไม่มีคำตอบ โครงสร้างผลลัพธ์ตัวอย่างด้านล่างเว้น evidence ให้เป็นค่าว่างแทนการสร้างงบการเงินขึ้นเอง แอปพลิเคชันควรกำหนดให้ claim ที่กรอกทุกตัวอ้างถึงส่วนจริงของแหล่งข้อมูล เมื่อการดึงข้อมูลผ่านการรีวิวแล้ว จึงให้โมเดลร่าง narrative สั้นๆ จากบันทึกเหล่านั้น ลำดับนี้ช่วยแก้การระบุผู้พูดผิดได้ง่ายขึ้น โดยไม่ต้องสร้างรายงานใหม่ทั้งหมด

{
  "event_id": "REQUIRED",
  "transcript_version": "REQUIRED",
  "claims": [],
  "guidance_changes": [],
  "unanswered_questions": [],
  "cross_checks": [],
  "review_status": "pending"
}

เปรียบเทียบ guidance บนฐานการวัดเดียวกัน

ก่อนสรุปว่า guidance เพิ่มขึ้นหรือลดลง ให้จัด metric งวด ฐานสกุลเงิน และขอบเขตให้ตรงกัน ข้อความแบบ constant-currency กับข้อความแบบ reported-currency ใช้แทนกันไม่ได้ เปรียบเทียบช่วงกับช่วงด้วยกฎที่บันทึกไว้ และเก็บเงื่อนไขของฝ่ายบริหารไว้ด้วย ตรวจสอบ claim เชิงปริมาณกับ earnings release หรือ filing ที่เกี่ยวข้อง โมเดลอาจเสนอวิธีจัดแนวข้อมูลได้ แต่โค้ดหรือผู้รีวิวควรเป็นผู้ตรวจสอบการเปรียบเทียบ หากนิยาม metric เปลี่ยน ให้บรรยายการเปลี่ยนนิยามแทนการฝืนเปรียบเทียบตัวเลข

เขียน brief โดยมีหลักฐานและคำถามเปิดเป็นแกน

จัดผลลัพธ์ตามหัวข้อธุรกิจสำคัญ แล้วแสดงข้อความปัจจุบัน ข้อความก่อนหน้า ตำแหน่งแหล่งข้อมูล และการตีความ ระบุพื้นที่ที่สายสนทนาให้หลักฐานไม่พอ แยกสิ่งที่ฝ่ายบริหารกล่าวอ้างออกจากสิ่งที่เอกสารอื่นยืนยันร่วมกัน transcript เพียงอย่างเดียวไม่ได้พิสูจน์ว่าคำอธิบายนั้นถูกต้อง หลีกเลี่ยงการเปลี่ยนภาษาที่มั่นใจ คะแนน sentiment หรือจำนวนวลีที่พูดซ้ำให้กลายเป็น claim เรื่องผลตอบแทนในอนาคต follow-up ที่มีประโยชน์ที่สุดมักเป็นคำถามเฉพาะที่นำไปตรวจสอบใน filing metric การดำเนินงาน หรือการเปิดเผยครั้งถัดไปได้

ตรวจคุณภาพและจัดการสายที่เกิดซ้ำ

ตรวจการระบุผู้พูด ความถูกต้องของคำอ้าง ความสอดคล้องของตัวเลข และการเข้าถึงแหล่งข้อมูลก่อนอนุมัติ เก็บ extraction ที่ถูกปฏิเสธและการแก้ไขด้วยมือไว้ สำหรับการวิเคราะห์ซ้ำ ให้ cache การแบ่งข้อความด้วย transcript hash และเปรียบเทียบเฉพาะ claim ที่ใหม่หรือถูกแก้จริง เก็บคำขอโมเดล งานถอดเสียง การอนุญาตข้อมูล และการรีวิวของนักวิเคราะห์ไว้ใน task ledger จำกัดการ retry อัตโนมัติ และคืนสถานะบางส่วนเมื่อส่วนสำคัญของแหล่งข้อมูลใช้ไม่ได้ จากนั้นเวิร์กโฟลว์ watchlist จะแจ้งผู้รีวิวเมื่อมีการเปลี่ยนแปลงที่มีความหมาย แทนการออกสรุปทั่วไปใหม่ทุกครั้งที่ job ทำงาน

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

หน้านี้เสนอวิธีการที่มีแหล่งข้อมูลรองรับและโครงสร้างผลลัพธ์ตัวอย่าง ไม่ได้นำเสนอเคส Earnings Call ที่รันจริง ความแม่นยำของ sentiment ที่วัดแล้ว หรือต้นทุนงานของ APIsRouter หน้า issuer ที่ลิงก์ไว้แสดงตำแหน่งของแหล่งข้อมูลอย่างเป็นทางการ เคสที่สมบูรณ์ควรเก็บ transcript ที่ได้รับอนุญาต บันทึกการดึงข้อมูล การตรวจสอบไขว้ ตัวตนของโมเดลที่ใช้จริง และการรีวิวโดยมนุษย์ก่อนเผยแพร่ข้อสรุป

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