Codex में Goals का उपयोग कैसे करें

 (developers.openai.com)
1 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Goals एक persistent objective फीचर है जो Codex thread को किसी परिभाषित नतीजे की ओर कई turns तक काम जारी रखने देता है
  • यह profiling, patching, benchmarking, flaky test reproduction, evidence-backed audit जैसे उन कामों के लिए उपयुक्त है जिन्हें एक single prompt से संभालना कठिन होता है
  • अगर आप outcome, verification surface, और constraints परिभाषित करें, तो Codex evidence के आधार पर खुद तय कर सकता है कि काम पूरा हुआ या नहीं
  • /goal, /goal pause, /goal resume, /goal clear कमांड्स से lifecycle control किया जा सकता है; यह Codex 0.128.0 से समर्थित है
  • यह thread scope तक सीमित completion contract संरचना है, और इसकी मुख्य बात unlimited autonomous execution नहीं बल्कि user control के तहत persistence है

Goals की परिभाषा और इन्हें लाने की पृष्ठभूमि

  • Goals, Codex को completion condition देने वाला फीचर है, जो यह परिभाषित करता है कि क्या सच होना चाहिए, सफलता को कैसे जांचना है, और कौन-सी constraints बनाए रखनी हैं
  • Codex पहले से repository inspection, bug fixing, test addition, failure explanation, और focused change implementation जैसे स्पष्ट दायरे वाले coding tasks में अच्छा काम करता है
  • Goals उन कामों के लिए उपयुक्त हैं जिनमें अगला कदम इस बात पर निर्भर करता है कि Codex ने बीच में क्या सीखा
    • जैसे profiling, patching, benchmarking, flaky test reproduction, और research questions को evidence-backed audit में बदलने वाले काम
  • ऐसे कामों को बड़े prompt की नहीं, बल्कि persistent objective की ज़रूरत होती है
  • Goal active होने पर Codex हर intermediate result के बाद goal को दोबारा कहे बिना उसे बनाए रखता है, completion का आकलन करता है, और अगला action चुनता है
  • Goal बिना सीमा वाली background autonomy नहीं, बल्कि scoped और user-controlled completion contract है

Quickstart: Goals का उपयोग

  • उन tasks में Goal का उपयोग करें जहाँ destination स्पष्ट हो लेकिन वहाँ तक पहुँचने का रास्ता अनिश्चित हो
    • अच्छे candidates: performance optimization, flaky test investigation, dependency migration, reproduction की ज़रूरत वाले bug tracking, multi-step refactoring, benchmark-based tuning, और final artifact वाले research tasks
    • one-off edits के लिए सामान्य prompt बेहतर है

  • Installation और version check

    • Goals Codex 0.128.0 से उपलब्ध हैं
    • npm: npm install -g @openai/codex@latest के बाद codex --version
    • Homebrew: brew update && brew upgrade --cask codex के बाद codex --version

  • Goal setup और lifecycle commands

    • /goal <result> फ़ॉर्मेट में सेट करें, उदाहरण: /goal Reduce p95 latency below 120 ms without regressing correctness tests
    • /goal: मौजूदा Goal देखें
    • /goal pause: active Goal को pause करें
    • /goal resume: paused Goal को resume करें
    • /goal clear: वर्तमान Goal हटाएँ

  • Stopping condition

    • सफलता, pause, removal, interruption, budget limit तक पहुँचना, या ऐसा blocker आना जिसमें user input चाहिए हो
  • Goal उस स्थिति में इरादे को स्पष्ट रूप से व्यक्त करता है जहाँ आपको हर turn पर बार-बार “आगे बढ़ो”, “अगला possible fix आज़माओ”, “benchmark फिर चलाओ”, “अब test check करो” जैसे निर्देश देने पड़ते हैं

Goals बनाम prompts

  • सामान्य prompt: “यह अगला काम करो”
  • Goal: “यह result सच होने तक काम जारी रखो”

  • व्यवहार में अंतर

    • सामान्य request में Codex तुरंत निर्देश पूरा करके result report करता है और रुकता है
    • Goal में thread से durable target जुड़ जाता है, इसलिए turn खत्म होने के बाद भी वर्तमान evidence की जांच करके यह तय किया जाता है कि goal पूरा हुआ या नहीं
    • अगर goal पूरा नहीं हुआ, goal active है, और budget के भीतर है, तो Codex ताज़ा स्थिति से काम जारी रख सकता है

  • उदाहरण: /goal Reduce p95 checkout latency below 120 ms on the checkout benchmark while keeping the correctness suite green

    • यह measurable outcome, verification method, और constraints देता है
    • Codex benchmark run → hot path inspection → targeted changes → benchmark rerun → correctness suite run को दोहराता है, और result पर्याप्त न होने पर जारी रखता है

  • Mental model

    • prompt: ask → work → result → wait
    • Goal: work → check → continue or complete
  • Goal finish line देता है, लेकिन काम को अभी भी evidence के against audited होना चाहिए

