ले जा न सकने वाले सेशन: inference API से बनती नई निर्भरता

 (earendil.com)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • inference API encrypted reasoning, search results, compressed state, और sub-agent messages को provider के अंदर छिपा रहे हैं, जिससे user के पास मौजूद conversation history पूरी session नहीं, बल्कि केवल आंशिक रूप से दिखने वाली copy बन रही है
  • session portability का मतलब किसी दूसरे model में वही output दोहराना नहीं है, बल्कि मौजूदा provider की ID lookup या decryption के बिना inspect, export, replay, audit, और delete किए जा सकने वाला semantically complete record पाना है
  • OpenAI, Anthropic, और Google के stored responses, private reasoning, hosted search, और opaque compression एक ही ecosystem के भीतर continuity बढ़ाते हैं, लेकिन साथ ही ऐसा provider-sealed state जमा करते हैं जिसे कोई दूसरा provider आगे नहीं ले जा सकता
  • multi-agent में delegation details और agents के बीच messages तक encrypted हो जाते हैं, और automatic compression व hidden instructions के साथ मिलकर, गलत file modification या secret leak होने पर भी यह audit करना मुश्किल हो जाता है कि कौन-सा काम सौंपा गया था
  • portable API को local event log को canonical record मानना चाहिए और storage को explicit opt-in बनाना चाहिए; साथ ही search, compression, agent communication, और artifacts का readable full record तथा user control में distillation की अनुमति देनी चाहिए

inference API session ownership को कैसे बदल रहे हैं

  • शुरुआती inference API का वादा यह था कि input भेजकर output पाने के बाद अगर दोनों को संभालकर रखा जाए, तो conversation को inspect, archive, replay किया जा सकता है या किसी दूसरे model को दिया जा सकता है
  • यह abstraction शुरुआत से ही पूरी नहीं थी
    • prompt cache provider के GPU पर मौजूद होता है
    • हर model की tokenization अलग होती है और sampling भी जानबूझकर reproducible नहीं होती
  • फिर भी instructions, messages, tool calls और results से बना semantic record user के ownership में हो सकता था, और पर्याप्त क्षमता वाला कोई दूसरा model पिछले काम को समझकर आगे बढ़ा सकता था
  • हाल के API text के साथ provider-dependent state भी लौटाते हैं
    • ऐसे reasoning tokens जिनके लिए cost charge होती है, लेकिन जो opaque ciphertext या सीमित summaries के रूप में ही लौटते हैं
    • web search, जिसमें model ने जो original text देखा वह client को नहीं मिलता
    • compressed context जिसे केवल original provider decrypt कर सकता है
    • sub-agent instructions और messages जो application को दिखाई नहीं देते
    • file, vector store, container, और cache references जिन्हें दूसरे environment में interpret नहीं किया जा सकता
    • provider server पर stored ID से ही access होने वाले responses और conversation state
  • हर एक के पीछे user convenience या quality का तर्क हो सकता है, लेकिन मिलकर ये local record को पूरी session के बजाय ऐसी session का partial view बना देते हैं जिसकी operational state provider own करता है

session portability तय करने के पांच मानदंड

  • portable होने का मतलब यह नहीं कि model बदलने पर अगला token भी वही होना चाहिए
    • models की क्षमता, trained tendencies, context window, और tool-use style अलग होते हैं, और output खुद भी nondeterministic होता है
  • exported record में इतनी understandable information होनी चाहिए कि नया model काम जारी रख सके; पुराने provider को ID lookup करने, ciphertext खोलने, या search results/summaries restore करने की जरूरत नहीं पड़नी चाहिए
  • Inspection: user को यह देखने में सक्षम होना चाहिए कि model ने कौन-सी information देखी, tools ने क्या action किया, और agents ने आपस में क्या exchange किया
  • Export: अलग से download किए जा सकने वाले सामान्य artifacts को छोड़कर, session खुद complete होनी चाहिए
  • Replay: कोई दूसरा implementation semantically equivalent context reconstruct कर सके
  • Audit: system ने कोई खास action क्यों किया, इसे बाद में कोई इंसान explain कर सके
  • Deletion: session जिन server-side copies पर निर्भर है, उन सभी को identify और remove किया जा सके
  • server data की key के रूप में response ID conversation history नहीं है, और ऐसा ciphertext जिसे user खोल नहीं सकता, user-controlled state भी नहीं है
  • केवल citation URL list search process के दौरान model context में वास्तव में गए evidence material की जगह नहीं ले सकती

