Python ในการเทรด – วิเคราะห์ข้อมูล ระบบอัตโนมัติ และวิจัย

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

1. Python ช่วยตรงไหนจริง และตรงไหนเพียงดูเหมือนทางแก้

สเปรดชีตจัดการบันทึกการเทรดได้ตราบเท่าที่คุณยังอดทน ขอบเขตขึ้นกับเครื่อง จำนวนสูตร และการสร้างชีต จึงไม่มีจำนวนธุรกรรมกลม ๆ ที่อธิบายได้ แต่มีขอบเขตตายตัวหนึ่งข้อที่ไม่ขึ้นกับอะไร เพราะเขียนในสเปกไฟล์: Excel หนึ่งแผ่นมีได้ 1,048,576 แถวและ 16,384 คอลัมน์ ^[16] ประวัติ tick หนึ่งปีของคู่เงินเดียวมากกว่านั้นหลายเท่า และไม่มีเทคนิคใดเลี่ยงได้

Python ไม่ใช่เวทมนตร์ มันแก้ปัญหาเฉพาะสี่ข้อที่สเปรดชีตแก้ไม่ได้หรือใช้เวลาหลายชั่วโมง:

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

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

สิ่งที่ Python ไม่ทำ ไม่เหมาะกับการเทรดความหน่วงต่ำมาก ซึ่งไมโครวินาทีมีความหมาย ภาษาที่แปลคำสั่งและมี garbage collector เป็นตัวเลือกไม่ดี แต่ “Python ช้าเกินเทรด” ก็ผิดเช่นกัน สำหรับกลยุทธ์ที่เข้าตอนเปิดแท่ง H1 ถัดไป เวลาคำนวณน้อยมากเมื่อเทียบกับเวลาคำสั่งผ่านเครือข่ายและเซิร์ฟเวอร์โบรกเกอร์

ความเร็วจาก vectorization มาจากกลไก ไม่ใช่เวทมนตร์ การทำทั้งคอลัมน์รันใน numpy ที่คอมไพล์แล้ว แทนลูป interpreter ระดับความต่างขึ้นกับข้อมูล ชนิดงาน และฮาร์ดแวร์ หากจะอ้างค่าต้องวัดบนเครื่องตนด้วยโมดูล timeit จากไลบรารีมาตรฐาน ^[4] และบันทึกพร้อมเวอร์ชันไลบรารี อ้าง benchmark คนอื่นโดยไม่มีสภาพแวดล้อมไม่ใช่การวัด

เปรียบเทียบเครื่องมือวิเคราะห์ของเทรดเดอร์:

ความต่างแถวสุดท้ายสำคัญกว่าที่ดู Pine Script รันใน TradingView ส่วน MQL รันใน MetaTrader และ Python รันที่คุณสั่ง อิสระนี้ทำให้คุณรับผิดชอบสภาพแวดล้อม ได้แก่ เวอร์ชันไลบรารี เขตเวลาระบบ ความต่อเนื่อง และสิทธิที่สคริปต์จะแตะบัญชี

2. สภาพแวดล้อมทำซ้ำได้: เวอร์ชัน venv และ requirements

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

สภาพแวดล้อมทำซ้ำได้เมื่อระบุหกอย่าง: เวอร์ชัน Python วิธีแยกสภาพแวดล้อม รุ่น dependencies ที่ตรึง แหล่งข้อมูลพร้อมช่วงวันที่ เขตเวลา และ random seed ทุกจุดที่ผลขึ้นกับการสุ่ม หากขาด ผลเป็นเรื่องเล่า ไม่ใช่การวัด

สภาพแวดล้อมเสมือนไม่ใช่ทางเลือกเสริม ติดตั้งไลบรารีแบบ global ทำให้การอัปเดตโปรเจกต์หนึ่งทำอีกโปรเจกต์เสีย การแยกฟรี ใช้สิบกว่าวินาที และอาศัยโมดูล venv จากไลบรารีมาตรฐาน ^[4]:

# Windows, PowerShell
py -3.12 -m venv .venv
.venv\Scripts\Activate.ps1

# macOS / Linux
python3.12 -m venv .venv
source .venv/bin/activate

# ใช้ร่วมกันทั้งสองระบบ
python -m pip install --upgrade pip
python -m pip install pandas numpy matplotlib requests python-dotenv
python -m pip freeze > requirements.txt

บรรทัดสุดท้ายมักถูกข้ามที่สุด pip freeze บันทึกเวอร์ชันตรงตัวของทุกอย่างที่ติดตั้งจริง รวม dependencies ที่ไม่รู้ว่ามี ให้วางไฟล์นั้นใน repository ข้างโค้ด การสร้างสภาพแวดล้อมซ้ำบนเครื่องอื่นจึงเป็นการใช้ python -m pip install -r requirements.txt ไม่ใช่คาดเดา

สภาพแวดล้อมที่ใช้ตรวจออฟไลน์ครั้งปัจจุบัน สำหรับตัวอย่างคำนวณหัวข้อ 4 และ 9: Windows 11, Python 3.12.10, pandas 3.0.5 และ NumPy 2.5.3 ตรวจเมื่อ 8 ตุลาคม 2026 รายการต่อไปบันทึกแพ็กเกจที่เกี่ยวกับการคำนวณ เป็นบัญชีจำกัด ไม่ใช่ส่งออกทุกแพ็กเกจในเครื่อง^[1][3].

# เวอร์ชัน dependencies ที่ใช้ตรวจคำนวณในเครื่อง
numpy==2.5.3
pandas==3.0.5
python-dateutil==2.9.0.post0
six==1.17.0
tzdata==2026.4

# interpreter
Python 3.12.10

pandas ใช้แพ็กเกจอื่นด้วย คำอธิบายสภาพแวดล้อมจึงไม่จบที่รุ่นไลบรารีเดียว Dependencies ทำให้เครื่องต่างกันได้ คำสั่งติดตั้งด้านบนแสดงขั้นตอนตั้งโปรเจกต์ ไม่ใช่บันทึกการติดตั้งระหว่างการตรวจครั้งนี้ สร้าง requirements.txt แบบครบในสภาพแวดล้อมตนด้วย python -m pip freeze และเก็บกับโค้ด

ไฟล์นี้ไม่ใช่คำอธิบายสภาพแวดล้อมครบทั้งบทความ แต่เฉพาะส่วนคำนวณ ต้องอ่านเช่นนั้น ส่วนตรวจ HTTP error ในหัวข้อ 7 รันในสภาพแวดล้อมที่เพิ่ม requests 2.34.2 ส่วนทดสอบ safety gate หัวข้อ 8 ไม่ใช้แพ็กเกจนอกไลบรารีมาตรฐาน เวอร์ชันของ matplotlib และ python-dotenv ไม่ระบุเพราะไม่ใช้ในตัวอย่างที่รันจริง การใส่ “ให้เรียบร้อย” คือเขียนเลขที่ไม่มีใครตรวจ หากตั้งสภาพแวดล้อมทั้งชุด ใช้คำสั่งติดตั้งเป็นจุดเริ่มแล้วตรึง pip freezeของตนเอง มีเพียงไฟล์ dependencies นั้นที่บอกเกี่ยวกับผลของคุณ

Notebook หรือไฟล์ .py? ใช้ทั้งคู่แต่คนละงาน Jupyter เหมาะเมื่อยังไม่รู้ว่าค้นหาอะไร รันเซลล์ ดูผล เปลี่ยนพารามิเตอร์ แต่มีคุณสมบัติที่ไม่เหมาะกับโค้ดดำเนินการ คือสถานะตัวแปรขึ้นกับลำดับรัน ไม่ใช่ลำดับที่เขียน Notebook ที่รันลำดับ 1–3–2 ดูเหมือนรันตามลำดับ โค้ดที่แตะบัญชีต้องเป็นไฟล์ .py ปกติ รันจากบนลงล่าง พร้อมการทดสอบและ log

Anaconda และ Google Colab เป็นทางลัดที่มีต้นทุนเฉพาะ Anaconda ติดตั้งแพ็กเกจมากพร้อมกันและมีตัวจัดการ dependencies เอง เริ่มง่ายแต่บรรยายสภาพแวดล้อมอย่างแม่นยำยากเมื่อผสม conda กับ pip Colab รันในเบราว์เซอร์ไม่ต้องติดตั้ง เหมาะเรียนรู้ แต่สร้างสภาพแวดล้อมใหม่ทุกเซสชันและเปลี่ยนเวอร์ชันโดยคุณไม่เกี่ยวข้อง เนื้อหาที่ต้องทำซ้ำในอีกปีต้องมีวินัยเพิ่มทั้งสองแบบ

ไลบรารีสำหรับเริ่ม – สี่รายการ ไม่ใช่สี่สิบ (มีห้าแพ็กเกจ เพราะรายการแรกเป็นคู่):

• pandas และ numpy – โครงสร้างข้อมูลและคำนวณ
• matplotlib – กราฟ
• requests – สื่อสาร HTTP กับ API
• python-dotenv – โหลดการตั้งค่าจากไฟล์นอก repository

เพิ่มอินดิเคเตอร์เมื่อจำเป็นจริง มีข้อแก้จากคู่มือเก่า: TA-Lib เผยแพร่ binary wheel ทางการพร้อมไลบรารี C บน PyPI ดังนั้น OS สถาปัตยกรรม และ Python ที่รองรับ ใช้เพียง pip install TA-Lib โดยไม่ต้องดาวน์โหลดไม่เป็นทางการหรือคอมไพล์เอง^[9] ตรวจ wheel นั้นก่อนติดตั้ง ไม่ใช่รับรองว่าทุกเครื่องใช้ได้ Metadata ที่ตรวจ 8 ตุลาคม 2026 ระบุ TA-Lib 0.8.1 และ pandas-ta ยังเป็น 0.4.71b0 เผยแพร่กันยายน 2025^[13] ตัวหลังตรึง numba==0.61.2 จึงตรวจเฉพาะข้อกำหนด pandas ไม่พอ การทดสอบติดตั้งเดิมบน Python 3.14.3 วันที่ 22 สิงหาคม 2026 ล้มเหลวที่ dependency นี้ด้วยข้อความ only versions >=3.10,<3.14 are supported ข้อสังเกตนั้นไม่ใช้กับตัวอย่างปัจจุบันบน Python 3.12.10 โดยอัตโนมัติ การตรวจปัจจุบันอ่าน metadata PyPI ไม่ได้ติดตั้งหรือรัน TA-Lib หรือ pandas-ta กฎตรวจข้าง ๆ จึงแคบไป รุ่นใหม่และเงื่อนไข pandas ที่เข้ากันไม่ได้พิสูจน์ว่าชุด dependencies ทั้งหมดติดตั้งและทำงานได้ ต้องตรวจไลบรารีคอมไพล์ที่ตรึง wheel สำหรับ interpreter และทดลองข้อมูลเล็กด้วย Metadata สองรุ่นล่าสุดไม่อธิบายทั้งประวัติ ให้ประเมินช่องว่างเดิมใน repository

