Pydantic AI 2.55.0 ให้บอตพกแชตต่อ พร้อมยอดใช้ที่ไม่เริ่มนับใหม่

Pydantic AI รุ่น 2.55.0 เพิ่ม Conversation ให้บอตพกบทสนทนาต่อระหว่างรอบทำงานได้ แปลว่าเครื่องมือสร้างบอตด้วยภาษา Python มีตัวรวมข้อมูลสำหรับคุยต่อโดยเฉพาะครับ (บันทึกการออกรุ่น) โครงการเผยแพร่รุ่นนี้วันที่ 9 ตุลาคม โดยทุกช่องทางเริ่มทำงานรับข้อมูลผ่าน conversation= ได้ตามประกาศเดียวกัน (GitHub)

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

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

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

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

รุ่นนี้กำหนด Python ขั้นต่ำเป็น 3.11 แปลว่าทีมที่ใช้รุ่นเก่ากว่านี้ต้องตรวจสภาพแวดล้อมก่อนอัปเกรด (GitHub) หากยังใช้ Python 3.10 การติดตั้งจะเลือก Pydantic AI รุ่นก่อนหน้าแทนตามหมายเหตุความเข้ากันได้ (GitHub) เจ้าของกิจการไม่ต้องจำชื่อวิธีเรียกโปรแกรม แต่ควรรู้ว่าการเปลี่ยนครั้งนี้อาจต้องเตรียมระบบร่วมด้วย

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

ลองสมมติร้านค้าทำบอตใน LINE ให้ลูกค้าถามสินค้าแล้วกลับมาคุยต่อวันถัดไป ตัวอย่างนี้เป็นสถานการณ์ประกอบ ไม่ใช่ประกาศว่ารุ่นนี้มีตัวเชื่อม LINE สำเร็จรูป หลักที่เอกสารยืนยันคือแอปสามารถเก็บ Conversation ลงฐานข้อมูลของตัวเอง แล้วโหลดกลับมาสำหรับการคุยครั้งถัดไป (Pydantic Docs)

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

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

แล้วบอตที่จำข้อความได้ แปลว่าจำยอดใช้ไปด้วยหรือเปล่า? คำตอบจาก DouweM คือไม่เสมอไป เพราะยอดใช้งานมีรายละเอียดที่ย้อนสร้างจากข้อความอย่างเดียวไม่ได้ (PR ของ Conversation) ประโยคนี้ทำให้ข่าวเปลี่ยนจากเรื่องแชตสะดวก ไปเป็นเรื่องที่คนอนุมัติงบควรรู้ด้วย

ทำงานยังไง

State คือข้อมูลสถานะที่ต้องรักษาไว้เพื่อทำงานต่อ ในกรณีนี้ไม่ได้มีแค่สิ่งที่ลูกค้าพิมพ์ แต่รวมยอดใช้และสิ่งที่บอตยังรออยู่ด้วย (PR ของ Conversation) Run คือการทำงานหนึ่งรอบ ส่วน Conversation เป็นข้อมูลที่ส่งจากรอบที่จบแล้วไปยังรอบถัดไป (Pydantic Docs)

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

Serialize คือแปลงข้อมูลในโปรแกรมให้อยู่ในรูปที่เก็บและอ่านกลับได้ เอกสารแนะนำให้แปลง Conversation เป็น JSON ซึ่งเป็นรูปแบบข้อมูลข้อความ แล้วเก็บในฐานข้อมูลของแอป (Pydantic Docs) เมื่อเริ่มรอบใหม่ แอปอ่านกลับแล้วส่งผ่าน conversation= ยอดใช้งานจึงนับต่อจากรอบก่อน (Pydantic Docs)

Deferred tool request คือคำขอใช้เครื่องมือที่พักไว้ก่อน เช่น รอคนอนุมัติ หรือรอผลจากระบบภายนอก (PR ของ Conversation) ข้อความอย่างเดียวบอกได้ว่ามีคำขอที่ยังไม่ได้คำตอบ แต่ไม่บอกครบว่ารออะไร Conversation จึงเก็บรายการนี้เพื่อให้ระบบกลับมาจัดการต่อได้ถูกชนิด (PR ของ Conversation)

สำหรับทีมพัฒนา จุดสำคัญคือข้อมูลประกอบระดับแอปยังควรอยู่ในแบบข้อมูลของตัวเอง DouweM ระบุว่า metadata ระดับรอบทำงานไม่ได้ถูกนำติดไปกับ Conversation เพราะอาจต้องคำนวณใหม่ในแต่ละรอบ (PR ของ Conversation) จึงอย่าเข้าใจว่าเก็บวัตถุนี้แล้วจะครอบคลุมข้อมูลธุรกิจทุกอย่างโดยอัตโนมัติ

