Pelajaran dari Membangun Bersama LLM Selama 1 Tahun

 (eugeneyan.com)
75 poin oleh xguru 2024-06-10 | 9 komentar | Bagikan ke WhatsApp
  • Pengembangan dengan menggunakan model bahasa besar (LLM) sedang berada pada masa yang menarik
    • Dalam satu tahun terakhir, LLM telah mencapai tingkat yang "cukup baik" untuk aplikasi nyata, dan setiap tahun menjadi lebih baik sekaligus lebih murah
    • Seiring dengan demo-demo di media sosial, diperkirakan sekitar 200 miliar dolar AS akan diinvestasikan ke AI hingga 2025
    • API dari berbagai vendor membuat LLM lebih mudah diakses, sehingga bukan hanya engineer dan ilmuwan ML, tetapi semua orang dapat membangun intelligence ke dalam produk
  • Hambatan untuk membangun dengan AI memang menurun, tetapi membuat produk dan sistem yang efektif di luar sekadar demo tetap sulit
  • Kami telah membangun selama setahun terakhir, dan menemukan banyak kesulitan di sepanjang prosesnya
    • Kami ingin membagikan apa yang kami pelajari agar Anda bisa menghindari kesalahan kami dan beriterasi lebih cepat
  • Tulisan ini terdiri dari tiga bagian:
    1. Tactical (taktis): beberapa praktik untuk prompting, RAG, workflow engineering, evaluasi, dan monitoring
      • Ditulis untuk praktisi yang membangun dengan LLM atau orang yang mengerjakan proyek akhir pekan
    2. Operational (operasional): perhatian organisasi dan keseharian dalam peluncuran produk serta cara membangun tim yang efektif
      • Ditujukan untuk pemimpin produk/teknologi yang ingin melakukan deployment secara berkelanjutan dan andal
    3. Strategic (strategis): pandangan jangka panjang dan gambaran besar serta cara beriterasi, termasuk opini seperti "tidak ada GPU sebelum PMF" dan "fokus pada sistem, bukan model"
      • Ditulis dengan mempertimbangkan para pendiri dan eksekutif
  • Panduan ini bertujuan menjadi panduan praktis untuk membangun produk yang sukses dengan menggunakan LLM
    • Berasal dari pengalaman kami sendiri dan menyajikan contoh dari seluruh industri

[Taktik: inti penggunaan LLM]

  • Di bagian ini, kami membagikan praktik terbaik untuk komponen inti dari stack LLM yang sedang berkembang
    • Termasuk tip prompting untuk meningkatkan kualitas dan reliabilitas, strategi untuk mengevaluasi output, serta ide retrieval augmented generation untuk meningkatkan grounding
    • Kami juga akan mengeksplorasi cara merancang workflow human-in-the-loop

Taktik 1. Prompting

  • Saat mengembangkan aplikasi baru, kami merekomendasikan untuk memulai dengan prompting
    • Pentingnya prompting mudah untuk diremehkan maupun dilebih-lebihkan
    • Cenderung diremehkan karena jika teknik prompting yang tepat digunakan dengan benar, Anda bisa melangkah sangat jauh
    • Cenderung dilebih-lebihkan karena bahkan aplikasi berbasis prompt tetap membutuhkan rekayasa yang cukup besar di sekeliling prompt agar dapat bekerja dengan baik

Fokus untuk memaksimalkan teknik prompting dasar

  • Ada beberapa teknik prompting yang secara konsisten membantu meningkatkan performa di berbagai model dan tugas
    • Di antaranya N-shot prompt + in-context learning, Chain-of-Thought, dan penyediaan resource yang relevan
  • N-shot prompt dan in-context learning
    • Gagasan dari in-context learning melalui N-shot prompt adalah memberi LLM beberapa contoh yang mendemonstrasikan tugas dan menyelaraskan output dengan ekspektasi
    • Jika N terlalu rendah, model bisa terlalu terpaku pada contoh tertentu tersebut sehingga kemampuan generalisasinya menurun
    • Secara empiris, targetkan N ≥ 5, dan jangan takut menggunakan hingga puluhan contoh
    • Contoh harus mewakili distribusi input yang diharapkan
    • Tidak selalu perlu memberikan pasangan input-output secara lengkap; dalam banyak kasus, contoh output yang diinginkan saja sudah cukup
    • Jika menggunakan LLM yang mendukung penggunaan tool, contoh N-shot juga harus menggunakan tool yang ingin Anda lihat dipakai oleh agen
  • Chain-of-Thought (CoT) prompting
    • Dalam CoT prompting, LLM didorong untuk menjelaskan proses berpikirnya sebelum mengembalikan jawaban akhir
    • Ini bisa dianggap seperti menyediakan scratchpad agar LLM tidak harus melakukan semuanya hanya dari memori
    • Pendekatan awalnya hanya dengan menambahkan frasa "mari berpikir langkah demi langkah" sebagai bagian dari instruksi, tetapi kami menemukan bahwa membuat CoT lebih spesifik itu membantu
    • Menambahkan spesifisitas dalam 1–2 kalimat sering kali secara signifikan mengurangi tingkat halusinasi
    • Belakangan ini, muncul keraguan apakah teknik ini sekuat yang diyakini
    • Ada juga perdebatan besar tentang apa sebenarnya yang terjadi selama penalaran saat CoT digunakan
    • Meski begitu, ini tetap teknik yang layak diuji jika memungkinkan
  • Menyediakan resource yang relevan
    • Menyediakan resource yang relevan adalah mekanisme yang kuat untuk memperluas basis pengetahuan model, mengurangi halusinasi, dan meningkatkan kepercayaan pengguna
    • Ini sering dilakukan melalui Retrieval Augmented Generation (RAG)
    • Memberikan potongan teks kepada model yang dapat langsung digunakan dalam respons adalah teknik yang esensial
    • Saat menyediakan resource yang relevan, sekadar menyertakannya saja tidak cukup
      • Jangan lupa untuk menginstruksikan model agar memprioritaskan penggunaan resource, merujuknya secara langsung, dan kadang menyebutkan jika resource tersebut tidak memadai
    • Hal-hal ini membantu "meng-ground" respons agen ke corpus resource

Menstrukturkan input dan output

  • Input dan output yang terstruktur membantu model lebih memahami input dan mengembalikan output yang dapat diintegrasikan secara andal dengan sistem downstream
    • Menambahkan format serialisasi pada input dapat membantu hubungan antartoken dalam konteks, metadata tambahan untuk token tertentu (seperti tipe), atau mengaitkan permintaan dengan contoh serupa dalam data pelatihan model
    • Misalnya, banyak pertanyaan di internet tentang penulisan SQL dimulai dengan mendefinisikan skema SQL
      • Karena itu, prompting yang efektif untuk Text-to-SQL harus mencakup definisi skema yang terstruktur
  • Output terstruktur memiliki tujuan serupa, tetapi menyederhanakan integrasi ke komponen downstream sistem
    • Instructor dan Outlines bekerja dengan baik untuk output terstruktur
      • (gunakan Instructor jika Anda mengimpor SDK API LLM, dan gunakan Outlines jika Anda mengimpor Huggingface untuk model self-hosted)
    • Input terstruktur meningkatkan peluang output yang lebih baik karena mengekspresikan tugas dengan jelas dan mirip dengan format dalam data pelatihan
  • Saat menggunakan input terstruktur, perlu diingat bahwa setiap keluarga LLM memiliki cara yang disukai masing-masing
    • Claude lebih menyukai <xml>, sedangkan GPT lebih menyukai Markdown dan JSON
    • Dengan XML, Anda juga dapat melakukan prefill pada respons Claude dengan menyediakan tag <response>

Buat prompt yang kecil dan sangat baik dalam melakukan satu hal

  • Anti-pattern/code smell yang umum dalam software adalah "God Object", yaitu satu kelas atau fungsi yang melakukan segalanya
    • Hal yang sama berlaku untuk prompt
  • Prompt biasanya dimulai secara sederhana
    • Anda bisa mulai dengan beberapa kalimat instruksi dan beberapa contoh
    • Namun, saat mencoba meningkatkan performa dan menangani lebih banyak edge case, kompleksitas pun bertambah
      • Lebih banyak instruksi, penalaran multi-tahap, puluhan contoh, dan sebagainya ditambahkan
    • Pada akhirnya, prompt yang awalnya sederhana berubah menjadi Frankenstein 2.000 token
      • Selain itu, performa untuk input yang lebih umum dan intuitif justru menurun
      • GoDaddy menempatkan masalah ini sebagai pelajaran nomor satu dari pengalamannya membangun dengan LLM
  • Sebagaimana kita berusaha menjaga sistem dan kode tetap sederhana, hal yang sama juga berlaku untuk prompt
    • Alih-alih menggunakan satu prompt serbaguna untuk peringkas transkrip rapat, Anda bisa membaginya menjadi langkah-langkah seperti berikut
      • Mengekstrak keputusan utama, action item, dan penanggung jawab dalam format terstruktur
      • Memeriksa konsistensi detail yang diekstrak dengan membandingkannya terhadap transkrip asli
      • Menghasilkan ringkasan yang ringkas dari detail terstruktur tersebut
  • Hasilnya, satu prompt dipecah menjadi beberapa prompt yang sederhana, fokus, dan mudah dipahami
    • Dengan pemecahan seperti ini, kini Anda dapat mengiterasi dan mengevaluasi tiap prompt secara terpisah

Membuat token konteks

  • Perlu meninjau ulang dan menantang asumsi tentang seberapa banyak konteks yang benar-benar perlu dikirim ke agen
    • Alih-alih membentuk patung konteks seperti Michelangelo, kita harus mengikis bahan yang tidak perlu agar patungnya terlihat
    • RAG adalah metode yang umum digunakan untuk mengumpulkan semua blok marmer yang berpotensi relevan, tetapi apa yang dilakukan untuk mengekstrak hal yang benar-benar dibutuhkan?
  • Ditemukan bahwa mengambil prompt akhir yang dikirim ke model, lalu meletakkannya di halaman kosong bersama seluruh susunan konteks, meta-prompting, dan hasil RAG, kemudian membacanya, membantu untuk meninjau ulang konteks
    • Dengan metode ini, kita bisa menemukan redundansi, bahasa yang saling bertentangan, dan bagian yang formatnya buruk
  • Optimalisasi penting lainnya adalah struktur konteks
    • Representasi bag-of-docs tidak membantu manusia, jadi jangan berasumsi itu juga baik untuk agen
    • Perlu mempertimbangkan dengan cermat bagaimana menyusun konteks agar hubungan antarsetiap bagiannya terlihat jelas dan ekstraksi informasi menjadi sesederhana mungkin

Taktik 2. Pencarian informasi / RAG

  • Selain prompting, cara efektif lain untuk menyesuaikan LLM adalah dengan menyediakan pengetahuan sebagai bagian dari prompt
    • Ini membuat LLM ter-ground pada konteks yang diberikan, dan digunakan untuk pembelajaran dalam konteks
    • Ini disebut Retrieval-Augmented Generation (RAG)
    • Praktisi menemukan bahwa RAG efektif untuk menyediakan pengetahuan dan meningkatkan output, dengan usaha dan biaya yang jauh lebih rendah dibanding fine-tuning
    • RAG hanya sebaik relevansi, kepadatan informasi, dan detail dokumen yang diambil

Kualitas output RAG bergantung pada kualitas dokumen yang diambil, dan ada beberapa faktor yang bisa dipertimbangkan

  • Ukuran pertama dan paling jelas adalah "relevansi"
    • Ini biasanya dikuantifikasi dengan metrik pemeringkatan seperti Mean Reciprocal Rank (MRR) atau Normalized Discounted Cumulative Gain (NDCG)
    • MRR mengevaluasi seberapa baik sistem menempatkan hasil relevan pertama dalam daftar peringkat, sedangkan NDCG mempertimbangkan relevansi dan posisi semua hasil
    • Keduanya mengukur kinerja sistem dalam memberi peringkat lebih tinggi pada dokumen relevan dan lebih rendah pada dokumen yang tidak relevan
    • Misalnya, jika mengambil ringkasan pengguna untuk membuat ringkasan ulasan film, akan lebih baik jika ulasan untuk film tertentu diberi peringkat lebih tinggi dan ulasan untuk film lain dikeluarkan
    • Seperti pada sistem rekomendasi tradisional, peringkat item yang diambil sangat memengaruhi cara LLM menjalankan tugas downstream
    • Untuk mengukur dampaknya, coba jalankan tugas berbasis RAG dengan item yang diambil diacak, lalu lihat bagaimana performa output RAG
  • Kedua adalah "kepadatan informasi"
    • Jika dua dokumen sama-sama relevan, sebaiknya pilih dokumen yang lebih ringkas dan memiliki lebih sedikit detail yang tidak relevan
    • Kembali ke contoh film, naskah film dan semua ulasan pengguna bisa dianggap relevan dalam arti yang luas
    • Meski begitu, ulasan dengan penilaian tinggi dan ulasan editorial kemungkinan memiliki kepadatan informasi yang lebih tinggi
  • Terakhir, pertimbangkan "tingkat detail" yang disediakan dalam dokumen
    • Bayangkan membangun sistem RAG untuk menghasilkan kueri SQL dari bahasa alami
      • Menyediakan hanya skema tabel dengan nama kolom sebagai konteks mungkin sudah cukup
      • Namun bagaimana jika juga menyertakan deskripsi kolom dan beberapa nilai representatif?
    • Detail tambahan dapat membantu LLM memahami makna tabel dengan lebih baik dan menghasilkan SQL yang lebih akurat