Random seed ทุกจุดที่ผลขึ้นกับการสุ่ม เช่น แบ่งตัวอย่าง bootstrap จำลอง และตั้งต้นโมเดล ต้องตั้งและบันทึก seed ใน numpy: rng = np.random.default_rng(20260822) ^[3]แล้วใช้เฉพาะออบเจ็กต์นั้น หากไม่มี รันสคริปต์เดียวกันสองครั้งได้สองผลและไม่ชัดว่าอธิบายผลใด

3. pandas และ numpy: OHLCV ดัชนีเวลา เขตเวลา

numpy คำนวณอาร์เรย์ตัวเลข pandas จัดโครงสร้าง DataFrame คืออาร์เรย์ที่มีชื่อคอลัมน์และดัชนี ซึ่งมักเป็นเวลา ในข้อมูลตลาด ดัชนีเวลาสำคัญกว่าตัวคำนวณ เพราะตัดสินว่ากำลังคำนวณสิ่งที่คิดจริงหรือไม่

การโหลด – pd.read_csv() จัดการไฟล์หลายล้านแถว รู้จักตัวคั่น และแปลงวันที่ได้เมื่อระบุคอลัมน์ แต่ค่าเริ่มต้นไม่รู้เขตเวลา ซึ่งต้องกำหนดก่อน

เปลี่ยนช่วงเวลา – รวม M1 เป็น H4 โดยคง OHLCV ใช้คำสั่งเดียว: df.resample('4h').agg({'open':'first', 'high':'max', 'low':'min', 'close':'last', 'tick_volume':'sum'}) ระวังสองอาร์กิวเมนต์ที่มักไม่ตั้งแต่กำหนดการตีความ: label กำหนดว่าใช้ต้นหรือท้ายหน้าต่างเป็นป้าย และ closed กำหนดว่ารวมขอบด้านใดในหน้าต่าง ค่าเริ่มต้นความถี่ส่วนใหญ่ติดป้ายที่ขอบซ้าย ^[1] หมายถึงเวลาแท่งคือเวลาเปิด ใน pandas 3.0.5 การใช้ resample('4h') กับแท่งรายชั่วโมงแปดแท่งจากเที่ยงคืนให้ป้าย 00:00 และ 04:00 หากสัญญาณถือเวลาแท่งปิดแต่ข้อมูลติดป้ายตอนเปิด คุณเลื่อนผลทั้งหมดหนึ่งช่วงโดยไม่รู้ตัว

สถิติเคลื่อนที่ – df['close'].rolling(20).mean() ให้ ค่าเฉลี่ยเคลื่อนที่, .rolling(20).std() ให้ส่วนเบี่ยงเบนที่ใช้กับ Bollinger Bands, .ewm(span=20).mean() ให้ค่าเฉลี่ยเอ็กซ์โพเนนเชียล ^[1] ทั้งหมดคำนวณจากข้อมูลในอดีตเทียบกับแถวปัจจุบันเท่านั้น คุณสมบัตินี้เป็นฐานความถูกต้องของทุกอย่างที่เหลือ

การกรอง – เขียนเงื่อนไขผสมครั้งเดียว: df[(df['sma20'] > df['sma50']) & (df['rsi'] < 30)] ต้องใส่วงเล็บรอบแต่ละเงื่อนไข เพราะ & มีลำดับก่อนการเปรียบเทียบใน Python หากละจะเกิด error แทนคำตอบผิดเงียบ ๆ ซึ่งในจุดนี้เป็นข่าวดี

เขตเวลาเป็นการตัดสินใจ ไม่ใช่รายละเอียดเล็ก ข้อมูลโบรกเกอร์มักใช้เวลาเซิร์ฟเวอร์ ข้อมูลภายนอกมัก UTC และ OS อาจใช้เวลาท้องถิ่นพร้อมการเปลี่ยนนาฬิกาตามโซน หากผสมนาฬิกาสามชุด การวิเคราะห์ “เซสชันลอนดอน” จะศึกษาอย่างอื่นแทน

หลักปฏิบัติคือยืนยันโซนต้นทางก่อนและคำนวณใน UTC สำหรับเวลาที่มี offset ชัดหรือ Zให้ใช้ pd.to_datetime(column, utc=True) ส่วนเวลาเซิร์ฟเวอร์ไม่มี offset ให้แปลงก่อน กำหนดโซนที่ยืนยันด้วย tz_localize() พร้อมจัดการชั่วโมงกำกวมและไม่มีอยู่ แล้วใช้ tz_convert("UTC") การใช้ utc=True อย่างเดียวถือค่าที่ไม่มีเขตเป็น UTC ไม่ได้อนุมานโซนโบรกเกอร์ ให้แปลงเป็น Europe/London เฉพาะแสดงผล^[1] ดัชนีที่มีโซนชัดและบันทึกแหล่งข้อมูลช่วยรวมชุดอย่างสอดคล้อง

ข้อมูลขาดหาย ประวัติ OHLCV มีช่องว่างจากสุดสัปดาห์ วันหยุด พักทางเทคนิค หรือไม่มีราคา pandas มี df.ffill()ซึ่งเติมค่าล่าสุด แต่กับราคามักไม่ดี เพราะสร้างแท่งความผันผวนศูนย์และกดส่วนเบี่ยงเบนมาตรฐาน ควรลบช่วงขาดและนับจำนวน

หลายตราสารพร้อมกัน สำหรับวิเคราะห์พอร์ตสกุลเงิน pandas มีดัชนีหลายชั้น (MultiIndex) ให้ DataFrame เดียวเก็บหลายคู่โดยมีคู่และเวลาเป็นดัชนี จึงคำนวณสหสัมพันธ์บนแกนเวลาเดียวกันได้ หากทุกชุดอยู่โซนและกริดเวลาเดียวกันก่อน มิฉะนั้นกำลังคำนวณความสัมพันธ์ข้อมูลที่เหลื่อมกัน

บันทึกผล df.to_csv() อ่านได้และใช้ทั่วไป df.to_parquet() ให้ไฟล์เล็กและอ่านเร็วกว่า พร้อมรักษาประเภทคอลัมน์และเขตเวลาของดัชนี ^[1] ส่วน CSV เขียนทุกอย่างเป็นข้อความ จึงแปลงใหม่เมื่อโหลด สำหรับข้อมูลทำงานขนาดใหญ่ Parquet สะดวกกว่า แต่ต้องมีเอนจินเขียนเพิ่ม จึงใส่ใน requirements.txt.

4. ตัวอย่างขั้นต่ำ: CSV → UTC → ผลตอบแทน → ตรวจช่องว่าง → บันทึก

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

สมมติฐาน ไฟล์ CSV มีคอลัมน์ time,open,high,low,close,tick_volume คอลัมน์ time ใช้ ISO 8601 พร้อมตัวบอกโซน (Z หมายถึง UTC) ระบุช่วงเป็นรายชั่วโมง ไฟล์ที่รันจงใจมีสามข้อบกพร่องที่เกิดจริง: เวลาซ้ำหนึ่งค่า ชั่วโมงหายหนึ่งช่วง และ volume ว่างหนึ่งเซลล์ วางหกแถวในโค้ดเพื่อให้รันแล้วได้ผลเดิมโดยไม่ดาวน์โหลดไฟล์ ผลที่ทำซ้ำไม่ได้ไม่ใช่ผล สภาพแวดล้อม: Python 3.12.10, pandas 3.0.5, numpy 2.5.3, Windows 11, [ณ วันที่: 2026-10-08].

"""ตัวอย่างขั้นต่ำ: CSV -> UTC -> log return -> ตรวจช่องว่าง -> บันทึก"""
import io
from pathlib import Path

import numpy as np
import pandas as pd

# ใส่ข้อมูลในโค้ดเพื่อทำซ้ำผลได้โดยไม่ดาวน์โหลดไฟล์
# หกแถวมีสามข้อผิดพลาดจงใจ: เวลา 01:00 ซ้ำ
# ชั่วโมง 03:00 หาย และเซลล์ volume ว่างที่ 02:00
CSV_DATA = """time,open,high,low,close,tick_volume
2026-06-01T00:00:00Z,1.08140,1.08170,1.08131,1.08153,812
2026-06-01T01:00:00Z,1.08153,1.08190,1.08150,1.08176,640
2026-06-01T01:00:00Z,1.08153,1.08195,1.08149,1.08182,655
2026-06-01T02:00:00Z,1.08182,1.08188,1.08130,1.08141,
2026-06-01T04:00:00Z,1.08120,1.08125,1.08040,1.08050,903
2026-06-01T05:00:00Z,1.08050,1.08061,1.07980,1.07993,774
"""

OUTPUT = Path("EURUSD_H1_returns.csv")
INTERVAL = "1h"  # ความถี่ข้อมูลนำเข้าที่ระบุ


def load_data(source) -> pd.DataFrame:
    """โหลด CSV และตั้งดัชนีมีเขตเวลาเป็น UTC

    ตั้งใจไม่เรียง เพราะลำดับแถวเป็นข้อมูลคุณภาพการส่งออก
    เรียงหลังรายงานเท่านั้น
    """
    df = pd.read_csv(source)
    # utc=True บังคับโซนเดียว หากไม่มี pandas อาจคืนดัชนีไม่มีโซน
    df["time"] = pd.to_datetime(df["time"], utc=True, format="ISO8601")
    return df.set_index("time")