จุดหักมุม: เก็บแชตได้ ไม่ได้แปลว่ากู้งานกลางทางได้

แต่ Conversation ไม่ได้รับประกันการกลับมาทำต่อจากจุดที่โปรแกรมล่มกลางคำสั่งครับ เอกสารแยกกรณีนี้ไปที่ durable execution หรือระบบรักษาการทำงานให้ฟื้นต่อได้หลังโปรเซสหยุด (Pydantic Docs)

การเก็บแชตที่จบรอบแล้ว กับการรักษางานที่กำลังทำอยู่ เป็นคนละปัญหา เอกสารยังแยกความจำข้ามบทสนทนาออกไปเป็นความสามารถชื่อ Memory ด้วย (Pydantic Docs) ดังนั้นคำว่า “บอตจำได้” ต้องถามต่อว่าจำภายในแชต จำข้ามแชต หรือกู้งานที่ค้างอยู่

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

UsageLimits คือเพดานการใช้งานที่โปรแกรมกำหนด DouweM ชี้ว่าถ้าส่งประวัติแชตโดยไม่ส่งยอดสะสม เพดานระดับบทสนทนาจะเริ่มนับจากศูนย์ทุกครั้ง (PR ของ Conversation) แปลว่าแม้หน้าจอดูเหมือนคุยเรื่องเดิม ระบบคุมการใช้งานอาจไม่ได้ตามข้อมูลไปด้วย บอตคุยต่อเก่ง แต่ฝ่ายบัญชีอาจไม่อยากให้เก่งแบบไร้เพดานครับ

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

ต้นทุนการเก็บข้อมูลก็ต้องคิดด้วย เอกสารระบุว่าการเขียน Conversation ทั้งชุดทุกครั้งทำง่าย แต่ข้อมูลที่เขียนจะโตตามบทสนทนา (Pydantic Docs) สำหรับแชตยาว ทีมอาจเก็บข้อความใหม่แยกตาราง แล้วรักษายอดสะสม รหัส และคำขอที่พักไว้ข้างกัน วิธีนี้ต้องประกอบข้อมูลกลับให้ครบก่อนคุยต่อ (Pydantic Docs)

นอกจาก Conversation บันทึกออกรุ่นยังมีการเปลี่ยนแปลงที่เกี่ยวข้องกับแอปจริงอีกหลายด้าน ต่อไปนี้เลือกเฉพาะรายการที่ประกาศไว้ ไม่ได้ถือว่าทุกแอปจะได้ประโยชน์เหมือนกัน (GitHub)

ตัวเก็บข้อมูลบน Postgres: เพิ่ม PostgresStepStore และ PostgresMediaStore เป็นส่วนเชื่อมฐานข้อมูล Postgres ที่ให้บริการบนเซิร์ฟเวอร์ สำหรับข้อความและสื่อ (บันทึกออกรุ่น) นี่เป็นทางเลือกด้านที่เก็บข้อมูล ไม่ใช่คำยืนยันว่าฐานข้อมูลของร้านถูกย้ายให้แล้ว
การใช้ข้อมูลคำสั่งเดิมซ้ำ: เพิ่มการตั้งค่า cache แบบรวมและความสามารถ Caching สำหรับ prompt caching ข้ามผู้ให้บริการ คำนี้หมายถึงการเก็บข้อมูลคำสั่งที่ใช้ซ้ำเพื่อใช้ในการเรียกโมเดลภายหลัง (GitHub) ประกาศไม่ได้บอกส่วนลดค่าใช้จ่ายของแอปคุณ จึงควรวัดผลก่อนนับเป็นงบที่ประหยัดได้
การเก็บเสียงสนทนา: เพิ่มขอบเขตเสียงที่เก็บไว้ผ่าน retain_audio_max_seconds โดยจำกัดคล้ายภาพที่เก็บไว้ (GitHub) ทีมที่มีบอตเสียงควรตรวจค่านี้ในระบบของตัวเอง มากกว่าสมมติว่าจะรักษาเสียงเดิมทั้งหมด

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

ฝั่งสนับสนุนที่ชัดคือ DouweM ผู้เสนอ PR ซึ่งอธิบายว่ารวมข้อมูลไว้ด้วยกันช่วยลดการหล่นหายตอนส่งต่อ (GitHub PR) เอกสาร Pydantic ก็แนะนำให้เก็บ Conversation แทนประวัติข้อความอย่างเดียว (Pydantic Docs) แต่ทั้งสองมาจากโครงการเดียวกัน จึงไม่ใช่ผลยืนยันจากผู้ใช้ธุรกิจอิสระ

