Oxide में LLM का उपयोग कैसे करें

 (rfd.shared.oxide.computer)
4 पॉइंट द्वारा GN⁺ 2025-12-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Large Language Model (LLM) काम करने के तरीके को मूल रूप से बदल रहे हैं, और Oxide ने इन्हें संगठन के अंदर कैसे इस्तेमाल करना है, इसे स्पष्ट रूप से परिभाषित किया है
    • Oxide एक ऑन-प्रिमाइज़ डेटा सेंटर के लिए integrated hardware और software बनाने वाला on-demand computing infrastructure startup है
  • LLM उपयोग के लिए Oxide ने जवाबदेही, कठोरता, सहानुभूति, टीमवर्क और तात्कालिकता के संतुलन को मुख्य सिद्धांत के रूप में रखा है
  • दस्तावेज़ सारांश/समझ, कोड रिव्यू और डिबगिंग जैसे कामों में यह बहुत उपयोगी है, लेकिन लिखने या कोड लिखने में मानवीय निर्णय और जिम्मेदारी अनिवार्य है
  • LLM द्वारा बनाई गई सामग्री में हमेशा एक ऐसा ढांचा होना चाहिए जिसमें मानव समीक्षा और जवाबदेही बनी रहे
  • Oxide LLM के उपयोग को बढ़ावा देता है, लेकिन इसे उत्पाद, ग्राहक और सहकर्मियों के प्रति जिम्मेदारी के आधार पर करता है

LLM उपयोग के मूल्य मानदंड

  • Oxide LLM उपयोग का मूल्यांकन अपने संगठन के मुख्य मूल्यों के अनुसार करता है
    • Responsibility (जवाबदेही) : LLM केवल एक tool है; परिणाम की जिम्मेदारी पूरी तरह इंसान की होती है
    • Rigor (कठोरता) : सावधानी से इस्तेमाल करने पर सोच को परिष्कृत किया जा सकता है, लेकिन लापरवाही करने पर सोच की गुणवत्ता गिरती है
    • Empathy (सहानुभूति) : संदेश का रिसीवर और लेखक दोनों इंसान होते हैं, इसलिए मानव-केंद्रित संवाद बनाए रखना जरूरी है
    • Teamwork (टीमवर्क) : LLM का उपयोग टीम के बीच भरोसा कमजोर न करे, इसलिए ध्यान रखें; और उपयोग की जानकारी साझा करने से ऐसा न लगे कि कोई जिम्मेदारी से बच रहा है
    • Urgency (तात्कालिकता) : गति बढ़ाना संभव हो, फिर भी अन्य मूल्यों की बलि नहीं देनी चाहिए

LLM के विभिन्न उपयोग तरीके

LLMs as Readers

  • LLM दस्तावेज़ सारांश और प्रश्नोत्तर में बहुत अच्छे हैं और भारी मात्रा में सामग्री जल्दी समझने में मदद करते हैं
  • लेकिन डेटा प्राइवेसी सुनिश्चित होनी चाहिए, और अपलोड किए गए दस्तावेज़ों को मॉडल ट्रेनिंग के लिए इस्तेमाल न करने का सेटअप करना जरूरी है
  • दस्तावेज़ समझ के सपोर्ट टूल के रूप में उपयोगी हैं, लेकिन जहाँ सीधे पढ़ना जरूरी है, उसे replace नहीं करना चाहिए

LLMs as Editors

  • तैयार दस्तावेज़ की structure और शैली सुधारने में प्रभावी हैं, और अंतिम चरणों में इस्तेमाल करने पर उपयोगी होते हैं
  • हालांकि LLM में बहुत ज्यादा सकारात्मक प्रतिक्रिया देने की प्रवृत्ति हो सकती है, जिससे critical analysis कम हो सकता है
  • ड्राफ्ट चरण में इस्तेमाल करने पर लेखक की अपनी विशिष्ट आवाज़ खोने का जोखिम रहता है