def quality_report(df: pd.DataFrame, interval: str) -> dict:
    """ตัวนับที่ต้องดูก่อนคำนวณ"""
    expected = pd.date_range(df.index.min(), df.index.max(), freq=interval, tz="UTC")
    return {
        "rows": int(len(df)),
        "index_duplicates": int(df.index.duplicated().sum()),
        "missing_cells": int(df.isna().sum().sum()),
        "missing_timestamps": int(len(expected.difference(df.index))),
        # วัดก่อนเรียง หลัง sort_index() การตรวจนี้จะเป็น
        # true เสมอและไม่พบไฟล์ที่ลำดับเวลาสับสน
        "file_chronology_ok": bool(df.index.is_monotonic_increasing),
    }


def add_returns(df: pd.DataFrame) -> pd.DataFrame:
    """Log return = ln(close_t / close_(t-1)) หน่วยลอการิทึมธรรมชาติ ไม่มีมิติ"""
    df = df[~df.index.duplicated(keep="last")].copy()
    df["log_return"] = np.log(df["close"]).diff()
    return df


def main() -> None:
    df = load_data(io.StringIO(CSV_DATA))  # ใช้จริง: load_data(Path("EURUSD_H1.csv"))
    print("ตรวจคุณภาพ:", quality_report(df, INTERVAL))
    df = add_returns(df.sort_index())
    print("แท่งหลังลบซ้ำ:", len(df))
    print("ผลรวม log return:", round(float(df["log_return"].sum()), 6))
    print("ส่วนเบี่ยงเบนมาตรฐาน log return (ช่วง 1h และ 2h):",
          round(float(df["log_return"].std()), 6))
    df.to_csv(OUTPUT)
    print("บันทึก:", OUTPUT)


if __name__ == "__main__":
    main()

ผลการรัน บนข้อมูลในโค้ดและสภาพแวดล้อมที่อธิบาย คุณทำซ้ำได้ตรงกัน:

ตรวจคุณภาพ: {'rows': 6, 'index_duplicates': 1, 'missing_cells': 1, 'missing_timestamps': 1, 'file_chronology_ok': True}
แท่งหลังลบซ้ำ: 5
ผลรวม log return: -0.00148
ส่วนเบี่ยงเบนมาตรฐาน log return (ช่วง 1h และ 2h): 0.000467
บันทึก: EURUSD_H1_returns.csv

การตีความ สคริปต์พบข้อบกพร่องทั้งสามก่อนคำนวณ ซึ่งคือคุณค่าทั้งหมด ผลรวม log return คือ −0.00148 เมื่อเหลือห้าแท่งหลังลบซ้ำ หรือสี่ช่วงระหว่างราคาที่สังเกตต่อเนื่อง จึงหมายถึงราคาลดรวมประมาณ 0.15 เปอร์เซ็นต์ในหน้าต่างนั้น หกคือจำนวนแถว ไม่ใช่จำนวนแท่ง เพราะหนึ่งแถวซ้ำ ส่วนเบี่ยงเบนมาตรฐาน 0.000467 เป็นปริมาณ ต่อแท่ง H1 รายแท่ง ไม่ใช่ต่อปีหรือต่อวัน เทียบโดยไม่ระบุช่วงไม่มีความหมาย Log return ไม่มีหน่วยและบวกตามเวลาได้ จึงรวมด้วยการบวก ไม่ใช่คูณแบบ simple return

ข้อจำกัด ห้าแท่งแสดงกลไก ไม่ใช่ตัวอย่างสถิติ จึงสรุปตลาดไม่ได้ สคริปต์ไม่จำลองสเปรด คอมมิชชัน หรือ slippageเพราะไม่ใช่ backtest คำนวณผลราคามิใช่ผลบัญชี การตรวจเวลาขาดสมมติว่าข้อมูลเป็นรายชั่วโมงจริง หากคร่อมสุดสัปดาห์ เวลาที่ “ขาด” มากอาจปกติ ต้องตั้งเกณฑ์เตือนตามปฏิทินเทรด อีกกับดักคือตัววัด สคริปต์พบช่องแต่ไม่เติม ผลตอบแทนข้ามชั่วโมงที่ขาดจึงครอบคลุมสองช่วงไม่ใช่หนึ่ง ในตัวอย่างเป็นหนึ่งในสี่ผลตอบแทน แต่ทั้งชุดยังติดป้าย “ต่อแท่ง H1” ซึ่งลดทอน ไม่ใช่การวัดแม่นยำ ทางที่ตรงไปตรงมามีสองแบบ: reindex เป็นกริดชั่วโมงเต็มแล้วปล่อยช่องว่าง หรือรายงานการผสมระยะเวลาเป็นข้อจำกัดชัดเจน

เหตุใดตรวจลำดับก่อนเรียง หาก load_data() ลงท้ายด้วยการเรียก sort_index() ช่อง file_chronology_ok จะเป็น true เสมอ การตรวจที่อ้างในรายงานจะจับอะไรไม่ได้ และไฟล์ลำดับมั่วผ่านไร้ร่องรอย การตรวจที่ล้มเหลวไม่ได้แย่กว่าไม่ตรวจ เพราะให้ความมั่นใจเท็จ จึงวัดลำดับขณะโหลดจากไฟล์และเรียงหลังรายงานเท่านั้น

สถานะการตรวจ: ส่วนนี้รันในสภาพแวดล้อมที่ระบุและผลด้านบนเป็นผลจริงของโปรแกรม รุ่น pandas อื่นอาจจัดรูป dictionary หรือปัดต่าง

5. การแสดงผล: หนึ่งคำถามต่อกราฟ

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

matplotlib เป็นไลบรารีกราฟพื้นฐานของ Python เป็นแบบคงที่และไวยากรณ์ค่อนข้างเทอะทะ plotly ให้กราฟโต้ตอบ ชี้จุดดูวันและค่า ซูมช่วง และส่งออก HTML ข้อมูลใหญ่มากอาจช้าและต้องติดตั้งแยก สำรวจใน notebook ใช้ plotly สะดวกกว่า ส่วนกราฟบันทึกรายงานใช้ matplotlib

กราฟสี่แบบที่ควรวาดเป็น เพราะตอบต่างคำถาม:

1. เส้น equity – ผลสะสมตามเวลา ตอบว่าโตหรือไม่และเมื่อใด ไม่ใช่จะทำเงินเท่าใด
2. กราฟ drawdown – ระยะจากจุดสูงสุดสะสมทุกขณะ แสดงลึกสุดและเวลาฟื้น ต้องระบุเสมอว่าคิด balance หรือ equity และเป็นเปอร์เซ็นต์หรือเงิน
3. Heat map เซสชัน – ผลแยกตามชั่วโมงและวัน ต้องจัดเขตเวลาก่อน ไม่เช่นนั้นอธิบายชั่วโมงที่ไม่มีอยู่
4. การแจกแจงผลตอบแทน – histogram ผลรายธุรกรรม แสดงหางหนาและความไม่สมมาตรที่ตัววัดความเสี่ยงเดียวไม่บอก

กราฟแท่งจาก DataFrame โดยตรงใช้ mplfinanceซึ่งเป็นชั้นบน matplotlib โดยมีข้อควรระวังตามหัวข้อ 2: รุ่นล่าสุดสิงหาคม 2023 และยังเป็นเลข pre-release (0.12.10b0) ^[13] [ณ วันที่: 2026-10-08] ไม่ได้ตัดสิทธิ์ทันที แต่ก่อนเพิ่มใน requirements.txtต้องตรวจบนข้อมูลตนว่าทำงานกับรุ่น matplotlib และ pandas ที่ใช้หรือไม่ รุ่นใหม่ไม่ตรวจแทนคุณ หากจะแปลงสคริปต์เป็น dashboard ง่าย ๆ พร้อม slider และ dropdown มี streamlitซึ่งเผยแพร่สม่ำเสมอ ^[13]เริ่มด้วย streamlit run dashboard.py ทั้งสองช่วยประหยัดเวลาและเพิ่ม dependencies ใน requirements.txt จึงเพิ่มอย่างรู้ตัว

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

6. Backtesting ใน Python: ส่วนของโค้ดและส่วนของวิธีวิทยา

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

pandas เองไม่ใช่ backtest คูณคอลัมน์สัญญาณกับผลตอบแทนได้ชุดผล แต่ไม่จำลองสิ่งระหว่างตัดสินใจกับดำเนินการ ได้แก่ เวลาเข้า ราคาเข้า สเปรด คอมมิชชัน สวอป เติมบางส่วน และปฏิเสธคำสั่ง ยอมรับได้ในขั้นคัดไอเดีย หากเรียกว่าการลดทอน ไม่ใช่ผลจริง

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

แถวสุดท้ายไม่ใช่พิธีการ ทุก framework สมมติราคาและเวลาเติม และสมมติฐานนั้นมักตัดสินผลแทนตรรกะกลยุทธ์ ก่อนเชื่อให้หาคำตอบสามข้อ: เติมเข้าเท่าใด คิดต้นทุนอย่างไร และจัดการ gap ระหว่างแท่งอย่างไร

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

7. API โบรกเกอร์: ยืนยันตัวตน ขีดจำกัด ข้อผิดพลาด สภาพแวดล้อมทดสอบ

“โบรกเกอร์มี API” บางครั้งถูกอ่านว่า “สคริปต์เข้าบัญชีได้ไม่จำกัด” ซึ่งไม่จริง API มี endpoint พร้อมยืนยันตัวตน สิทธิ rate limit และรหัสผิดพลาด บางครั้งแยกทดสอบกับจริง แต่ไม่เสมอ วิธีแยกต้องดูเอกสาร ไม่ใช่กฎที่สมมติ ก่อนบรรทัดแรกควรตอบเก้าข้อ: ยืนยันตัวตนอย่างไร token มีสิทธิใด กี่คำขอต่อวินาที แยกทดสอบจากจริงอย่างไร คืนข้อมูลประเภทใด มีรหัสผิดพลาดใด จำกัดภูมิภาคหรือไม่ รักษาการเชื่อมต่ออย่างไร และ token มีสิทธิส่งคำสั่งหรือไม่

