WRNOTE: Membaca Proposal Vendor AI Tanpa Tersesat dalam Jargon

Istilah teknis perlu diterjemahkan menjadi klaim yang bisa diperiksa. Proposal yang menarik belum tentu menjawab kebutuhan yang tepat.

Proposal fiktif yang terdengar serba bisa

Bayangkan tim layanan menerima proposal: "Asisten AI memakai model canggih, RAG, dan agent untuk memahami semua dokumen, menjawab akurat, serta menyelesaikan pekerjaan otomatis." Kalimatnya lancar. Namun belum jelas pekerjaan apa yang benar-benar dibantu.

Contoh ini fiktif dan bukan kutipan vendor tertentu. Gunanya menyatukan konsep AI, pemilihan solusi, dan teknik generative AI yang telah dibahas dalam seri. Review menjadi lebih berguna ketika konsep dipakai memeriksa satu keputusan, bukan diulang sebagai kamus.

Langkah pertama bukan mencari arti setiap singkatan. Tulis ulang janji itu menjadi tugas: menemukan prosedur yang berlaku, menyusun draf jawaban, dan melakukan tindakan pada sistem. Ketiganya punya bukti keberhasilan serta batas kewenangan yang berbeda.

Diagram orisinal. Skenario fiktif untuk pembelajaran.

Pisahkan tiga lapisan yang sering bercampur

Algoritma adalah cara perhitungan atau pembelajaran, model adalah hasil yang digunakan untuk menghasilkan prediksi atau keluaran, dan aplikasi menggabungkan model dengan data, antarmuka, aturan, serta alur kerja. Nama model tidak menjelaskan seluruh aplikasi.

Training mengubah kemampuan model melalui data pelatihan; inference memakai model untuk menghasilkan keluaran. Saat aplikasi mengambil dokumen untuk ditambahkan ke konteks, itu tidak otomatis berarti model dilatih ulang. Perbedaan ini penting ketika menilai janji pembaruan pengetahuan.

Tanyakan bagian mana yang memakai aturan tetap, model prediktif, atau generative AI. Alur layanan dapat memakai ketiganya sekaligus. Meminta rincian ini bukan mengharuskan pembeli memilih arsitektur teknis sendiri, melainkan memastikan bahwa istilah punya hubungan dengan kebutuhan.

Ganti klaim besar dengan bukti yang relevan

Frasa "menjawab akurat" perlu diikuti pertanyaan: akurat untuk jenis pertanyaan apa, dibandingkan dengan apa, dan dinilai oleh siapa? Demo pada beberapa contoh pilihan belum menunjukkan perilaku pada dokumen lama, pertanyaan ambigu, atau permintaan di luar cakupan.

Minta evaluasi dengan contoh yang mewakili penggunaan yang diizinkan. Pisahkan keberhasilan menemukan sumber, kesesuaian isi jawaban, ketepatan menyatakan tidak tahu, dan kemampuan meneruskan kasus. Jangan menyatukannya menjadi satu angka tanpa penjelasan.

Periksa data yang mendasari uji. Siapa pemilik dokumen, versi mana yang berlaku, dan bagaimana izin akses diterapkan? Data berlabel rapi pun belum tentu mewakili masalah saat ini. Hasil pada contoh historis tidak otomatis tetap sama ketika jenis pelanggan atau proses berubah.

Tanyakan apa yang sebenarnya dilakukan RAG dan fine-tuning

RAG mengambil informasi dari sumber lalu memasukkannya ke konteks untuk membantu jawaban. Fine-tuning menyesuaikan parameter model lewat pelatihan tambahan. Keduanya dapat dipadukan, tetapi bukan nama lain untuk fungsi yang sama.

Jika prosedur sering berubah, tanyakan bagaimana perubahan, pencabutan, dan penghapusan sumber masuk ke aplikasi. Jangan menerima jawaban "sudah memakai RAG" sebagai bukti pembaruan pasti benar. Dokumen yang salah dipilih atau akses yang keliru tetap dapat menghasilkan jawaban bermasalah.

Jika vendor menawarkan fine-tuning, tanyakan masalah perilaku apa yang ingin diperbaiki dan bukti bahwa pendekatan itu membantu. Gaya tulisan, format, atau pola tugas tidak sama dengan kebutuhan mengambil kebijakan terbaru. Memilih teknik perlu mengikuti evaluasi, bukan urutan kecanggihan istilah.

Bedakan jawaban dengan hak untuk bertindak

Sebuah agent dapat memakai alat dan menjalankan langkah, tetapi kemampuan teknis tidak memberi kewenangan bisnis. Membaca status pesanan berbeda dari mengubah alamat kirim atau menyetujui pengembalian uang.

Tulis tindakan yang diizinkan, data yang boleh diakses, kapan persetujuan manusia diperlukan, serta cara menghentikan dan meninjau kesalahan. Batas ini bagian dari kebutuhan aplikasi, bukan catatan tambahan setelah demo berhasil.

Contoh keputusan sementara: pilot hanya membantu petugas mencari sumber dan menyusun draf. Pengiriman jawaban serta tindakan finansial tetap diperiksa oleh orang yang berwenang. Ini bukan aturan universal, melainkan pilihan terbatas untuk kasus fiktif dengan bukti yang belum lengkap.

Akhiri review dengan catatan keputusan

Buat empat kolom sederhana: klaim, bukti yang tersedia, batas bukti, dan pertanyaan berikutnya. Misalnya klaim memakai sumber terbaru, bukti daftar dokumen uji, batas belum ada uji pencabutan, pertanyaan bagaimana pembaruan diverifikasi.

Keputusan tidak harus langsung beli atau tolak. Bisa meminta penjelasan, menguji satu alur, mempersempit pilot, atau berhenti karena kebutuhan belum jelas. Catat siapa memeriksa bukti dan kondisi yang akan mengubah keputusan.

Tulisan ini dikembangkan dari cakupan publik AI Fundamentals and Literacy dan rujukan teknis, bukan ulasan seluruh aktivitas kursus atau penilaian vendor nyata. Kemampuan literacy terlihat ketika kita bisa menghubungkan istilah, bukti, dan batas keputusan dengan bahasa yang dimengerti tim.