วิธีลด AOI False Call: สาเหตุที่แท้จริงและแนวทางแก้ไข

ในการลด false call ของ AOI ให้แก้ไขสาเหตุตามลำดับนี้: ยืนยันว่า golden sample เป็นชิ้นงานที่ดีจริง, ปรับระบบไฟส่องสว่างและเลนส์ออปติกให้กลับมาอยู่ในสเปก, เคลียร์ component library ให้ถูกต้อง จากนั้นปรับจูน threshold ใหม่ทีละวินโดว์เทียบกับเกณฑ์ IPC-A-610 การขยายขีดจำกัดแบบครอบคลุมทั้งระบบไม่ใช่การแก้ปัญหา แต่มันคือการแลก false call กับการเกิด escape และหาก false call พุ่งกลับขึ้นมาทุกครั้งหลังเปลี่ยนรอบการผลิต (changeover) หรือเปลี่ยนล็อตชิ้นส่วนใหม่ กำแพงที่คุณกำลังชนอยู่ก็คือตัวอัลกอริทึมแบบ rule-based เอง ซึ่งเป็นปัญหาเชิงโครงสร้างของระบบ ไม่ใช่ปัญหาเรื่องการปรับจูน

false call (หรือที่เรียกว่า false positive หรือ overkill) คือการที่ AOI แจ้งเตือนบอร์ดที่ดีว่าเป็นของเสีย การเตือนแต่ละครั้งทำให้ต้องส่งบอร์ดไปให้คนตรวจสอบซ้ำ เครื่องที่ส่งสัญญาณเตือนหลอก 50 ครั้งต่อกะทำให้สิ้นเปลืองแรงงาน ทั้งยังทำให้โอเปอเรเตอร์เริ่มหมดความเชื่อถือในตัวเครื่อง ซึ่งนั่นคือส่วนที่มีต้นทุนแพงที่สุด บทความนี้ครอบคลุมถึงที่มาของ false call ต้นทุนที่แท้จริง สิ่งที่คุณสามารถแก้ไขได้จริงบน AOI ทั่วไป และสิ่งที่จะเปลี่ยนไปเมื่อเปลี่ยนตรรกะการตรวจสอบมาใช้ AI แทนระบบกฎเกณฑ์

อะไรคือสาเหตุของ false call ใน AOI?

false call ใน AOI เกิดจากกฎการตรวจสอบที่ไม่สามารถรองรับความแปรปรวนตามธรรมชาติของกระบวนการผลิตได้ แหล่งที่มาทั่วไปคือ threshold ที่ตั้งไว้แคบกว่าเกณฑ์การยอมรับจริง, การดริฟต์ของแสง, การเปลี่ยนล็อตชิ้นส่วน และการโก่งงอของบอร์ด (board warpage) ยิ่งไปกว่านั้น ชิ้นส่วนบางประเภทยังทำให้อัลกอริทึมแบบตรวจจับสีล้มเหลวโดยสิ้นเชิง เช่น ตัวถังชิ้นส่วนที่มีสีเดียวกับ laminate ของ PCB รวมถึงมาร์กเกอร์และตัวอักษรที่หนาแน่นบนพื้นผิวของชิป inductor และ crystal oscillator ชิ้นส่วนเหล่านี้ต้องการการจัดการเฉพาะทาง เพราะไม่ว่าจะปรับ threshold เท่าใดก็แก้ปัญหาไม่ได้

การพูดถึง false call ส่วนใหญ่มักหยุดอยู่แค่ "threshold แคบเกินไป" ซึ่งก็จริง แต่เป็นเพียงแค่ยอดภูเขาน้ำแข็ง รายการสาเหตุทั้งหมดมีดังนี้:

• threshold แคบเกินไป (Over-tight thresholds) โปรแกรมเมอร์มักตั้งค่าเผื่อปลอดภัยไว้ก่อน เพราะหากชิ้นงานเสียหลุดรอด (escape) ลูกค้าจะโทรมาต่อว่าทันที ขณะที่ false call เพียงแค่สร้างความรำคาญที่สถานี verify หากใช้วิธีคิดแบบนี้กับวินโดว์ชิ้นส่วนหลายร้อยจุด โปรแกรมจะเอียงไปทางการแจ้งเตือนเกินจริง (overkill) ตั้งแต่บอร์ดยังไม่เริ่มรัน
• การดริฟต์ของระบบออปติกและไฟส่องสว่าง หลอดไฟเสื่อมสภาพตามอายุ เลนส์จับฝุ่น แสงแวดล้อมเปลี่ยนไปตามกะการทำงาน การเปรียบเทียบพิกเซลและสีจะมองว่าสิ่งเหล่านี้คือความเปลี่ยนแปลงที่เกิดขึ้นบนบอร์ดทั้งหมด
• ความแปรปรวนของชิ้นส่วนระหว่างล็อต ม้วนรีลชิ้นส่วนจากซัพพลายเออร์รายที่สองมาพร้อมกับผิวตัวถังที่ต่างไปเล็กน้อยหรือฟอนต์มาร์กเกอร์แบบใหม่ ตัวชิ้นส่วนสมบูรณ์ดี แต่การจับคู่รูปแบบ (pattern match) กลับล้มเหลว
• การโก่งงอของบอร์ด (Board warpage) บอร์ดที่โก่งตัวจะทำให้ตำแหน่งชิ้นส่วนขยับไปอยู่ที่ขอบวินโดว์ ส่งผลให้ระบบแจ้งเตือนว่าชิ้นส่วนเบี่ยงเบน (offset) หรือไม่มีชิ้นส่วน (presence check) ผิดพลาด
• ชิ้นส่วนที่มีสีเดียวกับบอร์ด เมื่อตัวถังชิ้นส่วนมีสีเหมือนกับ laminate ของ PCB การตรวจจับด้วยระบบสี RGB อาจล้มเหลวทันที เนื่องจากอัลกอริทึมไม่สามารถแยกชิ้นส่วนออกจากบอร์ดได้ โบรชัวร์ของ DaoAI ได้บันทึกรูปแบบความล้มเหลวนี้พร้อมวิธีแก้ไขไว้ (ดูเพิ่มเติมด้านล่าง)
• การรบกวนจากมาร์กเกอร์บนตัว inductor สีดำและ crystal oscillator ชิ้นส่วนสองกลุ่มนี้ขึ้นชื่อเรื่องการสร้าง false positive มาร์กเกอร์เลเซอร์สีขาวบนพื้นดำที่หนาแน่นจะถูก rule engine มองว่าเป็นรอยขีดข่วนหรือความเสียหาย
• สิ่งปนเปื้อนที่รบกวนการจัดตำแหน่ง (alignment) ฝุ่นหรือคราบฟลักซ์สามารถลดทอนความแม่นยำในขั้นตอนการจัดตำแหน่ง ทำให้ชิ้นส่วนที่วางไว้อย่างถูกต้องถูกวัดค่าว่าเบี่ยงเบนตำแหน่ง

ลองทำ Pareto จากสาเหตุของ false call ของคุณ หากสามข้อหลังเป็นสาเหตุหลัก แสดงว่าคุณกำลังเผชิญกับปัญหาเชิงอัลกอริทึม ซึ่งการปรับจูนค่าไม่สามารถช่วยได้

ต้นทุนที่แท้จริงของ false call คือเท่าใด?

false call สร้างต้นทุนใน 3 ระดับ: ค่าแรงในการตรวจสอบซ้ำ (โอเปอเรเตอร์ต้องคอยตัดสินบอร์ดที่ถูกแจ้งเตือนทุกแผ่น), ไลน์การผลิตต้องหยุดชะงักระหว่างที่บอร์ดรอคิวที่สถานี verify และการที่โอเปอเรเตอร์เกิดความชาชิน ซึ่งเป็นระดับที่มองเห็นยากที่สุดแต่มีราคาแพงที่สุด เมื่อการแจ้งเตือนส่วนใหญ่กลายเป็นเรื่องหลอก คนจะเริ่มปล่อยผ่านอย่างไม่ใส่ใจ และของเสียจริงก็จะหลุดรอดไปเพราะความน่าเชื่อถือของเครื่องจักรถูกทำลายไปหมดแล้ว DaoAI ประเมินว่าค่าแรงในการตรวจสอบซ้ำและต้นทุนไลน์หยุดชะงักอยู่ที่ประมาณ USD 15,000 ถึง 40,000 ต่อโอเปอเรเตอร์หนึ่งคนต่อปี (ข้อมูลรายงานโดย DaoAI)