ฝั่งทักท้วงมีชื่อชัดเจนเช่นกัน: ระบบรีวิว Macroscope เคยระบุว่าไม่ควรอนุมัติอัตโนมัติ เพราะการเปลี่ยนแปลงครอบคลุมการเก็บสถานะ งบใช้งาน งานพักรอ และการส่งต่อเสียง จึงควรมีคนตรวจ (ประวัติการรีวิวใน PR) นี่เป็นข้อทักท้วงต่อกระบวนการตรวจ ไม่ใช่หลักฐานว่ารุ่นที่ปล่อยมีช่องโหว่ และหน้าเดียวกันระบุว่า PR รวมเข้าระบบแล้ว (GitHub PR)

รายละเอียดใน PR มีทั้งฉบับระหว่างพัฒนาและคำอธิบายที่แก้แล้ว ช่วงแรกเคยรวม metadata แต่คำอธิบายภายหลังนำออก เพราะขอบเขตของข้อมูลนี้เป็นรายรอบ (GitHub PR) นี่เป็นการเปลี่ยนการออกแบบตามลำดับ ไม่ควรหยิบข้อความเก่ามาสรุปว่าข้อมูลนี้ยังติดไปกับ Conversation

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

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

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

เจ้าของร้านและคนทำงานทั่วไป — คำแนะนำสำหรับคุยกับผู้พัฒนา

ขอให้ทีมอธิบายว่าบันทึกประวัติแชตหรือ Conversation และเก็บที่ใด เอกสารเปิดให้ผู้พัฒนาเลือกฐานข้อมูลเอง จึงต้องถามจากระบบที่คุณใช้จริง (Pydantic Docs)
ขอทดสอบด้วยข้อมูลสมมติ: คุยให้จบรอบ รีสตาร์ตเซิร์ฟเวอร์ แล้วคุยต่อ ตรวจว่าประวัติ ยอดใช้งาน และงานรออนุมัติกลับมาครบ นี่เป็นการตรวจรูปแบบเก็บแล้วโหลดที่เอกสารเสนอ (Pydantic Docs)
ถามให้ครบว่าใครอ่านแชตได้ เก็บนานเท่าไร และลบอย่างไร คำตอบเป็นเรื่องออกแบบระบบของร้าน เพราะเฟรมเวิร์กไม่ได้เลือกนโยบายเก็บข้อมูลให้ทุกทีม (Pydantic Docs)

นักพัฒนาและทีม IT — คำแนะนำก่อนนำขึ้นระบบจริง

ตรวจ Python ก่อน แล้วตรึงเวอร์ชันแพ็กเกจให้ชัดเจนเพื่อทดสอบชุดเดียวกับที่จะใช้งานจริง รุ่นนี้มีข้อกำหนด Python ขั้นต่ำใหม่ จึงไม่ควรเปลี่ยนแบบข้ามการตรวจความเข้ากันได้ (บันทึกออกรุ่น)
ทดสอบบันทึกและอ่านกลับ รวมข้อมูลประกอบที่ต้องปกปิด และคำขอรออนุมัติ PR มีการแก้การส่งต่อค่าที่ใช้กรองข้อมูลตอนแปลงข้อความ จึงควรตรวจว่ากติกาของแอปยังทำงานตามต้องการ (GitHub PR)
ตรวจเพดานข้ามรอบและข้ามการโหลดกลับ อย่าส่ง conversation= พร้อมประวัติ ยอดใช้ หรือรหัสแยกซ้ำ เพราะ PR ระบุว่าระบบจะปฏิเสธการส่งอาร์กิวเมนต์ที่ขัดกัน (GitHub PR)
ถ้าระบบต้องกู้งานที่ล่มกลางคำสั่ง ให้ประเมิน durable execution แยกต่างหาก ส่วนทีมที่ต้องการให้ระบบช่วยบันทึกแต่ละขั้น มี StepPersistence ซึ่งเป็นความสามารถบันทึกจุดพักสำหรับทำต่อภายหลัง (Pydantic Docs)

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

ผมมองว่า…

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

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

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

ความจำของบอตควรถูกประเมินจากข้อมูลที่รักษาได้และขอบเขตที่กำหนดไว้ จับตาผลทดสอบการโหลด Conversation จากระบบของคุณ และการรักษายอดใช้งานหลังเปลี่ยนรอบตามกลไกที่เอกสารอธิบาย (Pydantic Docs) แหล่งที่อ่านยังไม่ให้กำหนดการเปลี่ยนแปลงครั้งถัดไป จึงไม่ควรตั้งวันคาดหวังเอง

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