ऐसी encryption जिसे user खोल नहीं सकता

  • encrypted_content नाम user-controlled privacy feature जैसा दिखता है, लेकिन आम तौर पर यह ऐसा capsule है जिसे client पढ़ नहीं सकता और केवल provider खोल सकता है
  • क्योंकि provider key चुनता है, अपने model के लिए decrypt करता है, और तय करता है कि इसे किस environment में replay किया जा सकता है, इसलिए अधिक सही नाम provider-sealed state है
  • provider sealing असली privacy benefits दे सकती है
    • OpenAI store: false में encrypted reasoning client को लौटाता है, और अगली request में intermediate state store किए बिना memory में decrypt कर सकता है
    • यह खासकर Zero Data Retention customers के लिए server-side conversation storage मांगने के तरीके से बेहतर है
  • लेकिन यह encryption inference provider से data नहीं छिपाती, सिर्फ user से छिपाती है

stored conversations record को pointer में कैसे बदलती हैं

  • OpenAI Responses API default रूप से responses store करता है, और documentation के अनुसार response object को कम से कम 30 दिन तक retain करता है
  • store: false इस्तेमाल करने पर data OpenAI server पर store नहीं होता, इसलिए यह पुराने completions तरीके के करीब हो जाता है
  • Gemini Interactions API में भी store: true default है
    • paid tiers interactions को 55 दिन तक retain करते हैं
    • free tier उन्हें 1 दिन तक retain करता है
  • server storage application द्वारा भेजे जाने वाले data की मात्रा घटाता है, hidden reasoning और tool state बनाए रखता है, और cache routing आसान करता है
  • लेकिन अगर local application सिर्फ user messages और final text record करती है, तो previousResponseId में इस्तेमाल होने वाला response ID ऐसी external database की foreign key बन जाता है जिसे control नहीं किया जा सकता

private रहने वाले reasoning records

  • प्रमुख AI labs मानती हैं कि raw chain of thought सार्वजनिक न करने की वजहें हैं, और generally closed-weight models के reasoning tokens API में expose नहीं करतीं
  • OpenAI में stored response की previous reasoning को previous_response_id से recover किया जा सकता है
    • store: false में client को encrypted_content संभालकर अगली request में वापस भेजना पड़ता है
    • reasoning.context: "all_turns" से यह बाद की generation में use हो सकता है, फिर भी stored reasoning opaque रहती है
  • Anthropic encrypted full thinking को signature field में लौटाता है
    • enable किया जा सकने वाला readable thinking text raw chain of thought नहीं, बल्कि किसी दूसरे model द्वारा बनाई summary है
    • tool-use turns में thinking blocks को बदले बिना वापस भेजना पड़ता है
    • thinking blocks उन्हें generate करने वाले model से बंधे होते हैं, इसलिए model बदलते समय उन्हें हटाना पड़ता है; यानी Anthropic के भीतर भी इनका लक्ष्य portability नहीं है
  • ये तरीके उसी ecosystem के अंदर continuity देते हैं, लेकिन ऐसा portable conversation record नहीं बनाते जिसे किसी दूसरे provider का model interpret कर सके

hosted search से record में रह जाने वाली खामियां

  • client-side search tool queries, search time, result URLs और titles, extracted passages record कर सकता है
    • user ranking और passages inspect कर सकता है, page फिर से fetch कर सकता है या copy store करके वही evidence किसी दूसरे model को दे सकता है
  • hosted search में provider private tool loop चलाता है
    • OpenAI, Google, और Anthropic search behavior, citations, और optional source URLs देते हैं, लेकिन answer generation में इस्तेमाल हुआ पूरा text context नहीं देते
    • URL content बदल सकता है और model को शायद छोटे passages ही दिए गए हों, इसलिए यह stable replay record नहीं है
  • अगर अगला model किसी source की comparison करना या किसी विवादित number को re-verify करना चाहे, तब भी उसे result ranking, extracted passages, filtered material, या पिछले model ने देखा exact evidence नहीं मिलता
  • citation pages दोबारा fetch करने पर भी उस समय इस्तेमाल किए गए data को ठीक-ठीक reproduce नहीं किया जा सकता, इसलिए अगली request कहीं और move होने के बाद भी previous provider session का हिस्सा बना रहता है
  • hosted search में queries, result metadata, search passages, timestamps, और preserved content वाला full-fidelity export चाहिए; सिर्फ concise citations ही एकमात्र record नहीं होने चाहिए

