Μέσα στον εσωτερικό πράκτορα δεδομένων της OpenAI

Τα δεδομένα τροφοδοτούν το πώς μαθαίνουν τα συστήματα, πώς εξελίσσονται τα προϊόντα και πώς παίρνουν αποφάσεις οι εταιρείες. Αλλά το να λαμβάνετε απαντήσεις γρήγορα, σωστά και με το σωστό πλαίσιο είναι συχνά πιο δύσκολο απ’ όσο θα έπρεπε. Για να το κάνουμε αυτό πιο εύκολο καθώς η OpenAI κλιμακώνεται, δημιουργήσαμε τον δικό μας εξατομικευμένο εσωτερικό πράκτορα δεδομένων τεχνητής νοημοσύνης που εξερευνά και συλλογίζεται πάνω στη δική μας πλατφόρμα.

Ο πράκτοράς μας είναι ένα προσαρμοσμένο εργαλείο αποκλειστικά για εσωτερική χρήση (όχι μια εξωτερική προσφορά), που δημιουργήθηκε ειδικά με βάση τα δεδομένα, τα δικαιώματα και τις ροές εργασίας της OpenAI. Δείχνουμε πώς το δημιουργήσαμε και το χρησιμοποιούμε για να αναδείξουμε παραδείγματα των πραγματικών, ουσιαστικών τρόπων με τους οποίους μπορεί η τεχνητή νοημοσύνη να υποστηρίξει την καθημερινή εργασία στις ομάδες μας. Τα εργαλεία της OpenAI που χρησιμοποιήσαμε για να το δημιουργήσουμε και να το εκτελέσουμε (Codex, το κορυφαίο μοντέλο μας GPT‑5, το Evals API⁠(ανοίγει σε νέο παράθυρο) και το Embeddings API⁠(ανοίγει σε νέο παράθυρο)) είναι τα ίδια εργαλεία που διαθέτουμε σε προγραμματιστές παντού.

Ο πράκτορας δεδομένων μας επιτρέπει στους εργαζομένους να μεταβαίνουν από την ερώτηση στην πληροφορία μέσα σε λεπτά, όχι σε ημέρες. Αυτό μειώνει το εμπόδιο για άντληση δεδομένων και λεπτομερή ανάλυση σε όλες τις λειτουργίες, όχι μόνο από την ομάδα δεδομένων μας. Σήμερα, ομάδες από τη Μηχανική, την Επιστήμη δεδομένων, τη διάθεση στην αγορά, τα Οικονομικά και την Έρευνα στην OpenAI βασίζονται στον πράκτορα για να απαντήσουν σε ερωτήσεις δεδομένων με υψηλό αντίκτυπο. Για παράδειγμα, μπορεί να σας βοηθήσει να απαντήσετε στο πώς να αξιολογείτε λανσαρίσματα και να κατανοείτε την υγεία της επιχείρησης, όλα μέσα από τη διαισθητική μορφή της φυσικής γλώσσας. Ο πράκτορας συνδυάζει γνώση σε επίπεδο πίνακα που υποστηρίζεται από το Codex με το πλαίσιο του προϊόντος και του οργανισμού. Το σύστημα μνήμης του, που μαθαίνει συνεχώς, σημαίνει ότι βελτιώνεται επίσης με κάθε στροφή.

Σε αυτήν την ανάρτηση, θα αναλύσουμε γιατί χρειαζόμασταν έναν εξατομικευμένο πράκτορα δεδομένων τεχνητής νοημοσύνης, τι καθιστά το εμπλουτισμένο με κώδικα πλαίσιο δεδομένων και την αυτομάθησή του τόσο χρήσιμα, και τα διδάγματα που αποκομίσαμε στην πορεία.

Η πλατφόρμα δεδομένων της OpenAI εξυπηρετεί περισσότερους από 3,5 χιλιάδες εσωτερικούς χρήστες που εργάζονται σε τομείς Μηχανικής, Προϊόντων και Έρευνας, καλύπτοντας πάνω από 600 petabyte δεδομένων σε 70 χιλιάδες σύνολα δεδομένων. Σε αυτό το μέγεθος, το να βρείτε τον σωστό πίνακα μπορεί να είναι από τα πιο χρονοβόρα μέρη της ανάλυσης.

Όπως το έθεσε ένας εσωτερικός χρήστης:

