LLM applications के लिए नई आर्किटेक्चर
(a16z.com)- a16z द्वारा संकलित "LLM app stack के लिए reference architecture"
Emerging LLM App Stack
Contextual Data
- Data Pipelines: Databricks, Airflow, Unstructured,..
- Embedding Model: OpenAI, Cohere, Hugging Face
- Vector Database: Pinecone, Weaviate, Chroma, pgvector
Prompt Few-shot Examples
- 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,...
Design Pattern: In-context Learning
- In-Context Learning: LLM को fine-tuning के बिना वैसे ही इस्तेमाल करते हुए, smart prompting और कुछ "Contextual" डेटा पर आधारित शर्तों का उपयोग करना
- उदाहरण) अगर कानूनी दस्तावेज़ों पर जवाब देने वाला chatbot बनाना हो, तो naive तरीके से सभी दस्तावेज़ ChatGPT में डालकर सवाल पूछा जा सकता है, लेकिन यह सिर्फ छोटे dataset के लिए संभव है। ChatGPT का सबसे बड़ा मॉडल भी लगभग 50 पेज ही प्रोसेस कर पाता है
In-Context Learning में केवल संबंधित दस्तावेज़ भेजे जाते हैं और उन्हीं के आधार पर जवाब लिया जाता है - इसलिए यह निम्न 3-स्टेप workflow से बना होता है
- Step 1. डेटा preprocessing / embedding
- Step 2. prompt निर्माण / vector DB से संबंधित दस्तावेज़ retrieval
- Step 3. prompt execution / inference
- यह काम भले बहुत लगे, लेकिन LLM को खुद train और fine-tune करने की तुलना में यह कहीं आसान है
Step 1. [Data preprocessing / embedding]
→ Contextual Data, Data Pipeline से होकर Embedding Model में जाता है और फिर Vector Database में स्टोर होता है
Contextual Data
- टेक्स्ट दस्तावेज़, PDF, CSV और SQL tables
- ज़्यादातर मामलों में डेटा loading और transformation के लिए मौजूदा ETL tools (Databricks, Airflow) वैसे ही उपयोग किए जाते हैं
- कुछ मामलों में LangChain, LlamaIndex जैसे orchestration framework में built-in document loaders का उपयोग होता है
- stack का यह हिस्सा अभी अपेक्षाकृत कम विकसित माना जाता है, और LLM apps के लिए विशेष रूप से बने data replication solutions में अवसर है
Embeddings
- अधिकांश developers OpenAI API का उपयोग करते हैं (
text-embedding-ada-002मॉडल)- इसे उपयोग करना आसान है, reasonably अच्छे परिणाम देता है, और लगातार सस्ता होता जा रहा है
- कुछ बड़ी कंपनियाँ Cohere को explore कर रही हैं। यह कुछ खास scenarios में बेहतर performance देता है
- open source पसंद करने वाले developers के लिए Hugging Face की Sentence Transformers library standard है
- इसके अलावा use case के अनुसार विभिन्न प्रकार की embeddings बनाना भी संभव है
- यह niche मामला है, लेकिन promising research क्षेत्र है
Vector Database
- preprocessing pipeline का सबसे महत्वपूर्ण हिस्सा vector database है
- इसका काम अरबों तक embeddings (vectors) को कुशलता से स्टोर, compare और search करना है
- बाज़ार में सबसे आम विकल्प Pinecone है
- यह पूरी तरह cloud-hosted है, इसलिए शुरू करना आसान है
- इसमें बड़े enterprises की production ज़रूरतों के लिए कई फीचर्स हैं (अच्छी performance, SSO, uptime SLA आदि)
- लेकिन उपलब्ध vector databases की संख्या बहुत ज़्यादा है। खास तौर पर:
- Weaviate, Vespa, Qdrant जैसे open source विकल्प
- बेहतरीन single-node performance देते हैं और specific apps के अनुसार tune किए जा सकते हैं
- custom platform बनाना पसंद करने वाली अनुभवी AI teams में लोकप्रिय हैं
- Chroma, Faiss जैसी local vector management libraries
- शानदार developer experience
- छोटे apps और development experiments के लिए आसानी से चलाई जा सकती हैं
- पूर्ण बड़े-स्तर के database का विकल्प नहीं हैं
pgvectorजैसे OLTP extensions- उन developers के लिए vector support का अच्छा समाधान, जो हर database requirement में Postgres फिट करना चाहते हैं, या उन कंपनियों के लिए जो अपनी अधिकांश data infrastructure एक ही cloud provider से खरीदती हैं
- लंबी अवधि में vector और scalar workloads को इस तरह tightly coupled रखना सही है या नहीं, यह अभी स्पष्ट नहीं है
- Weaviate, Vespa, Qdrant जैसे open source विकल्प
- आगे देखें तो अधिकांश open source vector database कंपनियाँ cloud products विकसित कर रही हैं
- हमारे शोध के अनुसार cloud पर विभिन्न use cases में शानदार performance देना बहुत कठिन है
- इसलिए यह चुनाव short term में शायद न बदले, लेकिन long term में बदलने की संभावना ज़्यादा है
- मुख्य सवाल यह है कि क्या vector databases भी OLTP और OLAP की तरह एक या दो प्रसिद्ध systems में समेकित हो जाएंगे
- एक और सवाल यह है कि जैसे-जैसे अधिकतर models में उपलब्ध context window बढ़ेगी, embeddings और vector databases कैसे विकसित होंगे
- यह कहना आकर्षक लग सकता है कि अगर सारा contextual data prompt में डाला जा सकता है, तो embeddings की ज़रूरत खत्म हो जाएगी,
- लेकिन इस पर विशेषज्ञों की राय है कि embedding pipelines और भी अधिक महत्वपूर्ण हो सकती हैं
- बड़े context windows शक्तिशाली tool हैं, लेकिन उनके साथ काफी computational cost जुड़ी होती है। इसलिए उनका efficient उपयोग अधिक महत्वपूर्ण है
- अब हम ऐसे विभिन्न embedding models देखेंगे जो लोकप्रिय हो रहे हैं, relevance के लिए सीधे train किए जाते हैं, और ऐसे vector databases जो उन्हें कुशलता से activate और use कर सकें
Step 2. [Prompt construction / retrieval]
- LLM prompting और contextual data को जोड़ने की रणनीतियाँ लगातार अधिक जटिल हो रही हैं, और product differentiation के स्रोत के रूप में और भी महत्वपूर्ण बन रही हैं
- अधिकांश developers नए projects की शुरुआत सरल prompts से करते हैं, जिनमें direct instructions (zero-shot prompting) या कुछ examples (few-shot prompting) शामिल होते हैं
- ऐसे prompts कभी-कभी अच्छे परिणाम देते हैं, लेकिन production deployment के लिए आवश्यक accuracy स्तर तक नहीं पहुँचते
- prompting का अगला चरण है मॉडल के उत्तर को किसी truth source से grounded करना और मॉडल को ऐसा external context देना जिस पर उसे train नहीं किया गया था
- Prompt Engineering Guide में 12 advanced prompt strategies संकलित हैं
- यहीं LangChain/LlamaIndex जैसे orchestration frameworks चमकते हैं
- ये prompt chaining की कई बारीकियों को abstract कर देते हैं
- external APIs से integration, vector database से contextual data retrieval, कई LLM calls के बीच memory बनाए रखना आदि
- ये कई सामान्य programs के लिए templates भी प्रदान करते हैं
- इनका output वह prompt या prompts होते हैं जिन्हें language model को भेजा जाता है
- startups और hobby developers के बीच LangChain सबसे अधिक उपयोग में है
- LangChain अभी भी नया project है (वर्तमान version 0.0.220)
- फिर भी, इसके उपयोग से बने apps production में दिखने लगे हैं
- कुछ developers, विशेषकर LLM early adopters, dependencies हटाने के लिए production में pure Python पर जाना पसंद करते हैं
- लेकिन हमारा मानना है कि web app stack की तरह यह DIY तरीका समय के साथ कम होगा (ज़्यादातर लोग frameworks का उपयोग करेंगे)
- तेज़ नज़र वाले पाठकों ने orchestration box में ChatGPT को देखा होगा
- आम तौर पर ChatGPT developer tool नहीं बल्कि एक app है, लेकिन इसे API के माध्यम से access किया जा सकता है
- एक अर्थ में यह इन orchestration frameworks जैसा व्यवहार करता है (prompt abstraction, state retention, plugins के जरिए contextual data retrieval आदि)
- यह यहाँ बताए गए tools का सीधा competitor नहीं है, लेकिन ChatGPT को एक वैकल्पिक समाधान माना जा सकता है। यह तेज़ी से सेटअप और उपयोग के लिए एक सरल विकल्प हो सकता है
Step 3. [Prompt execution / inference]
- फिलहाल OpenAI language models में leader है
- लगभग सभी developers GPT-4, GPT-4-32k मॉडल से LLM app development शुरू करते हैं
- ये उपयोग में आसान हैं, कई domains में काम आते हैं, और fine-tuning या self-hosting की आवश्यकता नहीं होती
- production में जाने और scale बढ़ने पर कई विकल्प खुलते हैं
gpt-3.5-turboपर स्विच:- यह 50x से अधिक सस्ता है और GPT-4 से काफ़ी तेज़ है
- जब GPT-4 स्तर की accuracy की ज़रूरत न हो, और तेज़ response time चाहिए या free users को efficient support देना हो, तब यह विकल्प चुना जाता है
- दूसरे vendor models को experiment करना (खासकर Anthropic के Claude models)
- Claude तेज़ inference, GPT-3.5 स्तर की accuracy, अधिक custom options, और अधिकतम 100k context window देता है (हालाँकि context लंबा होने पर accuracy घटती है)
- कुछ requests को open source models की ओर route करना
- search/chat जैसे बड़े B2C use cases में, जहाँ query complexity अलग-अलग होती है या free users को कम लागत पर serve करना होता है, यह प्रभावी हो सकता है
- open source models अभी proprietary products का पीछा कर रहे हैं, लेकिन अंतर कम होना शुरू हो गया है
- Meta के LLaMA models ने open source accuracy के लिए नया benchmark सेट किया और कई variants को जन्म दिया
- LLaMA केवल research use के लिए licensed था, लेकिन वैकल्पिक base models (Together, Mosaic, Falcon, Mistral) को train करने के लिए कई providers सामने आए
- Meta सच्चे open source LLaMa 2 model को जारी करने पर चर्चा कर रहा है
- जब open source LLM, GPT-3.5 जैसी accuracy तक पहुँच जाएंगे, तब text में भी Stable Diffusion Moment जैसी स्थिति की उम्मीद की जा सकती है
- बड़े पैमाने पर experimentation, sharing, और fine-tuned models का productionization आदि
- Replicate जैसी hosting कंपनियाँ पहले से ऐसे tools जोड़ रही हैं ताकि developers इन models का उपयोग और आसानी से कर सकें
- developers का यह विश्वास बढ़ रहा है कि छोटे लेकिन fine-tuned models भी state-of-the-art models की accuracy तक पहुँच सकते हैं
- जिन अधिकांश developers से हमने बात की, वे LLM के लिए operational tools पर बहुत गहराई से नहीं गए थे
- Caching आम है, और आमतौर पर Redis से की जाती है (क्योंकि इससे response time और cost बेहतर होते हैं)
- Weights & Biases, MLFlow, PromptLayer, Helicone जैसे tools भी काफ़ी उपयोग में हैं
- इनके जरिए LLM outputs को log, trace और evaluate किया जा सकता है ताकि तेज़ prompt creation, pipeline tuning, और model selection संभव हो
- LLM outputs validation (Guardrails) या prompt injection detection (Rebuff) जैसे tools भी तेज़ी से उभर रहे हैं
- इनमें से अधिकांश operational tools अपने Python client के माध्यम से LLM calls करने की सलाह देते हैं, इसलिए आगे चलकर ये एक-दूसरे के साथ कैसे coexist करेंगे, यह देखना दिलचस्प होगा
- अंत में, LLM का static हिस्सा (models के अलावा बाकी सब कुछ) भी कहीं न कहीं host किया जाना चाहिए
- सबसे आम समाधान Vercel या प्रमुख cloud providers हैं
- लेकिन दो नई categories उभर रही हैं
- Steamship, LLM apps के लिए end-to-end hosting देता है, जिसमें orchestration (LangChain), multi-tenant data context, async tasks, vector store, key management जैसी सुविधाएँ शामिल हैं
- Anyscale और Modal developers को models और Python code दोनों को एक साथ host करने देते हैं
Agent का क्या?
- इस reference architecture में सबसे महत्वपूर्ण गायब तत्व AI Agent Framework है
- AutoGPT इस वसंत में "GPT-4 को पूरी तरह autonomous बनाने के लिए open source experiment" के रूप में इतिहास का सबसे तेज़ी से बढ़ने वाला GitHub repo था
- आजकल लगभग हर AI project में किसी न किसी रूप में agents शामिल हैं
- जिन अधिकांश developers से हमने बात की, वे agents की क्षमता को लेकर बहुत उत्साहित हैं
- इस लेख में वर्णित in-context learning pattern content generation tasks को बेहतर support करता है, और hallucination तथा data freshness की समस्याओं को हल करने में उपयोगी है
- दूसरी ओर agents, AI apps को मूल रूप से नई क्षमताएँ देते हैं
- जैसे जटिल समस्याएँ हल करना, बाहरी दुनिया पर actions लेना, या deployment के बाद अनुभव से सीखना
- यह advanced reasoning/planning, tools के उपयोग, memory/recursion/self-reflection के संयोजन से किया जाता है
- agents, LLM app architecture का केंद्रीय हिस्सा बन सकते हैं (और अगर आप recursion-आधारित self-improvement में विश्वास करते हैं, तो पूरा stack भी घेर सकते हैं)
- LangChain जैसे frameworks पहले ही agent concept को integrate कर चुके हैं
- बस एक समस्या है: agents अभी ठीक से काम नहीं करते
- इस समय अधिकांश agent frameworks PoC चरण में हैं — शानदार demos संभव हैं, लेकिन वे स्थिर या reproducible नहीं हैं
- हम देख रहे हैं कि वे आगे कैसे विकसित होते हैं
आगे की ओर देखते हुए
- pre-trained AI models, इंटरनेट के बाद software में सबसे महत्वपूर्ण architectural बदलाव हैं
- इनके कारण अब हर developer कुछ ही दिनों में ऐसे AI apps बना सकता है, जो बड़े teams द्वारा महीनों में बनाए जाने वाले supervised machine learning projects से भी आगे निकल जाएँ
- यहाँ प्रस्तुत tools और patterns अंतिम रूप नहीं, बल्कि LLM integration के लिए एक शुरुआती बिंदु होने की अधिक संभावना रखते हैं
6 टिप्पणियां
यह काफ़ी insight वाला और गहराई महसूस कराने वाला लेख लग रहा है।
इस सामग्री के आधार पर LLM app architecture डिज़ाइन करने में काफ़ी मदद मिलेगी।
इकोसिस्टम में अभी क्षेत्रवार कोई स्पष्ट winner नहीं है, इसलिए कई solutions मिले-जुले रूप में मौजूद हैं।
इससे चुनाव की समस्या बढ़ जाती है, और अपनी requirements के हिसाब से सही combination ढूंढ पाना ही अब एक अहम capability बनता जा रहा है.
यह बहुत ही बढ़िया और जानकारी से भरपूर लेख है। मैं इसे ध्यान से पढ़ रहा हूँ।
अगर LLM को GN सिखाया जाए, तो क्या गुरुजी के लिए भी यह आसान हो जाएगा? ^^;
धन्यवाद।
अरे, आपने GN+ बना दिया :-o
लगता है कि इससे काम थोड़ा आसान तो होगा, लेकिन ऐसे लेख मैं शायद पढ़ाई समझकर लगातार पढ़ता रहूंगा। हा हा
GN⁺ अगर बाकी सारी खबरें संभाल ले, तो शायद ऐसे लेख और भी बढ़ने का असर हो सकता है!
अच्छे लेख और सारांश के लिए धन्यवाद।