Deterministic กับ Non-Deterministic Output ในซอฟต์แวร์และระบบ AI

Read the English version

บทคัดย่อ

บทความนี้ชี้ให้เห็นว่าซอฟต์แวร์ตอบสนองได้สองแบบที่ต่างกัน และความแตกต่างนี้เองที่กำหนดรูปแบบการออกแบบระบบในปัจจุบัน ขั้นตอนแบบ deterministic จะให้เอาต์พุตเดิมจากอินพุตเดิมภายใต้เงื่อนไขเดิมเสมอ กฎทางธนาคาร ฐานข้อมูล และคอมไพเลอร์ล้วนสร้างขึ้นบนคำมั่นสัญญานี้ ขั้นตอนแบบ non-deterministic อาจให้เอาต์พุตต่างออกไปจากอินพุตที่ดูเหมือนเดิม การสุ่ม (sampling) หมายถึงการที่โมเดลเลือก token ถัดไปแต่ละตัว ซึ่งก็คือคำหรือชิ้นส่วนของคำ จากตัวเลือกที่น่าจะเป็นหลายตัว สถานะของระบบและโครงสร้างพื้นฐานสำหรับการอนุมาน (inference คือเซิร์ฟเวอร์และซอฟต์แวร์ที่รันโมเดลเพื่อสร้างคำตอบแต่ละครั้ง) ก็มีส่วนในผลลัพธ์ที่ได้กลับมาเช่นกัน โมเดลภาษาขนาดใหญ่เป็นเชิงความน่าจะเป็นโดยโครงสร้างของมันเอง เพราะสุ่มจากการแจกแจงความน่าจะเป็น การตั้ง temperature เท่ากับศูนย์ทำให้ความแปรผันแคบลงอย่างชัดเจน แต่ก็ยังไม่รับประกันว่าข้อความจะเหมือนกันทุกประการข้ามเวอร์ชันของโมเดล ฮาร์ดแวร์ หรือโครงสร้างพื้นฐานสำหรับการอนุมาน แนวทางที่ใช้ได้ผลจริงคือการห่อการตัดสินเชิงความน่าจะเป็นไว้ภายในการควบคุมแบบ deterministic โดยโมเดลทำหน้าที่ให้คะแนน และโค้ดธรรมดาจะเทียบคะแนนนั้นกับเกณฑ์ที่ใครก็อ่านและตรวจสอบได้ บทความนี้แสดงให้เห็นว่าเส้นแบ่งนั้นควรอยู่ตรงไหน ทีละขั้นตอนของระบบ

---

🔍 คลิกเพื่อขยาย คลิกที่ใดก็ได้เพื่อปิด

เอาต์พุตสองแบบ

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

เลขคณิตพื้นฐานเป็นตัวอย่างที่ชัดเจนที่สุด เมื่อใช้ตัวเลขสองจำนวนเดิมในลำดับเดิม ผลบวก $0.75 + 0.10$ ให้ค่า $0.85$ เสมอ ไม่ว่าจะรันครั้งเดียวหรือรันนับล้านครั้ง ค่านี้ก็ไม่เปลี่ยน

non-deterministic output คือสิ่งตรงข้าม อินพุตที่ดูเหมือนเดิมอาจให้ผลลัพธ์ต่างออกไปเมื่อรันในภายหลัง การสุ่ม สถานะของระบบ และพฤติกรรมของฮาร์ดแวร์ล้วนมีส่วนเกี่ยวข้อง

non-deterministic ไม่ได้แปลว่าสุ่มเดา ระบบสามารถแปรผันได้ในขณะที่ยังอยู่ในช่วงที่แคบและมีพฤติกรรมสมเหตุสมผล ลองขอให้โมเดลภาษาแต่งบทกวีเกี่ยวกับแมวหลายครั้ง บทกวีแต่ละบทจะต่างกันทั้งถ้อยคำและโครงสร้าง แต่ทุกบทยังคงสมเหตุสมผล

แต่ละแบบมีพื้นที่ที่เหมาะกับตัวเอง การคำนวณทางธนาคาร การทำงานของฐานข้อมูล กฎทางธุรกิจ การคอมไพล์ และตรรกะ if/else ธรรมดา อยู่ฝั่ง deterministic ส่วนการสร้างเนื้อหา การจำลอง การพยากรณ์ และการจัดอันดับ อยู่อีกฝั่งหนึ่ง

ทำไมโมเดลภาษาจึงให้ผลต่างกันโดยการออกแบบ

โมเดลภาษาขนาดใหญ่ไม่ได้ค้นหาคำตอบจากที่ใดที่หนึ่ง แต่เขียนออกมาทีละ token คำ token คือชิ้นส่วนข้อความขนาดเล็ก (หน่วยย่อยของข้อความ) ซึ่งมักเป็นเพียงส่วนหนึ่งของคำ ไม่ใช่ทั้งคำ