ขีดจำกัดเป็นตัวเลขเผยแพร่ แต่ต้องอ่านว่าจำกัดอะไร ความต่างนี้หายในคู่มือส่วนใหญ่ ทั้งที่กำหนดวิธีออกแบบลูป OANDA v20 มีสองเลขจากสองเอกสารและหมายถึงต่างเรื่อง คู่มือนักพัฒนาระบุค่า ที่บังคับจริง: “120 คำขอต่อวินาที ส่วนเกินได้ HTTP 429” สำหรับ REST API พร้อมยี่สิบ stream ที่ทำงานและสองการเชื่อมต่อใหม่ต่อวินาที ทั้งหมดนับตาม IP ผู้ส่ง ^[15] ส่วนเอกสาร best practices ให้ คำแนะนำ: ควรจำกัดหนึ่งร้อยคำขอต่อวินาทีบนการเชื่อมต่อเดิม และสองการเชื่อมต่อใหม่ต่อวินาที ^[5]. [ณ วันที่: 2026-08-22]

หนึ่งร้อยต่อวินาทีคือเพดานแนะนำ หนึ่งร้อยยี่สิบคือระดับที่เกินแล้วเซิร์ฟเวอร์ตอบ 429 โค้ดที่ถือ “100/s เป็นสูงสุด” ไม่เสียหาย แต่ถ้าคิดว่าเป็นขีดบังคับและไม่จัดการ 429 จะล้มเมื่อเกินครั้งแรก เพราะขีดจริงไม่เท่าคำแนะนำ เป็นเลขผู้ให้บริการเดียว ไม่ใช่กฎตลาด รายอื่นต่างกันและ [ฟีเจอร์ขึ้นกับโบรกเกอร์/บัญชี] ตรวจเอกสารของคุณก่อนเขียน polling loop

สภาพแวดล้อมทดสอบคือคนละ host ไม่ใช่คนละโหมด OANDA แยกให้เห็นในที่อยู่: api-fxpractice.oanda.com สำหรับฝึก และ api-fxtrade.oanda.com สำหรับจริง พร้อมคู่ที่อยู่แบบเดียวกันสำหรับ stream ^[15] [ณ วันที่: 2026-08-22] ดีเพราะตรวจผิดในโค้ดได้ โดยเพิ่มเงื่อนไขกั้น production host หากผู้ให้บริการใช้ที่อยู่เดียวแยกด้วย token อย่างเดียว แย่กว่าเพราะมีเพียง configuration กั้น

สี่ทางทั่วไปเชื่อม Python สู่บัญชี แต่ละทางต่างสถาปัตยกรรม ไม่ใช่ต่างความ “ล้ำ”:

นอกตลาดเงิน ควรรู้จัก ccxt ไลบรารีรวมการเข้าถึงตลาดคริปโต ไม่ใช้กับ FX/CFD ที่โบรกเกอร์รายย่อย แต่บางครั้งถูกเข้าใจว่าใช้ได้ทุกกรณี

cTrader หากใช้ cTrader เขียนอัลกอริทึมใน cTrader Algo ซึ่งรองรับ C# และ Python โดยตรง รวม cBot อินดิเคเตอร์ และ plugin ^[8] [ณ วันที่: 2026-08-22] เป็นแบบต่างจากด้านบน โค้ดรันในแพลตฟอร์ม ไม่ใช่ process แยกเชื่อม API ตรวจขอบเขตฟังก์ชันและวิธีเริ่มในเอกสารล่าสุด เพราะพัฒนาต่อเนื่อง

คีย์และรหัสผ่าน: ห้ามอยู่ในโค้ด

คีย์ API ในสคริปต์จะตามเข้า repository สำรอง และประวัติรุ่น ไม่หายจาก Git เมื่อแค่ลบบรรทัด Repository สาธารณะถูกสแกนหาอัตโนมัติ ที่ยอมรับได้มีเพียงตัวแปรสภาพแวดล้อม ไฟล์ตั้งค่านอก repository และลงใน .gitignoreหรือระบบจัดการ secret ที่ส่งค่าผ่านวิธีดังกล่าว

"""การตั้งค่าและ secret: ห้ามข้อมูลอ่อนไหวในไฟล์โค้ด"""
import os
from dataclasses import dataclass

HOSTS = {
    "practice": "https://api-fxpractice.oanda.com",
    "live": "https://api-fxtrade.oanda.com",
}


class MissingConfiguration(RuntimeError):
    """เกิดเมื่อขาดข้อมูลที่ต้องมีก่อนเริ่ม"""


@dataclass(frozen=True)
class Configuration:
    token: str
    account: str
    environment: str

    @property
    def host(self) -> str:
        return HOSTS[self.environment]


def _required(name: str) -> str:
    value = os.environ.get(name, "").strip()
    if not value:
        # จงใจไม่มีค่าเริ่มต้น เพราะ token ว่างจะส่งคำขอ
        # โดยไม่มีสิทธิ แทนหยุดโปรแกรม
        raise MissingConfiguration(f"ไม่มีตัวแปรสภาพแวดล้อม {name}")
    return value


def load_config() -> Configuration:
    environment = os.environ.get("BROKER_ENV", "practice").strip().lower()
    if environment not in HOSTS:
        raise MissingConfiguration(f"BROKER_ENV ต้องเป็นค่าหนึ่งใน {sorted(HOSTS)}")
    return Configuration(
        token=_required("BROKER_API_TOKEN"),
        account=_required("BROKER_ACCOUNT_ID"),
        environment=environment,
    )

สามการตัดสินใจจงใจ ค่าเริ่มต้นเป็น practice ไม่ใช่จริง ตั้งผิดจึงไป demo ตัวแปรที่ขาดหยุดโปรแกรมแทนสตริงว่าง และไม่มีค่าเริ่มต้น token แม้ในคอมเมนต์ เพราะ secret ในคอมเมนต์ก็เปิดเผยแล้ว

แพ็กเกจ python-dotenv ที่กล่าวก่อนไม่แทนโค้ดนี้ แต่ทำก่อน การเรียก load_dotenv() (หลัง from dotenv import load_dotenv) โหลดไฟล์ .env นอก repository เข้าตัวแปรสภาพแวดล้อม process แล้ว load_config() จึงอ่าน ฟังก์ชันไม่ต้องรู้ว่ามาจากไฟล์ ระบบ หรือ secret manager ส่วนไฟล์ .env ต้องลงใน .gitignore พร้อมโฟลเดอร์ตั้งค่าทั้งหมด

ดึงข้อมูล: timeout การลองซ้ำ และรหัสตอบกลับ

คำขอไม่จำกัดเวลาอาจค้างตลอดและหยุดทั้ง process ลองซ้ำไร้ขีดจำกัดกิน quota จนโดนตัด ส่วนต่อไปแสดงการป้องกันขั้นต่ำสำหรับอ่านข้อมูล และความต่างที่ภายหลังช่วยบัญชี: ลองซ้ำได้เฉพาะงาน idempotent ที่ทำซ้ำแล้วไม่เปลี่ยนสถานะฝั่งโบรกเกอร์

import logging
import time

import requests

TIMEOUT_S = 10.0        # วินาทีไม่มีกิจกรรมเชื่อมต่อ/อ่าน ไม่ใช่เส้นตายทั้งงาน
MAX_ATTEMPTS = 4            # จำนวนลองรวมครั้งแรก
BACKOFF_S = 1.0         # ฐานหน่วงแบบเอ็กซ์โพเนนเชียล หน่วยวินาที

log = logging.getLogger("data")


class ApiError(RuntimeError):
    """ข้อผิดพลาดที่ลองใหม่ไม่แก้"""


def fetch_candles(session: requests.Session, host: str, token: str,
                   instrument: str, parameters: dict) -> dict:
    """ลองซ้ำเฉพาะ GET ที่ไม่เปลี่ยนสถานะโบรกเกอร์"""
    url = f"{host}/v3/instruments/{instrument}/candles"
    headers = {"Authorization": f"Bearer {token}"}

    for attempt in range(1, MAX_ATTEMPTS + 1):
        delay = BACKOFF_S * 2 ** (attempt - 1)
        try:
            response = session.get(url, headers=headers, params=parameters, timeout=TIMEOUT_S)
        except requests.RequestException as error:
            if attempt == MAX_ATTEMPTS:
                raise ApiError(f"ไม่เชื่อมต่อหลัง {MAX_ATTEMPTS} ครั้ง") from error
            log.warning("ครั้ง %s: %s", attempt, error)
            time.sleep(delay)
            continue

        if response.status_code == 429:
            # เกิน rate limit หากโบรกเกอร์ส่ง Retry-After
            # เชื่อถือได้กว่าคาดเดาเอง
            try:
                wait = float(response.headers.get("Retry-After", delay))
            except (TypeError, ValueError):
                # สเปกอนุญาตวันที่ HTTP แทนจำนวนวินาทีด้วย
                # หากไม่มีสาขานี้ float() จะทำการดาวน์โหลดทั้งหมดหยุด
                wait = delay
            log.warning("เกินอัตรา รอ %.1f s", wait)
            time.sleep(wait)
            continue

        if 500 <= response.status_code < 600:
            log.warning("เซิร์ฟเวอร์ผิดพลาด %s ลองใหม่", response.status_code)
            time.sleep(delay)
            continue

        if response.status_code != 200:
            raise ApiError(f"HTTP {response.status_code}: {response.text[:200]}")

        try:
            data = response.json()
        except ValueError as error:
            raise ApiError("คำตอบ JSON ไม่ถูกต้อง") from error
        if not isinstance(data, dict):
            raise ApiError("คำตอบ JSON ต้องเป็นออบเจ็กต์")
        if not isinstance(data.get("candles"), list) or not data["candles"]:
            raise ApiError("ไม่มีแท่งในคำตอบ ตรวจตราสารและช่วงวันที่")
        return data

    raise ApiError(f"ไม่มีคำตอบถูกต้องหลัง {MAX_ATTEMPTS} ครั้ง")