Jangan lupakan pencarian kata kunci, dan gunakan untuk baseline serta pencarian hibrida

  • Karena demo RAG berbasis embedding tersebar luas, mudah untuk melupakan atau mengabaikan puluhan tahun riset dan solusi di bidang pencarian informasi
    • Meski demikian, embedding jelas merupakan alat yang kuat, tetapi bukan solusi serba bisa
  • Kelebihan pencarian berbasis kata kunci
    • Pertama, embedding sangat baik dalam menangkap kemiripan semantik tingkat tinggi, tetapi bisa kesulitan dengan kueri yang lebih spesifik dan berbasis kata kunci, seperti saat pengguna mencari nama (misalnya Ilya), akronim (misalnya RAG), atau ID (misalnya claude-3-sonnet)
      • Pencarian berbasis kata kunci seperti BM25 secara eksplisit dirancang untuk hal ini
      • Pengguna sudah lama menggunakan pencarian berbasis kata kunci sehingga menganggapnya wajar, dan bisa merasa frustrasi jika dokumen yang ingin mereka cari tidak dikembalikan
    • Kedua, lebih intuitif untuk memahami mengapa sebuah dokumen ditemukan lewat pencarian kata kunci
      • Karena kita bisa melihat kata kunci yang cocok dengan kueri
      • Sebaliknya, pencarian berbasis embedding kurang dapat diinterpretasikan
    • Ketiga, pencarian kata kunci umumnya lebih efisien secara komputasi berkat sistem seperti Lucene atau OpenSearch yang telah dioptimalkan selama puluhan tahun dan terbukti di lapangan
  • Dalam sebagian besar kasus, pendekatan hibrida adalah yang paling efektif
    • Gunakan pencocokan kata kunci untuk kecocokan yang jelas, dan embedding untuk sinonim, hipernim, salah eja, serta multimodal (misalnya gambar dan teks)
    • Shortwave pernah membagikan cara mereka membangun pipeline RAG mereka sendiri, termasuk query rewriting, pencarian kata kunci + embedding, pemeringkatan, dan lain-lain

Untuk pengetahuan baru, lebih pilih RAG daripada fine-tuning

  • RAG dan fine-tuning sama-sama dapat digunakan untuk mengintegrasikan informasi baru ke dalam LLM dan meningkatkan performa pada tugas tertentu
    • Jadi, mana yang sebaiknya dicoba lebih dulu?
  • Kelebihan RAG
    • Penelitian terbaru menunjukkan bahwa RAG bisa lebih unggul
    • Dalam satu studi, RAG dibandingkan dengan fine-tuning tanpa pengawasan (juga disebut continual pretraining) pada subset MMLU dan isu-isu terkini
      • RAG secara konsisten menunjukkan performa yang lebih baik daripada fine-tuning, baik untuk pengetahuan yang sudah ditemui selama pelatihan maupun pengetahuan yang benar-benar baru
    • Makalah lain membandingkan RAG dan fine-tuning terawasi pada data set pertanian
      • Hasilnya, peningkatan performa RAG juga lebih besar daripada fine-tuning, terutama pada GPT-4 (lihat tabel 20 di makalah)
    • Selain peningkatan performa, RAG juga memiliki beberapa keunggulan praktis
      • Pertama, menjaga indeks pencarian tetap mutakhir lebih mudah dan murah dibanding continual pretraining atau fine-tuning
      • Kedua, jika ada dokumen bermasalah dalam indeks pencarian yang mengandung konten berbahaya atau bias, dokumen tersebut dapat dengan mudah dihapus atau diperbaiki
    • Selain itu, huruf R dalam RAG memberikan kontrol yang lebih terperinci atas cara dokumen diambil
      • Misalnya, jika meng-host sistem RAG untuk beberapa organisasi, indeks pencarian dapat dipartisi sehingga tiap organisasi hanya bisa mengambil dokumen dari indeks mereka sendiri
      • Dengan begitu, informasi dari satu organisasi tidak akan terekspos secara tidak sengaja ke organisasi lain

Model konteks panjang tidak akan membuat RAG menjadi tidak berguna

  • Seiring Gemini 1.5 menyediakan context window hingga 10 juta token, sebagian orang mulai mempertanyakan masa depan RAG
    • Context window 10 juta token membuat sebagian besar framework RAG yang ada menjadi tidak perlu
      • Cukup masukkan data ke dalam konteks dan ajak model berdialog seperti biasa
    • Bayangkan dampaknya terhadap startup, agen, dan proyek langchain yang menginvestasikan sebagian besar upaya rekayasa mereka ke RAG
      • Jika diringkas dalam satu kalimat, context 10 juta token membunuh RAG
  • Kebutuhan RAG yang berkelanjutan
    • Memang benar bahwa konteks panjang akan menjadi game changer untuk use case seperti analisis banyak dokumen atau chat dengan PDF, tetapi kabar tentang berakhirnya RAG sangat dilebih-lebihkan
      • Pertama, meskipun ada context window 10 juta token, kita tetap membutuhkan cara untuk memilih informasi mana yang akan dimasukkan ke model
      • Kedua, di luar evaluasi needle-in-a-haystack yang sempit, saya belum melihat data yang meyakinkan bahwa model benar-benar dapat bernalar secara efektif atas konteks sebesar itu
      • Karena itu, tanpa retrieval (dan ranking) yang baik, ada risiko membanjiri model dengan informasi yang mengalihkan perhatian atau bahkan memenuhi context window dengan informasi yang sepenuhnya tidak relevan
  • Terakhir, ada masalah biaya
    • Biaya inferensi Transformer meningkat secara kuadrat terhadap panjang konteks (atau secara linear baik dalam ruang maupun waktu)
    • Hanya karena ada model yang mampu membaca seluruh isi Google Drive sebuah organisasi, bukan berarti melakukannya sebelum menjawab setiap pertanyaan adalah ide yang baik
    • Pertimbangkan analogi tentang cara kita menggunakan RAM
      • Ada instance komputasi dengan RAM puluhan terabyte, tetapi kita tetap membaca dan menulis dari disk
  • Jadi, jangan buru-buru membuang RAG ke tempat sampah
    • Pola ini akan tetap berguna meskipun ukuran context window semakin besar

Taktik 3. Tuning dan optimasi workflow

  • Memberi prompt ke LLM hanyalah permulaan
    • Untuk memaksimalkan LLM, kita perlu melampaui satu prompt dan mengadopsi workflow
    • Misalnya, bagaimana tugas tunggal yang kompleks bisa dipecah menjadi beberapa tugas yang lebih sederhana?
    • Kapan fine-tuning atau caching membantu meningkatkan performa dan mengurangi latensi/biaya?
  • Bagian ini membagikan strategi yang sudah terbukti dan contoh nyata untuk membantu mengoptimalkan dan membangun workflow LLM

"Flow" bertahap dan multi-turn dapat memberikan peningkatan performa yang besar

  • Kita sudah tahu bahwa hasil yang lebih baik bisa didapat dengan memecah satu prompt besar menjadi beberapa prompt kecil
    • AlphaCodium adalah contohnya
      • Dengan beralih dari satu prompt ke workflow multistep, akurasi GPT-4 (pass@5) pada CodeContests meningkat dari 19% menjadi 44%
    • Workflow tersebut mencakup
      • Memikirkan masalah
      • Bernalar terhadap tes publik
      • Menghasilkan solusi yang mungkin
      • Memberi peringkat pada solusi yang mungkin
      • Menghasilkan tes sintetis
      • Mengiterasi solusi terhadap tes publik dan sintetis
  • Tugas kecil dengan tujuan yang jelas menghasilkan prompt agen atau flow terbaik
    • Tidak semua prompt agen perlu meminta output terstruktur, tetapi output terstruktur sangat membantu sebagai antarmuka dengan sistem yang mengoordinasikan interaksi agen dengan lingkungannya
  • Hal-hal yang layak dicoba
    • Tahap perencanaan eksplisit yang dispesifikasikan seketat mungkin
      • Pertimbangkan untuk memilih dari rencana yang telah didefinisikan sebelumnya
    • Menulis ulang prompt pengguna asli menjadi prompt agen
      • Berhati-hatilah karena kehilangan informasi bisa terjadi dalam proses ini
    • Perilaku agen sebagai rantai linear, DAG, dan state machine
      • Berbagai dependensi dan hubungan logika mungkin lebih atau kurang cocok untuk skala yang berbeda
      • Bisakah optimasi performa dicapai di berbagai arsitektur tugas?
    • Verifikasi rencana
      • Rencana dapat mencakup panduan tentang cara mengevaluasi respons agen lain agar hasil akhir berfungsi dengan baik
    • Prompt engineering dengan state upstream yang tetap
      • Pastikan prompt agen dievaluasi terhadap berbagai variasi yang mungkin terjadi sebelumnya

Untuk saat ini, prioritaskan workflow deterministik

  • AI agent dapat merespons permintaan pengguna dan lingkungan secara dinamis, tetapi sifat non-deterministiknya membuat deployment menjadi sulit
    • Setiap langkah yang dilakukan agen berpotensi gagal, dan kemungkinan pulih dari kesalahan rendah
    • Karena itu, peluang agen untuk menyelesaikan tugas multistep dengan sukses menurun secara eksponensial seiring bertambahnya jumlah langkah
    • Akibatnya, tim yang membangun agen kesulitan menerapkan agen yang andal
  • Pendekatan yang menjanjikan adalah memiliki sistem agen yang menghasilkan rencana deterministik dan mengeksekusinya dengan cara yang terstruktur dan dapat direproduksi
    • Pada tahap pertama, ketika diberi tujuan tingkat tinggi atau prompt, agen menghasilkan rencana
    • Lalu rencana tersebut dieksekusi secara deterministik
    • Ini memungkinkan setiap langkah menjadi lebih dapat diprediksi dan lebih andal
    • Keuntungan
      • Rencana yang dihasilkan dapat digunakan sebagai sampel few-shot untuk memberi prompt pada agen atau untuk fine-tuning
      • Eksekusi deterministik membuat sistem lebih andal sehingga pengujian dan debugging menjadi lebih mudah. Selain itu, kegagalan dapat ditelusuri ke langkah tertentu dalam rencana
      • Rencana yang dihasilkan dapat direpresentasikan sebagai directed acyclic graph (DAG), sehingga lebih mudah dipahami dan disesuaikan dengan situasi baru dibanding prompt statis
  • Pembuat agen yang paling sukses mungkin adalah orang yang punya pengalaman kuat dalam mengelola engineer junior
    • Karena proses pembuatan rencana mirip dengan cara memberi arahan dan mengelola junior
    • Sama seperti kita memberi junior tujuan yang jelas dan rencana yang spesifik alih-alih arahan yang ambigu dan terbuka, hal yang sama juga harus dilakukan pada agen
  • Pada akhirnya, kunci agen yang andal dan benar-benar bekerja kemungkinan besar ditemukan dengan
    • mengadopsi pendekatan yang lebih terstruktur dan deterministik, dan
    • mengumpulkan data untuk memperbaiki prompt dan melakukan fine-tuning model
  • Tanpa ini, Anda akan membangun agen yang kadang-kadang bisa bekerja sangat baik, tetapi secara rata-rata mengecewakan pengguna dan menurunkan retensi

Mendapatkan output yang beragam melampaui parameter temperature

  • Misalkan ada tugas yang membutuhkan keragaman pada output LLM
    • Anda mungkin sedang menulis pipeline LLM yang menyarankan produk untuk dibeli dari katalog dengan mempertimbangkan daftar produk yang pernah dibeli pengguna sebelumnya
    • Saat menjalankan prompt beberapa kali, Anda mungkin menyadari bahwa rekomendasi yang dihasilkan terlalu mirip
    • Karena itu, Anda bisa menaikkan parameter Temperature pada permintaan LLM
  • Menaikkan parameter temperature membuat respons LLM menjadi lebih beragam
    • Saat sampling, distribusi probabilitas token berikutnya menjadi lebih rata, sehingga token yang biasanya lebih kecil kemungkinannya dipilih jadi lebih sering dipilih
  • Namun, saat menaikkan temperature, beberapa failure mode terkait keragaman output bisa muncul
    • Misalnya, beberapa produk dalam katalog mungkin relevan tetapi tidak dihasilkan oleh LLM
    • Jika LLM cenderung mengikuti apa yang dipelajarinya saat training, sejumlah kecil produk yang sama bisa menjadi terlalu terwakili dalam output
    • Jika temperature terlalu tinggi, output dapat dihasilkan dengan merujuk pada produk yang tidak ada (atau isi yang tidak masuk akal)
  • Menaikkan temperature juga tidak menjamin bahwa LLM akan melakukan sampling output dari distribusi probabilitas yang Anda harapkan (misalnya acak seragam)
  • Meski demikian, ada trik lain untuk meningkatkan keragaman output
    • Cara paling sederhana adalah menyesuaikan elemen dalam prompt
      • Misalnya, jika template prompt memuat daftar item seperti riwayat pembelian sebelumnya, mengacak urutan item-item tersebut setiap kali dimasukkan ke prompt dapat membuat perbedaan yang signifikan
    • Menyimpan daftar singkat output terbaru juga membantu mencegah duplikasi
      • Dalam contoh rekomendasi produk, Anda dapat menginstruksikan LLM untuk menghindari menyarankan item dari daftar terbaru ini, atau membuat respons lebih beragam dengan menolak output yang mirip dengan saran terbaru lalu melakukan resampling
    • Strategi efektif lainnya adalah memvariasikan ungkapan yang digunakan dalam prompt
      • Misalnya, memasukkan frasa seperti "pilih item yang kemungkinan ingin digunakan pengguna secara rutin" atau "pilih produk yang kemungkinan akan direkomendasikan pengguna kepada temannya" dapat menggeser fokus dan memengaruhi keragaman produk yang direkomendasikan

