Cara Menambah Ciri AI ke Apl Anda

Untuk menambah ciri AI ke apl anda, panggil API model bahasa besar (LLM) dari pelayan anda: hantar arahan yang jelas bersama data yang berkaitan, dan gunakan apa yang dipulangkan. Kebanyakan ciri yang berguna termasuk dalam salah satu daripada empat corak — meringkaskan, sembang, mengekstrak data berstruktur dan mengelaskan — dan setiap satu ialah beberapa dozen baris kod yang boleh ditulis oleh pembina apl AI untuk anda. Kerja yang menentukan sama ada ciri itu berguna ialah di sekeliling panggilan tersebut: memastikan kunci API berada di pelayan, mengawal kos setiap pengguna, dan menyemak output sebelum anda mempercayainya.

Empat corak di sebalik kebanyakan ciri AI

Pengekstrakan dan pengelasan selalunya paling bernilai tetapi paling kurang kelihatan. Ia diam-diam menjimatkan masa beberapa minit bagi setiap rekod, dan oleh kerana output mempunyai bentuk tetap, anda boleh menyemaknya secara automatik. Sembang paling kelihatan tetapi paling sukar untuk dibetulkan, dan ia mempunyai panduan sendiri: cara membina apl chatbot AI.

Bagaimana ia muat dalam apl anda

Setiap corak mempunyai bentuk yang sama:

1. Pengguna bertindak — klik “Ringkaskan”, muat naik fail, hantar mesej.
2. Bahagian hadapan anda memanggil pelayan anda sendiri, bukan penyedia AI.
3. Pelayan anda membina permintaan: arahan sistem, input pengguna, dan sebarang data yang diperlukan model daripada pangkalan data anda — hanya data yang dibenarkan untuk pengguna ini.
4. Pelayan anda memanggil API LLM dengan kunci yang disimpan dalam pembolehubah persekitaran.
5. Pelayan anda menyemak respons — JSON yang sah, label yang diketahui, panjang yang munasabah — dan menyimpan atau memulangkannya.
6. Bahagian hadapan memaparkannya, distrim teks sambil ia tiba untuk jawapan yang lebih panjang.

Kunci berada di pelayan pada langkah 4 dan tidak sekali-kali sampai ke pelayar. Jika idea API masih baharu, apa itu API ialah pengenalan ringkas, dan cara menggunakan API LLM membincangkan token, model dan kunci dengan lebih mendalam.

Memilih penyedia dan model

Penyedia utama — OpenAI, Anthropic, Google dan lain-lain — semuanya menawarkan API teks dengan bentuk yang hampir serupa. Soalan berguna ketika memilih:

• Kualiti untuk tugas anda. Cuba beberapa contoh sebenar daripada apl anda pada dua atau tiga model. Perbezaannya selalunya lebih jelas pada data anda berbanding penanda aras umum.
• Saiz berbanding kos. Penyedia menawarkan model yang lebih besar dan lebih berkeupayaan, serta model yang lebih kecil, lebih murah dan lebih pantas. Pengelasan dan pengekstrakan mudah sering berfungsi dengan baik pada model kecil; penaakulan panjang atau penulisan yang halus mungkin memerlukan model yang lebih besar.
• Output berstruktur. Untuk pengekstrakan dan pengelasan, pilih ciri API yang membuat model memulangkan JSON yang sepadan dengan skema yang anda berikan, dan bukannya menghuraikan teks bebas.
• Pengendalian data. Baca terma penyedia mengenai sama ada input API disimpan atau digunakan untuk latihan, dan sama ada itu sesuai dengan data yang diberikan pengguna anda kepada anda.
• Had. Akaun baharu selalunya mempunyai had kadar yang lebih rendah; semak sebelum pelancaran.

Nama dan harga model kerap berubah, jadi kod patut membaca nama model daripada konfigurasi dan bukannya mengekodkannya di banyak tempat.

Menambah satu ciri, langkah demi langkah

