A16Z: Arsitektur yang Muncul untuk Aplikasi Model Besar

Catatan redaksi: Ledakan kecerdasan buatan generatif berpotensi mendisrupsi banyak industri, salah satunya industri perangkat lunak. Munculnya model bahasa besar (LLM) telah mengantarkan ledakan aplikasi terkait Raksasa teknologi dan start-up telah meluncurkan berbagai aplikasi LLM Jadi alat dan pola desain apa yang digunakan aplikasi ini? Artikel ini merangkum. Artikel ini dari kompilasi.

Sumber gambar: Dihasilkan oleh AI Tak Terbatas

Model bahasa besar (LLM) adalah primitif baru yang kuat untuk mengembangkan perangkat lunak. Tetapi karena LLM sangat baru dan berperilaku sangat berbeda dari sumber daya komputasi normal, tidak selalu jelas cara menggunakan LLM.

Pada artikel ini, kami akan membagikan arsitektur referensi untuk tumpukan aplikasi LLM yang muncul. Arsitekturnya akan menampilkan sistem, alat, dan pola desain paling umum yang pernah kami lihat digunakan oleh perusahaan rintisan AI dan perusahaan teknologi terkemuka. Tumpukan teknologi ini masih relatif primitif dan dapat mengalami perubahan besar seiring kemajuan teknologi yang mendasarinya, tetapi kami berharap ini dapat memberikan referensi yang berguna bagi pengembang yang mengerjakan pengembangan LLM saat ini.

Pekerjaan ini didasarkan pada percakapan dengan pendiri dan insinyur startup AI. Secara khusus, kami mengandalkan masukan dari orang-orang termasuk Ted Benson, Harrison Chase, Ben Firshman, Ali Ghodsi, Raza Habib, Andrej Karpathy, Greg Kogan, Jerry Liu, Moin Nadeem, Diego Oppenheimer, Shreya Rajpal, Ion Stoica, Dennis Xu, Matei Zaharia dan Jared Zoneraich. Terima kasih atas bantuan Anda!

Tumpukan teknologi LLM

Versi tumpukan aplikasi LLM saat ini terlihat seperti ini:

Kotak abu-abu adalah komponen kunci, dan kotak dengan panah mewakili aliran data yang berbeda: garis putus-putus hitam adalah data konteks yang disediakan oleh pengembang aplikasi untuk membatasi keluaran, garis hitam solid adalah prompt dan beberapa contoh contoh diteruskan ke LLM , dan garis solid biru adalah User query, garis solid merah adalah output yang dikembalikan ke pengguna

Di bawah ini adalah daftar tautan ke setiap item untuk referensi cepat:

, alat/sistem umum untuk setiap komponen kunci tumpukan aplikasi

Ada banyak cara untuk mengembangkan dengan LLM, termasuk model pelatihan dari awal, menyempurnakan model sumber terbuka, atau memanfaatkan API terkelola. Tumpukan teknologi yang kami sajikan di sini didasarkan pada pembelajaran dalam konteks, pola desain yang kami amati sebagian besar pengembang mulai memanfaatkan (dan saat ini hanya mungkin dengan model dasar).

Bagian selanjutnya secara singkat menjelaskan pola desain ini.

Pola Desain: Pembelajaran Kontekstual

Gagasan inti dari pembelajaran kontekstual adalah untuk memanfaatkan LLM siap pakai (yaitu, tanpa penyesuaian apa pun), dan kemudian mengontrol perilaku mereka melalui petunjuk cerdas dan pengondisian pada data "konteks" pribadi.

Misalnya, Anda sedang mengembangkan chatbot untuk menjawab pertanyaan tentang serangkaian dokumen hukum. Cara sederhananya, Anda dapat menempelkan semua dokumen ke prompt ChatGPT atau GPT-4, lalu mengajukan pertanyaan terkait. Ini mungkin berfungsi untuk kumpulan data yang sangat kecil, tetapi tidak dapat diskalakan. Model GPT-4 terbesar hanya dapat menangani sekitar 50 halaman teks masukan, dan kinerja (diukur dengan waktu inferensi dan akurasi) menurun drastis saat mendekati apa yang disebut batas jendela konteks ini.

