LangChain4j 1.21.0 ให้ AI คัดงานก่อนตอบ บิลจะลดจริงไหม

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

รุ่นเบตาที่ประกาศคู่กันคือ 1.21.0-beta31 แปลว่าในประกาศมีทั้งรุ่นหลักและรุ่นเบตา โดยฟีเจอร์ตัดสินใจยังถูกระบุว่าเป็นการทดลอง GitHub ระบุไว้ชัด ส่วน InfoQ นำข่าวนี้มาอยู่ในสรุปสัปดาห์เริ่มวันที่ 28 กันยายน แปลว่าเป็นกรอบเวลาของข่าวรวม ไม่ใช่หลักฐานระบุวันปล่อยรุ่นแบบเจาะจง

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

LangChain4j เป็นไลบรารี หรือชุดเครื่องมือสำเร็จรูปที่ทีมเขียนโปรแกรม Java ใช้สร้างแอปซึ่งทำงานกับโมเดลภาษา ส่วน LLM คือโมเดลภาษาขนาดใหญ่ที่รับข้อความแล้วสร้างคำตอบได้ ฟีเจอร์ใหม่ชื่อ decision models เปลี่ยนงานบางประเภทให้เป็นการตอบคำถามตามรูปแบบที่กำหนด เช่น ใช่หรือไม่ เลือกหมวด หรือประเมินระดับ ตาม ประกาศโครงการ

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

อีกทางเข้าใช้งานคือ Decision Services ซึ่งให้ทีมประกาศคำถามเป็นเมธอด หรือคำสั่งย่อย ใน Java interface ที่ทำหน้าที่ระบุข้อตกลงของบริการ แล้วไลบรารีเชื่อมคำถามกับโมเดลให้ตาม คู่มือ Decision Services แต่ทั้งหมดนี้ยังเป็น API ทดลอง หรือจุดเชื่อมต่อโปรแกรมที่อาจเปลี่ยนในรุ่นถัดไป ตาม release notes

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

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

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

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

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

ทำงานยังไง

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

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

คำถามแบบใช่หรือไม่เหมาะกับ “ลูกค้าขอเงินคืนหรือเปล่า” แบบเลือกหมวดเหมาะกับ “ฝ่ายไหนควรรับเรื่อง” และแบบระดับเหมาะกับ “เรื่องนี้เร่งด่วนระดับใด” เอกสารแนะนำให้เขียนเกณฑ์จากสิ่งที่สังเกตได้ในข้อความ มากกว่าการเดาเจตนา พร้อมเพิ่มตัวเลือก “อื่น ๆ” เมื่อข้อความอาจไม่เข้าหมวด ตาม คู่มือทางการ ไม่เช่นนั้นโมเดลต้องเลือกหมวดที่มี แม้ไม่มีหมวดไหนเหมาะ

สำหรับนักพัฒนา boolean คือค่าจริงหรือเท็จ ส่วน enum คือชุดชื่อทางเลือกที่กำหนดไว้ และ record คือข้อมูลหลายช่องที่รวมเป็นชุดเดียว Decision Services แปลงคำตอบกลับเป็นชนิดเหล่านี้ได้ ส่วน Choice<E> เก็บทั้งตัวเลือกและค่าความน่าจะเป็น ตาม คู่มือ Decision Services ถ้าต้องการหลายคำถามพร้อมกัน แต่ละช่องของชุดข้อมูลสามารถเป็นคำถามในการเรียกเดียว

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

จุดหักมุม: ตอบสั้นลง แต่ไม่ได้แน่นอนขึ้น

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

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

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

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

ส่วน re-ranking คือการจัดอันดับเอกสารที่ค้นมาใหม่ ให้ชิ้นที่ช่วยตอบคำถามอยู่ก่อน โดยมี DecisionScoringModel เป็นตัวช่วย นอกจากนี้ยังมีการเลือกเครื่องมือและ guardrails หรือขั้นตรวจข้อความเข้าและคำตอบออก ตาม release notes สิ่งเหล่านี้เป็นการเลือกสิ่งที่เกี่ยวข้อง ไม่ได้ให้สิทธิ์เข้าถึงข้อมูลหรือเครื่องมือแทนกฎของแอป