Caching diremehkan

  • Caching mengurangi biaya dengan menghilangkan kebutuhan untuk menghitung ulang respons untuk input yang sama dan menghapus latensi generasi
    • Selain itu, jika respons sebelumnya sudah melalui guardrailing, kita dapat menyajikan respons yang sudah tervalidasi tersebut untuk mengurangi risiko menyajikan konten yang berbahaya atau tidak pantas
  • Pendekatan sederhana terhadap caching adalah menggunakan ID unik untuk item yang sedang diproses, misalnya saat merangkum artikel baru atau ulasan produk
    • Ketika permintaan masuk, kita dapat memeriksa apakah ringkasan sudah ada di cache
      • Jika ya, dapat langsung dikembalikan; jika tidak, maka dibuat, di-guardrail, disajikan, lalu disimpan ke cache untuk permintaan berikutnya
  • Untuk kueri yang lebih terbuka, kita dapat meminjam teknik dari ranah search yang memanfaatkan caching bahkan untuk input terbuka
    • Fitur seperti autocomplete dan koreksi ejaan membantu menormalisasi input pengguna untuk meningkatkan cache hit rate

Kapan finetune (fine-tuning) diperlukan

  • Ada beberapa tugas yang bahkan prompt yang dirancang secerdas apa pun tetap tidak cukup
    • Misalnya, bahkan setelah prompt engineering yang signifikan, sistem mungkin masih jauh dari mampu mengembalikan output yang andal dan berkualitas tinggi
    • Dalam kasus seperti ini, model mungkin perlu di-fine-tune untuk tugas tertentu
  • Contoh kasus fine-tuning yang berhasil
    • Honeycomb Natural Language Query Assistant
      • Pada awalnya, “manual pemrograman” diberikan di dalam prompt bersama contoh n-shot untuk in-context learning
      • Ini bekerja cukup baik, tetapi dengan fine-tuning model dapat menghasilkan output yang lebih baik terhadap sintaks dan aturan bahasa yang spesifik domain
    • Rechat Lucy
      • LLM harus menghasilkan respons dalam format yang sangat spesifik yang menggabungkan data terstruktur dan tidak terstruktur agar frontend dapat merendernya dengan benar
      • Fine-tuning sangat penting agar ini dapat bekerja secara konsisten
  • Fine-tuning bisa efektif, tetapi disertai biaya yang besar
    • Kita perlu memberi anotasi pada data fine-tuning, melakukan fine-tuning dan evaluasi model, lalu pada akhirnya melakukan self-hosting
    • Karena itu, perlu dipertimbangkan apakah biaya awal yang lebih tinggi memang sepadan
  • Jika dengan prompting Anda sudah bisa mencapai 90%, mungkin tidak layak berinvestasi pada fine-tuning
    • Namun, jika memutuskan untuk melakukan fine-tuning, Anda dapat membuat dan melakukan fine-tuning pada data sintetis atau melakukan bootstrap dari data open source untuk mengurangi biaya pengumpulan data beranotasi manusia

Taktik 4. Evaluasi dan monitoring

  • Evaluasi LLM bisa menjadi ladang ranjau
    • Input dan output LLM adalah teks arbitrer, dan tugas yang ditetapkan juga beragam
    • Meski demikian, evaluasi yang ketat dan cermat tetap penting
      • Bukan kebetulan bahwa para pemimpin teknis OpenAI ikut serta dalam evaluasi dan memberikan umpan balik untuk evaluasi individual
  • Evaluasi aplikasi LLM memerlukan beragam definisi dan reduksi
    • Ini bisa semata-mata berupa unit test, atau lebih mirip observability, atau sekadar data science
    • Kami menemukan bahwa semua sudut pandang ini bermanfaat
  • Di bagian ini, kami membagikan pelajaran tentang hal-hal penting dalam membangun pipeline evaluasi dan monitoring

Buat beberapa unit test berbasis assertion dari sampel input-output nyata

  • Buat unit test (yaitu assertion) dari sampel input dan output di production, lalu tetapkan ekspektasi terhadap output berdasarkan setidaknya 3 kriteria
    • Tiga kriteria mungkin terdengar arbitrer, tetapi ini adalah angka yang praktis untuk memulai
      • Jika lebih sedikit, tugasnya mungkin belum cukup terdefinisi atau terlalu terbuka seperti chatbot serbaguna
    • Unit test atau assertion ini harus dipicu oleh perubahan pada pipeline, seperti pengeditan prompt, penambahan konteks baru melalui RAG, atau modifikasi lainnya
  • Pertimbangkan untuk memulai dari assertion yang menentukan frasa atau ide yang harus disertakan atau dikecualikan dari setiap respons
    • Pertimbangkan juga pemeriksaan apakah jumlah kata, item, atau kalimat berada dalam rentang yang diharapkan
    • Untuk jenis generasi lain, bentuk assertion bisa berbeda
      • Misalnya, dalam execution evaluation, yang merupakan metode kuat untuk menilai code generation, kode yang dihasilkan dijalankan lalu diperiksa apakah status runtime sudah cukup memenuhi permintaan pengguna
  • Sebagai contoh, jika pengguna meminta fungsi baru bernama foo, maka setelah menjalankan kode yang dihasilkan agen, kita harus bisa memanggil foo
  • Salah satu tantangan execution evaluation adalah bahwa kode agen sering kali meninggalkan runtime dalam bentuk yang sedikit berbeda dari kode target
    • Meringankan assertion menjadi asumsi terlemah yang masih dapat dipenuhi oleh jawaban yang valid bisa menjadi pendekatan yang efektif
  • Menggunakan produk sebagaimana dimaksud untuk pelanggan (yaitu, “dogfooding”) dapat memberikan wawasan tentang mode kegagalan pada data nyata
    • Pendekatan ini bukan hanya membantu mengidentifikasi kelemahan potensial, tetapi juga menyediakan sumber sampel production yang berguna untuk diubah menjadi evaluasi

LLM-as-Judge bisa bekerja (sampai batas tertentu), tetapi bukan solusi untuk semua hal

  • LLM-as-Judge adalah pendekatan yang menggunakan LLM kuat untuk mengevaluasi output LLM lain, dan bagi sebagian orang pendekatan ini dipandang dengan skeptis
  • Meski begitu, jika diimplementasikan dengan baik, LLM-as-Judge dapat mencapai korelasi yang signifikan dengan penilaian manusia, dan setidaknya membantu membangun informasi awal tentang bagaimana prompt atau teknik baru mungkin akan bekerja
    • Khususnya saat melakukan perbandingan berpasangan (misalnya kelompok kontrol vs kelompok perlakuan), LLM-as-Judge umumnya menangkap arah dengan benar, meskipun besar kemenangan/kekalahannya bisa berisik
  • Saran untuk memaksimalkan penggunaan LLM-as-Judge
    • Gunakan perbandingan berpasangan
      • Alih-alih meminta LLM menilai satu output pada skala Likert, sajikan dua opsi dan minta memilih mana yang lebih baik
      • Ini cenderung menghasilkan hasil yang lebih stabil
    • Kendalikan position bias
      • Urutan opsi yang disajikan dapat membias keputusan LLM
      • Untuk menguranginya, lakukan setiap perbandingan berpasangan dua kali dan tukar urutan pasangan pada setiap kali
      • Setelah ditukar, kemenangan harus diatribusikan ke opsi yang benar
    • Izinkan hasil seri
      • Dalam beberapa kasus, kedua opsi bisa sama-sama baik
      • Karena itu, izinkan LLM menyatakan seri agar tidak perlu memilih pemenang secara acak
    • Gunakan Chain-of-Thought
      • Meminta LLM menjelaskan keputusannya sebelum menyajikan preferensi akhir dapat meningkatkan keandalan evaluasi
      • Sebagai bonus, ini memungkinkan penggunaan LLM yang lebih lemah tetapi lebih cepat sambil tetap memperoleh hasil yang serupa
      • Karena bagian pipeline ini sering berjalan dalam mode batch, latensi tambahan dari CoT tidak menjadi masalah
    • Kendalikan panjang respons
      • LLM cenderung bias terhadap respons yang lebih panjang
      • Untuk menguranginya, pastikan panjang pasangan respons serupa
  • Penerapan LLM-as-Judge yang sangat kuat adalah untuk memeriksa strategi prompt baru terhadap regresi
    • Jika Anda telah melacak kumpulan hasil production, terkadang Anda dapat menjalankan ulang contoh-contoh production tersebut dengan strategi prompt baru dan menggunakan LLM-as-Judge untuk dengan cepat menilai di mana strategi baru mungkin mengalami kesulitan
  • Contoh pendekatan sederhana tetapi efektif untuk LLM-as-Judge
    • Cukup catat respons LLM, kritik dari judge (yaitu CoT), dan hasil akhirnya
    • Lalu tinjau bersama para pemangku kepentingan untuk mengidentifikasi area yang perlu ditingkatkan
    • Melalui 3 iterasi, tingkat kesesuaian manusia dan LLM meningkat dari 68% menjadi 94%
  • Namun, LLM-as-Judge bukan solusi untuk semua hal
    • Bahkan model terkuat pun memiliki aspek linguistik halus yang tidak dapat dievaluasi secara andal
  • Kami juga menemukan bahwa classifier dan reward model tradisional dapat mencapai akurasi yang lebih tinggi daripada LLM-as-Judge dengan biaya dan latensi yang lebih rendah
    • Untuk code generation, LLM-as-Judge bisa lebih lemah dibanding strategi evaluasi yang lebih langsung seperti execution evaluation

“Tes magang” untuk menilai hasil generasi

  • Saat mengevaluasi hasil generasi, ada baiknya menggunakan "tes magang" seperti berikut
    • Jika kita mengambil input yang akurat untuk model bahasa beserta konteksnya, lalu memberikannya sebagai tugas kepada mahasiswa rata-rata di jurusan terkait, apakah mereka akan berhasil?
    • Berapa lama waktu yang dibutuhkan?
  • Jika jawabannya tidak
    • Jika karena LLM kekurangan pengetahuan yang dibutuhkan, pertimbangkan cara memperkaya konteks
    • Jika tidak bisa diselesaikan bahkan setelah konteks diperbaiki, ini mungkin tugas yang terlalu sulit untuk LLM modern
  • Jika jawabannya ya tetapi memakan waktu
    • Anda bisa mencoba mengurangi kompleksitas tugas
      • Apakah bisa diuraikan?
      • Aspek mana dari tugas yang bisa dibuat lebih berbasis templat?
  • Jika jawabannya ya dan bisa dilakukan dengan cepat
    • Saat menggali data
      • Apa yang salah dilakukan model?
      • Bisakah ditemukan pola kegagalan?
    • Coba minta model menjelaskan dirinya sendiri sebelum atau sesudah merespons

Terlalu berfokus pada evaluasi tertentu dapat menurunkan kinerja secara keseluruhan

"Ketika metrik pengukuran menjadi tujuan, ia tidak lagi menjadi metrik pengukuran yang baik." - Hukum Goodhart

  • Contohnya adalah evaluasi Needle-in-a-Haystack (NIAH)
    • Evaluasi aslinya membantu mengukur recall model saat ukuran konteks membesar, dan melihat bagaimana posisi jarum memengaruhi recall
    • Namun, ini terlalu ditekankan hingga diperkenalkan sebagai Figure 1 dalam laporan Gemini 1.5
    • Evaluasi ini melibatkan penyisipan frasa tertentu ("The special magic {city} number is: {number}") ke dalam dokumen panjang yang mengulang esai Paul Graham, lalu meminta model mengingat angka ajaib tersebut
  • Beberapa model mencapai recall yang nyaris sempurna, tetapi masih dipertanyakan apakah NIAH benar-benar mencerminkan kemampuan penalaran dan recall yang dibutuhkan aplikasi nyata
  • Pertimbangkan skenario yang lebih praktis
    • Jika diberi transkrip rapat berdurasi 1 jam, apakah LLM dapat merangkum keputusan utama dan langkah selanjutnya, serta mengatribusikan setiap item dengan benar kepada penanggung jawab terkait?
    • Tugas ini lebih realistis karena melampaui hafalan sederhana; ia juga mempertimbangkan kemampuan memahami diskusi kompleks, mengidentifikasi informasi yang relevan, dan menyintesis ringkasan
  • Contoh evaluasi NIAH yang lebih praktis
    • Menggunakan transkrip panggilan video dokter-pasien dan mengajukan pertanyaan kepada LLM tentang obat pasien
    • Juga mencakup NIAH yang lebih menantang, seperti menyisipkan frasa tentang bahan acak yang dibutuhkan untuk topping pizza, misalnya kurma yang direndam espresso, lemon, dan keju kambing
    • Recall untuk tugas obat sekitar 80%, sedangkan untuk tugas pizza 30%
  • Terlalu menekankan evaluasi NIAH dapat menurunkan kinerja pada tugas ekstraksi dan peringkasan
    • Karena LLM seperti ini di-fine-tune agar memperhatikan setiap kalimat, mereka bisa mulai memperlakukan detail yang tidak relevan dan distraksi sebagai sesuatu yang penting
    • Hal itu kemudian bisa masuk ke output akhir (bahkan ketika seharusnya tidak!)
  • Ini juga dapat berlaku pada evaluasi dan use case lain
    • Misalnya ringkasan
      • Jika terlalu menekankan konsistensi faktual, ringkasan yang dihasilkan bisa menjadi kurang spesifik (dan karena itu lebih kecil kemungkinan bertentangan dengan fakta) serta kurang relevan
      • Sebaliknya, jika terlalu menekankan gaya penulisan dan kefasihan, bisa dihasilkan bahasa ala pemasaran yang lebih bombastis yang dapat menyebabkan ketidaksesuaian faktual

