- 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 को सहज रूप से उपलब्ध कराना है
1 टिप्पणियां
Hacker News की राय
सबसे बड़ी समस्या विश्वसनीयता और explainability है
हम Veezoo में 10 साल से natural language analytics बना रहे हैं, और साधारण Text-to-SQL approach की scalability कमज़ोर है
जब CFO revenue पूछता है, तो 99% सही संख्या का कोई मतलब नहीं होता, और CFO खुद SQL verify भी नहीं कर सकता
इसलिए हमने Knowledge Graph नाम की एक abstraction layer रखी है, जहाँ AI natural language को meaning-based query language में बदलता है और फिर उसे deterministic तरीके से SQL में compile करता है
उल्टा, इस semantic query को फिर natural language explanation में बदला जाता है ताकि user आसानी से verify कर सके कि result उसके इरादे के मुताबिक है या नहीं
business logic Knowledge Graph में मौजूद रहता है, और compiler यह सुनिश्चित करता है कि सभी queries उसे 100% follow करें
इसकी विस्तृत संरचना Veezoo Architecture दस्तावेज़ में दी गई है
मेरी जिज्ञासा यह है कि cardinality explosion को कैसे manage किया जाता है, और multi-query requests जो पिछली query results पर depend करती हैं, उन्हें कैसे handle किया जाता है
यह track किया जा सके कि किस तारीख़ को कौन-सी query इस्तेमाल हुई और उसे कैसे validate किया गया
(बेशक prompt भी version control के दायरे में आता है)
पहला example पूरी तरह बेतुका लगा, यह देखकर हैरानी हुई
अगर यह human review से पास हुआ, तो लगता है शायद इसे AI ने लिखा था, और अगर ऐसा है तो system की reliability पर सवाल उठता है
समस्या वाली image link
desktop में सही prompt है,
mobile में गलत prompt है
कई BI systems इस्तेमाल करने के अनुभव से, मुझे लगता है कि ऐसे AI agents एकदम उपयुक्त use case हैं
BI में मूल रूप से कई स्तरों पर errors होती हैं — या तो query ही गलत होती है, या data की interpretation गलत होती है
जब ये दोनों मिल जाते हैं, तो आप पहले ही ‘काल्पनिक दुनिया’ में पहुँच चुके होते हैं, इसलिए बेहतर है कि AI ही step 1 संभाल ले
मुझे उम्मीद थी कि OpenAI ने reliability problem हल कर ली होगी, लेकिन अफ़सोस कि ऐसा नहीं था
step 0: data गलत store किया गया
step -1: modeling को ही गलत समझा गया
step -2: business process शुरू से ही गलत था
इसलिए मैं इसे ‘single source of truth’ की जगह ‘single source of falsehood’ कहता हूँ
trust को scale करना सबसे कठिन हिस्सा है
हम भी कुछ ऐसा ही बना रहे हैं, और चाहे agent loop कितना भी अच्छा हो, अंत में मानव-क्यूरेटेड standard metrics (canonical metrics) की ज़रूरत पड़ती ही है
वरना non-technical users ऐसे SQL के आधार पर ख़तरनाक फ़ैसले ले सकते हैं जिन्हें वे validate नहीं कर सकते
हमारा approach यह है
समय के साथ ज़्यादातर queries standard metrics का उपयोग करने लगती हैं, और agent एक साधारण SQL generator नहीं बल्कि intent→verified metrics का smart router बन जाता है
“trust को तोड़े बिना तेज़ी से आगे बढ़ना” सेक्शन में golden SQL evaluation system भी यही insight दिखाता है
इस बारे में यह blog post में लिखा है
अगर answer तक पहुँचने के कई रास्ते हैं, तो अलग-अलग results आएँगे
LLM अक्सर ‘xyz_index’ जैसे बेकार metrics बना देता है, और users उन्हें plausible मानकर सीधे इस्तेमाल कर लेते हैं
मेरी राय में developer jobs पर AI का असली असर data और documentation quality पर पड़ेगा
किसी कंपनी का data कितना अच्छी तरह व्यवस्थित है, यही AI उपयोग की efficiency तय करेगा
public data लगभग समाप्त हो चुका है, और अगला resource internal documents, code repositories, और data lakes हैं
जिन कंपनियों की यह नींव मज़बूत है, वे AI के ज़रिए नई services जल्दी और कम लागत में बना और maintain कर सकेंगी
इसके उलट, जिन कंपनियों में documentation और code management अव्यवस्थित है, वहाँ AI ठीक से काम नहीं करेगा
आखिरकार वे competitors से बाज़ार हार जाएँगी
इसलिए आगे नौकरी खोजते समय मैं ज़रूर पूछूँगा कि documentation, data, और repository management का स्तर कैसा है
Amplitude ने Moda नाम का एक मिलता-जुलता system बनाया है
कुछ महीने पहले Wade ने Claire Vo को demo video दिखाया था, और वह सचमुच शानदार था
मैं हर दिन इससे तरह-तरह के सवाल पूछते हुए इसका उपयोग कर रहा हूँ
हम भी Definite.app में ऐसा ही feature सिर्फ़ 5 मिनट में देते हैं
Spark या Snowflake की ज़रूरत नहीं है
हम data lake, pipeline, semantic layer, और data agent को एक ही app में उपलब्ध कराते हैं
सच तो यह है कि agent से ज़्यादा मुश्किल data infrastructure बनाना है
अगर agent केवल SQL लिख सकता है, तो उसकी सीमा काफ़ी है, लेकिन हमने उसे infrastructure खुद manage करने लायक बनाया है, जिससे बड़ा turning point आया है
सामग्री वाकई बहुत अच्छी है
लेकिन ऐसा लगता है कि result कैसे calculate हुआ, इसे explain करने वाला हिस्सा गायब है
OpenAI के internal use के लिए यह मान लेना ठीक है कि user SQL पढ़ सकता है, लेकिन non-technical users के लिए यह design के स्तर पर बड़ी चुनौती है
data systems के साथ काम करते हुए जल्दी समझ आ जाता है कि सिर्फ़ ‘answer’ ही नहीं, बल्कि ‘answer कैसे निकला’ भी उतना ही महत्वपूर्ण है
व्यक्तिगत रूप से मुझे Kimi का In-House Data Agent ज़्यादा दिलचस्प लगता है
data problems तकनीकी समस्याएँ नहीं बल्कि organizational problems हैं
मेरे अनुभव में data problems की जड़ ‘गलत technology choice’ नहीं, बल्कि governance और ownership decisions में होती है
आख़िरकार सब कुछ Conway's Law पर आकर टिकता है