Goal कैसे लिखें

  • अच्छा Goal बड़ा prompt नहीं, बल्कि Codex कैसे काम करे, सफलता क्या मानी जाए, और सफलता तक न पहुँचने पर क्या करे—इसका संक्षिप्त contract होता है

  • एक मजबूत Goal के 6 तत्व

    • Outcome: task पूरा होने पर क्या सच होना चाहिए
    • Verification surface: इसे सिद्ध करने वाले tests, benchmarks, reports, artifacts, command output, या source material
    • Constraints: वे चीज़ें जिनमें Codex के काम के दौरान regression नहीं होना चाहिए
    • Boundaries: कौन-सी files, tools, data, repositories, resources इस्तेमाल किए जा सकते हैं
    • Iteration policy: हर प्रयास के बाद अगला कदम कैसे चुना जाएगा
    • Blocked stop condition: कब report करके रुकना है, जब मौजूदा सीमाओं में कोई defendable path न बचे

  • Writing pattern

    • /goal <desired end state> verified by <specific evidence> while preserving <constraints>. Use <allowed inputs/tools/boundaries>. Between iterations, <how to choose the next best action>. If blocked or no valid paths remain, <what to report and what input is needed to make progress>.

  • कमजोर बनाम मजबूत उदाहरण

    • कमजोर: /goal Reduce p95 checkout latency below 120 ms without regressing correctness tests
    • मजबूत: verification method (checkout benchmark), usage scope (checkout service, benchmark fixtures, related tests), iteration policy (changes, benchmark results, next experiments का रिकॉर्ड), और blocker report conditions तक स्पष्ट

  • Research / investigation Goals

    • जहाँ exact proof संभव न हो, वहाँ काम शुरू करने से पहले evidence standard परिभाषित करें
    • उदाहरण: /goal Produce the strongest evidence-backed reproduction of the paper using the available materials and local resources. Attempt the headline results where feasible, verify outputs where possible, and end with a report that separates confirmed findings, approximate reconstructions, blocked claims, and remaining uncertainty.

  • Goal writing Codex को सौंपना

    • सामान्य भाषा में task समझाएँ → Codex से draft Goal लिखवाएँ → success conditions, verification methods, constraints, और blocker stop condition को refine करके activate करें; यह 2-step workflow सुझाया गया है

Goal active होने पर क्या बदलता है

  • Goal दिखाई देता रहता है

    • test fail होने पर भी thread मूल goal को बनाए रखता है
    • benchmark बेहतर हो जाए लेकिन threshold तक न पहुँचे, तो Codex जारी रखता है
    • research path data की कमी से टकराए, तब भी research standard खोए बिना evidence plan को adjust करता है

  • Idle thread पर continuation संभव

    • अगर कोई दूसरा turn active हो, user input queue में हो, या दूसरे thread का काम pending हो, तो continuation नहीं होता
    • continuation केवल तब होता है जब thread idle हो, Goal active हो, और budget के भीतर हो

  • Completion evidence-based होना चाहिए

    • सिर्फ model का यह मान लेना कि “शायद काम पूरा हो गया” पर्याप्त नहीं है
    • संबंधित files, tests, logs, benchmark output, generated artifacts, और अन्य concrete evidence के against goal की जांच के बाद ही completion माना जाता है
  • Design का मुख्य बिंदु: Codex चलता रह सकता है, लेकिन completion evidence तय करता है

