ऑफ़लाइन-फ़र्स्ट AI: ऐसा LLM जो बिना नेटवर्क के चले

नौ घंटे से बिजली नहीं है, सेल नेटवर्क पर भारी दबाव है, और गैराज के फ़्रीज़र में शनिवार को खरीदा गया मांस रखा है। क्या अब भी उसे खाना सुरक्षित है? आम दिनों में आप किसी चैटबॉट से पूछ लेते। पर अभी सबसे पहले इंटरनेट ही टूटा है। यही परिदृश्य ऑफ़लाइन-फ़र्स्ट AI टूल्स की बढ़ती श्रेणी का डिज़ाइन ब्रीफ़ है: ऐसा असिस्टेंट और संदर्भ-पुस्तकालय जो पूरी तरह आपके लैपटॉप पर चलता है। मॉडल, कॉर्पस, सर्च इंडेक्स, सब कुछ लोकल चलता है, इसलिए “इस पानी को कैसे शुद्ध करूँ” वाला सवाल ईथरनेट केबल निकाल देने पर भी उतनी ही अच्छी तरह काम करता है। मुझे यह किसी आपदा-किट से ज़्यादा एक आर्किटेक्चर प्रयोग के रूप में दिलचस्प लगता है। नेटवर्क हटाते ही कुछ ऐसे इंजीनियरिंग फ़ैसले सामने आते हैं जिन्हें क्लाउड-होस्टेड AI नज़रअंदाज़ कर सकता है, और ये फ़ैसले आपातकालीन किट से कहीं आगे काम आते हैं। अगर आपने अपने हार्डवेयर पर बड़े भाषा मॉडल चलाने के बारे में सोचा है, तो ऑफ़लाइन असिस्टेंट की बाधाएँ उसी समस्या की सबसे तीखी धार हैं।

ऑफ़लाइन-फ़र्स्ट AI को असल में क्या भेजना पड़ता है

क्लाउड असिस्टेंट एक पतली परत है: आपका क्लाइंट टेक्स्ट भेजता है, डेटा सेंटर टोकन लौटाता है। ऑफ़लाइन असिस्टेंट को यही पूरा स्टैक उपभोक्ता हार्डवेयर पर दोहराना पड़ता है, यानी तीन बड़ी चीज़ें भेजनी होती हैं और उन्हें आपस में सामंजस्य में रखना होता है। पहली, इन्फ़रेंस इंजन। व्यवहार में इसका मतलब llama.cpp या उसका कोई डेरिवेटिव है, क्योंकि यह Apple Silicon, सामान्य x86 CPU और उपभोक्ता GPU पर एक ही डिपेंडेंसी ट्री के साथ चलता है। Mac ऐप इसे साथ बंडल करता है; Windows बिल्ड इसे सेटअप के दौरान खींचता है। दोनों ही स्थितियों में आप यह नहीं मान सकते कि यूज़र की मशीन पर यह पहले से है, तो आप पहली बार चलने के दौरान इसे चुपचाप खुद इंस्टॉल करते हैं। दूसरी, मॉडल। यहीं मामला दिलचस्प होता है और मैं इस पर वापस आऊँगा, क्योंकि सही मॉडल चुनना इस पूरी डिज़ाइन समस्या का केंद्र है। तीसरी, लाइब्रेरी। इस क्षेत्र का एक ऑफ़लाइन असिस्टेंट लगभग 9,30,000 विकिपीडिया लेख (सबसे ज़्यादा पढ़े जाने वाला हिस्सा), MedlinePlus और WikiMed जैसे मेडिकल संदर्भ, FEMA और CDC के आपातकालीन दिशा-निर्देश, सैन्य उत्तरजीविता मैनुअल, wikiHow, iFixit की मरम्मत गाइड, और घरेलू मरम्मत व हैम रेडियो जैसे विषयों पर Stack Exchange के Q&A डंप साथ लेकर आता है। सब सादा टेक्स्ट है, और हर लेख के साथ उसका लाइसेंस सुरक्षित रखा और दिखाया जाता है। पूरा डाउनलोड लगभग 9 GB का है, जो इंस्टॉल होने पर 19 GB तक फैल जाता है; विकिपीडिया और iFixit के बिना हल्का संस्करण 1.3 GB का है। यह जितना इंजीनियरिंग का काम है, उतना ही क्यूरेशन का भी: किसी ने तय किया है कि कौन से स्रोत इस छँटाई में बचेंगे। पूरी चीज़ को पाँच मिनट की क्लिक वाली तीन-चरण सेटअप प्रक्रिया में फ़िट होना है, जिसमें डाउनलोड में ढाई घंटे तक लग सकते हैं। आखिरी संख्या जितनी दिखती है उससे ज़्यादा मायने रखती है: यही डाउनलोड विंडो आपका इकलौता मौका है कुछ भी लाने का, हमेशा के लिए। यह वही अनुशासन है जो आप ऐसे सॉफ़्टवेयर पर लगाते हैं जिसे आप रीबूट या रीच नहीं कर सकते, बस यहाँ अनरीचेबल माहौल एक तूफ़ान से अंधेरी हुई रसोई है।