Sederhanakan anotasi menjadi tugas biner atau perbandingan berpasangan

  • Memberikan umpan balik terbuka untuk output model atau menilainya dengan skala Likert merupakan hal yang berat secara kognitif
    • Akibatnya, data yang dikumpulkan menjadi lebih berisik karena variabilitas antar penilai manusia, sehingga kurang berguna
  • Pendekatan yang lebih efektif adalah menyederhanakan tugas dan mengurangi beban kognitif anotator
    • Dua tugas yang bekerja dengan baik adalah klasifikasi biner dan perbandingan berpasangan
  • Dalam klasifikasi biner, anotator diminta membuat penilaian ya/tidak yang sederhana terhadap output model
    • Misalnya, apakah ringkasan yang dihasilkan konsisten secara faktual dengan dokumen sumber, apakah respons yang diusulkan relevan, apakah mengandung unsur berbahaya, dan sebagainya
    • Dibandingkan skala Likert, keputusan biner lebih akurat, lebih konsisten antar penilai, dan throughput-nya lebih tinggi
    • Seperti cara Doordash menyiapkan antrean pelabelan untuk memberi tag pada item menu melalui serangkaian pertanyaan ya/tidak
  • Dalam perbandingan berpasangan (Pairwise Comparison), anotator menerima sepasang respons model dan ditanya mana yang lebih baik
    • Karena bagi manusia lebih mudah mengatakan "A lebih baik daripada B" daripada memberi skor terpisah untuk A atau B, ini menghasilkan anotasi yang lebih cepat dan lebih andal (dibandingkan skala Likert)
  • Dalam meetup Llama2, Thomas Scialom, salah satu penulis makalah Llama2, mengonfirmasi bahwa perbandingan berpasangan lebih cepat dan lebih murah daripada mengumpulkan data supervised fine-tuning seperti respons tertulis
    • Biaya yang pertama adalah $3.5 per unit dan yang kedua $25 per unit

Evaluasi tanpa referensi (reference-free) dan guardrail dapat digunakan secara saling menggantikan

  • Guardrail membantu menangkap konten yang tidak pantas atau berbahaya, sementara evaluasi membantu mengukur kualitas dan akurasi output model
    • Untuk evaluasi tanpa referensi, ini bisa dilihat sebagai dua sisi dari mata uang yang sama
      • Evaluasi tanpa referensi adalah evaluasi yang dapat menilai kualitas output hanya dari prompt input dan respons model, tanpa bergantung pada reference "golden" seperti jawaban yang ditulis manusia
  • Contoh evaluasi tanpa referensi: evaluasi ringkasan
    • Untuk menilai konsistensi faktual dan relevansi ringkasan, cukup mempertimbangkan dokumen input
    • Jika ringkasan mendapat skor rendah pada metrik-metrik ini, Anda dapat memilih untuk tidak menampilkannya kepada pengguna, sehingga evaluasi efektif digunakan sebagai guardrail
  • Evaluasi "terjemahan" tanpa referensi:
    • Kualitas terjemahan dapat dinilai tanpa referensi terjemahan buatan manusia, sehingga kembali bisa digunakan sebagai guardrail

LLM tetap mengembalikan output bahkan ketika seharusnya tidak

  • Tantangan utama saat bekerja dengan LLM adalah bahwa LLM sering menghasilkan output bahkan ketika seharusnya tidak
    • Ini dapat berujung pada respons yang tidak berbahaya tetapi tidak bermakna, atau cacat yang lebih serius seperti konten berbahaya atau berisiko
    • Misalnya, ketika diminta mengekstrak atribut atau metadata tertentu dari dokumen, LLM dapat dengan percaya diri mengembalikan nilai meskipun nilai tersebut sebenarnya tidak ada
    • Atau model bisa merespons dalam bahasa selain Inggris karena konteks yang diberikan berisi dokumen non-Inggris
  • Anda dapat memberi prompt agar LLM mengembalikan respons seperti "tidak berlaku" atau "tidak diketahui", tetapi ini tidak sempurna
    • Bahkan ketika log probability tersedia, itu tetap merupakan indikator yang buruk untuk kualitas output
      • Log probability menunjukkan kemungkinan token muncul dalam output, tetapi tidak mencerminkan akurasi teks yang dihasilkan
    • Bahkan, untuk model instruction-tuned yang dilatih untuk merespons kueri dan menghasilkan respons yang koheren, log probability bisa tidak terkalibrasi dengan baik
      • Karena itu, log probability yang tinggi dapat menunjukkan bahwa output lancar dan koheren, tetapi bukan berarti akurat atau relevan
  • Prompt engineering yang cermat bisa membantu sampai batas tertentu, tetapi harus dilengkapi dengan guardrail yang kuat untuk mendeteksi dan memfilter/menghasilkan ulang output yang tidak diinginkan
    • Misalnya, OpenAI menyediakan API moderasi konten yang dapat mengidentifikasi respons tidak aman seperti ujaran kebencian, self-harm, atau output seksual
    • Demikian pula, ada banyak paket untuk mendeteksi personally identifiable information (PII)
  • Salah satu keuntungan guardrail adalah relatif tidak bergantung pada use case, sehingga dapat diterapkan secara luas pada semua output dalam bahasa tertentu
    • Selain itu, dengan retrieval yang presisi, jika tidak ada dokumen yang relevan, sistem dapat secara tegas menjawab "saya tidak tahu"
  • LLM juga bisa gagal menghasilkan output ketika output sebenarnya diharapkan
    • Ini dapat terjadi karena berbagai alasan, mulai dari masalah sederhana seperti latensi tinggi dari penyedia API hingga masalah yang lebih kompleks seperti output diblokir oleh filter moderasi konten
  • Karena itu, penting untuk mencatat input secara konsisten dan juga (potensi tidak adanya output) untuk debugging dan monitoring

Halusinasi (Hallucination) adalah masalah yang persisten

  • Masalah keamanan konten atau cacat PII jarang terjadi karena mendapat banyak perhatian, sedangkan ketidaksesuaian faktual terus bertahan dan lebih sulit dideteksi
    • Ini lebih sering terjadi, dengan tingkat kejadian dasar 5–10%, dan menurut yang dipelajari dari penyedia LLM, menurunkannya hingga di bawah 2% bisa jadi sulit bahkan untuk tugas sederhana seperti peringkasan
  • Untuk mengatasinya, prompt engineering (upstream generasi) dapat digabungkan dengan guardrail ketidaksesuaian faktual (downstream generasi)
    • Dalam prompt engineering, teknik seperti CoT membantu mengurangi halusinasi dengan membuat LLM menjelaskan penalarannya sebelum mengembalikan output akhir
    • Setelah itu, guardrail ketidaksesuaian faktual dapat diterapkan untuk menilai kefaktualan ringkasan dan memfilter atau menghasilkan ulang halusinasi
  • Dalam beberapa kasus, halusinasi dapat dideteksi secara deterministik
    • Saat menggunakan resource dari pencarian RAG, jika output terstruktur dan resource dapat diidentifikasi, seharusnya dimungkinkan untuk memeriksa secara manual apakah output tersebut bersumber dari konteks input

[Operasional: Masalah Harian (Day-to-Day) dan Organisasi ]

Operasional 1. Data

  • Seperti kualitas bahan menentukan rasa masakan, kualitas data input membatasi performa sistem machine learning
  • Selain itu, data output adalah satu-satunya cara untuk mengetahui apakah produk benar-benar berfungsi
  • Semua penulis mencermati input dan output selama beberapa jam setiap minggu untuk lebih memahami distribusi data (mode, edge case, keterbatasan model)

Memeriksa bias pengembangan-produksi

  • Dalam pipeline machine learning tradisional, penyebab umum kesalahan adalah training-serving skew
    • Ini terjadi ketika data yang digunakan untuk pelatihan berbeda dari data yang dihadapi model di produksi
  • Karena LLM dapat digunakan tanpa pelatihan atau fine-tuning, memang tidak ada set pelatihan, tetapi masalah serupa berupa bias data pengembangan-produksi tetap muncul
    • Pada dasarnya, data yang digunakan untuk menguji sistem selama pengembangan harus mencerminkan data yang akan dihadapi sistem di produksi
      • Jika tidak, akurasi di produksi dapat menurun
  • Bias pengembangan-produksi pada LLM dapat dibagi menjadi dua jenis: bias struktural dan bias berbasis konten
    • Bias struktural mencakup masalah seperti ketidakcocokan format, misalnya perbedaan antara dictionary JSON dengan nilai berbentuk daftar dan daftar JSON, casing yang tidak konsisten, serta kesalahan seperti typo atau fragmen kalimat
      • Kesalahan semacam ini dapat menyebabkan performa model yang tidak dapat diprediksi karena berbagai LLM dilatih pada format data tertentu dan prompt bisa sangat sensitif terhadap perubahan kecil
    • Bias berbasis konten atau “semantik” mengacu pada perbedaan makna atau konteks dalam data
  • Seperti pada ML tradisional, mengukur bias secara berkala antara pasangan input-output LLM itu berguna
    • Metrik sederhana seperti panjang input dan output atau persyaratan format tertentu (misalnya JSON atau XML) adalah cara mudah untuk melacak perubahan
  • Untuk deteksi bias yang lebih “lanjut”, pertimbangkan mengelompokkan embedding dari pasangan input-output untuk mendeteksi bias semantik, seperti perubahan topik yang dibicarakan pengguna yang dapat menunjukkan bahwa pengguna sedang menjelajahi area yang sebelumnya belum pernah terekspos ke model
  • Saat menguji perubahan seperti prompt engineering, pastikan holdout dataset tetap mutakhir dan mencerminkan jenis interaksi pengguna yang paling baru
    • Misalnya, jika typo umum ditemukan pada input produksi, typo tersebut juga harus ada dalam data holdout
  • Lebih dari sekadar mengukur bias dengan angka, bermanfaat juga melakukan evaluasi kualitatif terhadap output
    • Meninjau output model secara rutin (praktik yang secara informal dikenal sebagai “vibe check”) membantu memastikan bahwa hasilnya sesuai harapan dan tetap relevan dengan kebutuhan pengguna
  • Mengintegrasikan nondeterminisme ke dalam pemeriksaan bias juga berguna
    • Dengan menjalankan pipeline beberapa kali untuk setiap input dalam test dataset dan menganalisis semua output, peluang untuk menangkap anomali yang hanya sesekali muncul menjadi lebih tinggi

Memeriksa sampel input-output LLM setiap hari

  • LLM bersifat dinamis dan terus berevolusi
    • Terlepas dari kemampuan zero-shot yang mengesankan dan output yang sering terasa memuaskan, mode kegagalan LLM sangat sulit diprediksi
  • Untuk tugas yang disesuaikan, meninjau sampel data secara berkala sangat penting guna membangun pemahaman intuitif tentang performa LLM
    • Pasangan input-output dari produksi adalah “benda nyata, tempat nyata” (genchi genbutsu) untuk aplikasi LLM, dan tidak tergantikan
  • Riset terbaru menekankan bahwa semakin banyak data yang berinteraksi dengan pengembang, semakin berubah pula persepsi mereka tentang output yang “baik” dan “buruk” (yakni criteria drift)
    • Pengembang dapat menetapkan sebagian kriteria untuk mengevaluasi output LLM sejak awal, tetapi kriteria yang telah ditentukan sebelumnya ini sering kali tidak lengkap
  • Misalnya, selama proses pengembangan, prompt dapat diperbarui untuk meningkatkan probabilitas respons yang baik dan menurunkan probabilitas respons yang buruk
    • Proses berulang berupa evaluasi, evaluasi ulang, dan pembaruan kriteria ini diperlukan karena sulit memprediksi perilaku LLM maupun preferensi manusia tanpa mengamati output secara langsung
  • Untuk mengelola ini secara efektif, input dan output LLM harus dicatat
    • Memeriksa sampel log ini setiap hari memungkinkan identifikasi dan penyesuaian cepat terhadap pola baru atau mode kegagalan
    • Saat menemukan masalah baru, Anda dapat segera menulis assertion atau eval untuk masalah tersebut
  • Demikian pula, setiap pembaruan pada definisi mode kegagalan harus tercermin dalam kriteria evaluasi
    • “Vibe check” semacam ini adalah sinyal adanya output yang salah, sedangkan kode dan assertion mengoperasionalkannya
  • Terakhir, sikap ini perlu disosialisasikan
    • Misalnya dengan menambahkan peninjauan atau anotasi input dan output ke dalam rotasi on-call

