กรณีศึกษา: เทรดอัลกอริทึมด้วยภาษา Go

 (massive.com)
4 คะแนน โดย GN⁺ 2023-07-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • กรณีศึกษาของโปรเจกต์ส่วนตัวที่สร้างบอตเทรดสำหรับรายย่อยด้วยภาษา Go ซึ่งคอยมอนิเตอร์หุ้นมากกว่า 5,500 ตัว ที่จดทะเบียนใน NYSE และ NASDAQ แบบเรียลไทม์ และทำการซื้อขายอัตโนมัติ
  • ในช่วงแรกทำได้เพียงขาดทุนอย่างรวดเร็ว แต่หลังผ่านการลองผิดลองถูกหลายปี ก็พัฒนามาจนถึงระดับ คุ้มทุน และบางครั้งก็มีกำไร
  • ระบบประกอบด้วย 3 คอมโพเนนต์หลัก คือผู้ให้บริการข้อมูล, แอปพลิเคชัน Go และโบรกเกอร์ โดยช่วงตลาดเปิดและปิดสามารถประมวลผลอีเวนต์ในหน่วยความจำได้มากกว่า 60,000 รายการต่อวินาที
  • บทเรียนสำคัญจากการใช้งานจริง ได้แก่ การทดสอบระบบด้วยการสุ่มซื้อ, การ สร้างแท่งเทียนเองจาก tick bar, และการย้ายสถาปัตยกรรมไปไว้ในหน่วยความจำทั้งหมด
  • เป็นตัวอย่างที่แสดงให้เห็นถึงความซับซ้อนและความเป็นไปได้จริงของการ สร้างแพลตฟอร์มเทรดส่วนบุคคล ในจุดตัดระหว่างการเงิน การเขียนโปรแกรม และการวิเคราะห์ข้อมูล

พื้นหลังและแรงจูงใจของโปรเจกต์

  • เริ่มต้นจากแนวคิดแบบตามเทรนด์ที่ต้องการ รันและบริหารดีลระยะสั้นแบบอัตโนมัติราว 500 รายการ ทั่วทั้งตลาดหุ้น และเก็บกำไรเล็กน้อยจากแต่ละดีล
  • เริ่มทำระบบอัตโนมัติเนื่องจากข้อจำกัดของการเทรดด้วยมือ
    • การทุ่มเงินทั้งหมดลงในหุ้นตัวเดียวมีความเสี่ยงสูงมาก แต่การมอนิเตอร์การเดิมพันระยะสั้นหลายสิบรายการพร้อมกันนั้นเกินขีดความสามารถของมนุษย์
    • การเข้าและออกอย่างรวดเร็วทำได้เฉพาะใน หุ้นที่มีสภาพคล่องสูง และเพื่อให้จับคู่คำสั่งได้เร็ว จำเป็นต้องซื้อครั้งละจำนวนน้อย
  • การบริหารโพสิชันก็เป็นโจทย์ใหญ่เช่นกัน เพราะการจับ จังหวะเข้าและออก ให้ได้ในการเดิมพันพร้อมกันมากกว่า 25 รายการมีความซับซ้อนมาก
  • มี ปัญหาเรื่องการขยายระบบ เพราะยิ่งขนาดเงินทุนมากขึ้น ก็ยิ่งต้องเพิ่มจำนวนการเดิมพัน
  • จำเป็นต้องคำนวณต้นทุนการเทรดอย่างรวดเร็ว เช่น สเปรด ค่าคอมมิชชัน slippage ค่าธรรมเนียม API และภาษี เพื่อประเมินว่าดีลนั้นคุ้มค่าหรือไม่

โครงสร้างโซลูชัน

  • ใช้เวลาหลายปีพัฒนาเครื่องมืออัตโนมัติที่คอยมอนิเตอร์หุ้นมากกว่า 5,500 ตัว ใน NYSE และ NASDAQ แบบเรียลไทม์ เพื่อให้ตัดสินใจเทรดได้รวดเร็ว
  • รันบนเครื่อง Linux ประสิทธิภาพสูงสำหรับเกมมิง: 16 คอร์, RAM 128GB, สตอเรจ NVMe 8TB, อินเทอร์เน็ต 1Gbps

  • 3 คอมโพเนนต์หลัก

    • Data Provider (Massive.com): ครอบคลุมทั้งข้อมูลย้อนหลังและข้อมูลเรียลไทม์ของทั้งตลาด พร้อม API และเอกสารที่เป็นมิตรกับนักพัฒนาและใช้งานเข้าใจง่าย มีโมเดลค่าบริการที่เรียบง่ายและเข้าถึงข้อมูลตลาดทั้งหมดได้โดยไม่มีข้อจำกัดที่สร้างขึ้นโดยเจตนา
    • แอปพลิเคชัน Go: เอนจินหลักที่รวบรวมและตีความ data feed คำนวณการตัดสินใจเทรด และส่งคำสั่งซื้อขายไปยัง API ของโบรกเกอร์
    • Broker (Interactive Brokers): ให้ API แบบเรียบง่ายสำหรับการส่งคำสั่งซื้อขาย

  • เหตุผลที่เลือกภาษา Go

    • แม้อุตสาหกรรมเฮดจ์ฟันด์จะพึ่งพา C++ และ Python เป็นหลัก แต่ผู้เขียนใช้ Go มาหลายปี และเห็นว่าเหมาะอย่างยิ่งกับ การประมวลผล data stream และการเชื่อมต่อ API