Pembelajaran konteks memecahkan masalah ini dengan trik yang rapi: alih-alih mengirim semua dokumen setiap kali prompt LLM dimasukkan, ia hanya mengirimkan beberapa dokumen yang paling relevan. Siapa yang akan membantu memutuskan dokumen mana yang paling relevan? Anda dapat menebaknya ... LLM.

Pada tingkat yang sangat tinggi, alur kerja ini dapat dipecah menjadi tiga fase:

• Data preprocessing/embedding: Fase ini menyimpan data pribadi (dalam hal ini dokumen hukum) untuk pengambilan nanti. Secara umum, dokumen dibagi menjadi potongan-potongan, diteruskan ke model penyematan, dan disimpan dalam database khusus yang disebut database vektor.
• Pembuatan/pengambilan cepat: Saat pengguna mengirimkan kueri (dalam hal ini, pertanyaan hukum), aplikasi membuat serangkaian petunjuk, yang kemudian dikirimkan ke model bahasa. Petunjuk yang dikompilasi sering digabungkan dengan templat petunjuk yang dikodekan oleh pengembang; contoh keluaran yang valid disebut contoh beberapa tembakan; setiap informasi yang diperlukan diambil melalui API eksternal; dan satu set dokumen terkait diambil dari database vektor.
• Eksekusi/inferensi petunjuk: Setelah petunjuk dikompilasi, petunjuk dikirim ke LLM terlatih untuk inferensi, termasuk API model berpemilik serta model open-source atau model yang dilatih sendiri. Selama fase ini, beberapa developer juga menambahkan sistem operasional seperti logging, caching, dan validasi.

Ini mungkin tampak seperti banyak pekerjaan, tetapi biasanya lebih mudah diterapkan daripada alternatifnya: melatih LLM atau menyempurnakan LLM itu sendiri sebenarnya lebih sulit. Anda tidak memerlukan tim insinyur pembelajaran mesin khusus untuk melakukan pembelajaran kontekstual. Anda juga tidak perlu menghosting infrastruktur Anda sendiri atau membeli instans khusus yang mahal dari OpenAI. Model ini secara efektif mengurangi masalah AI menjadi masalah rekayasa data yang sudah diketahui oleh sebagian besar perusahaan rintisan serta perusahaan besar untuk dipecahkan. Ini juga cenderung mengungguli fine-tuning untuk kumpulan data yang relatif kecil, karena informasi spesifik harus terjadi setidaknya sekitar 10 kali dalam set pelatihan sebelum LLM dapat disesuaikan untuk mengingat informasi tertentu, dan pembelajaran kontekstual juga dapat memasukkan informasi baru. hampir secara real-time.data.

Salah satu pertanyaan terbesar dalam pembelajaran konteks adalah: apa yang terjadi jika kita hanya mengubah model dasar untuk meningkatkan jendela konteks? Itu memang mungkin, dan ini adalah bidang penelitian yang aktif. Tapi ini datang dengan beberapa trade-off - terutama biaya dan waktu skala inferensi kuadrat dengan panjang petunjuk. Saat ini, bahkan penskalaan linier (hasil teoretis terbaik) terlalu mahal untuk banyak aplikasi. Dengan tarif API saat ini, satu kueri GPT-4 lebih dari 10.000 halaman akan menelan biaya ratusan dolar. Oleh karena itu, kami tidak memperkirakan perubahan skala besar pada tumpukan berdasarkan jendela konteks yang diperluas, tetapi kami akan menguraikannya lebih lanjut nanti.

Di sisa artikel ini, kita akan menelusuri kumpulan teknologi ini menggunakan alur kerja di atas sebagai panduan.

Pemrosesan/penyembahan data

Bagian pemrosesan/penyematan data: meneruskan data ke model yang disematkan melalui pipa data untuk vektorisasi, lalu menyimpannya di database vektor