สถานะตรวจ: ทดสอบออฟไลน์ ไม่เชื่อมโบรกเกอร์ ฟังก์ชัน fetch_candles() ที่เผยแพร่รันกับ mock HTTP session ในหน่วยความจำ ไม่ใช่เซิร์ฟเวอร์จริง เก้าสถานการณ์ครอบคลุม 429 พร้อม Retry-After หน่วยวินาทีตามด้วย503แล้วสำเร็จในสถานการณ์เดียว รายการแท่งว่าง 404 วันที่ HTTP หมดการลอง connection exception, JSON เสีย ไม่ใช่ออบเจ็กต์ และประเภท candles ผิด การเรียก sleep() แทนด้วยบันทึกเวลารอ ไม่เปิด socket และไม่วัดเวลาเครือข่าย สภาพแวดล้อม: Python 3.12.10, requests 2.34.2, Windows 11, ตรวจเมื่อ 2026-10-08 รายงานสถานการณ์จริงดังนี้:

A: 429 วินาที -> 503 -> 200: calls=3; waits=[3.0, 2.0]; หนึ่งแท่ง
B: แท่งว่าง: calls=1; waits=[]; ข้อผิดพลาดตามคาด
C: HTTP 404: calls=1; waits=[]; ข้อผิดพลาดตามคาด
D: สำรองเมื่อเป็นวันที่ HTTP: calls=2; waits=[1.0]; หนึ่งแท่ง
E: ขีดจำกัดลอง: calls=4; waits=[0.0, 0.0, 0.0, 0.0]; ข้อผิดพลาดตามคาด
F: การส่งล้มเหลว: calls=4; waits=[1.0, 2.0, 4.0]; ข้อผิดพลาดตามคาด
G: JSON เสีย: calls=1; waits=[]; ข้อผิดพลาดตามคาด
H: JSON ไม่ใช่ออบเจ็กต์: calls=1; waits=[]; ข้อผิดพลาดตามคาด
I: ประเภท candles ผิด: calls=1; waits=[]; ข้อผิดพลาดตามคาด

ผลนี้ยืนยันและไม่ยืนยันอะไร ยืนยันพฤติกรรมที่คาดในเก้าสถานการณ์ A ตรวจว่า 429 เลือกรอสามวินาทีของเซิร์ฟเวอร์ ไม่ใช่หนึ่งวินาทีของโค้ด D ตรวจ fallback เมื่อ float() แปลงวันที่ HTTP ไม่ได้ F ตรวจว่ามีการส่ง timeout=10 ลองสี่ครั้งและจบความล้มเหลวจำลองด้วย exception ไม่ได้กำหนดเส้นตายเชื่อมจริง เพราะ timeout ของ requests ไม่ใช่เส้นตายทั้งงาน และเวลารอถูก mock B, C และ G–I ตรวจการปฏิเสธผลว่างหรือผิด ไม่ตรวจ API พร้อมใช้งาน ทุกฟิลด์ หรือพฤติกรรมเครือข่ายรายโบรกเกอร์

ไม่ได้ยืนยันตัวโบรกเกอร์ เส้น endpoint ชื่อพารามิเตอร์ รูปตอบ และการส่ง Retry-After ล้วนเป็นคุณสมบัติ API เฉพาะ [ฟีเจอร์ขึ้นกับโบรกเกอร์/บัญชี] ต้องดูเอกสารและทดสอบบัญชีฝึก Mock พิสูจน์โค้ด ไม่ใช่สมมติฐานต่อเซิร์ฟเวอร์คนอื่น ความต่างนี้คือคุณค่าของการทดสอบ

ต้องวัดความหน่วง ไม่ใช่อ้าง ช่วงในคู่มือ “50–200 ms สำหรับ API นี้ 100–500 ms สำหรับอีกอัน” ไร้ค่าเพราะไม่ระบุที่ตั้งลูกค้า ลิงก์ ช่วงวัน หรือวิธีวัด แทนคัดเลขให้แยกเวลาตอบ endpoint ข้อมูล เวลาส่งคำสั่งถึงรับยืนยัน เวลาถึงยืนยันเติม และอายุข้อมูลขณะตัดสินใจ ทั้งสี่คนละปริมาณ มีเพียงหนึ่งที่ทั่วไปเรียก latency วัดแต่ละอย่างในสายตน บันทึก log แล้วอ้างพร้อมวัน โบรกเกอร์ และจำนวนลอง ICMP ping ไม่ใช่ทั้งสี่ค่า

Polling หรือ streaming REST polling ทำให้อายุข้อมูลขึ้นกับช่วงคำขอ ทุกห้าวินาทีหมายถึงเลวร้ายสุดใช้ราคาห้าวินาทีก่อน ถี่ขึ้นกิน rate limit Stream ซึ่งเป็น WebSocket หรือ HTTP ตาม API กลับให้เซิร์ฟเวอร์ส่งเมื่อมีอัปเดต เหมาะเมื่อต้องตอบในแท่งหรือ polling กิน limit กลยุทธ์เข้าตอนเปิด H1 ถัดไปใช้ polling พอและดูแลง่ายกว่า Stream เพิ่มสามปัญหา อย่างแรก ช่องว่างหลังเชื่อมใหม่: หลุดสามสิบวินาทีไม่มีใครเล่นสามสิบวินาทีนั้นจาก socket ให้ ต้องขออดีตแยกมาเติมก่อนเรียกว่าครบ อย่างที่สอง ตรวจการเชื่อมต่อที่ตาย: socket หยุดส่งดูเหมือนตลาดนิ่ง จึงต้อง heartbeat หรือ keep-alive และตัวนับความเงียบของตนที่ถึงแล้วประกาศว่าหลุดและเชื่อมใหม่ อย่างที่สาม ลำดับและข้อมูลซ้ำ: หลังกลับมาอาจได้ข้อความที่ประมวลแล้ว เป็นปัญหาเดียวกับคำสั่ง แก้ด้วย event ID และตรวจว่าเคยบันทึกหรือไม่

ขีดจำกัดข้อมูลกับคำสั่งแยกกัน API จริงจังแยกราคาจากธุรกรรม และ limit ของงานเปลี่ยนบัญชีบางครั้งต่ำกว่าอ่านมาก โค้ดที่พยายามแก้ stop-loss สิบกว่าครั้งต่อวินาทีในตลาดแรงอาจถูกตัดทางธุรกรรม แล้วเหลือสถานะเปิดที่โปรแกรมเข้าถึงชั่วคราวไม่ได้ จึงควรจำกัดอัตราแก้เอง ไม่หวังให้โบรกเกอร์ยอม

8. จาก notebook สู่ service: โค้ดดำเนินการต่างจากสคริปต์อย่างไร

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

ระบบอัตโนมัติสามระดับ – ต่างที่ผู้ตัดสินใจสุดท้าย ไม่ใช่เทคโนโลยี:

ระดับ 1: แจ้งเตือน สคริปต์ตรวจแล้วส่งข้อความ ไม่เข้าบัญชีและไม่ต้อง token ส่งคำสั่ง คนตัดสินและดำเนินการ เป็นระดับเดียวที่โค้ดผิดเสียเพียงความรำคาญ

ระดับ 2: เตรียมพร้อมยืนยัน สคริปต์ประกอบตราสาร ทิศทาง ขนาด แล้วรอการยืนยันชัดจากผู้ควบคุมก่อนส่ง จับผิดคำนวณก่อนเป็นสถานะและคงมนุษย์ในวง สำหรับรายย่อยที่ไม่คิดดูแลซอฟต์แวร์ มักควรจบตรงนี้ ไม่ใช่ช่วงผ่าน แต่เป็นความเห็นบรรณาธิการ ไม่ใช่งานวิจัย

ระดับ 3: ทำงานไม่รอยืนยัน สคริปต์เปิดปิดเอง ต้องมีทุกอย่างในกรอบ ทดสอบบัญชีฝึก ตามด้วยบัญชีขนาดขั้นต่ำ และดูแลช่วงต้น จำนวนธุรกรรมก่อนก้าวต่อเป็นคำถามขนาดตัวอย่างและกำลังสถิติ ไม่ใช่เลขกลม อยู่ใน บทความการทดสอบ.

ชั้นดำเนินการพร้อม safety gate

หากแสดงโค้ดส่ง ต้องแสดงตัวหยุดด้วย โมดูลนี้รันได้ทั้งชุดโดยไม่มี network call สร้างคำสั่ง ตรวจขีดจำกัด และหยุดที่ประตู การส่งแยกเป็นอีกส่วนและตั้งใจไม่เป็นโค้ด

"""ชั้นดำเนินการ: ตรวจ โหมดทดสอบ และ gate ชัดก่อน live"""
import logging
import os
import sys
import uuid

ALLOWED_INSTRUMENTS = {"EUR_USD"}
MAX_UNITS = 1_000          # หน่วยสกุลเงินฐาน ไม่ใช่ล็อต รูปแบบขึ้นกับ API

# อ่านค่ายืนยัน live จากไฟล์นี้ไม่ได้ เพราะไม่มีอยู่
# โปรแกรมอ่านจากตัวแปรสภาพแวดล้อมและยอมรับ
# เลขบัญชีที่ผู้ควบคุมตั้งใจเทรด พิมพ์เองใน shell
# ก่อนเริ่ม ขอบเขตประตูนี้อยู่กรอบใต้ผลทดสอบ
CONFIRMATION_VARIABLE = "BROKER_LIVE_CONFIRMATION"

# หากไม่ตั้ง ไม่มี log.info เพราะระดับ root เริ่มต้น
# คือ WARNING และไม่มีที่เขียน ไฟล์ทิ้งร่องรอยหลังล้ม
# stream แสดงทันที ในโปรแกรมใหญ่การตั้งค่า log
# อยู่จุดเริ่ม ไม่ใช่โมดูล
logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(name)s %(message)s",
    handlers=[logging.FileHandler("execution.log", encoding="utf-8"),
              logging.StreamHandler(sys.stdout)],
)

