Jev และชั้นการตัดสินใจใหม่สำหรับเอเยนต์ AI

ทำไมโมเดล System One จึงสามารถแยกการตัดสินใจที่เร็วจากการให้เหตุผลที่ช้า

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

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

สิ่งที่ Jev ทำจริง ๆ

TypeSafe เปิดตัว Jev ในเดือนกันยายน 2026, เป็นโมเดล System One รุ่นใหม่แรกของพวกเขา Jev ไม่ได้เขียนข้อความยาว ๆ แต่คุณจะส่งสถานะให้มัน (เช่นข้อความสนับสนุนและข้อมูลผู้ใช้) คุณยังส่งคำถามหนึ่งหรือหลายคำถามที่มีประเภทคำตอบที่กำหนดไว้ล่วงหน้า จากนั้น Jev จะตอบด้วยคำตอบที่มีประเภทและความน่าจะเป็น

ตามเอกสารอย่างเป็นทางการของบริษัท, มีสามพื้นฐานสำหรับการทำการตัดสินใจ:

• Choice ให้คุณเลือกจากตัวเลือกที่กำหนดไว้ล่วงหน้า.
• Score ให้คุณให้คะแนนบางอย่างตามเกณฑ์ที่เรียงลำดับ.
• Noul ประมาณความน่าจะเป็นที่คำกล่าวเป็นจริง.

คุณสามารถถามคำถามอิสระหลายคำถามเกี่ยวกับสถานะเดียวกันในคำขอเดียว.

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

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

การเปลี่ยนแปลงสถาปัตยกรรมสำคัญกว่ารุ่นโมเดล

ส่วนใหญ่ของการโต้แย้งเหล่านี้เปรียบเทียบโมเดลขนาดใหญ่กับขนาดเล็ก Jev เสนอขอบเขตทางเลือกบางอย่าง ขั้นตอนบางส่วนเกี่ยวข้องกับการสร้างภาษา ส่วนอื่นเป็นการตัดสินใจที่แคบซึ่งซอฟต์แวร์สามารถใช้ได้.

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

รูปที่ 1. เส้นทางการตัดสินใจที่มีขอบเขตรักษาเกณฑ์, สิทธิ์, และการขยายระดับไว้ในโค้ด.

มีความคล้ายคลึงกับการกำหนดเส้นทางโมเดล แต่มีความแตกต่างที่สำคัญ. RouteLLM ทำการตัดสินใจเกี่ยวกับการเลือกโมเดลภาษาใดจากสองโมเดล มันเลือกระหว่างโมเดลที่แข็งแกร่งกว่าและที่อ่อนกว่าเพื่อสมดุลคุณภาพและราคา โมเดล System One ผลิตการตัดสินใจที่มีขอบเขตซึ่งโค้ดสามารถใช้ได้โดยตรง การตัดสินใจเหล่านี้สามารถสนับสนุนการกำหนดเส้นทางโมเดลรวมถึงการตัดสินใจอื่น ๆ ภายในเอเยนต์.

ทำไมลูปเอเยนต์จึงเป็นการจับคู่ที่เหมาะสมโดยธรรมชาติ

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

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

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

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

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

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

Typed หมายถึงถูกต้องหรือไม่?

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

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

หลักฐานการทำงานยังอยู่ในระยะเริ่มต้น

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

การทดสอบเชิงปฏิบัติก่อนการนำไปใช้

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

สี่คำถามจะช่วยให้คุณประเมินว่ามันจะทำงานได้หรือไม่:

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

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

บทเรียนระยะยาวที่นี่

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

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

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