ฟังก์ชันหลักของแอปพลิเคชัน Go

  • Data Ingestion Loop

    • รวบรวม ข้อมูลเรียลไทม์อย่างต่อเนื่อง ของหุ้นมากกว่า 5,500 ตัวผ่าน Massive.com
    • ช่วงแรกพยายามบันทึกลงฐานข้อมูล แต่ไม่สามารถรองรับ อีเวนต์มากกว่า 60,000 รายการต่อวินาที ในช่วงตลาดเปิดและปิดได้ จึงเปลี่ยนมาใช้สถาปัตยกรรมในหน่วยความจำทั้งหมด

  • Build Our View Of The Stock Market

    • สร้าง มุมมองของตลาดหุ้นแบบเรียลไทม์ในหน่วยความจำ จากข้อมูลที่รวบรวมมา โดยติดตามราคา สเปรด กิจกรรมการซื้อขาย และอื่น ๆ
    • ทำให้สามารถจับโอกาสและลงมือเทรดได้ก่อนข่าวกระแสหลัก
    • เข้าถึงกิจกรรมการซื้อขายในช่วง pre-market, ตลาดปกติ และ after-hours ได้

  • BUY Signal Loop

    • เมื่อพบโอกาส จะส่งคำขอคำสั่งซื้อไปยัง API ของโบรกเกอร์
    • ไม่ได้อาศัยเพียงทริกเกอร์ง่าย ๆ แต่มีการคำนวณล่วงหน้า เช่น การประเมินกำไรจากสเปรด การกำหนดจำนวนหุ้นที่ต้องซื้อ และการรวมค่าธรรมเนียมกับภาษี
    • รวมตรรกะสำหรับกรณีราคาผันผวน การจับคู่คำสั่งบางส่วน และการยกเลิกคำสั่ง

  • Position Tracking System

    • เป็นลูปที่คอยมอนิเตอร์โพสิชันที่ถืออยู่ โดย เปรียบเทียบตารางโพสิชันกับราคาปัจจุบันแบบเรียลไทม์ เพื่อติดตามกำไรขาดทุน
    • สามารถดูเหตุผลที่ทริกเกอร์การเทรด สถานะปัจจุบัน และจุดขายผ่าน GUI ได้
    • มีบทบาทสำคัญในการปรับแต่งตรรกะ BUY และ SELL

  • SELL Signal Loop

    • เมื่อพบกำไรที่ดีหรือขาดทุนมากเกินไป จะส่งคำสั่งขายผ่าน API ของโบรกเกอร์
    • มีตรรกะซับซ้อน เช่น การอัปเดตราคาของหุ้นที่เคลื่อนไหวเร็ว และการจัดการคำสั่งที่จับคู่บางส่วน

เว็บอินเทอร์เฟซและภาพหน้าจอ

  • มีเว็บอินเทอร์เฟซในตัวสำหรับ สำรวจโครงสร้างข้อมูลทั้งหมด, แสดงผลข้อมูล, และดูเหตุผลของทริกเกอร์การเทรดรวมถึงสถานะปัจจุบัน
  • หน้าจอ ภาพรวมทั้งตลาด ที่แสดงราคา สเปรด และข้อมูลอื่น ๆ ของ ticker มากกว่า 5,500 ตัว
  • หน้าแยกของแต่ละสัญลักษณ์ (เช่น Tesla TSLA) ที่แสดง tick bar และข้อมูลที่เกี่ยวข้อง
  • อินเทอร์เฟซที่แสดงอัตราชนะ/แพ้และโพสิชันที่ยังเปิดอยู่ (ในเซสชันตัวอย่างบันทึก ขาดทุนประมาณ -$900)
  • หน้าจอที่แสดงเมทาดาทาและกราฟของการเทรดแบบเรียลไทม์ (แสดงจุดซื้อด้วยเส้นสีส้ม)
  • หน้าจอ คอนโซลล็อก ที่บันทึกอีเวนต์แบบเรียลไทม์ เช่น คำสั่งซื้อและขาย

การพัฒนากลยุทธ์และการแบ็กเทสต์

  • มองว่าแอปพลิเคชัน Go, กลยุทธ์ และการแบ็กเทสต์เป็น 3 องค์ประกอบหลักที่แยกจากกัน
  • แม้ว่าการพูดคุยส่วนใหญ่จะมุ่งไปที่กลยุทธ์ (เช่น mean reversion, trend following, linear regression) และการแบ็กเทสต์ แต่ งานปฏิบัติการและโลจิสติกส์ของการนำกลยุทธ์ไปใช้กับการเทรด intraday แบบเรียลไทม์ มักถูกมองข้าม
  • ใช้ข้อมูลย้อนหลังด้านการซื้อขายและ bid/ask จำนวนมหาศาลจาก Massive.com เพื่อสำรวจกลยุทธ์และทำแบ็กเทสต์ด้วย Python (ซึ่งเป็นเหตุผลที่ใช้สตอเรจ NVMe ขนาด 8TB)
  • การแบ็กเทสต์มักถูกเปรียบว่าเป็น “การขับรถไปข้างหน้าขณะมองกระจกหลัง” แต่ก็ยังเป็นวิธีตรวจสอบที่มีคุณค่าในการประเมิน สเปรด ภาษี ค่าธรรมเนียม และจุดเข้าออก
  • อินไซต์ที่ได้จากการพัฒนากลยุทธ์และการแบ็กเทสต์จะถูกแปลงไปเป็น ตรรกะของ BUY Signal Loop

ตัวอย่างโค้ด

  • มีทั้ง pseudocode ระดับสูงและตัวอย่างโค้ด Go จริง (แอปจริงมีขนาดประมาณ 7,000 บรรทัด)
  • โครงสร้างข้อมูลหลัก ได้แก่ TrackedSymbols (แมปของสัญลักษณ์ทั้งหมด, แฟลกเปิดการเทรด, global lock), Symbol (ข้อมูลซื้อขายและ bid/ask ดิบ, Aggregate, Position ฯลฯ), TradeEvent, QuoteEvent, Aggregate, Position
  • โครงสร้างของลูปหลัก
    • เก็บข้อมูลซื้อขายและ bid/ask ผ่านการเชื่อมต่อ WebSocket และ parse อีเวนต์
    • บันทึกลงใน symbol map แล้ว รวมข้อมูลซื้อขายและ bid/ask เข้าสู่ Aggregate
    • ส่งสัญญาณไปยังตรรกะการซื้อและขายผ่าน Go channel
    • ให้บริการผ่าน HTTP server สำหรับดู symbol ทั้งหมด, โพสิชัน, และ watchlist แบบกำหนดเอง

