Spring AI รุ่นใหม่จัดแชตเป็นลำดับ แต่ความจำถาวรยังตามไม่ทัน

Spring AI 2.1.0-M1 เปิดให้ทดลองแล้ว แปลว่าเครื่องมือสร้างแชตบอตด้วย Java มีรุ่นใหม่ให้ทีมงานทดสอบ ตามประกาศวันที่ 25 กันยายนของ DevFeed ครับ จุดเปลี่ยนคือข้อความสนทนาเก็บส่วนประกอบตามลำดับได้ แต่ยังเป็นรุ่นทดลองที่รายละเอียดอาจเปลี่ยนก่อนรุ่นพร้อมใช้ทั่วไป ตามประกาศเดียวกัน

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

สรุป 30 วินาที: เกิดอะไรขึ้น

Spring AI คือชุดเครื่องมือช่วยนักพัฒนาเชื่อมโปรแกรม Java เข้ากับบริการ AI รุ่นนี้เป็น milestone แรกของสายใหม่ แปลว่าเป็นจุดตรวจระหว่างการพัฒนา ยังไม่ใช่ GA หรือรุ่นพร้อมใช้ทั่วไป ตาม DevFeed ทีมจึงควรใช้เพื่อทดลองและส่งข้อเสนอแนะ ก่อนตัดสินใจนำไปให้บริการลูกค้า

รายการรุ่นบน GitHub ของ Spring AI ยืนยันการเพิ่ม MessagePart ซึ่งแบ่งข้อความเป็นส่วนย่อยที่เรียงลำดับได้ แหล่งเดียวกันยืนยันการรองรับ OpenAI Responses API หรือช่องทางรับส่งคำขอแบบใหม่กับบริการ AI และเพิ่ม VectorStore.upsert สำหรับนำข้อมูลที่คำนวณไว้แล้วเข้าแหล่งเก็บข้อมูลค้นหา

รุ่นนี้สร้างโดยอิง Spring Boot 4.2.0-M2 แปลว่าชุดเครื่องมือพื้นฐานที่รองรับแอปก็เป็นรุ่น milestone ตาม JavaRubberDuck ดังนั้นการประเมินไม่ได้จบแค่เปลี่ยน Spring AI ต้องตรวจความเข้ากันได้ของพื้นฐานแอปด้วย แล้วการเรียงส่วนประกอบข้อความใหม่เกี่ยวกับคำตอบที่เราเห็นอย่างไร?

ทำไมเรื่องนี้เกี่ยวกับคุณ

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

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

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

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

ทำงานยังไง

ข้อความหนึ่งชุด เก็บชิ้นส่วนตามลำดับ

MessagePart คือส่วนย่อยภายในข้อความสนทนา มีทั้งข้อความธรรมดา ข้อมูลการให้เหตุผล คำขอเรียกเครื่องมือ ผลจากเครื่องมือ และสื่อ ตาม DevFeed ชื่อที่นักพัฒนาจะพบคือ TextPart, ReasoningPart, ToolCallPart, ToolResultPart และ MediaPart ตามลำดับ ทั้งหมดอยู่ในรายการที่รักษาลำดับเดิมจากผู้ให้บริการ ตามประกาศนี้

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

อุปมานี้ช่วยอธิบายการส่งประวัติกลับไปในรอบถัดไป ไม่ได้หมายความว่ารุ่นใหม่รับประกันคำตอบถูกต้อง DevFeed ระบุว่า ReasoningPart และ ToolCallPart เก็บ OpaquePayload ได้ ซึ่งคือข้อมูลเฉพาะผู้ให้บริการที่ต้องส่งกลับโดยไม่เปลี่ยนแปลง นอกจากนี้ UnknownPart ยังรักษาข้อมูล JSON ดิบ หรือข้อมูลเป็นโครงสร้าง ของส่วนที่ตัวเชื่อมยังไม่รู้จัก เพื่อไม่ให้ข้อมูลถูกทิ้งเงียบ ๆ ตามแหล่งเดียวกัน

