OpenAI के इन-हाउस डेटा एजेंट के अंदर की झलक

• OpenAI ने 3,500 से अधिक आंतरिक उपयोगकर्ताओं और 600PB पैमाने के डेटा का कुशलतापूर्वक विश्लेषण करने के लिए कस्टम AI डेटा एजेंट खुद बनाया
• केवल natural language सवालों के आधार पर टेबल एक्सप्लोर करना, SQL चलाना, नोटबुक और रिपोर्ट प्रकाशित करना तक की end-to-end analysis workflow को अपने-आप संभालता है
• सटीकता सुनिश्चित करने के लिए 6 स्तरों के context — टेबल उपयोग, मानव annotations, Codex-आधारित code analysis, organizational knowledge, memory, और runtime context — को जोड़ता है
• अगर बीच का परिणाम गलत हो, तो कारण खुद जांचकर अपना approach बदलने वाली self-learning closed loop संरचना पर चलता है
• Evals API आधारित व्यवस्थित evaluation system से quality regression को जल्दी detect करता है, और मौजूदा security व permission model को ज्यों का त्यों अपनाकर reliability बनाए रखता है

---

कस्टम डेटा एजेंट की ज़रूरत क्यों पड़ी

• OpenAI के डेटा प्लेटफ़ॉर्म में 3,500 से अधिक आंतरिक उपयोगकर्ता, 600 petabyte पैमाने का डेटा, और 70,000 से अधिक datasets हैं, और सही टेबल ढूंढना ही analysis का सबसे समय लेने वाला काम है
• एक जैसे कई टेबल होने से, जैसे logged-out users शामिल हैं या नहीं, fields दोहराए गए हैं या नहीं, टेबलों के बीच अंतर समझना कठिन हो जाता है
• सही टेबल चुनने के बाद भी many-to-many join, filter pushdown errors, और null को handle न करना जैसे मुद्दे नतीजों को अमान्य बना सकते हैं
• analysts को SQL debugging पर नहीं, बल्कि metric definitions, assumptions की validation, और data-driven decision making पर ध्यान देना चाहिए

एजेंट कैसे काम करता है

• GPT-5.2 पर आधारित
• Slack agent, web interface, IDE, Codex CLI (MCP integration), और internal ChatGPT app जैसे उन्हीं environments में उपलब्ध है जिन्हें कर्मचारी पहले से इस्तेमाल करते हैं
• जटिल और open-ended सवालों को भी संभाल सकता है
  • सवाल को समझना
  • डेटा एक्सप्लोर करना
  • SQL चलाना
  • नतीजों का analysis और summary तक end-to-end पूरा करना
  • उदाहरण: NYC taxi dataset में pickup-dropoff ZIP pairs के बीच travel time variability सबसे अधिक किस संयोजन में है, इसका analysis
• यह किसी fixed script का पालन नहीं करता, बल्कि अपनी प्रगति का खुद मूल्यांकन करता है, और अगर बीच का परिणाम गलत निकले (जैसे गलत join या filter के कारण 0 rows मिलना), तो कारण ढूंढकर approach बदलता है और दोबारा कोशिश करता है
• पूरा analysis workflow कवर करता है: data discovery, SQL execution, notebook और report publishing, internal knowledge reference, web search, और memory-based learning

context की परतदार संरचना

• Layer 1: Table Usage

  • metadata grounding: schema metadata (column names, data types) का उपयोग SQL लिखने में किया जाता है, और table lineage (parent-child table relationships) से टेबलों के बीच संबंध समझे जाते हैं
  • query inference: पुरानी queries इकट्ठा करके एजेंट अपने query-writing patterns और आम तौर पर साथ join होने वाले टेबल combinations सीखता है

• Layer 2: Human Annotations

  • domain experts टेबल और columns के लिए curated explanations लिखते हैं, जो intent, semantics, business context, और known caveats जैसी ऐसी जानकारी पकड़ते हैं जिन्हें schema या पुरानी queries से समझना मुश्किल होता है
  • केवल metadata से टेबलों में फर्क करना मुश्किल होने के कारण वे कैसे बने और उनका source क्या है, यह समझना ज़रूरी है