ในแต่ละขั้น โมเดลจะประเมินว่า token ถัดไปที่เป็นไปได้แต่ละตัวมีความน่าจะเป็นเท่าใด ชุดตัวเลขนี้คือการแจกแจงความน่าจะเป็นของ token ถัดไป จากนั้น decoding strategy (กลยุทธ์การเลือกคำ) จะเลือก token หนึ่งตัวจากการแจกแจงนั้น token ที่ถูกเลือกจะเข้าไปอยู่ในบริบท แล้วโมเดลก็เริ่มขั้นถัดไป

มีค่าปรับตั้งหนึ่งตัวที่ควบคุมว่าการเลือกนั้นกล้าเสี่ยงมากแค่ไหน temperature จะขยายหรือลดระยะที่โมเดลเบี่ยงออกจาก token ที่น่าจะเป็นที่สุด temperature สูงทำให้เกิดความแปรผันมากขึ้น ส่วน temperature ต่ำทำให้การเลือกกระจุกอยู่ที่ตัวเลือกอันดับต้น ๆ

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

Temperature เท่ากับศูนย์ไม่ใช่การรับประกัน

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

ในโมเดลรุ่นปัจจุบันบางรุ่น ค่านี้ไม่มีให้ตั้งแล้ว โมเดล Claude รุ่นใหม่ปฏิเสธค่า temperature ที่ไม่ใช่ 1.0 และโมเดลเชิงให้เหตุผลหลายตัวก็ไม่รับค่าที่ไม่ใช่ค่าเริ่มต้นเช่นกัน ควรตรวจเอกสาร API ของโมเดลที่คุณเรียกใช้ก่อนจะสรุปว่าตั้งค่านี้ได้ ดูรายการอ้างอิงที่ 2

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

token ที่เปลี่ยนไปเพียงตัวเดียวก็เพียงพอที่จะเปลี่ยนส่วนที่เหลือทั้งหมด token ที่เปลี่ยนไปนั้นจะกลายเป็นส่วนหนึ่งของบริบท ทำให้ข้อความที่ตามมาเดินไปคนละเส้นทาง การรันที่เคยตรงกับเมื่อวานอาจแยกออกจากกันตั้งแต่ประโยคแรก

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

การตัดสินเชิงความน่าจะเป็นภายในรูปแบบเอาต์พุตที่ตายตัว

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

กฎในรูปแบบ IF word = "angry" THEN emotion = anger จะล้มเหลวตั้งแต่คำร้องเรียนแบบสุภาพข้อความแรก โมเดลสามารถชั่งน้ำหนักโทนเสียง ถ้อยคำ บริบท และความสัมพันธ์ระหว่างวลีแทนได้ การตัดสินแบบนี้เป็นเชิงความน่าจะเป็นโดยธรรมชาติ เพราะหลักฐานเองก็ไม่แน่นอน

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

{
  "emotion": "anger",
  "probability": 0.87,
  "requires_review": true
}

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

แยกชั้นการตัดสินออกจากชั้นการทำงาน

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

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

ชั้นการทำงานรับตัวเลขที่ชั้นการตัดสินผลิตออกมาแล้วนำไปปฏิบัติ มันเทียบตัวเลขนั้นกับเกณฑ์และตอบแบบเดียวกันทุกครั้ง

IF probability >= 0.80
THEN send_to_human_review
ELSE continue_automatically

เมื่อมีค่าความน่าจะเป็นแล้ว กฎนั้นก็เป็น deterministic ค่าความน่าจะเป็น 0.87 ผ่านเกณฑ์ 0.80 ได้ในทุกการรันและทุกเครื่อง ไม่มีส่วนใดของกฎที่ขึ้นกับว่าโมเดลเคยส่งอะไรกลับมาในครั้งก่อน

การแบ่งนี้ทำให้คำถามสองข้อแยกจากกัน ข้อมูลนี้น่าจะหมายความว่าอย่างไร และซอฟต์แวร์ควรทำอะไรกับการตัดสินนั้น

คำถามแรกคือจุดที่โมเดลมีคุณค่า ส่วนคำถามที่สองเป็นของโค้ดที่คุณอ่านได้ ทดสอบได้ และเล่นซ้ำได้

ตัดสินว่าส่วนไหนต้องใช้แบบไหน

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

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

มาตรฐานนี้คือสิ่งที่วงการวิทยาศาสตร์เชิงคำนวณยึดถือสำหรับงานที่ทำซ้ำได้ ดูรายการอ้างอิงที่ 5