วิธีอ่านข้อมูลเดิมอย่าง getText() และ getMedia() ยังอยู่ โดยเปลี่ยนมาอ่านจากส่วนประกอบเหล่านี้ ตาม JavaRubberDuck แต่การที่โค้ดยังแปลงเป็นโปรแกรมได้ ไม่ใช่ผลทดสอบว่าทุกเส้นทางของแอปทำงานเหมือนเดิม ทีมยังควรตรวจส่วนที่สร้างข้อความ เก็บประวัติ และส่งคำขอจริงแยกกัน

ช่องทางเชื่อม OpenAI แบบใหม่

OpenAiResponsesChatModel คือส่วนของ Spring AI ที่เชื่อมกับปลายทาง /v1/responses ของ OpenAI ตาม JavaRubberDuck ปลายทางในที่นี้หมายถึงช่องทางที่โปรแกรมส่งคำขอไปให้บริการประมวลผล นักพัฒนาเลือกใช้งานได้ด้วยค่าตั้งต้น spring.ai.openai.chat.api=responses ตามรายงานนี้

JavaRubberDuck อธิบายว่า Chat Completions ซึ่งเป็นช่องทางแชตอีกแบบ มีข้อจำกัดเมื่อใช้การเรียกเครื่องมือร่วมกับ reasoning effort ที่ไม่ใช่ none ตามรายงานของสื่อนี้ reasoning effort คือค่ากำหนดระดับการให้เหตุผล ส่วน none หมายถึงไม่ใช้ระดับดังกล่าว รายงานระบุว่า Responses API ทำงานร่วมกันในกรณีนี้ได้ แต่ไม่ได้ให้ผลทดสอบว่าบอตของทุกบริษัทจะตอบดีขึ้นหรือเร็วขึ้น ตามแหล่งเดียวกัน

จุดหักมุม: เรียงครบตอนคุย แต่ยังเก็บถาวรไม่ครบ

แต่ความสามารถใหม่ยังไปไม่ถึงทุกส่วนครับ JavaRubberDuck ระบุว่า OpenAiResponsesChatModel เป็นโมเดลเดียวในตอนนี้ที่สร้าง Message Parts โดยตรง ผู้ให้บริการอื่นมีแผนปรับโครงสร้างก่อน RC1 ซึ่งหมายถึงรุ่นเตรียมพร้อมก่อนออกจริง ตามรายงานนี้

ข้อจำกัดที่ต้องอ่านให้ชัดคือ persistent chat memory หรือระบบเก็บประวัติแชตถาวร ยังไม่เก็บ parts ตาม JavaRubberDuck รายงานระบุว่าข้อมูลการให้เหตุผลจึงส่งต่อระหว่างรอบได้ด้วยความจำภายในหน่วยความจำของโปรแกรมในตอนนี้ การเปิดฟีเจอร์ใหม่จึงไม่ได้แปลว่าชั้นเก็บประวัติถาวรพร้อมรองรับตามไปด้วย

เรื่องเงิน / ผลกระทบ

อีกความสามารถที่เกี่ยวข้องกับงานหลังบ้านคือ VectorStore.upsert ตามรายการรุ่นของ Spring AI บน GitHub Vector Store คือแหล่งเก็บข้อมูลตัวเลขสำหรับค้นสิ่งที่มีความหมายใกล้กัน ส่วน embeddings คือการแปลงเอกสารเป็นชุดตัวเลขเพื่อใช้ในการค้นหา รุ่นนี้รับเอกสารที่มีชุดตัวเลขคำนวณมาแล้วได้ ตาม JavaRubberDuck

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

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

แหล่งเก็บข้อมูลที่รองรับตอนเปิดตัวมี pgvector, Redis, Elasticsearch และ Qdrant ตาม JavaRubberDuck หากบริษัทใช้ระบบอื่น อย่าอนุมานว่ารองรับเหมือนกัน ควรตรวจความเข้ากันได้ก่อนวางแผนย้ายงาน ส่วนแหล่งข่าวที่อ่านยังไม่มีตัวเลขลดต้นทุนหรือค่าใช้จ่ายเป็นเงินบาท จึงยังตอบไม่ได้ว่าบริษัทไทยจะประหยัดเท่าไร

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

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

