Arsitektur Baru untuk Aplikasi LLM

• Ringkasan dari a16z tentang "arsitektur referensi untuk stack aplikasi LLM"

Emerging LLM App Stack

Data Kontekstual

• Data Pipelines: Databricks, Airflow, Unstructured,..
• Embedding Model: OpenAI, Cohere, Hugging Face
• Vector Database: Pinecone, Weaviate, Chroma, pgvector

Contoh Prompt Few-shot

• Playground: OpenAI, nat.dev, Humanloop
• Orchestration: Pytion/DIY, LangChain, LlamaIndex, ChatGPT
• APIs/Plugins: Serp, Wolfram, Zapier,...

Query & Output

• App Hosting: Vercel, Steamship, Streamlit, Modal
• LLM Cache: Redis, SQLite, GPTCache
• Logging/LLMops: Weights & Biases, MLflow, PromptLayer, Helicone
• Validation: Guardrails, Rebuff, Guidance, LMQL

LLM APIs and Hosting

• Proprietary API: OpenAI, Anthropic
• Open API: Hugging Face, Replicate
• Cloud Provider: AWS, GCP, Azure, Coreweave
• Opinionated Cloud: Databricks, Anyscale, Mosaic, Modal, Runpod,...

Pola Desain: In-context Learning

• In-Context Learning: menggunakan LLM apa adanya tanpa fine-tuning, sambil memanfaatkan prompting yang cerdas dan kondisi berbasis sebagian data "Contextual"
• Contoh) saat membuat chatbot yang menjawab dokumen hukum, pendekatan naifnya adalah memasukkan semua dokumen ke ChatGPT lalu mengajukan pertanyaan, tetapi itu hanya mungkin untuk dataset kecil. Bahkan model terbesar ChatGPT hanya dapat memproses sekitar 50 halaman
  Dalam In-Context Learning, hanya dokumen yang relevan yang dikirim, lalu jawaban diambil dari sana
• Karena itu, alurnya terdiri dari 3 tahap berikut
  • Step 1. prapemrosesan data / embedding
  • Step 2. pembuatan prompt / retrieval dokumen relevan dari vector DB
  • Step 3. eksekusi prompt / inferensi
• Terlihat membutuhkan banyak pekerjaan, tetapi jauh lebih mudah daripada melatih dan fine-tuning LLM itu sendiri

Step 1. [Data preprocessing / embedding]

→ Data Kontekstual melewati Data Pipeline, lalu Embedding Model, lalu disimpan ke Vector Database

Data Kontekstual

• dokumen teks, PDF, CSV, dan tabel SQL
• untuk sebagian besar kasus, loading dan transformasi data tetap menggunakan tool ETL yang sudah ada (Databricks, Airflow)
• sebagian lainnya menggunakan document loader bawaan dari framework orkestrasi seperti LangChain dan LlamaIndex
• bagian stack ini dinilai masih relatif kurang berkembang, dan ada peluang untuk solusi replikasi data yang dibuat khusus untuk aplikasi LLM

Embeddings

• sebagian besar developer menggunakan OpenAI API (text-embedding-ada-002)
  • mudah digunakan, hasilnya cukup bagus, dan harganya makin murah
• beberapa perusahaan besar sedang mengeksplorasi Cohere, yang memberi performa lebih baik pada skenario tertentu
• developer yang menyukai open source umumnya memakai library Sentence Transformers dari Hugging Face sebagai standar
• juga dimungkinkan untuk menghasilkan berbagai jenis embedding yang sesuai dengan use case
  • ini memang kasus niche, tetapi merupakan area riset yang menjanjikan

Vector Database

• komponen terpenting dalam bagian pipeline prapemrosesan adalah vector database
• perannya adalah menyimpan, membandingkan, dan mencari hingga miliaran embedding (vektor) secara efisien
• pilihan paling umum di pasar adalah Pinecone
  • sepenuhnya di-host di cloud sehingga mudah untuk memulai
  • memiliki banyak fitur yang dibutuhkan perusahaan besar untuk production (performa bagus, SSO, uptime SLA, dll.)
