1. Tuliskan apa yang akan membuat uji berhasil atau selesai
Sebelum memulai satu rangkaian, catat hasil yang diharapkan, cacat yang membuat keluaran tidak dapat digunakan, dan waktu pengambilan keputusan. Tujuan seperti "dua puluh empat gambar yang diterima dalam format yang diminta" lebih mudah dikendalikan daripada "membuat gambar yang bagus". Tujuan pembelajaran juga bisa sah: berhasil menjalankan eksekusi kecil, menemukan kembali pengaturannya, dan memverifikasi salinannya.
Tetapkan batas waktu pribadi dan plafon untuk pengeluaran tambahan yang dipertimbangkan. Keduanya boleh sederhana: satu hipotesis perbaikan sebelum evaluasi, lalu penyimpanan. Ini bukan nilai universal. Pilih sesuai tugas Anda dan orang yang akan memvalidasi hasilnya.
Tetapkan juga kriteria yang tidak bisa dinegosiasikan di saat terakhir. Jawaban yang mengarang prosedur atau visual yang membuat produk terdistorsi dapat tetap ditolak meskipun semua hal lain tampak meyakinkan. Jika tidak, kelelahan saat uji berisiko perlahan mengubah cacat yang menghambat menjadi detail yang dapat diterima.
2. Hitung waktu yang benar-benar tersedia untuk percobaan baru
Mulailah dari waktu yang tersisa dalam sesi Anda dan dalam jendela penyewaan yang dapat digunakan. Ambil kendala yang paling dekat, lalu kurangi waktu yang direncanakan untuk memverifikasi dan menyalin hasil. Sisanya dapat menampung percobaan baru, pengendaliannya, dan perbaikan yang wajib. Jangan menghitung slot yang sama untuk memproduksi sekaligus menyimpan.
Batas yang dikonfigurasi dalam perangkat lunak tidak menggantikan pengaturan ini. Misalnya, Transformers menyatakan bahwa max_time dapat membiarkan proses generasi yang sedang berjalan tetap selesai setelah waktu yang ditentukan. Pengaturan ini juga tidak menyisihkan waktu untuk peninjauan ulang atau transfer. Pertahankan titik henti Anda sendiri dan gunakan perintah penghentian yang disediakan oleh alat Anda.
Jika durasi proses berikutnya tidak diketahui, kecilkan cakupannya: satu masukan, satu pertanyaan, satu ekspor. Jika bahkan uji kecil ini tidak dapat dikendalikan sebelum batas waktu, tunda saja. Keluaran yang muncul tepat sebelum akhir tetapi tidak pernah dibuka bukanlah hasil yang diterima.
3. Bedakan tiga keputusan yang mungkin
Perbedaan antara melanjutkan dan mengubah terletak pada apa yang Anda pelajari. Lanjutkan ketika metode mencapai kriteria pada cakupan yang dikendalikan dan Anda memperluas batch dengan hati-hati. Ubah ketika Anda dapat menyebutkan penyebab dan perubahan yang mengujinya. Hentikan ketika Anda tidak lagi memiliki pertanyaan berguna untuk diselesaikan dalam batas Anda.
Kesalahan teknis yang berulang memerlukan diagnosis, bukan serangkaian pengaturan baru yang tidak berkaitan. Keluaran yang secara teknis lengkap tetapi berkualitas buruk memerlukan pemeriksaan lain. Jelaskan kegagalan itu dengan kata-kata Anda sendiri sebelum memutuskan. Membeli lebih banyak kapasitas tidak menjawab dokumen yang hilang atau instruksi yang meminta dua hal yang bertentangan.
| Décision | Condition utile | Prochaine action bornée |
|---|---|---|
| Lanjutkan | Kriteria tercapai pada sampel yang relevan; waktu pengendalian tersedia | Perluas bagian pendek dengan parameter yang sama |
| Ubah | Penyebab yang masuk akal, perubahan yang terisolasi, dan hasil yang dapat diverifikasi | Uji satu masukan yang sulit lalu satu kasus yang sudah berhasil |
| Hentikan | Batas tercapai, tidak ada asumsi yang jelas, atau hasil penting tidak dapat diakses | Simpan pekerjaan, catat kendalanya, dan siapkan pendekatan lain |
4. Pisahkan paket yang dipesan dari biaya lanjutan
Harga paket BriefGPU berlaku untuk satu lot selama periode yang dipilih. Dalam laporan Anda, pertahankan jumlah penuh ini dikalikan jumlah lot. Jangan menggantinya dengan tarif per menit yang dihitung belakangan dan jangan mengubah waktu yang tidak terpakai menjadi kredit yang diasumsikan. Keputusan kerja tidak menciptakan aturan penagihan baru.
Anda dapat membandingkan biaya paket dengan hasil yang diterima, asalkan Anda menyebutkan jumlah dan cakupannya. Jika tidak ada hasil yang diterima, rasio tersebut tidak dapat dihitung; menampilkan nol akan memberi kesan menyesatkan bahwa hasilnya gratis. Output yang ditolak tetap masuk dalam laporan uji coba, tetapi tidak termasuk dalam hasil yang diterima.
Periksa secara terpisah biaya lanjutan: waktu manusia, biaya eksternal yang diketahui, kemungkinan periode lain yang perlu dipertimbangkan, dan hasil tambahan yang diharapkan. Biaya yang tidak dicatat tetap tidak diketahui, bukan nol. Kalkulator anggaran membantu Anda mempertahankan perbedaan ini. Pengeluaran di masa lalu tidak membuktikan bahwa percobaan berikutnya akan bermanfaat.
Contoh: delapan belas gambar diterima dari target dua puluh empat
Mari kita ambil skenario pembelajaran dengan lot RTX A5000 selama tiga hari, dengan harga 23,57 USD dari katalog 24 September 2026. Target pekerja lepas ini adalah menghasilkan dua puluh empat visual yang diterima. Dalam skenario fiktif ini, delapan belas lolos pemeriksaan dan enam memiliki cacat yang berulang. Angka-angka ini menggambarkan sebuah keputusan; angka-angka ini tidak mengukur produksi GPU tersebut.
Rasio yang direncanakan adalah 23,57 ÷ 24, yaitu sekitar 0,98 USD per hasil. Dengan delapan belas hasil yang diterima, rasio paket adalah 23,57 ÷ 18, yaitu sekitar 1,31 USD. Biaya eksternal tidak dicatat: tidak ada biaya keseluruhan per hasil yang diumumkan. Selisih antara kedua rasio tersebut menggambarkan laporan, bukan alasan yang cukup untuk menjalankan ulang keenam file.
Tersisa lima puluh menit sebelum batas sesi yang ditetapkan. Pekerja lepas ini menyisihkan dua puluh menit untuk menyalin dan memeriksa folder; tiga puluh menit tersisa untuk satu percobaan dan tinjauannya. Perkiraannya untuk pemrosesan baru adalah empat puluh menit, ditambah sepuluh menit pemeriksaan. Percobaan lima puluh menit ini tidak muat dalam slot waktu tiga puluh menit.
Karena itu ia menghentikan produksi untuk mempertahankan delapan belas output dan enam alasan penolakan. Target dua puluh empat tidak dinyatakan tercapai. Jika pengiriman sebagian cocok untuk penerima, hal itu harus disepakati secara eksplisit. Sesi lain dapat menangani asumsi yang spesifik; laporan saat ini tidak mewajibkan untuk segera memulai lagi atau membeli periode lain.
| Repère du scénario | Calcul ou état | Conséquence |
|---|---|---|
| Waktu hingga batas | 50 menit | Titik awal |
| Waktu untuk menyalin dan memeriksa | 20 menit | Harus dipertahankan |
| Waktu untuk satu percobaan dan tinjauannya | 50 − 20 = 30 menit | Batas atas pekerjaan tambahan |
| Perkiraan percobaan baru | 40 + 10 = 50 menit | Tidak muat dalam slot waktu |
| Laporan kualitas | 18 diterima; 6 ditolak | Target 24 tidak tercapai |
5. Hentikan dengan rapi dan buat keputusan dapat digunakan kembali
Jika perangkat memungkinkan, hentikan penambahan tugas baru lalu biarkan elemen yang sedang berjalan selesai sebelum menutup. Ikuti prosedur penghentiannya. Jika gangguan meninggalkan file yang tidak lengkap, tandai untuk diperiksa dan simpan terpisah dari output yang diterima. Menutup jendela atau kehilangan koneksi bukan merupakan cara untuk mengendalikan status pekerjaan.
Simpan catatan beberapa baris: tujuan, hasil yang diperoleh, kendala yang dihadapi, keputusan, dan syarat untuk melanjutkan. Misalnya: «Delapan belas output diterima; enam detail tidak terbaca; produksi dihentikan untuk menjaga salinan; lanjutkan setelah uji coba terarah pada detail tersebut.» Lampirkan parameter dan daftar pengenal terkait.
Penghentian uji coba perangkat lunak Anda bukan merupakan, dengan sendirinya, permintaan pembatalan, pengembalian dana, atau perubahan pesanan. Untuk pertanyaan tentang berkas penyewaan, lihat syarat dan ketentuan serta alur dukungan. Panduan ini mengatur pekerjaan Anda dan tidak mengandaikan adanya perubahan komersial otomatis.
Kesalahan yang memperpanjang uji coba tanpa memperbaiki keputusan
Hindari menunda batas setelah setiap kegagalan, memilih hanya hasil terbaik untuk evaluasi, atau menganggap hasil yang belum diperiksa sebagai diterima. Jangan diam-diam menurunkan kriteria agar hasil sesuai dengan target. Jika kebutuhan berubah, tuliskan target baru: itu adalah keputusan proyek, bukan keberhasilan retroaktif.
Jangan lanjutkan hanya karena waktu sudah terlanjur dihabiskan untuk pekerjaan tersebut. Tanyakan apa yang bisa dipelajari atau dihasilkan dari percobaan berikutnya, dengan verifikasi apa. Jawaban samar seperti "mungkin kali ini berhasil" menuntut hipotesis yang lebih spesifik. Ketika tindakan terbaik adalah menyiapkan file di komputer Anda, persiapan itu bisa dilakukan sebelum penyewaan berikutnya.