ฝั่งที่ชวนให้ทดลอง: Tzolov เขียนใน DevFeed ในนามทีม Spring AI ว่า API ใหม่พร้อมให้ลอง และข้อเสนอแนะจะช่วยกำหนดทิศทางต่อไป แหล่งเดียวกันย้ำว่า API อาจเปลี่ยนก่อน GA นี่จึงเป็นเสียงสนับสนุนให้ร่วมทดสอบ ไม่ใช่คำรับรองให้นำขึ้นระบบใช้งานจริงทันที

ฝั่งที่ชี้ข้อจำกัด: Stanislav Lentsov ใน JavaRubberDuck ระบุว่าผู้ให้บริการอื่นยังต้องปรับโครงสร้าง และระบบเก็บประวัติถาวรยังไม่เก็บ parts ประเด็นนี้เป็นข้อจำกัดที่ถ่วงความพร้อมใช้งาน ไม่ใช่คำประกาศคัดค้าน Spring AI จากผู้เขียน ในชุดแหล่งข่าวนี้ไม่มีเสียงคัดค้านโดยตรง จึงไม่ควรแต่งคู่ขัดแย้งขึ้นมา

ทั้งสองแหล่งไม่ได้ขัดกันเรื่องการมี Message Parts แต่รายละเอียดคนละระดับ DevFeed อธิบายโครงสร้างที่รักษาข้อมูลและลำดับ ส่วน JavaRubberDuck บอกขอบเขตการรองรับในรุ่นนี้ การอ่านเฉพาะประโยชน์โดยข้ามข้อจำกัด จึงอาจทำให้เข้าใจว่าการเชื่อมทุกบริการกับการเก็บประวัติพร้อมแล้ว

GitHub releases ยืนยันรายการฟีเจอร์หลัก แต่รายละเอียดแก้บั๊กจำนวนมากในไฟล์แหล่งข่าวอยู่ใต้หัวข้อรุ่นก่อนหน้า จึงไม่ควรนำทั้งหมดมาเขียนเป็นการแก้ใหม่ของรุ่นนี้ ส่วน JavaRubberDuck ระบุการแก้ค่ากำหนดเวลารอ OpenAI ที่ถูกละเลย และโครงสร้างเครื่องมือใน strict mode ซึ่งเป็นโหมดบังคับรูปแบบข้อมูลอย่างเข้มงวด รายละเอียดการแก้เหล่านี้อ้างจากรายงานสื่อนี้โดยตรง ไม่ใช่รายการยืนยันแยกในส่วนรุ่นใหม่ที่ไฟล์ GitHub ให้มา

ยังไม่มีวัน GA หรือวันที่เก็บ parts ในประวัติถาวรได้ครบในชุดข้อมูลนี้ แผนปรับผู้ให้บริการก่อน RC1 ก็ยังไม่มีวันที่ระบุ ตาม JavaRubberDuck ถ้าระบบต้องเปิดบทสนทนาเก่ากลับมาทำงานต่อ ทีมจะพิสูจน์ความครบของข้อมูลตรงนั้นอย่างไร? คำตอบต้องมาจากการทดสอบระบบของตัวเอง ไม่ใช่ชื่อรุ่นเพียงอย่างเดียว

แล้วเราควรทำอะไร

คนทั่วไปและเจ้าของธุรกิจที่ใช้บอต

1. ขอให้ผู้ดูแลบอกชัดว่าบอตใช้รุ่นใด และการเปลี่ยนรุ่นจะกระทบงานอะไร ไม่ต้องอนุมัติการย้ายเพียงเพราะมีคำว่า AI รุ่นใหม่
2. เลือกบทสนทนาที่สำคัญกับงาน เช่น ถามข้อมูลแล้วถามต่อจากผลเดิม ให้ทีมทดสอบด้วยข้อมูลสมมติที่ไม่มีรายละเอียดลูกค้า
3. ขอผลทดสอบทั้งการคุยต่อทันทีและการกลับมาเปิดประวัติที่เก็บไว้ จุดนี้สัมพันธ์กับข้อจำกัดความจำถาวรที่ JavaRubberDuck ระบุ