• tetapi ada sangat banyak vector database yang tersedia. Secara khusus:
  • open source seperti Weaviate, Vespa, dan Qdrant
    • menawarkan performa single-node yang sangat baik dan bisa disesuaikan untuk aplikasi tertentu
    • populer di kalangan tim AI berpengalaman yang lebih suka membangun platform kustom
  • library manajemen vektor lokal seperti Chroma dan Faiss
    • pengalaman developer yang sangat baik
    • mudah dijalankan untuk aplikasi kecil dan eksperimen pengembangan
    • tidak dimaksudkan untuk menggantikan database skala besar sepenuhnya
  • ekstensi OLTP seperti pgvector
    • solusi bagus untuk dukungan vektor bagi developer yang ingin memaksakan Postgres ke semua kebutuhan database, atau perusahaan yang membeli sebagian besar infrastruktur data dari satu cloud provider
    • dalam jangka panjang, belum jelas apakah mengikat workload vektor dan skalar secara ketat memang masuk akal
• ke depan, sebagian besar perusahaan vector database open source sedang mengembangkan produk cloud
  • menurut riset kami, sangat sulit memberikan performa hebat di cloud untuk berbagai macam use case
  • karena itu, pilihan ini mungkin tidak berubah dalam jangka pendek, tetapi kemungkinan akan berubah dalam jangka panjang
  • pertanyaan intinya adalah apakah vector database akan terkonsolidasi menjadi satu atau dua sistem terkenal seperti pada kasus OLTP & OLAP
• pertanyaan lainnya adalah bagaimana embedding dan vector database akan berevolusi seiring membesarnya context window yang tersedia pada kebanyakan model
  • memang menggoda untuk mengatakan bahwa embedding tidak lagi dibutuhkan karena semua data konteks bisa dimasukkan ke prompt,
  • tetapi masukan dari para ahli menunjukkan bahwa pipeline embedding justru bisa menjadi semakin penting
  • context window yang besar adalah alat yang kuat, tetapi membawa biaya komputasi yang signifikan. Karena itu, prioritasnya adalah menggunakannya secara efisien
• ke depan kita mungkin akan melihat berbagai jenis model embedding menjadi arus utama, dilatih langsung dengan relevansi model, serta vector database yang bisa mengaktifkan dan memanfaatkannya secara efisien

Step 2. [Prompt construction / retrieval]

• strategi untuk menggabungkan prompting LLM dengan data yang sesuai konteks menjadi semakin kompleks, dan makin penting sebagai sumber diferensiasi produk
• sebagian besar developer memulai proyek baru dengan prompt sederhana, baik berupa instruksi langsung (zero-shot prompting) maupun disertai beberapa contoh (few-shot prompting)
• prompt seperti ini kadang memberikan hasil yang baik, tetapi belum mencapai tingkat akurasi yang dibutuhkan untuk deployment production
• tahap berikutnya dalam prompting adalah merancang agar respons model berlandaskan pada sumber kebenaran tertentu, dan memberi konteks eksternal yang tidak dipelajari model saat training
• Prompt Engineering Guide merangkum 12 strategi prompt tingkat lanjut
• di sinilah framework orkestrasi seperti LangChain/LlamaIndex bersinar
  • mereka mengabstraksi banyak detail dari prompt chaining
  • termasuk integrasi API eksternal, pengambilan data konteks dari vector database, pemeliharaan memori antar beberapa panggilan LLM, dan sebagainya
  • mereka juga menyediakan template untuk banyak program umum
  • output mereka adalah prompt, atau beberapa prompt, yang akan dikirim ke language model
  • di kalangan startup dan developer hobi, LangChain adalah yang paling banyak digunakan
