Membuat Produk AI Generatif: Hal-Hal yang Perlu Diketahui Terlebih Dahulu

Pendahuluan

AI generatif mudah dicoba, tetapi jauh lebih sulit untuk diubah menjadi produk yang dapat diandalkan oleh orang-orang. Sebuah tim dapat menghubungkan model bahasa ke antarmuka obrolan dalam beberapa hari. Namun, membuat antarmuka tersebut mampu menangani permintaan pelanggan yang sebenarnya, mematuhi izin akses, bekerja dengan data perusahaan, dan memulihkan diri dari jawaban yang salah adalah masalah yang sama sekali berbeda.

Bagi perusahaan yang mempertimbangkan AI generatif untuk aplikasi bisnis, keputusan pertama bukanlah model mana yang akan digunakan. Melainkan apakah masalah tersebut memang memerlukan produk baru sama sekali. Alat AI siap pakai mungkin sudah cukup memenuhi sebagian besar kebutuhan, sementara implementasi khusus lebih masuk akal jika perangkat lunak yang ada tidak dapat mengakomodasi alur kerja yang diperlukan. Perusahaan yang mempertimbangkan opsi terakhir dapat berkonsultasi dengan insinyur AI generatif SysGears untuk mengeksplorasi persyaratan teknis produk yang dibangun berdasarkan kasus penggunaan spesifik mereka.

Produk AI generatif melibatkan jauh lebih dari sekadar menempatkan model di balik antarmuka bermerek perusahaan. Model mungkin menangani bahasa, tetapi bagian lain dari aplikasi menentukan informasi apa yang dapat diaksesnya, apakah dapat berinteraksi dengan perangkat lunak lain, dan apa yang terjadi ketika jawabannya meleset. Keputusan-keputusan tersebut memengaruhi kegunaan produk sama pentingnya dengan pilihan model itu sendiri.

Asisten internal dapat menyesatkan karyawan jika ia mengambil dokumen kebijakan yang sudah usang. Jika diberikan akses ke catatan pelanggan, izin akses menjadi sama pentingnya dengan kualitas jawaban. Jika aplikasi juga dapat mengubah catatan, respons yang meyakinkan namun salah dapat menyebabkan kerugian nyata.

Ini bukanlah detail yang bisa diperbaiki setelah peluncuran. Hal-hal tersebut memengaruhi arsitektur, upaya rekayasa yang terlibat, dan biaya pengembangan AI, termasuk apa yang diperlukan untuk menjaga produk tetap berjalan. Sebuah bisnis harus mempertimbangkan hal-hal tersebut sebelum berkomitmen pada pengembangan, selagi masih ada ruang untuk mempersempit cakupan atau memutuskan bahwa alat yang sudah ada dapat menyelesaikan tugas tersebut.

Mulailah dengan Masalah yang Membutuhkan AI Generatif

Demo yang meyakinkan dapat menyamarkan masalah bisnis yang sebenarnya cukup biasa. Jika karyawan menghabiskan terlalu banyak waktu mencari dokumentasi internal, misalnya, sistem pencarian semantik mungkin sudah cukup. Jika mereka perlu menafsirkan dokumen panjang, mengekstrak detail spesifik, dan menyusun tanggapan menggunakan informasi dari beberapa sumber, model bahasa mungkin memberikan nilai tambah yang lebih substansial.

Perbedaan ini penting sejak awal. AI generatif membuktikan nilainya ketika perangkat lunak harus memahami materi yang berantakan dan tidak terstruktur atau menyusun sesuatu yang bergantung pada konteks. Namun, untuk tugas yang diatur oleh aturan tetap, skrip biasa seringkali lebih murah untuk dijalankan dan lebih mudah dipercaya.

Ambil contoh distributor yang menangani aliran pertanyaan produk yang terus-menerus. Pelanggan mendeskripsikan barang yang sama dengan berbagai cara, sehingga aplikasi AI generatif dapat memahami permintaan mereka, menampilkan spesifikasi yang relevan, dan menyusun balasan. Tingkat stok adalah masalah lain. Data tersebut harus diambil dari catatan inventaris real-time, sementara harga yang dikutip harus mengikuti aturan penetapan harga perusahaan, bukan angka sembarangan yang dihasilkan model.

Pembagian tugas ini perlu dijaga dengan jelas: biarkan model menangani aspek bahasa dan serahkan operasi yang dapat diprediksi kepada perangkat lunak konvensional sejauh mungkin.

Sebelum pengembangan dimulai, tentukan dengan jelas apa yang sebenarnya perlu ditingkatkan. Staf penjualan mungkin membutuhkan waktu lebih singkat untuk menyusun penawaran; pelanggan mungkin mendapatkan jawaban tanpa harus menunggu agen dukungan. Bagaimanapun juga, catat bagaimana proses tersebut berjalan saat ini. Jika tidak, tim bisa saja merayakan penerapan antarmuka AI baru tanpa mengetahui apakah hal itu benar-benar mempermudah pekerjaan.

Membuat vs. Membeli: Seberapa Besar Kontrol yang Sebenarnya Anda Butuhkan?

Keputusan antara membangun atau membeli sering kali disajikan sebagai pilihan antara kepemilikan penuh dan kenyamanan. Dalam praktiknya, ada beberapa opsi di antaranya.

