เมื่อคำขอสำเร็จ แต่ประสบการณ์ยังถือว่าล้มเหลว
ลองนึกภาพว่าคุณคุยกับตัวละครเดิมมาหลายสัปดาห์ น้ำเสียงของเขาคุ้นเคย ภาษาสม่ำเสมอ และคำตอบดูเฉียบคมมีชีวิตชีวา
แล้วจู่ ๆ ทั้งที่ไม่ได้เปลี่ยนตัวละครหรือโมเดล บางอย่างกลับรู้สึกผิดปกติ
คำตอบถัดไปใช้เวลาสิบวินาทีกว่าจะเริ่ม ฟีเจอร์ที่อาศัย structured output หยุดทำงาน ตัวละครเริ่มพูดวกวน แทรกข้อความจากภาษาอื่น หรือใช้สำนวนที่เหมือนมาจากโมเดลที่อ่อนกว่ามาก
จากมุมมองของเซิร์ฟเวอร์ ไม่มีอะไรล้มเหลว API ส่งกลับ 200 OK มี token กลับมา และคำขอก็ถูกคิดค่าใช้จ่าย
แต่จากมุมมองของผู้ใช้ โมเดลเพิ่งแย่ลงอย่างชัดเจน
ช่องว่างนี้คือเหตุผลที่เราสร้างระบบ provider canary probe และการกักกันเส้นทางให้ Reverie
ชื่อโมเดลเดียว แต่มีสภาพแวดล้อม inference หลายแบบ
OpenRouter คือ model gateway หลักของเรา จุดแข็งอย่างหนึ่งคือโมเดลเดียวสามารถให้บริการโดยผู้ให้บริการ inference อิสระหลายราย หากรายหนึ่งไม่พร้อม อีกรายก็รับคำขอแทนได้ เราจึงมี capacity มากขึ้น ราคาที่แข่งขันได้ และความทนทานสูงกว่าการพึ่ง endpoint เพียงแห่งเดียว
แต่ก็ทำให้เกิดตัวแปรที่ผู้ใช้มองไม่เห็น
ชื่อโมเดลอาจเหมือนเดิม แต่โครงสร้างพื้นฐานที่รันโมเดลอาจเปลี่ยนไปในแต่ละคำขอ ผู้ให้บริการแต่ละรายอาจใช้ inference engine, hardware, ระดับ quantization, parser, chat template, queue หรือชั้น policy เพิ่มเติมที่ต่างกัน
เอกสาร provider routing ของ OpenRouter อธิบายว่า routing เริ่มต้นพิจารณาความพร้อมใช้งานล่าสุดและราคา พร้อมเก็บผู้ให้บริการอื่นไว้เป็น fallback สัญญาณเหล่านี้สำคัญ แต่ endpoint อาจออนไลน์ ราคาถูก และยังให้ผลลัพธ์ที่ยอมรับไม่ได้สำหรับผลิตภัณฑ์บางประเภท
OpenRouter ยังพูดต่อสาธารณะถึง ความแตกต่างที่วัดได้ระหว่างผู้ให้บริการที่รันโมเดลเดียวกัน ในทางทฤษฎี weights เดียวกันที่ precision เดียวกันควรทำงานคล้ายกัน แต่การรันโมเดลขนาดใหญ่ใน production มีความซับซ้อน และความแตกต่างก็เกิดขึ้นได้
“โมเดลเสื่อมคุณภาพ” หมายถึงอะไรสำหรับเรา
“โมเดลเสื่อมคุณภาพ” ไม่ใช่คำวินิจฉัยมาตรฐานที่มีสาเหตุเดียว และไม่ได้หมายความโดยอัตโนมัติว่าผู้ให้บริการจงใจสลับไปใช้โมเดลที่เล็กกว่า
เราใช้คำนี้ในเชิงปฏิบัติการว่า endpoint สำหรับ inference เสื่อมคุณภาพเมื่อไม่สามารถรักษาพฤติกรรม ความสามารถ หรือประสิทธิภาพการโต้ตอบที่คาดหวังจากโมเดลที่ขอไว้บน prompt ที่เป็นตัวแทน แม้คำขอจะสำเร็จในทางเทคนิคก็ตาม
รูปแบบที่ชัดเจนที่สุดสำหรับ Reverie ได้แก่:
- Latency degradation: เชื่อมต่อสำเร็จ แต่ first token มาช้าจนทำลายความรู้สึกของบทสนทนาแบบสด
- Capability degradation: endpoint ที่ควรรองรับ structured output ส่งข้อความผิดรูปแบบหรือไม่สามารถทำตาม schema ได้
- Behavioral degradation: คำตอบเสียหาย ไม่ต่อเนื่อง ซ้ำผิดปกติ หรือเปลี่ยนไปเป็นภาษาอื่นอย่างชัดเจน
- Policy mismatch: upstream host เพิ่มชั้น filter ของตนเอง ทำให้ฉากที่ Reverie รองรับกลายเป็นการปฏิเสธ คำตอบว่าง หรือข้อความที่ถูกตัด
สาเหตุมีได้หลายอย่าง Quantization ที่ precision ต่ำอาจกระทบ prompt ที่ยาก ดังที่ทั้ง เอกสาร OpenRouter และ งานวิจัย quantization ระบุไว้ แต่ quantization ไม่ใช่คำอธิบายสำหรับทุกกรณี bug ใน inference engine หรือ tool parser, ข้อผิดพลาดของ tokenizer หรือ chat template, queue ที่รับภาระเกิน และ middleware ของผู้ให้บริการก็สำคัญได้ไม่แพ้กัน OpenRouter พบว่าในการเรียกใช้เครื่องมือ ตัว parser มักสร้างความแตกต่างระหว่างผู้ให้บริการ มากกว่า precision เพียงอย่างเดียว
คำถามสำคัญจึงไม่ใช่ “สาเหตุไหนฟังดูน่าสงสัยที่สุด” แต่คือ “เราสามารถแยก endpoint แล้วทำให้ความผิดพลาดเกิดซ้ำได้หรือไม่”
สองกรณีที่ทำให้ปัญหานี้ชัดเจน
นี่ไม่ใช่แค่ความกังวลเชิงทฤษฎีสำหรับเรา
ในการเปรียบเทียบที่ pin คำขอไว้กับผู้ให้บริการแต่ละราย ผู้ให้บริการรายหนึ่งทำให้ต้นคำตอบเสียหาย 19 จาก 20 ครั้ง ด้วยการแทรกเครื่องหมายวรรคตอนหรือชิ้นส่วน token ที่ไม่เกี่ยวข้อง ขณะที่ host อีก 14 แห่งซึ่งรันโมเดลเดียวกันพบปัญหา 0 ครั้งจาก 49 คำตอบ ใน roleplay ตัวอักษรแรกมักเป็นเครื่องหมายเน้นข้อความของ Markdown ดังนั้น byte แปลกปลอมเพียงหนึ่งตัวจึงทำให้รูปแบบของคำตอบทั้งหมดเสียได้
ในการทดสอบอีกชุด endpoint หนึ่งผสมภาษาโปรตุเกสกับสเปนอย่างรุนแรง 3 จาก 3 ครั้ง prompt เดียวกันยังคงเป็นภาษาโปรตุเกสบน host ทางการของโมเดลและ host อื่นใน precision class เดียวกัน คำอธิบายว่า “โมเดลไม่สม่ำเสมออยู่แล้ว” จึงไม่น่าเชื่อถือ เพราะข้อบกพร่องเคลื่อนตาม endpoint
ความล้มเหลวเหล่านี้ตรวจจับยากเพราะไม่จำเป็นต้องโยน exception ระบบติดตาม uptime แบบเดิมเห็น API ที่ปกติ แต่ผู้ใช้เห็นตัวละครที่จู่ ๆ ก็พูดไม่รู้เรื่อง
คำตอบของเรา: ทดสอบทุกเส้นทาง ไม่ใช่แค่โมเดล
ทุกสามสิบนาที canary ของเราจะค้นหาผู้ให้บริการที่กำลังรันโมเดลแชตเริ่มต้นของ Reverie จากนั้นส่งคำขอสังเคราะห์ขนาดเล็กไปยังแต่ละราย โดย pin ไว้กับผู้ให้บริการรายนั้นเพียงรายเดียวและปิด fallback
การ pin สำคัญมาก หาก probe fallback ได้ ผู้ให้บริการรายที่สองซึ่งปกติอาจซ่อนความล้มเหลวของรายแรก เราต้องรู้แน่ชัดว่าสภาพแวดล้อมใดสร้างผลลัพธ์นั้น
ระบบทดสอบสัญญาแคบ ๆ สี่ประเภทที่ตัดสินได้ด้วยโค้ด
1. เวลาจนถึง first token
สำหรับบทสนทนาแบบ streaming ค่า throughput เป็นเพียงครึ่งหนึ่งของประสบการณ์ first token เป็นตัวกำหนดว่าผู้ใช้ต้องมองหน้าจอโหลดนานเท่าไร
เราวัดจาก stream โดยตรง ผู้ให้บริการที่ไม่ส่งข้อความภายในสิบวินาทีจะไม่ผ่าน latency probe เกณฑ์นี้ตั้งไว้อย่างเผื่อเหลือเผื่อขาด และความช้าเพียงรอบเดียวไม่พอที่จะนำ host ออก เพราะ queue อาจหนาแน่นชั่วคราวได้
2. การกรองและการปฏิเสธแบบเงียบ
เราส่งคำขอให้เขียน roleplay ต่อจากข้อความคงที่ซึ่งเป็นตัวแทนของ traffic ที่ Reverie รองรับ Probe ตรวจ finish reason, รูปแบบการปฏิเสธที่มีความมั่นใจสูง และ output ว่าง
เรายังทดสอบกับ host ที่ทราบว่าใช้ filter เพื่อเป็น positive control หาก control ผ่านอย่างผิดคาด เราจะไม่ประกาศว่าผู้ให้บริการอื่นปกติทั้งหมด แต่จะระบุว่าตัว probe เองอ่อนเกินไป การทดสอบที่ตรวจความผิดพลาดซึ่งทราบอยู่แล้วไม่ได้ ย่อมไม่ใช่หลักฐานว่าสุขภาพดี
3. Structured output
เราขอ object ขนาดเล็กที่มี schema คงที่และตรวจสอบผลลัพธ์ Transport error กับ output ผิดรูปแบบถูกจัดการต่างกัน: การเชื่อมต่อที่ล้มเหลวแปลว่าเข้าถึงผู้ให้บริการไม่ได้ ส่วน generation ที่จบสำเร็จแต่ไม่ตรง schema เป็นหลักฐานว่าความสามารถถดถอย
“Endpoint ประกาศว่ารองรับ parameter” กับ “endpoint ปฏิบัติตาม parameter ได้อย่างเชื่อถือได้” ไม่ใช่คำสัญญาเดียวกัน
4. ความสมบูรณ์ของภาษา
Reverie รองรับภาษาอินเทอร์เฟซ 17 ภาษา ดังนั้น smoke test ภาษาอังกฤษอย่างเดียวจะพลาดปัญหาที่ผู้ใช้ของเราพบจริง
Canary จะหมุนเวียนทดสอบภาษาที่รองรับด้วย prompt roleplay สังเคราะห์ ตัวตรวจภาษาที่ทำงานในเครื่องแบบ deterministic จะมองหาการเปลี่ยนภาษาของทั้งคำตอบอย่างชัดเจน การผสมภาษาอย่างต่อเนื่อง และ encoding ที่เสียหายอย่างเห็นได้ชัด ระบบไม่ใช้บทสนทนาจริง และไม่ขอให้โมเดลอื่นให้คะแนนแบบ subjective
Output ที่กำกวมหรือสั้นเกินไปจะถือว่าสรุปไม่ได้ ไม่ใช่ล้มเหลว เมื่อพบความผิดปกติทางภาษา canary จะลองยืนยันเพิ่มทันทีสองครั้งและใช้เสียงข้างมาก ภาษานั้นจะถูกทดสอบซ้ำในรอบถัดไป เพื่อไม่ให้ผู้ให้บริการหลบกฎรอบต่อเนื่องเพียงเพราะการหมุนเวียนเปลี่ยนภาษาไปแล้ว
เราออกแบบให้ระบบสงสัยข้อสรุปของตัวเอง
การตัด capacity ของ inference โดยอัตโนมัติมีประโยชน์ แต่ false positive อาจก่อ outage ที่ใหญ่กว่าข้อบกพร่องเดิม Canary จึงมีเบรกหลายชั้น:
- Transport error ไม่นับเป็นความล้มเหลวด้านคุณภาพ Timeout, rate limit และ response 5xx จะหยุดคะแนนไว้ ไม่เพิ่มจำนวนครั้งต่อเนื่องเพื่อ suspension
- รอบที่แย่เพียงรอบเดียวไม่พอ ผู้ให้บริการต้องล้มเหลวสองรอบติดต่อกัน ซึ่งแต่ละรอบทำงานทุกครึ่งชั่วโมง
- แยก observation ออกจาก enforcement เราสามารถรันระบบใน observe mode บันทึกว่า host ใดควรถูกพัก แจ้งผู้ดูแล และวัด false positive ก่อนเปิดการทำงานอัตโนมัติ
- Capacity มีขีดต่ำสุด Canary จะไม่พักผู้ให้บริการหากทำให้เหลือ production host น้อยกว่าสองแห่ง แต่จะแจ้งผู้ดูแลแทน
- การฟื้นตัวก็ถูกทดสอบ ผู้ให้บริการที่ถูกพักยังคงได้รับ probe และจะกลับมาได้ก่อนกำหนดเมื่อผ่านครบสองรอบติดต่อกัน
- ปัญหาซ้ำจะเพิ่มระยะเวลาอย่างค่อยเป็นค่อยไป ครั้งแรกพักหนึ่งวัน ครั้งถัดไปสามวัน และหลังจากนั้นเจ็ดวัน เมื่อไม่มี suspension ใหม่เป็นเวลา 14 วัน ประวัติจะจางลงและเริ่มขั้นบันไดใหม่
เป้าหมายไม่ใช่การลงโทษผู้ให้บริการ แต่คือการย้าย traffic ผู้ใช้ออกจากเส้นทางที่พิสูจน์แล้วว่าไม่ปกติ และเปิดทางกลับอย่างชัดเจนเมื่อแก้ปัญหาแล้ว
การป้องกันสามชั้น
การตัดสินใจ routing ขั้นสุดท้ายรวมข้อยกเว้นสามประเภท:
- ข้อยกเว้นในโค้ดที่ผ่านการทบทวน สำหรับข้อบกพร่องหรือ policy mismatch ที่เราวัดแล้วและไม่ต้องการนำกลับมาโดยไม่ตั้งใจ
- ข้อยกเว้นเหตุการณ์แบบ runtime ที่ผู้ดูแลเพิ่มได้ทันทีโดยไม่ต้องรอ deployment
- Canary suspension แบบจำกัดเวลา สำหรับผู้ให้บริการที่ข้ามเกณฑ์ความล้มเหลวอัตโนมัติ
เมื่อ Reverie สร้างคำขอ รายการเหล่านี้จะรวมเข้าในค่า provider.ignore ของ OpenRouter ผู้ใช้ไม่ต้องลองใหม่จนกว่าจะสุ่มเจอผู้ให้บริการที่ดีกว่า เพราะเส้นทางที่ผิดปกติจะถูกนำออกจากตัวเลือก
ทุกการตัดสินใจอัตโนมัติถูกบันทึก ผู้ดูแลได้รับแจ้งเมื่อสถานะสำคัญเปลี่ยน และสามารถยกเลิก suspension ด้วยตนเองได้เมื่อจำเป็น
ระบบนี้รับประกันอะไร — และไม่รับประกันอะไร
Canary ถูกจำกัดขอบเขตโดยตั้งใจ โค้ดสามารถตัดสิน latency, ความถูกต้องของ schema, การกรองที่มีความมั่นใจสูง, ความสมบูรณ์ของภาษาและ encoding แต่ไม่ได้แสร้งว่าสามารถให้คะแนนว่าตัวละครตลกพอ เข้าใจอารมณ์ดีพอ หรือซื่อตรงต่อบุคลิกที่ซับซ้อนเพียงใด
คำถามที่กว้างกว่านั้นยังต้องใช้การประเมินด้วย prompt ที่เป็นตัวแทน การตรวจโดยมนุษย์ production telemetry และที่สำคัญที่สุดคือรายงานจากผู้ใช้
ระบบนี้ไม่ได้หมายความว่าคำตอบแปลกทุกครั้งพิสูจน์ว่าโมเดลเสื่อม Generative model มีความน่าจะเป็น บทสนทนายาวอาจสะสมบริบทที่ขัดแย้งกัน และคำจำกัดความของตัวละครอาจมีคำสั่งที่แข่งขันกัน บางครั้งคำตอบแปลกก็คือคำตอบแปลกเพียงครั้งเดียว
สิ่งที่เปลี่ยนคือ “โมเดลเดียวกัน” ไม่ใช่จุดจบของการตรวจสอบอีกต่อไป ตอนนี้เราแยก serving route ทำซ้ำความล้มเหลวที่วัดได้ และกัน traffic ถัดไปออกจากเส้นทางนั้นได้
ความน่าเชื่อถือคือการรักษาประสบการณ์
Multi-provider routing ยังคงมีคุณค่า มันมอบ capacity และ resilience ให้ Reverie รักษาบทสนทนาให้พร้อมใช้งานเมื่อ endpoint บางแห่งล่ม
แต่ resilience ไม่ใช่แค่การได้รับ HTTP response คำตอบที่เริ่มช้าเกินไป สูญเสียโครงสร้างที่ต้องการ ปฏิเสธเนื้อหาที่รองรับ หรือเปลี่ยนภาษาอย่างฉับพลัน ไม่ได้กลายเป็นผลลัพธ์ที่ดีเพียงเพราะใบแจ้งหนี้บอกว่าคำขอสำเร็จ
สำหรับผลิตภัณฑ์ตัวละคร AI ความน่าเชื่อถือมีความหมายที่เป็นมนุษย์มากกว่า: ไม่ว่าเครื่องใดจะพูดแทน ตัวละครก็ควรยังรู้สึกว่าเป็นตัวละครเดิม
นี่คือมาตรฐานที่ระบบป้องกัน routing ใหม่ของเราสร้างขึ้นเพื่อรักษาไว้
หากคุณสังเกตว่าคุณภาพหรือภาษาของคำตอบเปลี่ยนไปอย่างฉับพลัน โปรดส่งรายงานพร้อมชื่อโมเดลและเวลาโดยประมาณ ข้อมูลนี้ช่วยให้เราเชื่อมประสบการณ์ที่คุณเห็นกับเส้นทางจริงที่ให้บริการได้