Data konteks untuk aplikasi LLM mencakup dokumen teks, PDF, dan bahkan format terstruktur seperti tabel CSV atau SQL. Solusi pemuatan dan transformasi data (ETL) yang digunakan oleh pengembang yang kami wawancarai sangat bervariasi. Sebagian besar menggunakan alat ETL tradisional, seperti Databricks atau Airflow. Beberapa juga memanfaatkan pemuat dokumen yang dibangun ke dalam kerangka kerja orkestrasi, seperti LangChain (didukung oleh Unstructed) dan LlamaIndex (didukung oleh Llama Hub). Namun, kami yakin bagian tumpukan teknologi ini relatif kurang berkembang dan ada peluang untuk mengembangkan solusi replikasi data khusus untuk aplikasi LLM.

Sedangkan untuk embedding, sebagian besar developer menggunakan OpenAI API, terutama model text-embedding-ada-002. Model ini mudah digunakan (terutama jika Anda sudah menggunakan API OpenAI lainnya), memberikan hasil yang cukup baik, dan semakin murah. Beberapa perusahaan besar juga sedang menjajaki Cohere, yang pekerjaan produknya lebih terfokus pada penyematan dan memiliki kinerja yang lebih baik dalam beberapa skenario. Untuk pengembang yang lebih menyukai open source, perpustakaan Hugging Face's Sentence Transformers adalah standarnya. Dimungkinkan juga untuk membuat berbagai jenis penyematan tergantung pada kasus penggunaan; ini adalah praktik yang relatif khusus saat ini, tetapi bidang penelitian yang menjanjikan.

Dari sudut pandang sistem, bagian terpenting dari pipeline prapemrosesan adalah database vektor. Database vektor bertanggung jawab untuk menyimpan, membandingkan, dan mengambil hingga miliaran penyematan (alias vektor) secara efisien. Opsi paling umum yang kami lihat di pasaran adalah Biji Pinus. Ini defaultnya, mudah untuk memulai karena sepenuhnya dihosting di cloud, dan memiliki banyak fitur yang dibutuhkan perusahaan besar dalam produksi (mis., kinerja yang baik dalam skala besar, sistem masuk tunggal, dan SLA waktu aktif).

Namun, ada juga sejumlah besar database vektor yang tersedia. Yang terkenal termasuk:

• Sistem Open Source seperti Weaviate, Vespa, dan Qdrant: Sistem ini biasanya memiliki performa node tunggal yang sangat baik dan dapat disesuaikan untuk aplikasi tertentu, menjadikannya populer di kalangan tim AI berpengalaman yang suka mengembangkan platform khusus.
• Faiss et al Native Vector Management Library: Library ini memiliki pengalaman developer yang luas dan mudah dimulai untuk aplikasi kecil dan eksperimen pengembangan. Tapi ini belum tentu menggantikan database penuh dalam skala besar.
• Ekstensi OLTP seperti pgvector: Cocok untuk developer yang melihat lubang di setiap bentuk database dan mencoba menghubungkan ke Postgres, atau perusahaan yang membeli sebagian besar infrastruktur data mereka dari satu penyedia cloud Solusi dukungan vektor yang bagus. Tidak jelas bahwa menggabungkan beban kerja vektor versus skalar secara ketat masuk akal dalam jangka panjang.

Ke depan, sebagian besar perusahaan basis data vektor sumber terbuka sedang mengembangkan produk cloud. Penelitian kami menunjukkan bahwa mencapai kinerja yang kuat di cloud adalah masalah yang sangat sulit dalam ruang desain yang luas dari kemungkinan kasus penggunaan. Jadi rangkaian pilihan mungkin tidak berubah secara dramatis dalam jangka pendek, tapi mungkin dalam jangka panjang. Pertanyaan kuncinya adalah apakah database vektor akan dikonsolidasikan di sekitar satu atau dua sistem populer yang mirip dengan database OLTP dan OLAP.