Alat AI siap pakai merupakan titik awal yang masuk akal ketika sebuah bisnis membutuhkan kemampuan yang sudah dikenal, seperti bantuan penulisan, ringkasan rapat, analisis dokumen, atau penelitian umum. Produk-produk ini biasanya memerlukan lebih sedikit pekerjaan teknik, dan vendornya menangani sebagian besar infrastruktur yang mendasarinya. Sebuah perusahaan dapat menguji apakah karyawan menganggap suatu kemampuan berguna tanpa harus terlebih dahulu mendanai proyek pengembangan khusus.

Masalah mulai muncul ketika alat generik harus disesuaikan dengan proses yang tidak dirancang untuknya. Alat tersebut mungkin tidak dapat terintegrasi dengan basis data lama, misalnya, atau menerapkan izin akses yang tepat ketika karyawan memiliki peran yang berbeda-beda. Hasilnya mungkin juga perlu diolah ulang sebelum dapat digunakan oleh sistem bisnis lainnya. API dan opsi konfigurasi dapat membantu menjembatani kesenjangan ini, tetapi tidak selalu dapat mengatasi keunikan alur kerja yang sudah mapan.

Produk AI khusus menjadi lebih dapat dipertahankan ketika alur kerja itu sendiri merupakan keunggulan kompetitif, ketika produk yang ada tidak dapat memenuhi persyaratan material, atau ketika aplikasi tersebut memerlukan integrasi yang erat dengan data eksklusif dan sistem internal.

Pilihan ketiga adalah membangun aplikasi Anda sendiri berdasarkan model yang dihosting oleh penyedia eksternal. Perusahaan mengembangkan antarmuka dan logika di baliknya, mengintegrasikan sistem tersebut ke dalam perangkat lunak yang sudah ada, dan menyiapkan cara sendiri untuk menguji hasilnya. Model itu sendiri diakses melalui API, sehingga tidak perlu melatih model dasar dari awal. Hal ini memberi ruang bagi bisnis untuk menyesuaikan produk dengan alur kerjanya, meskipun tetap bergantung pada harga penyedia, ketersediaan model, dan batasan layanan.

Perbedaan terakhir ini patut diperhatikan. Mengembangkan aplikasi AI khusus dan mengembangkan model AI baru adalah dua hal yang berbeda. Melatih model dasar membutuhkan sumber daya komputasi yang besar, keahlian khusus, data yang sesuai, dan eksperimen berkelanjutan. Sebagian besar bisnis tidak perlu menanggung beban tersebut. Model yang sudah ada, dilengkapi dengan pengambilan data dari dokumen perusahaan atau akses alat yang dirancang dengan cermat, mungkin sudah cukup.

Pilih Arsitektur yang Sesuai dengan Alur Kerja

Setelah kasus bisnis jelas, tantangan berikutnya adalah menentukan bagaimana aplikasi akan beroperasi. Model hanyalah salah satu komponen, dan mungkin bukan komponen yang memakan waktu pengembangan paling banyak.

Untuk asisten dokumen, retrieval-augmented generation (RAG) sering kali layak dipertimbangkan. Alih-alih hanya mengandalkan apa yang dipelajari model selama pelatihan, aplikasi ini mengambil bagian-bagian relevan dari sumber informasi yang disetujui dan menyertakannya dalam prompt. Model kemudian merumuskan jawaban menggunakan materi tersebut.

Jawaban yang didasarkan pada kebijakan internal atau informasi produk terkini bisa jadi lebih relevan, asalkan proses pengambilan data berjalan dengan baik. Namun, hal itu tidak selalu terjamin. Pencarian mungkin saja menampilkan dokumen yang sudah usang, melewatkan peringatan penting, atau memberikan potongan teks kepada model yang kemudian dibaca secara keliru.

Proses pengambilan informasi perlu diuji secara terpisah. Cara dokumen dibagi menjadi bagian-bagian dapat memengaruhi hasil yang ditemukan sistem, dan bahkan hasil pencarian yang baik pun tidak berguna jika berasal dari sumber yang tidak boleh dilihat pengguna. Hak akses karyawan harus diterapkan hingga ke proses pengambilan informasi, bukan diabaikan hanya karena pencarian kebetulan menampilkan materi yang dibatasi. Aplikasi itu sendiri harus menegakkan otorisasi. Model tidak boleh dipercaya untuk mengambil keputusan tersebut.

Penyesuaian (fine-tuning) memiliki tujuan yang berbeda. Hal ini dapat membantu menyesuaikan perilaku model, format respons, atau penanganan pola tugas berulang ketika contoh pelatihan yang sesuai tersedia. Ini bukanlah pengganti langsung untuk proses pengambilan data ketika masalah utamanya adalah akses ke fakta yang terus berubah. Model yang disesuaikan berdasarkan katalog produk tahun lalu tidak akan secara otomatis mengetahui apa yang berubah pagi ini.

Sebuah prompt dan antarmuka API model mungkin sudah cukup untuk aplikasi dengan cakupan yang sempit, setidaknya pada awalnya. Hal ini bergantung pada seberapa dapat diprediksi masukan-masukannya dan apa yang diharapkan sistem lakukan dengan hasilnya. Jika setiap respons perlu dicocokkan dengan kumpulan dokumentasi internal yang besar, proses pengambilan data mungkin menjadi diperlukan; untuk tugas yang lebih sederhana, hal itu justru dapat menambah beban.

Jaga agar versi pertama tetap ringkas dan ujilah pada permintaan nyata, bukan hanya masukan demo yang sudah disempurnakan. Lihat bagaimana model tersebut menangani pertanyaan yang tidak jelas atau informasi yang kurang. Jika model tersebut berpura-pura tahu daripada mengakui adanya celah, hal itu perlu diperbaiki sebelum menambahkan komponen tambahan.