Codex में Goals की design structure

  • Goals को persisted thread state के रूप में लागू किया गया है; यह global memory या project-level instruction नहीं है
    • Goal उसी thread का हिस्सा होता है जहाँ संबंधित context मौजूद हो, जैसे inspected files, run commands, generated diff, seen logs, और reasoning record

  • Architecture layers

    • persistent, thread-scoped state के रूप में goal, lifecycle, budget, और progress accounting का रिकॉर्ड
    • Goal states: active, paused, complete, budget-limited
    • state के आधार पर Codex तय करता है कि जारी रखना है, user का इंतज़ार करना है, या नए काम के बजाय progress summary देनी है

  • Continuation event-based है

    • यह simple loop नहीं है और केवल safety boundaries पर check होता है: turn के बाद, pending work न हो, user input queue न हो, और thread idle हो
    • dispatcher का व्यवहार conservative है: planning-only work continuation trigger नहीं करता, interruption पर goal pause हो जाता है, thread resume होने पर उपयुक्त होने पर goal restore होता है, और अगर continuation turn tool calls नहीं करता तो अगला automatic continuation दबा दिया जाता है ताकि spin न हो

  • Prompting layer

    • continuation prompt, active goal के आसपास Codex को align करता है, लेकिन completion से पहले audit की माँग बनाए रखता है
    • goal की तुलना concrete evidence से की जाती है, जैसे changed files, run commands, passed tests, benchmark output, generated artifacts, और research evidence

  • Budget handling

    • budget पूरा होने पर वास्तविक काम रुक जाता है, progress और blockers का summary दिया जाता है, और अगला उपयोगी step पहचाना जाता है
    • budget limit तक पहुँचना goal completion के बराबर नहीं है

  • Tool contract

    • model Goal शुरू कर सकता है, लेकिन existing Goal को complete तभी mark कर सकता है जब evidence completion को support करे
    • pause, resume, removal, और budget-limit transitions पर user या system control बना रहता है

कमजोर Goal को मजबूत Goal में बदलना

  • Performance tuning उदाहरण

    • कमजोर: /goal Improve performance
    • मजबूत: /goal Reduce p95 latency below 120 ms on the checkout benchmark while keeping the correctness test suite green
    • मजबूत version outcome, verification method, और constraints देता है, इसलिए यह समझ सकता है कि कब रुकना नहीं चाहिए
      • p95 180ms से 135ms हो जाए, तब भी Goal पूरा नहीं
      • latency 120ms से कम हो लेकिन correctness tests fail हों, तब भी पूरा नहीं
      • benchmark चल ही न पाए, तो success declare करने के बजाय blocker सामने लाना होगा

  • Goal का सही scope

    • इतना narrow होना चाहिए कि audit किया जा सके, और इतना broad कि अगला action चुना जा सके
    • “Fix the failing checkout test” बहुत narrow हो सकता है अगर असली समस्या upstream dependency में हो
    • “Improve the whole system” बहुत broad है क्योंकि इसका audit surface नहीं है
    • “Make the checkout test suite pass on the current branch without changing public API behavior” उपयुक्त है

  • Generated artifacts पर वही सिद्धांत लागू

    • कमजोर: /goal Write docs for this feature
    • मजबूत: /goal Produce a docs page for Goals that explains the lifecycle, command surface, and two examples. Verify that the page builds locally and that all referenced commands match the current CLI behavior.
    • मजबूत version checkable page, build command, और command behavior देता है

  • Research Goal के evidence standards

    • investigation शुरू करने से पहले परिभाषित करें: exact reproduction, partial reconstruction, proxy support, और blocker के रूप में क्या गिना जाएगा
    • मजबूत research Goal claim inventory बनाना, claim-to-evidence mapping, executable parts का implementation, blockers की labeling, और confirmed claims, support-only evidence, blocked claims, तथा remaining uncertainty को अलग करने वाला audit बनाना माँगता है