• Layer 3: Codex Enrichment

  • टेबल की code-level definition निकालकर डेटा के वास्तविक अर्थ को गहराई से समझता है
    • values की uniqueness, table refresh frequency, data scope (कुछ fields excluded हैं या नहीं, granularity level क्या है) जैसी analysis event-आधारित nuances देता है
  • SQL के अलावा Spark, Python जैसे विभिन्न data systems में usage context भी समझ सकता है
  • ऊपर से समान दिखने वाले लेकिन मूल रूप से अलग टेबलों में फर्क कर सकता है, जैसे कोई टेबल केवल 1st-party ChatGPT traffic को शामिल करता है या नहीं
  • यह context अपने-आप update होता है, इसलिए manual maintenance की ज़रूरत नहीं पड़ती

• Layer 4: Institutional Knowledge

  • Slack, Google Docs, Notion आदि से launches, incidents, internal code names, और key metrics की official definitions और calculation logic जैसी company context इकट्ठा करता है
  • documents को collect, embed, और metadata व permissions के साथ store किया जाता है, और runtime पर access control और caching संभालने वाली retrieval service चलती है

• Layer 5: Memory

  • जब एजेंट को corrections मिलते हैं या वह data questions की nuance पहचानता है, तो उन्हें store कर लेता है ताकि अगले analysis में अधिक सटीक baseline से शुरुआत हो
  • memory का लक्ष्य ऐसे non-obvious corrections, filters, और constraints को सुरक्षित रखना और दोबारा इस्तेमाल करना है जिन्हें दूसरी layers से infer करना कठिन हो
    • उदाहरण: किसी खास analysis experiment को filter करते समय experiment gate में defined किसी specific string matching की ज़रूरत थी, लेकिन memory के बिना fuzzy string matching आज़माने की गलती हो रही थी
  • correction या learned discovery होने पर एजेंट memory save करने का सुझाव देता है, और उपयोगकर्ता इसे manually create और edit भी कर सकते हैं
  • memory का दायरा global level और personal level में अलग किया गया है

• Layer 6: Runtime Context

  • अगर किसी टेबल के लिए पहले से context नहीं है या जानकारी पुरानी हो चुकी है, तो data warehouse पर live queries चलाकर schema verify करता है और real-time data समझता है
  • metadata service, Airflow, Spark जैसे Data Platform के अन्य systems से भी बात करके warehouse के बाहर का data context लेता है

• दैनिक offline pipeline और RAG

  • table usage, human annotations, और Codex-based enrichment को एक single normalized representation में जोड़ने वाली daily offline pipeline चलती है
  • enriched context को OpenAI Embeddings API से embedding में बदलकर store किया जाता है, और query के समय RAG (Retrieval-Augmented Generation) के जरिए केवल relevant context निकाला जाता है
  • इससे दसियों हज़ार टेबलों में table understanding तेज़ और scalable बनी रहती है, और runtime latency कम व predictable रहती है

टीममेट की तरह सोचने और सहयोग करने वाला डिज़ाइन

• one-shot जवाब के बजाय conversational iterative exploration को support करता है, और turns के बीच पूरा context बनाए रखता है ताकि follow-up questions या direction change पर शुरुआत से दोबारा समझाना न पड़े
• अगर एजेंट गलत दिशा में बढ़ रहा हो, तो उपयोगकर्ता analysis के बीच में हस्तक्षेप करके उसे redirect कर सकते हैं
• अगर निर्देश अस्पष्ट हों, तो clarifying questions proactively पूछता है, और जवाब न मिलने पर reasonable defaults (जैसे पिछले 7 दिन या 30 दिन) लागू करके आगे बढ़ता है
• जब यह देखता है कि एक ही analysis बार-बार हो रहा है, तो उस recurring analysis को reusable workflow (instruction set) के रूप में package कर देता है
  • जैसे weekly business reports, table validation
  • context और best practices को एक बार encode करके उपयोगकर्ताओं के बीच consistent results सुनिश्चित करता है

