# จะทดสอบความเข้ากันได้ของ Streaming และ Tool Call ก่อนเปลี่ยน LLM API ได้อย่างไร? > ทดสอบการย้าย LLM API ด้วย contract fixture ที่บันทึกได้ ไม่ใช่ demo chat ครั้งเดียว ตรวจ text streaming, forced tool, อาร์กิวเมนต์ที่แบ่งเป็นส่วน, หลาย call, การส่งผลกลับ, cancellation, error และ usage การทดสอบ chat สิบนาทีอาจพลาด failure ที่สำคัญ: call ซ้ำหลัง retry, execute JSON ก่อน final stream event, ส่งผล tool ด้วย role ผิด หรือ write ยังทำงานหลัง cancellation Migration gate ที่มีประโยชน์จะส่ง fixed request ผ่าน parser และ executor จริง แล้วตรวจ structural invariant Suite แรกควรเล็กพอที่จะรันบ่อยและ deterministic พอสำหรับเปรียบเทียบหลายโมเดล เป้าหมายไม่ใช่จัดอันดับความฉลาด แต่พิสูจน์ว่า API ใหม่ขับ agent loop เดิมได้อย่างปลอดภัย ## กำหนด contract ที่ client พึ่งพา เขียนพฤติกรรมที่ client ต้องใช้ก่อนทดสอบ provider อย่าใช้เพียงคำกว้างๆ อย่าง “OpenAI compatible” | พื้นที่ contract | Invariant ที่ต้องรักษา | Evidence ที่เก็บ | |---|---|---| | Authentication | Endpoint รับ key | Status และ request ID | | Text stream | Delta ประกอบเป็น final message | Raw event ตามลำดับ | | Tool stream | Call เสร็จก่อน execution | Call buffer และ final event | | Correlation | Result เชื่อมกับ call ที่ถูกต้อง | Call ID mapping | | Retry | Call execute ไม่เกินหนึ่งครั้ง | Idempotency log | | Usage | Counter มีหรือระบุ unavailable | Final response metadata | Protocol support ขึ้นกับ model Atlas Cloud มีหลาย request format จึงควรดูคำแนะนำ [`supported_apis`](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=test-streaming-tool-call-compatibility-before-changing-llm-apis) ล่าสุดก่อนเลือก test route ## สร้างเครื่องมือ deterministic สี่ตัว ใช้ fixture ที่เผย failure mode ต่างกัน: * `echo_json` ส่งคืน validated argument โดยไม่เปลี่ยน * `read_fixture` อ่านไฟล์ที่รู้จักใน sandbox * `delayed_value` เสร็จหลัง delay ที่ควบคุมได้ * `always_error` ส่ง structured error ที่คงที่ กำหนด strict schema ที่มี `additionalProperties: false` และ unique fixture ID เพื่อให้เห็น duplicate execution อย่าพึ่ง weather, search result หรือ repository ที่เปลี่ยนตลอด ## รัน compatibility matrix เป็นขั้น ทดสอบ non-streaming ก่อน streaming และ single call ก่อน multiple call | ขั้น | Prompt behavior | เงื่อนไขผ่าน | |---|---|---| | A | ส่ง plain text | Final text และ stop status มาถึง | | B | Force `echo_json` | Name และ valid argument มาถึง | | C | Stream `echo_json` | Fragment ประกอบครั้งเดียว | | D | เรียก read tool สองตัว | Result ทั้งสอง correlate ถูกต้อง | | E | รับ tool error หนึ่งครั้ง | Model ซ่อมหรือออกอย่างสะอาด | | F | Cancel กลาง stream | ไม่มี late tool execution | ใช้ schema และ semantic request เดียวกันกับทุก candidate หาก native protocol ต้องใช้ envelope อื่น ให้ปรับเฉพาะ wire representation ## จับ raw event ใต้ SDK High-level SDK object สะดวกใน production แต่อาจซ่อนความต่างตอนย้าย เพิ่ม debug transport ที่เขียน monotonic sequence number, response ID, output index, call ID, event type และความยาว payload ที่ลบข้อมูลสำคัญแล้ว Streaming function argument เป็น incremental ประกอบตาม call และรอ final argument event: ```text START -> CALL_OPEN -> ARGUMENT_DELTAS -> CALL_DONE -> VALIDATED -> EXECUTED | | +-> CANCELLED <---+ ``` ปฏิเสธ transition ย้อนกลับและ double execution หาก connection ขาดหลัง `EXECUTED` แต่ก่อน model ได้ผล ให้ใช้ idempotency key แทนการทำ write ซ้ำโดยไม่ตรวจ ## ทดสอบ round trip ของผล tool ทั้งหมด Valid tool call เป็นเพียงครึ่งหนึ่งของ contract ส่งผลกลับด้วย message หรือ item type ที่ protocol คาดหวัง แล้วบังคับให้ final answer ใช้ field ที่ทราบจากผลนั้น ทดสอบผลขนาดใหญ่ ผลว่าง Unicode และ structured error จำกัดขนาดก่อนกลับเข้า context สมมติฐานของ adapter อาจเพิ่งเผยเมื่อเจอผลขนาดใหญ่ครั้งแรก ## เปรียบเทียบ invariant ไม่ใช่ถ้อยคำ อย่าให้ suite fail เพียงเพราะสองโมเดลเขียน final answer ต่างกัน ตรวจว่า: * เลือก tool name ที่คาดไว้ * Argument ผ่าน JSON Schema * ทุก call ID unique และ correlate ถูกต้อง * แต่ละ tool execute ศูนย์หรือหนึ่งครั้งตามแผน * Loop จบภายใน call budget * Final answer ใช้ fixture result เก็บ candidate-specific snapshot สำหรับ debugging เท่านั้น และรักษา pass criteria ให้เป็นกลางต่อ provider ## เพิ่มกรณี failure และ cancellation ตัด stream หลัง argument fragment แรก หลัง call complete และหลัง tool execution Inject 429, timeout, malformed JSON และ unknown tool name ตรวจว่า client retry อย่างปลอดภัย resume ได้ หรือหยุดด้วย error ที่มีประโยชน์ Bug ที่อันตรายที่สุดคือ ambiguous retry ที่ทำ state-changing tool ซ้ำ Write ต้องมี explicit idempotency ## ทำ suite ให้เป็น release gate เก็บ fast smoke suite สำหรับ configuration change และ full matrix สำหรับ SDK หรือ gateway upgrade บันทึก model, protocol, Base URL, schema hash, streaming flag, client version และ timestamp กับผล Atlas Cloud รองรับ LLM request แบบ streaming และ non-streaming และให้สำรวจ candidate จาก [model catalog](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=test-streaming-tool-call-compatibility-before-changing-llm-apis) เดียว Shared access ไม่ได้แปลว่าความสามารถเหมือนกัน จึงต้องรัน gate เดียวกันกับแต่ละ model ## สรุป ทดสอบการย้าย LLM API เป็นการเปลี่ยนโปรโตคอลที่มี state เริ่มด้วย deterministic tool บันทึก raw event ประกอบ argument หลัง completion เท่านั้น ตรวจ result round trip และ inject retry กับ cancellation เปิดใช้โมเดลใหม่เมื่อ contract suite ผ่าน ไม่ใช่เมื่อ chat response หนึ่งครั้งดูถูกต้อง ## FAQ ### การทดสอบ compatibility ครั้งแรกควรครอบคลุมอะไร? เริ่มด้วย text request แบบไม่ streaming หนึ่งครั้งและ forced read-only tool call หนึ่งครั้ง เพื่อแยกปัญหา endpoint, authentication, schema และรูปแบบ response พื้นฐาน ### เหตุใดต้องบันทึก raw streaming event? SDK helper อาจซ่อนลำดับ event และความต่างของ field Raw event แสดงว่า call ID, argument fragment, completion marker, error และ usage มาถึงอย่างไรจริงๆ ### เปรียบเทียบ provider ด้วยข้อความที่เหมือนกันทุกคำได้หรือไม่? โดยทั่วไปไม่ควร เปรียบเทียบ structural invariant เช่น call ที่ valid, field บังคับ, จำนวน execution, final status และ task outcome ### ควรทดสอบ malformed tool argument อย่างไร? ส่ง structured validation error กลับให้โมเดล และตรวจว่า loop แก้หรือหยุดภายใน call budget ที่กำหนดโดยไม่ execute input ที่ไม่ปลอดภัย ### Test suite ควรใช้ write tool หรือไม่? เริ่มด้วย deterministic read-only tool เพิ่ม sandboxed write fixture หลังจาก call assembly, validation, deduplication และ error recovery ผ่านแล้ว ### ควรรัน compatibility test บ่อยเพียงใด? รัน smoke subset ก่อนเปลี่ยน model หรือ protocol ทุกครั้ง และรัน full suite เมื่อ SDK, schema, gateway หรือ stream parser เปลี่ยน