«Έχουμε πολλούς πίνακες που είναι αρκετά παρόμοιοι και αφιερώνω πολύ χρόνο προσπαθώντας να καταλάβω πώς διαφέρουν και ποιους να χρησιμοποιήσω. Ορισμένα περιλαμβάνουν αποσυνδεδεμένους χρήστες, ενώ άλλα όχι. Μερικά έχουν επικαλυπτόμενα πεδία. Είναι δύσκολο να καταλάβει κανείς τι είναι τι.

Ακόμα και με τους σωστούς πίνακες επιλεγμένους, η παραγωγή σωστών αποτελεσμάτων μπορεί να είναι δύσκολη. Οι αναλυτές πρέπει να εξετάζουν τα δεδομένα των πινάκων και τις σχέσεις μεταξύ τους, ώστε να διασφαλίζεται ότι οι μετασχηματισμοί και τα φίλτρα εφαρμόζονται σωστά. Συνηθισμένοι τρόποι αποτυχίας—συνδέσεις πολλών-προς-πολλά, σφάλματα προώθησης φίλτρων και μη διαχειριζόμενες τιμές μηδέν—μπορούν να ακυρώσουν σιωπηρά τα αποτελέσματα. Στην κλίμακα του OpenAI, οι αναλυτές δεν θα πρέπει να αφιερώνουν χρόνο στην επιδιόρθωση σφαλμάτων της σημασιολογίας SQL ή της απόδοσης ερωτημάτων: η εστίασή τους θα πρέπει να είναι στον ορισμό μετρήσεων, στην επικύρωση υποθέσεων και στη λήψη αποφάσεων που βασίζονται σε δεδομένα.

Ας εξετάσουμε τι είναι ο πράκτοράς μας, πώς επιμελείται το θεματικό πλαίσιο και πώς συνεχίζει να αυτοβελτιώνεται.

Ο πράκτοράς μας τροφοδοτείται από το GPT‑5.2 και έχει σχεδιαστεί για να επεξεργάζεται δεδομένα στην πλατφόρμα της OpenAI. Είναι διαθέσιμο όπου εργάζονται ήδη οι εργαζόμενοι: ως πράκτορας στο Slack, μέσω μιας διεπαφής ιστού, μέσα σε IDE, στο Codex CLI μέσω MCP⁠(ανοίγει σε νέο παράθυρο) και απευθείας στην εσωτερική εφαρμογή ChatGPT της OpenAI μέσω συνδέσμου MCP⁠(ανοίγει σε νέο παράθυρο).

Οι χρήστες μπορούν να θέσουν σύνθετες, ανοιχτού τύπου ερωτήσεις, οι οποίες συνήθως απαιτούν πολλαπλούς γύρους μη αυτόματης εξερεύνησης. Πάρτε αυτό το παράδειγμα προτροπής, το οποίο χρησιμοποιεί ένα σύνολο δεδομένων δοκιμής:«Για τις διαδρομές με ταξί στη Νέα Υόρκη, ποια ζεύγη Τ.Κ. παραλαβής-αποβίβασης είναι τα πιο αναξιόπιστα, με το μεγαλύτερο χάσμα μεταξύ των τυπικών και των χειρότερων χρόνων ταξιδιού, και πότε εμφανίζεται αυτή η μεταβλητότητα;»

Ο πράκτορας χειρίζεται την ανάλυση από την αρχή μέχρι το τέλος, από την κατανόηση της ερώτησης έως την εξερεύνηση των δεδομένων, την εκτέλεση ερωτημάτων και τη σύνθεση των ευρημάτων.

Μία από τις υπερδυνάμεις του πράκτορα είναι το πώς συλλογίζεται για την επίλυση προβλημάτων. Αντί να ακολουθεί ένα προκαθορισμένο σενάριο, ο πράκτορας αξιολογεί την πρόοδό του. Εάν ένα ενδιάμεσο αποτέλεσμα φαίνεται λανθασμένο (π.χ., εάν δεν έχει καμία γραμμή λόγω λανθασμένης σύνδεσης ή φίλτρου), ο πράκτορας διερευνά τι πήγε λάθος, προσαρμόζει την προσέγγισή του και προσπαθεί ξανά. Καθ' όλη τη διάρκεια αυτής της διαδικασίας, διατηρεί πλήρες πλαίσιο και μεταφέρει τα διδάγματα από το ένα βήμα στο επόμενο. Αυτή η κλειστού βρόχου, αυτοεκπαιδευόμενη διαδικασία μεταφέρει την επανάληψη από τον χρήστη στον ίδιο τον πράκτορα, επιτρέποντας ταχύτερα αποτελέσματα και σταθερά υψηλότερης ποιότητας αναλύσεις από τις μη αυτόματες ροές εργασίας.