मॉडल टियरिंग की समस्या: एक ऐप, कई दिमाग़

यह वह फ़ैसला है जो क्लाउड सॉफ़्टवेयर को कभी नहीं लेना पड़ता: आप नहीं जानते कि यूज़र के पास कैसा हार्डवेयर है, आप उसकी RAM जाँचकर उसे किसी बड़े क्लस्टर पर नहीं भेज सकते, और यह जवाब हर आगे के जवाब के डाउनलोड साइज़ और उसकी गुणवत्ता, दोनों को हमेशा के लिए बदल देता है। इस श्रेणी के टूल्स का समाधान है हार्डवेयर-जाँच आधारित टियरिंग। पहली बार लॉन्च होने पर ऐप सिस्टम मेमोरी जाँचता है और एक ऐसा मॉडल चुनता है जो फ़िट हो सके: - 128 GB या उससे ज़्यादा: एक बड़ा फ़्लैगशिप-स्तर मॉडल (एक बिल्ड NVIDIA Nemotron 3.5 Super इस्तेमाल करता है, डिस्क पर लगभग 80 GB), जो ब्लैकआउट और प्राथमिक उपचार के सवालों की प्रोजेक्ट की अंधी-जाँच परीक्षा में 22 में से 21 अंक लाता है। - 32–96 GB: लगभग 27B पैरामीटर वाला मध्यम आकार का मॉडल (लगभग 18 GB), वह भी 22 में से 21। - Windows पर 32 GB: स्पीड के लिए ट्यून किया गया लगभग 25 GB का मॉडल, 22 में से 19। - 16–31 GB: 8B-क्लास का मॉडल (लगभग 6 GB), 22 में से 14। आखिरी पंक्ति को फिर से पढ़िए। ज़्यादातर लोगों के पास जो मशीन होती है, यानी 16 GB का लैपटॉप, उसे ऐसा दिमाग़ मिलता है जो आधिकारिक दिशा-निर्देशों के मुख्य बिंदु को लगभग एक-तिहाई बार चूक जाता है, और वह भी ऐसे सवालों पर जिनका मुख्य बिंदु यह है कि “छह घंटे कमरे के तापमान पर रखा चिकन मत खाओ।” यही ऑफ़लाइन-फ़र्स्ट AI का असहज गणित है। क्वांटाइज़ेशन और छोटे मॉडल सच में अच्छे हो गए हैं, एक अच्छी तरह ट्यून किया गया 8B मॉडल अच्छा लेखन सहायक और ठीक-ठाक सर्च इंटरफ़ेस है। लेकिन गुणवत्ता की यह वक्र रेखा आपकी डिप्लॉयमेंट की बाधाओं के हिसाब से नहीं मुड़ती। जब कोई क्लाउड ऐप ज़्यादा स्मार्ट मॉडल चाहता है तो वह एक कॉन्फ़िग फ़्लैग पलट देता है। जब ऑफ़लाइन ऐप को ऐसा मॉडल चाहिए, तो यूज़र को तीन साल पहले एक बड़ा लैपटॉप खरीदा होना चाहिए था। आप वक्र को शिप करते हैं, और वक्र आपको शिप कर देता है। ईमानदार बचाव वही है जो ये टूल अपनाते हैं: छोटे मॉडल को लाइब्रेरी का अधिकारी नहीं, बल्कि उसका इंटरफ़ेस मानना। हर जवाब ठीक-ठीक बताता है कि कौन से लेख पढ़े गए, और संबंधित हिस्सा हाइलाइट होता है, क्योंकि डिज़ाइनरों को पता है कि 8B टियर कभी-कभी गलत होगा।

