Neon Functions รองรับการเชื่อมต่อแบบสตรีมมิ่งที่ไม่มีการจำกัดระยะเวลาแล้ว ช่วยให้ AI agent สามารถเปิดช่องทางการสื่อสารแบบสด (live channel) ทิ้งไว้ได้นานเป็นวินาที เป็นนาที หรือนานกว่านั้น โดยไม่ติดขีดจำกัดเรื่อง timeout ที่มักจะสั่งปิดเวิร์กโหลดแบบ serverless ส่วนใหญ่ การเปลี่ยนแปลงนี้มีความสำคัญอย่างยิ่งสำหรับใครก็ตามที่กำลังสร้างผู้ช่วยในรูปแบบแชท (chat-style assistants) หรือบอทที่ใช้งานเครื่องมือได้ (tool-using bots) เพราะการที่สตรีมขาดตอนจะทำให้การสนทนาหยุดชะงักและทำลายประสบการณ์ของผู้ใช้

ทำไม serverless และ AI agent ถึงมักจะมีปัญหาขัดแย้งกัน

แพลตฟอร์ม serverless ส่วนใหญ่ถูกสร้างขึ้นมาเพื่อรองรับงานแบบสั่งแล้วจบไป (fire-and-forget) อย่างรวดเร็ว โดยมีการกำหนดขีดจำกัดการประมวลผลที่เข้มงวด เช่น มักจะจำกัดไว้ที่ 10 วินาทีสำหรับแพ็กเกจฟรี และ 60 วินาทีสำหรับแพ็กเกจแบบชำระเงิน เพื่อให้การใช้ทรัพยากรเป็นไปอย่างคาดการณ์ได้ อย่างไรก็ตาม AI agent ต้องใช้เวลาในการ "คิด" เรียกใช้เครื่องมือภายนอก และส่งออกโทเคน (tokens) ในขณะที่กำลังสร้างข้อมูล ช่วงเวลาแห่งการ "คิด" นี้มักจะลากยาวไปหลายสิบวินาที และสตรีมของโทเคนสามารถดำเนินต่อไปได้ตราบเท่าที่โมเดลยังคงสร้างผลลัพธ์ออกมา เมื่อตัวจับเวลาของแพลตฟอร์มหมดลง มันจะปิดการเชื่อมต่อ และฝั่งไคลเอนต์ก็จะพบกับสตรีมที่ขาดตอน

คำตอบจาก Neon: การสตรีมมิ่งที่คงอยู่ได้นานเป็นค่าเริ่มต้น

Neon Functions พลิกกฎเกณฑ์เดิมๆ โดยการเรียกใช้งานฟังก์ชันสามารถเปิดค้างไว้ได้ไม่จำกัดเวลา โดยส่งข้อมูลผ่าน WebSockets หรือ Server-Sent Events (SSE) ได้โดยไม่ต้องมีการตั้งค่าพิเศษ แพลตฟอร์มจะปฏิบัติกับสตรีมที่ยาวนานเหมือนกับการร้องขอ (request) ปกติ ดังนั้นนักพัฒนาเพียงแค่เขียนลอจิกที่สร้างสตรีมขึ้นมา แล้วปล่อยให้ Neon จัดการส่วนที่เหลือเอง

ในการทดสอบล่าสุด มีสองเอนด์พอยต์ที่แสดงให้เห็นถึงพฤติกรรมนี้:

  • Heartbeat endpoint – ฟังก์ชันส่งสัญญาณ "tick" หนึ่งครั้งต่อวินาที เป็นเวลา 90 วินาที โดยปกติแล้วระดับ serverless ทั่วไปจะยุติการร้องขอหลังจากผ่านไป 10 หรือ 60 วินาที แต่ Neon ยังคงรักษาการเชื่อมต่อไว้จนกว่าฟังก์ชันจะทำงานเสร็จสิ้นด้วยตัวเอง
  • Token-relay endpoint – ฟังก์ชันสตรีมโทเคนจาก AI model ไปยังไคลเอนต์ทันทีที่แต่ละโทเคนถูกสร้างขึ้น ผู้ใช้จะเห็นคำตอบปรากฏขึ้นทีละคำแทนที่จะต้องรอให้ข้อความทั้งหมดแสดงออกมาพร้อมกัน

ทั้งสองตัวอย่างนี้ต้องการเพียงการร้องขอเพียงครั้งเดียวจากไคลเอนต์ โดยไม่จำเป็นต้องใช้เทคนิคการทำ polling หรือ keep-alive ใดๆ

ใครได้ประโยชน์ และใครที่ควรระมัดระวัง

ทีมที่กำลังสร้างผู้ช่วยสนทนา (conversational assistants), เอเจนต์ที่ใช้งานเครื่องมือได้ (tool-using agents) หรือบริการใดๆ ที่จำเป็นต้องส่งผลลัพธ์แบบทีละส่วน (incremental results) จะได้รับประโยชน์ทันที นั่นคือปัญหาเรื่อง timeout จะหมดไป ผลลัพธ์ที่ได้คือโค้ดที่เรียบง่ายขึ้น ความหน่วง (latency) ที่ต่ำลง และประสบการณ์ผู้ใช้ที่ราบรื่นยิ่งขึ้น

อย่างไรก็ตาม มีข้อควรพิจารณาดังนี้:

  • Request-only model – Neon Functions จัดการกับสตรีมที่เชื่อมต่ออยู่กับการร้องขอที่ยังทำงานอยู่ (active request) เท่านั้น สำหรับงานเบื้องหลัง (background jobs) ที่ต้องทำงานนานกว่าการร้องขอ ยังคงต้องใช้ตัวจัดตารางงานแยกต่างหาก เช่น Inngest หรือ workflow engine ที่คล้ายกัน
  • Cold starts – ฟังก์ชันที่ไม่ได้ใช้งานสามารถสเกลลงจนเหลือศูนย์ได้ ดังนั้นการร้องขอครั้งถัดไปอาจเกิดความล่าช้าจาก cold-start แม้ว่าสตรีมที่กำลังทำงานอยู่จะช่วยป้องกันการสเกลลงได้ แต่การร้องขอครั้งแรกหลังจากไม่มีการใช้งานยังคงต้องเผชิญกับต้นทุนในการเริ่มระบบ (start-up cost)

สิ่งที่ต้องจับตามองต่อไป

สรุปใจความสำคัญคือ: Neon Functions ช่วยขจัดเพดานเรื่อง timeout ที่เคยบีบบังคับให้นักพัฒนา AI ต้องใช้วิธีการแก้ปัญหาแบบอ้อมๆ มาอย่างยาวนาน การปล่อยให้การร้องขอเปิดค้างไว้ได้นานเท่าที่เอเจนต์ต้องการเพื่อคิดและสื่อสาร ทำให้ Neon ช่วยให้การปรับใช้ AI agent แบบสตรีมมิ่งนั้นง่ายพอๆ กับการใช้งาน serverless function อื่นๆ ทั่วไป