log = logging.getLogger("execution")


class SafetyGateError(RuntimeError):
    """หยุดคำสั่งก่อนออก process"""


def new_order_id() -> str:
    """เรียกครั้งเดียวต่อเจตนาคำสั่งและเก็บก่อนส่ง

    ทุกการลองคำสั่งเดิมต้องกลับมาใช้ค่าเดิม
    มิฉะนั้นไม่มีสิ่งใช้รู้จักซ้ำ
    """
    return str(uuid.uuid4())


def build_order(instrument: str, units: int, order_id: str) -> dict:
    if instrument not in ALLOWED_INSTRUMENTS:
        raise SafetyGateError(f"ตราสารไม่อยู่รายการอนุญาต: {instrument}")
    # bool เป็น subclass ของ int ดังนั้น isinstance(True, int) เป็น true หากไม่
    # ปฏิเสธชัด boolean จะผ่านและเข้า payload
    if isinstance(units, bool) or not isinstance(units, int) or units == 0:
        raise SafetyGateError("ขนาดต้องเป็นจำนวนเต็มไม่เป็นศูนย์")
    if abs(units) > MAX_UNITS:
        raise SafetyGateError(
            f"ขนาด {abs(units)} เกินขีดจำกัด {MAX_UNITS}")
    return {
        "order": {
            "type": "MARKET",
            "instrument": instrument,
            "units": str(units),
            # ID มาจากภายนอกและไม่เปลี่ยนระหว่างลอง
            # หากสร้างตรงนี้ retry ทุกครั้งจะได้คนละค่า
            # ชื่อฟิลด์และเงื่อนไขมาจาก API เฉพาะ
            "clientExtensions": {"id": order_id},
        }
    }


def _operator_confirmation() -> str:
    """อ่านค่าจากนอกไฟล์ โค้ดไม่รู้และไม่เก็บค่านี้"""
    return os.environ.get(CONFIRMATION_VARIABLE, "").strip()


def submit_order(session, cfg, instrument: str, units: int, order_id: str,
                  test_mode: bool = True) -> dict | None:
    """เริ่มต้นไม่ส่งอะไร Host จริงต้องตัดสินใจสองชั้น"""
    order = build_order(instrument, units, order_id)

    if test_mode:
        log.info("โหมดทดสอบ [%s] สร้างคำสั่งแล้ว ไม่ส่ง: %s",
                 cfg.environment, order)
        return None

    if cfg.environment == "live" and _operator_confirmation() != cfg.account:
        raise SafetyGateError(
            "Host จริงต้องมีการยืนยันชัดจากผู้ควบคุม")

    # ผ่าน gate แล้ว โมดูลจบตรงนี้ ไม่มีการส่ง
    # เพราะรันตรวจอย่างตรงไปตรงมาไม่ได้ โครงสร้างอยู่ด้านล่าง
    raise NotImplementedError(
        "โมดูลนี้ยังไม่ทำส่วนส่ง ดูโครงสร้าง")

สร้าง order ID ครั้งเดียว ไม่ใช่ทุกครั้งที่ลอง เพื่อรู้จักซ้ำหลังหลุด ต้องคำนวณค่า เมื่อเกิดเจตนาส่งคำสั่งเก็บถาวรก่อนส่ง และใช้ซ้ำทุกการลองคำสั่งเดิม หาก uuid.uuid4() อยู่ในการสร้างคำสั่ง ทุก retry ส่งคนละค่า จึงแยกไม่ได้ว่าคำขอสองคือซ้ำครั้งแรก นั่นทำให้ build_order() รับ ID เป็นอาร์กิวเมนต์ ไม่สร้างเอง

สิ่งที่ ID ไม่แก้ ฟิลด์ clientExtensions ใน payload เป็นวิธีรายเดียว ไม่ใช่มาตรฐานหรือคำรับประกัน idempotency เอกสาร OANDA อธิบายว่าเป็นข้อมูลกำหนดเองเสริม และเตือนแยกว่า “ห้ามตั้ง แก้ หรือลบ tradeClientExtensions หากบัญชีเชื่อมกับ MT4” ^[14] (ตรวจเมื่อ 2026-08-22) ไม่รับรองว่าคำสั่งตลาด ID เดิมจะถูกปฏิเสธเป็นซ้ำ และคำสั่งตลาดเติมทันที ช่วงตรวจซ้ำสั้นมาก การรู้ซ้ำจึงอิงสองสิ่งฝั่งคุณ ไม่ใช่ฟิลด์ คือทะเบียนเจตนาถาวรที่เขียน ก่อน ส่ง และการเทียบรายการคำสั่งกับธุรกรรมจากโบรกเกอร์หลังล้มเหลว ตรวจชื่อฟิลด์และข้อจำกัดของ API คุณ รายอื่นอาจชื่ออื่นหรือไม่มี

ส่งคำสั่ง: โครงสร้าง

ด้านล่างไม่ใช่ฟังก์ชันให้คัดลอก แต่เป็นลำดับขั้นและชื่อการทำงานให้นำไปเขียนเอง ไม่ใช่วางแล้วรัน เป็นการเลือก ไม่ใช่ตกหล่น ผู้จัดทำไม่รันส่วนนี้และไม่ตั้งใจรัน เพราะส่งต้องมีบัญชี และทดสอบโค้ดธุรกรรมบนบัญชีผู้อื่นไม่ใช่ทดสอบแต่เป็นความเสี่ยงของเขา ฟังก์ชันเต็มจะเป็นสิ่งที่ไม่มีใครรันและสอนให้เชื่อโค้ดไม่ตรวจ เราเลือกเช่นเดียวกับโครง MQL ใน บทความ 11.5 และโครง Pine Script ใน บทความ 11.2.

โครงสร้าง - ส่งคำสั่งและจัดการคำตอบไม่มา
แนวทางชั้น HTTP ไม่ใช่โค้ดครบที่รันได้

ประกาศ: StanNieznany - คำตอบไม่มา จึงไม่รู้ว่า
             มีคำสั่งหรือไม่ เป็นประเภทแยก ไม่สืบทอด network error
             เพราะ network error ลองซ้ำได้ แต่สถานะนี้ห้ามลองซ้ำ

นำเข้า: คำสั่งที่สร้างและตรวจแล้ว order_id การตั้งค่า HTTP session
ผลออก: คำตอบโบรกเกอร์หรือ StanNieznany ห้ามสำเร็จเงียบ

1. ทะเบียนถาวร - ก่อนทุกอย่าง
   เขียนนอกหน่วยความจำ process: order_id เวลา UTC
   instrument, units, environment, status := INTENT
   บังคับเขียนดิสก์ก่อนต่อ
   หากขาดขั้นนี้ restart ทำข้อมูลเจตนาหาย
   และเริ่มใหม่จะไม่รู้เคยลองอะไร

2. LOG - ก่อนส่งเช่นกัน
   บันทึก: order_id + environment + เนื้อหาคำสั่ง
   ห้าม token เข้า log
   ซ่อนเลขบัญชีเหลือสี่ตัวท้าย
   คนอ่าน log ภายหลัง โปรแกรมอ่านทะเบียนขั้น 1

3. หนึ่งคำขอ ไม่มีลองซ้ำ
   POST ไปทางคำสั่งที่เอกสาร API ระบุ
   header สิทธิใช้ token จากการตั้งค่า ไม่ใช่โค้ด
   ต้อง timeout มิฉะนั้นค้างตลอดได้

4. คำตอบไม่มา (timeout หรือการส่งผิดพลาด)
   ห้ามลองซ้ำ POST ไม่ idempotent
   status ในทะเบียน := UNKNOWN
   ยก StanNieznany
   เทียบสถานะ: ขอคำสั่งและธุรกรรมช่วงไม่กี่นาทีล่าสุด
   ค้น order_id และเมื่อยืนยันว่ามีคำสั่งหรือไม่แล้ว
   จึงตัดสินใจใหม่
   (โครงนี้ไม่มีขั้นตอนนั้น ดูย่อหน้าข้างล่าง)

5. คำตอบมา
   บันทึก: รหัส HTTP + เนื้อหาคำตอบตัดสั้น
   หากรหัสนอก (200, 201) -> status := REJECTED -> ยกข้อผิดพลาด
   หากไม่ใช่ JSON       -> status := UNKNOWN  -> ยก StanNieznany
   นอกนั้น               -> status := ACCEPTED -> คืนคำตอบ

สิ่งที่โครงนี้ไม่มีและมีไม่ได้:
   ไม่มีฟังก์ชันพร้อมวางรันกับบัญชี
   และไม่มีชื่อฟิลด์ระดับป้องกัน เพราะต้องมาจาก
   เอกสาร API เฉพาะ ไม่ใช่ตัวอย่างคนอื่น

สิ่งที่โครงนี้ไม่ทำ ซึ่งสำคัญเท่ากับสิ่งที่อธิบาย ไม่เพิ่ม stop loss หรือ take profit ไม่ใช่ลืม แต่ API ใช้รูปแบบต่างกัน เช่น ฟิลด์แยก ระยะหรือราคาตายตัว และเวลามีผล ต้องใช้เอกสารโบรกเกอร์ ไม่ใช่ตัวอย่างผู้อื่น ผลจริงเกี่ยวกับขั้น 4 โดยตรง หลัง StanNieznany อาจมีสถานะไร้การป้องกันและไม่แน่ว่ามีจริง ในโค้ดที่ส่งได้ ระดับป้องกันต้องไปในคำขอเดียวกับการเข้า มิฉะนั้นเปิดช่วงที่สถานะไม่มี stop

ไม่ได้ขาดแค่ระดับป้องกัน จากกรอบ “Notebook วิจัย ≠ โปรแกรมดำเนินการ” ทั้งโมดูลที่รันได้กับโครงนี้ยังไม่มี monitoring, kill switch หรือขั้นตอน deploy สถานะคงหลัง restart อยู่ขั้น 1 ของโครงในฐานะข้อกำหนด ไม่ใช่ implementation หัวข้อ log สถานะและทดสอบพูดถึง ไม่ได้แสดงโค้ด สรุปเดิมว่านี่คือสื่อเรียนสถาปัตยกรรม ไม่ใช่โปรแกรมดำเนินการ