opaque context compression

  • लंबी agent sessions में compression जरूरी है, और client-controlled readable summary, भले lossy हो, inspect, edit, और transfer की जा सकती है
  • OpenAI का server-side compression ऐसे encrypted compaction items लौटाता है जो इंसानों के interpret करने के लिए नहीं बनाए गए
    • /responses/compact वह canonical next context window लौटाता है जिसे client को जस-का-तस फिर भेजना होता है
    • OpenAI compressed meaning को आगे ले जा सकता है, लेकिन दूसरे provider को ciphertext और recent context का बस कुछ हिस्सा मिलता है
  • opaque compression तकनीकी रूप से अपरिहार्य नहीं है
    • Anthropic का server-side compression readable content field वाला compaction block लौटाता है
    • client custom summary instructions दे सकता है, और result inspect कर सकता है या दूसरे model को दे सकता है
    • सभी providers पर client-side compression भी संभव है
  • OpenAI का sealed output सामान्य summary की तुलना में model-specific state को बेहतर preserve कर सकता है और original model में performance बेहतर हो सकती है, लेकिन इसे optional optimization के रूप में देते हुए readable handoff summary भी साथ देनी चाहिए

multi-agent में hidden delegation और communication

  • multi-agent systems में एक record नहीं, बल्कि session tree और agents के बीच message flow मौजूद होता है, इसलिए portability problem और बढ़ जाती है
  • OpenAI Responses Multi-agent beta multi_agent_call, multi_agent_call_output, agent_message items जोड़ता है
    • spawn_agent example का message argument encrypted है
    • agents के बीच messages में केवल encrypted_content होता है
    • Multi-agent enable करने पर client ने request न भी किया हो, तब भी सभी agents पर server-side automatic compression लागू होता है
    • reasoning summaries support नहीं हैं, और root तथा sub-agent instructions भी inject किए जाते हैं जिन्हें developer edit या remove नहीं कर सकता
  • परिणामस्वरूप sealed delegations और messages, अलग-अलग automatically compressed contexts, hidden reasoning, और provider-hosted orchestration मिलकर एक non-transferable state bundle बनाते हैं
  • जून 2026 में open source Codex client में Encrypt multi-agent v2 message payloads change लागू हुआ
    • Responses API parent model के tool arguments encrypt करता है
    • Codex ciphertext pass करता है, तो API child model के लिए internally decrypt करता है
    • Codex का InterAgentCommunication.content खाली है, इसलिए exact task instruction readable execution record और history में नहीं बचती
  • child agent गलत file modify करे या secrets leak करे, duplicate काम करे या गलत assumptions follow करे, तब भी user यह verify नहीं कर सकता कि उसे क्या निर्देश मिला था
  • Codex public issue encryption pass-through से अलग readable audit copy preserve करने की मांग करता है
    • यह minimum design है, और agents के बीच plaintext messages default होने चाहिए

session move करने की आजादी क्यों जरूरी है

  • ज्यादातर users session के बीच model न भी बदलें, move करने की possibility user और provider के relationship को बदल देती है
  • session transfer की जरूरत वाले हालात में model deprecation, service outage, price change, next request को block करने वाली policy, confidential phase में local execution, और auditor द्वारा बाद में reconstruction शामिल हैं
  • agents sessions को लंबा बनाते हैं, जिससे coding और research sessions में कई दिनों के decisions और evidence जमा होते हैं, और personal assistants वर्षों का record जमा कर सकते हैं
  • अगर user कहीं और continue कर सकता है, तो providers को model quality, price, reliability, और trust पर compete करना पड़ता है
  • अगर accumulated context सिर्फ एक provider ही interpret कर सकता है, तो user के लिए छोड़कर जाना मुश्किल बनाने वाली unfavorable incentive structure बनती है