रिट्रीवल फ़ीचर नहीं, ट्रस्ट लेयर है

हर रिट्रीवल-ऑगमेंटेड जनरेशन सिस्टम अब सोर्स दिखाता है; क्लाउड में यह एक चेकबॉक्स फ़ीचर है, पारदर्शिता का थोड़ा दिखावा। ऑफ़लाइन में रिट्रीवल भार उठाने वाला हिस्सा है। यही वह अकेली चीज़ है जो एक विश्वसनीय लगने वाले हैलुसिनेशन और असली आपात स्थिति में उस पर अमल करने वाले यूज़र के बीच खड़ी होती है। जो डिज़ाइन उभरता है वह कुछ ऐसा है: मॉडल सादे-टेक्स्ट लाइब्रेरी में खोज करता है, शीर्ष पैसेज पढ़ता है, और ऐसा जवाब लिखता है जो उसने जो पढ़ा उसे उद्धृत करे। अगर यूज़र उसे कुछ खोजने को कहे, तो वह खोजेगा, भले ही उसने पहले से याद के आधार पर जवाब दे दिया हो, और UI बताता है कि हर जवाब किस मोड से आया: याद से, उन लेखों से जिन्हें उसने खोला, या उन खोज परिणामों से जिन्हें उसने खोला ही नहीं। यह आखिरी भेद सूक्ष्म भी है और ज़रूरी भी। “मुझे मिलते-जुलते अंश मिले” और “मैंने लेख पढ़ा” अलग-अलग दावे हैं, जिनकी विश्वसनीयता भी अलग है, और इंटरफ़ेस उन्हें वैसा ही मानता है। एक फ़ेल्योर-मोड का विवरण भी है जो मुझे बहुत पसंद है: जब मॉडल खोज करने चला गया पर अंतिम जवाब लिख नहीं पाया, जो छोटे मॉडल वास्तव में करते हैं, तो ऐप सबसे अच्छे मिले लेखों को उसके सामने फिर से रखता है और उसे एक बार और कोशिश करने को कहता है, बजाय इसके कि यूज़र को कुछ भी न दिखाए। ऑफ़लाइन में आप बड़े मॉडल या रिट्राई क्यू पर वापस नहीं जा सकते। रिट्राई को आप एजेंट लूप में ही बना देते हैं। यह एक छोटा उदाहरण है कि लोग यह कहते समय क्या मतलब रखते हैं कि LLM एजेंट वितरित सिस्टम की तरह व्यवहार करते हैं: हर जगह आंशिक विफलता, और ऑर्केस्ट्रेशन लेयर का काम है उस विफलता को झेलने लायक बनाना। एक और आर्किटेक्चर चुनाव है जिसे चुराने लायक है: रीज़निंग बजट। ऐप बताता है कि जवाब देने से पहले मॉडल कितने टोकन सोच सकता है: बंद, 1,000, 4,000, 16,000, या असीमित। सीमा पहुँचने पर सोच काट दी जाती है और मॉडल जो उसके पास है उसी से जवाब देता है। बैटरी पर, जो मॉडल चक्कर लगाकर सोचता है वह सिर्फ़ गलत नहीं होता, बल्कि बिजली की बर्बादी भी होता है। कठोर सीमा असीमित कम्प्यूट समस्या को सीमित बना देती है, और जब दीवार का सॉकेट ही एक कल्पना हो, तो यही सहज प्रवृत्ति आपको चाहिए।