Operasional 2. Bekerja dengan model

  • Menggunakan API LLM berarti bergantung pada kecerdasan dari sejumlah kecil penyedia
    • Ini ada sisi baiknya, tetapi ketergantungan ini juga membawa trade-off dalam hal performa, latensi, throughput, dan biaya
  • Selain itu, karena model yang lebih baru dan lebih baik dirilis hampir setiap bulan selama setahun terakhir, Anda harus siap memperbarui produk saat menghentikan model lama dan bermigrasi ke model baru
    • Bagian ini membagikan pelajaran yang didapat saat menggunakan teknologi yang tidak sepenuhnya bisa dikendalikan, yakni teknologi yang modelnya tidak dapat di-self-host dan dikelola sendiri
  • Untuk sebagian besar use case nyata, output LLM akan dikonsumsi oleh aplikasi downstream melalui semacam format yang dapat dibaca mesin
    • Misalnya, ReChat, CRM properti, memerlukan respons terstruktur untuk merender widget di frontend
    • Demikian juga, Boba, alat pembuat ide strategi produk, memerlukan output terstruktur dengan field judul, ringkasan, skor kelayakan, dan rentang waktu
    • Terakhir, LinkedIn membagikan cara membatasi LLM agar menghasilkan YAML, yang digunakan untuk menentukan teknologi yang akan dipakai dan memberikan parameter untuk memanggil teknologi tersebut
  • Pola aplikasi ini adalah versi ekstrem dari hukum Postel
    • Longgar dalam menerima (bahasa alami apa pun) dan konservatif dalam mengirim (objek terketik yang dapat dibaca mesin)
    • Karena itu, pola ini diperkirakan akan sangat tahan lama
  • Saat ini, Instructor dan Outlines adalah standar de facto untuk mendorong output terstruktur dari LLM
    • Jika menggunakan API LLM (misalnya Anthropic, OpenAI), gunakan Instructor, dan jika menggunakan model self-hosted (misalnya Huggingface), gunakan Outlines

Migrasi prompt antar model adalah pekerjaan yang menyakitkan

  • Terkadang prompt yang disusun dengan cermat bisa bekerja sangat baik pada satu model, tetapi tidak berjalan semestinya pada model lain
    • Hal ini bisa terjadi bukan hanya saat berpindah antar penyedia model yang berbeda, tetapi juga saat meng-upgrade antar versi dari model yang sama
  • Sebagai contoh, Voiceflow menemukan bahwa migrasi dari gpt-3.5-turbo-0301 ke gpt-3.5-turbo-1106 menyebabkan penurunan performa sebesar 10% pada tugas klasifikasi intent
    • (Untungnya, mereka punya evaluasi!)
  • Demikian pula, GoDaddy mengamati tren positif bahwa ketika upgrade ke versi 1106, kesenjangan performa antara gpt-3.5-turbo dan gpt-4 menyempit
    • (Atau, jika Anda termasuk orang yang melihat gelas setengah penuh, Anda mungkin justru kecewa karena keunggulan gpt-4 berkurang akibat upgrade baru ini)
  • Karena itu, jika Anda perlu memigrasikan prompt antar model, perkirakan bahwa prosesnya akan memakan waktu lebih banyak daripada sekadar mengganti API endpoint
    • Jangan berasumsi bahwa memakai prompt yang sama akan menghasilkan hasil yang serupa atau lebih baik
  • Selain itu, evaluasi yang andal dan otomatis membantu mengukur performa tugas sebelum dan sesudah migrasi, sekaligus mengurangi upaya yang dibutuhkan untuk validasi manual

Pengelolaan dan pinning versi model

  • Dalam setiap pipeline machine learning, "kalau satu hal berubah, semuanya ikut berubah"
    • Ini особенно relevan ketika kita bergantung pada komponen seperti large language model (LLM) yang tidak kita latih sendiri dan bisa berubah tanpa sepengetahuan kita
  • Untungnya, banyak penyedia model menawarkan opsi untuk "mengunci" versi model tertentu (misalnya gpt-4-turbo-1106)
    • Ini memungkinkan kita memakai versi tertentu dari bobot model agar tidak berubah
  • Mengunci versi model di produksi dapat mencegah perubahan tak terduga pada perilaku model
    • Ini dapat membantu menghindari keluhan pelanggan terkait masalah seperti output yang terlalu bertele-tele atau mode kegagalan tak terduga lainnya yang bisa muncul saat model diganti
  • Pertimbangkan juga untuk mempertahankan "shadow pipeline" yang mencerminkan pengaturan produksi, tetapi menggunakan versi model terbaru
    • Dengan ini, Anda bisa melakukan eksperimen dan pengujian dengan aman terhadap rilis baru
  • Setelah stabilitas dan kualitas output pada model-model baru ini tervalidasi, Anda dapat memperbarui versi model di lingkungan produksi dengan lebih percaya diri

Memilih model terkecil yang bisa menyelesaikan tugas

  • Saat mengerjakan aplikasi baru, ada godaan untuk memakai model terbesar dan terkuat yang tersedia
    • Namun, setelah dipastikan bahwa tugas tersebut memang secara teknis bisa dilakukan, layak untuk bereksperimen apakah model yang lebih kecil dapat memberikan hasil serupa
  • Keunggulan model kecil adalah latensi dan biaya yang lebih rendah
    • Meski mungkin lebih lemah, teknik seperti Chain-of-Thought, prompt n-shot, dan in-context learning dapat membantu model kecil bekerja melampaui kemampuannya
  • Di luar API LLM, fine-tuning untuk tugas tertentu juga dapat membantu meningkatkan performa
  • Secara keseluruhan, workflow yang dirancang dengan cermat menggunakan model kecil bisa lebih cepat dan murah, sambil tetap menyamai atau bahkan melampaui kualitas output dari satu model besar
    • Sebagai contoh, tweet ini membagikan anekdot tentang bagaimana Haiku + prompt 10-shot mengungguli Opus zero-shot dan GPT-4
  • Dalam jangka panjang, diperkirakan akan muncul lebih banyak contoh flow engineering dengan model kecil yang menawarkan keseimbangan optimal antara kualitas output, latensi, dan biaya
  • Contoh lainnya adalah tugas klasifikasi yang sederhana
    • Model ringan seperti DistilBERT (67 juta parameter) merupakan baseline yang sangat kuat
    • DistilBART dengan 400 juta parameter adalah opsi hebat lainnya
      • Jika di-fine-tune pada data open source, model ini dapat mengidentifikasi halusinasi dengan ROC-AUC 0,84, mengungguli sebagian besar LLM dengan latensi dan biaya kurang dari 5%
  • Intinya, jangan mengabaikan model kecil
    • Sangat mudah untuk menerapkan model raksasa pada semua masalah, tetapi dengan sedikit kreativitas dan eksperimen, kita sering kali bisa menemukan solusi yang lebih efisien

Operasi 3. Produk

  • Teknologi baru membuka kemungkinan baru, tetapi prinsip membuat produk yang hebat bersifat abadi
    • Karena itu, meskipun kita sedang menyelesaikan masalah baru untuk pertama kalinya, tidak perlu menemukan ulang roda dalam desain produk
  • Ada banyak manfaat jika pengembangan aplikasi LLM dibangun di atas dasar-dasar produk yang kokoh
    • Dengan begitu, kita dapat memberikan nilai nyata kepada orang-orang yang kita layani

Libatkan desain sejak awal

  • Memiliki desainer mendorong kita untuk memahami dan memikirkan secara mendalam bagaimana produk harus dibangun dan disajikan kepada pengguna
    • Terkadang, desainer distereotipkan sebagai orang yang membuat sesuatu terlihat indah
    • Namun, mereka juga memikirkan ulang bagaimana pengalaman pengguna dapat ditingkatkan, bahkan jika itu berarti melanggar aturan dan paradigma yang ada, bukan hanya antarmuka pengguna
  • Desainer sangat berbakat dalam membingkai ulang kebutuhan pengguna ke dalam berbagai bentuk
    • Beberapa bentuk ini lebih mudah diselesaikan daripada yang lain, sehingga bisa memberi lebih banyak atau lebih sedikit peluang bagi solusi AI
  • Seperti banyak produk lainnya, membangun produk AI seharusnya berpusat pada pekerjaan yang harus diselesaikan, bukan pada teknologi yang menggerakkan produk tersebut
  • Fokuslah untuk mengajukan pertanyaan seperti berikut kepada diri sendiri
    • "Pekerjaan apa yang diminta pengguna dari produk ini? Apakah itu sesuatu yang cocok dikerjakan chatbot? Bagaimana dengan autocomplete? Mungkin malah sesuatu yang lain!"
  • Pertimbangkan pola desain yang sudah ada dan bagaimana kaitannya dengan pekerjaan yang ingin diselesaikan
    • Ini adalah aset berharga yang desainer tambahkan pada kemampuan tim

Merancang UX untuk human-in-the-loop

  • Salah satu cara untuk mendapatkan anotasi berkualitas tinggi adalah dengan mengintegrasikan Human-in-the-Loop (HITL) ke dalam pengalaman pengguna (UX)
    • Jika pengguna dapat dengan mudah memberikan umpan balik dan koreksi, Anda bisa meningkatkan output secara langsung sekaligus mengumpulkan data yang berguna untuk peningkatan model
  • Bayangkan sebuah platform e-commerce tempat pengguna mengunggah dan mengategorikan produk
    • Ada beberapa cara untuk merancang UX-nya
      1. Pengguna secara manual memilih kategori produk yang benar, lalu LLM secara berkala memeriksa produk baru dan memperbaiki salah klasifikasi di backend
      2. Pengguna sama sekali tidak memilih kategori, dan LLM secara berkala mengklasifikasikan produk di backend (termasuk potensi kesalahan)
      3. LLM menyarankan kategori produk secara real-time, dan pengguna dapat memverifikasi serta memperbaruinya bila perlu
  • Ketiga pendekatan tersebut sama-sama melibatkan LLM, tetapi memberikan UX yang sangat berbeda
    • Pendekatan pertama membebankan kerja awal kepada pengguna dan LLM berperan sebagai pemeriksaan pascaproses
    • Pendekatan kedua tidak memerlukan usaha dari pengguna sama sekali, tetapi tidak memberikan transparansi maupun kontrol
    • Pendekatan ketiga menjaga keseimbangan yang tepat
      • Dengan LLM yang lebih dulu menyarankan kategori, beban kognitif pengguna berkurang dan mereka tidak perlu mempelajari taksonomi kita untuk mengategorikan produk
      • Pada saat yang sama, dengan memungkinkan pengguna meninjau dan mengedit saran, keputusan akhir tentang bagaimana produk diklasifikasikan tetap sepenuhnya berada di tangan pengguna
    • Sebagai bonus, pendekatan ketiga menciptakan loop umpan balik yang alami untuk peningkatan model
      • Saran yang baik akan diterima (label positif) dan saran yang buruk akan diperbarui (label negatif lalu positif)
  • Pola saran, verifikasi pengguna, dan pengumpulan data ini umum terlihat di berbagai aplikasi
    • Asisten coding: pengguna dapat menerima saran (positif kuat), menerima lalu menyesuaikannya (positif), atau mengabaikannya (negatif)
    • Midjourney: pengguna dapat melakukan upscale dan mengunduh gambar (positif kuat), mengubah gambar (positif), atau membuat set gambar baru (negatif)
    • Chatbot: pengguna dapat memberi suka (positif) atau tidak suka (negatif) pada respons, atau jika responsnya benar-benar buruk, memilih untuk membuat ulang respons (negatif kuat)
  • Umpan balik bisa bersifat eksplisit maupun implisit
    • Umpan balik eksplisit adalah informasi yang diberikan pengguna sebagai respons terhadap permintaan dari produk
    • Umpan balik implisit adalah informasi yang dipelajari dari interaksi pengguna tanpa pengguna perlu secara sengaja memberikan umpan balik
  • Asisten coding dan Midjourney adalah contoh umpan balik implisit, sementara suka dan tidak suka adalah umpan balik eksplisit
    • Jika UX dirancang dengan baik seperti pada asisten coding dan Midjourney, produk dapat mengumpulkan banyak umpan balik implisit untuk meningkatkan produk dan model

Memprioritaskan hierarchy persyaratan secara tanpa kompromi

  • Saat memikirkan tentang menempatkan demo ke production, Anda perlu mempertimbangkan persyaratan berikut
    • Keandalan: uptime 99,9%, kepatuhan terhadap output terstruktur
    • Keamanan konten: tidak menghasilkan konten ofensif, NSFW, atau konten berbahaya lainnya
    • Konsistensi faktual: setia pada konteks yang diberikan dan tidak memelintir fakta
    • Kegunaan: relevan dengan kebutuhan dan permintaan pengguna
    • Skalabilitas: SLA latensi, throughput yang didukung
    • Biaya: karena anggaran tidak tak terbatas
    • Lainnya: keamanan, privasi, fairness, GDPR, DMA, dan sebagainya
  • Jika mencoba menyelesaikan semua persyaratan ini sekaligus, Anda tidak akan pernah bisa merilis apa pun
    • Karena itu, Anda harus menentukan prioritas. Tanpa kompromi.
  • Ini berarti memperjelas hal-hal yang tidak bisa ditawar karena tanpa itu produk mungkin tidak akan berfungsi atau tidak layak dijalankan (misalnya keandalan, keamanan konten)
    • Penting untuk mengidentifikasi produk MVP (Minimum Lovable Product)
  • Terimalah bahwa versi pertama tidak akan sempurna, lalu rilis dan iterasikan