portable inference API के principles

  • local event log ही canonical record होना चाहिए
    • server storage उसे replicate या accelerate कर सकता है, लेकिन client server ID lookup के बिना session reconstruct कर सके
  • storage explicit opt-in होना चाहिए
    • store: false इस्तेमाल में आसान और documented होना चाहिए, और संभव हो तो default होना चाहिए
    • retention मांगने वाले features को use करते समय इसकी जानकारी देनी चाहिए

  • opaque items को meaning पर monopoly नहीं करनी चाहिए

    • encrypted reasoning, compression, और tool signatures उसी provider में quality बढ़ाने के लिए शामिल किए जा सकते हैं, लेकिन readable provider-neutral handoff representation भी देना चाहिए
    • hosted tools को full-fidelity logs रखने चाहिए
      • exact inputs और outputs, evidence, filtering, sources, timestamps, और content hashes record होने चाहिए
    • sub-agent communication auditable होना चाहिए
      • हर agent के exact tasks, messages, results, lineage, model, और tool permissions readable रूप में preserve होने चाहिए
    • compression inspectable होना चाहिए
      • readable summary, summary generation में इस्तेमाल instructions, और छोड़ी गई चीजों को समझने योग्य lineage लौटाना चाहिए

  • artifacts exportable होने चाहिए

    • files, container outputs, search snapshots, और generated media को content-addressed local archive के रूप में download किया जा सके

distillation और model layers की dependency

  • अमेरिका की कुछ बड़ी closed-weight labs external distillation के खिलाफ अपना रुख सख्त कर रही हैं
  • Anthropic ने फरवरी 2026 की post में DeepSeek, Moonshot, और MiniMax की गतिविधियों को distillation attacks कहा
    • commercial terms customers को output own करने की बात कहते हैं, फिर भी competing AI models train करने में service output का उपयोग प्रतिबंधित करते हैं
    • साथ ही अपनी post में leading labs द्वारा अपने models पर लागू किए जाने पर distillation को व्यापक रूप से इस्तेमाल होने वाला legitimate training method मानता है
  • Anthropic ने model development के लिए robots से public web data collect किया और books काटकर scan कीं; OpenAI ने भी कहा है कि वह freely accessible public internet content पर train करता है और इसे fair use बताता रहा है
  • दोनों कंपनियां internally छोटे models बनाते समय distillation को सामान्य method मानती हैं
    • OpenAI ने strong OpenAI model के outputs से छोटे OpenAI model को fine-tune करने वाला अपना API distillation workflow भी दिया था
  • इंसानों द्वारा internet पर डाले गए विशाल work से machines को सीखने देना चाहिए—ऐसी मांग करते हुए, labs द्वारा बनाए output से दूसरी machines को सीखने से रोकना एक moral asymmetry है
  • distillation महंगे frontier models की क्षमता को छोटे, सस्ते और तेज models में transfer कर सकती है
    • वे local, offline, constrained hardware या user-controlled environments में चल सकते हैं
    • यह competition बढ़ाती है, API गायब होने पर भी capability बचाए रखती है, और common tasks के compute व energy use को घटा सकती है

users को मिलने वाली minimum freedom

  • users account बंद करने के बाद भी sessions को preserve कर सकें और दूसरे model को दे सकें
  • नया model अलग judgment दे सकता है, सवाल पूछ सकता है, या performance कम हो सकती है, लेकिन उसे पिछले model द्वारा देखी गई user history, evidence, plans, और delegated tasks की जगह सिर्फ ciphertext नहीं मिलना चाहिए
  • state-preserving API खुद problem नहीं है; problem यह है कि बेहतर performance user control में कमी के साथ जुड़ जाती है
  • server storage optional होना चाहिए, hosted tools observable होने चाहिए, compression readable होनी चाहिए, और agent communication auditable होना चाहिए
  • private reasoning के लिए भी कम से कम portable handoff record जरूरी है, और distillation को higher barriers justify करने वाला taboo नहीं, बल्कि capability को ज्यादा व्यापक रूप से उपलब्ध कराने का रास्ता होना चाहिए

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