ข้อควรระวังเรื่องบิลอยู่ในรายละเอียดของ คู่มือ Decision Models: ตัวช่วยแต่ละตัวเรียกโมเดลตัดสินใจเพิ่ม และปริมาณ token ไม่รวมในยอดของคำตอบแชต Token คือหน่วยย่อยที่ระบบนับจากเนื้อหาที่โมเดลประมวลผล การติดตามจึงต้องเก็บจากตัวรับเหตุการณ์ของ decision model ด้วย มิฉะนั้นการดูเฉพาะยอดฝั่งแชตจะไม่เห็นงานคัดกรองครบ

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

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

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

เสียงสนับสนุนมาจากโครงการ LangChain4j ซึ่งระบุใน GitHub ว่าโมเดลแบบนี้เหมาะกับงานคัดหมวด ส่งต่อ ตรวจผ่าน และให้คะแนน โดยเน้นความเร็วกับต้นทุน ส่วน InfoQ โดย Michael Redlich รายงานการเพิ่มฟีเจอร์ทดลองและองค์ประกอบสำคัญ แต่ไม่ได้เสนอผลทดสอบอิสระว่าประหยัดเท่าไร จึงไม่ควรอ่านข่าวรายงานรุ่นเป็นการรับรองผลทางธุรกิจ

ข้อทักท้วงที่มีหลักฐานมาจากเอกสาร LangChain4j เอง คู่มือ Decision Models เตือนว่า guardrails ยังใช้ความน่าจะเป็น และไม่ควรเป็นมาตรการความปลอดภัยเพียงอย่างเดียว ข้อความจากผู้ใช้หรือเอกสารที่ค้นมาอาจชักจูงการตัดสินใจได้ แหล่งชุดนี้ไม่มีองค์กรภายนอกออกมาคัดค้านโดยตรง จึงไม่มีเหตุผลให้แต่งคู่ขัดแย้งขึ้นมาครับ

รุ่นในข่าวกับตัวอย่างติดตั้งไม่ตรงกัน: release notes ประกาศ 1.21.0 แปลว่าเป็นรุ่นที่บทความนี้รายงาน แต่ตัวอย่าง dependency หรือรายการไลบรารีที่โปรแกรมต้องใช้ ใน คู่มือ Decision Services ระบุ 1.22.0 แปลว่าตัวอย่างนั้นอ้างรุ่นใหม่กว่าข่าวนี้ ยังสรุปจากแหล่งที่ให้มาไม่ได้ว่ารายละเอียดทุกบรรทัดในคู่มือใช้กับรุ่นข่าวได้เหมือนกันทั้งหมด

ขอบเขตผู้ให้บริการต้องอ่านให้แคบพอ: ประกาศรุ่น ระบุการเชื่อมต่อแรกเป็น TypeSafe และบอกว่าใช้กับเซิร์ฟเวอร์ที่พูดรูปแบบรับส่ง /v1/systemone เดียวกันได้ เช่น OpenRouter ข้อความนี้ไม่ได้ยืนยันว่าโมเดลทุกตัวหรือบริการทุกชนิดบน OpenRouter ใช้ได้เหมือนกัน จึงต้องตรวจการรองรับของปลายทางที่ทีมจะเลือก

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

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

คนทั่วไปและเจ้าของร้านที่ใช้บริการของทีม IT — ทำตามได้เลย

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

ทีม IT และคนดูแลงบ — ทำตามได้เลย

1. บันทึกตัวเลือก ค่าความน่าจะเป็น ชื่อโมเดลที่ตอบ และปริมาณ token สำหรับประเมินผล ใช้ตัวรับเหตุการณ์ของ decision model ให้เห็นต้นทุนส่วนนี้ แต่ไม่เปิดบันทึกข้อมูลเข้าออกที่มีข้อมูลส่วนตัวในระบบจริง ตาม คำแนะนำด้านการติดตามและข้อมูล
2. ตั้งเกณฑ์ส่งต่อจากตัวอย่างของทีม และให้คนรับช่วงเมื่อความน่าจะเป็นของหมวดที่นำอยู่ใกล้กัน คู่มือแนะนำดู margin() หรือส่วนต่างระหว่างตัวเลือกที่มีโอกาสสูงสุดกับตัวรอง และปรับเกณฑ์ใหม่เมื่อเปลี่ยนโมเดล ตาม เอกสาร Decision Models
3. กำหนด fallback หรือทางทำงานสำรองเมื่อโมเดลตอบไม่ได้ให้ตรงกับความเสี่ยง คู่มือระบุว่าตัวเลือกเครื่องมือส่งเครื่องมือทั้งหมดต่อเป็นค่าเริ่มต้นเมื่อโมเดลล้มเหลว แต่ guardrails ทำให้คำขอล้มเหลว ทีมต้องตรวจพฤติกรรมขององค์ประกอบที่ใช้ ไม่เหมารวมว่ามันหยุดทุกกรณี ตาม ตารางพฤติกรรมเมื่อเกิดข้อผิดพลาด