संशयवादियों की बात में दम है (पर आधे हिस्से में ही)

इस पूरी श्रेणी की सबसे तीखी आलोचना: LLM को छोड़कर खोजने योग्य आर्काइव क्यों न भेजा जाए? Kiwix सालों से ठीक यही कर रहा है: विकिपीडिया और मेडिकल संदर्भ, संपीड़ित, इंडेक्स किए हुए, ऑफ़लाइन खोजने योग्य, बिना हैलुसिनेशन के खतरे के, और कमज़ोर से कमज़ोर हार्डवेयर पर चलने वाले। क्यूरेटेड टेक्स्ट के डेटासेट के लिए सर्च इंजन शायद ज़्यादा भरोसेमंद टूल है। एक टेस्टर ने ऑफ़लाइन असिस्टेंट से बो ड्रिल बनाने का तरीका पूछा तो पुर्ज़े सही मिले, पर हरकत गलत: मॉडल ने स्पिंडल को हथेलियों के बीच घुमाने का तरीका बताया, बो को पूरी तरह नज़रअंदाज़ कर दिया, और “चिंगारियों को पंखा झलना” लिख दिया, जो घर्षण से आग जलाने पर होता ही नहीं। सर्च इंजन यह गलती नहीं कर सकता, क्योंकि वह कुछ जनरेट ही नहीं करता। पर मुझे लगता है यह आलोचना उस चीज़ को चूक जाती है जिसके लिए इन सिस्टम में LLM असल में है, और डिज़ाइन का सबसे मज़बूत बचाव यह है कि मॉडल की भूमिका बदली जाए: उसे ओरेकल नहीं, सर्च इंटेलिजेंस की तरह इस्तेमाल किया जाए। कीवर्ड सर्च तब फ़ेल होता है जब आपको शब्दावली नहीं पता, जब आपके पास निदान नहीं बल्कि लक्षण हों, जब चीज़ टूटी हो और आपको उसका पुर्ज़ा नाम न पता हो। सिमेंटिक रिट्रीवल “अर्थ में पास” वाली चीज़ों में मदद करता है, पर “तंत्र या कारण से जुड़ी” चीज़ों में नहीं, और यही वह अंतर है जिसे जनरेटिव मॉडल भरता है: वह “पत्तियों के किनारे पीले पड़ रहे हैं” जैसी बात लेकर पाँच ऐसे रास्ते सुझा सकता है जो कीवर्ड कभी नहीं खोजता। मॉडल का काम है आपको सही पन्नों तक पहुँचाना। पन्नों का काम है सही होना। दूसरी आलोचना, “अगर प्रलय के दौरान LLM चाहिए, तो बस कौशल सीख लो”, जीवन की सलाह के रूप में ठीक है, पर सॉफ़्टवेयर की आलोचना के रूप में बेकार। किसी का भी प्राथमिक उपचार ज्ञान बच्चों के जलने, पानी शुद्ध करने की रसायन विद्या और जनरेटर मरम्मत तक नहीं पहुँचता। किताबें यह सब कवर करती हैं; बहस सिर्फ़ इंटरफ़ेस की है। जहाँ संशयवादी सही निशाना लगाते हैं वह 22 में से 14 वाला टियर है। अगर इंटरफ़ेस की परत एक-तिहाई बार गलत है और हर जवाब के साथ “सोर्स जाँचें” की चेतावनी है, तो किसी बिंदु पर ईमानदार उत्पाद वही है जिसके साथ सर्च बॉक्स वाला आर्काइव हो। LLM अपनी जगह तभी कमाता है जब वह साबित करे कि वह गैर-विशेषज्ञों को Ctrl+F से तेज़ी से सही पैसेज तक पहुँचाता है। यह आपके यूज़र के बारे में एक अनुभवजन्य सवाल है, कोई माहौल-आधारित धारणा नहीं।