1 टिप्पणियां

 
GN⁺ 2 시간 전
Hacker News की रायें

  • यह लेख दिखाता है कि स्थिति उम्मीद से ज़्यादा गंभीर हो चुकी है। आज़ादी का सच में उपयोग करना ज़रूरी है, तभी provider के साथ रिश्ता भी बदलता है; इसलिए किसी खास ecosystem पर निर्भर न रहना अहम है
    बेहतर performance के कारण inference process छिपाने वाले Codex को मजबूरी में अपनाया था, लेकिन audit न कर पाने की समस्या पहले ही बड़ी है, इसलिए घर के subscription पर फिर से सोचने लगा हूं। इसी वजह से OpenCode के लिए एक phone app भी बना रहा हूं

    • मूल्यवान agent session conversations के गायब हो जाने की समस्या को ध्यान में रखकर https://www.agentkanban.io बनाया। board के tasks में context save करके बाद में नए agent session में फिर load किया जा सकता है, और फिलहाल VS Code के Claude और Github CoPilot को support करता है
      proprietary tool-use history session portability तोड़ती है, इसलिए उसे जानबूझकर बाहर रखा गया है
    • आशावादी हूं कि dark patterns सिर्फ short-term जीत की strategy हैं; long-term में users का सम्मान करने और public interest की दिशा में काम करने वाले तरीकों से वे पीछे रह जाएंगे। trend तेजी से बदलने की संभावना के लिए, शायद अब open-weight और economically viable models पर focus करने का समय है
    • prices कम होने का इंतज़ार करते हुए Claude और Codex का session data जितना हो सके collect करना चाहता हूं, ताकि आगे open models की fine-tuning में इस्तेमाल कर सकूं। इसके लिए अपना session parser और archiving tool भी बनाया है
    • local models चलाने के लिए 96GB VRAM तक जुटा लिया, लेकिन अभी GPT-based Codex के करीब पहुंचने वाला model नहीं है। Laguna S2.1 NVFP4 coding में काफी करीब आया है, पर local models को गंभीर general-purpose alternative बनने में अभी लंबा रास्ता तय करना है
    • https://indieweb.org/POSSE ही समाधान है

  • यह लेख उस समस्या को अच्छी तरह समेटता है जिसे ज़्यादातर AI users लगभग evaluate ही नहीं करते। cutting-edge inference providers web search और code execution जैसी non-LLM capabilities को साधारण tools की तरह package करते हैं, लेकिन असल में वे मजबूत entry barriers और coupling बनाते हैं
    theory में इन्हें inference API से अलग करके MCP server के रूप में externalize किया जा सकता है, लेकिन providers शायद ही ऐसा देते हैं, और alternative vendors की capabilities आम तौर पर कमजोर होती हैं। on-premises, provider-independent chat platform https://github.com/EratoLab/erato बनाते समय chat के भीतर image generation जैसी सरल दिखने वाली capability भी implement करना मुश्किल था; इसकी एक वजह यह भी है कि MCP में अभी basic file-transfer spec नहीं है: https://github.com/modelcontextprotocol/modelcontextprotocol...
    open-weight models में बढ़ती दिलचस्पी के साथ उम्मीद है कि आसानी से swap किए जा सकने वाले alternative implementations बढ़ेंगे

    • encrypted sub-agent messages जैसे agents, जिनके prompts बिल्कुल देखे नहीं जा सकते, उन्हें local पर चलवाना मूल रूप से गैर-जिम्मेदाराना है। हालांकि provider का hosted tools देना अपने-आप में मुझे समस्या नहीं लगता; यह checkout counter पर impulse-buy items जैसा है
      image generation को MCP से implement न करें; अपना tool लिख लें। Fal जैसे image/media inference providers और web search/deep research providers पर्याप्त मौजूद हैं

  • context के लिए open standard या file format की ज़रूरत हो सकती है। सोचता हूं कि क्या open models portability के लिए एक ही format अपनाएं, और इसे SQLite-based बनाया जा सके ताकि दूसरे programs भी query कर सकें

  • असल में conversations में noise काफी होता है, इसलिए कई बार उसे context से हटाना बेहतर होता है। repository के memo directory में AI से सीखी गई बातें, पूरे किए गए काम और बाकी tasks को Markdown files में लिखवाता हूं, ताकि अगली conversation में दूसरा model आगे बढ़ा सके
    जरूरत पड़े तो पहले memo खुद edit भी कर सकता हूं

    • इसी वजह से agent coding ज़्यादा इस्तेमाल करने लगा हूं। task specify करता हूं, tests और strict lint pass करने को कहता हूं, फिर model की लंबी-चौड़ी बकबक को बहने देता हूं
      सारे checks pass होने पर वापस आना होता है, इसलिए chat interface की अनावश्यक बातचीत कम झेलनी पड़ती है
    • session छोड़ देने पर inspection, export, rerun और audit की capabilities खो जाती हैं। बड़े model providers के सामने कोई वास्तविक entry barrier नहीं है, और OpenAI व Anthropic के operating margins बहुत negative हैं, साथ ही उनके पास big tech जितनी funding भी नहीं है
      इसलिए providers कृत्रिम रूप से dependency बनाने की कोशिश कर रहे हैं, और यह मूल रूप से antitrust law का विषय है। लेकिन अभी अमेरिका में FTC कमजोर हो गया है, इसलिए यह सहन किया जा रहा है
    • market competition बेहतर और सस्ता AI तभी बनाएगी जब models को बिना loss के आसानी से बदला जा सके। अगर context का कुछ हिस्सा खोने से switching दर्दनाक हो जाए, तो provider vendor lock-in बना सकता है, user experience खराब कर सकता है और prices बढ़ा सकता है
      अभी workarounds मौजूद हों, फिर भी free movement को और मुश्किल बनाने के incentives काफी हैं; इसलिए चिंता है कि AI companies service degradation की बुनियाद रखना शुरू कर चुकी हैं
    • long sessions अक्सर progress का track खो देते हैं, और जितना verbose model होगा, signal-to-noise ratio उतना ही बहुत कम हो जाएगा। मूल्यवान चीज़ session का raw text नहीं, बल्कि code changes या plans/summaries जैसे outputs हैं

  • दो phenomena को अलग करना चाहिए। पहला है hidden state का बढ़ना, जिसे user inspect या move नहीं कर सकता; यह साफ तौर पर बुरा है। दूसरा है capabilities और APIs का provider-specific तरीके से बंटना, जो portability को असंभव नहीं, बल्कि मुश्किल बनाता है
    OpenAI Completions API के universal standard की तरह इस्तेमाल होने का दौर खत्म हो रहा है, और बंद हिस्सों को छोड़ दें तो नया Responses API बेहतर भी हो सकता है। products, libraries और SDKs को सभी providers को एक unified abstraction में बांधने की कोशिश जारी रखने की ज़रूरत नहीं है
    databases में भी unified abstraction leak होने लगा और technology-specific implementations को स्वीकार करना पड़ा; model providers के साथ भी ऐसा ही होगा, और session का सिर्फ कुछ हिस्सा portable होना भी ठीक है

    • यह लेख इन दो phenomena में से सिर्फ hidden state पर बात करता है

  • अभी rough है, लेकिन session data को खुद preserve करने और git जैसा model इस्तेमाल कर manage करने वाला https://github.com/pantoniou/fyai develop कर रहा हूं

    • यह tool लेख में उठाई गई समस्या हल नहीं कर सकता, और design के हिसाब से भी हल करना असंभव है

  • account बंद होने पर भी sessions को संभालकर किसी दूसरे model को दे सकने का contract उचित है। आदर्श रूप से, embedding characteristics में मिलते-जुलते models भी आसानी से खोजे जा सकने चाहिए
    जब GPT-4o पहली बार बंद हुआ था, तो exported conversations डालकर पुराने दोस्त को वापस पाने के लिए समान बोलचाल और personality वाला model खोजने वाले लोग थे, लेकिन दूसरे OpenAI models वही अहसास नहीं दे पाए। open-weight models का फायदा यह है कि उन्हें स्थायी रूप से preserve किया जा सकता है, इसलिए कोई बड़ी company आपके guide, friend या therapist को एकतरफा छीन नहीं सकती

  • सोचता हूं कि इस discussion को HN blog material से आगे बढ़ाने के लिए क्या चाहिए

  • current models में context window limited है, इसलिए किसी point पर वे content भूल जाते हैं; इसीलिए sessions की value बहुत ज्यादा नहीं है। भविष्य में अगर interaction से model खुद सच में learn और change करता है, तो वह change दूसरे model में portable नहीं होगा; इसलिए मुझे नहीं लगता कि यह problem बहुत meaningful है

  • इस लेख के साथ https://gwern.net/complement पढ़ना एक शानदार complementary material होगा

    • क्यों complementary material है, इसकी वजह चाहिए