ทำไมเราถึงเริ่มทดสอบ Jev กับการตัดสินใจจริงในระดับองค์กรแล้ว

เรากำลังทดสอบ decision model ตัวใหม่ของ TypeSafe กับการตัดสินใจที่เกิดขึ้นในทุกบทสนทนาบน Maven ทั้งการจัดหมวดหมู่ทิกเก็ต, Intelligent Fields และการตรวจสอบคุณภาพ จากการทดสอบเบื้องต้นของเราเอง โมเดลนี้ทำงานจัดหมวดหมู่ได้เร็วกว่าวิธีที่เราใช้อยู่ประมาณ 12 เท่า และไม่ช้าลงเมื่อเราเพิ่มจำนวนการจัดหมวดหมู่ในคำขอเดียวกัน

คำขอของลูกค้า 1 รายการมีการตัดสินใจมากกว่า 1 อย่าง

ลองนึกถึงลูกค้าที่เขียนมาว่า “บิลของเราเพิ่มขึ้นเป็น 2 เท่า ครึ่งหนึ่งของทีมล็อกอินไม่ได้ และต้องแก้ให้เสร็จก่อนต่อสัญญาพรุ่งนี้”

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

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

ประเภทสุดท้ายนี้เองที่ Jev น่าสนใจ

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

Jev คล้าย classifier แต่มีความต่าง: ป้อนบริบทและคำถามที่มีขอบเขตชัดเจน แล้วโมเดลจะส่งกลับเป็นตัวเลือก คะแนน หรือความน่าจะเป็น โมเดลใหม่ของ TypeSafe AI ออกแบบมาเพื่อส่งกลับการตัดสินใจแบบมีโครงสร้างที่ซอฟต์แวร์นำไปใช้ได้ทันที สำหรับแพลตฟอร์มระดับองค์กรอย่าง Maven นี่คือโอกาสในการยกระดับการตัดสินใจจำนวนมากที่อยู่ระหว่างคำขอของลูกค้ากับการแก้ปัญหา

Jev ทำงานต่างจาก LLM อย่างไร

TypeSafe เรียก Jev ว่าโมเดลแบบ “System One” นักพัฒนาใส่บริบท คำถาม และคำตอบที่เป็นไปได้ แล้ว Jev จะส่งกลับตัวเลือก คะแนน และความน่าจะเป็น คำถามอิสระหลายข้อเกี่ยวกับบริบทเดียวกันประเมินแบบขนานได้ และโมเดลไม่สร้างข้อความอิสระแบบ LLM

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

LLM ทั่วไปสร้าง output ตาม schema ได้อยู่แล้ว จุดเด่นของ Jev คือเป็นโมเดลที่สร้างมาเพื่องานนี้โดยเฉพาะ มีการสร้าง output แบบขนาน และการเทรนที่ TypeSafe เรียกว่า Reinforcement Learning for Calibrated Decisions เป้าหมายคือทำให้ความไม่แน่นอนเป็นข้อมูลที่ซอฟต์แวร์ใช้ประโยชน์ได้ ควบคู่กับ latency และต้นทุนที่ต่ำลง

ผู้ใช้กลุ่มแรกยังรายงานว่าความเร็วดีขึ้นอย่างมากในงานบางประเภท ในการทดสอบของเราเอง Jev ตอบกลับเร็วกว่าวิธีที่เราใช้อยู่ประมาณ 12 เท่า นี่เป็นการทำต้นแบบในช่วงแรก ไม่ใช่ benchmark และยังไม่ได้ใช้งานใน production กับลูกค้าของเรา ส่วนรายอื่นก็รายงานตัวเลขใกล้เคียงกันในงานของตนเอง Guillermo Rauch จาก Vercel วัดได้ว่าเร็วขึ้นสูงสุด 18 เท่าที่เปอร์เซ็นไทล์ที่ 95 ในการตรวจสอบความปลอดภัยของคำสั่งที่เอเจนต์ของเขารัน และแม่นยำกว่าตัวตรวจสอบ GPT-5.6-Luna ที่ถูกแทนที่

Intelligent Fields คือจุดที่เหมาะกับการประเมิน

Maven เปิดตัว Intelligent Fields ในฤดูใบไม้ผลิปี 2026 ทีมกำหนดสิ่งที่ต้องการรู้เกี่ยวกับบทสนทนา เช่น กลุ่มผลิตภัณฑ์ sentiment ความต้องการขอคืนเงิน หรือสัญญาณการ escalate แล้วฟิลด์ที่ได้จะนำไปใช้กับการรายงาน การ routing และการตั้งค่าเอเจนต์

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

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

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

เราจึงไม่คาดว่า Intelligent Fields จะทำงานต่างไปเมื่อใช้ Jev แต่เราคาดว่าจะได้ประสิทธิภาพที่ดีขึ้นและลดต้นทุนได้

‍

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

‍

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

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

เราไม่นำโมเดลที่เพิ่งออกมาได้ 1 สัปดาห์ไปใช้กับลูกค้าองค์กร

ทุกอย่างข้างต้นเป็นการทดสอบและแนวคิดด้านการออกแบบ Jev ยังไม่ได้ทำงานใน workflow ของลูกค้ารายใด และโมเดลที่เพิ่งเปิดตัวไม่กี่วันจะไม่ถูกนำไปใช้จนกว่าจะผ่านกระบวนการประเมินแบบเดียวกับที่เราใช้กับทุกโมเดลใหม่ คุณดูได้ว่าเราทดสอบ GPT-Live-1 และโมเดลเสียงอื่นๆ อย่างไร เราวัดคุณภาพการตัดสินใจเทียบกับวิธีที่ใช้อยู่บนเคสตัวแทน รวมถึงเคสที่กำกวมและเคสที่ขาดบริบทสำคัญ จากนั้นเปรียบเทียบ latency ต้นทุนต่อผลลัพธ์ที่ยอมรับได้ และผลลัพธ์ต่อลูกค้า ก่อนที่จะมีอะไรไปแตะ routing ที่ใช้งานจริง

ทางเลือกโมเดลที่กว้างขึ้นสำหรับงานระดับองค์กร

Jev เพิ่มทางเลือกในการสร้างเอเจนต์ AI ระดับองค์กร การสนทนา การให้เหตุผล การจัดหมวดหมู่ และการตรวจสอบ ล้วนอาจต้องการโมเดลที่ต่างกัน

สำหรับ Maven โอกาสอยู่ที่การประเมิน Jev ในจุดที่ช่วยให้ฟีเจอร์อย่าง Intelligent Fields มีประสิทธิภาพมากขึ้น โดยยังคงบริบทและการควบคุมที่จำเป็นต่อการแก้ปัญหาของลูกค้าไว้ครบถ้วน

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

เราทำได้รวดเร็วเพราะ Charters, Segments และ Intelligent Fields กำหนดการตัดสินใจที่สำคัญไว้แล้ว การเปลี่ยนไปใช้เลเยอร์การตัดสินใจที่เร็วกว่าอยู่เบื้องหลังจึงเป็นแค่การปรับ configuration ที่เราทดสอบได้ภายในไม่กี่วัน ไม่ใช่การสร้างใหม่ที่ใช้เวลาหลายไตรมาส