Streaming

Streaming คือวิธีรับคำตอบแบบทยอยส่งทีละชิ้นตั้งแต่ตอนที่ model ยังเขียนไม่จบ แทนที่จะรอให้เขียนครบทั้งก้อนแล้วค่อยส่งกลับมาทีเดียว คนทำงานทั่วไปเห็นผลของมันทุกวันบนหน้าจอ chatbot ตรงที่ตัวหนังสือค่อยๆ ไหลออกมาทีละท่อนเหมือนมีคนกำลังพิมพ์อยู่อีกฝั่ง เอกสารของ openai อธิบายประโยชน์ของมันตรงไปตรงมาว่าเราเริ่มแสดงผลหรือเริ่มประมวลผลส่วนต้นของคำตอบได้ทั้งที่ model ยังผลิตส่วนที่เหลือไม่เสร็จ ฝั่ง anthropic เปิดใช้ด้วยการใส่ค่า stream เป็น true ในคำขอที่ยิงผ่าน api แล้วคำตอบจะกลับมาเป็นสายเหตุการณ์ตามมาตรฐาน server-sent events (SSE) แทนที่จะเป็นก้อนคำตอบก้อนเดียว

สิ่งที่ไหลกลับมาไม่ใช่ตัวหนังสือลอยๆ แต่เป็นเหตุการณ์ที่มีลำดับชัดเจน เอกสารของ Anthropic ไล่ลำดับไว้ว่าเริ่มที่ message_start ซึ่งเป็นโครงข้อความเปล่า ตามด้วยชุดของ content_block ที่แต่ละชุดมี content_block_start แล้วทยอยส่ง content_block_delta หลายรอบก่อนปิดด้วย content_block_stop จากนั้นจบด้วย message_delta และ message_stop ส่วนฝั่ง OpenAI ใช้ชื่อเหตุการณ์คนละชุดแต่หลักการเดียวกัน คือ response.created ตอนเริ่ม response.output_text.delta สำหรับตัวหนังสือแต่ละท่อน และ response.completed ตอนจบ จุดที่คนเข้าใจผิดบ่อยคือคิดว่าเปิด streaming แล้ว AI จะคิดเร็วขึ้น ความจริงคือ inference ยังผลิต output-tokens ทีละตัวด้วยจังหวะเดิม สิ่งที่เปลี่ยนไปคือเราได้เห็นของชิ้นแรกเร็วขึ้นเท่านั้น เอกสารเรื่องการลด latency ของ Anthropic ถึงกับแยกตัววัดออกเป็นสองแบบ คือ baseline latency ที่นับเวลาทั้งกระบวนการ กับ time to first token (TTFT) ที่นับเฉพาะเวลาจนถึง token ตัวแรก แล้วระบุว่า TTFT สำคัญเป็นพิเศษเวลาใช้ streaming และบอกว่าสิ่งที่ streaming ช่วยได้คือ perceived responsiveness หรือความรู้สึกว่าระบบตอบสนองไว ไม่ใช่ความเร็วในการผลิตคำตอบ

ในงานจริง streaming ไม่ได้เป็นแค่ลูกเล่นให้หน้าจอดูมีชีวิต บางกรณีผู้ให้บริการเองเป็นฝ่ายบังคับ หน้าเอกสาร errors ของ Anthropic เตือนให้ใช้ streaming Messages API หรือ Message Batches API กับคำขอที่กินเวลานาน โดยเฉพาะงานที่เกิน 10 นาที และระบุว่า SDK ของบริษัทจะตรวจว่าคำขอแบบไม่ streaming ต้องไม่ถูกคาดหมายว่าจะเกิน timeout 10 นาที ส่วนหน้าเอกสาร streaming ระบุว่าคำขอที่ตั้ง max_tokens ไว้สูงมากนั้น SDK จะบังคับให้ใช้ streaming เพื่อเลี่ยง HTTP timeout เหตุผลที่ต้องระวังคือบางเครือข่ายตัดการเชื่อมต่อที่เงียบอยู่นานทิ้ง คำขอจึงล้มหรือหมดเวลาโดยไม่ได้คำตอบกลับมาเลย ในทางกลับกัน ระบบที่ต้องได้คำตอบครบก่อนถึงทำงานต่อได้กลับไม่ได้ประโยชน์จากการไหลนี้เท่าไร กรณีชัดที่สุดคือ tool-call เพราะเอกสารของ Anthropic ระบุว่าค่าที่ส่งเข้าเครื่องมือจะไหลมาเป็นชิ้นส่วน JSON ที่ยังไม่สมบูรณ์ ต้องสะสมไว้แล้วค่อยแปลงตอนได้ content_block_stop และเตือนไว้ด้วยว่าเวลาใช้เครื่องมือ ระหว่างเหตุการณ์แต่ละครั้งอาจมีจังหวะเงียบขณะที่ model กำลังทำงานอยู่ ฝั่ง OpenAI ก็เป็นแบบเดียวกัน คือค่าของ function call ไหลมาทีละ delta แล้วต้องรอเหตุการณ์ done ที่บรรจุคำสั่งเต็มก้อน อีกข้อที่องค์กรมักมองข้ามคือเอกสารของ OpenAI ระบุตรงๆ ว่าการเปิด streaming ในระบบที่ใช้งานจริงทำให้กลั่นกรองเนื้อหาได้ยากขึ้น เพราะคำตอบที่ยังไม่จบประเมินยากกว่า และคะแนนการกลั่นกรองจะมาถึงหลังคำตอบครบแล้วเท่านั้น ไม่ได้แนบมากับชิ้นส่วนระหว่างทาง ใครที่วางแผนให้มีด่านกรองก่อนข้อความถึงมือลูกค้าต้องเผื่อเรื่องนี้ไว้ตั้งแต่ออกแบบ

ตัวอย่างจากบทสนทนาจริง

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

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

ระวังสับสนกับ

• latency : latency คือเวลารอจริงที่จับเวลาได้ ส่วน streaming เป็นแค่วิธีส่งของกลับมา มันไม่ได้ทำให้เวลารวมสั้นลง แต่ย้ายจังหวะที่เราเห็นผลชิ้นแรกให้มาถึงเร็วขึ้น จนความรู้สึกระหว่างรอต่างกันมาก
• full-duplex : full-duplex คือการที่สองฝ่ายส่งเสียงหากันได้พร้อมกันจนพูดแทรกกลางประโยคได้ ส่วน streaming ที่พูดถึงในหน้านี้เป็นการไหลทางเดียวจาก model มาหาเรา และไม่ได้แปลว่าเราขัดจังหวะกลางคันได้เสมอไป
• structured-output : structured-output คือการบังคับให้คำตอบออกมาเป็นโครงสร้างข้อมูลตามแบบที่กำหนดไว้ ซึ่งเป็นคนละเรื่องกับจังหวะการส่ง ใช้ร่วมกับ streaming ได้ แต่ปลายทางยังต้องรอชิ้นส่วนมาครบก่อนถึงจะอ่านโครงสร้างนั้นได้จริง