• LangChain masih merupakan proyek baru (versi saat ini 0.0.220)
  • tetapi sudah mulai terlihat aplikasi yang menggunakannya masuk production
  • beberapa developer, terutama early adopter LLM, lebih suka beralih ke Python murni di production untuk menghilangkan dependensi
  • tetapi kami berpikir pendekatan DIY seperti ini akan perlahan berkurang, seperti halnya di web app stack (kebanyakan orang akhirnya memakai framework)
• pembaca yang jeli mungkin melihat ChatGPT ada di kotak orkestrasi
  • secara umum, ChatGPT adalah aplikasi, bukan developer tool, tetapi bisa diakses lewat API
  • dalam beberapa hal, ia melakukan hal yang mirip dengan framework orkestrasi ini (abstraksi prompt, mempertahankan state, mengambil data konteks lewat plugin, dll.)
  • memang bukan kompetitor langsung dari tool yang dibahas di sini, tetapi ChatGPT bisa dianggap sebagai solusi alternatif. Ia bisa menjadi alternatif sederhana yang cepat dirangkai dan digunakan

Step 3. [Prompt execution / inference]

• saat ini OpenAI adalah pemimpin di antara language model
• hampir semua developer memulai pengembangan aplikasi LLM dengan model GPT-4 dan GPT-4-32k
• mudah digunakan, bisa dipakai di berbagai domain, dan tidak membutuhkan fine-tuning maupun self-hosting
• ketika masuk production dan skala membesar, berbagai opsi mulai terbuka
  • beralih ke gpt-3.5-turbo:
    • lebih dari 50 kali lebih murah dan jauh lebih cepat daripada GPT-4
    • dipilih ketika akurasi setingkat GPT-4 tidak dibutuhkan, respons cepat diperlukan, atau perlu melayani pengguna gratis secara efisien
  • bereksperimen dengan model vendor lain (terutama model Claude dari Anthropic)
    • Claude menawarkan inferensi cepat, akurasi setara GPT-3.5, opsi kustomisasi lebih banyak, dan context window hingga 100k (meski akurasinya turun pada konteks yang sangat panjang)
  • mengalihkan sebagian request ke model open source
    • ini bisa efisien untuk use case B2C berskala besar seperti search/chat yang memiliki variasi kompleksitas query atau perlu melayani pengguna gratis dengan biaya rendah
• model open source saat ini masih mengejar produk proprietary, tetapi jaraknya mulai menyempit
  • model LLaMA dari Meta menetapkan standar baru untuk akurasi open source dan memicu berbagai turunannya
  • LLaMA hanya diizinkan untuk riset, tetapi banyak provider ikut serta untuk melatih model dasar alternatif (Together, Mosaic, Falcon, Mistral)
  • Meta sedang dibicarakan akan merilis model LLaMa 2 yang benar-benar open source
• jika LLM open source mencapai tingkat akurasi yang mirip GPT-3.5, kita bisa mengharapkan momen seperti Stable Diffusion untuk teks
  • eksperimen skala besar, berbagi, dan productionisasi model fine-tuned, dll.
  • perusahaan hosting seperti Replicate sudah mulai menambahkan tool agar developer lebih mudah menggunakan model-model ini
  • keyakinan developer juga makin besar bahwa model yang lebih kecil namun telah di-fine-tune bisa mencapai akurasi model state-of-the-art
• sebagian besar developer yang kami ajak bicara belum terlalu mendalami tool operasi untuk LLM
  • caching umum digunakan, biasanya dengan Redis (karena memperbaiki waktu respons dan biaya)
  • tool seperti Weights & Biases, MLFlow, PromptLayer, dan Helicone juga banyak dipakai
    • tool-tool ini memungkinkan logging, pelacakan, dan evaluasi output LLM untuk pembuatan prompt cepat, tuning pipeline, dan pemilihan model
  • tool untuk memvalidasi output LLM (Guardrails) atau mendeteksi prompt injection (Rebuff) juga mulai banyak bermunculan
  • sebagian besar tool operasi ini mendorong penggunaan Python client mereka sendiri untuk melakukan panggilan LLM, sehingga menarik untuk melihat bagaimana semuanya akan hidup berdampingan nantinya