ทดสอบ safety gate ออฟไลน์แล้ว โดยไม่มีเครือข่าย โบรกเกอร์ หรือ secret ใช้ configuration จำลอง ต่อไปคือการทดสอบทั้งชุด ไม่ใช่แค่ผล มิฉะนั้นต้องเชื่อคำพูด ซึ่งตรงกับความเชื่อที่บทความเตือน

"""ทดสอบ gate ไม่มีเครือข่าย ตั้งค่าจำลอง ไม่มี secret ไม่มี POST"""
from dataclasses import dataclass


@dataclass(frozen=True)
class MockConfiguration:
    environment: str = "practice"
    host: str = "https://api-fxpractice.oanda.com"
    token: str = "dummy-token-for-offline-test"
    account: str = "000-000-0000000-000"


def test_gates() -> None:
    cfg = MockConfiguration()
    order_id = new_order_id()
    print("การตั้งค่า:", cfg.environment, cfg.host, "token_length=", len(cfg.token))

    # จงใจ session=None หากยังลอง POST
    # จะเกิด AttributeError แทนผ่านเงียบ
    result = submit_order(None, cfg, "EUR_USD", 100, order_id)
    assert result is None
    print("1. โหมดทดสอบ: ไม่ส่ง - OK")

    for description, instrument, units in [
        ("ตราสารไม่อนุญาต", "GBP_JPY", 100),
        ("ขนาดเกิน limit", "EUR_USD", 5000),
        ("ขนาดศูนย์", "EUR_USD", 0),
        ("ค่า boolean แทนตัวเลข", "EUR_USD", True),
    ]:
        try:
            build_order(instrument, units, order_id)
        except SafetyGateError as error:
            print(f"2. gate [{description}]:", error)
        else:
            raise AssertionError(f"gate ที่คาดไม่ทำงาน: {description}")

    cfg_live = MockConfiguration(environment="live", host="https://api-fxtrade.oanda.com")
    try:
        submit_order(None, cfg_live, "EUR_USD", 100, order_id, test_mode=False)
    except SafetyGateError as error:
        print("3. gate [โหมดจริงไม่ยืนยัน]:", error)
    else:
        raise AssertionError("โหมดจริงผ่านโดยไม่ยืนยัน")

    print("ผ่านทุก gate")


if __name__ == "__main__":
    test_gates()

ผลการรัน Python 3.12.10 ตามหัวข้อ 2 ไม่มีเครือข่ายหรือแพ็กเกจนอกมาตรฐาน เมื่อถอดการส่ง โมดูลไม่ต้องใช้ requests บรรทัดสองเป็น log เนื้อหาเดียวกันไปไฟล์ execution.log และ standard output พร้อมกัน เวลาและ order ID ต่างทุกครั้ง ส่วนที่เหลือทำซ้ำตรงตัวอักษร:

การตั้งค่า: practice https://api-fxpractice.oanda.com token_length= 28
1. โหมดทดสอบ: ไม่ส่ง - OK
2. gate [ตราสารไม่อนุญาต]: ตราสารไม่อยู่รายการอนุญาต: GBP_JPY
2. gate [ขนาดเกิน limit]: ขนาด 5000 เกินขีดจำกัด 1000
2. gate [ขนาดศูนย์]: ขนาดต้องเป็นจำนวนเต็มไม่เป็นศูนย์
2. gate [ค่า boolean แทนตัวเลข]: ขนาดต้องเป็นจำนวนเต็มไม่เป็นศูนย์
3. gate [โหมดจริงไม่ยืนยัน]: Host จริงต้องมีการยืนยันชัดจากผู้ควบคุม
ผ่านทุก gate

ผลนี้ยืนยันและไม่ยืนยันอะไร ห้ากรณีลบกระตุ้น gate ตามคาด ได้แก่ ตราสารไม่อนุญาต ขนาดเกิน ศูนย์ boolean และ live ไม่ยืนยัน Assert ตรวจโหมดทดสอบด้วย การตรวจเพิ่มเช็กขอบ ±1000 การเกิน และประเภทผิด อาร์กิวเมนต์แรกคือ Noneและยังไม่ทำส่วนส่ง จึงวางคำสั่งไม่ได้ ผลไม่ตรวจ API ความทนทาน log หรือการซ่อนทุกฟิลด์ ตัว token จำลองไม่พิมพ์ แสดงแค่ความยาว ในโปรเจกต์ต้องแยกทดสอบเขียนและกู้ log กฎปกปิด และดิสก์เสีย

ไม่ยืนยันพฤติกรรมกับ API จริงและทำไม่ได้ เพราะสาขาส่งไม่มีในโมดูล ถูกแทนด้วยโครงพร้อมลบจุดเดียวที่จะส่งได้ นี่คือความต่าง “ไม่ได้รัน” กับ “ไม่มีให้รัน” แบบแรกทิ้งสิ่งพร้อมวาง แบบหลังทิ้งโครงให้สร้างเองและอ่านเอกสารโบรกเกอร์ระหว่างทาง

การทดสอบต้องพบ gate ที่หายด้วย จึง assert ผลโหมดทดสอบและยก AssertionError หลังแต่ละกรณีลบหาก exception ไม่เกิด ข้อความสุดท้ายออกเมื่อทุกเช็กผ่าน ยังเป็นตัวอย่างเล็ก ไม่ครอบคลุมรูปตอบ ทุกประเภท หรือกู้สถานะ โปรเจกต์ใหญ่ให้ย้ายไป pytestเพิ่มกรณีบวกและรันเมื่อ validator เปลี่ยน

หน่วยไม่ใช่ล็อต คอมเมนต์ข้าง MAX_UNITS ไม่ใช่ตกแต่ง API บอกขนาดเป็นหน่วยสกุลเงินฐาน ล็อต หรือสัญญา พลาดแล้วไม่เกิด syntax error หรือ exception แต่ได้ความเสี่ยงมากกว่าตั้งใจสองสามลำดับขนาดทั้งที่โค้ดถูก ก่อนส่งตรวจเอกสารและยืนยันด้วยธุรกรรมขนาดต่ำสุดบัญชีฝึก มีข้อจำกัด validator สองข้อ ขนาดจาก pandas หรือ NumPy มีประเภท numpy.int64ไม่ใช่ subclass ของ int ในตัว Validator จะปฏิเสธว่าไม่ใช่จำนวนเต็มทั้งที่ค่าเป็นจำนวนเต็ม เป็นการล้มอย่างปลอดภัยแต่ชวนงง จึงแปลงค่าจาก DataFrame ด้วย int(...) ก่อนเข้า build_order() ข้อสอง: order_id ไม่ตรวจเลย และ type annotation ไม่บังคับ เนื่องจากการรู้ซ้ำอิง ID นี้ ต้องตรวจความยาวและรูปแบบที่ API อนุญาตแล้วบังคับเหมือนขนาด

Log สถานะ และการทดสอบ

ใช้ log แทน print(). โมดูล logging ให้ระดับความรุนแรง เวลา และเขียนไฟล์ แต่ไม่เปิดเอง หากไม่ตั้งค่า ระดับเริ่มต้นคือ WARNING และไม่มีปลายทาง จึงทิ้งการเรียก log.info(...) เงียบ ๆ โค้ดเหมือนบันทึกแต่ไม่มีอะไร นี่คือเหตุพบบ่อยที่ log ว่างหลังล้ม ตั้งครั้งเดียวที่จุดเริ่มโปรแกรม ในสคริปต์ที่รัน ไม่ใช่โมดูล import การเรียก logging.basicConfig(...) อยู่โมดูลข้างบนเพราะตัวมันคือทั้งโปรแกรม คอมเมนต์บอกชัดว่าโปรเจกต์ใหญ่ไม่ควรอยู่ตรงนี้ เพราะตั้งในโมดูลจะรันตอน import และยึด log ทั้ง process แล้วการเรียก logging.basicConfig(...) ที่จุดเริ่มจริงภายหลังไม่ทำอะไร เพราะฟังก์ชันนิ่งเมื่อ root logger มีปลายทางแล้ว เว้นเรียกด้วย force=Trueและไม่แจ้ง error เลย ^[4] ค่าคุณหาย บันทึกไปตามโมดูล import เป็นข้อเสียเงียบเดิมจากอีกฝั่ง บันทึกการตัดสินใจพร้อมเหตุผล เนื้อหาคำขอ และคำตอบ ตัดคำตอบเพื่อหน้า HTML error ไม่ท่วม log และเพิ่มขีดจำกัดตอนวิเคราะห์ ยกเว้น token ห้ามเขียน Log ไม่มีคำตอบจะบอกภายหลังไม่ได้ว่าผิดตรรกะ เครือข่าย หรือเซิร์ฟเวอร์

สถานะต้องอยู่หลัง restart Process จะถูกหยุดสักวันจากอัปเดต ไฟดับ หรือ Ctrl+Cของคุณ หากข้อมูลส่งอยู่แค่หน่วยความจำ เมื่อเริ่มใหม่จะไม่รู้เคยทำอะไร ขั้นต่ำคือเขียน ID ไปไฟล์หรือฐานข้อมูลก่อนส่ง และเทียบกับสถานะบัญชีจาก API ตอนเริ่ม นี่คือวิธีกันเข้าซ้ำหลังหลุด

การทดสอบไม่ใช้เครือข่าย ตรรกะสัญญาณและตรวจ limit ใช้ข้อมูลเตรียมทดสอบโดยไม่เชื่อมได้ เหมือน safety gate ข้างบน การทดสอบที่ต้องมี API ทำงานไม่ใช่ unit test และรันทุกครั้งที่เปลี่ยนไม่ได้ เริ่มจากเงื่อนไขเข้า คำนวณขนาด พฤติกรรมข้อมูลว่างและช่องว่างที่ตรวจออฟไลน์ได้

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

