Kasus yang dilaporkan
Nomor komponen yang sama bisa membawa teknisi ke beberapa gambar. Pada produsen pendingin Kuken Industries di Jepang, peralatan dengan nama model serupa dapat memiliki spesifikasi berbeda menurut pelanggan atau tahun pemasangan. Saat komponen perlu diganti, satu hasil pencarian yang tampak mirip bisa mengarah ke versi yang salah.
Dalam studi kasus terbit 9 November 2026, OpenAI menjelaskan sistem pencarian yang dibangun Kuken bersama Recursive untuk menelusuri arsip sekitar 70 tahun. Teknisi dapat memasukkan nomor gambar atau komponen, atau mengunggah gambar maupun PDF. Aplikasi bisa membaca nomor dari tangkapan layar daftar komponen dan menampilkan calon gambar. Teknisi lalu memeriksa spesifikasi peralatan dan catatan penggantian untuk memilih versi yang sesuai.
Cari sampai ketemu dokumen yang bisa dipakai
Pekerjaan selesai ketika staf menemukan dokumen yang sah untuk kasusnya. Jika hasil pencarian cepat tetapi versi salah sering muncul, staf masih harus menelusuri arsip dan koreksi bisa menambah pekerjaan. Uji dengan arsip yang sama untuk dua cara pencarian. Mulai stopwatch saat pertanyaan diterima dan hentikan saat petugas menyetujui satu dokumen atau menyatakan bukti belum cukup.
Pisahkan hasil percobaan dan proyeksi tahunan
Recursive menyebut rata-rata 4,5 menit pada tahap uji coba di pabrik Fukuoka. Angka sekitar 90% adalah perkiraan pengurangan jam pencarian dalam setahun berdasarkan catatan periode sebelumnya. Perkiraan itu hanya mencakup pencarian gambar. Waktu untuk inspeksi, pemesanan komponen, dan perbaikan berada di luar hitungan tersebut. Publikasi itu tidak memuat jumlah pencarian yang mendasari rata-rata tersebut. Waktu untuk arsip lain bisa berbeda karena kualitas pindai, kelengkapan nomor revisi, dan jenis pertanyaannya.
Kuken dan Recursive juga mengembangkan pemeriksaan perbedaan antardokumen. OpenAI menyebut sekitar 90% selisih yang ditandai prototipe tersebut memang benar. Angka ini berbicara tentang temuan yang ditandai. Tanpa jumlah seluruh selisih yang seharusnya ditemukan, pembaca belum bisa tahu berapa banyak kesalahan yang luput.
Masukkan kasus ketika jawaban memang tidak ada
Mulai dengan arsip kecil dan jawaban yang ditetapkan petugas berpengalaman. Isi sebagian contoh dengan nama berkas mirip, revisi lama yang masih tersimpan, dan dokumen yang memang belum ada. Catat berapa kali versi benar masuk tiga hasil teratas, berapa kali orang memilih versi benar, dan berapa lama pemeriksaan lengkapnya. Pisahkan pencarian tanpa jawaban agar saran yang salah bisa dihitung.
Hasil pencarian perlu menunjuk berkas dan halaman asal agar pengguna dapat mengulang pemeriksaan. Dokumen sensitif bisa diwakili oleh berkas contoh saat menyiapkan uji. Saat memakai dokumen kerja, pastikan hak akses terhadap hasil pencarian mengikuti izin pada sumbernya.
Sebelum mengganti cara kerja, ukur juga pencarian dengan indeks biasa yang berisi nomor alat, nomor seri, revisi, dan tanggal berlaku. Untuk berkas yang sudah diberi nomor konsisten, indeks bisa cukup. AI lebih layak diuji pada bagian yang menyulitkan pencarian biasa, seperti tulisan pada hasil pindai atau variasi penamaan lama. Pembanding ini membantu tim menilai manfaat setiap perubahan.
Contoh penerapan
Contoh fiktif untuk tim pemeliharaan gedung di Surabaya. Dua PDF memakai nama komponen yang sama, tetapi revisi A berlaku untuk perangkat lama dan revisi B untuk kelompok nomor seri berikutnya. Saat aplikasi menawarkan keduanya, petugas membandingkan nomor seri dan riwayat perawatan dengan halaman sumber. Jika data itu tidak terbaca, hasil yang benar adalah menunda pemilihan dan meminta informasi tambahan.
Ilustrasi Nalarku.
Sumber dan referensi
Analisis menggabungkan fakta bersumber dan penafsiran Nalarku.
NALAR PEKAN
Kabar AI pilihan, lewat email.
Berita yang sudah ditinjau, konteks Indonesia, dan ide yang bisa kamu coba. Konfirmasi alamat email untuk mulai berlangganan.
Memeriksa kesiapan pendaftaran email…