บทเรียนสำคัญ (Lessons Learned)

  • ความเข้าใจเรื่อง abstraction

    • NYSE และ NASDAQ ไม่ใช่ระบบเดียว แต่เป็นระบบกระจายขนาดใหญ่ที่ประกอบด้วย ตลาดซื้อขายมากกว่า 19 แห่ง
    • ข้อมูลแท่งเทียนคือ abstraction ขนาดใหญ่ ที่สร้างขึ้นจากข้อมูลการซื้อขายดิบ (tick) และการเข้าใจสิ่งนี้อย่างลึกซึ้งเป็นเรื่องจำเป็น
    • มีกฎที่ต่างกันไปตามช่วงเวลาการซื้อขายของตลาด เช่น pre-market, ตลาดปกติ, after-hours

  • การจัดการคำสั่งซื้อขาย

    • ความสำเร็จในการเทรดไม่ได้ขึ้นอยู่กับแค่การส่งคำสั่งซื้อขายอย่างง่าย แต่รวมถึง การกำหนดขนาดโพสิชันล่วงหน้า, ความสามารถในการซื้อขายอย่างรวดเร็ว, การบริหารโพสิชันมากกว่า 25 รายการพร้อมกัน, การคำนวณภาษีและค่าธรรมเนียม, การจัดการ slippage และการมอนิเตอร์สถานะคำสั่ง

  • edge case

    • มี edge case จำนวนมาก เช่น การส่งคำสั่ง การติดตาม การแก้ไข การยกเลิก การจับคู่บางส่วน และ การหยุดซื้อขายของตลาด ซึ่งถ้าพลาดอาจนำไปสู่ความเสียหายทางการเงิน
    • จำเป็นต้องทดสอบด้วย paper trading (การจำลอง) แทนการใช้เงินจริง
    • เคยมีประสบการณ์ซื้อหุ้นที่พุ่งขึ้น 40% ใน pre-market ที่จุดสูงสุดก่อนจะร่วงแรง และ ขาดทุน 40% ภายในไม่กี่นาทีเพราะปรับคำสั่งขายไม่สำเร็จ โดยช่วง pre-market และ after-hours มีกฎต่างจากตลาดปกติ ทำให้เกิดความผันผวนรุนแรงได้อย่างรวดเร็ว

  • การใช้การสุ่มซื้อ

    • การ ทดสอบฟังก์ชันหลักของระบบ สำคัญกว่าการค้นหากลยุทธ์ลับ
    • หากสุ่มซื้อหุ้นวันละ 1,000 รายการเป็นเวลา 1 สัปดาห์ ก็สามารถตรวจสอบตรรกะการซื้อขาย การจัดการคำสั่งที่จับคู่บางส่วน ตรรกะการยกเลิก และระบบติดตามโพสิชันได้อย่างมีประสิทธิภาพ
    • ผู้เขียนนำ การสุ่มซื้อในบัญชี paper trading มาเป็นส่วนหนึ่งของกระบวนการทดสอบ เพราะเป็นวิธีที่มีประสิทธิภาพในการตรวจสอบหลายแง่มุมของระบบพร้อมกัน

  • tick bar vs time bar

    • แท่งเทียนจากโบรกเกอร์ครอบคลุมกรอบเวลาคงที่ (เช่น 30 วินาที) แต่เมื่อเกิดความผันผวนสูง อาจมีทั้ง 100 ดีลและหลายพันดีลปะปนกันในเวลาเดียวกัน
    • การสร้างแท่งข้อมูลเองจากข้อมูล tick และ bid/ask ดิบโดยอิงตามจำนวนดีล จะให้ความละเอียดสูงกว่ามากในช่วงกิจกรรมหนาแน่นอย่างตอนตลาดเปิดและปิด และยังเพิ่มเมตริกแบบกำหนดเองอย่างสเปรดได้

  • การย้ายไปสู่ in-memory

    • วิธีเก็บข้อมูลลงฐานข้อมูลในช่วงแรกไม่สามารถรองรับสไปก์ของกิจกรรมขนาดใหญ่ในช่วงตลาดเปิดและปิดได้
    • จึงเปลี่ยนมาใช้สถาปัตยกรรมในหน่วยความจำทั้งหมด โดยอาศัย แมปขนาดใหญ่ที่มี mutex lock เพื่อแก้ปัญหาการขยายระบบ
    • บันทึกข้อมูลโดย dump โครงสร้างข้อมูลทั้งหมดเป็น ไฟล์ gob แบบบีบอัด และสามารถโหลดกลับได้ตอนรีสตาร์ต โดยข้อมูลเติบโตเกิน 40GB ต่อวัน และเพื่อรองรับ gob dump ขนาดนี้จำเป็นต้องแพตช์ Go build
    • หลังจากเคยสูญเสีย ข้อมูลสถานะทั้งหมด ของระบบขณะรันจริงเพราะไฟดับ จึงสรุปว่า UPS เป็นสิ่งจำเป็น

  • ความซับซ้อนและความโดดเดี่ยว

    • โปรเจกต์นี้ท้าทายและใช้เวลามากกว่าที่คาด จากงานอดิเรกเล็ก ๆ กลายเป็น ความหมกมุ่นอย่างจริงจัง
    • เพราะทุกอย่างวัดกันที่ยอดเงินในบัญชี มันจึงอาจเป็นงานที่โดดเดี่ยวและมีอารมณ์ขึ้นลงอย่างรุนแรง

  • การใช้ Go และ Python ร่วมกัน

    • ใช้ระบบเทรดเขียนด้วย Go แต่ใช้ ไลบรารีด้าน data science ที่หลากหลายของ Python สำหรับการสำรวจข้อมูล เป็นแนวทางแบบไฮบริด

  • การใช้พีซีส่วนตัว

    • เดสก์ท็อปพีซีสมัยใหม่ทรงพลังพอที่จะรับมือกับ การมอนิเตอร์ตลาดหุ้นทั้งตลาดแบบเรียลไทม์ ได้ หากมีการปรับแต่งอย่างเหมาะสม

  • การใช้ ChatGPT

    • แทนที่จะพึ่งการค้นหาและการอ่านเมื่อไม่รู้วิธีแก้ปัญหา ผู้เขียนเปลี่ยนมาอธิบายปัญหาให้ ChatGPT ฟัง ถามวิธีแก้ และขอให้ช่วยสร้างโค้ด ซึ่งทำให้รู้สึกว่า ประสิทธิภาพเพิ่มขึ้น 3 เท่า