ระดับที่สามนี้สมควรได้รับการพิจารณาอย่างจริงจัง เพราะมันกลับทิศทางเป้าหมายของการตรวจสอบ เมื่อ AOI จมอยู่กับ overkill เครื่องจะไม่ช่วยประหยัดแรงงานอีกต่อไป แต่จะเริ่มสร้าง escape ขึ้นมาเอง เนื่องจากขั้นตอนการ verify ด้วยคนนั้นหมดความตื่นตัวไปแล้ว จากนั้นทีมควบคุมคุณภาพจะบีบ threshold ให้แคบลงเพื่อดักจับสิ่งที่หลุดรอด ซึ่งทำให้เกิด false call มากขึ้น และยิ่งทำให้เกิดความชาชินลึกขึ้นไปอีก วงจรนี้คือสาเหตุที่การ "ตรวจซ้ำเฉพาะบอร์ดที่แจ้งเตือน" ไม่เคยมีราคาถูกจริง

นอกจากนี้ยังมีต้นทุนแฝงที่เกิดขึ้นอย่างช้าๆ เมื่อ false call ครอบงำ วิศวกรจะเลิกเชื่อถือข้อมูลทุกอย่างที่ AOI รายงาน แนวโน้มของเสียและชาร์ต SPC ที่สร้างจากข้อมูลของเครื่องจะกลายเป็นเพียงสัญญาณรบกวน (noise) จนท้ายที่สุดเครื่องจักรก็ถูกปล่อยทิ้งไว้โดยไม่มีใครสนใจ ระบบตรวจสอบที่ถูกละเลยคือวิธีที่ไม่ตรวจบอร์ดที่มีราคาแพงมหาศาล

จะลด false call บน AOI แบบดั้งเดิมได้อย่างไร?

บน AOI แบบดั้งเดิม ให้ลด false call โดยการแก้ไขระบบการวัดก่อนที่จะไปแตะต้อง threshold ให้ตรวจยืนยัน golden sample ซ้ำ, ปรับระบบแสงให้กลับมาตามสเปก และอัปเดต component library สำหรับล็อตที่กำลังวิ่งอยู่บนไลน์ จากนั้นจึงค่อยปรับจูนขีดจำกัดใหม่ทีละวินโดว์เทียบกับเกณฑ์ IPC-A-610 โดยเริ่มจากจุดที่สร้างปัญหามากที่สุดใน Pareto พร้อมทั้งตรวจสอบความสามารถในการทำซ้ำ (repeatability) เพื่อให้แน่ใจว่าความแปรปรวนที่เหลืออยู่นั้นเป็นของกระบวนการผลิต ไม่ใช่เกิดจากตัวเครื่องจักร

หากทำตามลำดับนี้ จะสามารถแก้ปัญหาได้อย่างแท้จริง:

1. ตรวจสอบชิ้นงานอ้างอิงก่อนแตะกฎเกณฑ์ หาก golden sample หรือรูปภาพที่เทรนไว้ดริฟต์ไปจากผลิตภัณฑ์ที่ดีในปัจจุบัน (เช่น มี ECO, เปลี่ยนซัพพลายเออร์, ปรับโปรไฟล์การบัดกรีใหม่) ทุกการตัดสินหลังจากนั้นจะสืบทอดความผิดพลาดนี้ไปทั้งหมด ให้เริ่มจากการ re-teach โดยใช้บอร์ดจริงที่ตรวจสอบแล้วก่อนเสมอ
2. ฟื้นฟูระบบออปติกและแสงสว่าง ทำความสะอาดเลนส์ ตรวจสอบกำลังส่องสว่างของหลอดไฟเทียบกับค่า commissioning ปรับตั้งค่า white balance ใหม่ งานเหล่านี้ดูน่าเบื่อ แต่มันคือจุดที่สร้างผลลัพธ์ที่ดีขึ้นได้มากที่สุดในโรงงานหลายแห่ง
3. จัดระเบียบ component library อัปเดตรายการแพ็กเกจเมื่อมีการเปลี่ยนล็อตหรือผู้ผลิต และคัดรายการที่ไม่ได้ใช้ออก ควรกำหนดผู้รับผิดชอบ library ให้ชัดเจน เพราะ library จะเสียหายเร็วที่สุดเมื่อกลายเป็นของทุกคนที่ไม่มีใครดูแล
4. ปรับจูนตาม Pareto และเทียบกับมาตรฐาน จัดอันดับสาเหตุของ false call และแก้วินโดว์ที่แย่ที่สุดก่อน กำหนดขีดจำกัดการยอมรับและการปฏิเสธ (accept/reject limits) โดยอิงกับ IPC-A-610 (ฉบับปัจจุบัน IPC-A-610J, 2024) แทนที่จะปรับจูนส่งเดชเพียงเพื่อให้เสียงแจ้งเตือนเงียบลง วิธีนี้จะช่วยให้คุณมีหลักฐานอ้างอิงกับลูกค้าได้ ในขณะที่ขยายวินโดว์ที่แคบเกินไปให้ผ่อนคลายลง
5. ตรวจสอบความสามารถในการทำซ้ำ (repeatability) ทำการตรวจสอบในรูปแบบ Gage R&R บน AOI ในฐานะระบบการวัด หากบอร์ดแผ่นเดิมให้ผลการตัดสินต่างกันในการรันแต่ละรอบ การปรับจูน threshold ก็เป็นเพียงการเดาสุ่มจนกว่าความไม่เสถียรนั้นจะได้รับการแก้ไข
6. สร้างมาตรฐานให้สถานี verify มอบเกณฑ์การยอมรับและภาพอ้างอิงชุดเดียวกันตาม IPC-A-610 ให้แก่โอเปอเรเตอร์ที่ตรวจสอบซ้ำ เพื่อให้คำว่า "false call" มีความหมายตรงกันในทุกกะ ไม่อย่างนั้น เมตริกที่คุณพยายามปรับปรุงอยู่นั้นจะไม่น่าเชื่อถือตั้งแต่ต้น

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

AI ช่วยลด false call ได้อย่างไร?

AI ลด false call โดยการตัดสินชิ้นส่วนในระดับ feature space แทนที่จะเป็นระดับ pixel space โมเดลวิชันที่ผ่านการฝึกฝนจะดึงรูปร่าง โครงสร้าง พื้นผิว และบริบทเชิงพื้นที่ จากนั้นจะประเมินความผิดปกติเทียบกับลักษณะของบอร์ดที่ดีจริง แทนที่จะนำพิกเซลดิบไปเปรียบเทียบกับกฎที่ตายตัว สิ่งนี้ทำให้การตัดสินทนทานต่อการดริฟต์ของแสง ความแปรปรวนภายนอกของล็อตชิ้นส่วน และการโก่งงอของบอร์ด ซึ่งความแปรปรวนเหล่านี้คือต้นเหตุของ false call ส่วนใหญ่ในระบบแบบใช้กฎ (ข้อมูลรายงานโดย DaoAI; กรุณาตรวจสอบกับบอร์ดของคุณเอง)

เมื่อเทียบกลไกต่อกลไกกับสาเหตุรากเหง้าข้างต้น:

ความแตกต่างเชิงโครงสร้างอย่างที่สองคือ feedback loop ในระบบของ DaoAI เมื่อโอเปอเรเตอร์ทำเครื่องหมายภาพที่แจ้งเตือนว่าเป็น false call การตัดสินนั้นจะส่งกลับไปยังโมเดลและพารามิเตอร์จะอัปเดต การผลิตของแต่ละไลน์จะกลายเป็นข้อมูลฝึกฝนของตัวเอง ส่งผลให้อัตรา false call มีแนวโน้มลดลงตามการใช้งานจริงแทนที่จะดริฟต์สูงขึ้น (กระบวนการทำงานของ golden-board ที่อยู่เบื้องหลังสิ่งนี้มีอธิบายไว้ใน การเขียนโปรแกรม AOI โดยไม่ต้องใช้ไฟล์ CAD) false call จะลดลงเรื่อยๆ เมื่อโอเปอเรเตอร์ให้ feedback ขณะที่ความแม่นยำในการตรวจจับประเมินไว้ที่ 98% ขึ้นไป ยืนยันประสิทธิภาพกับบอร์ดของคุณเองได้ระหว่างการสาธิต

