- Redis के संस्थापक antirez AI और LLM का अक्सर उपयोग करते हैं, लेकिन उनका मानना है कि इस समय इंसानों की समस्या-समाधान क्षमता LLM से काफी आगे है
- Redis Vector Sets में आए एक जटिल bug को ठीक करने की प्रक्रिया में उन्होंने LLM की सीमाएँ सीधे अनुभव कीं
- LLM द्वारा सुझाए गए algorithm आम तौर पर मानक या सरल समाधानों तक सीमित रहे
- मानव डेवलपर का रचनात्मक दृष्टिकोण ऐसे नवोन्मेषी समाधान देने में अधिक सक्षम है, जहाँ तक LLM के लिए पहुँचना कठिन होता है
- LLM idea validation या बातचीत के साथी के रूप में बहुत उपयोगी हैं, लेकिन अंतिम रचनात्मकता इंसानों के पास है
भूमिका: मानव और LLM की तुलना
- मेरा AI और LLM के प्रति बिल्कुल भी कोई विरोध नहीं है
- मैं लंबे समय से LLM का रोज़मर्रा में उपयोग कर रहा हूँ, और idea testing, code review, alternative exploration जैसे कई कामों में इसका इस्तेमाल करता हूँ
- AI का मौजूदा स्तर निश्चित रूप से व्यावहारिक और प्रभावशाली है, लेकिन मानव बुद्धि से इसका अंतर अभी भी बड़ा है, इस बात पर मैं ज़ोर देता हूँ
- हाल में मुझे यह आवश्यकता इतनी गहराई से महसूस हुई कि संतुलित AI चर्चा करना भी कठिन लगने लगा, इसलिए मैंने यह लेख लिखा
Redis Vector Sets bug का मामला
- हाल ही में मैं Redis के अंदर Vector Sets से जुड़े एक bug को ठीक कर रहा था
- Redis के सहकर्मी मौजूद नहीं थे, इसलिए मैंने file data corruption (RDB/RESTORE) के लिए अतिरिक्त protection feature जोड़ा
- यह feature मूल रूप से बंद रहता है, और checksum पास होने पर भी corruption रोकने के लिए एक अतिरिक्त safety net की तरह काम करता है
- समस्या HNSW data structure की graph representation को RDB में serialize करने की speed optimization के दौरान पैदा हुई
- nodes के बीच connection list को integer के रूप में store किया जाता है, और deserialization के समय उन्हें pointer में restore किया जाता है
- HNSW के self-implementation की एक विशेषता, यानी mutual connection guarantee, के कारण graph/memory corruption होने पर नीचे जैसी समस्याएँ हो सकती हैं
- यह store हो सकता है कि A, B से जुड़ा है, लेकिन B, A से जुड़ा न हो (जैसे numbering error)
- या B node delete होने पर mutual connection का नियम टूट जाता है, A→B link बचा रह जाता है, और बाद में B->A खोजते समय use-after-free bug हो सकता है
- डेटा load होने के बाद यह verify करना ज़रूरी था कि सभी links 'mutual connection' को satisfy करते हैं
- शुद्ध algorithm लागू करने पर complexity O(N^2) होती है. बड़े डेटा (~2 करोड़ vectors) में loading speed 45 सेकंड से बढ़कर 90 सेकंड हो गई, यानी दोगुनी
LLM का उपयोग और उसकी सीमाएँ
- मैंने Gemini 2.5 PRO के साथ बातचीत करते हुए अधिक efficient तरीका पूछा और LLM के सुझावों की समीक्षा की
- LLM का पहला सुझाव: neighbor node list को sort करके binary search लागू करना (यह पहले से ही काफी जाना-पहचाना तरीका है)
- जब इससे कोई बड़ा सुधार नहीं मिला, तो मैंने अतिरिक्त ideas माँगे, लेकिन इससे बेहतर जवाब नहीं मिला
- मैंने खुद एक alternative तरीका सुझाया: hash table का उपयोग करके link pairs (A:B:X, sort करके और bidirectional distinction हटाकर) को register और remove करना
- LLM ने भी इसे अच्छा idea कहा, लेकिन key generation performance और hashing performance जैसी कमियों का ज़िक्र किया
- मैंने आगे सुझाव दिया कि
snprintf के बिना fixed-length key को memcpy से handle किया जाए, जिससे efficiency बढ़े
मानव रचनात्मकता बनाम LLM की सीमाएँ
- मैंने hash table के बिना accumulator पर XOR technique लागू करने का idea पेश किया
- pointer pair (और level information) को accumulator में XOR किया जाता है, mutual connection होने पर वे cancel होकर 0 हो जाते हैं, और missing होने पर pattern बचा रहता है
- हालांकि collision की संभावना और pointer predictability की ओर ध्यान दिलाया गया (LLM भी इससे सहमत था)
- आगे सुधार के तौर पर random seed/hashing (
murmur-128 और urandom seed) को जोड़कर 128-bit accumulator पर XOR लागू किया गया
- अंत में accumulator का मान 0 है या नहीं, इससे mutual connection स्थापित है या नहीं, यह तय किया जाता है
- LLM ने इस तरीके को सामान्य errors और बाहरी attackers, दोनों के खिलाफ अधिक robust और efficient माना
निष्कर्ष
- अंततः मैंने analysis पूरा किया ताकि reliability के आधार पर यह तय कर सकूँ कि इसे अपनाना है या नहीं
- इस मामले में यह स्पष्ट हुआ कि मानव डेवलपर का रचनात्मक, गैर-मानक दृष्टिकोण LLM द्वारा दिए गए सीमित उत्तरों से बेहतर था
- LLM idea validation और बौद्धिक संवाद साथी ('smart duck' की भूमिका) के रूप में बेहद उपयोगी हैं
- लेकिन अंतिम रचनात्मक समाधान निकालने की क्षमता में इंसानों की बढ़त साफ़ है
7 टिप्पणियां
लगता है redis जल्द ही पीछे छूट जाएगा
यह तो साइकिल और दौड़ की रेस कराने जैसा लग रहा है।
antirez 1% मानव डेवलपर हैं। मेरा मानना है कि 1% मानव डेवलपर LLM से लगातार बेहतर रहेंगे। लेकिन 99% का क्या होगा, यह कह पाना मुश्किल है।
AI के ज़रिए troubleshooting करने की कोशिश में सब कुछ विफल हो गया, और आखिरकार कई बार मुझे खुद ही समस्या हल करनी पड़ी है.
मुझे लगता है कि LLM इसलिए उच्च स्तर के और रचनात्मक लगते हैं क्योंकि उन्होंने ऐसे ही लेखन पर training ली है, और उनके परिणामों को बेहतर बनाने के लिए असंख्य वैज्ञानिकों ने उस ज्ञान को सत्यापित करते हुए training data की गुणवत्ता को ऊंचा किया है.
लेकिन समय के साथ trends बदलते रहते हैं, और परिस्थितियों के अनुसार अलग तरह की रचनात्मकता की ज़रूरत होती है, इसलिए आखिरकार क्या यह ज़रूरी नहीं है कि उसे इस्तेमाल करने वाला व्यक्ति अपनी स्थिति के मुताबिक खुद रचनात्मकता दिखाए..
Hacker News राय
मुझे लगा कि यह बात मेरे अनुभव से बिल्कुल मेल खाती है। सच कहूँ तो LLM assistant की मेरे लिए सबसे बड़ी वैल्यू यह है कि वह काफ़ी intelligent ‘rubber duck’ की भूमिका निभाता है। कभी-कभी यह ‘duck’ मेरी बात का विरोध भी करता है, और यहाँ तक कि मेरी सोच को और refine भी कर देता है। (Rubber duck debugging क्या है?) लेकिन मुझे लगता है कि असली सवाल, जिसे हर कोई टालना चाहता है, यह है: ‘क्या यह वैल्यू 2 साल बाद भी बनी रहेगी?’ इसका जवाब मुझे भी नहीं पता
मेरे लिए LLM rubber duck नहीं, बल्कि एक ‘गलत जवाब मशीन’ जैसा है। एक कहावत है कि इंटरनेट पर सही जवाब पाने का सबसे अच्छा तरीका गलत जवाब पोस्ट करना है, और मेरे लिए LLM ठीक वही काम करता है। जब मैं उससे कोई आसान लेकिन झंझट वाला काम करवाता हूँ, तो वह इतना गलत रिज़ल्ट देता है कि मैं झुंझलाकर गुस्से में खुद ही वह काम कर देता हूँ
हद से ज़्यादा आत्मविश्वासी duck, अपनी असली क्षमता की तुलना में बहुत ज़्यादा भरोसा दिखाता है। मैंने बहुत से लोगों को LLM से बात करते-करते रास्ता भटकते देखा है
मेरे लिए LLM ऐसा है जैसे कोई junior developer मेरे नीचे काम कर रहा हो जिसे API की अच्छी समझ है लेकिन architecture में common sense की कमी है। अजीब गलतियों की चिंता में मैं ज़्यादातर PR को टीम review में भेजने से पहले पूरे 3~4 बार देखता हूँ। हाँ, इससे कम से कम मेरा दिमाग दूसरी समस्याओं पर लगा रह सकता है
क्या यह वैल्यू 2 साल बाद भी रहेगी? मेरे लिए ‘क्या मैं इस बातचीत को पार कर पाऊँगा?’ से बड़ा सवाल यह है कि ‘क्या हम 2 साल बाद तक पहुँच भी पाएँगे?’ दुनिया अभी इतनी अस्थिर है कि 6 महीने बाद क्या होगा, यह भी कहना मुश्किल है
मेरे लिए LLM pair programming वाले साथी जैसा लगता है। ऐसा साथी जिससे मैं आइडिया शेयर कर सकता हूँ, जो code review और alternatives दे सकता है। और यह मुझे वे features आज़माने में मदद करता है जिनके बारे में मुझे पहले पता नहीं था
इस comment thread को देखकर थोड़ा लगता है कि लोग ‘इंसान ज़रूरी हैं’, ‘LLM debugging नहीं कर सकते’, ‘LLM गलत दिशा में ले जाते हैं’ जैसी बातों पर बहुत उम्मीद लगाए बैठे हैं। यह सब सही है, लेकिन सिर्फ 2 साल पहले तक जो code generation मुमकिन नहीं थी, उसमें बहुत तेज़ प्रगति हुई है, और अभी भी उसी रफ़्तार से चल रही है। आगे चलकर ‘Pareto law’ की तरह improvement की speed कम हो सकती है, लेकिन प्रगति तो जारी रहेगी। हाल ही में मैंने r/fpga में LLM से पहला testbench version बनाने का अपना अनुभव शेयर किया, और यह देखकर बहुत हैरानी हुई कि जिन लोगों ने खुद कभी कोशिश भी नहीं की, वे इसकी संभावना को ही नकार रहे थे
इस तरह का रवैया professionals के बीच बहुत आम है। मैं /r/law भी गया था, और Dario Amodei की legal AI पर टिप्पणी सुनकर वहाँ जो तुरंत dismissive माहौल था, वह साफ़ महसूस हुआ। शायद यह एक adaptation mechanism हो, या फिर status quo में आराम, लेकिन आर्थिक और सामाजिक बदलावों के लिए future readiness के लिहाज़ से यह बहुत बुरी बात है
यह वैसा ही है जैसे उस दौर में जब assembly ही आधार थी, और programming languages आने पर programmers ने उन्हें (तथ्यों से ज़्यादा मतलब न रखते हुए) inefficient, inflexible और बहुत oversimplified कहकर मज़ाक उड़ाया था। यह नई तकनीक की असली वैल्यू से लगभग अलग एक स्वाभाविक प्रतिक्रिया है
LLM ने थोड़े समय में तेज़ छलाँग लगाई, लेकिन हाल के models कुछ मामलों में पीछे जाते हुए भी लगते हैं। test code generation में अच्छे नतीजे आते हैं, लेकिन जब LLM को नई feature implementation जैसे कामों में बहुत गहराई से इस्तेमाल किया जाता है, तो चीज़ें अजीब होने लगती हैं। नए projects या simple web apps में यह ठीक काम करता है, लेकिन बड़े या legacy codebase में refactoring और feature additions पर इसका असर ज़्यादा नहीं है। उदाहरण के लिए, Claude या ChatGPT को D3 API के बारे में पूरा का पूरा बकवास बनाते मैंने कई बार देखा है
आख़िर में, आप खुद अपना replacement बना रहे हैं, जबकि आपके colleagues सावधानी से आगे बढ़ रहे हैं
ChatGPT-4o ने VHDL लिखने में ज़बरदस्त क्षमता दिखाई है। आज भी low-level controller prototype बनाने में मैंने इसके कमाल के नतीजे देखे
असली software को ठीक से लिखने के लिए जितना context चाहिए, वह LLM के लिए बहुत विशाल है। Software अपने आप में ‘business का codeification’ है। LLM को कैसे पता होगा कि sales team ने ग्राहक से कौन-कौन सी खास शर्तें वादा की हैं, या हर department के कौन से अनकहे नियम हैं? अभी LLM जिस दायरे को संभाल सकते हैं, वह general और सीमित है। दो से ज़्यादा classes हों या 20~30 files से ऊपर चला जाए, तो top-tier LLM भी रास्ता भूल जाते हैं और focus खो देते हैं। context टिकता नहीं, इसलिए बेकार का code churn बहुत बढ़ जाता है। अगर LLM को सच में developers को replace करना है, तो उसे बहुत ज़्यादा context absorb करना होगा, पूरे organization से context इकट्ठा करना होगा, और long-term projects में thought process बनाए रखना होगा। जब ये समस्याएँ सचमुच हल होने के करीब पहुँचेंगी, तभी मैं सच में चिंता करना शुरू करूँगा
हर बार जब लोग इस पर बहस करते हैं कि क्या LLM developers को replace करेंगे, वे एक बात भूल जाते हैं: असली software engineering में code लिखने के अलावा भी बहुत काम होता है। code लिखना तो छोटा हिस्सा है। असली चीज़ social skills, requirement analysis, और यह समझना है कि ग्राहक सच में क्या चाहता था। अक्सर तो ग्राहक खुद भी नहीं जानता कि उसे क्या चाहिए, और engineer को यह पता लगाने में बहुत मेहनत करनी पड़ती है। जो चीज़ इंसानों के लिए भी मुश्किल है, वह LLM कैसे कर पाएगा?
आखिरकार यह feedback loop की बात है, यानी ग्राहक चीज़ को इस्तेमाल करे, राय दे, और उसी आधार पर तेज़ iteration हो। chat UI customer feedback loop के लिए बहुत बढ़िया है, और agent तेज़ी से नए versions बना सकते हैं। LLM abstraction, अलग-अलग component systems, overall structure design, और requirement analysis तक अच्छी तरह कर सकते हैं। असली सवाल यह है कि iteration कितनी तेज़ी से होती है। models की robustness और IQ लगातार बेहतर हो रही है। software engineering का पूरा क्षेत्र पहले ही automation phase में दाखिल हो चुका है। शायद 5 साल बाद इंसान अगर सहायता के बिना काम करे तो वह बहुत बड़ा bottleneck बन जाएगा। AI के साथ गहराई से integrate हुए बिना पीछे रहना तय है
2000s की offshoring लहर में भी यही समस्या थी। overseas teams के लिए change requests या समस्याएँ उठाना मुश्किल था, इसलिए वे सिर्फ जो कहा गया वही बनाते गए, और नतीजा यह हुआ कि चीज़ें बस जमती चली गईं। AI के साथ भी कुछ ऐसा ही होने की संभावना है। शायद नतीजा भी वैसा ही निकले
LLM मूल रूप से software engineering करते ही नहीं हैं। लेकिन यह अपने आप में समस्या नहीं है। सच तो यह है कि बहुत से सफल programs ‘software engineering’ के बिना भी ठीक चलते हैं। खासकर ऐसे माहौल में जहाँ कोई cloud cost structure की परवाह नहीं करता। बल्कि मुझे लगता है कि आगे technical sense रखने वाला कोई IT business partner बिना software engineer की मदद के पूरे apps बना सकेगा। green energy industry में तो यह पहले से रोज़ की हक़ीक़त है। लेकिन दिक्कत तब शुरू होगी जब maintenance, scale, और efficiency की ज़रूरत पड़ेगी। तभी ‘Python में list इस्तेमाल करें या generator’ जैसी बातें अहम हो जाएँगी, और वहीं असली engineering की ज़रूरत पड़ेगी
5 साल बाद शायद हम code design लगभग न के बराबर करें। पहले ही 1 साल पहले की तुलना में मैं बहुत कम code type कर रहा हूँ। लेकिन यह process का सिर्फ एक हिस्सा है, developers पूरी तरह गायब नहीं होने वाले
दूसरी तरफ, सिर्फ ‘coder’ की भूमिका काफ़ी हद तक replace हो रही है। LLM का मज़बूत क्षेत्र यही है। बहुत से ऐसे coders होते हैं जो सिर्फ टिकट देखकर “यह API लो और वह value निकालो” जैसा काम करते हैं, बिना customer requirement समझे या analysis किए। LLM इस हिस्से को तेज़ी से संभाल रहे हैं। proper software engineering इससे बिल्कुल अलग चीज़ है, लेकिन simple coders की demand बहुत बड़ी थी, यह बात नज़रअंदाज़ नहीं करनी चाहिए
यह बहुत महत्वपूर्ण बात है कि abstract concepts और creative problem solving की क्षमता अभी भी इंसानों के पास है। Programmer तर्क का architect होता है, और computer इंसानी सोच को commands में बदलने का माध्यम। tools इंसानों की नकल करके task-specific code generation तो कर सकते हैं, लेकिन बुनियादी abstraction design और build की भूमिका को replace नहीं कर सकते। अगर models सिर्फ code लिखने के बजाय spec के आधार पर पूरा project शुरू से बना सकें, तो developers की भूमिका फिर से बदल जाएगी
हमेशा यह मानकर चलना चाहिए कि ‘क्या बेहतर है’ यह task पर निर्भर करता है। LLM repetitive और formula-driven कामों में (जैसे CSS syntax मिलाना या किसी प्रसिद्ध library का call pattern ढूँढना) मुझसे पहले ही बहुत बेहतर है। ऐसे ‘छोटे-मोटे झंझट’ पहले मेरा बहुत समय लेते थे, लेकिन अब वे लगभग तुरंत निपट जाते हैं, और इससे मैं बहुत खुश हूँ
बुनियादी styling से आगे की चीज़ों में (basic CSS से ज़्यादा), LLM का output उल्टा काफ़ी कमजोर होता है। जब effect को साफ़-साफ़ समझाना मुश्किल हो, या काम subtle हो जाए, तो यह अक्सर सबसे अहम नतीजा नहीं दे पाता और एक ही approach में अटक जाता है
जिसमें मैं कमजोर हूँ (SQL), उसमें LLM मुझसे बेहतर है, लेकिन जिसमें मैं अच्छा हूँ (CSS), उसमें यह उल्टा कमजोर है। इससे पैमाना साफ़ दिखता है
“ज़्यादातर developers से बेहतर” वाली बात, और यह कि CSS न आना LLM को बेहतर दिखाता है, दोनों से मैं सहमत हूँ। सच में बहुत से लोग CSS से नफ़रत करते हैं, उसे सीखते नहीं, और बस मजबूरी में इस्तेमाल करते हैं, इसलिए यह भ्रम पैदा होता है। अगर कोई कंपनी असली CSS expert रखने की हैसियत नहीं रखती और सस्ता विकल्प चाहती है, तब LLM एक विकल्प है; लेकिन अगर उसके पास सच में अच्छे लोगों को रखने की क्षमता है, तो LLM की तुलना ही नहीं। आखिरकार LLM का असली competitor कमजोर developer है
जिन मुख्य languages या domains को आप ठीक से नहीं जानते, उनमें LLM autocomplete बहुत मददगार है। लेकिन अगर आप ‘reflex memory’ विकसित किए बिना सिर्फ LLM पर निर्भर हो जाएँ, तो इस tool की सिफ़ारिशों का मूल्यांकन करने की क्षमता घट सकती है, और आप कमजोर समाधान पर अटक सकते हैं
यह देखकर अच्छा लगता है कि लोग ‘good code’ की चिंता करते हैं, लेकिन डर यह है कि कहीं यह सब असल में बेकार न हो। software industry को business world ने काफ़ी पहले ही निगल लिया था, और यह कब हुआ, यह भी साफ़ नहीं है (क्या Bill Gates के 1976 open letter से?). असली समस्या यह है कि shareholders और executives को code की कम परवाह है, जब तक profit बढ़ता रहे। अगर developers और users की तरफ़ से cultural resistance न हो, तो यह ढाँचा चलता रहेगा
developers/users की cultural resistance न होने पर सब खत्म है — इस बात के जवाब में मैं कहना चाहूँगा कि companies में अब भी बहुत सी जगहें हैं जहाँ अच्छा code लिखा जाता है, सब कुछ पूरी तरह बर्बाद नहीं है। असली सवाल code quality नहीं, बल्कि यह ethical सवाल है कि क्या आप capitalist business goals से सहमत हैं। सुंदर software और वास्तविक दुनिया के बीच संतुलन सबसे महत्वपूर्ण है। मैं खुद developer और founder दोनों हूँ; मुझे open source और engineering पसंद है, लेकिन मैं साथ ही आराम से जीना भी चाहता हूँ
code business की ताकत है। बुरा code, बुरा business बनाता है। hosting teams (physical firewalls, vmware, proxies वगैरह) और public cloud (QEMU, netfilter, simple appliances वगैरह) के बीच स्पष्ट फ़र्क है। किसने किसे निगला है, और भविष्य क्या होगा, यह कोई नहीं जानता
पिछली रात मैंने o3 से जूझते-जूझते पूरा समय निकाल दिया। मैंने ज़िंदगी में कभी Dockerfile नहीं बनाया था, इसलिए सोचा कि o3 को GitHub repository देकर अपने-आप हल करने दूँ, लेकिन उसके output को debug करने में कई घंटे बर्बाद हो गए। वह ऐसी चीज़ें जोड़ देता है जो हैं ही नहीं, जो नहीं हैं उन्हें मिटाता या गड़बड़ कर देता है, और python3 बनाम python जैसे बुनियादी concepts तक में गड़बड़ा जाता है। आखिर में झुंझलाकर मैंने Google docs देखे और बात जल्दी साफ़ हो गई। AI एक शानदार tool है, लेकिन सर्वशक्तिमान नहीं, और किसी न किसी को ज़रूर ‘जागते रहना’ पड़ता है
जो कंपनियाँ LLM·AI से कर्मचारियों की productivity बढ़ाती हैं, वे फलेंगी-फूलेंगी; जो कंपनियाँ कर्मचारियों को पूरी तरह replace करना चाहेंगी, वे असफल होंगी। short term में हो सकता है CEO/executives short-term results से खुश होकर भविष्य की growth को नुकसान पहुँचाने वाले फ़ैसले लें
बिल्कुल सही। programmers के assistant के रूप में LLM का इस्तेमाल करना ठीक है, पूरी तरह replacement बनाना मुश्किल है। तकनीक को संतुलित तरीके से अपनाना ही सही रास्ता है
कर्मचारियों को replace करके short-term value बढ़ाने और उससे कंपनी को फ़ायदा होने का विचार काफ़ी दिलचस्प है। यानी mid/long term में यह कंपनी के लिए नुकसानदेह हो सकता है, लेकिन थोड़े समय के लिए stock price बढ़ सकती है
code assistant एक ज़रूरी shared tool है, इंसानों को replace करने वाला हथियार नहीं। जब competitors भी वही AI subscription खरीद सकते हैं, तब इससे लोगों को replace नहीं किया जा सकता
field experience साझा करूँ — पहले developer था, अब manager हूँ, लेकिन अभी भी code लिखता हूँ। LLM assistants मददगार भी हैं, लेकिन कभी-कभी परेशान भी करते हैं। जब वे अचानक अनचाहे code suggestions बरसाने लगते हैं, तो काम मेरी मंशा से अलग दिशा में चला जाता है, और review में समय भी लगता है। शायद यह settings की समस्या है, लेकिन मैं default को ऐसा करना चाहूँगा कि यह सिर्फ तब दिखे जब मैं command से बुलाऊँ। एक बात पक्की है: चाहे मैं LLM को पूरा code या functions लिखने दूँ, मैं हमेशा अपनी review process ज़रूर करता हूँ
Zed editor में ऐसा ‘हल्का सुझाव’ mode है (और देखें)। काश हर editor ऐसा mode देता
आजकल startup में कई तरह के काम करते हुए मुझे LLM से बना UI ज़्यादा पसंद नहीं आता। building blocks जैसी बुनियादी चीज़ों में यह उपयोगी है, लेकिन Claude को लंबे code blocks सौंप देने पर मनचाहे नतीजे तक पहुँचने के लिए बहुत बार दोबारा काम करना पड़ता है
https://freederia.com AI वैज्ञानिक साइट की तरह सह-अस्तित्व वाला संबंध बनाए रखेंगे।