Ada juga pertanyaan terbuka tentang bagaimana penyematan dan basis data vektor akan berkembang seiring dengan perluasan jendela konteks yang tersedia untuk sebagian besar model. Anda dapat dengan mudah berargumen bahwa penyematan menjadi kurang penting karena data kontekstual dapat dimasukkan langsung ke prompt. Umpan balik dari para ahli tentang topik ini, bagaimanapun, menunjukkan sebaliknya - bahwa saluran pipa tertanam dapat menjadi lebih penting dari waktu ke waktu. Jendela konteks besar memang alat yang ampuh, tetapi juga membutuhkan biaya komputasi yang signifikan. Oleh karena itu, sangat penting untuk memanfaatkan jendela ini secara efektif. Kita mungkin mulai melihat berbagai jenis model penyematan menjadi populer, melatih secara langsung relevansi model, dan basis data vektor muncul yang dirancang untuk mengaktifkan dan memanfaatkan ini.

Segera bangun dan dapatkan

Segera bangun dan dapatkan

Strategi yang mendorong LLM dan memasukkan data kontekstual menjadi lebih canggih dan juga digunakan sebagai sumber diferensiasi produk, dan peran mereka semakin penting. Sebagian besar pengembang memulai proyek baru dengan bereksperimen dengan petunjuk sederhana yang menyertakan instruksi langsung (petunjuk zero-shot) atau keluaran yang mungkin berisi beberapa contoh (petunjuk beberapa tembakan). Petunjuk ini umumnya memberikan hasil yang baik, tetapi bukan tingkat akurasi yang diperlukan untuk penerapan produksi.

Trik petunjuk tingkat berikutnya adalah mendasarkan tanggapan model pada beberapa sumber kebenaran dan untuk menyediakan konteks eksternal di mana model tidak dilatih. Panduan Rekayasa Isyarat mencantumkan tidak kurang dari selusin (!) strategi isyarat yang lebih maju, termasuk rantai pemikiran, konsistensi diri, pengetahuan generatif, pohon pemikiran, rangsangan terarah, dan banyak lagi. Strategi ini dapat digabungkan untuk mendukung kasus penggunaan LLM yang berbeda seperti T&J dokumen, chatbot, dll.

Di sinilah kerangka orkestrasi seperti LangChain dan LlamaIndex masuk. Kerangka kerja ini mengabstraksi banyak detail rantai petunjuk; berinteraksi dengan API eksternal (termasuk menentukan kapan panggilan API diperlukan); mengambil data konteks dari database vektor; dan memelihara memori di seluruh panggilan di beberapa LLM. Mereka juga menyediakan template untuk banyak aplikasi umum yang disebutkan di atas. Outputnya adalah petunjuk atau serangkaian petunjuk yang dikirimkan ke model bahasa. Kerangka kerja ini banyak digunakan oleh penghobi serta pemula yang ingin mengembangkan aplikasi, dengan LangChain sebagai pemimpinnya.

LangChain masih merupakan proyek yang relatif baru (saat ini pada versi 0.0.201), tetapi kami sudah mulai melihat aplikasi yang dikembangkan dengannya mulai diproduksi. Beberapa pengembang, terutama pengadopsi awal LLM, lebih suka beralih ke Python mentah dalam produksi untuk menghilangkan ketergantungan tambahan. Tapi kami berharap pendekatan do-it-yourself ini berkurang untuk sebagian besar kasus penggunaan, seperti yang terjadi pada tumpukan aplikasi web tradisional.

Pembaca yang bermata elang akan melihat entri yang tampak aneh di kotak tata letak: ChatGPT. Dalam keadaan normal, ChatGPT adalah aplikasi, bukan alat pengembang. Tapi itu juga bisa diakses sebagai API. Dan, jika Anda melihat lebih dekat, ini melakukan beberapa fungsi yang sama seperti kerangka kerja orkestrasi lainnya, seperti: menghilangkan kebutuhan akan petunjuk khusus; mempertahankan keadaan; mengambil data kontekstual melalui plugin, API, atau sumber lain. Meskipun ChatGPT bukan pesaing langsung dari alat lain yang tercantum di sini, ini dapat dianggap sebagai solusi alternatif, dan dapat menjadi alternatif yang layak dan mudah untuk pembangunan cepat.