Menyesuaikan tingkat toleransi risiko berdasarkan use case

  • Saat menentukan tingkat peninjauan untuk model bahasa dan aplikasi, Anda harus mempertimbangkan use case dan sasarannya
    • Untuk chatbot yang berhadapan langsung dengan pelanggan dan memberikan nasihat medis atau finansial, standar keselamatan dan akurasi harus sangat tinggi
      • Kesalahan atau output yang keliru dapat menyebabkan kerugian nyata dan hilangnya kepercayaan
    • Namun, untuk aplikasi yang kurang kritis seperti sistem rekomendasi atau aplikasi internal seperti klasifikasi maupun peringkasan konten, persyaratan yang terlalu ketat hanya akan memperlambat kemajuan tanpa menambah banyak nilai
  • Ini selaras dengan laporan a16z terbaru bahwa banyak perusahaan bergerak lebih cepat pada aplikasi LLM internal dibandingkan aplikasi eksternal
    • Dengan bereksperimen menggunakan AI untuk produktivitas internal, organisasi dapat mulai menangkap nilai sambil belajar mengelola risiko dalam lingkungan yang lebih terkendali
    • Setelah itu, ketika kepercayaan diri sudah terbentuk, mereka dapat memperluasnya ke use case yang berhadapan dengan pelanggan

Operasi 4. Tim dan peran (Roles)

  • Tidak ada jabatan yang mudah didefinisikan, tetapi menulis job description untuk pekerjaan di wilayah baru ini bahkan lebih sulit lagi
    • Saya akan melewatkan diagram Venn untuk jabatan-jabatan yang saling beririsan atau usulan job description
    • Namun, saya akan mengakui keberadaan peran baru, yaitu AI engineer, dan membahas peran tersebut
  • Yang lebih penting, saya akan membahas bagaimana sisa tim dan tanggung jawab sebaiknya dialokasikan

Fokus pada proses, bukan alat

  • Saat menghadapi paradigma baru seperti LLM, software engineer cenderung lebih menyukai alat
    • Akibatnya, mereka mengabaikan masalah dan proses yang sebenarnya ingin diselesaikan oleh alat tersebut
    • Dengan melakukan ini, banyak engineer justru mengambil kompleksitas insidental, yang berdampak negatif pada produktivitas jangka panjang tim
  • Sebagai contoh, tulisan ini menjelaskan bagaimana alat tertentu dapat secara otomatis menghasilkan prompt untuk large language model
    • Argumennya adalah bahwa engineer yang menggunakan alat semacam ini tanpa terlebih dulu memahami metodologi atau proses pemecahan masalah pada akhirnya akan mewarisi technical debt yang tidak perlu (IMHO, dan saya rasa memang benar)
  • Selain kompleksitas insidental, alat juga sering kali tidak dispesifikasikan dengan memadai
    • Sebagai contoh, industri alat evaluasi LLM sedang berkembang dengan menawarkan “kotak peralatan evaluasi LLM” beserta evaluator umum untuk hal-hal seperti harmfulness, keringkasan, tone, dan sebagainya
    • Saya melihat banyak tim mengadopsi alat semacam ini tanpa berpikir kritis tentang mode kegagalan spesifik dalam domain mereka sendiri
  • Sebaliknya, EvalGen berfokus untuk mengajarkan proses pembuatan evaluasi spesifik domain dengan melibatkan pengguna secara mendalam dalam setiap tahap, termasuk penentuan kriteria, pelabelan data, verifikasi evaluasi, dan sebagainya
    • Perangkat lunak ini memandu pengguna melalui workflow seperti berikut
  • Praktik terbaik pembuatan evaluasi LLM yang dipandu oleh EvalGen
    1. Mendefinisikan pengujian spesifik domain (di-bootstrap secara otomatis dari prompt)
      • Didefinisikan sebagai assertion melalui kode atau LLM-as-a-Judge
    2. Pentingnya menyelaraskan pengujian dengan penilaian manusia agar pengguna dapat memverifikasi bahwa pengujian benar-benar menangkap kriteria yang ditetapkan
    3. Mengiterasi pengujian seiring perubahan pada sistem (misalnya prompt)
  • EvalGen memberi developer sebuah mental model tentang proses membangun evaluasi, tetapi tidak mengikat mereka pada alat tertentu
    • Setelah memberikan konteks ini kepada AI engineer, kami sering mendapati bahwa mereka justru memilih alat yang lebih sederhana atau memutuskan membangun alat mereka sendiri
  • Selain penulisan prompt dan evaluasi, ada terlalu banyak komponen dalam LLM untuk dicantumkan semuanya di sini
    • Namun, penting bagi AI engineer untuk berusaha memahami proses sebelum mengadopsi alat

Selalu bereksperimen

  • Produk ML sangat erat terkait dengan eksperimen
    • Ini bukan hanya berarti A/B testing dan randomized controlled trials, tetapi juga upaya yang sering dilakukan untuk mengubah komponen sekecil mungkin dalam sistem dan menjalankan evaluasi offline
    • Alasan semua orang begitu antusias terhadap evaluasi sebenarnya bukan soal reliabilitas dan keyakinan, melainkan karena evaluasi memungkinkan eksperimen!
      • Semakin baik evaluasinya, semakin cepat eksperimen bisa diulang, dan karena itu semakin cepat pula sistem bisa mencapai versi terbaiknya
  • Karena eksperimen menjadi sangat murah, sudah umum untuk mencoba berbagai pendekatan dalam menyelesaikan masalah yang sama
    • Biaya tinggi untuk pengumpulan data dan pelatihan model sudah berkurang seminimal mungkin
      • Biaya prompt engineering hanya sedikit lebih besar daripada waktu manusia
    • Tempatkan tim agar semua orang bisa mempelajari dasar-dasar prompt engineering
      • Ini mendorong semua orang untuk bereksperimen dan menghasilkan beragam ide di seluruh organisasi
  • Jangan gunakan eksperimen hanya untuk eksplorasi, tetapi juga untuk eksploitasi!
    • Apakah sudah ada versi yang berjalan untuk tugas baru?
      • Pertimbangkan agar anggota tim lain mendekatinya dengan cara berbeda
    • Coba dengan metode lain yang mungkin lebih cepat
    • Tingkatkan kualitas dengan meneliti teknik prompt seperti Chain-of-Thought atau Few-Shot
    • Pastikan alat tidak menghambat eksperimen
      • Jika iya, beli sesuatu yang bisa dibangun ulang atau ditingkatkan
  • Saat merencanakan produk/proyek, sisihkan waktu khusus untuk membangun evaluasi dan menjalankan berbagai eksperimen
    • Pikirkan spesifikasi produk untuk produk rekayasa, lalu tambahkan kriteria yang jelas untuk evaluasi
  • Saat menyusun roadmap, jangan meremehkan waktu yang dibutuhkan untuk eksperimen
    • Perkirakan akan ada beberapa putaran pengembangan dan evaluasi sebelum mendapat persetujuan untuk produksi

Berdayakan semua orang agar dapat menggunakan teknologi AI baru

  • Seiring meningkatnya adopsi AI generatif, kita ingin bukan hanya para spesialis, tetapi seluruh tim merasa mampu memahami dan menggunakan teknologi baru ini
    • Tidak ada cara yang lebih baik untuk membangun intuisi tentang cara kerja LLM (misalnya latensi, mode kegagalan, UX)
    • LLM relatif mudah diakses
      • Anda tidak perlu tahu cara menulis kode untuk meningkatkan performa pipeline, dan semua orang dapat berkontribusi lewat prompt engineering dan evaluasi
  • Bagian besar dari ini adalah pendidikan
    • Anda bisa mulai dari dasar-dasar prompt engineering, seperti bagaimana teknik n-shot prompting dan CoT membantu mengondisikan model ke arah output yang diinginkan
  • Orang yang memiliki pengetahuan juga dapat mengajarkan aspek yang lebih teknis, seperti fakta bahwa LLM pada dasarnya bersifat autoregresif
    • Artinya, token input diproses secara paralel, tetapi token output dihasilkan secara berurutan
    • Karena itu, latensi merupakan fungsi dari panjang output, bukan panjang input
      • Ini adalah pertimbangan utama saat merancang UX dan menetapkan ekspektasi performa
  • Anda juga bisa menyediakan kesempatan praktik langsung untuk eksperimen dan eksplorasi
    • Bagaimana dengan hackathon?
      • Mungkin terlihat mahal jika seluruh tim menghabiskan beberapa hari mengerjakan proyek spekulatif, tetapi hasilnya bisa mengejutkan Anda
    • Ada tim yang hampir menyelesaikan roadmap tiga tahun hanya dalam satu tahun lewat hackathon
      • Tim lain, lewat hackathon, menghasilkan UX yang menggeser paradigma dan kini dimungkinkan berkat LLM, yang sekarang menjadi prioritas untuk tahun ini dan seterusnya

Jangan terjebak pada anggapan bahwa "AI engineering adalah segalanya"

  • Ketika jabatan baru muncul, pada awalnya ada kecenderungan untuk melebih-lebihkan kemampuan yang terkait dengan peran tersebut
    • Hal ini sering berujung pada koreksi yang menyakitkan ketika cakupan nyata dari pekerjaan itu menjadi lebih jelas
    • Pendatang baru di bidang ini dan para manajer perekrutan dapat membuat klaim berlebihan atau memiliki ekspektasi yang terlalu tinggi
  • Contoh yang menonjol selama 10 tahun terakhir adalah sebagai berikut
    • Data scientist: "orang yang lebih paham statistik daripada semua software engineer, dan lebih paham software engineering daripada semua ahli statistik"
    • Machine learning engineer (MLE): sudut pandang software engineering yang berpusat pada machine learning
  • Pada awalnya, banyak orang menganggap bahwa untuk proyek berbasis data, data scientist saja sudah cukup
    • Namun kemudian menjadi jelas bahwa data scientist harus bekerja sama dengan software engineer dan data engineer untuk mengembangkan dan menerapkan produk data secara efektif
  • Kesalahpahaman ini muncul kembali dalam peran baru bernama AI engineer, dan beberapa tim percaya bahwa AI engineer adalah semua yang mereka butuhkan
    • Pada kenyataannya, membangun produk machine learning atau AI memerlukan beragam peran spesialis yang luas
  • Kami telah berkonsultasi dengan lebih dari 12 perusahaan tentang produk AI, dan secara konsisten mengamati bahwa mereka jatuh ke dalam jebakan keyakinan bahwa "AI engineering adalah semua yang dibutuhkan"
    • Akibatnya, produk mereka sering kesulitan berkembang melampaui demo karena mengabaikan aspek-aspek penting yang diperlukan untuk membangun produk
  • Misalnya, evaluasi dan pengukuran sangat penting untuk mengembangkan produk melampaui sekadar vibe check
    • Keterampilan untuk evaluasi yang efektif selaras dengan beberapa kekuatan yang secara tradisional dimiliki machine learning engineer
      • Tim yang hanya terdiri dari AI engineer kemungkinan besar akan kekurangan keterampilan ini
  • Salah satu penulis, Hamel Husain, menjelaskan pentingnya keterampilan ini dalam pekerjaan terbarunya terkait deteksi bias data dan perancangan evaluasi yang spesifik domain
  • Jenis peran yang dibutuhkan dan kapan dibutuhkan dalam perjalanan membangun produk AI
    1. Pertama, fokuslah pada pembangunan produk
    • Ini bisa mencakup AI engineer, tetapi tidak selalu diperlukan
    • AI engineer berguna untuk membuat prototipe produk (UX, plumbing, dan sebagainya) dan melakukan iterasi cepat
    1. Selanjutnya, instrumentasikan sistem dan kumpulkan data untuk membangun fondasi yang tepat
    • Bergantung pada jenis dan skala data, Anda mungkin memerlukan platform engineer dan/atau data engineer
    • Anda juga harus memiliki sistem untuk melakukan query dan menganalisis data ini guna men-debug masalah
    1. Berikutnya, optimalkan sistem AI
    • Ini tidak harus mencakup pelatihan model
    • Dasarnya mencakup langkah-langkah seperti merancang metrik, membangun sistem evaluasi, menjalankan eksperimen, mengoptimalkan retrieval RAG, dan men-debug sistem probabilistik
    • MLE sangat mahir di bidang ini (meskipun tentu saja AI engineer juga bisa mempelajarinya)
    • Jika langkah-langkah sebelumnya belum selesai, biasanya tidak masuk akal untuk merekrut MLE
  • Selain itu, Anda selalu membutuhkan pakar domain
    • Di perusahaan kecil, idealnya tim pendiri yang menjalankan peran ini, sedangkan di perusahaan besar, product manager dapat mengambil peran tersebut
  • Penting untuk memahami perkembangan dan timing dari tiap peran
    • Merekrut orang pada waktu yang salah (misalnya merekrut MLE terlalu dini) atau membangun dalam urutan yang salah adalah pemborosan waktu dan biaya, serta memicu turnover
  • Selain itu, melakukan check-in rutin dengan MLE pada tahap 1-2 (namun tidak merekrutnya sebagai karyawan penuh waktu) dapat membantu perusahaan membangun fondasi yang tepat

[Strategi: cara agar tidak tertinggal saat membangun dengan LLM]

  • Untuk pengembangan produk yang sukses, dibutuhkan perencanaan yang matang dan penetapan prioritas, bukan sekadar membuat prototipe secara sembarangan atau mengikuti model maupun tren terbaru
  • Saat mengembangkan produk AI, perlu meninjau trade-off utama seperti apakah akan membangun sendiri atau membeli
  • Disajikan sebuah "playbook" untuk pengembangan aplikasi LLM tahap awal