एक न्यूनतम ऑफ़लाइन-फ़र्स्ट AI स्टैक

अगर आप इसका अपना संस्करण बनाना चाहते हैं, और आपको बनाना चाहिए, क्योंकि यह एक सचमुच सिखाने वाला वीकेंड प्रोजेक्ट है, तो ढाँचा आपकी उम्मीद से छोटा है। दिलचस्प हिस्से चुनाव हैं, कोड नहीं। Python में रिट्रीवल-प्रथम लोकल असिस्टेंट कुछ इस तरह दिखता है:

import subprocess
from pathlib import Path
CORPUS_DIR = Path("./library")          # plain-text articles, one file each
MODEL = "./models/granite-8b-q4.gguf"   # quantized to fit 16 GB RAM
def search_corpus(query: str, k: int = 5) -> list[dict]:
"""Dumb but honest: rank articles by keyword overlap.
Swap in BM25 or embeddings later; the interface is the point."""
terms = set(query.lower().split())
hits = []
for f in CORPUS_DIR.rglob("*.txt"):
text = f.read_text(errors="ignore")
score = sum(text.lower().count(t) for t in terms)
if score:
hits.append({"path": f.name, "score": score, "text": text[:3000]})
return sorted(hits, key=lambda h: -h["score"])[:k]
def answer(question: str) -> str:
sources = search_corpus(question)
context = "\n\n".join(
f"[SOURCE {i}: {s['path']}]\n{s['text']}"
for i, s in enumerate(sources, 1)
)
prompt = (
"Answer ONLY from the sources below. Cite them as [SOURCE n]. "
"If they don't cover it, say so.\n\n"
f"{context}\n\nQuestion: {question}\nAnswer:"
)
out = subprocess.run(
["llama-cli", "-m", MODEL, "-p", prompt,
"-n", "512", "--ctx-size", "8192"],
capture_output=True, text=True,
)
citations = "\n".join(f"[{i}] {s['path']}" for i, s in enumerate(sources, 1))
return out.stdout + "\n\n--- Sources ---\n" + citations
print(answer("how long is food safe in a fridge without power"))

उन चालीस लाइनों में जो बात इसे प्रोडक्ट जैसा महसूस कराती है, खिलौने जैसा नहीं, वह बनी हुई बाधाओं में है: प्रॉम्प्ट स्रोतों के बाहर जवाब देने से मना करता है, उद्धरण यांत्रिक रूप से जोड़े जाते हैं (मॉडल पर फ़ॉर्मेटिंग का भरोसा कभी नहीं किया जाता; एक असली बग में मॉडल ने अपने ही सर्च कमांड की सूची वाली एक “Sources:” लाइन खुद गढ़ दी थी), और जनरेशन की लंबाई सीमित रखी जाती है। उत्पादन के लिए ज़रूरी पर यहाँ न दिखने वाली चीज़ें हैं: सिमेंटिक सर्च के लिए एम्बेडिंग इंडेक्स, रीज़निंग-टोकन बजट, मॉडल फ़ाइल चुनने के लिए मेमोरी जाँच, और UI में दिखाने के लिए हर फ़ाइल का लाइसेंस मेटाडेटा। ध्यान दें कि यहाँ क्या नहीं है: कोई नेटवर्क कॉल नहीं, कोई API key नहीं, कोई टेलीमेट्री नहीं। एक बार मॉडल फ़ाइल और कॉर्पस डिस्क पर आ जाएँ, तो यह प्रोग्राम किसी सवाल को लीक करने में भौतिक रूप से असमर्थ है। गोपनीयता नीति का वादा नहीं रहती, बल्कि डिपेंडेंसी ग्राफ़ का नतीजा बन जाती है।