Ambil contoh konkrit: CRM kecil di mana setiap kenalan mempunyai sejarah nota yang panjang.

1. Simpan kunci. Cipta kunci dalam papan pemuka penyedia anda dan simpan sebagai rahsia di bahagian pelayan, contohnya OPENAI_API_KEY atau ANTHROPIC_API_KEY.

2. Minta satu ciri yang sempit:

Tambahkan butang “Ringkaskan” pada halaman kenalan. Di pelayan, hantar 20 nota terakhir kenalan itu kepada [PENYEDIA] menggunakan rahsia [ENV_NAME], dengan arahan untuk menulis tiga poin: status semasa, soalan terbuka, langkah seterusnya. Hanya sertakan nota yang boleh dilihat oleh pengguna yang log masuk. Tunjukkan keadaan memuatkan, simpan ringkasan dengan cap masa, dan tunjukkan “Tidak dapat meringkaskan buat masa ini” jika panggilan gagal. Jangan sekali-kali hantar kunci ke pelayar.

3. Tambah pengekstrakan di tempat ia menjimatkan menaip:

Apabila pengguna menampal tandatangan e-mel dalam kotak “Tambah pantas”, panggil [PENYEDIA] di pelayan dan pulangkan JSON dengan nama, syarikat, jawatan, e-mel dan telefon, menggunakan ciri output berstruktur penyedia. Sahkan JSON di pelayan, isi borang kenalan baharu dengannya, dan benarkan pengguna mengedit sebelum menyimpan. Biarkan medan kosong dan jangan meneka.

“Benarkan pengguna mengedit sebelum menyimpan” ialah bahagian yang penting: model mencadangkan, orang membuat keputusan.

4. Kelaskan di latar belakang:

Apabila tiket sokongan baharu tiba, kelaskannya kepada tepat satu daripada: bil, pepijat, permintaan ciri, akses akaun, lain-lain. Gunakan model kecil dan kos rendah. Jika respons bukan salah satu label tersebut, simpan “lain-lain”. Paparkan label sebagai tag yang boleh diedit.

5. Uji dengan data sebenar yang tidak kemas — nota panjang, nota kosong, bahasa lain, tandatangan tanpa nombor telefon — dan lihat dua puluh output bersebelahan sebelum melancarkan.

Menulis arahan yang berkesan

Arahan yang anda hantar bersama setiap permintaan (selalunya dipanggil prompt sistem) ialah tempat kualiti datang.

• Nyatakan untuk siapa ia dan apa yang baik. “Ringkasan dibaca oleh jurujual dalam 10 saat sebelum panggilan” memberi model satu sasaran.
• Tetapkan format. Bilangan poin yang tepat, had panjang, medan, label.
• Nyatakan apa yang perlu dilakukan jika tidak pasti. “Jika nota tidak menyebut langkah seterusnya, tulis ‘Tiada langkah seterusnya direkodkan’.” Ini mengurangkan jawapan yang direka.
• Berikan dua atau tiga contoh input dan output yang baik untuk pengekstrakan dan pengelasan.
• Asingkan arahan daripada kandungan pengguna, dan labelkan kandungan pengguna dengan jelas, supaya model dapat membezakannya.

Simpan prompt dalam fail dalam kod anda supaya ia berversi dan boleh disemak seperti kod lain.

Mengawal kos

API LLM mengenakan bayaran mengikut token — ketulan teks kecil — untuk kedua-dua yang anda hantar dan yang dipulangkan. Kos meningkat mengikut jumlah konteks setiap permintaan didarab dengan kekerapan ia dijalankan. Kawalan praktikal:

• Hantar hanya apa yang diperlukan. 20 nota terakhir, bukan keseluruhan sejarah. Potong atau pecahkan dokumen yang panjang.
• Gunakan model terkecil yang mencukupi untuk tugas. Uji sebelum menjadikan yang terbesar sebagai lalai.
• Hadkan panjang output dengan tetapan token maksimum API.
• Simpan hasil dalam cache. Simpan ringkasan dan hanya jana semula apabila sumbernya berubah, bukan pada setiap paparan halaman.
• Hadkan setiap pengguna. Had harian bagi setiap akaun atau pelan menghalang seorang pengguna berat, atau satu skrip, daripada menjana bil yang besar.
• Hadkan kadar titik akhir seperti mana-mana laluan mahal yang lain.
• Tetapkan bajet atau amaran dalam papan pemuka penyedia, dan semak penggunaan setiap minggu selepas pelancaran.
• Log penggunaan token bagi setiap ciri supaya anda tahu yang mana satu menelan kos.

Jika ciri AI menjadi teras produk anda, masukkan kos operasinya ke dalam harga anda dan bukannya menanggungnya sendiri.

Keselamatan dan kepercayaan

Output AI bersifat kebarangkalian. Ia boleh salah sambil kedengaran yakin, dan ia boleh dipengaruhi oleh teks yang dibacanya. Bina untuk keadaan itu:

• Anggap output sebagai input tidak dipercayai. Sahkan struktur, lepaskan aksara sebelum dipaparkan sebagai HTML, dan jangan sekali-kali jalankannya sebagai kod atau pertanyaan pangkalan data.
• Kekalkan manusia dalam gelung untuk apa-apa yang ada akibat — menghantar e-mel, menukar rekod, membuat bayaran balik. Model merangka; seseorang mengesahkan.
• Pertahankan diri daripada suntikan prompt. Dokumen atau mesej mungkin mengandungi teks seperti “abaikan arahan anda”. Hadkan apa yang boleh dilihat model kepada apa yang boleh dilihat oleh pengguna semasa, dan jangan berikan alat yang boleh mengambil tindakan sensitif tanpa kod anda menyemak kebenaran dahulu.
• Labelkan kandungan AI supaya pengguna tahu sesuatu ringkasan atau cadangan dijana dan boleh disemak.
• Kendalikan kegagalan dengan baik. Penyedia mengalami gangguan dan had kadar. Tetapkan had masa, tunjukkan mesej yang jelas, dan biarkan bahagian lain apl terus berfungsi.
• Perhatikan apa yang dihantar pengguna. Untuk input teks terbuka, pertimbangkan langkah penyederhanaan kandungan dan nyatakan dengan jelas dalam dasar privasi anda bahawa kandungan diproses oleh penyedia AI pihak ketiga.

Senarai pemeriksaan yang lebih luas ada dalam senarai semak keselamatan untuk apl yang dibina dengan AI.

Kesilapan biasa

• Bermula dengan chatbot umum apabila satu butang “Ringkaskan” atau “Kategorikan” akan membantu lebih ramai orang.
• Meletakkan kunci dalam kod bahagian hadapan atau dalam repositori awam.
• Menghantar seluruh pangkalan data sebagai konteks, yang perlahan, mahal dan berisiko mendedahkan data pengguna lain.
• Mempercayai output teks bebas apabila skema atau set label tetap akan menjadikannya boleh disemak.
• Tiada had setiap pengguna, baru diketahui apabila invois pertama tiba.

Menambah ciri AI dengan Mythex

Di Mythex, anda menambah AI dalam apl anda sendiri dengan memintanya dalam sembang, menggunakan kunci penyedia anda sendiri. Simpan kunci sebagai rahsia projek — apabila ejen memerlukannya, Mythex menunjukkan kad rahsia dalam sembang supaya anda tidak perlu menampal kunci ke dalam perbualan — dan ejen menulis laluan pelayan, prompt dan antara muka. Penggunaan AI apl anda dicaj oleh penyedia anda, berasingan daripada kredit Mythex yang anda guna untuk membina. Dokumentasi mempunyai prompt permulaan dalam tambah ciri AI dengan kunci API anda sendiri.

Soalan lazim