LLMs as Writers

  • LLM से बने लेख अक्सर बहुत सामान्य या स्वचालित निर्माण के स्पष्ट निशान वाले होते हैं
  • ऑटोमेटिक रूप से बने लेखन से विचार की प्रामाणिकता और पाठक का भरोसा प्रभावित हो सकता है
  • पाठक मानता है कि लेखक सामग्री को समझता है, लेकिन LLM आउटपुट उस धारणा को तोड़ देता है
  • Oxide यह मानकर चलता है कि सभी सदस्य लिखने की क्षमता रखते हैं, इसलिए LLM को लिखने के मुख्य लेखक के रूप में नहीं इस्तेमाल करता
  • हालाँकि, आइडिया व्यवस्थित करने या सहायक टूल के रूप में सीमित रूप से उपयोग संभव है

LLMs as Code Reviewers

  • LLM कुछ तरह की code issues खोजने में उपयोगी हैं, लेकिन मानव रिव्यू का विकल्प नहीं हैं
  • प्रस्ताव गैर-तार्किक हो सकते हैं या संदर्भ छूट सकता है, इसलिए सिर्फ सहायक औज़ार के तौर पर उपयोग करें

LLMs as Debuggers

  • LLM का उपयोग डिबगिंग आइडिया जगाने वाले ‘rubber duck’ के रोल में किया जा सकता है
  • वास्तविक समस्या सुलझाने की क्षमता सीमित है, लेकिन यह नई सोच शुरू करने वाला ट्रिगर हो सकता है

LLMs as Programmers

  • LLM की code generation ability बहुत मजबूत है और यह प्रयोगात्मक/सहायक कोड लिखने के लिए उपयुक्त है
  • जैसे-जैसे कोड प्रोडक्ट कोड के करीब आता है, validation और जवाबदेही और अधिक महत्वपूर्ण हो जाती है
  • LLM द्वारा लिखे गए कोड की लेखक द्वारा सीधे self-review होनी चाहिए और peer review से पहले जरूर जाँचना चाहिए
  • कोड रिव्यू के दौरान पूरे हिस्से को दोबारा जेनरेट करके बदलने की कार्रवाई प्रतिबंधित है, क्योंकि दोबारा-review करना मुश्किल हो जाता है
  • कोड निर्माण के दौरान भी जवाबदेही, कठोरता, सहानुभूति, टीमवर्क को बनाए रखना चाहिए

संचालन और गाइडलाइंस

  • LLM उपयोग की टेक्निकल डिटेल्स और internal guideline GitHub की internal documentation में दर्ज हैं
  • Oxide LLM उपयोग की सिफारिश तो करता है, लेकिन जिम्मेदार उपयोग को अनिवार्य मानता है
    • उत्पाद गुणवत्ता, ग्राहक भरोसा और सहकर्मी सहयोग के लिए जवाबदेही को शीर्ष प्राथमिकता देता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-12-08