Strategi 1: tidak ada GPU sebelum PMF

  • Agar menjadi produk yang hebat, produk harus lebih dari sekadar pembungkus tipis di atas API milik orang lain
  • Namun, kesalahan ke arah sebaliknya bisa menimbulkan biaya yang lebih besar
    • Selama tahun lalu, modal ventura dalam jumlah besar dihabiskan untuk pelatihan dan kustomisasi model tanpa visi produk atau pasar sasaran yang jelas
    • Bahkan ada satu perusahaan yang menerima pendanaan Seri A sebesar 6 miliar dolar AS
  • Bagian ini akan menjelaskan mengapa langsung memulai pelatihan model sendiri adalah sebuah kesalahan, dan akan mempertimbangkan peran self-hosting

Hampir tidak ada gunanya melakukan pelatihan ulang dari awal (atau hampir dari awal)

  • Bagi sebagian besar organisasi, melakukan pretraining LLM dari nol sejak awal adalah hal yang tidak realistis dan menyimpang dari pengembangan produk
    • Pengembangan dan pemeliharaan infrastruktur machine learning membutuhkan banyak sumber daya
      • Termasuk pengumpulan data, pelatihan dan evaluasi model, serta deployment
    • Jika masih berada pada tahap memvalidasi product-market fit, upaya semacam ini akan mengalihkan sumber daya dari pengembangan produk inti
    • Bahkan jika memiliki sumber daya komputasi, data, dan kapabilitas teknis, LLM yang telah dipretrain bisa menjadi usang dalam hitungan bulan
  • Kasus BloombergGPT
    • BloombergGPT, LLM yang dikhususkan untuk pekerjaan keuangan, dipretrain dengan 363B token
    • Upaya besar dari 9 karyawan penuh waktu dikerahkan, termasuk 4 engineer AI serta 5 staf produk dan riset ML
    • Meski begitu, dalam waktu 1 tahun model ini tertinggal dari gpt-3.5-turbo dan gpt-4 pada tugas tersebut
  • Kasus-kasus ini menunjukkan bahwa, untuk sebagian besar aplikasi nyata, melakukan pretraining LLM dari nol bukanlah penggunaan sumber daya yang terbaik
    • Sebagai gantinya, tim lebih baik melakukan fine-tuning pada model open source paling kuat yang tersedia agar sesuai dengan kebutuhan spesifik
  • Tentu saja ada pengecualian
    • Model kode milik Replit adalah contoh yang baik dari pretraining yang dikhususkan untuk generasi dan pemahaman kode
    • Melalui pretraining, model ini menunjukkan performa lebih baik daripada model yang lebih besar seperti CodeLlama7b
    • Namun, seiring dirilisnya model-model yang lebih kuat, investasi berkelanjutan tetap dibutuhkan untuk mempertahankan kegunaannya

Jangan lakukan fine-tuning sampai benar-benar terbukti perlu

  • Di sebagian besar organisasi, fine-tuning didorong oleh FOMO (Fear Of Missing Out, takut ketinggalan) alih-alih pemikiran strategis
    • Organisasi berinvestasi terlalu dini pada fine-tuning untuk menghindari kritik sebagai "wrapper sederhana"
    • Pada praktiknya, fine-tuning ibarat alat berat yang baru seharusnya dikerahkan setelah mengumpulkan banyak bukti bahwa pendekatan lain memang tidak memadai
  • Setahun lalu banyak tim antusias terhadap fine-tuning, tetapi hanya sedikit yang menemukan product-market fit dan sebagian besar menyesali keputusan tersebut
    • Jika akan melakukan fine-tuning, Anda harus siap mengulanginya terus saat model dasar ikut membaik
      • Lihat "Model bukan produk" dan "Membangun LLMOps" di bawah
  • Kapan fine-tuning benar-benar bisa menjadi pilihan yang tepat
    • Saat Anda membutuhkan data yang tidak tersedia di sebagian besar dataset skala web terbuka yang digunakan untuk melatih model yang ada
    • Saat Anda sudah membangun MVP yang menunjukkan bahwa model yang ada memang tidak cukup
    • Namun hati-hati: jika pembuat model saja tidak bisa dengan mudah mendapatkan data pelatihan yang bagus, dari mana Anda akan mendapatkannya?
  • Aplikasi berbasis LLM bukan proyek science fair
    • Investasi harus sebanding dengan kontribusinya terhadap tujuan strategis dan diferensiasi kompetitif

Mulai dengan API inferensi, tetapi jangan takut melakukan self-hosting

  • Dengan menggunakan API LLM, startup dapat dengan mudah mengadopsi dan mengintegrasikan kemampuan language modeling tanpa harus melatih model sendiri dari nol
    • Penyedia seperti Anthropic dan OpenAI menyediakan API umum yang dapat menambahkan kecerdasan ke produk hanya dengan beberapa baris kode
    • Dengan memakai layanan ini, upaya dapat dikurangi dan fokus bisa diarahkan pada penciptaan nilai bagi pelanggan, sehingga validasi ide dan iterasi product-market fit dapat berlangsung lebih cepat
  • Namun, seperti halnya database, layanan terkelola tidak cocok untuk semua use case ketika skala dan kebutuhan meningkat
    • Bahkan, self-hosting bisa menjadi satu-satunya cara untuk menggunakan model tanpa mengirim data rahasia/pribadi ke luar jaringan, sebagaimana disyaratkan oleh industri teregulasi seperti kesehatan dan keuangan atau oleh kewajiban kontraktual maupun persyaratan kerahasiaan
  • Self-hosting juga membantu menghindari batasan seperti rate limit, penghentian model, dan pembatasan penggunaan yang diberlakukan penyedia inferensi
    • Self-hosting memberi kontrol penuh atas model sehingga lebih mudah membangun sistem yang terdiferensiasi dan berkualitas tinggi
  • Terakhir, self-hosting, khususnya fine-tuning, dapat menghemat biaya pada skala besar
    • Misalnya, Buzzfeed pernah membagikan kasus fine-tuning open source LLM yang menurunkan biaya hingga 80%

Strategi 2: Beriterasi menuju sesuatu yang lebih baik

  • Untuk mempertahankan keunggulan kompetitif dalam jangka panjang, Anda perlu memikirkan elemen yang dapat membedakan produk melampaui modelnya
  • Kecepatan eksekusi itu penting, tetapi tidak boleh menjadi satu-satunya keunggulan

Model bukan produk, sistem di sekeliling model itulah produknya

  • Bagi tim yang tidak membangun model, laju inovasi yang cepat adalah berkah
    • Karena mereka bisa membuat produk yang lebih baik dengan bermigrasi ke model terbaru sambil memanfaatkan peningkatan seperti ukuran konteks, kemampuan penalaran, dan value for money
    • Kemajuan semacam ini cukup dapat diprediksi sekaligus menarik
    • Jika digabungkan, model kemungkinan adalah komponen dengan daya tahan paling rendah dalam sistem
  • Sebaliknya, upaya harus difokuskan pada bagian yang bisa memberi nilai berkelanjutan
    • Evals: untuk mengukur performa tugas secara andal di berbagai model
    • Guardrails: untuk mencegah output yang tidak diinginkan, terlepas dari modelnya
    • Caching: untuk menurunkan latensi dan biaya dengan menghindari model sepenuhnya
    • Data flywheel: untuk mendorong perbaikan berulang dari semua hal di atas
    • Komponen-komponen ini menciptakan moat kualitas produk yang lebih kuat daripada kemampuan model mentah
  • Namun, membangun di lapisan aplikasi bukan berarti tanpa risiko
    • Jika OpenAI atau penyedia model lain ingin menyediakan perangkat lunak enterprise yang layak, jangan memotong pada bagian yang nantinya akan mereka potong sendiri
  • Sebagai contoh, beberapa tim berinvestasi membangun alat kustom untuk memvalidasi output terstruktur dari model proprietary
    • Investasi minimal di sini memang penting, tetapi investasi mendalam bukan penggunaan waktu yang baik
    • OpenAI harus memastikan bahwa ketika meminta function calling, Anda menerima function call yang valid, karena semua pelanggan menginginkannya
    • Terapkan "penundaan strategis" di sini, bangun hanya yang benar-benar perlu, lalu tunggu penyedia memperluas kemampuannya

Mulai dari kecil lalu bangun kepercayaan

  • Membangun produk yang mencoba menjadi segalanya bagi semua orang adalah resep untuk menjadi biasa-biasa saja
  • Untuk menciptakan produk yang meyakinkan, perusahaan harus berspesialisasi dalam membangun pengalaman yang lengket sehingga pengguna terus kembali
  • Pertimbangkan sistem RAG umum yang bertujuan menjawab setiap pertanyaan pengguna
    • Kurangnya spesialisasi berarti sistem tidak dapat memprioritaskan informasi terbaru, mengurai format khusus domain, atau memahami nuansa tugas tertentu
    • Akibatnya, pengguna mendapatkan pengalaman yang dangkal dan tidak dapat diandalkan, gagal memenuhi kebutuhan mereka, lalu pergi
  • Untuk mengatasinya, Anda perlu fokus pada domain dan use case tertentu
    • Persempit cakupan dengan menambah kedalaman, bukan keluasan
    • Dengan begitu, Anda dapat membangun alat yang spesifik domain dan benar-benar relevan bagi pengguna
  • Spesialisasi juga memungkinkan Anda mengomunikasikan kemampuan dan keterbatasan sistem secara jujur
    • Bersikap transparan tentang apa yang bisa dan tidak bisa dilakukan sistem menunjukkan kesadaran diri, membantu pengguna memahami di mana mereka dapat menambahkan nilai paling besar, dan pada akhirnya membangun kepercayaan serta keyakinan terhadap output

Bangun LLMOps, tetapi dengan alasan yang tepat: iterasi cepat

  • DevOps pada dasarnya bukan soal alur kerja yang dapat direproduksi, shift-left, atau memberdayakan tim dua pizza. Terlebih lagi bukan soal menulis file YAML
  • DevOps adalah tentang memperpendek siklus umpan balik antara pekerjaan dan hasilnya sehingga yang terakumulasi adalah perbaikan, bukan kesalahan
    • Akar konsep ini dapat ditelusuri kembali ke lean startup movement, lalu ke lean manufacturing dan Toyota Production System, dengan penekanan pada single-minute die exchange dan kaizen
  • MLOps menerapkan bentuk DevOps ke ML
    • Ada rangkaian alat all-in-one untuk eksperimen yang dapat direproduksi dan memberdayakan pembuat model agar bisa melakukan deployment. File YAML juga banyak
  • Namun, sebagai sebuah industri, MLOps tidak mengadopsi fungsi DevOps. MLOps tidak memperkecil kesenjangan umpan balik antara model dan inferensi serta interaksi di production
  • Untungnya, ranah LLMOps telah bergeser dari masalah sepele seperti manajemen prompt menuju perbaikan berkelanjutan yang bermuara pada masalah sulit yang menghambat iterasi, yaitu monitoring production dan evaluasi
  • Sudah ada arena percakapan untuk evaluasi netral dan crowdsourced terhadap model chat dan coding. Ini adalah loop eksternal untuk perbaikan kolektif dan iteratif
    • Alat seperti LangSmith, Log10, LangFuse, W&B Weave, HoneyHive, dan lainnya menjanjikan bukan hanya mengumpulkan dan menata data tentang hasil sistem di production, tetapi juga terintegrasi erat dengan pengembangan agar data itu dapat dimanfaatkan untuk memperbaiki sistem tersebut. Gunakan alat-alat ini atau bangun sendiri

Jangan membuat kapabilitas LLM yang bisa dibeli

  • Sebagian besar bisnis yang sukses bukanlah bisnis LLM. Pada saat yang sama, sebagian besar bisnis memiliki peluang untuk ditingkatkan dengan LLM
  • Dua pengamatan ini sering menyesatkan para pemimpin hingga terburu-buru merombak sistem mereka dengan LLM, menaikkan biaya dan menurunkan kualitas, lalu meluncurkannya sebagai fitur "AI" buatan yang penuh kesia-siaan. Kini ikon berkilau yang ditakuti itu pun selesai dibuat
  • Ada cara yang lebih baik: fokuslah pada aplikasi LLM yang benar-benar selaras dengan tujuan produk dan memperkuat operasi inti
  • Mari pertimbangkan beberapa upaya keliru yang membuang waktu tim
    • Membangun kapabilitas text-to-SQL kustom untuk bisnis
    • Membangun chatbot yang bisa bercakap dengan dokumen
    • Mengintegrasikan knowledge base perusahaan dengan chatbot dukungan pelanggan
  • Hal-hal di atas memang merupakan hello world dari aplikasi LLM, tetapi tidak masuk akal jika perusahaan produk membangunnya sendiri
    • Ini adalah masalah umum yang dimiliki banyak bisnis, dengan jarak yang besar antara demo yang menjanjikan dan komponen yang andal, dan merupakan wilayah konvensional bagi perusahaan perangkat lunak
    • Memboroskan sumber daya R&D yang berharga untuk masalah umum yang saat ini sedang diselesaikan dalam skala besar oleh batch Y Combinator adalah pemborosan
  • Jika ini terdengar seperti nasihat bisnis yang klise, itu karena di tengah euforia gelombang hype saat ini, mudah untuk salah mengira sesuatu yang berlabel "LLM" sebagai sesuatu yang mutakhir dan terdiferensiasi, sambil melewatkan aplikasi yang sebenarnya sudah menjadi komoditas