Ο πράκτορας καλύπτει ολόκληρη τη ροή εργασιών ανάλυσης: ανακάλυψη δεδομένων, εκτέλεση SQL και δημοσίευση σημειωματάριων και αναφορών. Κατανοεί εσωτερικές εταιρικές γνώσεις, μπορεί να πραγματοποιεί αναζητήσεις στο διαδίκτυο για εξωτερικές πληροφορίες και βελτιώνεται με την πάροδο του χρόνου μέσω της εκμάθησης και της μνήμης.

Οι υψηλής ποιότητας απαντήσεις εξαρτώνται από πλούσιο και ακριβές πλαίσιο. Χωρίς το κατάλληλο πλαίσιο, ακόμη και ισχυρά μοντέλα μπορούν να παράγουν λανθασμένα αποτελέσματα, όπως η υπερβολικά λανθασμένη εκτίμηση του αριθμού των χρηστών ή η εσφαλμένη ερμηνεία της εσωτερικής ορολογίας.

Για να αποφευχθούν αυτές οι καταστάσεις αποτυχίας, ο πράκτορας βασίζεται σε πολλαπλά επίπεδα πλαισίου που τον βασίζουν στα δεδομένα και τη θεσμική γνώση του OpenAI.

• Θεμελίωση μεταδεδομένων: Ο πράκτορας βασίζεται στα μεταδεδομένα του σχήματος (ονόματα στηλών και τύποι δεδομένων) για να καθοδηγεί τη σύνταξη SQL και χρησιμοποιεί τη γενεαλογία πινάκων (π.χ. σχέσεις πινάκων ανάντη και κατάντη) για να παρέχει πλαίσιο σχετικά με το πώς σχετίζονται διαφορετικοί πίνακες.
• Συμπερασματολογία ερωτημάτων: Η εισαγωγή ιστορικών ερωτημάτων βοηθά τον πράκτορα να κατανοήσει πώς να συντάσσει τα δικά του ερωτήματα και ποιοι πίνακες συνήθως συνδέονται μεταξύ τους.

• Επιμελημένες περιγραφές πινάκων και στηλών που παρέχονται από ειδικούς στον τομέα, οι οποίες αποτυπώνουν την πρόθεση, τη σημασιολογία, το επιχειρηματικό νόημα και γνωστές προειδοποιήσεις που δεν συνάγονται εύκολα από σχήματα ή προηγούμενα ερωτήματα.

Τα μεταδεδομένα από μόνα τους δεν είναι αρκετά. Για να ξεχωρίσετε πραγματικά τους πίνακες, πρέπει να κατανοήσετε πώς δημιουργήθηκαν και από πού προέρχονται.

• Με την εξαγωγή ενός ορισμού σε επίπεδο κώδικα για έναν πίνακα, ο πράκτορας αποκτά βαθύτερη κατανόηση του τι περιέχουν πραγματικά τα δεδομένα. 
  • Οι λεπτομέρειες σχετικά με το τι αποθηκεύεται στον πίνακα και πώς προκύπτει από ένα συμβάν ανάλυσης παρέχουν επιπλέον πληροφορίες. Για παράδειγμα, μπορεί να παρέχει πλαίσιο σχετικά με τη μοναδικότητα των τιμών, το πόσο συχνά ενημερώνονται τα δεδομένα του πίνακα, το εύρος των δεδομένων (π.χ., αν ο πίνακας εξαιρεί ορισμένα πεδία, έχει αυτό το επίπεδο λεπτομέρειας), κ.λπ.
• Αυτό παρέχει βελτιωμένο πλαίσιο χρήσης, δείχνοντας πώς χρησιμοποιείται ο πίνακας πέρα από την SQL σε Spark, Python και άλλα συστήματα δεδομένων.
• Αυτό σημαίνει ότι ο πράκτορας μπορεί να διακρίνει μεταξύ πινάκων που φαίνονται παρόμοιοι αλλά διαφέρουν σε κρίσιμα σημεία. Για παράδειγμα, μπορεί να διαπιστώσει εάν ένας πίνακας περιλαμβάνει μόνο επισκεψιμότητα ChatGPT πρώτου μέρους. Αυτό το περιβάλλον ανανεώνεται επίσης αυτόματα, επομένως παραμένει ενημερωμένο χωρίς μη αυτόματη συντήρηση.

