เอเจนต์แปลงข้อความเป็นคำค้นหาของเราลดเวลาจาก 45 วินาทีบนโมเดลระดับแนวหน้าเหลือ 2 วินาทีบน GLM 5.3 Flash โดยมีความแม่นยำเท่าเดิมที่ต้นทุน 1/20
งาน AI ล่าสุดของเราที่ Conversion ส่วนใหญ่มุ่งเน้นไปที่ระบบวิเคราะห์การตลาดทั่วไป
ทีมระบบอัตโนมัติทางการตลาดทำงานหลากหลายข้ามระบบต่างๆ เช่น การค้นคว้าบัญชี การสร้างกลุ่มเป้าหมาย การวางแผนแคมเปญ การเขียนเนื้อหา และการดำเนินการกับข้อมูลประสิทธิภาพ เราได้สร้างเอเจนต์ที่สามารถให้เหตุผลข้ามขั้นตอนการทำงานเหล่านั้นและใช้เครื่องมือเดียวกับที่นักการตลาดที่มีทักษะใช้
ระบบเหล่านั้นได้รับประโยชน์จากโมเดลอเนกประสงค์ที่มีความสามารถสูง งานเป็นแบบปลายเปิด และการใช้วิจารณญาณที่ดีมักสำคัญกว่าการทำงานให้เสร็จอย่างรวดเร็ว
แต่เราก็มีฟีเจอร์ AI ขนาดเล็กและเฉพาะทางที่ค้างอยู่จำนวนหนึ่ง หนึ่งในนั้นคือตัวกรองภาษาธรรมชาติ: ให้ผู้ใช้อธิบายกลุ่มเป้าหมายเป็นภาษาอังกฤษธรรมดา และเปลี่ยนคำอธิบายนั้นเป็นตัวกรองที่พวกเขาสามารถตรวจสอบและแก้ไขในตัวสร้างคำสั่งที่มีอยู่ของ Conversion (ใน Conversion ตัวกรองเรียกว่าคำสั่ง)
ในตอนแรก สิ่งนี้ดูเหมือนเป็นงานสร้างโครงสร้างที่ตรงไปตรงมา ให้ฟิลด์ที่มีอยู่แก่โมเดล อธิบายรูปแบบเอาต์พุต และขอให้สร้าง JSON กลับกลายเป็นว่ายากกว่าที่คิดมาก
คำสั่งแบบผสมที่สร้างขึ้นในเวลาไม่ถึง 5 วินาทีโดยใช้ GLM 5.3 Flash
ลองดูตัวอย่างต่อไปนี้:
ค้นหาผู้ติดต่อที่ส่งแบบฟอร์มสาธิตอย่างน้อยหนึ่งครั้งใน 30 วันที่ผ่านมา และทำงานที่บริษัทซอฟต์แวร์ที่มีโอกาสเปิดมูลค่ามากกว่า 50,000 ดอลลาร์
สิ่งนี้ต้องการให้ระบบ:
- ค้นหาแบบฟอร์มเฉพาะที่ผู้ใช้หมายถึงจาก "แบบฟอร์มสาธิต"
- กำหนดว่าฟิลด์ใดแสดงถึงอุตสาหกรรมของบริษัท
- เรียนรู้ว่าพื้นที่ทำงานนั้นแทน "ซอฟต์แวร์" อย่างไร ซึ่งหมายถึงการดูค่าที่จัดเก็บจริงในฟิลด์นั้นแทนการเดา
- เดินทางจากผู้ติดต่อไปยังบริษัทของเขา และจากนั้นไปยังโอกาสของบริษัทนั้น
- ตรวจสอบให้แน่ใจว่า "เปิด" และ "มากกว่า 50,000 ดอลลาร์" ใช้กับโอกาสเดียวกัน
- ใช้หน้าต่างเหตุการณ์สัมพัทธ์
นอกจากนี้ยังต้องทำทั้งหมดนี้อย่างรวดเร็วพอที่จะให้ความรู้สึกเหมือนอินเทอร์เฟซตัวกรอง ไม่ใช่เอเจนต์วิจัย
สิ่งที่ดูเหมือนงานปรับแต่งพรอมต์เล็กๆ กลายเป็นปัญหาการแปลงข้อความเป็นคำค้นหาที่มีข้อจำกัด การแก้ปัญหานี้ต้องใช้เอเจนต์ที่ใช้เครื่องมือ การแสดงระดับกลาง (IR) คอมไพเลอร์ที่กำหนดได้ และเกณฑ์มาตรฐานเชิงความหมาย
เราทดสอบแปดโมเดลผ่านเกณฑ์มาตรฐานที่ได้ชื่อว่า Statement Bench รวมถึง Claude Opus 5, Kimi K3, GLM 5.3 Flash และ Gemini 3.8 Flash ที่เพิ่งปล่อยเมื่อเช้านี้ ผลลัพธ์อยู่ด้านล่าง
การให้เครื่องมือแก่เอเจนต์
ข้อมูลส่วนใหญ่ที่จำเป็นในการตอบคำขอข้างต้นนั้นเฉพาะเจาะจงกับสภาพแวดล้อมของลูกค้า พื้นที่ทำงานเดียวสามารถเก็บค่าฟิลด์ในประวัติได้หลายร้อยล้านค่า พร้อมกับทรัพย์สินและออบเจกต์ของมัน ด้วยเหตุผลที่ชัดเจน เราไม่สามารถใส่ทั้งหมดนั้นลงในพรอมต์เดียว
การตัดสินใจทางสถาปัตยกรรมที่มีประโยชน์ครั้งแรกของเราคือการหยุดมองปัญหานี้เป็นการสร้างโครงสร้างทั่วไป แต่โมเดลจะได้รับชุดเครื่องมือขนาดเล็กแทน มันสามารถค้นหาฟิลด์ ตรวจสอบค่าประวัติ และแก้ไขทรัพย์สินเฉพาะธุรกิจ เช่น แบบฟอร์ม แคมเปญ อีเมล และกลุ่มเป้าหมาย มันใช้เครื่องมือเหล่านั้นเมื่อคำขอต้องการเท่านั้น
โครงสร้างพื้นฐานการค้นหาส่วนใหญ่มาจากงาน Global Search ล่าสุดของเรา ซึ่งให้การค้นหาข้อความและความหมายเหนือเรกคอร์ดทั้งหมดใน Conversion เราวางแผนที่จะแชร์เพิ่มเติมเกี่ยวกับเรื่องนี้เร็วๆ นี้!
โฟลว์พื้นฐานมีลักษณะดังนี้:
1คำขอภาษาธรรมชาติ2 |3 v4 เอเจนต์ที่ใช้เครื่องมือ <-----------------+5 / | \ |6ฟิลด์ ทรัพย์สิน ความสัมพันธ์ | การปฏิเสธพร้อมเหตุผล7 \ | / |8 v |9 IR ที่มีข้อจำกัด |10 | |11 v |12 ตัวตรวจสอบและคอมไพเลอร์ ---------------+13 |14 v15 คำสั่งที่ใช้งานจริง
สิ่งนี้ทำให้บริบทเริ่มต้นมีขนาดเล็ก นอกจากนี้ยังทำให้ความล้มเหลวเข้าใจได้ง่ายขึ้นมาก หากคำสั่งผิด เราสามารถระบุได้ว่าเอเจนต์พบทรัพย์สินผิด เลือกฟิลด์ผิด เข้าใจความสัมพันธ์ผิด แสดงแนวคิดที่ถูกต้องไม่ถูกต้อง หรือมีบั๊กในคอมไพเลอร์ ความแตกต่างนี้มีความสำคัญในภายหลังสำหรับลูปการประเมินของเรา
การสร้างภาษาที่เล็กลง
การใช้เครื่องมือแก้ปัญหาบริบทได้ แต่มันไม่ได้แก้ปัญหาความหน่วง
บทเรียนหนึ่งจากข้อเสนอแนะในช่วงแรก: ผู้ใช้ยอมรับความหน่วงในอินเทอร์เฟซที่สร้างขึ้นเพื่อวัตถุประสงค์เฉพาะได้น้อยกว่าในแชทมาก
สิ่งนี้ชี้ให้เห็นถึงความขัดแย้งในวงกว้าง เรากำหนดความคาดหวังด้านความหน่วงตามความยากของงานที่เรารู้สึก ไม่ใช่ความยากสำหรับระบบ การเขียนเนื้อหาดูเหมือนยากเพราะเราเห็นงานที่ต้องทำ การอธิบายตัวกรองดูเหมือนง่ายเพราะจิตใจของเราแก้ไขบริบท เอนทิตี ความสัมพันธ์ และเจตนาอย่างเงียบๆ สำหรับโมเดล การสร้างสมมติฐานที่ซ่อนอยู่เหล่านั้นขึ้นมาใหม่คืองาน ยิ่งผู้ใช้รับรู้工作量น้อยเท่าไหร่ พวกเขาก็ยิ่งให้เวลาระบบน้อยลงเท่านั้น
จากข้อเสนอแนะในช่วงแรก เรากำหนดเป้าหมายสองประการ: ความแม่นยำมากกว่า 95 เปอร์เซ็นต์ และเวลาตอบสนองประมาณ 5 วินาทีสำหรับคำถามทั่วไป
Conversion มีภาษาคำค้นหาภายในที่แสดงออกได้ ในการทดสอบช่วงแรกของเรา การใช้รูปแบบการผลิตโดยตรง มีเพียงโมเดลที่ใหญ่ที่สุด เช่น Claude Opus เท่านั้นที่สามารถสร้างได้อย่างน่าเชื่อถือ แม้แต่คำสั่งง่ายๆ ก็ใช้เวลาประมาณ 45 วินาที
ตัวสร้างคำสั่งแบบภาพแสดงเฉพาะส่วนย่อยของภาษาเต็ม เราได้สร้างการแสดงระดับกลางที่เล็กลงและเป็นมิตรกับเอเจนต์สำหรับส่วนย่อยนั้น โมเดลที่เล็กลงสามารถสร้างได้โดยใช้โทเค็นน้อยลง ในขณะที่คอมไพเลอร์ที่กำหนดได้จัดการรูปแบบการผลิตเต็มรูปแบบ
พิจารณาคำสั่ง:
ตำแหน่งงานมีคำว่า "Director"
คำสั่งการผลิตดั้งเดิมมีลักษณะดังนี้:
1{2 "type": "LOGICAL",3 "version": 1,4 "logical": {5 "operator": "OR",6 "operands": [7 {8 "type": "LOGICAL",9 "version": 1,10 "logical": {11 "operator": "AND",12 "operands": [13 {14 "type": "VARIABLE",15 "version": 1,16 "variable": {17 "variableSchemaId": "550e8400-e29b-41d4-a716-446655440000",18 "where": {19 "type": "LOGICAL",20 "version": 1,21 "logical": {22 "operator": "AND",23 "operands": [24 {25 "type": "LOGICAL",26 "version": 1,27 "logical": {28 "operator": "CONTAINS",29 "operands": [30 {31 "type": "ATTRIBUTE",32 "version": 1,33 "attribute": {34 "name": "value"35 }36 },37 {38 "type": "CONSTANT",39 "version": 1,40 "constant": {41 "value": "Director"42 }43 }44 ]45 }46 }47 ]48 }49 }50 }51 }52 ]53 }54 }55 ]56 }57}
การแสดงที่โมเดลเห็นของตัวกรองเดียวกันคือ:
1{2 "field": "550e8400-e29b-41d4-a716-446655440000",3 "op": "contains",4 "value": "Director"5}
IR ผ่านการพัฒนามาหลายรุ่นแล้ว และรุ่นล่าสุดถูกกำหนดโดยการดูโมเดลขนาดเล็กล้มเหลวในรุ่นก่อนหน้า การปรับปรุงครั้งใหญ่ครั้งหนึ่งคือการแนะนำความหมายของเรกคอร์ดเดียวกันที่ดีขึ้น (สิ่งที่การตรวจสอบสคีมาไม่สามารถจับได้):
1{2 "related": "OPPORTUNITY",3 "all": [4 { "field": "<uuid ของขั้นตอน>", "op": "equals", "value": "Closed Won" },5 { "field": "<uuid ของจำนวนเงิน>", "op": "gt", "value": 100000 }6 ]7}
การแยกระหว่างโมเดลและโค้ดนี้ทำให้เรามีคุณสมบัติที่มีประโยชน์หลายประการ:
- คำสั่งที่ไม่รองรับนั้นแสดงออกได้ยาก
- ความหมายความสัมพันธ์ของเรกคอร์ดเดียวกันนั้นมองเห็นได้
- การอ้างอิงฟิลด์และความสัมพันธ์สามารถตรวจสอบได้
- คอมไพเลอร์สามารถทดสอบได้โดยอิสระจากโมเดล
- คำสั่งที่สร้างขึ้นยังคงแก้ไขได้ใน UI ที่มีอยู่
IR ช่วยลดงานของโมเดลลงในที่สุด: เอเจนต์แก้ไขเจตนาของผู้ใช้และสร้างแผนที่มีข้อจำกัด โค้ดจัดการรูปแบบการผลิต
การสร้างเกณฑ์มาตรฐานเชิงความหมาย
เอาต์พุตสามารถถูกต้องสมบูรณ์และยังผิดได้ ลองดูคำขอนี้:
ผู้ติดต่อที่บริษัทที่มีโอกาสชนะมูลค่ามากกว่า 100,000 ดอลลาร์
ผู้ติดต่อเป็นของบริษัท และบริษัทสามารถมีโอกาสได้หลายรายการ การจับคู่ตัวกรองนี้หมายถึงการเดินทางผ่านความสัมพันธ์ (ผู้ติดต่อไปยังบริษัท บริษัทไปยังโอกาส) และตรวจสอบสองเงื่อนไขระหว่างทาง: ดีลชนะ และดีลมีมูลค่ามากกว่า 100,000 ดอลลาร์
ความยากคือเงื่อนไขเหล่านั้นต้องเป็นจริงสำหรับโอกาส เดียวกัน หากตรวจสอบแยกกัน บริษัทที่มีดีลชนะมูลค่า 20,000 ดอลลาร์และดีลเปิดมูลค่า 150,000 ดอลลาร์จะทำให้ทั้งสองเงื่อนไขเป็นจริง: หนึ่งเงื่อนไขตรงกับแต่ละรายการ การตรวจสอบสคีมาจะไม่มีทางจับสิ่งนี้ได้
เมื่อตัวอย่างสองสามตัวอย่างเช่นนี้ผ่านไป การแก้ไขพรอมต์เสี่ยงที่จะทำให้ตัวอย่างเหล่านั้นถดถอย เราต้องการวิธีตรวจสอบความหมาย ไม่ใช่แค่ความถูกต้อง และตรวจสอบทุกครั้งที่มีการเปลี่ยนแปลงบางอย่าง
เราสร้าง Statement Bench รอบพฤติกรรมของผลิตภัณฑ์ ซึ่งได้มาจากรูปแบบกลุ่มเป้าหมายที่ไม่ระบุชื่อที่ลูกค้าของเราเคยสร้างไว้ก่อนหน้านี้ ชุดทดสอบตอนนี้มี 100 กรณีในสิบห้าหมวดหมู่ เช่น เงื่อนไขฟิลด์ธรรมดา เหตุการณ์ หน้าต่างเวลาสัมพัทธ์และปฏิทิน ความสัมพันธ์ และคำถามแบบผสม
แต่ละกรณีทำงานกับแซนด์บ็อกซ์พื้นที่ทำงานที่สมจริง เอเจนต์ได้รับข้อมูลและเครื่องมือเดียวกับที่ได้รับในการผลิต
ผู้ประเมินตรวจสอบหลายชั้น:
- เอเจนต์ส่งคืนคำสั่งหรือไม่
- IR เป็นไปตามสคีมาหรือไม่
- ฟิลด์และความสัมพันธ์ที่อ้างอิงมีอยู่หรือไม่
- คำสั่งสามารถคอมไพล์และผ่านการตรวจสอบการผลิตได้หรือไม่
- มันแสดงถึงความหมายที่ร้องขอหรือไม่
- ต้องใช้ขั้นตอนโมเดล การเรียกเครื่องมือ โทเค็น และการส่งที่ถูกปฏิเสธกี่ครั้ง
ข้อที่ห้าเป็นข้อที่น่าสนใจที่สุด เนื่องจากความถูกต้องไม่ได้รับประกันความเท่าเทียมทางความหมาย
การตรวจสอบเชิงความหมายอ่านคำสั่งที่คอมไพล์แล้ว โดยยืนยันสิ่งต่างๆ เช่น "เงื่อนไขโอกาสหนึ่งเงื่อนไขที่มีทั้งขั้นตอนและจำนวนเงิน" "เหตุการณ์อีเมลที่ประเภทคือคลิก ไม่ใช่เปิด" หรือ "เงื่อนไขเว็บินาร์แทนที่จะเป็นเงื่อนไขแคมเปญที่กำหนดเอง"
การรันลูปการปรับให้เหมาะสมที่ขับเคลื่อนด้วยการประเมิน
เกณฑ์มาตรฐานเปลี่ยนวิธีที่เราสามารถทำงานกับฟีเจอร์ต่อไปได้ แทนที่จะขอให้เอเจนต์เขียนโค้ด "ปรับปรุงพรอมต์" หรือ "ใช้ IR ใหม่" เราสามารถให้คำจำกัดความที่ดำเนินการได้ของการปรับปรุงแก่พวกเขา
ลูปมีลักษณะดังนี้:
- รันเกณฑ์มาตรฐาน
- จัดกลุ่มความล้มเหลวตามสาเหตุพื้นฐาน
- ตรวจสอบเส้นทางเครื่องมือของเอเจนต์และ IR ที่ส่ง
- เปลี่ยนพรอมต์ เครื่องมือ ตัวตรวจสอบ หรือคอมไพเลอร์
- รันเกณฑ์มาตรฐานทั้งหมดอีกครั้ง
- เก็บการเปลี่ยนแปลงเฉพาะเมื่อปรับปรุงระบบโดยไม่ทำให้เกิดการถดถอย
เอเจนต์เขียนโค้ดสามารถใช้เกณฑ์มาตรฐานเพื่อเปรียบเทียบโมเดล ทดลองกับ IR ปรับปรุงคำอธิบายเครื่องมือ และปรับแต่งพรอมต์ได้โดยอัตโนมัติ การรันชุดทดสอบทั้งหมดหลังการเปลี่ยนแปลงทุกครั้งยังป้องกันไม่ให้เรา overfit กับความล้มเหลวแต่ละรายการ และเรากันอีก 50 กรณีเพื่อยืนยันสิ่งนั้น
การเปลี่ยนแปลงบางอย่างปรับปรุงผลลัพธ์มากที่สุด:
- ย้ายเส้นทาง ประเภท และโครงสร้างไปยังคอมไพเลอร์ IR แรกของเราทำให้โมเดลเขียนความสัมพันธ์ทั้งหมดอย่างชัดเจน: ผู้ติดต่อไปยังบริษัท บริษัทไปยังโอกาส เมทาดาทาของฟิลด์บอกเป็นนัยถึงเส้นทางนั้นอยู่แล้ว ดังนั้นคอมไพเลอร์จึงอนุมานมันได้ในตอนนี้ เราทำเช่นเดียวกันกับวันที่ การแปลงประเภท ตำแหน่งการปฏิเสธ และการจัดกลุ่ม การย้ายกฎไปยังคอมไพเลอร์ทำให้ IR ง่ายขึ้นและลดความล้มเหลวของสคีมา
- ปฏิเสธพร้อมคำอธิบายและวิธีแก้ไข ทุกการปฏิเสธของสคีมาและคอมไพเลอร์บอกว่าควรเขียนอะไรแทน (เมื่อมี): "ไม่สามารถปฏิเสธ gt ในฟิลด์นี้ได้ ใช้ lte", "คัดลอก id จาก campaign_list" โมเดลขนาดเล็ก converged ในการลองหนึ่งหรือสองครั้ง และโมเดลการผลิตถูกปฏิเสธในคำขอสองสามครั้งต่อร้อย
- จัดโครงสร้างพรอมต์สำหรับโมเดลขนาดเล็ก การจัดระเบียบพรอมต์ใหม่ไม่ได้เปลี่ยนความแม่นยำ แต่ลดจำนวนการลองใหม่ลงครึ่งหนึ่ง ซึ่งช่วยปรับปรุงความหน่วงโดยตรง สิ่งนี้ได้รับแรงบันดาลใจจาก แนวทางปฏิบัติที่ดีที่สุดในการเขียนพรอมต์ ของ Anthropic
- ใช้ตัวอย่างแทนคำอธิบาย ตัวอย่างเพิ่มเติมสองตัวอย่างในการอ้างอิงรูปแบบของเราแก้ไขข้อผิดพลาดประเภทหนึ่งที่ย่อหน้าคำอธิบายไม่สามารถแก้ไขได้ ลดการส่งที่ถูกปฏิเสธลงประมาณครึ่งหนึ่ง
- ให้บริบทที่สมบูรณ์หรือไม่ให้เลย โมเดลเข้าถึงสิ่งที่อยู่ในบริบทก่อนที่จะเรียกเครื่องมือ เมื่อบริบทรวมชุดฟิลด์บางส่วนหรือไม่มีป้ายกำกับ โมเดลใช้ฟิลด์ที่ใกล้ที่สุดแทนการค้นหา ทำให้เกิดคำสั่งที่ไม่ถูกต้องเชิงความหมาย โดยการลดบริบทบางส่วนเพื่อสนับสนุนการเรียกเครื่องมือ เราเพิ่มอัตราการสร้างและลดโทเค็นอินพุตลงหนึ่งในห้า
การกำหนดค่าการผลิตสุดท้าย GLM 5.3 Flash ทำครบทั้ง 100 กรณีเกณฑ์มาตรฐานด้วยค่ามัธยฐานความหน่วง 2.3 วินาที และเปอร์เซ็นไทล์ที่ 95 ที่ 7.1 วินาที และ 97 จาก 100 ถูกต้องเชิงความหมาย เมื่อเทียบกับแนวทางรูปแบบการผลิตดั้งเดิม ตัวกรองง่ายๆ ย้ายจากประมาณ 45 วินาทีเหลือมากกว่าหนึ่งวินาทีเล็กน้อยที่ต้นทุน 1/20
การเปรียบเทียบโมเดลบน Statement Bench
เกณฑ์มาตรฐานยังให้วิธีเปรียบเทียบโมเดลในงานจริงแก่เราด้วย
ในวันที่ 2 กันยายน 2026 เรารัน 100 กรณีเดียวกันในแปดโมเดล แต่ละโมเดลได้รับพรอมต์ เครื่องมือ IR คอมไพเลอร์ และหมดเวลาคำขอ 30 วินาทีเดียวกัน
การกำหนดเส้นทางผู้ให้บริการ การแคชพรอมต์ และโหลดการอนุมานชั่วคราวล้วนส่งผลต่อความหน่วง
โมเดล
การสร้างที่ถูกต้อง
ถูกต้องเชิงความหมาย
P50 ความหน่วง
P95 ความหน่วง
อ่านแคช
การเรียกเครื่องมือ
การส่งที่ถูกปฏิเสธ
ประมาณการต้นทุนต่อ 1,000 คำขอ
Claude Opus 5
100/100 (100%)
100/100 (100%)
3.16s
8.53s
91.1%
162
0
$27.51
GLM 5.2
100/100 (100%)
100/100 (100%)
4.38s
13.02s
93.5%
201
5
$14.94
Kimi K3
100/100 (100%)
100/100 (100%)
5.17s
11.84s
34.3%
157
0
$48.51
GLM 5.3 Flash
100/100 (100%)
97/100 (97%)
2.34s
7.07s
92.8%
163
2
$1.33
DeepSeek V4 Pro
96/100 (96%)
96/96 (100%)
5.53s
24.31s
47.8%
172
1
$12.00
Gemini 3.7 Flash
77/100 (77%)
77/77 (100%)
15.14s
30.01s
26.5%
228
1
$18.24
Gemini 3.8 Flash
76/100 (76%)
76/76 (100%)
14.29s
30.01s
35.4%
266
1
$27.44
DeepSeek V4 Flash
56/100 (56%)
55/56 (98%)
6.79s
30.00s
41.5%
100
1
$0.56
ต้นทุนโดยประมาณต่อ 1,000 คำขอที่พยายาม โดยใช้โทเค็นอินพุต อินพุตที่แคช และเอาต์พุตที่สังเกตได้ในอัตราที่ไม่ใช่โปรโมชันที่ระบุไว้ของผู้ให้บริการแต่ละรายในวันที่ 2 กันยายน 2026 อินพุตที่แคชจะถูกเรียกเก็บในอัตราการอ่านแคชที่เผยแพร่เมื่อผู้ให้บริการเผยแพร่ และในอัตราอินพุตเต็มรูปแบบเป็นอย่างอื่น
รูปที่ 1. ความถูกต้องเทียบกับต้นทุน GLM 5.3 Flash ถึง 97 เปอร์เซ็นต์ที่ประมาณหนึ่งในยี่สิบของต้นทุนของ Claude Opus 5
รูปที่ 2. การกระจายความหน่วง ค่ามัธยฐานและเปอร์เซ็นไทล์ที่ 95 เรียงตาม P95
ข้อค้นพบสองสามข้อโดดเด่น
ทั้งขนาดโมเดลและราคาไม่ได้ทำนายความหน่วง โมเดลที่เร็วที่สุดคือโมเดลที่เล็กที่สุดและถูกที่สุด โมเดลที่เร็วเป็นอันดับสองคือโมเดลที่ใหญ่ที่สุดและแพงที่สุด
ความล้มเหลวเปลี่ยนจากคำตอบที่ผิดเป็นคำตอบที่ช้า หกในแปดโมเดลถูกต้องเชิงความหมายในทุกคำสั่งที่พวกเขาทำเสร็จ ความแตกต่างระหว่างพวกเขาเกือบทั้งหมดอยู่ในจำนวนคำขอที่เสร็จสิ้นภายในเวลาที่กำหนด ในการทำซ้ำช่วงแรกของ IR และพรอมต์ โมเดลขนาดเล็กส่วนใหญ่ล้มเหลวในเกณฑ์มาตรฐานที่ขั้นตอนการสร้างด้วยความแม่นยำเชิงความหมาย <50%
โทเค็นการให้เหตุผลมีน้ำหนักมากกว่าการเรียกเครื่องมือ Gemini 3.8 Flash ใช้ 180,000 จาก 192,000 โทเค็นเอาต์พุตในการให้เหตุผลและเรียกเครื่องมือ 266 ครั้ง Claude Opus 5 ใช้ 813 โทเค็นในการให้เหตุผล เรียกเครื่องมือ 162 ครั้ง และทำทุกกรณีเสร็จ ความพยายาม Global Search ของเราลดการค้นหาเครื่องมือแต่ละครั้งให้อยู่ในช่วงมิลลิวินาที ดังนั้นต้นทุนที่เหลือคือเทิร์นของโมเดลระหว่างการเรียกเหล่านั้น
ข้อสรุป
โมเดลเก่งในการแก้ไขความคลุมเครือ โค้ดเก่งในการบังคับใช้ความแม่นยำ และความล้มเหลวในช่วงแรกของเราส่วนใหญ่มาจากการขอให้โมเดลทำทั้งสองอย่าง การสร้างเอเจนต์นี้เป็นงานตัดสินใจว่าสองสิ่งนี้ควรเป็นเจ้าของส่วนใด เราคาดว่าสิ่งเดียวกันนี้เป็นจริงสำหรับ text-to-SQL และอินเทอร์เฟซภาษาธรรมชาติอื่นๆ ส่วนใหญ่
หากคุณสนใจปัญหาเหล่านี้ โปรดติดต่อเรา! เรากำลังรับสมัครงาน