ดูเพิ่มเติม: การเทรดด้วยอัลกอริทึม – โครงสร้างระบบและที่ของอัตโนมัติในกระบวนการตัดสินใจ

9. Look-ahead และข้อมูลรั่วในโค้ด Python

Look-ahead ไม่ใช่ผิดวิธีวิทยา แต่ผิดโค้ดหนึ่งบรรทัด จึงอยู่บทความนี้แทนวิธีทดสอบ คือผลที่จัดให้เวลาหนึ่งใช้ข้อมูลที่ยังไม่มี ณ เวลานั้น

รูปแบบ pandas ธรรมดาคือคอลัมน์สัญญาณคูณผลตอบแทนแถวเดียว ผลในแถว t เกิดระหว่างปิดแท่งก่อนกับปิดแท่ง t ส่วนสัญญาณจากปิดแท่ง t รู้ได้เมื่อผลนั้นเกิดแล้ว การคูณจึงให้ผลการเคลื่อนไหวที่ยังไม่รู้ตอนตัดสินใจ

สมมติฐานตัวอย่าง: ข้อมูลสังเคราะห์รายชั่วโมงแปดค่า ดัชนี UTC ค่าประกอบ ไม่มีต้นทุน เพื่อแสดงกลไกเลื่อน ไม่ประเมินกฎ สภาพแวดล้อมตามหัวข้อ 2: Python 3.12.10, pandas 3.0.5

"""Look-ahead หนึ่งบรรทัด กฎเดิมแต่สองผล"""
import pandas as pd

index = pd.date_range("2026-06-01", periods=8, freq="1h", tz="UTC")
df = pd.DataFrame(
    {"close": [1.0800, 1.0810, 1.0825, 1.0815, 1.0830, 1.0845, 1.0840, 1.0855]},
    index=index,
)
df["sma"] = df["close"].rolling(3).mean()
df["return"] = df["close"].pct_change()

# กฎ: ถือซื้อเมื่อปิดเหนือเฉลี่ยสามแท่ง
df["position"] = (df["close"] > df["sma"]).astype(int)

# ผิด: สถานะแถว t คูณผลตอบแทนแถวเดียว
# ผล t เกิดระหว่างปิด t-1 กับปิด t การตัดสินใจจึง
# ใช้ราคาที่ยังไม่มีตอนเข้า
df["result_with_lookahead"] = df["position"] * df["return"]

# ถูก: สถานะตัดสินตอนปิด t ใช้กับผลของ t+1 เท่านั้น
df["result_without_lookahead"] = df["position"].shift(1) * df["return"]

print(df[["result_with_lookahead", "result_without_lookahead"]].sum().round(6))

ผลรัน:

result_with_lookahead       0.005082
result_without_lookahead    0.001384
dtype: float64

การตีความ กฎเดิม ข้อมูลเดิม ต่างเพียงการเรียก shift(1) หนึ่งครั้ง ผลรวม simple return รายช่วงตกจาก 0.005082 เป็น 0.001384 หรือต่ำกว่า 30 เปอร์เซ็นต์ของเดิม แปดค่าจึงเป็นภาพประกอบ ไม่ใช่การวัด แต่บนหลายปี ข้อผิดพลาดเดียวทำกลยุทธ์เฉลี่ยดูยอดเยี่ยม และที่ยอดเยี่ยมดูเป็นไปไม่ได้ ทั้งสองไม่มีหน่วยและไม่คิดสเปรดคอมมิชชัน หลังหัก รุ่นถูกจะต่ำลงอีก

ข้อระวังทางคำนวณ pct_change() ให้ simple return ซึ่งตามหัวข้อ 4 ต้องทบแบบคูณ ไม่ใช่บวก มีแต่ log return ที่รวมได้ การบวกที่นี่ตั้งใจประมาณ เพราะค่าระดับหนึ่งในพันทำให้ต่างจากทบถูกต่ำกว่า 0.00001 หรือน้อยกว่าความต่างที่ต้องการแสดงมากกว่าสองลำดับขนาด หากจะบอกผลบัญชี ไม่ใช่กลไกเลื่อน ให้คูณทบ (1 + r) หรือเปลี่ยนเป็น log แล้วรวม

ระวังเลื่อนสองครั้ง เลื่อนที่เดียว คือคอลัมน์สถานะหรือข้อมูลเข้าสัญญาณ ห้ามทั้งคู่ ถ้าคำนวณจากราคาเลื่อนแล้วยังเลื่อนสถานะ จะเข้าช้าสองช่วงและกดผลเงียบ ผิดทิศนี้อันตรายน้อยกว่า look-ahead แต่ผิดเท่ากัน

Look-ahead แบบอื่นใน Python – ทุกแบบถามเหมือนกันว่ารู้ค่านี้ตอนตัดสินใจหรือไม่?

• ใช้ high หรือ low แท่งปัจจุบันในเงื่อนไข ทั้งที่รู้หลังปิด
• ปรับสเกลหรือ normalize ทั้งชุดก่อนแยกฝึกและยืนยัน พารามิเตอร์จึงมีอนาคต
• อินดิเคเตอร์ใช้แท่งภายหลังเกลี่ยหรือระบุจุดกลับ ค่าย้อนหลังต่างจากที่เห็นสด
• ข้อมูลมหภาคฉบับแก้แทนค่าประกาศแรก
• เติมที่ราคาปิดแท่งที่เกิดสัญญาณ

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

ทดสอบหลายครั้ง ยิ่งลองหลายรูปแบบบนข้อมูลเดิม ยิ่งมีโอกาสดีที่สุดเป็นบังเอิญ ภายใต้ null model ชัด หาก 10,000 การทดสอบมีโอกาส false positive 0.05 แต่ละอัน จำนวนคาดที่เรียก “มีนัยสำคัญ” คือ 0.05 × 10,000 = 500 มาจากรวมความน่าจะเป็น ไม่ต้องอิสระ ความพึ่งกันเปลี่ยนการแจกแจงจำนวน ไม่ใช่ค่าเฉลี่ยภายใต้สมมติฐานนี้ ระดับขนาดแสดงว่าต้องรายงานจำนวนลองพร้อมผล

มีการแก้ตามจำนวนลอง คือ Deflated Sharpe Ratio ที่ Bailey และ López de Prado เสนอปี 2014 ^[12] ก่อนใช้ implementation สำเร็จ ตรวจสถานะและไลเซนส์ เพราะบางโครงการเปลี่ยนวิธีเผยแพร่ สูตรมีในต้นฉบับและเขียนเองได้

สิ่งที่ไม่ครอบคลุม Overfitting การเลือกตัวอย่าง walk-forward, survivorship bias และความทนต่อต้นทุนสูงเป็นวิธีทดสอบ อยู่ใน บทความ backtesting และ forward testing ที่นี่สนใจสิ่งที่ทำพังและตรวจได้ในโค้ดเท่านั้น

ตรวจโค้ดก่อนเชื่อผล:

1. ผลแถว t ใช้เฉพาะข้อมูลก่อนตัดสินใจหรือไม่?
2. เลื่อนครั้งเดียวที่สัญญาณหรือข้อมูล ไม่ทั้งคู่หรือไม่?
3. ระบุเวลาและราคาเติมชัดหรือไม่?
4. มีต้นทุน หรือจงใจละพร้อมอธิบายหรือไม่?
5. แบ่งฝึกและยืนยันตามเวลาหรือไม่?
6. กำหนดการแปลงจากส่วนก่อนเท่านั้นหรือไม่?
7. บันทึกจำนวนรูปแบบพร้อมผลหรือไม่?
8. ดัชนีระบุโซนและเพิ่มโดยไม่ซ้ำหรือไม่?

10. คุณต้องใช้โค้ดมากเพียงใดจริง

ไม่ต้องเป็นนักพัฒนา แต่ต้องรู้พอไม่ถูกโค้ดตนหรือสคริปต์จาก repository หลอก

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

ระดับ 1 และ 2 ไม่ให้ความได้เปรียบตลาด แต่ให้ตรวจว่าทางแก้ผู้อื่นมีเหตุผลหรือไม่ และหยุดซื้อระบบตรวจไม่ได้ มีค่าจริงแต่คนละชนิดกับที่ผู้ขายเสนอ ระดับ 4 ใช้เพื่อดูแลโปรแกรมดำเนินการ ไม่ใช่เทรดดีขึ้น ภาพรวมการใช้ Python การเงินอยู่ตำรา Hilpisch ^[11] โดยมีข้อระวังเหมือนทุกเล่มโค้ด ต้องตรวจเทียบไลบรารีปัจจุบันเพราะบาง interface เปลี่ยนแล้ว

ลำดับเรียนที่เหมาะ – ทุกขั้นต่อจากก่อนและจบด้วยสิ่งที่ทำงาน:

1. พื้นฐานภาษา – ตัวแปร list ฟังก์ชัน เงื่อนไข พออ่านโค้ดโดยไม่เดา
2. pandas บนข้อมูลตน – โหลดบันทึก คำนวณแยกวันและตราสาร หากชอบตำรา McKinney ผู้สร้าง pandas ครอบคลุมขั้นนี้ ^[10]
3. กราฟ – วาด equity และ drawdown จากผลก่อน
4. ตรวจคุณภาพ – ทำตัวอย่างหัวข้อ 4 บนไฟล์ตน: โซน ซ้ำ ขาด
5. เชื่อมอ่านอย่างเดียว – ดึง API บัญชีฝึกด้วย token ไม่มีสิทธิธุรกรรมถ้ารองรับ

ลำดับจงใจ ขั้นห้ามาหลังตรวจข้อมูลที่โหลดได้แล้ว มิฉะนั้นทำผิดอัตโนมัติ ไม่ใช่ทำงาน

เริ่มหนึ่งงาน โหลดข้อมูล คำนวณที่ตรวจมือสามแถวได้แล้วเทียบ หากตรงนับนิ้วมีฐาน หากไม่ตรงพบ bug แรก ซึ่งดีกว่าสคริปต์รันได้ทันทีแต่ไม่เข้าใจ

Python ไม่แก้กลยุทธ์แย่ อย่างดีที่สุดแสดงเร็วขึ้นว่าแย่