• Ο πράκτορας μπορεί να έχει πρόσβαση σε Slack, Google Docs και Notion, τα οποία καταγράφουν κρίσιμο εταιρικό πλαίσιο, όπως λανσαρίσματα, περιστατικά αξιοπιστίας, εσωτερικές κωδικές ονομασίες και εργαλεία, καθώς και τους κανονικούς ορισμούς και τη λογική υπολογισμού για βασικές μετρήσεις.
• Αυτά τα έγγραφα εισάγονται, ενσωματώνονται και αποθηκεύονται με μεταδεδομένα και δικαιώματα πρόσβασης. Μια υπηρεσία ανάκτησης διαχειρίζεται τον έλεγχο πρόσβασης και την προσωρινή αποθήκευση κατά την εκτέλεση, επιτρέποντας στον πράκτορα να αντλεί αυτές τις πληροφορίες αποτελεσματικά και με ασφάλεια.

• Όταν δίνονται διορθώσεις στον πράκτορα ή ανακαλύπτει αποχρώσεις σε ορισμένα ερωτήματα δεδομένων, μπορεί να αποθηκεύει αυτές τις γνώσεις για την επόμενη φορά, επιτρέποντάς του να βελτιώνεται συνεχώς με τους χρήστες του. 
  • Ως αποτέλεσμα, οι μελλοντικές απαντήσεις ξεκινούν από μια πιο ακριβή βάση αντί να αντιμετωπίζουν επανειλημμένα τα ίδια προβλήματα.
  • Ο στόχος της μνήμης είναι να διατηρεί και να επαναχρησιμοποιεί μη προφανείς διορθώσεις, φίλτρα και περιορισμούς που είναι κρίσιμοι για την ορθότητα των δεδομένων, αλλά είναι δύσκολο να εξαχθούν συμπεράσματα μόνο από τα άλλα επίπεδα. 
  • Για παράδειγμα, σε μία περίπτωση, ο πράκτορας δεν ήξερε πώς να πραγματοποιήσει φιλτράρισμα για ένα συγκεκριμένο πείραμα αναλυτικών (βασιζόταν στην αντιστοίχιση με μια συγκεκριμένη συμβολοσειρά που ορίζεται σε μια πύλη πειράματος). Η μνήμη ήταν καίριας σημασίας εδώ για να διασφαλιστεί ότι μπορούσε να φιλτράρει σωστά, αντί να προσπαθεί αόριστα να κάνει αντιστοίχιση συμβολοσειρών.
• Όταν κάνετε μια διόρθωση στον πράκτορα ή όταν αυτός βρει κάτι που μαθαίνει από τη συζήτησή σας, θα σας ζητηθεί να αποθηκεύσετε αυτήν την ανάμνηση για την επόμενη φορά. 
  • Οι μνήμες μπορούν επίσης να δημιουργούνται και να υποβάλλονται σε επεξεργασία μη αυτόματα από εσάς.
  • Οι μνήμες οριοθετούνται σε παγκόσμιο και προσωπικό επίπεδο, και τα εργαλεία του πράκτορα διευκολύνουν την επεξεργασία τους.

• Όταν δεν υπάρχει προηγούμενο πλαίσιο για έναν πίνακα ή όταν οι υπάρχουσες πληροφορίες είναι παρωχημένες, ο πράκτορας μπορεί να εκτελεί ζωντανά ερωτήματα στην αποθήκη δεδομένων για να επιθεωρεί και να υποβάλλει ερωτήματα στον πίνακα απευθείας. Αυτό επιτρέπει την επικύρωση των σχημάτων, την κατανόηση των δεδομένων σε πραγματικό χρόνο και την ανάλογη ανταπόκριση.
• Ο πράκτορας είναι επίσης σε θέση να επικοινωνεί με άλλα συστήματα της Πλατφόρμας Δεδομένων (υπηρεσία μεταδεδομένων, Airflow, Spark) όπως απαιτείται, για να αποκτήσει ευρύτερο πλαίσιο δεδομένων που υπάρχει εκτός της αποθήκης.

We run a daily offline pipeline that aggregates table usage, human annotations, and Codex-derived enrichment into a single, normalized representation. This enriched context is then converted into embeddings using the OpenAI embeddings API⁠(ανοίγει σε νέο παράθυρο) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(ανοίγει σε νέο παράθυρο) (RAG) instead of scanning raw metadata or logs. This makes table understanding fast and scalable, even across tens of thousands of tables, while keeping runtime latency predictable and low. Runtime queries are issued to our data warehouse live as needed.

Together, these layers ensure the agent’s reasoning is grounded in OpenAI’s data, code, and institutional knowledge, dramatically reducing errors and improving answer quality.