นักพัฒนา Java — ทำตามได้เลย

1. เริ่มจาก Decision Services เมื่อตัวเลือกตายตัว และใช้ DecisionModel โดยตรงเมื่อตัวเลือกหรือคำถามเพิ่งรู้ตอนโปรแกรมทำงาน นี่คือการแบ่งหน้าที่ที่ คู่มือ Decision Models และ คู่มือ Decision Services แนะนำ ตรวจ API ของรุ่นที่ติดตั้งก่อนใช้ตัวอย่างจากคู่มือ
2. ตรึงรุ่นไลบรารีที่ทดสอบไว้ และใช้ชื่อรุ่นโมเดลแบบคงที่แทนชื่อที่ชี้รุ่นล่าสุดอัตโนมัติ พร้อมเก็บชื่อโมเดลที่ตอบจริง เอกสารเตือนว่าชื่อแบบล่าสุดเปลี่ยนปลายทางได้ และเปลี่ยนทั้งคำตอบกับความหมายเชิงใช้งานของเกณฑ์ ตาม หัวข้อ Model versions
3. ทดสอบกรณีไม่มีหมวดเหมาะ ไม่มีค่าความน่าจะเป็น และโมเดลปฏิเสธคำถาม การปฏิเสธในงานตรวจความปลอดภัยควรถูกถือว่าไม่ผ่าน ไม่ใช่ตีความเป็นคำตอบว่าไม่มีปัญหา ตาม คู่มือ Decision Models และใช้ผลความน่าจะเป็นที่เก็บแล้วลองเกณฑ์หลายแบบได้ โดยไม่ต้องเรียกโมเดลใหม่ทุกครั้ง ตาม คู่มือ Decision Services

ผมมองว่า…

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

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

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

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

ถ้าจะทดลองแยกอีเมล “ขอคืนเงิน / ร้องเรียน / สอบถาม” ในที่ทำงานของคุณ หมวดไหนควรให้คนตรวจทุกครั้งก่อนส่งต่อ?

Recap

• เกิดอะไรขึ้น: LangChain4j เพิ่ม decision models และ Decision Services สำหรับตอบคำถามตามชนิดข้อมูล พร้อมองค์ประกอบช่วยส่งต่อและตรวจงาน 1
• เลขรุ่นที่จำ: 1.21.0 แปลว่าเป็นรุ่นหลักในข่าวนี้ แต่ฟีเจอร์ใหม่ยังเป็น @Experimental และอาจเปลี่ยน 1
• ใครทักท้วง: เอกสาร LangChain4j เองเตือนเรื่องความน่าจะเป็น ความปลอดภัย และต้นทุนเรียกเพิ่ม ส่วน InfoQ รายงานข่าวรุ่น ไม่ได้ยืนยันผลประหยัด 2 3
• ข้อมูลต่างกัน: ตัวอย่างติดตั้งในคู่มืออ้างรุ่นใหม่กว่าข่าว ต้องตรวจรุ่นที่ใช้ก่อนนำตัวอย่างไปต่อ 4
• ยังไม่รู้: ไม่มีตัวเลขประหยัด ราคาเงินบาท ผลทดสอบภาษาไทย หรือวันยืนยัน API คงที่ในแหล่งชุดนี้
• กระทบคุณ: งานบริการอาจส่งต่อได้เหมาะขึ้น แต่ทีมต้องวัดเวลาจบเรื่อง ต้นทุนรวม และจำนวนเรื่องที่คนต้องแก้
• สิ่งที่ต้องจับตา: การเปลี่ยน API และผลทดลองกับข้อความจริงของทีม พร้อมเกณฑ์ที่ปรับใหม่เมื่อเปลี่ยนโมเดล 3