ความกำกวมคืออีกกรณีหนึ่ง การตีความภาษาธรรมชาติ การจัดประเภทเอกสาร การสร้างเนื้อหา และการตัดสินความหมาย ล้วนต่อต้านกฎที่ตายตัว โมเดลมีคุณค่าตรงจุดที่รายการกฎจะต้องยาวไม่มีที่สิ้นสุดพอดี

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

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

เทียบ Deterministic กับ Non-Deterministic

สิ่งที่มักพลาดตรงเส้นแบ่ง

• ใช้ temperature เท่ากับศูนย์เหมือนเป็นสัญญา

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

  วิธีแก้: ตรึงเวอร์ชันโมเดล เก็บล็อกเอาต์พุตดิบ และเทียบผลแต่ละครั้งแทนการเดาว่าเหมือนกัน

• เข้าใจผิดว่ารูปแบบตายตัวคือคำตอบตายตัว

  สคีมารับประกันแค่ว่าฟิลด์มีอยู่จริง แต่ค่าที่อยู่ข้างในยังมาจากโมเดลเชิงความน่าจะเป็น

  วิธีแก้: ตรวจสอบค่าที่ได้ ไม่ใช่แค่รูปแบบ และกำหนดช่วงที่แต่ละฟิลด์รับได้

• ทดสอบขั้นตอนเชิงความน่าจะเป็นเพียงครั้งเดียว

  การรันผ่านครั้งเดียวไม่ได้พิสูจน์การรันครั้งถัดไป ความผิดพลาดที่โผล่หนึ่งครั้งในยี่สิบครั้งมีโอกาสสูงมากที่จะไปถึงระบบจริง

  วิธีแก้: รันอินพุตเดิมหลายครั้งแล้วรายงานการกระจายของผล ไม่ใช่ผลเพียงค่าเดียว

• ปล่อยขั้นตอนที่มีผลร้ายแรงไว้ในโมเดล

  การจ่ายเงิน สิทธิ์การเข้าถึง และความปลอดภัยของผู้ป่วยต้องการคำตอบที่เล่นซ้ำได้ การให้โมเดลตัดสินเรื่องเหล่านี้คือการซ่อนกฎไว้ใน prompt

  วิธีแก้: ให้โมเดลผลิตคะแนน แล้วให้โค้ดธรรมดาเทียบคะแนนนั้นกับเกณฑ์ที่คุณอ่านได้

• อ่านผลจากแคชว่าเป็นโมเดลที่ให้ผลซ้ำได้

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

  วิธีแก้: ปิดแคชขณะทดสอบความสามารถในการทำซ้ำ และบันทึกว่าชั้นใดเป็นผู้ตอบการเรียกแต่ละครั้ง

สามการรันเทียบกับเกณฑ์เดียว

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

1. ขั้นที่ 1 กำหนดกฎ

   \[ \text{escalate if } s \ge 0.80 \]

   ให้ s คือค่าความน่าจะเป็นที่โมเดลส่งกลับมาในฟิลด์ที่กำหนดไว้ก่อนหน้านี้ กฎจะส่งต่อให้คนตรวจเมื่อ s ไม่น้อยกว่า 0.80

2. ขั้นที่ 2 อ่านคะแนนทั้งสาม

   \[ s_1 = 0.92, \quad s_2 = 0.79, \quad s_3 = 0.84 \]

   การรันทั้งสามครั้งให้ค่า 0.92, 0.79 และ 0.84 จากอินพุตเดียวกัน

3. ขั้นที่ 3 ลบเกณฑ์ออกจากแต่ละคะแนน

   \[ 0.92 - 0.80 = 0.12, \quad 0.79 - 0.80 = -0.01, \quad 0.84 - 0.80 = 0.04 \]

   ผลต่างสองค่าเป็นบวก และหนึ่งค่าเป็นลบ

4. ขั้นที่ 4 อ่านเครื่องหมาย

   \[ 0.12 \ge 0 \Rightarrow \text{escalate}, \quad -0.01 < 0 \Rightarrow \text{continue}, \quad 0.04 \ge 0 \Rightarrow \text{escalate} \]

   การรันที่หนึ่งและที่สามถูกส่งต่อให้คนตรวจ การรันที่สองขาดไป 0.01 จึงทำงานอัตโนมัติต่อไป

5. ขั้นที่ 5 เพิ่มช่วงทบทวน

   \[ 0.75 \le s \le 0.85 \Rightarrow \text{send to review} \]

   คะแนนที่ก้ำกึ่งไม่ควรตัดสินด้วยตัวเอง ค่าตั้งแต่ 0.75 ถึง 0.85 ให้ส่งต่อให้คนตรวจ