जटिल research में Goals का उपयोग: quant paper reproduction case

  • Case overview

    • target: Buehler, Gonon, Teichmann, Wood का Deep Hedging पेपर
    • पेपर का विषय: क्या neural network trading strategies, risk preference, transaction cost, और high-dimensional market settings में model-based hedge को reproduce कर सकती हैं
    • सही Goal कोई abstract “paper reproduce करो” नहीं, बल्कि headline numerical claims को attempt करना, exact mechanisms और approximate trained substitutes को अलग रखना, और available material से exact reproduction असंभव हो तो उसे स्पष्ट करना है

  • कमजोर बनाम मजबूत research Goal

    • कमजोर: /goal Reproduce Buehler et al., "Deep Hedging"
      • इसमें यह तय नहीं कि कौन-से sections महत्वपूर्ण हैं, क्या reproduction माना जाएगा, missing training state को कैसे handle करना है, या approximate match और exact replay के बीच सीमा क्या है
    • मजबूत: /goal Produce the strongest evidence-backed reproduction of Buehler et al., "Deep Hedging," using the available paper materials and local resources. Attempt every headline result, verify the outputs, and end with a report that separates reproduced mechanics, approximate trained results, blocked exact replay, and remaining uncertainty.

  • Codex वास्तव में क्या करता है

    • headline claims और supporting claims को अलग करता है
    • claims को available evidence से map करता है
    • locally testable parts को rebuild करता है
    • जिन claims को available material से exactly reproduce नहीं किया जा सकता, उन्हें label करता है

  • जो हिस्से executable थे

    • pricing और hedging mechanics का reconstruction
    • Heston reference pricing का reproduction
    • CVaR hedging experiments के लिए policy training
    • main histogram और hedge surface artifacts का reconstruction
    • Black-Scholes transaction-cost slope का reproduction
    • Heston transaction-cost और high-dimensional examples के लिए trained checks चलाना

  • जो हिस्से blockers बने रहे

    • पेपर exact random seeds, generated training paths, TensorFlow graphs, optimizer state, checkpoints, या पूरा original simulation state उपलब्ध नहीं कराता
    • सबसे ईमानदार नतीजा partial और approximate reproduction है, exact neural replay नहीं

  • Report epistemic support level को बनाए रखती है

    • trained substitutes claims को support कर सकते हैं, close numerical matches confidence बढ़ा सकते हैं, reconstructed figures result के कुछ हिस्सों को verify कर सकते हैं, लेकिन इनमें से कोई भी original experiment को exactly restore करने का दावा नहीं कर सकता
    • ledger उदाहरण:
      • Claim: Deep hedging approximates complete-market Heston hedge without transaction costs
      • Route: model mechanics reconstruction, reference hedge comparison, neural policy training
      • Evidence surface: pricing checks, histograms, hedge surface
      • Status: Close approximate reproduction
      • Remaining uncertainty: original training path, seeds, और checkpoints उपलब्ध नहीं
  • Research में Goals की demonstration value यह है कि यह ambiguity के बीच भी काम जारी रखता है, लेकिन plausible artifacts को बढ़ा-चढ़ाकर conclusion बनने से रोकता है; completion का अर्थ evidence-based claim-by-claim audit, approximation की स्पष्टता, और reproduction तथा replay की सीमा पर ईमानदारी के रूप में परिभाषित करता है

Goals का उपयोग कब नहीं करना चाहिए

  • एक लाइन का edit, सरल explanation, छोटा code review, या ऐसा प्रश्न जहाँ एक जवाब के बाद रुकना हो—इनके लिए यह उपयुक्त नहीं; सामान्य Codex prompt बेहतर है
  • जहाँ finish line अस्पष्ट हो, वहाँ भी उपयुक्त नहीं
    • “Make this better” कोई भरोसेमंद completion condition नहीं देता
    • “Refactor this code” भी कमजोर है अगर expected end state, tests, और constraints परिभाषित न हों
  • uncertainty छिपाने के लिए इसका उपयोग नहीं करना चाहिए
    • अगर data उपलब्ध न हो सकता हो, तो उसे Goal में स्पष्ट करें
    • अगर benchmark flaky हो सकता हो, तो handling method बताएँ
    • अगर proxy evidence की अनुमति हो, तो labeling method परिभाषित करें
  • Goals सबसे शक्तिशाली तब होते हैं जब ये तीन गुण साथ हों: persistent objective, evidence-based finish line, और multiple turns की investigation वाला path

निष्कर्ष: लक्ष्य बना रहे, लेकिन completion evidence तय करे

  • Goals, Codex के operating model को बदलते हैं, जिससे thread isolated prompts की श्रृंखला से निकलकर किसी परिभाषित result के इर्द-गिर्द state-based work loop में बदल जाता है
  • Architecture जानबूझकर bounded है
    • Goal thread तक सीमित होता है, lifecycle state और budget accounting रखता है, और उसे pause, resume, remove, complete, या budget-stop किया जा सकता है
    • Codex चलता रह सकता है, लेकिन केवल user-defined contract के भीतर
  • यह उन कामों में उपयोगी है जहाँ Codex पहले से सबसे अधिक मूल्य देता है: debugging, optimization, migration, testing, research
  • user goal देता है, Codex evidence का पीछा करता है, और Goal इन दोनों को तब तक जोड़कर रखता है जब तक काम पूरा न हो जाए या ईमानदारी से blocked न घोषित हो
  • जटिल research में, यह जवाब पैदा करने और audit पैदा करने के बीच का अंतर बनाता है
  • अच्छा Goal, Codex से सिर्फ खत्म करने को नहीं कहता, बल्कि उसे यह बताता है कि खत्म होने का मतलब क्या है

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

1 टिप्पणियां

 
hmmhmmhm 20 분 전

/goal कृपया दोपहर 12 बजे तक मेरे पहले किए गए कामों के आधार पर जो भी किया जा सकता है, सब जाँचकर आगे बढ़ाइए। 12 बजे से पहले काम रोकना नहीं है।