Tempatkan AI di dalam loop, dan manusia di pusatnya

  • Saat ini, aplikasi berbasis LLM rapuh. Ia memerlukan sangat banyak pengaman dan defensive engineering, namun tetap sulit diprediksi. Meski begitu, jika ruang lingkupnya dibatasi dengan ketat, aplikasi seperti ini bisa sangat berguna. Ini berarti LLM menjadi alat yang sangat baik untuk mempercepat alur kerja pengguna
  • Mungkin menggoda untuk membayangkan aplikasi berbasis LLM akan sepenuhnya menggantikan alur kerja atau mengambil alih fungsi pekerjaan, tetapi paradigma yang paling efektif saat ini adalah centaur manusia-komputer (Centaur chess)
    • Ketika manusia yang kompeten dipadukan dengan kapabilitas LLM yang disesuaikan untuk pemanfaatan cepat mereka, produktivitas dan kepuasan dalam menyelesaikan pekerjaan dapat meningkat secara signifikan
    • GitHub CoPilot, salah satu aplikasi LLM yang paling representatif, telah membuktikan kekuatan alur kerja semacam ini
      • "Secara keseluruhan, para developer mengatakan bahwa saat menggunakan GitHub Copilot dan GitHub Copilot Chat, coding terasa lebih mudah, dengan lebih sedikit error, lebih mudah dibaca, lebih mudah digunakan kembali, lebih ringkas, lebih mudah dirawat, dan lebih tangguh." - Mario Rodriguez, GitHub
  • Mereka yang telah lama bekerja di ML mungkin akan cepat sampai pada gagasan "human-in-the-loop", tetapi jangan terburu-buru ke sana
    • HITL machine learning adalah paradigma yang bertumpu pada pakar manusia untuk memastikan model ML berperilaku sebagaimana diprediksi
    • Yang diusulkan di sini terkait, tetapi lebih bernuansa. Sistem berbasis LLM seharusnya bukan penggerak utama bagi sebagian besar alur kerja saat ini, melainkan sekadar menjadi sumber daya
  • Menempatkan manusia di pusat dan bertanya bagaimana LLM dapat mendukung alur kerja memberi dampak yang sangat berbeda pada keputusan produk dan desain
    • Pada akhirnya, Anda akan membangun produk yang berbeda dari pesaing yang berlomba-lomba mengalihdayakan semua tanggung jawab ke LLM, yaitu produk yang lebih baik, lebih berguna, dan lebih rendah risikonya

Strategi 3. Mulai dari prompting, eval, dan pengumpulan data

  • Bagian sebelumnya telah mencurahkan banyak teknik dan nasihat. Itu banyak untuk dicerna. Mari pertimbangkan himpunan minimum dari nasihat yang berguna.
    • Jika sebuah tim ingin membangun produk LLM, harus mulai dari mana?
  • Selama setahun terakhir, sudah cukup banyak yang terlihat hingga meyakinkan bahwa aplikasi LLM yang sukses mengikuti lintasan yang konsisten. Bagian ini akan membahas playbook dasar untuk "memulai" ini
  • Gagasan intinya adalah memulai secara sederhana dan menambahkan kompleksitas sesuai kebutuhan
    • Rule of Thumb: setiap tingkat kecanggihan biasanya memerlukan setidaknya usaha satu orde lebih besar daripada tahap sebelumnya. Dengan mengingat itu...

Prompt engineering adalah prioritas nomor satu

  • Mulailah dari prompt engineering
    • Gunakan semua teknik yang telah dibahas sebelumnya di bagian taktik
    • Chain-of-thought, contoh n-shot, dan input/output terstruktur hampir selalu merupakan ide yang baik
    • Buat prototipe dengan model yang performanya paling tinggi sebelum mencoba memeras performa dari model yang lebih lemah
  • Hanya pertimbangkan fine-tuning jika Anda tidak dapat mencapai tingkat performa yang diinginkan dengan prompt engineering
    • Ini akan lebih sering terjadi jika ada persyaratan nonfungsional yang menghalangi penggunaan model proprietari dan menuntut self-hosting, misalnya privasi data, kontrol penuh, atau biaya
    • Berhati-hatilah agar persyaratan privasi yang sama tidak menghalangi penggunaan data pengguna untuk fine-tuning

Bangun evaluasi dan mulai data flywheel

  • Tim yang baru mulai pun membutuhkan evaluasi (evals). Tanpa itu, Anda tidak akan tahu apakah prompt engineering sudah cukup, atau apakah model yang di-fine-tune siap menggantikan model dasar
  • Evaluasi yang efektif bersifat spesifik terhadap tugas dan mencerminkan use case yang dimaksud
    • Tingkat evaluasi pertama yang direkomendasikan adalah unit test
    • Assertion sederhana ini membantu mendeteksi mode kegagalan yang sudah diketahui atau masih berupa hipotesis, serta membantu mengambil keputusan desain awal
    • Lihat juga evaluasi spesifik tugas lainnya untuk klasifikasi, ringkasan, dan sebagainya
  • Unit test dan evaluasi berbasis model memang berguna, tetapi tidak menggantikan kebutuhan akan evaluasi manusia
    • Biarkan orang menggunakan model/produk dan memberi umpan balik
    • Ini memiliki tujuan ganda: mengukur performa nyata dan tingkat cacat, sekaligus mengumpulkan data anotasi berkualitas tinggi yang dapat digunakan untuk fine-tuning model di masa depan
    • Ini menciptakan loop umpan balik positif, atau data flywheel, yang memberi efek compounding seiring waktu
      • Evaluasi manusia untuk menilai performa model atau menemukan cacat
      • Gunakan data anotasi untuk fine-tuning model atau memperbarui prompt
      • Ulangi
  • Misalnya, saat mengaudit cacat dalam ringkasan yang dihasilkan LLM, Anda dapat memberi label umpan balik terperinci yang mengidentifikasi ketidaksesuaian faktual, ketidakrelevanan, atau gaya yang buruk pada tiap kalimat
    • Lalu Anda dapat menggunakan anotasi ketidaksesuaian faktual ini untuk melatih pengklasifikasi halusinasi, atau menggunakan anotasi relevansi untuk melatih relevance reward model
  • LinkedIn telah membagikan contoh sukses penggunaan evaluator berbasis model untuk memperkirakan halusinasi, pelanggaran responsible AI, koherensi, dan lain-lain
  • Dengan menciptakan aset yang nilainya bertambah seiring waktu, membangun evaluasi (evals) berubah dari sekadar biaya operasional menjadi investasi strategis, sambil sekaligus membangun data flywheel dalam prosesnya

Strategi 4. Tren tingkat tinggi dari kognisi berbiaya rendah (The high-level trend of low-cost cognition)

  • Pada tahun 1971, para peneliti di Xerox PARC memprediksi dunia komputer pribadi yang saling terhubung lewat jaringan seperti yang kita tinggali sekarang
    • Mereka turut mewujudkan masa depan itu dengan memainkan peran penting dalam menciptakan teknologi yang memungkinkannya (Ethernet, rendering grafis, mouse, window, dan lain-lain)
  • Mereka juga melakukan latihan sederhana
    • Mereka meninjau aplikasi yang sangat berguna (misalnya display video) tetapi belum ekonomis (RAM yang cukup untuk menjalankan display video berharga ribuan dolar)
    • Lalu mereka melihat tren harga historis teknologi tersebut (mirip Hukum Moore) dan memprediksi kapan teknologi itu akan menjadi ekonomis
  • Hal yang sama bisa dilakukan untuk teknologi LLM, meski tidak serapi jumlah transistor per dolar
    • Pilih benchmark populer yang telah lama digunakan (misalnya dataset Massively-Multitask Language Understanding) dan pendekatan input yang konsisten (prompting 5-shot)
    • Lalu bandingkan biaya menjalankan model bahasa dengan tingkat performa yang berbeda-beda pada benchmark ini dari waktu ke waktu
  • Untuk biaya tetap, kapabilitas meningkat dengan cepat. Untuk tingkat kapabilitas yang tetap, biaya turun dengan cepat
    • Dalam empat tahun sejak model davinci dari OpenAI dirilis lewat API, biaya untuk menjalankan model dengan performa yang sebanding pada tugas itu dalam skala 1 juta token (sekitar 100 salinan dokumen ini) telah turun dari $20 menjadi kurang dari 10 sen. Waktu paruhnya hanya 6 bulan
    • Demikian pula, per Mei 2024, biaya untuk menjalankan Meta LLaMA 3 8B baik melalui penyedia API maupun sendiri hanya sekitar 20 sen per 1 juta token, dengan performa yang mirip OpenAI text-davinci-003, model yang memungkinkan ChatGPT
    • Saat model tersebut dirilis pada akhir November 2023, biayanya juga sekitar $20 per 1 juta token. Hanya dalam 18 bulan, ada selisih dua digit. Ini adalah periode yang sama dengan prediksi pelipatan sederhana menurut Hukum Moore
  • Sekarang pertimbangkan aplikasi LLM yang sangat berguna (seperti menggerakkan karakter video game generatif ala Park et al) tetapi belum ekonomis (biayanya diperkirakan $625 per jam)
    • Sejak makalah itu diterbitkan pada Agustus 2023, biayanya telah turun sekitar satu digit menjadi kira-kira $62,50 per jam
    • Sembilan bulan kemudian, kita bisa memperkirakan biayanya akan turun menjadi $6,25 per jam
  • Sementara itu, saat Pac-Man dirilis pada 1980, dengan $1 dalam nilai uang saat ini Anda bisa membeli kredit untuk bermain selama beberapa menit atau puluhan menit. Sebut saja 6 game per jam atau $6 per jam
    • Hitungan kasar ini menunjukkan bahwa pengalaman game menarik yang diperkuat LLM akan menjadi ekonomis sekitar tahun 2025
  • Tren ini memang baru dan baru berlangsung beberapa tahun. Namun, hampir tidak ada alasan untuk mengharapkan proses ini melambat dalam beberapa tahun ke depan
    • Bahkan setelah buah yang paling mudah dipetik dari algoritme dan dataset digunakan, seperti scaling melampaui "rasio Chinchilla" sekitar 20 token per parameter, inovasi dan investasi yang lebih mendalam di dalam data center dan lapisan silikon akan menutup kesenjangan itu
  • Dan ini mungkin fakta strategis yang paling penting
    • Demo panggung atau makalah riset yang hari ini sepenuhnya tidak praktis akan menjadi fitur premium dalam beberapa tahun, lalu segera setelah itu menjadi komoditas
    • Sistem dan organisasi harus dibangun dengan mengingat hal ini

[Demo dari 0 ke 1 kini sudah cukup. Sekarang saatnya membuat produk dari 1 ke N]

  • Membuat demo LLM itu sangat menyenangkan. Dengan beberapa baris kode, vector database, dan prompt yang dirancang dengan hati-hati, kita bisa menciptakan "keajaiban"
  • Selama setahun terakhir, keajaiban ini telah dibandingkan dengan internet, smartphone, bahkan mesin cetak
  • Sayangnya, seperti diketahui siapa pun yang pernah benar-benar meluncurkan software, ada jurang besar antara demo yang bekerja di lingkungan terkontrol dan produk yang bekerja secara andal dalam skala besar
  • Ada banyak masalah yang mudah dibayangkan dan didemokan, tetapi sangat sulit dijadikan produk
    • Misalnya kendaraan otonom: memperagakan mobil yang menyetir sendiri sejauh satu blok itu mudah, tetapi menjadikannya produk butuh 10 tahun - Andrej Karpathy
  • Mari ambil contoh mobil otonom
    • Pada 1988, mobil pertama yang dikemudikan oleh neural network muncul
    • Dua puluh lima tahun kemudian, Andrej Karpathy melakukan demo ride pertama di Waymo
    • Sepuluh tahun setelah itu, perusahaan tersebut mendapatkan izin operasi tanpa pengemudi
    • Dari prototipe ke produk komersial, dibutuhkan 35 tahun rekayasa yang ketat, pengujian, perbaikan, dan navigasi regulasi
  • Di seluruh industri dan akademia, kami telah mengamati pasang surut selama setahun terakhir: tahun pertama aplikasi LLM (Year 1 of N for LLM applications)
    • Kami berharap pelajaran yang kami petik — mulai dari taktik seperti evaluasi, prompt engineering, dan guardrail hingga sudut pandang strategis seperti keterampilan operasional, membangun tim, dan memilih kemampuan yang perlu dibangun secara internal — akan membantu pada tahun kedua dan seterusnya
    • Kami menantikan untuk terus memajukan teknologi baru yang menarik ini bersama-sama

Bacaan terkait

9 komentar

 
inthelife 2024-06-17

Karena isinya bagus, saya membuatnya dalam bentuk mind map agar bisa dilihat berulang kali ^^;

https://drive.google.com/file/d/…
 
hheungsu 2024-06-15

Tulisan yang sangat bagus!! Dari awal sampai akhir, ada banyak hal berguna yang layak direnungkan berulang kali. Terima kasih telah menerjemahkan dan membagikan tulisan seberharga permata seperti ini!!
 
nutella 2024-06-12

Pada titik ini, ini benar-benar sangat membantu.
 
komanabi 2024-06-11

Megastudy sudah tamat, saatnya Omega-3 datang!!!
 
ssifood 2024-06-11

Sekarang Skynet sudah berakhir, MegaStudy yang datang.
 
my0075425 2024-06-11

Sekarang umat manusia sudah tamat, Skynet datang!!
 
zihado 2024-06-10

Karier penulis artikel aslinya juga menarik.
https://id.news.hada.io/topic?id=1626
 
eungook 2024-06-11

Wah.. ini sangat memotivasi.. terima kasih atas perkenalannya
 
humblebee 2024-06-10

Ini tulisan yang luar biasa; wawasan dan pengalamannya terasa sangat hidup! Sepertinya ini akan sangat membantu bagi saya dan tim. Saya sangat menikmati membacanya. Terima kasih ☺️