6. ขั้นที่ 6 วัดความกว้างของช่วง

   \[ 0.85 - 0.75 = 0.10 \]

   ช่วงนี้กว้าง 0.10 และคร่อมเกณฑ์อยู่

7. ขั้นที่ 7 วางคะแนนทั้งสามลงในช่วง

   \[ 0.79 \in [0.75,\, 0.85], \quad 0.84 \in [0.75,\, 0.85], \quad 0.92 \notin [0.75,\, 0.85] \]

   สองในสามการรันตกอยู่ในช่วงทบทวน จึงต้องมีคนยืนยันผล มีเพียง 0.92 ที่อยู่นอกช่วงและถูกส่งต่อโดยกฎเพียงอย่างเดียว

ผลลัพธ์: กฎไม่เคยเปลี่ยน มีแต่คะแนนที่เปลี่ยน ช่วงทบทวนจึงเปลี่ยนความแปรผันนั้นให้เป็นการตัดสินใจที่ทีมอธิบายได้

ตัวเลขเป็นค่าสมมติ แต่รูปแบบของคำตอบไม่ใช่ค่าสมมติ คะแนนเชิงความน่าจะเป็นขยับได้ ขณะที่กฎที่อ่านคะแนนยังคงเดิม

⤢ คลิกเพื่อขยาย

อภิธานศัพท์

deterministic output (เอาต์พุตที่กำหนดผลได้แน่นอน)

อินพุตเดิมภายใต้เงื่อนไขเดิมให้เอาต์พุตเดิมทุกครั้งที่รัน

non-deterministic output (เอาต์พุตที่ไม่ได้กำหนดผลตายตัว)

อินพุตที่ดูเหมือนเดิมอาจให้เอาต์พุตต่างออกไป เพราะมีการสุ่มหรือสถานะของระบบเข้ามาเกี่ยวข้อง

token (หน่วยข้อความย่อย)

ชิ้นส่วนข้อความขนาดเล็กที่โมเดลภาษาอ่านและเขียน มักเป็นส่วนหนึ่งของคำ

inference (การอนุมานของโมเดล)

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

temperature (ค่าความกระจายของการสุ่ม)

ค่าการสุ่มที่ทำให้โมเดลเบี่ยงออกจากโทเคนที่น่าจะเป็นที่สุดมากขึ้นหรือน้อยลง

greedy decoding (การเลือกโทเคนที่น่าจะเป็นที่สุด)

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

decision engine (กลไกตัดสินใจ)

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

reproducibility (การทำซ้ำได้)

ความสามารถในการได้ผลลัพธ์เดิมอีกครั้งจากอินพุต โค้ด และเงื่อนไขที่บันทึกไว้ชุดเดิม

เอกสารอ้างอิง

1. OpenAI. API reference: create chat completion, the temperature sampling parameter, with the note on the same page that determinism is not guaranteed. https://developers.openai.com/api/reference/resources/chat/subresources/completions/methods/create
2. Anthropic. Messages API reference: the temperature parameter, deprecated for models released after Claude Opus 4.6, where only a value of 1.0 is accepted. https://platform.claude.com/docs/en/api/messages
3. OpenAI Cookbook. How to make your completions outputs consistent with the new seed parameter: determinism is best effort and is tracked by the system fingerprint. https://developers.openai.com/cookbook/examples/reproducible_outputs_with_the_seed_parameter
4. He H. Defeating nondeterminism in LLM inference. Thinking Machines Lab, 10 September 2025: batch invariance and floating point reduction order. https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/
5. Peng RD. Reproducible research in computational science. Science 2011;334:1226 to 1227. https://doi.org/10.1126/science.1213847

ประเด็นสำคัญ

• ถามกับทุกขั้นตอนว่า ขั้นนี้ต้องให้ผลเดิมเป๊ะ หรือต้องรับมือกับความกำกวม
• โมเดลภาษาให้ผลต่างกันโดยการออกแบบ เพราะมันสุ่มโทเคนถัดไปจากการแจกแจงความน่าจะเป็น
• temperature เท่ากับศูนย์ทำให้ความแปรผันแคบลง แต่ไม่ได้สัญญาว่าจะได้ข้อความเดิมทุกครั้งที่รัน
• รูปแบบเอาต์พุตที่ตายตัวบังคับได้แค่รูปร่างของคำตอบ ไม่ได้บังคับการตัดสินที่อยู่ข้างใน
• เก็บการตัดสินไว้ในโมเดลและเก็บการควบคุมไว้ในโค้ด เพื่อให้เกณฑ์และร่องรอยการตรวจสอบยังเป็น deterministic

อ่านต่อในวิกิ: [[harness-is-not-a-tool-th]] [[uniqcret-research-suite-th]] [[git-workflow-decision-guide-th]]