ในภาพยนตร์ Men in Black II สายลับ J ไปหา K ที่ที่ทำการไปรษณีย์ซึ่งดูธรรมดาทั่วไป เขาเปิดเครื่องคัดแยกจดหมายและเผยให้เห็นเอเลี่ยนตัวหนึ่งอยู่ข้างใน กำลังคัดแยกจดหมายอย่างรวดเร็ว
มันเป็นฉากเล็ก ๆ ที่ดูไร้สาระ แต่ก็ให้มุมมองที่มีประโยชน์ในการคิดเรื่อง AI
ระหว่างขั้นตอนการรับข้อมูลเข้ามาและการนำข้อมูลนั้นไปทำอะไรสักอย่าง มักจะมีการตัดสินใจย่อย ๆ แทรกอยู่เสมอว่า: ข้อมูลนี้ควรไปอยู่ที่ไหน?
ถ้าตัดสินใจเรื่องนี้ได้ถูกต้องตั้งแต่ต้น ส่วนที่เหลือของระบบก็จะสามารถทำงานตามเส้นทางที่เหมาะสมได้ทันที
ผมคิดถึงเอเลี่ยนตัวน้อยตัวนั้นตลอดตอนที่พัฒนาซอฟต์แวร์ AI
แอปพลิเคชันหนึ่งอาจได้รับคำถามเรื่องการเรียกเก็บเงิน, รายงานบั๊ก, รูปถ่ายสินค้า และคำขอจองเดโม แต่ละอย่างต้องการการจัดการที่แตกต่างกัน แต่เรากลับลงเอยด้วยการขอให้โมเดลภาษาขนาดใหญ่ (LLM) ตัวเดิมตรวจสอบทุกอย่างแล้วคิดเอาเองว่าควรทำอะไรต่อ ซึ่งไม่ใช่วิธีที่มีประสิทธิภาพหรือคุ้มค่าเลย
นั่นคือเหตุผลที่ผมคิดว่าโมเดลเฉพาะทางจะมีบทบาทสำคัญมากขึ้นในอนาคตของ AI ตัวอย่างเช่น Jev ถูกสร้างมาเพื่อการตัดสินใจแบบมีโครงสร้างที่ซอฟต์แวร์สามารถนำไปดำเนินการต่อได้ หรือ Coinbase ที่ปรับแต่ง Qwen3.5-9B เพื่อใช้ตรวจจับการฉ้อโกงในบริการ Onramp โดยเฉพาะ แต่ละตัวโฟกัสกับงานที่กำหนดไว้ชัดเจน พร้อมผลลัพธ์ที่วัดผลได้
https://x.com/brian_armstrong/status/2109412046244913643
ผมกำลังสร้างชั้นคัดแยก (sorting layer) ขึ้นมา
คำขอที่คุ้นเคยสามารถส่งตรงไปยังเวิร์กโฟลว์ที่กำหนดไว้ได้เลย ส่วนคำขอที่ต้องใช้การคิดวิเคราะห์มากกว่าจะถูกส่งต่อไปยังอีกโมเดลหนึ่ง และคำขอที่ยังคลุมเครือจะถูกทำเครื่องหมายไว้เพื่อขอความชัดเจนหรือรอการตรวจสอบ
การประหยัดที่เกิดขึ้นมาจาก việcให้ทรัพยากรประมวลผลแก่แต่ละคำขอในปริมาณที่พอดี จากนั้นเราก็ต้องวัดว่าตัวคัดแยกนี้ตัดสินใจได้ถูกต้องมากพอที่จะคุ้มค่ากับการมีอยู่ของมันหรือไม่
จุดเริ่มต้นของเราคือ CludeMem เราพยายามตัดสินใจว่า AI ควรจำอะไร ควรดึงข้อมูลอะไรกลับมา และอะไรที่กำลังกินโทเคนไปโดยเปล่าประโยชน์ ความชอบถาวร คำสั่งชั่วคราว และคำถามที่ยังไม่ได้คำตอบ ล้วนสมควรได้รับการจัดการที่ต่างกัน ก่อนที่จะตัดสินใจเรื่องเหล่านั้นได้ เราจำเป็นต้องจัดหมวดหมู่ข้อมูลเสียก่อน
นั่นกลายเป็นแนวคิดเบื้องหลังชั้นการจัดหมวดหมู่ที่กว้างขึ้น ขั้นตอนเดียวกันนี้สามารถใช้ช่วยคัดแยกคำขอซัพพอร์ต จัดเส้นทางเอกสาร หรือเลือกว่าผู้เชี่ยวชาญคนไหนควรเป็นคนจัดการงานนั้นได้
GIF
เมื่อมีโมเดลเฉพาะทางเกิดขึ้นมากขึ้น แอปพลิเคชันจะต้องตัดสินใจว่าอินพุตแบบไหนที่สมควรได้รับความสนใจจากโมเดลใด และนั่นคือส่วนที่เรากำลังสร้าง: จัดหมวดหมู่สิ่งที่เข้ามา จัดการเคสที่คุ้นเคยในระบบท้องถิ่น แล้วส่งเคสที่ยากกว่าไปยังโมเดลหรือกระบวนการตรวจสอบที่เหมาะสม
พบกับ Clude Cat (Cat ย่อมาจาก categorisation หรือการจัดหมวดหมู่นั่นเอง 😉)
ก่อนที่จะบันทึกความทรงจำ ดึงเอกสาร เรียกใช้เครื่องมือ หรือสร้างคำตอบขึ้นมา มักจะต้องมีการตัดสินใจก่อนเสมอว่าเรากำลังจัดการกับข้อมูลประเภทไหน
การตัดสินใจเหล่านี้อยู่ทุกหนทุกแห่ง
ลองนึกภาพว่ามีคนเขียนข้อความถึงบริษัทซอฟต์แวร์ว่า:
“ฉันจะดาวน์โหลดใบแจ้งหนี้ได้ที่ไหน?”
AI agent สามารถอ่านข้อความ ตรวจสอบเครื่องมือที่มี พิจารณาเจตนาของลูกค้า และตัดสินใจค้นหาใบแจ้งหนี้ได้
แต่เวิร์กโฟลว์ที่ตรงไปตรงมากว่าอาจเป็นแบบนี้:
ข้อความ → คำขอเอกสารการเรียกเก็บเงิน → การยืนยันตัวตนบัญชี → การดึงใบแจ้งหนี้
โมเดลภาษาก็ยังสามารถเป็นคนเขียนตอบกลับได้ แต่การตัดสินใจจัดเส้นทางในตอนแรกอาจจัดการได้ในระบบท้องถิ่น
ทีนี้ลองเปลี่ยนข้อความดู:
“ฉันถูกเรียกเก็บเงินซ้ำสองครั้ง บัญชีถูกล็อก และฉันต้องการยกเลิก”
การส่งข้อความนี้เข้าไปในเวิร์กโฟลว์ใบแจ้งหนี้เพียงอย่างเดียวอย่างมั่นใจ จะยิ่งสร้างงานเพิ่ม เพราะมีปัญหาหลายอย่างที่ต้องแก้ไข และการตอบสนองที่ถูกต้องอาจต้องอาศัยการสอบถามเพิ่มเติมหรือต้องใช้คนจริง ๆ
ตัวคัดแยกต้องมีสิทธิ์ที่จะบอกว่า “ฉันไม่สามารถจัดหมวดหมู่นี้ได้อย่างน่าเชื่อถือ”
นั่นเป็นส่วนสำคัญของผลิตภัณฑ์ ระบบที่ส่งคำขอไปยังปลายทางผิดอย่างมั่นใจ อาจทำลายข้อได้เปรียบด้านความเร็วของตัวเองไปหมดด้วยงานที่ต้องมานั่งแก้ข้อผิดพลาดเหล่านั้น
สำหรับลูกค้า ประโยชน์ที่ตั้งใจไว้คือการรอน้อยลงและไม่ต้องพูดซ้ำซาก
สำหรับนักพัฒนา มันคือการตัดสินใจที่ชัดเจนซึ่งพวกเขาสามารถตรวจสอบ ทดสอบ และเปลี่ยนแปลงได้ พวกเขาสามารถเห็นหมวดหมู่ที่ถูกเลือก เวอร์ชันของโมเดล เวลาที่ใช้ประมวลผล และดูได้ว่าระบบปฏิเสธที่จะตัดสินใจหรือไม่
ภายใต้การทำงาน โค้ดส่วนข้อความจะเริ่มจากโมเดลพรีเทรนขนาดเล็กที่เรียกว่า encoder
มันจะแปลงข้อความให้เป็นชุดตัวเลขที่แสดงถึงแง่มุมต่าง ๆ ของความหมาย นักพัฒนาเรียกตัวแทนค่านี้ว่า embedding
“ใบแจ้งหนี้ของฉันอยู่ไหน?” กับ “ฉันต้องการสำเนาบิลของฉัน” ใช้คำที่ต่างกัน แต่ตัวแทนค่าเชิงตัวเลขของทั้งสองประโยคอาจคล้ายกันมากพอที่ระบบจะรับรู้ได้ว่าเป็นคำขอประเภทเดียวกัน
ชั้นการจัดหมวดหมู่จะใช้ตัวแทนค่าเหล่านี้ในการให้คะแนนหมวดหมู่ที่นักพัฒนากำหนดไว้
เราได้ทดลองใช้สองวิธี วิธีแรกคือการเปรียบเทียบข้อความที่เข้ามากับตัวอย่างของแต่ละหมวดหมู่ อีกวิธีคือการเรียนรู้ขอบเขตระหว่างหมวดหมู่จากตัวอย่างที่มีการติดป้ายกำกับไว้แล้ว
ในแนวทางแบบ fitted เราจะตรึง encoder ไว้คงที่แล้วเทรนชั้นตัดสินใจขนาดเล็กที่อยู่ด้านบนแทน เราไม่จำเป็นต้องเทรน foundation model ใหม่ทุกครั้งสำหรับแต่ละแอปพลิเคชัน
นักพัฒนายังคงต้องนิยามว่าหมวดหมู่เหล่านั้นหมายถึงอะไร และเชื่อมโยงพวกมันเข้ากับแอ็กชันที่เป็นประโยชน์ ตัวจำแนกหมวดหมู่ไม่สามารถคิดค้นแผนกของบริษัท นโยบายการคืนเงิน หรือสิทธิ์การเข้าถึงบัญชีขึ้นมาเองได้
นอกจากนี้ยังต้องมีนโยบายการยอมรับ (acceptance policy) ด้วย
หมวดหมู่ที่ได้คะแนนสูงสุดก็อาจจะยังไม่ตรงกับความต้องการ สองหมวดหมู่อาจมีคะแนนใกล้เคียงกันจนแทบเท่ากัน หรือคำขอที่ไม่คุ้นเคยอาจดูเหมือนสิ่งที่คุ้นเคย
คะแนนในระบบท้องถิ่นปัจจุบันของเรายังไม่ใช่ความน่าจะเป็นที่ผ่านการปรับเทียบ คะแนน 0.92 ไม่ได้แปลว่า “มีโอกาสถูกต้อง 92%” โดยอัตโนมัติ
เราต้องทดสอบว่าจะเกิดอะไรขึ้นเมื่อใช้คะแนนเหล่านั้นเป็นตัวควบคุมการตัดสินใจ
ดังนั้นผลลัพธ์จึงต้องแยกแยะระหว่างหมวดหมู่ที่ยอมรับได้ คำขอที่ต้องรอการตรวจสอบ และความล้มเหลวทางเทคนิค รวมถึงกรณี timeout การยกเลิก และข้อผิดพลาดของโมเดล ก็ต้องมีการจัดการที่คาดเดาได้เช่นกัน
ทั้งหมดนี้คืองานวิศวกรรมที่อยู่รอบตัวคัดแยก ซึ่งเป็นตัวกำหนดว่าแอปพลิเคชันอื่นจะสามารถนำผลลัพธ์ไปใช้ได้อย่างปลอดภัยและสม่ำเสมอหรือไม่
เราทำการทดลองกับคำขอด้านการธนาคาร 770 รายการ เพื่อดูว่าแนวทางนี้จะช่วยลดภาระงานของ generative model ได้หรือไม่
การตั้งค่าแบบแรกส่งทุกคำขอไปยังโมเดล Qwen2.5 7B ที่รันอยู่ในระบบท้องถิ่นเพื่อจัดหมวดหมู่
แบบที่สองใช้ตัวจำแนกหมวดหมู่ในระบบท้องถิ่นของเราก่อน แล้วค่อยส่งคำขอที่ยังตัดสินไม่ได้ไปให้ Qwen
ผลลัพธ์ที่ได้คือ:
- จำนวนการเรียกใช้ Qwen ลดลงจาก 770 เหลือ 227
- การจัดหมวดหมู่ที่ถูกต้องเพิ่มขึ้นจาก 535 เป็น 642
- ความแม่นยำโดยรวมของอินพุตทั้งหมดเพิ่มขึ้นจาก 69.5% เป็น 83.4%
- ผลรวมเวลาที่วัดได้ลดลงจาก 299.7 วินาที เหลือ 87.7 วินาที
ขั้นตอนในระบบท้องถิ่นช่วยให้ไม่ต้องเรียกใช้ Qwen ถึง 543 ครั้ง คิดเป็นการลดลง 70.5%
ระบบแคชยังคงเปิดใช้งานอยู่ และเราทดสอบวิธีแบบตรงก่อนวิธีแบบผสม ตัวเลขเวลาที่แสดงไม่นับรวมการตั้งค่าและการวอร์มอัพ เราวัดเฉพาะเวลาในการจัดหมวดหมู่ โดยไม่ได้สร้างคำตอบสุดท้ายให้ลูกค้าหรือจ่ายเงินให้ผู้ให้บริการโมเดล
ตัวเลขเหล่านี้ใช้อธิบายการตั้งค่านี้เท่านั้น ไม่ได้เป็นการพิสูจน์ว่ามันดีกว่า LLM ทุกตัว หรือรับประกันว่าจะช่วยลูกค้าประหยัดเงินได้จริง
ในการทดลองแยกต่างหากในเวลาต่อมา เราได้ทดสอบตัวจำแนกหมวดหมู่แบบ fitted ในระบบท้องถิ่นกับเจตนา (intent) ด้านการเดินทางและสถานที่ทำงาน 24 รูปแบบ
จากคำขอ 720 รายการ มันยอมรับและจัดการในระบบท้องถิ่นได้ 688 รายการ ในจำนวนนั้นถูกต้อง 681 รายการ และผิด 7 รายการ ส่วนอีก 32 รายการถูกปล่อยไว้รอการตรวจสอบ
นั่นทำให้เราได้ค่าวัดสองแบบ:
- Coverage (ความครอบคลุม): จัดการในระบบท้องถิ่นได้ถึง 95.6% ของคำขอทั้งหมด
- Accepted precision (ความแม่นยำของรายการที่ยอมรับ): ตัดสินใจถูกต้อง 99.0% จากคำขอที่มันยอมรับ
ทั้งสองค่าต้องนำมาพิจารณาร่วมกัน เพราะตัวจำแนกหมวดหมู่อาจทำ precision ได้สูงลิ่วเพียงแค่ยอมรับคำขอที่ง่าย ๆ ไม่กี่รายการก็ได้
เรายังทดสอบกับอินพุตที่ไม่คุ้นเคย 100,000 รายการที่ควรอยู่นอกเหนือหมวดหมู่ที่รองรับ และพบว่ามันมีความแม่นยำมากกว่า 94%
การรู้ว่าระบบ "ไม่รู้" อะไร ยังคงเป็นส่วนหนึ่งของงานที่ต้องทำ
เรื่องความเร็วก็ต้องใส่ใจไม่แพ้กัน ในการทดสอบ CPU แบบ warm แยกต่างหาก ตัวจำแนกหมวดหมู่ด้านการธนาคารใช้เวลาประมาณ 1.8 มิลลิวินาทีต่อคำขอ (ค่ามัธยฐาน) บนชิป M4 Max ซึ่งรวมถึงการทำ tokenisation, embedding และการให้คะแนนแล้ว
แต่ไม่รวมเวลาดาวน์โหลดและเริ่มการทำงานของโมเดล นี่คือการวัดเวลาในการจัดหมวดหมู่ ไม่ใช่เวลาที่ใช้แก้ปัญหาของลูกค้าทั้งกระบวนการ และไม่ได้การันตีว่าจะได้ประสิทธิภาพระดับเดียวกันบนมือถือหรือแล็ปท็อปทั่วไป
Jev เข้ามาเกี่ยวข้องในเรื่องนี้เพราะมันถูกออกแบบมาเพื่อจัดการกับการตัดสินใจในลักษณะเดียวกันอยู่แล้ว
TypeSafe อธิบายว่า Jev คือโมเดลสำหรับการตัดสินแบบมีขอบเขต (bounded judgments) ซึ่งรวมถึงการเลือกจากตัวเลือกที่มี และการจัดเส้นทางคำขอไปยังโค้ดปกติ โมเดลเฉพาะทาง หรือมนุษย์ \เอกสาร intent-routing ของ Jev\
บทบาทที่ผมมองเห็นสำหรับ Jev คือเส้นทางการยกระดับ (escalation path) แบบทางเลือก สำหรับคำขอที่ตัวจำแนกหมวดหมู่ในระบบท้องถิ่นไม่สามารถจัดการได้อย่างน่าเชื่อถือ
สถาปัตยกรรมที่เรากำลังมุ่งหน้าไปนั้นเรียบง่ายมาก:
คำขอที่เข้ามา → การจัดหมวดหมู่ในระบบท้องถิ่น → คำขอที่คุ้นเคยจะไปตามเส้นทางที่กำหนดไว้ ส่วนคำขอที่ไม่แน่ใจจะถูกส่งต่อไปยัง Jev, โมเดลอื่น หรือให้คนตรวจสอบ
หากไม่มี Jev ขั้นตอนการจัดหมวดหมู่ในระบบท้องถิ่นก็สามารถส่งคำขอที่ยังตัดสินไม่ได้กลับไปยัง LLM ที่มีอยู่เดิม ขั้นตอนการขอความชัดเจน หรือกระบวนการตรวจสอบของแอปพลิเคชันนั้นได้
นักพัฒนาจะเป็นผู้ควบคุมหมวดหมู่ เกณฑ์การยอมรับ และ fallback พวกเขาสามารถนำตัวจำแนกหมวดหมู่ในระบบท้องถิ่นเข้าไปใส่ในเวิร์กโฟลว์ที่มีอยู่ แล้ววัดผลว่ามันสามารถรับหน้าที่ตัดสินใจแทนในส่วนไหนได้บ้าง
ปัจจุบันการเชื่อมต่อกับ Jev ทำงานในโหมด shadow โดยเปรียบเทียบการตัดสินใจในหัวข้อกว้าง ๆ 5 หัวข้อโดยไม่ไปเปลี่ยนแปลงพฤติกรรมของแอปพลิเคชัน ขั้นตอนต่อไปคือการทดสอบว่าการยกระดับแบบเจาะจงจะช่วยปรับปรุงเวิร์กโฟลว์ทั้งหมดให้ดีขึ้นหรือไม่ ผลลัพธ์ของ Qwen ข้างต้นไม่ใช่การทดสอบ benchmark ของ Jev
นั่นคือสิ่งที่เราต้องวัด: การเรียกใช้โมเดลโดยไม่จำเป็นที่น้อยลง, การจัดการคำขอที่คุ้นเคยได้เร็วขึ้น, และมีเส้นทางที่ชัดเจนสำหรับเคสที่ต้องการความใส่ใจมากขึ้น
เราได้เริ่มขยายแนวทางเดียวกันนี้ไปสู่รูปภาพแล้ว
ลองนึกภาพธุรกิจหนึ่งที่รับรูปใบเสร็จ ภาพหน้าจอแสดง error และรูปถ่ายสินค้าเข้ามา แต่ละอย่างต้องการเส้นทางการประมวลผลที่ต่างกัน
ใบเสร็จอาจถูกส่งไปเข้าระบบดึงข้อมูลใบเสร็จ ภาพหน้าจออาจเข้าสู่เวิร์กโฟลว์ฝ่ายซัพพอร์ต รูปถ่ายสินค้าอาจเข้าสู่เวิร์กโฟลว์จัดทำแคตตาล็อก ส่วนภาพที่ไม่แน่ใจก็ส่งไปให้คนตรวจสอบ
ตัวจำแนกหมวดหมู่ทำหน้าที่เลือกปลายทาง ส่วนการอ่านยอดซื้อ การวินิจฉัย error และการระบุรายละเอียดสินค้า ยังคงเป็นงานที่แยกออกจากกัน
การใช้งานกับรูปภาพในขั้นทดลองของเราใช้ CLIP encoder แบบพรีเทรนเพื่อสร้างตัวแทนค่าเชิงตัวเลขของรูปภาพ
ตัววิจัยแบบ fitted สามารถจำแนกรูปถ่ายสินค้าอาหารได้ถูกต้อง 19 จาก 20 รูปในการทดสอบวินิจฉัยขนาดเล็ก และยังส่งภาพใบถั่วทั้ง 30 ภาพไปรอการตรวจสอบทั้งหมด
ข้อผิดพลาดที่เกิดขึ้นคือแผงข้อมูลโภชนาการและบาร์โค้ดบนขวดถูกจำแนกเป็นใบเสร็จ
คุณจะเห็นปัญหาทันที ทั้งสองอย่างมีข้อความหนาแน่น ตัวเลข และเลย์เอาต์แบบสี่เหลี่ยมเหมือนกัน เราจึงต้องมีตัวอย่างที่สอนให้ระบบรู้ถึงขอบเขตที่แอปพลิเคชันของเราให้ความสำคัญ
กลุ่มตัวอย่างนั้นแคบเกินไปที่จะใช้อ้างอิงในระดับโปรดักชัน ป้ายกำกับได้มาจากชุดข้อมูลโดยตรง ไม่ได้ผ่านการตัดสินอย่างเป็นอิสระ และไม่มีตัวอย่างใบเสร็จหรือภาพหน้าจอใหม่ ๆ รวมอยู่ในการทดสอบ เดโมสาธารณะใช้ baseline แยกต่างหาก ดังนั้นผลลัพธ์ของตัวแบบ fitted จึงไม่ควรนำไปนับรวมกับเดโมนั้น
การประมวลผลรูปภาพยังมีน้ำหนักมากกว่าการจัดหมวดหมู่ข้อความด้วย เวลาประมวลผลมัธยฐานแบบ warm อยู่ที่ประมาณ 36 มิลลิวินาทีใน Node และ 197 มิลลิวินาทีใน Chromium บนชิป M4 Max โดยเบราว์เซอร์ต้องโหลด asset ของโมเดลประมาณ 85 MiB ก่อน บวกกับ runtime ของมัน
การรันในระบบท้องถิ่นก็มีต้นทุน ขนาดไฟล์ดาวน์โหลด หน่วยความจำ เวลาเริ่มทำงาน และประสิทธิภาพของอุปกรณ์ ล้วนต้องนำมาประเมินด้วย
ผลิตภัณฑ์ที่ผมวาดภาพไว้จะเข้าไปอยู่ในแอปพลิเคชันที่มีอยู่แล้ว โดยทำหน้าที่ตัดสินใจว่าจะเกิดอะไรขึ้นต่อไป
นักพัฒนาเป็นผู้กำหนดหมวดหมู่ จัดเตรียมตัวอย่างที่เป็นตัวแทน เชื่อมต่อปลายทาง และเลือกว่าควรทำอย่างไรเมื่อการจัดหมวดหมู่ยังไม่แน่นอน
การติดตั้งครั้งแรกควรเป็นแค่การสังเกตเวิร์กโฟลว์ปัจจุบันโดยไม่ไปเปลี่ยนแปลงผลลัพธ์ จากนั้นเราจึงเปรียบเทียบการตัดสินใจที่เสนอแนะกับผลลัพธ์ที่ตรวจสอบแล้ว ก่อนที่จะปล่อยให้ตัวจำแนกหมวดหมู่ควบคุมการจัดเส้นทางจริง
เราต้องตรวจสอบข้อผิดพลาดที่ระบบยอมรับอย่างละเอียดเท่ากับคำขอที่ระบบปฏิเสธ ไม่เช่นนั้นการตัดสินใจที่ผิดอย่างมั่นใจอาจถูกซ่อนไว้ใต้คะแนนที่ดูน่าเชื่อถือ
การเทรน การปรับเทียบ และการทดสอบ ต่างก็ต้องใช้ข้อมูลที่แยกจากกัน การเทรนคือการสอนหมวดหมู่ การปรับเทียบคือการเลือกกฎการยอมรับ และการทดสอบที่ถูกป้องกันไว้คือการตรวจสอบผลลัพธ์ที่ถูกแช่แข็งแล้ว
เมื่อข้อผิดพลาดจากการทดสอบถูกนำไปมีอิทธิพลต่อโมเดลเวอร์ชันถัดไป ตัวอย่างนั้นจะกลายเป็นข้อมูลสำหรับการพัฒนาทันที และการประเมินครั้งต่อไปจะต้องใช้ชุดทดสอบใหม่
เอเลี่ยนตัวน้อยในเครื่องคัดแยกจดหมายช่วยให้ผู้คนจินตนาการภาพของงานนี้ออก แต่การสร้างเวอร์ชันที่ใช้ได้จริงหมายถึงการค้นหาให้เจอว่าอินพุตแบบไหนที่มันจัดการได้ เมื่อไหร่ที่มันควรขอความช่วยเหลือ และข้อผิดพลาดของมันมีต้นทุนเท่าไหร่
ก้าวต่อไปคือการสร้างเวิร์กโฟลว์ที่เป็นตัวแทนการใช้งานจริง มีป้ายกำกับที่เป็นอิสระ และบันทึกผลลัพธ์ทุกอย่างไว้ เราต้องวัดว่ามีคำขอกี่รายการที่ผ่านเส้นทางในระบบท้องถิ่น กี่รายการที่ไปถึงโมเดลอื่น กี่รายการที่ผิดพลาด และแอปพลิเคชันโดยรวมเร็วขึ้นหรือถูกลงจริงหรือไม่เมื่อหักลบกับข้อผิดพลาดเหล่านั้น
ถึงเวลาขยายสเกลและเติมสเตียรอยด์ให้โมเดลท้องถิ่นตัวนี้กันแล้ว