Eksekusi/penalaran petunjuk

Petunjuk eksekusi/penalaran

Hari ini, OpenAI adalah pemimpin di bidang model bahasa. Hampir setiap pengembang yang kami wawancarai telah meluncurkan aplikasi LLM baru menggunakan OpenAI API, biasanya mereka menggunakan model gpt-4 atau gpt-4-32k. Ini memberikan skenario kasus penggunaan terbaik untuk kinerja aplikasi, dan mudah digunakan karena dapat menggunakan berbagai domain masukan, dan seringkali tidak memerlukan penyempurnaan atau hosting sendiri.

Setelah sebuah proyek dalam produksi dan mulai berkembang, berbagai opsi yang lebih luas dapat digunakan. Beberapa pertanyaan umum yang kami dengar antara lain:

• Beralih ke gpt-3.5-turbo: ini sekitar 50 kali lebih murah daripada GPT-4 dan secara signifikan lebih cepat. Banyak aplikasi tidak memerlukan akurasi tingkat GPT-4, tetapi memerlukannya untuk inferensi latensi rendah dan dukungan hemat biaya untuk pengguna gratis. *Bereksperimen dengan vendor berpemilik lainnya (terutama model Claude Anthropic): Claude menawarkan inferensi cepat, akurasi tingkat GPT-3.5, lebih banyak opsi penyesuaian untuk klien besar, dan jendela konteks hingga 100k (walaupun Kami menemukan bahwa akurasi menurun dengan bertambahnya panjang input) .
• Mengklasifikasikan sebagian permintaan untuk model sumber terbuka: Ini sangat efektif untuk kasus penggunaan B2C bervolume tinggi seperti penelusuran atau obrolan, di mana kerumitan kueri sangat bervariasi dan pengguna gratis harus dilayani dengan murah:

1. Ini biasanya paling masuk akal dalam kombinasi dengan menyempurnakan model basis sumber terbuka. Kami tidak akan mempelajari kumpulan alat ini dalam artikel ini, tetapi platform seperti Databricks, Anyscale, Mosaic, Modal, dan RunPod semakin banyak digunakan oleh tim teknik.

2. Model open source dapat menggunakan beberapa opsi inferensi, termasuk Hugging Face dan antarmuka API sederhana Replicate; sumber daya komputasi mentah dari penyedia cloud besar; dan produk cloud (opinionated cloud) dengan preferensi yang lebih jelas seperti yang tercantum di atas.

Saat ini, model sumber terbuka tertinggal di belakang produk berpemilik, tetapi celahnya mulai tertutup. Model LLaMa Meta menetapkan standar baru untuk akurasi sumber terbuka dan menelurkan berbagai varian. Karena LLaMa hanya dilisensikan untuk penggunaan penelitian, banyak penyedia baru telah mulai melatih model dasar alternatif (mis. Bersama, Mosaik, Falcon, Mistral). Meta masih mendiskusikan apakah akan meluncurkan LLaMa 2 versi open source yang sebenarnya.

Ketika (bukan jika) LLM open-source mencapai tingkat akurasi yang sebanding dengan GPT-3.5, kami berharap untuk melihat teks juga memiliki momen Difusi Stabilnya sendiri, dengan eksperimen berskala besar, berbagi, dan menyempurnakan model yang akan diproduksi. Perusahaan hosting seperti Replicate telah mulai menambahkan alat untuk membuat model ini lebih mudah diakses oleh pengembang perangkat lunak. Pengembang semakin percaya bahwa model yang lebih kecil dan disempurnakan dapat mencapai akurasi canggih untuk berbagai kasus penggunaan yang sempit.