มาตรฐานการยอมรับเองไม่มีการเปลี่ยนแปลง เกณฑ์ยอมรับและปฏิเสธยังคงตรงตามมาตรฐาน IPC-A-610 สิ่งที่โมเดลเปลี่ยนไปคือความสามารถที่เชื่อถือได้ของระบบในการแยกแยะความแตกต่างระหว่าง "ต่างจากเดิมแต่ยอมรับได้" กับ "ของเสีย" สำหรับด้านการตรวจจับภายใต้สถาปัตยกรรมเดียวกันนี้ ดูเพิ่มเติมได้ที่ วิธีที่การตรวจจับด้วย AI จากภาพเดียวจัดการกับความหลากหลายของข้อบกพร่อง

เมื่อใดที่การปรับจูนไม่เพียงพออีกต่อไป?

การปรับจูนจะไม่เพียงพออีกต่อไปเมื่อการแก้ false call กลายเป็นภาระงานประจำของวิศวกร แทนที่จะเป็นแค่งาน commissioning ก่อนเริ่มผลิต สัญญาณบ่งชี้คือ: ทุกการเปลี่ยนรอบการผลิตจำเป็นต้องจูน threshold ใหม่, false call พุ่งกลับขึ้นมาทุกครั้งหลังเปลี่ยนล็อตชิ้นส่วนหรือซัพพลายเออร์, การตรวจสอบซ้ำกลายเป็นสถานีถาวรที่มีคนประจำแทนที่จะเป็นข้อยกเว้น และเริ่มมี escape หลุดรอดในขณะที่ overkill ยังคงสูง ถึงจุดนั้น ข้อจำกัดอยู่ที่สถาปัตยกรรมแบบ rule-based และการปรับจูนเพิ่มเติมจะช่วยยื้อเวลาได้เพียงไม่กี่สัปดาห์

วิธีคิดในทางปฏิบัติเพื่อช่วยตัดสินใจ: การปรับจูนยังคงเป็นเครื่องมือที่เหมาะสม หากกลุ่มผลิตภัณฑ์ของคุณมีเสถียรภาพ, NPI เกิดขึ้นไม่บ่อย, library มีผู้ดูแลชัดเจน และ false call ลดลงจริงหลังปฏิบัติตามลำดับการบำรุงรักษาข้างต้น ไลน์การผลิต High-volume ที่คงที่และมีโปรแกรมที่เป็นระเบียบสามารถใช้งาน AOI แบบดั้งเดิมได้ดี ซึ่งถือเป็นการจับคู่ที่ลงตัว และสามารถอ่านได้ใน การเปรียบเทียบฉบับเต็ม

สถาปัตยกรรมจะกลายเป็นข้อจำกัดทันทีหากภาระ false call เพิ่มขึ้นตามความหลากหลายของผลิตภัณฑ์ (mix) ทุก NPI จะเริ่มต้นหนี้การจูนรอบใหม่ ชิ้นส่วนจากแหล่งสำรองทำให้ pattern match พัง Pareto ของคุณเต็มไปด้วยชิ้นส่วนสีเดียวกับบอร์ด, inductor และ oscillator ที่มีมาร์กเกอร์ หรือการดริฟต์ของแสง ซึ่งสาเหตุเหล่านี้อยู่ลึกกว่าระดับ threshold ที่การจูนจะเข้าไปถึง บททดสอบง่ายๆ: หากคุณต้องจ่ายเงินจ้างวิศวกรเพื่อมาลด false call เดิมๆ ซ้ำซากทุกเดือน การแก้ปัญหานั้นเป็นเพียงแค่การเช่าชั่วคราว ไม่ใช่การเป็นเจ้าของ สถาปัตยกรรมที่เรียนรู้จาก feedback จะช่วยแก้ปัญหานี้ได้อย่างเบ็ดเสร็จในครั้งเดียว

คำถามที่พบบ่อย

อัตรา false call ปกติของ AOI คือเท่าใด?