भरोसा बनाए रखते हुए तेज़ी से सुधारने वाली evaluation framework

• क्योंकि एजेंट लगातार evolve हो रहा है, quality drift आसानी से हो सकती है, और systematic evaluation के बिना regression चुपचाप आगे बढ़ सकती है
• OpenAI Evals API के आधार पर question-answer pairs का curated set बनाया जाता है, और हर सवाल के लिए manually written "golden" SQL query जोड़ी जाती है
• natural language सवालों को query generation endpoint पर भेजा जाता है, generated SQL चलाया जाता है, और expected SQL results से तुलना की जाती है
• सिर्फ string matching नहीं, बल्कि SQL और result data दोनों की तुलना करके उन्हें Evals grader में डाला जाता है, जिससे accuracy और acceptable variance को दर्शाने वाला final score और explanation मिलता है
• यह evaluation development के दौरान लगातार चलने वाले unit tests की तरह काम करती है, और production में canary की तरह regression जल्दी पकड़ती है

एजेंट सुरक्षा

• यह OpenAI के मौजूदा security और access control model से सीधे जुड़ा है, और उसी permissions व guardrails को interface layer तक inherit और apply करता है
• हर access pass-through मॉडल में होता है, इसलिए उपयोगकर्ता केवल उन्हीं टेबलों पर query कर सकते हैं जिनकी उन्हें पहले से permission है; permission न होने पर एजेंट यह बताता है या alternative dataset पर fallback करता है
• transparency के लिए reasoning process को सामने लाता है: assumptions और execution steps को जवाब के साथ summarize करता है, और executed queries के raw results के direct links देता है ताकि उपयोगकर्ता हर analysis step verify कर सकें

निर्माण के दौरान सीखे गए सबक

• Lesson 1: Less is More

  • शुरुआत में पूरे toolset को एजेंट के सामने खोल दिया गया था, लेकिन feature overlap से confusion पैदा हुआ
  • जो overlapping features इंसानों के लिए manual use में उपयोगी थे, वही एजेंट के लिए ambiguity पैदा कर रहे थे; इसलिए कुछ tool calls को सीमित और एकीकृत करके reliability बढ़ाई गई

• Lesson 2: Guide the Goal, Not the Path

  • बहुत ज़्यादा निर्देशात्मक prompting ने उल्टा नतीजों को खराब किया
  • क्योंकि हर सवाल की details अलग होती हैं, rigid instructions एजेंट को गलत रास्ते पर ले जा सकती हैं; इसलिए high-level guidance देना और execution path चुनने की ज़िम्मेदारी GPT-5 की reasoning को देना अधिक बेहतर रहा

• Lesson 3: Meaning Lives in Code

  • schema और query history सिर्फ टेबल के shape और usage pattern को बताते हैं, जबकि असली अर्थ उस code में होता है जो टेबल बनाता है
  • pipeline logic assumptions, freshness guarantees, और business intent को पकड़ता है, जो SQL या metadata में दिखता नहीं
  • Codex से codebase crawl करके datasets वास्तव में कैसे बने हैं यह समझने से, केवल warehouse signals से संभव न होने वाले "इसमें क्या है" और "यह कब इस्तेमाल किया जा सकता है" जैसे सवालों के सटीक जवाब मिलते हैं

आगे की दिशा

• ambiguous questions को संभालने की क्षमता बढ़ाना, और मज़बूत validation के ज़रिए reliability और accuracy में सुधार, और workflow integration को और गहरा करना जारी है
• लक्ष्य किसी अलग tool का नहीं, बल्कि लोगों के काम करने के मौजूदा तरीके में स्वाभाविक रूप से घुल-मिल जाने वाले रूप का है
• एजेंट reasoning, validation, और self-correction की आधारभूत तकनीकों में सुधार के साथ यह लगातार आगे बढ़ेगा,
  टीम का मिशन OpenAI के पूरे data ecosystem में तेज़ और भरोसेमंद data analysis को सहज रूप से उपलब्ध कराना है