Sebagian besar pengembang yang kami wawancarai tidak memiliki pemahaman mendalam tentang alat operasional LLM. Caching relatif umum (sering berdasarkan Redis), karena hal ini meningkatkan waktu respons aplikasi dan mengurangi biaya. Alat seperti Bobot & Bias dengan MLflow (porting dari pembelajaran mesin tradisional) atau Lapisan dengan Helicone (dibuat untuk LLM) juga cukup banyak digunakan. Alat-alat ini dapat merekam, melacak, dan mengevaluasi keluaran LLM, seringkali untuk tujuan meningkatkan konstruksi tip, menyetel jalur pipa, atau memilih model. Ada juga banyak alat baru yang sedang dikembangkan untuk memvalidasi output LLM (mis. Guardrails) atau mendeteksi serangan injeksi petunjuk (mis. Rebuff). Sebagian besar alat operasional ini mendorong klien Python mereka sendiri untuk melakukan panggilan LLM, jadi akan menarik untuk melihat bagaimana solusi ini hidup berdampingan dari waktu ke waktu.

Terakhir, bagian statis dari aplikasi LLM (yaitu, selain model) juga perlu dihosting di suatu tempat. Sejauh ini solusi paling umum yang kami lihat adalah opsi standar seperti Vercel atau penyedia cloud utama. Namun, dua kategori baru muncul. Startup seperti Steamship menyediakan hosting end-to-end untuk aplikasi LLM, termasuk orkestrasi (LangChain), konteks data multi-penyewa, tugas asinkron, penyimpanan vektor, dan manajemen kunci. Perusahaan seperti Anyscale dan Modal memungkinkan pengembang menghosting model dan kode Python di satu tempat.

Bagaimana dengan proxy?

Salah satu komponen terpenting yang hilang dalam arsitektur referensi ini adalah kerangka agen kecerdasan buatan. AutoGPT telah digambarkan sebagai "upaya open-source eksperimental untuk mengotomatisasi GPT-4 sepenuhnya," dan musim semi ini menjadi repositori Github dengan pertumbuhan tercepat dalam sejarah, dan hampir setiap proyek atau startup AI saat ini menggabungkan beberapa bentuk .

Sebagian besar pengembang yang kami ajak bicara sangat bersemangat tentang potensi proxy. Model pembelajaran kontekstual yang kami jelaskan dalam makalah ini dapat secara efektif mengatasi masalah halusinasi dan kesegaran data, sehingga mendukung tugas pembuatan konten dengan lebih baik. Agen, di sisi lain, menyediakan serangkaian kemampuan baru untuk aplikasi AI: memecahkan masalah kompleks, bertindak di dunia luar, dan belajar dari pengalaman pasca penerapan. Ini dilakukan melalui kombinasi penalaran/perencanaan lanjutan, penggunaan alat, dan memori/rekursi/pemikiran refleksi diri.

Dengan demikian, agen memiliki potensi untuk menjadi bagian inti dari arsitektur aplikasi LLM (atau bahkan mengambil alih seluruh tumpukan teknologi, jika Anda percaya pada peningkatan diri secara rekursif). Kerangka kerja yang ada seperti LangChain sudah memasukkan bagian dari konsep proxy. Hanya ada satu masalah: Proxy belum benar-benar berfungsi. Sebagian besar kerangka agen saat ini masih dalam tahap pembuktian konsep, menawarkan demonstrasi yang luar biasa tetapi tidak melakukan tugas dengan andal dan berulang. Kami mengamati dengan cermat bagaimana proxy berkembang dalam waktu dekat.

Melihat ke masa depan

Model AI pra-pelatihan mewakili perubahan paling signifikan dalam arsitektur perangkat lunak sejak Internet. Mereka memungkinkan pengembang individu untuk membuat aplikasi AI yang luar biasa dalam hitungan hari, bahkan melampaui proyek pembelajaran mesin yang diawasi yang biasanya membutuhkan waktu berbulan-bulan untuk dikembangkan oleh tim besar.

Alat dan pola yang kami cantumkan di sini mungkin merupakan titik awal untuk mengintegrasikan LLM, bukan keadaan akhir. Kami juga memperbarui saat ada perubahan yang dapat menyebabkan gangguan (misalnya, peralihan ke pelatihan model), dan menerbitkan arsitektur referensi baru yang masuk akal.