ประสบการณ์กับเหตุการณ์ในตลาด

  • สามารถตรวจจับความผิดปกติในตลาดได้หลากหลายผ่านระบบของตนเอง เช่น หุ้นมีม, อีเวนต์ IPO ขนาดใหญ่, ช่วงตลาดขาขึ้นและขาลง, ข่าวจาก Fed และการขึ้นดอกเบี้ย และมองเห็นสิ่งเหล่านี้ได้ก่อนข่าว
  • เป็นประสบการณ์ที่เหมือนได้นั่ง แถวหน้าสุดเพื่อชมเหตุการณ์ในตลาด ขณะทุกอย่างเกิดขึ้นตรงหน้า

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-07-01
ความคิดเห็นใน Hacker News

  • เคยทำงานในวงการ HFT อยู่พักหนึ่ง วงการนี้น่าสนใจมากจริง ๆ และก็ดีใจที่ผู้เขียนต้นฉบับรู้สึกสนุกคล้ายกัน
    เหตุผลที่ตัวแพลตฟอร์มเองมักหายไปจากบทสนทนาก็เพราะการเทรดเป็นพื้นที่ที่มีทั้ง เทคโนโลยีขั้นสูง·ความซับซ้อน·กฎระเบียบเข้มงวด·การแข่งขันรุนแรง อัดรวมกันอยู่ในที่เดียว
    แค่การสร้างระบบส่งคำสั่งซื้อขาย ระบบบริหารความเสี่ยง และระบบติดตามสถานะการถือครอง ก็ถือเป็นความสำเร็จใหญ่แล้ว แต่สำหรับบริษัทเทรด มันแทบจะเป็น ค่าใช้จ่ายเพื่อให้ได้เข้าร่วมเกม อยู่แล้ว
    เพราะงั้นผู้คนเลยคุยกันเรื่องกลยุทธ์มากกว่า เพราะทุกคนมีแพลตฟอร์มพื้นฐานกันครบแล้ว และตอนนี้ก็อยู่ในขั้นหาวิธีทำเงินจากมัน
    ยิ่งไปกว่านั้น ผู้เล่นในตลาดก็ไม่ได้เล่นเกมเดียวกันทั้งหมด ในโลก HFT มีการแข่งขันแย่งชิงอัลฟาที่อยู่ได้ไม่กี่วินาที โดยพยายามลดเวลาใน FPGA ลงระดับนาโนวินาที และลดความหน่วงในเครือข่ายไร้สายของนิวเจอร์ซีย์ลงระดับไมโครวินาที แต่ฝั่งธนาคารกลับสนใจการเลือกตั้งและภูมิรัฐศาสตร์มากกว่าอากาศที่ Carteret ถ้าฝนตก วันนั้นเครือข่ายไมโครเวฟก็ใช้ไม่ได้
    ระหว่างสองขั้วนั้นยังมีกลยุทธ์อีกนับไม่ถ้วนที่ไล่หาอัลฟาซึ่งอยู่ได้นานตั้งแต่ไม่กี่ชั่วโมงถึงหลายสัปดาห์ จนยากจะคุยกันด้วยภาษาเดียวกันในฟอรัมสาธารณะ ถึงอย่างนั้นก็เป็นโลกที่สนุกและบางทีก็คิดถึงมันอยู่เหมือนกัน

    • แพลตฟอร์มไม่ได้เป็นแค่ค่าใช้จ่ายเพื่อเข้าร่วมเท่านั้น แต่ยังเป็นส่วนที่ตรงไปตรงมามากกว่าเวลาจะสร้างด้วย แม้แต่ในแนวหน้าของการแข่งขันด้าน latency ส่วนใหญ่ก็เป็นแค่การดันระบบไปจนสุดข้อจำกัดของงบประมาณ ไม่ใช่งานที่ต้องค้นพบบางอย่างใหม่ทั้งหมด
      ส่วน กลยุทธ์ ต่างหากที่เป็นพื้นที่ของการค้นพบ มีกลยุทธ์ที่เป็นที่รู้จักดีและยังทำกำไรได้อยู่บ้าง แต่ส่วนใหญ่บริษัทใหญ่ ๆ เอาไปหมดแล้ว ที่เหลือคือกระบวนการสำรวจค้นหา กลยุทธ์บางอย่างทำกำไรได้แค่ในสภาวะตลาดช่วงสั้นมาก
      ผมก็คิดถึงมันบ้างเหมือนกัน แต่ทุกอย่างถูกรวมศูนย์มากขึ้นจนตอนนี้ส่วนใหญ่กลายเป็น โลกของบริษัทขนาดใหญ่ ไปแล้ว
    • พูดตามตรง มันดูไร้ความหมายยิ่งกว่าคริปโตเสียอีก
    • แม้ตัวอย่างจะมีแค่หนึ่งเดียว แต่จากที่เคยทำงานในบริษัทเทรดด้วยสัญญา 2 ปี ก็พบว่าการทำให้ธุรกิจเดินหน้าไม่ได้อาศัยแค่ ศักยภาพด้านเทคนิค เท่านั้น
    • เห็นด้วย 100% เลย ผมอ่านหนังสือแทบทุกเล่มที่หาได้ แต่ไม่มีใครพูดถึงเรื่อง แพลตฟอร์ม เลย และมุมมองนี้ฟังดูสมเหตุสมผลมาก
      ดูเหมือนเนื้อหาพวกนี้ส่วนใหญ่จะถูกเก็บเป็นไซโลอยู่ภายในแต่ละบริษัท และแทบไม่ถูกพูดถึงจากภายนอก
      HFT เล่นกันคนละเกมจริง ๆ ผมเคยอ่านทั้งสถาปัตยกรรมของตลาดหลักทรัพย์และโครงสร้างสายสัญญาณจริง ๆ แล้ว ฝั่งผมรับข้อมูลจาก SIP ขณะที่ HFT เชื่อมตรงเข้าตลาด [1]
      ผมเทรดระดับวินาที ส่วน HFT เทรดระดับไมโครวินาทีอย่างที่พูดไป จึงเทียบกันไม่ได้เลย ในบางแง่ การที่ไม่ได้แข่งกับพวกเขาโดยตรงก็ออกจะดีเหมือนกัน หรืออาจจะแข่งอยู่แต่ก็ยังพอทำเงินได้นิดหน่อยก็ได้
      [1] https://www.researchgate.net/figure/Latencies-in-the-Electro...
    • ผมอยู่ฝั่งการเทรดความถี่ปานกลาง คำนวณเงื่อนไขตลาดหลายอย่าง แล้วส่งคำสั่งมากสุดก็แค่ไม่กี่คำสั่งต่อนาที อยากเข้าใจโลก HFT ให้มากกว่านี้
      โดยพื้นฐานแล้วมันคือการ ทำให้การเทรดความถี่ปานกลางเร็วขึ้น หรือมีข้อได้เปรียบเฉพาะอย่าง เช่น การได้สิทธิ์ก่อนในคิวคำสั่งกันแน่

  • ถ้ามีคำถามเกี่ยวกับโปรเจ็กต์นี้ก็ยินดีตอบ เริ่มจากเป็นโปรเจ็กต์ข้าง ๆ แล้วกลายเป็นหมกมุ่นเต็มตัว
    ตัวระบบเองไม่ได้มีอะไรเป็นความลับมากนัก แก่นสำคัญคือการมี แพลตฟอร์มที่แข็งแรง สำหรับเสียบกลยุทธ์เข้าไปใช้งาน
    อาจจะปล่อยเป็นโอเพนซอร์สก็ได้ แต่ก่อนหน้านั้นคงต้องเก็บกวาดพวกแฮ็กสารพัดที่ยัดไว้ก่อน

    • อันนี้ก็น่าจะน่าสนใจ: https://www.techtrader.ai/#wall
      Tech Trader ถูกอธิบายว่าเป็น ระบบเทรดอัตโนมัติเต็มรูปแบบ ที่รันด้วยเงินจริงมานานกว่า 10 ปีโดยไม่มีการแทรกแซงจากมนุษย์หรือการอัปเดตใด ๆ
      จุดต่างจากระบบอัลกอริทึมแบบดั้งเดิมคือ ไม่ได้ใช้แนวทางเชิงปริมาณ statistical arbitrage หรือ high-frequency แต่พยายามมองหุ้นแบบเดียวกับที่มนุษย์มอง ขณะเดียวกันก็ใช้วินัยอันเยือกเย็นและสมาธิที่ไม่สิ้นสุดของเครื่องจักร
      ตั้งแต่เปิดตัวในเดือนธันวาคม 2012 ก็ทำการเทรดอัตโนมัติเต็มรูปแบบด้วยเงินจริงมาโดยตลอด และผู้สร้างคือโปรแกรมเมอร์ที่เรียนรู้ด้วยตนเองเพียงคนเดียวซึ่งใช้ชื่อในเกมว่า pftq
    • เป็นบทความที่ดีมาก ผมเองก็ทำโปรเจ็กต์คล้ายกันด้วย Go แต่ใช้แค่ ข้อมูลแท่งราคาแบบรายนาที แทนข้อมูล tick แบบเรียลไทม์
      อยากรู้ว่าพอจะแชร์แนวทางการเสียบกลยุทธ์หลายแบบเข้าไปได้ไหม ระบบกลยุทธ์แบบปลั๊กอินกินข้ามหลายเลเยอร์ได้ เลยยุ่งยากขึ้นเร็วมาก
      แล้วในฝั่ง backtest คุณเก็บข้อมูล bid/ask กับ tick ทั้งหมดไว้เพื่อ replay หรือใช้แค่ข้อมูลสรุปย้อนหลังเท่านั้น
    • ผมทำ algorithmic trading เป็นโปรเจ็กต์เสริมมาหลายปีแล้ว แต่ทั้งหมดทำผ่าน TD Ameritrade ได้ข้อมูลราคาและข้อมูลอื่น ๆ ฟรีเพราะมีบัญชีอยู่ และก็ใช้ข้อมูลฟรีจากที่อื่นเพิ่มด้วย
      พออ่านบทความแล้วก็คิดจะลองตั้งค่า WebSocket กับ Polygon แต่เห็นว่าแพ็กเกจแรกที่มี WebSocket ราคา 29 ดอลลาร์ และแพ็กเกจ Advanced ที่มีข้อมูลเรียลไทม์ราคา 200 ดอลลาร์ต่อเดือน
      ข้อมูลเรียลไทม์ที่เรียก API ได้ไม่จำกัดดูดีพอสมควร แต่กลยุทธ์ของผมกับขนาดเงินทุนทั่วไปมีอัตราชนะสูงสุดแค่ราว 78% เลยยากจะให้เหตุผลกับค่าใช้จ่ายเดือนละ 200 ดอลลาร์
      อยากรู้ว่าคุณใช้แพ็กเกจไหน และข้อดีข้อเสียของแพ็กเกจนั้นคืออะไร ถ้าอยากตอบทางอีเมลก็มีอยู่ในโปรไฟล์
    • อยากรู้ว่ามีอีเมลไหม ผมกำลังสร้างระบบคล้ายกันด้วย F# มาค่อนข้างนานแล้ว เลยอยากลองคุยกัน
    • ถ้าต่อเข้ากับ TWS API ของ IB แล้วจะใช้มันสำหรับส่งคำสั่งซื้อขายอย่างเดียวด้วย ผมสงสัยว่าเราน่าจะเลือกดึงราคาจาก IB API แบบเรียลไทม์ไปเลย และไม่ใช้ polygon.io เลยก็ได้หรือเปล่า
      ไม่แน่ใจว่า IB ส่ง price feed แบบเรียลไทม์หรือไม่ หน้าจอ TWS มีการอัปเดตตลอด เลยเหมือนว่ามันส่งข้อมูลแบบเรียลไทม์อยู่ แต่ก็สงสัยว่า order book มีให้ผ่าน API ด้วยไหม
      รู้ว่าบทความนี้ลงในบล็อกของ polygon.io แต่ก็อยากรู้ว่าโครงสร้างแบบนี้จะทำงานได้ด้วย IB/TWS API อย่างเดียวหรือไม่

  • หนึ่งในแนวคิดที่ถูกเข้าใจผิดมากที่สุดเกี่ยวกับ algorithmic trading คือ ในระบบส่วนใหญ่ ความเร็ว ไม่ใช่ปัจจัยชี้ขาด
    โมเดลอย่าง https://grizzlybulls.com/models/vix-ta-macro-mp-extreme ในระบบของผม เอาชนะตลาดได้มากในการเทรดจริงมานานกว่า 3 ปี แต่โดยเฉลี่ยเทรดเพียงประมาณทุก ๆ 18 วันทำการครั้งหนึ่ง และสัญญาณก็เกิดขึ้นเฉพาะใกล้จุดแบ่งตามกรอบเวลารายชั่วโมงเท่านั้น
    ช่วง 18 เดือนที่ผ่านมาอ่อนกว่าช่วงแรก เพราะมีการเปลี่ยนแปลงเชิงโครงสร้างครั้งใหญ่จากเงินเฟ้อสูงและการขึ้นดอกเบี้ยอย่างรวดเร็ว แต่ตั้งแต่เปิดไซต์ในเดือนมกราคม 2022 ก็ยังทำผลตอบแทนได้ +14.11% ขณะที่ SPX อยู่ที่ -7.83%
    ทำได้โดยไม่ใช้เลเวอเรจ และในช่วงเวลาเดียวกัน maximum drawdown ก็อยู่ที่ -16.48% ต่ำกว่า SPX ที่ -27.57%

    • การใส่สิ่งที่ดูเหมือนข้อมูล backtest ที่เริ่มตั้งแต่ปี 2009 ลงในกราฟ ดูไม่ค่อยตรงไปตรงมาเท่าไร จุดเริ่มต้นนั้นเป็นการเลือกแบบตามอำเภอใจทั้งหมด และคุณก็บอกว่าเริ่มเมื่อ 3 ปีก่อน ดังนั้นมันจึงไม่ใช่ผลงานจริง
      เป็นการจัดองค์ประกอบให้โมเดลดูเหมือนเอาชนะตลาดได้มากจริง ๆ ถ้าคุณมีเหมืองทองที่ยังไม่มีใครขุดจริงก็น่าทึ่งมาก แต่ส่วนตัวผมเชื่อได้ยากเพราะมี สัญญาณอันตราย อยู่หลายอย่าง
    • ผมสงสัยว่าโมเดลเหล่านี้ใช้ข้อมูลภายนอกมากแค่ไหน หรือมีการป้อนข้อมูลโดยมนุษย์หรือ การปรับจูนละเอียด เป็นประจำมากน้อยเพียงใด

  • ถ้าสนใจ algorithmic trading ลองดู Collective2 ได้ เป็นที่ที่วิศวกรขายสัญญาณซื้อขายแบบเก็บค่าสมัครสมาชิก
    ให้ความรู้สึกเหมือน ไมเนอร์ลีก ของ algorithmic trading และค่อนข้างน่าสนใจ
    ระบบจะติดตามกำไรขาดทุน จึงหลอกลวงรายงานผลการดำเนินงานได้ยาก และถ้าคุณอนุญาตให้ Collective2 เข้าถึงบัญชี Interactive Brokers ก็สามารถให้มันส่งคำสั่งตามสัญญาณแทนได้
    เป็นบริการที่มีมาอย่างน้อย 10 ปี จึงดูผลงานระยะยาวได้ แต่ระบบส่วนใหญ่ก็อยู่ได้ไม่ยาวขนาดนั้น
    https://collective2.com/leader-board
    แม้แต่อันดับต้น ๆ ตอนนี้ก็แทบไม่มีรายไหนอยู่ได้นาน โดยมากราว 1-2 ปีเท่านั้น แสดงให้เห็นว่า อัลฟาของระบบส่วนใหญ่หายไปค่อนข้างเร็ว
    เส้นผลตอบแทนก็กระโดกกระเดก และกำไรส่วนใหญ่ก็มักมาจากการเทรดเพียงไม่กี่ครั้ง

  • เวลาออกแบบระบบเทรดอัตโนมัติ แกนสำคัญคือ data feed และการเก็บข้อมูล การสร้าง feature การสร้างสัญญาณ การเทรดจริงและการจัดการคำสั่ง รวมถึงการประสานงานทั้งหมด
    ข้อมูลต้นทางแทบไม่ค่อยถูกใช้ตัดสินใจโดยตรง และบ่อยครั้งที่ การสร้าง feature ที่ดีเป็นปัจจัยหลักของความสำเร็จ ค่าเฉลี่ยเคลื่อนที่เป็นตัวอย่างหนึ่ง แต่ทุกวันนี้แทบใช้แค่นั้นไม่ได้แล้ว
    บทความนี้แสดงด้านเทคนิคของการประมวลผลข้อมูลและการจัดการคำสั่ง รวมถึงภาพรวมของทั้ง pipeline แต่ผมอยากเห็นรายละเอียดเพิ่มเกี่ยวกับการขยายโซลูชันและการทำ asynchronous implementation
    โดยเฉพาะเมื่อใช้ Go ก็มีโครงสร้าง channel ที่เหมาะกับงานแบบนั้นอยู่แล้ว เลยยิ่งอยากรู้
    เข้าใจว่าไม่ใช่ประเด็นหลักของบทความ แต่ข้อมูลทั่วไปเกี่ยวกับตรรกะการเทรด วิธีเสียบกลยุทธ์ใหม่เข้าไป และวิธีทำให้กลยุทธ์เดิม parameterize ได้ ก็น่าจะมีประโยชน์
    ลิงก์ท้ายบทความน่าสนใจดี และผมกำลังพัฒนา intelligent trading bot ที่อิง machine learning และ feature engineering (https://github.com/asavinov/intelligent-trading-bot) ดังนั้นบทความแบบนี้อาจสำคัญสำหรับผม

    • เห็นด้วยครับ ส่วนนั้นเป็นสิ่งที่ผมตกหล่นไป
      โครงสร้างเรียบง่ายมาก คือให้ goroutine กับ channel สื่อสารกัน และล็อกด้วย mutex ใหญ่ตัวเดียว
      เมื่อมีข้อมูลใหม่เข้ามา ก็จะสร้างค่ารวมที่จำเป็น เช่น candlestick แบบอิง tick แล้วข้อมูลนั้นจะไป trigger ลูปตรรกะ BUY ถ้าตรวจพบบางอย่างก็จะส่งคำสั่งผ่าน IB API
      มันเรียบง่ายมาก ไม่มีอะไรซับซ้อน ผมเคยติดตามมากกว่า 100 position พร้อมกันในคราวเดียว และมันก็ทำงานได้ดี เลยไม่ได้ไปแตะตรรกะ asynchronous ที่ซับซ้อนมากนัก
      พารามิเตอร์ต่าง ๆ ตอนนี้ hardcode อยู่ในลูป BUY จริง ๆ ฟังดูแปลกก็ได้ แต่ในระบบเล็ก ๆ มันไม่ได้เปลี่ยนบ่อยขนาดนั้น
      วิธีทำก็คือรันเทรดไม่กี่รอบ ปรับค่า แล้วรีสตาร์ตเพื่อทดสอบใหม่ ถ้าเป็นสภาพแวดล้อมระดับ enterprise ก็คงมีภาษาสำหรับงานนี้หรือมี hot loading อะไรทำนองนั้น แต่สำหรับผม hardcode ก็เพียงพอและใช้ได้ดีมาก

  • ทั้ง Go เองหรือภาษาใด ๆ ก็ไม่ได้ให้ข้อได้เปรียบมากนัก สิ่งที่ให้ข้อได้เปรียบคือ อัลกอริทึมการเทรด ซึ่งหาได้ยากเสมอ
    เคยใช้เวลาหลายเดือนเพื่อหาพารามิเตอร์ที่เหมาะสมที่สุด แต่สุดท้ายมันใช้ได้แค่กับข้อมูลในอดีต และของจริงกลับต่างออกไปโดยสิ้นเชิง
    ถ้าอัลกอริทึมและกลยุทธ์สมบูรณ์แบบ ต่อให้ใช้ Visual Basic ก็อาจดีกว่า Go, Rust หรือภาษาอื่นใดได้ ภาษาเป็นแค่เครื่องมือ
    การใช้ Go นั้นไม่ใช่เรื่องเสียหาย แต่ชื่อบทความอาจทำให้เข้าใจผิดได้เล็กน้อย คนอาจตีความว่ามันมีข้อได้เปรียบบางอย่าง ทั้งที่ไม่ใช่แบบนั้น
    และสำหรับ HFT ผมมองว่าภาษาที่มี garbage collector ไม่ใช่ตัวเลือกที่ดีนัก

    • สุดท้ายแล้วก็ต้องตัดสินใจว่าจะซื้อหรือขาย และจะทำเท่าไร ซึ่งการตัดสินใจนั้นก็ต้องไปแข่งขันกับการตัดสินใจอื่น ๆ ที่อิงอยู่บนตรรกะแบบอื่น
      เนื่องจากการพัฒนาตรรกะแบบนั้น หรือก็คือกลยุทธ์ ด้วยมือนั้นยากอยู่แล้ว ผมเลยสร้าง บอตเทรดอัจฉริยะ ที่สกัดกลยุทธ์การเทรดจากข้อมูลในอดีต
      https://github.com/asavinov/intelligent-trading-bot
      ตอนนี้มันทำงานกับคริปโต แต่ก็สามารถนำไปใช้กับตลาดอื่นได้
      https://t.me/intelligent_trading_signals
      การที่มันใช้ได้ดีแค่กับข้อมูลในอดีตแต่ต่างจากสถานการณ์จริงนั้นเป็นเรื่องที่พบได้บ่อยมาก ประเด็นสำคัญคือการสร้างกลยุทธ์ที่ยังใช้ได้กับข้อมูลอนาคตที่ยังไม่เคยเห็น
      อัลกอริทึมสำหรับ backtest เองก็ต้องออกแบบไม่ให้ข้อมูลจากอนาคตรั่วไหลย้อนเข้ามาในอดีตด้วย
    • ผมเป็นคนเขียนบทความนี้เอง และก็ทำมันด้วย Go จริง ๆ เหตุผลคือ Go เป็นภาษาโปรแกรมที่ผมใช้เป็นหลัก
      ในอุตสาหกรรมนี้นิยมใช้ C++ กับ Python กันมากกว่า ดังนั้นการ ใช้ Go อาจกลับเป็นข้อเสีย ด้วยซ้ำ แต่ภาษาที่ผมทำเป็นก็คือภาษานี้
      ไม่ได้มีเจตนาจะทำให้คนเข้าใจผิด Go ค่อนข้างเหมาะกับงานรับและประมวลผลข้อมูล รวมถึงเรียก remote API เลยใช้งานได้ดีจริง
      แต่ถ้าจะใช้สิ่งนี้เป็นฐานเพื่อหางาน ก็อาจไม่ได้ช่วยมากนัก
    • ถ้าเขียนโค้ดแบบไม่ให้มี allocation เลย ภาษาที่มี garbage collector ก็สามารถใช้กับ HFT ได้
      มีบางที่ที่ใช้ Java แล้วจัดสรรหน่วยความจำที่ต้องใช้ทั้งหมดไว้ล่วงหน้าตั้งแต่เริ่มต้น Jane Street ก็ขึ้นชื่อว่าใช้ OCaml เช่นกัน
    • มันขึ้นอยู่กับกรณี ผมเคยได้ยินว่ามีบางที่ใช้ Java โดยทำ heap ขนาดใหญ่ ลดการ allocation ให้ใกล้ศูนย์ที่สุด แล้วรีสตาร์ตแอปพลิเคชันเป็นระยะก่อนที่ heap จะเต็ม
      แบบนี้ประสิทธิภาพก็ค่อนข้างดี และไม่ต้องกังวลเรื่อง บั๊กหน่วยความจำ
    • นั่นคือ overfitting มันไม่ได้เกิดแค่กับการ optimization โดยคอมพิวเตอร์เท่านั้น ต่อให้คนปรับแต่งเองก็เกิดได้
      หลังจากทดลองกับข้อมูลในอดีตอยู่ช่วงหนึ่ง ประโยชน์ของข้อมูลชุดนั้นก็จะลดลง

  • ผมกำลังทำบอตด้วย TypeScript เพราะเป็นภาษาที่ผมรู้ และ Python เพราะมีเครื่องมือเยอะ
    มันเป็นงานที่หนักมากและ โดดเดี่ยว สุด ๆ โปรเจกต์อื่นที่ผมเคยทำมักจะทำเป็นทีมเสมอ ต่อให้เป็นทีมเล็กมากและทำงานกันอย่างอิสระ อย่างน้อยก็ยังมีประชุมหรือ standup กันบ้าง
    แต่นี่ผมทำคนเดียวมา 6 เดือนแล้ว ถึงขั้นคิดว่าจะชวนเพื่อนมาร่วมแค่เพื่อไม่ให้ต้องทำคนเดียว

    • ผมก็เป็นอีกคนที่พัฒนา algorithmic trading คนเดียวเหมือนกัน ลองติดต่อกันและคุยกันดูก็ได้
    • บทความนี้มาถูกจังหวะดีเลย ผมกำลังหาข้ออ้างเพื่อเรียนรู้เทคโนโลยีอื่น ๆ ผ่านการมอนิเตอร์ออปชันอยู่พอดี
      มันเป็น side project เลยอาจไม่ได้คืบหน้าอะไรมาก แต่ก็ยินดีคุยกันเสมอ
    • ผมสงสัยว่าคุณคาดหวังจะแข่งขันกับมืออาชีพได้อย่างไร มันยากที่จะเร็วกว่าเขา และถ้าไม่มีคนระดับปริญญาเอกด้านคณิตศาสตร์หลายคน ก็น่าจะยากที่จะสร้างอัลกอริทึมที่ดีกว่า
      วิธีเดียวที่ผมนึกออกคือการได้ ข้อมูล ที่พวกเขาไม่มี

  • ผมมองว่าบทความนี้แทบไม่มีสาระและออกแนวล่อคลิกเต็ม ๆ สรุปก็คือ “ใช้ polygon.io เป็นข้อมูลตลาดได้ แต่ algorithmic trading ก็ยังยากอยู่ดี เลยยังไม่มีอะไรให้แชร์มากนัก”

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

  • น่าจะดีถ้าได้เจอคนที่ชอบ วงจรป้อนกลับล้วน ๆ ของโค้ด กลยุทธ์ และเงิน ที่การเทรดมอบให้
    ผมศึกษาจังหวะเวลาและความสัมพันธ์ระหว่างหุ้นกับดัชนีในฐานะแหล่งของ alpha มาสักพัก และก็ได้ผลอยู่บ้าง
    ตอนนี้กำลังพยายามทำให้กระบวนการนั้นเป็นอัตโนมัติ และผมสนุกกับงานนี้มากจริง ๆ
    ผมไม่ได้พยายามเป็น market maker และก็ไม่ได้คิดจะย้ายไปมาระหว่างหุ้นหลายตัวตลอดเวลา ผมโฟกัสกับการขัดเกลาโมเดลที่แม่นยำเพื่อทำกำไรจากหุ้นไม่กี่ตัวให้ดีมาก ๆ
    เครื่องมือที่มีประโยชน์ได้แก่ TradingView และอินดิเคเตอร์/กลยุทธ์ของ Pinescript, โมเดล Excel ที่ใช้ข้อมูล export ออกมาสำหรับ backtest, Python และ Go สำหรับ machine learning ฝั่ง backend, และ ChatGPT สำหรับเร่งรอบการลองโค้ดใหม่ให้เร็วขึ้น
    ถ้าสนใจ อยากคุยกันที่ trading @ dianazink.com

  • เป็นบทความที่ดี คำอธิบายชัดเจนและโดยเฉพาะสกรีนช็อตก็ดีมาก
    ผมเข้าใจที่คุณไม่ลงรายละเอียดเรื่องกลยุทธ์ แต่ก็อยากรู้ว่าการเทรดนี้อิงกับ การวิเคราะห์ทางเทคนิค ล้วน ๆ หรือมีการใช้ข้อมูลภายนอกหรือฟีดข้อมูลทางเลือกด้วย
    พูดอีกอย่างคือ มันเป็นระบบที่ค่อนข้างปิด โดยมีแค่ input จาก Polygon และ output ผ่าน IB API หรือเป็นโครงสร้างที่กว้างกว่านั้นซึ่งรวมถึงฟีดข้อมูลแบบปรับแต่งเองจากเว็บข่าว, Twitter, Reddit ด้วย
    ถ้าเป็นอย่างหลัง ผมก็สงสัยด้วยว่าเวลา coverage ของข้อมูลย้อนหลังจากบางแหล่งยังไม่ครบ คุณจัดสมดุลกับการ backtest ย้อนหลังอย่างไร

    • ข้อมูลของผมทั้งหมดมาจาก polygon.io และไม่มีข้อมูลภายนอก
      ช่วงหลังผมกำลังดูวิธีใช้ตาราง lookup ของค่าทางประวัติศาสตร์ที่คำนวณไว้ล่วงหน้าเพื่อตรวจจับความผิดปกติ เช่น “กิจกรรมแบบนี้ในหุ้นตัวนี้ถือว่าปกติไหม”
      BXRX วันนี้เป็นตัวอย่างที่ดี [1]
      ผมกำลังดู activity ในตลาดออปชันด้วย เพื่อพยายามใช้มันเป็น สัญญาณ
      [1] https://www.google.com/search?q=BXRX