Thông số độ chính xác từ nhà cung cấp là vô nghĩa cho đến khi bạn tự tái hiện lại trên chính bo mạch của mình. 6 loại bo mạch cần mang theo, 5 hạng mục cần đo lường, và tiêu chuẩn của một kết quả đạt yêu cầu.
Đánh giá một hệ thống AOI AI bằng cách tái hiện các tuyên bố của nhà cung cấp trên chính bo mạch của bạn, chứ không phải bằng cách so sánh bảng thông số kỹ thuật. Hãy mang theo sáu nhóm bo mạch (đơn hàng high-mix phức tạp nhất, linh kiện cùng màu, cuộn cảm có ký hiệu đánh dấu, bo mạch không có dữ liệu CAD, bo mạch có sẵn các lỗi thực tế đã xác định, và bo mạch đang gây báo lỗi giả nhiều nhất hiện nay), sau đó đo lường năm yếu tố: thời gian lập trình, tỷ lệ báo lỗi giả, tỷ lệ lọt lỗi trên các lỗi đã biết, thời gian làm quen của người vận hành và độ lặp lại giữa các lần chạy. Đánh giá dựa trên dây chuyền hiện tại của bạn làm mốc chuẩn, không dựa trên các số liệu của nhà cung cấp.
Mọi nhà cung cấp AOI đều công bố số liệu về độ chính xác, và chúng tôi cũng không ngoại lệ. Những con số đó chỉ có giá trị khi bạn có thể tái hiện được chúng trên chính sản phẩm của mình. Bài viết này là quy trình chuẩn mà chúng tôi khuyến nghị người mua nên thực hiện: cần mang theo những gì, cần đo lường những gì, thời gian chạy thử nghiệm trong bao lâu và kết quả đạt yêu cầu trông như thế nào. Quy trình này áp dụng được cho máy của bất kỳ nhà cung cấp nào, và chúng tôi muốn bạn chạy thử quy trình này trên máy của chúng tôi hơn là chỉ nghe những lời tuyên bố.
Các con số về độ chính xác của AOI hiếm khi có thể so sánh trực tiếp vì mẫu số tính toán khác nhau. Tỷ lệ phát hiện lỗi có thể được tính trên mỗi linh kiện, trên mỗi bo mạch, hoặc trên từng loại lỗi, và ba cách tính này có thể chênh lệch nhau nhiều bậc độ lớn trên cùng một cỗ máy. Tỷ lệ báo lỗi giả cũng gặp vấn đề tương tự. Các số liệu công bố cũng thường bỏ qua thông tin về loại bo mạch nào, bộ lỗi nào và triết lý thiết lập ngưỡng nào đã tạo ra chúng. Những con số này không hẳn là thiếu trung thực. Chúng chỉ đơn giản là không thể áp dụng trực tiếp sang dây chuyền của bạn.
Một khảo sát nhanh về các tuyên bố công khai cho thấy mức độ chênh lệch rõ rệt. Các nguồn độc lập trong năm 2025 và 2026 ghi nhận các mức giảm khác nhau: giảm 30 đến 40 phần trăm báo lỗi giả, giảm 70 đến 85 phần trăm phế phẩm giả, và đạt 98 đến 99 phần trăm tỷ lệ phát hiện trên các mối hàn quan trọng, tùy thuộc vào nguồn số liệu (Overview.ai 2025; Boolean & Beyond 2026; Jidoka 2026). DaoAI đánh giá độ chính xác phát hiện ở mức 98 phần trăm trở lên, trong khi tỷ lệ báo lỗi giả giảm dần khi người vận hành phản hồi dữ liệu. Những số liệu này mô tả các thử nghiệm khác nhau mà không ai ghi chép đủ chi tiết để lặp lại, vì vậy hãy tự xác thực hiệu suất trên chính bo mạch của bạn.
Ba câu hỏi sau sẽ làm rõ phần lớn sự mơ hồ, và bạn có thể đặt chúng cho bất kỳ con số nào, kể cả số liệu của chúng tôi:
Điều này không có nghĩa là việc thử nghiệm là vô vọng. Nó chỉ có nghĩa là quá trình thử nghiệm phải diễn ra trực tiếp tại nhà xưởng của bạn.
Hãy mang theo sáu nhóm bo mạch, mỗi nhóm nhắm vào một năng lực cụ thể: đơn hàng high-mix phức tạp nhất, bo mạch có linh kiện cùng màu, bo mạch có cuộn cảm dán chip hoặc bộ dao động thạch anh có ký hiệu đánh dấu, đơn hàng bạn hoàn toàn không có dữ liệu CAD, bo mạch có các lỗi thực tế đã được cấy sẵn hoặc lập hồ sơ, và bo mạch đang tạo ra tỷ lệ báo lỗi giả tồi tệ nhất hiện nay. Các nhà cung cấp sẽ đề xuất dùng bo mạch demo của họ. Những bo mạch đó chỉ cho bạn thấy cỗ máy làm tốt điều gì, chứ không trả lời được câu hỏi bạn đang cần giải quyết.
| Bo mạch cần mang | Mục tiêu kiểm tra | Kết quả đạt yêu cầu |
|---|---|---|
| Đơn hàng high-mix phức tạp nhất | Thời gian lập trình trong điều kiện phức tạp thực tế | Hoàn tất cài đặt mà không cần nhà cung cấp can thiệp |
| Linh kiện cùng màu | Khả năng phát hiện khi thân linh kiện trùng màu với lớp nền mạch | Định vị linh kiện tin cậy, không bị bỏ sót hoặc báo lỗi hàng loạt |
| Cuộn cảm hoặc thạch anh có đánh dấu | Khả năng phân biệt giữa ký hiệu bề mặt và lỗi thực tế | Không báo nhầm ký hiệu thành vết xước hoặc hư hại |
| Đơn hàng không có dữ liệu CAD | CAD thực sự là tùy chọn hay là yêu cầu bắt buộc ngầm | Vẫn tạo ra được chương trình kiểm tra hoạt động tốt |
| Bo mạch có lỗi đã biết | Hành vi lọt lỗi thực tế | Bắt được mọi lỗi đã biết và phân loại chính xác |
| Bo mạch báo lỗi giả nhiều nhất hiện nay | Vấn đề nhức nhối hiện tại có thực sự được cải thiện hay không | Số lượng cảnh báo giảm rõ rệt so với hệ thống hiện tại |
Bo mạch có lỗi đã biết cần được lưu ý đặc biệt. Bạn cần các lỗi thực tế đã được lập hồ sơ, không phải lỗi mô phỏng: các bo mạch được lấy từ phế phẩm thực tế của bạn với danh sách lỗi được trạm kiểm tra xác nhận đối chiếu theo tiêu chuẩn IPC-A-610. Hãy giữ kín danh sách này trong suốt buổi demo. Một hệ thống được đánh giá dựa trên những lỗi mà nhà cung cấp đã biết trước thì không còn là đánh giá thực tế.
Ngoài ra, hãy mang theo một bo mạch đơn giản. Một đơn hàng tiêu chuẩn, yield cao sẽ thiết lập mức sàn báo lỗi giả của bạn. Nếu hệ thống tạo ra nhiễu cảnh báo ngay trên đơn hàng dễ, thì không tính năng nào trên các đơn hàng khó có thể cứu vãn được.
Hãy đo lường năm yếu tố: thời gian lập trình (bấm giờ từ khi nhận bo mạch đến lần kiểm tra đầu tiên), tỷ lệ báo lỗi giả (số cảnh báo chia cho số linh kiện được kiểm tra, dùng một mẫu số nhất quán), tỷ lệ lọt lỗi (số lỗi đã biết phát hiện được chia cho tổng số lỗi đã biết hiện có), thời gian làm quen của người vận hành (liệu nhân viên không phải kỹ sư có thể tự hoàn tất chuyển đổi model hay không), và độ lặp lại (chạy cùng một bo mạch ba lần và so sánh kết quả). Ghi lại các con số trong quá trình thực hiện. Những ấn tượng trong phòng demo sẽ phai nhạt chỉ sau một ngày.
Chi tiết cách tính toán năm yếu tố:
Ghi kết quả vào một bảng duy nhất trong suốt buổi đánh giá. Nhà cung cấp A so với Nhà cung cấp B so với dây chuyền hiện tại của bạn, cùng chung năm tiêu chí.
Buổi demo kéo dài hai giờ có thể đo lường thời gian lập trình, các lỗi giả rõ ràng, hành vi lọt lỗi trên các lỗi đã biết và khả năng thao tác của người vận hành. Nó không thể đo lường được liệu báo lỗi giả có giảm dần theo thời gian hay không, cách hệ thống xử lý khi thay đổi lô linh kiện, hoặc tỷ lệ lọt lỗi thực tế ở quy mô sản xuất hàng loạt. Những yếu tố đó cần hai đến bốn tuần trên dây chuyền thực tế. Hãy coi buổi demo là vòng sàng lọc và giai đoạn pilot là căn cứ đưa ra quyết định.
Những gì mỗi giai đoạn thực sự có thể mang lại:
Demo hai giờ, phạm vi thực tế. Thời gian cài đặt là thực và có thể đo lường tại đây. Hành vi nhận diện linh kiện cùng màu và ký hiệu đánh dấu cũng vậy, vì đó là bài toán trên từng hình ảnh đơn lẻ. Khả năng làm quen của người vận hành bộc lộ ngay lập tức. Hành vi lọt lỗi trên bo mạch có lỗi đã biết có giá trị trong phạm vi mẫu thử là một bo mạch.
Hai đến bốn tuần trên dây chuyền, điều chỉ có giai đoạn này hé lộ. Liệu tỷ lệ báo lỗi giả có xu hướng giảm khi người vận hành phản hồi các hiệu chỉnh hay không — đây chính là cơ chế phân biệt giữa hệ thống tự học và hệ thống tĩnh (chi tiết cơ chế tại đây). Liệu một lô linh kiện mới hoặc linh kiện từ nguồn thứ hai có làm sai lệch kết quả hay không. Liệu tỷ lệ lọt lỗi có duy trì ổn định ở quy mô sản lượng lớn thay vì chỉ trên một bo mạch mẫu. Liệu gánh nặng bảo trì có đúng như nhà cung cấp đã mô tả hay không.
Hai cảnh báo về những kết luận vội vã: Một buổi demo không thể xác thực tuyên bố về khả năng tự học của hệ thống, vì việc học cần dữ liệu phản hồi sản xuất và thời gian. Và một buổi demo chạy trên cỗ máy đã được nhà cung cấp chuẩn bị sẵn không phản ánh được đội ngũ của bạn sẽ duy trì nó ra sao sau ba tháng. Hãy hỏi cỗ máy đã ở trạng thái nào trước khi bạn bước vào.
Hãy đặt tiêu chuẩn đạt dựa trên chính dây chuyền của bạn, không dựa trên một con số tuyệt đối. Xác định mốc chuẩn hiện tại về thời gian lập trình, tỷ lệ báo lỗi giả, tỷ lệ lọt lỗi và nhân lực kiểm tra lại, sau đó quyết định trước mức cải thiện bao nhiêu là đủ để biện minh cho chi phí đầu tư và sự xáo trộn quy trình. Việc ghi sẵn các ngưỡng này trước buổi demo sẽ giữ cho quyết định luôn khách quan, bởi hệ thống nào trông cũng ấn tượng khi do chính nhà cung cấp thao tác.
Bảng chấm điểm nên hoàn thiện trước khi có bất kỳ ai đến khảo sát:
| Chỉ số | Mốc chuẩn hiện tại của bạn | Mức tối thiểu để quyết định thay đổi | Kết quả demo | Kết quả pilot |
|---|---|---|---|---|
| Thời gian lập trình mỗi đơn hàng | ___ | ___ | ||
| Tỷ lệ báo lỗi giả (cùng mẫu số) | ___ | ___ | ||
| Tỷ lệ lọt lỗi trên các lỗi đã biết | ___ | ___ (thường là: không suy giảm) | ||
| Người vận hành có thể tự chuyển đổi model | có / không | ___ | ||
| Độ lặp lại giữa các lần chạy | ___ | ___ |
Hai nguyên tắc khi điền bảng này. Thứ nhất, dòng tỷ lệ lọt lỗi là điều kiện tiên quyết mang tính sống còn, không thể nhân nhượng: một hệ thống cải thiện mọi mặt khác nhưng lại để lọt lỗi thực tế thì đều bị đánh trượt, bất kể các cột khác ra sao. Thứ hai, hãy xác định cột ở giữa trước buổi demo. Một ngưỡng được đặt ra sau khi xem demo chỉ là sự hợp lý hóa khiên cưỡng.
Nếu bạn vẫn đang trong giai đoạn thu hẹp phạm vi chọn loại máy và cấu hình thay vì xác thực các tuyên bố, hướng dẫn lựa chọn sẽ hỗ trợ giai đoạn này, bao gồm bảy câu hỏi đáng giá cần đặt ra cho mọi nhà cung cấp.
Hãy coi đó chính là câu trả lời. Các ràng buộc về bảo mật là có thật và có thể giải quyết bằng thỏa thuận NDA, nhưng một nhà cung cấp không sẵn sàng chạy sản phẩm của bạn dưới bất kỳ hình thức nào đang ngầm cho bạn biết rằng số liệu của họ chỉ tồn tại trên bo mạch của chính họ. Mọi quy trình đánh giá nghiêm túc đều phải chạy trên sản phẩm của người mua.
Đối với buổi demo, mức độ bao phủ trên cả sáu nhóm bo mạch quan trọng hơn số lượng. Đối với giai đoạn pilot, bạn cần đủ số lượng bo mạch sản xuất để tỷ lệ báo lỗi giả đạt mức ổn định chứ không phải do may rủi, điều này trên thực tế đồng nghĩa với việc cho dây chuyền chạy bình thường từ hai đến bốn tuần thay vì chỉ đếm một số lượng bo mạch cụ thể.
Có, và hãy để họ làm. Nhưng hãy ghi lại từng điều chỉnh mà họ thực hiện. Nhật ký đó chính là dự báo bảo trì của bạn: mọi thao tác kỹ sư ứng dụng làm trong giai đoạn pilot sẽ là công việc mà một người trong nhà máy của bạn phải tự gánh vác sau này. Nếu nhật ký đó quá dài, hãy đặt câu hỏi ai sẽ làm việc đó ở tháng thứ sáu.
Hình thức lỗi cần hỏi rõ là hiện tượng trôi dạt dữ liệu (drift): điều gì sẽ xảy ra khi lô linh kiện, phiên bản bo mạch hoặc điều kiện chiếu sáng thay đổi sau khi mô hình đã được huấn luyện. Các hệ thống học từ phản hồi của người vận hành được thiết kế để thích ứng với điều đó, và DaoAI ghi nhận tỷ lệ báo lỗi giả giảm dần trong quá trình sử dụng thay vì tăng lên (theo số liệu DaoAI công bố). Hãy hỏi bất kỳ nhà cung cấp nào về cách mô hình cập nhật, ai kích hoạt việc cập nhật đó và điều gì xảy ra khi bo mạch thay đổi phiên bản.
Hãy áp dụng quy trình này cho bất kỳ cỗ máy nào nằm trong danh sách rút gọn của bạn. Nếu thiết bị của chúng tôi là một trong số đó, hãy mang theo sáu bo mạch, giữ kín danh sách lỗi và đánh giá chúng tôi trên cùng một bảng chấm điểm khắt khe như mọi đối thủ khác.
Xem cách AOI nhận diện các mối hàn hở quan sát được, những điểm hạn chế của phương pháp ngưỡng màu cố định, và cách model 2D tiền huấn luyện xử lý các trường hợp phổ biến lẫn đặc biệt.
17 tháng 9, 2026
Các bảng tính ROI từ nhà cung cấp thường tự đưa ra giả định thay bạn. Dưới đây là toàn bộ mô hình: tám hạng mục chi phí, công thức tính mức tiết kiệm từ false-call và escape, cùng hai kịch bản phân tích cụ thể, gồm cả trường hợp không mang lại hiệu quả kinh tế.
25 tháng 8, 2026
Thông số kỹ thuật chỉ là tấm vé vào cửa. Khác biệt thực sự tại xưởng sản xuất high-mix nằm ở: dữ liệu đầu vào lập trình, thời gian chuyển đổi sản phẩm và gánh nặng báo lỗi giả. Bảy câu hỏi sau sẽ làm rõ điều đó.
5 tháng 8, 2026
Chuyên đề kiểm tra bằng AI, tin sản phẩm và phân tích ngành. Mỗi tháng một lần, không tin thừa.
Chúng tôi sử dụng thông tin của bạn để phản hồi yêu cầu liên hệ. Xem Chính sách quyền riêng tư của chúng tôi.