वे बाधाएँ जो घर तक साथ आती हैं

ऑफ़लाइन-फ़र्स्ट बनाइए, और कुछ गैर-स्पष्ट बाधाएँ आपके आर्किटेक्चर की स्थायी निवासी बन जाती हैं। **स्टोरेज और इंस्टॉल विंडो एक-बार की होती हैं।** पूरी लाइब्रेरी को इंस्टॉल के दौरान लगभग 27 GB खाली जगह चाहिए, फिर वह 19 GB पर बैठती है, और सब कुछ शुरुआती डाउनलोड में ही आना चाहिए। तूफ़ान के दौरान किसी गायब मेडिकल संदर्भ को लेज़ी-लोड करने का कोई विकल्प नहीं है। इससे आप आक्रामक क्यूरेशन की ओर धकेले जाते हैं: 9,30,000 लेख बहुत लगते हैं, जब तक याद न आए कि विकिपीडिया में लाखों लेख हैं। किसी ने पाठकों की संख्या के हिसाब से रैंक करके पूँछ काट दी। **बिजली एक प्रथम-श्रेणी संसाधन है।** MacBook Pro पर मापा गया: जवाब देने में प्रति सवाल 5 से 40 सेकंड तक लगभग 100 W खिंचते हैं, यानी पूरी बैटरी लगभग 100 से 300 जवाब देती है। अब लंबी चेन-ऑफ़-थॉट केवल धीमी नहीं, बल्कि ईंधन का फ़ैसला बन जाती है। रीज़निंग बजट और छोटे-मॉडल टियर ऑप्टिमाइज़ेशन से आगे बढ़कर प्रोडक्ट का हिस्सा बन जाते हैं। **आपका अपडेट चैनल ही आपकी जीवन-रेखा है।** ऐप को मॉडल, लाइब्रेरी और बाइनरी, तीनों एक क्लिक में अपडेट करने होंगे, बिना लोकल स्टेट तोड़े, क्योंकि अगली बार यूज़र के पास बैंडविड्थ महीनों बाद आ सकती है। और बैकग्राउंड रिसोर्स अनुशासन एक नए तरीके से मायने रखता है: एक रिलीज़ के फ़िक्स ने Cmd+Q को असल में इन्फ़रेंस इंजन रोकने वाला बना दिया, जो विंडो बंद होने के बाद भी कई गीगाबाइट का मॉडल मेमोरी में रखे हुए था। बैटरी पर यह मेमोरी लीक नहीं, बल्कि गर्मी और घंटों का लीक है। **यूज़र की फ़ाइलें भी ट्रस्ट सीमा में आती हैं।** यूज़र का अपना PDF डालने देना, जैसे जनरेटर मैनुअल या परिवार की आपातकालीन योजना, मतलब आपकी रिट्रीवल पाइपलाइन को प्रतिकूल रूप से गंदे इनपुट संभालने होंगे: स्कैन किए PDF, अजीब एन्कोडिंग, बड़ी फ़ाइलें। ऑफ़लाइन में इनमें से कुछ भी क्लाउड पार्सर को नहीं सौंपा जा सकता।

आपातकाल से परे इस पैटर्न का महत्व

गोपनीयता नीति का वादा नहीं रहती, बल्कि डिपेंडेंसी ग्राफ़ का नतीजा बन जाती है। बिना नेटवर्क कॉल वाला प्रोग्राम कभी कुछ लीक नहीं कर सकता।