ทีม IT ที่ดูแลบริการ

1. แยกพื้นที่ทดลองออกจากบริการลูกค้า และคงรุ่นเดิมที่ผ่านการตรวจของบริษัทไว้ก่อน เหตุผลคือ API ของ milestone ยังอาจเปลี่ยนตาม DevFeed
2. ตรวจความเข้ากันได้ของ Spring Boot และส่วนเก็บประวัติ พร้อมจดว่าบริการ AI ใดถูกใช้จริง อย่าสรุปว่าทุกผู้ให้บริการสร้าง parts ได้จากข่าวการรองรับรายแรก
3. ตั้งเกณฑ์ผ่านจากงานจริงของบริษัท เช่น ประวัติที่ส่งต่อครบและผลเครื่องมือไม่ตกหล่น พร้อมกำหนดผู้รับผิดชอบตัดสินใจย้อนกลับเมื่อผลต่างจากเดิม

นักพัฒนาที่จะลองความสามารถใหม่

1. เริ่มจากข้อความที่มีส่วนประกอบหลายชนิด ตรวจลำดับก่อนส่งและหลังรับกลับ เทียบกับวิธีอ่านข้อมูลเดิมที่ยังรองรับตาม DevFeed
2. ทดลองค่าตั้งต้นเลือก Responses API ในพื้นที่ทดสอบ แล้วตรวจการเรียกเครื่องมือร่วมกับข้อมูลการให้เหตุผล อย่าถือว่าการเปลี่ยนค่าเดียวทำให้การย้ายระบบเสร็จ
3. ถ้าใช้ upsert ให้กำหนดตัวระบุเอกสารคงที่ แล้วทดสอบนำเข้าซ้ำกับแหล่งเก็บที่รองรับตาม JavaRubberDuck เก็บผลทดสอบแยกจากสมมติฐานเรื่องความเร็วหรือค่าใช้จ่าย

ผมมองว่า…

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

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

ปิดท้าย: สิ่งที่ต้องจับตา

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

ถ้าบริษัทคุณมีบอตอยู่แล้ว คุณอยากให้ทีมทดสอบบทสนทนาที่ต้องถามต่อเรื่องไหนก่อนนำรุ่นใหม่มาใช้?

Recap

• เกิดอะไรขึ้น: Spring AI เพิ่มข้อความแบบเรียงส่วนประกอบ ช่องทาง Responses API และการนำเข้าชุดตัวเลขที่คำนวณไว้แล้ว ตามรายการรุ่นทางการ
• ตัวเลขที่ต้องจำ: M1 แปลว่า milestone แรก ยังเป็นรุ่นทดลอง ไม่ใช่ GA ตาม DevFeed
• ใครเห็นต่าง: ไม่มีเสียงคัดค้านโดยตรงในแหล่งที่อ่าน DevFeed ชวนทดลอง ส่วน JavaRubberDuck เพิ่มข้อจำกัดความพร้อม
• ยังไม่รู้: วัน GA วันเก็บ parts ถาวรได้ครบ และผลต้นทุนจริงของบริษัทไทย
• กระทบคุณ: ทีมทำบอตควรทดสอบการถามต่อ การเก็บประวัติ และการนำเข้าเอกสาร ก่อนใช้กับลูกค้าจริง
• สิ่งที่ต้องจับตา: การปรับผู้ให้บริการอื่นและความครบของชั้นเก็บประวัติ ไม่ถือว่าเปิดฟีเจอร์แล้วทุกส่วนพร้อม
• แหล่งอ้างอิง: 1 — DevFeed, 2 — GitHub releases, 3 — JavaRubberDuck