Hacker News राय

  • Bryan का लेख संतुलित और यथार्थवादी नज़रिया दिखाता है
    लगता है कि Oxide जूनियर इंजीनियरों को हायर नहीं करता, इसलिए RFD में उससे जुड़ी बातें नहीं आईं
    Bryan 30 साल से ज़्यादा समय से कठिन software और hardware पर काम कर चुके इंजीनियर हैं, और उनके पास वास्तव में कठिन program (OS) पूरा करने का अनुभव है
    वह LLM को जिस तरह इस्तेमाल करते हैं, वह 2025 के जूनियर इंजीनियर से काफ़ी अलग है
    आज के कई जूनियर शायद LLM की मदद के बिना coding करने के आदी ही नहीं रहे होंगे

    • पहले एक समय था जब कंपनी में data ingest model बनाने में ही कई महीने लग जाते थे
      काम इतना उबाऊ था कि दफ़्तर जाना भी भारी लगता था, लेकिन अब वही काम LLM से कुछ मिनटों में हो सकता है
      उस समय लगाया गया वक़्त अब सोचें तो लगभग पागलपन जैसा लगता है
    • web design की पहली class में शिक्षक ने पूरे semester Notepad से HTML, CSS, JS के ‘बुनियादी सिद्धांत’ सिखाए थे
      उसके बाद ही Dreamweaver से परिचय कराया, और productivity लगभग दस गुना बढ़ गई थी
    • LLM में ‘कारीगरी बनाम व्यावहारिकता’ का तनाव दिलचस्प है
      security research जैसे क्षेत्रों में, जहाँ परिणाम स्पष्ट होते हैं, LLM बेहतरीन हैं, लेकिन जहाँ सूक्ष्म निर्णय चाहिए वहाँ कमज़ोर पड़ते हैं
      इसलिए दोहराए जाने वाले और व्यवस्थित हिस्से LLM को देना, और निर्णय वाले हिस्से इंसानों के पास रखना आदर्श लगता है
    • 20 साल से ज़्यादा programming करने के बाद भी, LLM इस्तेमाल करने को लेकर भीतर एक अनकहा प्रतिरोध था
      लेकिन अब इसे ‘programming का नया तरीका’ मान लिया है, और यह समझ आने के बाद उल्टा खुद को कुछ जवान-सा महसूस हुआ
    • उस वाक्य में ‘LLM के निशान पहचानने वाले लोग’ लिखने के तुरंत बाद em-dash(—) आना काफ़ी मज़ेदार लगा
      आजकल em-dash इस्तेमाल करो तो लोग उसे AI से लिखा हुआ समझ लेते हैं, यह थोड़ा झुंझलाने वाला है

  • Oxide का RFD पढ़ते हुए ज़्यादातर बातों पर सिर हिलाया, लेकिन “LLM शुरू से अच्छा code लिख देता है” इस हिस्से से सहमत नहीं हूँ
    LLM ‘blank page syndrome’ दूर करने में अच्छे हैं, लेकिन जो output मिलता है वह production में deploy होने वाले code से काफ़ी दूर होता है
    शायद यह ‘प्रगति का भ्रम’ भी हो सकता है

    • writing व्यक्ति की अभिव्यक्ति है, लेकिन code समस्या सुलझाने का औज़ार है
      LLM dataset में बार-बार आने वाले ‘अच्छे समाधान’ सीखते हैं, इसलिए problem solving में मज़बूत हो सकते हैं
      दूसरी ओर, इंसानी अभिव्यक्ति का सार ही विविधता है, इसलिए औसत अभिव्यक्ति जल्दी नीरस लगने लगती है
      अंततः LLM अनसुलझी समस्याएँ हल करने की क्षमता को सीमित भी कर सकते हैं
      code quality कम होने की बड़ी वजह context window की सीमा लगती है
    • घिसी-पिटी writing बुरी है, लेकिन घिसा-पिटा code कई बार अच्छा होता है
    • “कोई दूसरा model इस्तेमाल करके देखो” वाली दलील अब LLM दुनिया का ‘No True Scotsman’ जैसी लगती है
      function-स्तर की generation ठीक है, लेकिन पूरा feature दे दो तो structure और interface बिगड़ जाते हैं
      writing की मिसाल दें तो जैसे किसी paragraph का पहला और आख़िरी वाक्य देकर बीच का हिस्सा भरने को कहना
    • यह वैसा ही है जैसे जिन क्षेत्रों की news हम अच्छी तरह जानते हैं, उनमें ग़लतियाँ तुरंत पकड़ लेते हैं, लेकिन अनजान क्षेत्रों की बातों पर आसानी से भरोसा कर लेते हैं
      programmer code quality का आकलन कर सकता है, लेकिन writing में हमेशा ऐसा नहीं होता
    • LLM की quality model के हिसाब से बदलती है
      कई लोगों की ख़राब राय इसलिए बनती है क्योंकि उन्होंने पुराने या सस्ते model इस्तेमाल किए होते हैं

  • “LLM, LLM द्वारा लिखे गए text को अच्छी तरह पहचान लेते हैं” इस दावे पर संदेह होता है
    जानना चाहूँगा कि क्या यह data से साबित है

    • Oxide के Bryan ने इस पर सीधे जवाब दिया
      उनका कहना है कि उनकी hiring process writing-केंद्रित है, इसलिए हाल में LLM से लिखे गए applications बहुत बढ़ गए हैं
      RFD 0003 और careers page में सावधानी की बात लिखी गई है, फिर भी यह जारी है
      podcast episode में भी ऐसे मामलों की चर्चा है
      LLM हर AI-generated text नहीं पकड़ पाते, लेकिन संदिग्ध मामलों में detection helper tool के रूप में काम के हैं
    • LLM-generated text पहचानने के लिए यह विचार सुझाया गया कि text के आधे हिस्से को LLM में देकर बाकी आधे की भविष्यवाणी कराई जाए और n-token probability की तुलना की जाए
      प्रयोग तो नहीं किया, लेकिन विचार दिलचस्प है
    • LLM ने कितना दख़ल दिया है—पूरा लिखा, summary बनाई, proofreading की—इस पर detection की कठिनाई बदलती है
      इसलिए मौजूदा तकनीक से पूरी तरह सही पहचान संभव नहीं लगती

  • LLM से बने code की ज़िम्मेदारी इंजीनियर की ही होती है
    जिस code को आपने खुद review नहीं किया, वह review के लिए भेजा ही नहीं जाना चाहिए
    मेरी प्रक्रिया कुछ ऐसी है:

    1. संबंधित code input → 2) लक्ष्य समझाना → 3) design review → 4) code generation → 5) test और fix → 6) पूरे code को ध्यान से पढ़कर manual edit
      आख़िरी चरण सबसे कठिन होता है, और भावनात्मक रूप से उसे छोड़ देने का मन करता है
      यह तरीका architecture-स्तर की सोच बनाए रखते हुए repetitive काम घटाता है
      लेकिन LLM nondeterministic हैं, इसलिए compiler जैसे पूर्वानुमेय tool नहीं हैं
    • व्यवहार में 6वाँ चरण ही कुल समय का ज़्यादातर हिस्सा ले लेता है
      अगर code ठीक से काम न करे तो और ज़्यादा fixes करने पड़ते हैं
      इसलिए पक्का नहीं कि LLM सच में समय बचाते हैं या नहीं
    • 4वें चरण से पहले test code generate करवाने, फिर fail से pass तक ले जाने वाला चरण जोड़ना अच्छा हो सकता है
    • manual edit की जगह अगर LLM से ही सारे बदलाव करवाए जाएँ, तो session के भीतर knowledge consistency बनाए रखना आसान हो सकता है
    • लेकिन इससे इंजीनियर का स्वाभिमान और ownership की भावना आहत होती है
      मशीन द्वारा बनाए गए code को सँवारने में भावनात्मक रूप से जुड़ना मुश्किल लगता है

  • यह अजीब लगा कि LLM-generated code में copyright उल्लंघन की संभावना का ज़िक्र नहीं था
    GitHub code ज्यों का त्यों कॉपी हो सकता है, और open source company के लिए यह बड़ा मुद्दा है

    • अगर LLM output copyright के दायरे में ही न आए, तो Copyleft license वाले code की कानूनी स्थिति और धुंधली हो जाती है
      copyright बनने के लिए पर्याप्त human contribution चाहिए, लेकिन उसकी सीमा स्पष्ट नहीं है
    • जानना चाहता हूँ कि क्या ऐसे मामलों पर कभी अदालत में सुनवाई हुई है
    • यह भी सवाल है कि क्या नए LLM अब भी ऐसी समस्या पैदा करते हैं, या इंसानों से ज़्यादा बार करते हैं

  • दस्तावेज़ अच्छी तरह बना है, लेकिन “LLM को reading aid की तरह इस्तेमाल करना ठीक है” यह हिस्सा विरोधाभासी लगता है
    अगर output पूरी तरह सही है तो वह मूल पाठ से अलग नहीं होगा, और अगर सही नहीं है तो गलत समझ का ख़तरा है
    अक्सर देखा है कि LLM दस्तावेज़ ठीक से पढ़ने के बजाय सिर्फ़ table of contents देखकर अनुमान लगाते हैं
    content और reader के बीच एक translation layer बनने का ख़तरा है

    • लगता है कि RFD का विषय ‘reading’ नहीं बल्कि ‘writing’ से जुड़ी सामाजिक अपेक्षाएँ थीं
    • अगर तीन technical books की तुलना करने को कहा गया और नतीजा ग़लत आया, तो यह tool usage failure है
      पूरा text सीधे context window में डालना चाहिए
      हालाँकि तीनों किताबें मिलाकर मात्रा शायद LLM की सीमा से बाहर हो सकती है

  • “LLM से बना लेखन सोच की प्रामाणिकता तक को नुकसान पहुँचाता है” इस बात से सहमति है
    इंसान द्वारा सीधे लिखा गया text मूल्यवान होता है, लेकिन LLM का लिखा मूल्य-क्षीण प्रतिरूप जैसा लगता है
    “बेहतर है prompt ही पढ़ लें” वाली बात प्रभावशाली लगी

    • इंसानी कला व्यक्ति के भीतर की दुनिया व्यक्त करती है, जबकि LLM सामूहिक औसत का output हैं
      रोचक और मौलिक विचार अक्सर औसत से हटकर जगहों पर मिलते हैं
      translation जैसी स्थिति में, जहाँ non-native speaker अपनी बात बेहतर ढंग से कहना चाहता है, वहाँ LLM का उपयोग समझ आता है, लेकिन
      प्राप्तकर्ता फिर भी सोच सकता है कि यह सचमुच उस व्यक्ति का विचार है या नहीं
    • Naur के “Programming as Theory Building” की याद आती है
      comment वह कोशिश है जिसमें code में न समा पाने वाला सैद्धांतिक संदर्भ व्यक्त किया जाता है
      LLM के पास ऐसी ‘theory’ नहीं हो सकती, इसलिए वह सचमुच मूल्यवान comment नहीं बना सकता
    • LLM की ख़ास ‘AI writing style’ खटकती है, लेकिन बहुत से लोग उसे पहचानते भी नहीं
      उदाहरण के लिए /r/SaaS की ज़्यादातर posts LLM से लिखी हुई लगीं,
      फिर भी वे emotional storytelling के ज़रिए पाठकों की प्रतिक्रिया अच्छी तरह खींच लेती हैं
      मैं भी docs या benchmark लिखने में LLM का उपयोग करता हूँ
      non-native speakers के लिए technical documentation लिखने में भी यह मददगार है, लेकिन quality में बहुत उतार-चढ़ाव है
      अंततः सूचना-प्रेषण वाली writing में LLM लगातार उपयोगी होते जा रहे हैं
    • “मैं prompt पढ़ना चाहूँगा” जैसी भावना news headline देखते समय भी आती है
      क्या लिखा गया, उससे ज़्यादा यह जानने की जिज्ञासा होती है कि क्यों लिखा गया
    • LLM औसत वाक्यों की भविष्यवाणी अच्छी तरह करते हैं, लेकिन रचनात्मक वाक्य लगभग नहीं कर पाते
      इसलिए यह सुकून देता है कि मेरे विचार बहुत मौलिक न सही, सांख्यिकीय रूप से तो दुर्लभ हैं

  • मुझे लगता है LLM से लिखा गया text पढ़ने लायक नहीं होता
    Oxide ने non-code output में LLM न इस्तेमाल करने का दृढ़ सिद्धांत बनाया, यह अच्छी बात है
    code review में भी वही बात लागू होनी चाहिए: generated code को author पहले खुद जाँचे
    यह संस्कृति वास्तव में टिकेगी या नहीं, यह देखना होगा, लेकिन दिशा समझदारी भरी है

  • यह धारणा काफ़ी मज़बूत है कि LLM चोरी किए गए data पर train किए गए हैं,
    इसलिए लगता है कि इस सार्वजनिक धारणा पर भी विचार होना चाहिए था
    चाहे यह ethical issue हो या brand risk, अभी यह स्पष्ट रूप से महत्वपूर्ण है

    • यह दस्तावेज़ आम जनता के लिए नहीं, बल्कि एक internal technical document जैसा लगता है
      इसका उद्देश्य ethical stance लेने से ज़्यादा technical guideline देना है
    • लेख में जिस ‘trust collapse’ की बात है, शायद वही इस समस्या को दूसरे शब्दों में छूती है
      LLM-generated text प्रामाणिकता खो देता है, और पाठक को लग सकता है कि विचार तक automated हो गए हैं
      अंततः यह आपसी भरोसे को नुकसान पहुँचा सकता है

  • “लेखन, पढ़ने से बड़ा बौद्धिक श्रम है” यह बात दिलचस्प लगी
    लेकिन code के मामले में उल्टा महसूस होता है

    • ख़राब writing बेकार होती है, लेकिन ख़राब code अगर किसी तरह चल जाए तो भी Jira ticket बंद किया जा सकता है
      इसलिए ख़राब code बहुत ज़्यादा है
      दूसरी ओर, अच्छा code सीखने लायक होता है और writing की तरह अंतर्दृष्टि माँगता है
    • Kernighan का नियम उद्धृत किया गया
      “Debugging, code लिखने से दोगुना कठिन है।
      इसलिए यदि आप code लिखते समय जितना हो सके उतना चतुर बनने की कोशिश करेंगे, तो उसे debug करना असंभव हो जाएगा।”
      laws-of-software.com लिंक