सुर्खियाँ आपातकाल वाला ढाँचा बटोरता है, पर कहानी असल में आर्किटेक्चर की है। वही स्टैक, यानी लोकल इन्फ़रेंस, क्यूरेटेड कॉर्पस, उद्धरण वाली रिट्रीवल और कठोर कम्प्यूट बजट, उस क्लिनिक के लिए भी चाहिए जिसके मरीज़ों का डेटा कानूनी रूप से इमारत से बाहर नहीं जा सकता, उस फ़ैक्टरी फ़्लोर के लिए जिसकी मशीनें एयर-गैप्ड हैं, उस पत्रकार के लिए जिसके देश में क्वेरी लॉग एक देनदारी है, या उस रिसर्च शिप के लिए जिसका सैटेलाइट इंटरनेट मेगाबाइट के हिसाब से बिल होता है। चर्चा में एक व्यवसायी ने ठीक यही बताया: जिस संपत्ति पर मोबाइल सिग्नल नहीं आता, वहाँ हर यात्रा से पहले ताज़ा की गई एक मैन्युअली क्यूरेट की गई लाइब्रेरी और लोकल मॉडल, फ़ाइबर उपलब्ध होने पर भी, उनके रोज़मर्रा के क्लाउड AI इस्तेमाल का बड़ा हिस्सा धीरे-धीरे बदल रहे हैं। यही वह दिशा है जिस पर मैं दाँव लगाऊँगा। एक क्वांटाइज़्ड 8B लोकल मॉडल और फ़्रंटियर API मॉडल के बीच का अंतर वास्तविक है, पर रिट्रीवल-आधारित कामों के लिए, जैसे “सही पैसेज ढूँढो और उसका ईमानदारी से सार बताओ”, वह इतना संकरा है कि लोकल विकल्प अक्सर काफ़ी होता है, और पर्याप्तता के साथ शून्य अतिरिक्त लागत और गारंटीड गोपनीयता एक आकर्षक पैकेज बनाते हैं। फ़्रंटियर मॉडल बेहतर होते जा रहे हैं, पर क्वांटाइज़ेशन भी, और छोटे मॉडल उसी स्केलिंग लहर पर थोड़ी देर बाद सवार होते हैं। अगर आप उस वक्र के दक्षता वाले सिरे पर नज़र रख रहे हैं, तो असली इन्फ़रेंस दक्षता की कहानी फ़्लैश-टियर मॉडल में है। इस क्षेत्र में कुछ डिज़ाइन करने की सलाह: पैटर्न चुराइए, प्रेपर वाली सौंदर्य-शैली नहीं। बेरहमी से क्यूरेट कीजिए, क्योंकि 200 ऐसे दस्तावेज़ों की लाइब्रेरी जिन पर आप भरोसा करते हैं, उन 9,30,000 से बेहतर है जो आपने पढ़े ही नहीं। उद्धरण यांत्रिक बनाइए, कभी मॉडल-जनित नहीं। सोचने के लिए मॉडल को कठोर बजट दीजिए। और साफ़-साफ़ तय कीजिए कि आपका मॉडल ओरेकल है या सर्च इंटरफ़ेस। जो टूल जाँच में टिकते हैं, वे इतने ईमानदार होते हैं कि दूसरा विकल्प बनें।

निष्कर्ष

ऑफ़लाइन-फ़र्स्ट AI प्रलय से बचने के बारे में नहीं है। यह जानने के बारे में है कि जब हर बच निकलने का रास्ता, यानी बड़ा मॉडल, क्लाउड फ़ॉलबैक, हमेशा चालू नेटवर्क और असीमित बिजली, बंद कर दिया जाए, तब आपका आर्किटेक्चर कैसा दिखता है। जो बचता है वह है एक क्यूरेटेड कॉर्पस, आपके नियंत्रण से बाहर के हार्डवेयर के हिसाब से आकार का क्वांटाइज़्ड मॉडल, भरोसा ढोने वाली रिट्रीवल, और एक ऐसा एजेंट लूप जो सुंदर तरीके से विफल हो। ये अनुशासन ऑनलाइन दुनिया में भी अच्छे साबित होते हैं। तूफ़ान बस आपको इन्हें जल्दी सीखने पर मजबूर करता है।