Model yang menjawab saat tidak tahu bukan fitur. Itu kewajiban dengan nada yang enak. Pada sistem yang saya jalankan, pertanyaan boleh kembali kosong. Perilaku yang berguna adalah kutipan bila bagian itu ada di pustaka, dan penolakan bila tidak.
Pengambilan dulu, kata-kata kemudian
Polanya membosankan dengan sengaja. Ambil pertanyaannya. Temukan bagian yang mungkin menyimpan jawaban. Nilai mereka. Jika tidak satu pun benar-benar menopang klaim, berhenti. Jika satu menopang, tunjukkan bagian itu di samping kalimat yang memakainya. Kalimat bukan sumbernya. Bagian itulah sumbernya. Pembaca yang tidak bisa membuka bagian itu tidak bisa memercayai kalimat, dan tidak seharusnya diminta untuk itu.
Begitulah saya membangun sistem pelatihan yang saya jalankan: bahan masuk, rencana mengarah ke tanggal, jawaban dinilai terhadap sumber, tinjauan datang sebelum bahan terlupakan. Begitu juga seharusnya pertanyaan atas dokumen. Berdasar, atau diam. Menebak terasa membantu dalam demo dan mahal pada minggu pertama seorang pelanggan bertindak atasnya.
| Yang kembali | Yang boleh dikatakan sistem |
|---|---|
| Kutipan yang menopang klaim | Jawabannya, dengan kutipan itu di samping. |
| Kutipan yang hanya berada di dekat | Tidak ada yang pasti. Katakan apa yang kurang. |
| Tidak ada kutipan | Tolak. Jangan isi celah dengan kalimat yang kira-kira. |
| Ekstraksi dengan keyakinan rendah | Jeda untuk seseorang. Jangan bayar model lagi untuk mencoba ulang secara buta. |
Tagihan dan log adalah bagian dari rancangan
Model cloud melihat data. Sebelum itu, alur data ditulis: layanan mana, kunci milik siapa, berapa batas bulanannya. Persetujuan bersifat tegas. Apa pun yang menyentuh pelanggan, harga, atau pesanan menunggu orang. Panggilan dicatat, karena “asisten yang bilang” bukan jejak audit.
Saya tidak menjanjikan bahwa ini menaruh situs di kotak jawaban orang lain. Peringkat adalah mesin lain, dengan insentif yang tidak saya kendalikan. Yang saya kendalikan adalah apakah sistem saya sendiri mengarang.
Kefasihan murah. Produknya adalah kutipan yang bisa Anda buka.
Ambang adalah keputusan produk
Seseorang harus memilih titik di mana “dekat” menjadi “tidak cukup baik”. Saya tidak menyerahkannya pada suasana model. Sebuah bagian melewati batas yang bisa saya jelaskan, atau jawabannya ditahan. Saya lebih suka menjelaskan penolakan kepada pengguna daripada menjelaskan langkah yang dikarang dalam prosedur yang ia ikuti. Batas bisa disetel setelah Anda melihat pertanyaan sungguhan. Ia tidak boleh mulai dari nol, tempat demo suka tinggal, karena demo dinilai dari seberapa sering ia mengatakan sesuatu.
Saat sebuah proses tidak pasti dengan cara lain, ekstrak berkeyakinan rendah dan bukan pustaka kosong, saya jeda untuk orang, bukan membayar percobaan lain yang akan terdengar lebih halus. Lebih halus bukan lebih benar. Log menyimpan percobaan pertama, agar orang melihat apa yang diambil dan apa yang dibuang.
Model dilatih untuk membantu, artinya mereka lebih suka menyelesaikan paragraf. Aplikasi harus lebih kasar daripada model. Ambang, kutipan yang hilang, pengambilan yang kosong: masing-masing adalah cabang yang tidak mengembalikan jawaban dan mencatat alasannya. Jika cabang itu tidak ada, sistem pada akhirnya akan menjawab pertanyaan yang tidak bisa ditopang pustaka, dan akan terdengar yakin.
Pertama kali Anda melihatnya menolak, rasanya seperti bug. Justru sebaliknya. Bug-nya adalah paragraf yang yakin, tanpa tempat untuk diklik.