One-shot answers work when the problem is clear, but most questions aren’t. More often, arriving at the correct result requires back-and-forth refinement and some course correction.

The agent is built to behave like a teammate you can reason with. It’s a conversational, always-on and handles both quick answers and iterative exploration.

It carries over complete context across turns, so users can ask follow-up questions, adjust their intent, or change direction without restating everything. If the agent starts heading down the wrong path, users can interrupt mid-analysis and redirect it, just like working with a human collaborator who listens instead of plowing ahead.

When instructions are unclear or incomplete, the agent proactively asks clarifying questions. If no response is provided, it applies sensible defaults to make progress. For example, if a user asks about business growth with no date range specified, it may assume the last seven or 30 days. These priors allow it to stay responsive and non-blocking while still converging on the right outcome.

The result is an agent that works well both when you know exactly what you want (e.g., “Tell me about this table”) and just as strong when you’re exploring (e.g., “I’m seeing a dip here, can we break this down by customer type and timeframe?”). 

After rollout, we observed that users frequently ran the same analyses for routine repetitive work. To expedite this, the agent's workflows package recurring analyses into reusable instruction sets. Examples include workflows for weekly business reports and table validations. By encoding context and best practices once, workflows streamline repeat analyses and ensure consistent results across users.

Building an always-on, evolving agent means quality can drift just as easily as it can improve. Without a tight feedback loop, regressions are inevitable and invisible. The only way to scale capability without breaking trust is through systematic evaluation.

In this section, we’ll discuss how we leverage OpenAI’s Evals API⁠(ανοίγει σε νέο παράθυρο) to measure and protect the agent’s response quality.

Its Evals are built on curated sets of question-answer pairs. Each question targets an important metric or analytical pattern we care deeply about getting right, paired with a manually authored “golden” SQL query that produces the expected result. For each eval, we send the natural language question to its query-generation endpoint, execute the generated SQL, and compare the output against the result of the expected SQL.

Evaluation doesn’t rely on naive string matching. Generated SQL can differ syntactically while still being correct, and result sets may include extra columns that don’t materially affect the answer. To account for this, we compare both the SQL and the resulting data, and feed these signals into OpenAI’s Evals grader. The grader produces a final score along with an explanation, capturing both correctness and acceptable variation.

These evals are like unit tests that run continuously during development to identify regressions as canaries in production; this allows us to catch issues early and confidently iterate as the agent's capabilities expand.

Our agent plugs directly into OpenAI’s existing security and access-control model. It operates purely as an interface layer, inheriting and enforcing the same permissions and guardrails that govern OpenAI’s data. 

All of the agent’s access is strictly pass-through, meaning users can only query tables they already have permission to access. When access is missing, it flags this or falls back to alternative datasets the user is authorized to use.

Finally, it's built for transparency. Like any system, it can make mistakes. It exposes its reasoning process by summarizing assumptions and execution steps alongside each answer. When queries are executed, it links directly to the underlying results, allowing users to inspect raw data and verify every step of the analysis.

Building our agent from scratch surfaced practical lessons about how agents behave, where they struggle, and what actually makes them reliable at scale.

Early on, we exposed our full tool set to the agent, and quickly ran into problems with overlapping functionality. While this redundancy can be helpful for specific custom cases and is more obvious to a human when manually invoking, it’s confusing to agents. To reduce ambiguity and improve reliability, we restricted and consolidated certain tool calls.

We also discovered that highly prescriptive prompting degraded results. While many questions share a general analytical shape, the details vary enough that rigid instructions often pushed the agent down incorrect paths. By shifting to higher-level guidance and relying on GPT‑5’s reasoning to choose the appropriate execution path, the agent became more robust and produced better results.

Schemas and query history describe a table’s shape and usage, but its true meaning lives in the code that produces it. Pipeline logic captures assumptions, freshness guarantees, and business intent that never surface in SQL or metadata. By crawling the codebase with Codex, our agent understands how datasets are actually constructed and is able to better reason about what each table actually contains. It can answer “what’s in here” and “when can I use it” far more accurately than from warehouse signals alone. 

We’re constantly working to improve our agent by increasing its ability to handle ambiguous questions, improving its reliability and accuracy with stronger validations, and integrating it more deeply into workflows. We believe it should blend naturally into how people already work, instead of functioning like a separate tool.

While our tooling will keep benefiting from underlying improvements in agent reasoning, validation, and self-correction, our team’s mission remains the same: seamlessly deliver fast, trustworthy data analysis across OpenAI’s data ecosystem.