• terakhir, bagian statis dari LLM (semua selain model) juga harus di-host di suatu tempat
  • solusi yang paling umum adalah Vercel atau cloud provider besar
  • tetapi dua kategori baru sedang muncul
    • Steamship menyediakan hosting end-to-end untuk aplikasi LLM, termasuk fitur orkestrasi (LangChain), konteks data multi-tenant, tugas asinkron, vector store, manajemen key, dll.
    • Anyscale dan Modal memungkinkan developer meng-host model dan kode Python secara bersamaan

Bagaimana dengan Agent?

• elemen terpenting yang hilang dari arsitektur referensi ini adalah AI Agent Framework
• AutoGPT adalah "eksperimen open source untuk membuat GPT-4 sepenuhnya otonom" dan merupakan repo GitHub dengan pertumbuhan tercepat dalam sejarah pada musim semi tahun itu
• sekarang hampir semua proyek AI memasukkan agent dalam suatu bentuk
• sebagian besar developer yang kami ajak bicara sangat antusias dengan potensi agent
  • pola in-context learning yang dijelaskan dalam artikel ini lebih baik untuk mendukung tugas pembuatan konten, serta bagus untuk mengatasi halusinasi dan masalah kesegaran data
  • sebaliknya, agent memberikan kemampuan yang secara fundamental baru bagi aplikasi AI
    • seperti menyelesaikan masalah kompleks, melakukan aksi terhadap dunia luar, atau belajar dari pengalaman setelah deployment
    • hal itu dilakukan melalui kombinasi penalaran/perencanaan tingkat lanjut, penggunaan tool, memori/rekursi/self-reflection, dan sebagainya
  • agent berpotensi menjadi bagian pusat dari arsitektur aplikasi LLM (jika Anda percaya pada perbaikan diri lewat rekursi, bahkan bisa mengambil alih seluruh stack)
  • framework seperti LangChain sudah mengintegrasikan konsep agent
  • hanya ada satu masalah: agent masih belum benar-benar bekerja dengan baik
  • saat ini sebagian besar framework agent masih berada pada tahap PoC — demo yang menakjubkan memang mungkin, tetapi belum stabil atau mudah direproduksi
  • kami terus mengamati bagaimana mereka akan berkembang

Menatap ke Depan

• model AI pra-latih adalah perubahan arsitektur paling penting dalam software sejak internet
• dengan ini, tiap developer bisa membangun aplikasi AI dalam hitungan hari yang melampaui proyek machine learning supervised yang biasanya membutuhkan tim besar dan waktu berbulan-bulan
• tool dan pola yang diperkenalkan di sini kemungkinan bukan kondisi akhir, melainkan titik awal untuk integrasi LLM

[sysmoon]

Tulisan ini terasa ditulis dengan wawasan dan pengalaman yang mendalam.
Berdasarkan isi ini, sepertinya akan sangat membantu dalam merancang arsitektur aplikasi LLM.

Karena belum ada pemenang yang benar-benar jelas untuk tiap bidang dalam ekosistem, banyak solusi bercampur dalam satu situasi,
sehingga persoalan pemilihan makin banyak, dan tampaknya kini kemampuan utamanya adalah menemukan kombinasi yang tepat sesuai kebutuhanmu.

[nicewook]

Ini tulisan yang sangat berbobot. Saya sedang membacanya pelan-pelan.

[cwyang]

Kalau GN diajarkan ke LLM, apakah Guru-nim juga akan jadi lebih nyaman? ^^;
Terima kasih.

[cwyang]

Wah, jadi Anda membuat GN+ ya :-o

[xguru]

Sepertinya memang akan jadi lebih nyaman, tapi saya rasa saya akan tetap terus membaca tulisan seperti ini sambil menganggapnya sebagai bagian dari belajar. hehe
Kalau GN⁺ menangani semua berita lain, bisa jadi efeknya justru makin banyak tulisan seperti ini!

[cosine20]

Terima kasih atas tulisan dan ringkasannya yang bagus.