ไม่มีเกณฑ์มาตรฐานเดียวที่ใช้อ้างอิงได้อย่างสนิทใจ เพราะแต่ละโรงงานวัดบนฐานข้อมูลที่ต่างกัน: วัดต่อชิ้นส่วน (PPM), วัดต่อบอร์ด หรือวัดเป็นสัดส่วนของการแจ้งเตือนทั้งหมด ความหลากหลายของผลิตภัณฑ์ ความซับซ้อนของบอร์ด และแนวคิดในการตั้ง threshold ทำให้ตัวเลขต่างกันได้หลายเท่า แนวทางที่ถูกต้องคือเลือกฐานการวัดแบบใดแบบหนึ่ง ทำเป็นค่า baseline สำหรับแต่ละไลน์ แล้วเฝ้าดูแนวโน้ม แนวโน้ม false call ที่สูงขึ้นในกระบวนการผลิตที่เสถียรหมายความว่าโปรแกรมกำลังเกิดการดริฟต์ ไม่ใช่เกิดจากตัวผลิตภัณฑ์

false call กับ escape แตกต่างกันอย่างไร?

false call คือการแจ้งเตือนบอร์ดที่ดีว่าเป็นของเสีย ส่วน escape คือการปล่อยให้ของเสียจริงหลุดรอดไป บนระบบแบบ rule-based สองสิ่งนี้จะส่งผลกระทบซึ่งกันและกัน: เมื่อบีบ threshold ให้แคบลง false call จะเพิ่มขึ้น เมื่อขยาย threshold ให้กว้างขึ้น escape ก็จะเพิ่มขึ้น นอกจากนี้ อัตรา false call ที่สูงยังเป็นสาเหตุทางอ้อมที่ทำให้เกิด escape จากการที่โอเปอเรเตอร์ที่ทำหน้าที่ตรวจสอบซ้ำเกิดความชาชิน

การขยาย threshold เพื่อลด false call จะทำให้ของเสียจริงหลุดรอดไปหรือไม่?

การขยายแบบเหมารวมทั้งระบบจะทำให้ของเสียหลุดรอดแน่นอน นั่นคือการซื้อความเงียบด้วยการแลกกับ escape ให้ขยายเฉพาะวินโดว์ที่พิสูจน์แล้วว่าแคบเกินไปเมื่อเทียบกับเกณฑ์ IPC-A-610 และทำหลังจากที่แก้ไขปัญหาของชิ้นงานอ้างอิง ระบบแสง และ library แล้วเท่านั้น หากวินโดว์ไม่สามารถทำให้เงียบลงได้โดยไม่ขัดต่อมาตรฐาน ขีดจำกัดที่คุณพบก็คือขีดความสามารถของอัลกอริทึมในการรองรับความแปรปรวน ไม่ใช่ทักษะการปรับจูนของคุณ

AOI ที่ใช้ AI ต้องการข้อมูลมากแค่ไหนก่อนที่ false call จะลดลง?

น้อยกว่าที่วิศวกรส่วนใหญ่คิด ระบบของ DaoAI เริ่มต้นจาก golden board เพียงแผ่นเดียว โมเดลได้รับการฝึกฝนล่วงหน้า (pre-trained) ด้วยภาพจากการผลิตจริงมากกว่าหนึ่งล้านภาพ และจะปรับให้เข้ากับบอร์ดของคุณจากตัวอย่างแผ่นเดียวนั้น จากนั้นจะพัฒนาต่อเนื่องจาก feedback ของโอเปอเรเตอร์ในระหว่างการผลิตตามปกติ (ข้อมูลรายงานโดย DaoAI) ไม่จำเป็นต้องมีโปรเจกต์เก็บข้อมูลมารอคั่นระหว่างการติดตั้งกับการเริ่มตรวจสอบครั้งแรก

false call สามารถลดลงจนเป็นศูนย์ได้หรือไม่?

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

ตรวจสอบกลไกเทียบกับชิ้นส่วนที่สร้างปัญหามากที่สุดของคุณ

หาก Pareto ของ false call ของคุณถูกครอบงำด้วยคอลัมน์ซ้ายของตารางนั้น ชั่วโมงการปรับจูนที่เพิ่มขึ้นจะไม่ช่วยอะไร P Series ของ DaoAI ใช้การตรวจสอบใน feature-space พร้อมการเรียนรู้ผ่าน feedback ของโอเปอเรเตอร์ ทั้งในรูปแบบออฟไลน์ (P1/P2) และอินไลน์ (P3/P3D)