Внутрішній агент даних OpenAI

Дані визначають, як навчаються системи, як розвиваються продукти, і як компанії ухвалюють рішення. Але отримувати відповіді швидко, правильно та в потрібному контексті часто складніше, ніж має бути. Щоб спростити це в міру масштабування OpenAI, ми створили власного унікального внутрішнього ШІ-агента для роботи з даними, який досліджує та міркує над нашою власною платформою.

Наш агент — це спеціалізований внутрішній інструмент (не зовнішнє рішення), розроблений спеціально для роботи з даними, дозволами та робочими процесами OpenAI. Ми покажемо, як ми його створили та використовуємо, щоб показати приклади реальних і значущих способів, у яких ШІ може підтримувати повсякденну роботу наших команд. Інструменти OpenAI, які ми використали для його створення та запуску (Codex, наша флагманська модель GPT‑5, Evals API⁠(відкривається у новому вікні) і Embeddings API⁠(відкривається у новому вікні)), — це ті самі інструменти, які ми надаємо розробникам у всьому світі.

Наш агент даних дозволяє співробітникам переходити від запитання до висновку не за дні, а за лічені хвилини. Це знижує поріг для отримання даних і проведення детального аналізу у всіх відділах, а не лише нашою командою з даних. Сьогодні команди з відділів Engineering, Data Science, Go-To-Market, Finance та Research в OpenAI покладаються на агента, щоб отримувати відповіді на значущі запитання щодо даних. Наприклад, він може допомогти відповісти на запитання, як оцінювати запуски та розуміти стан бізнесу, і все це завдяки інтуїтивному формату природної мови. Агент поєднує знання на рівні таблиць, що базуються на Codex, з контекстом продукту та організації. Його система пам’яті, що безперервно навчається, означає, що він також постійно вдосконалюється.

У цьому дописі ми розглянемо, чому нам знадобився окремий ШІ-агент для роботи з даними, що робить його контекст даних, збагачений кодом, і самонавчання такими корисними, а також які уроки ми засвоїли на цьому шляху.

Платформа даних OpenAI обслуговує понад 3,5 тис. внутрішніх користувачів, які працюють у сферах інженерії, продукту та досліджень, охоплюючи понад 600 петабайтів даних у 70 тис. наборів даних. За такого масштабу просто знайти потрібну таблицю може бути однією з найбільш трудомістких частин аналізу.

Як зазначив один із внутрішніх користувачів:

«У нас є багато досить схожих таблиць, і я витрачаю купу часу, намагаючись зрозуміти, чим вони відрізняються і яку з них використовувати. Деякі включають неавторизованих користувачів, а деякі — ні. Деякі поля перекриваються; важко зрозуміти, що до чого.»

Навіть якщо вибрано правильні таблиці, отримати правильні результати може бути складно. Аналітики повинні аналізувати дані таблиць та їх взаємозв'язки, щоб гарантувати правильне застосування перетворень і фільтрів. Поширені режими відмов — з’єднання «багато-до-багатьох», помилки проштовхування фільтрів і необроблені null-значення—можуть непомітно зробити результати недійсними. У масштабі OpenAI аналітикам не варто витрачати час на налагодження семантики SQL або продуктивності запитів: їхня увага має бути зосереджена на визначенні метрик, перевірці припущень та ухваленні рішень на основі даних.

Розглянемо нашого агента та проаналізуємо, як він добирає контекст і як він продовжує самовдосконалюватися.

Наш агент працює на основі GPT‑5.2 і призначений для роботи з платформою даних OpenAI. Він доступний там, де співробітники вже працюють: як агент у Slack, через веб-інтерфейс, у IDE, у Codex CLI через MCP⁠(відкривається у новому вікні) і безпосередньо у внутрішньому застосунку ChatGPT від OpenAI через конектор MCP⁠(відкривається у новому вікні).

Користувачі можуть ставити складні, відкриті запитання, які зазвичай вимагають кількох етапів ручного дослідження. Візьмемо цей приклад запиту, у якому використовується тестовий набір даних: «Для поїздок на таксі в Нью-Йорку, які пари ZIP-кодів “місце посадки — місце висадки” є найменш надійними, з найбільшим розривом між типовим і найгіршим часом у дорозі, і коли виникає ця варіативність?»

Агент виконує аналіз від початку до кінця, від розуміння запитання до дослідження даних, виконання запитів і синтезу висновків.

Одна з суперсил агента — його здатність розв'язувати проблеми. Замість того, щоб дотримуватися фіксованого сценарію, агент оцінює свій прогрес. Якщо проміжний результат виглядає неправильним (наприклад, якщо він має нуль рядків через некоректне з’єднання або фільтр), агент з’ясовує, що сталося, коригує свій підхід і пробує знову. Упродовж цього процесу зберігається повний контекст, а набуті знання переносяться між кроками. Цей замкнений самонавчальний процес переносить ітерації від користувача до самого агента, що дозволяє отримувати швидші результати та стабільно вищу якість аналізу, ніж у ручних робочих процесах.

Агент охоплює весь аналітичний робочий процес: виявлення даних, виконання SQL та публікацію блокнотів і звітів. Він розуміє внутрішні знання компанії, може здійснювати вебпошук зовнішньої інформації та з часом удосконалюється завдяки навчанню на основі використання та пам’яті.

Якість відповідей залежить від змістовності та точності контексту. Без контексту навіть потужні моделі можуть давати неправильні результати — наприклад, значно помилятися в оцінці кількості користувачів або неправильно тлумачити внутрішню термінологію.

Щоб уникнути таких проблем, агент побудований на основі кількох рівнів контексту, які прив’язують його до даних OpenAI та інституційних знань.

• Прив’язка до метаданих: Агент покладається на метадані схеми (назви стовпців і типи даних) для написання SQL і використовує походження таблиць (наприклад, зв’язки між висхідними та низхідними таблицями), щоб надати контекст щодо взаємозв’язку різних таблиць.
• Інтерпретація запитів: Завантаження попередніх запитів допомагає агенту зрозуміти, як формулювати власні запити та які таблиці зазвичай об'єднуються.

• Кураторські описи таблиць і стовпців, надані експертами в цій галузі, що відображають намір, семантику, бізнес-значення та відомі застереження, які важко вивести зі схем або попередніх запитів.

Самих лише метаданих недостатньо. Щоб дійсно розрізняти таблиці, потрібно зрозуміти, як їх створили і звідки вони походять.

• Виводячи визначення таблиці на рівні коду, агент отримує глибше розуміння того, що насправді містять дані. 
  • Нюанси щодо того, що зберігається в таблиці та як це отримується з аналітичної події, надають додаткову інформацію. Наприклад, це може надати контекст щодо унікальності значень, частоти оновлення даних таблиці, обсягу даних (наприклад, якщо таблиця виключає певні поля, вона має певний рівень деталізації) тощо.
• Це надає розширений контекст використання, демонструючи, як таблиця застосовується не лише в SQL, але й у Spark, Python та інших системах даних.
• Це означає, що агент може розрізняти таблиці, які виглядають схожими, але мають ключові відмінності. Наприклад, можна визначити, чи таблиця містить лише трафік ChatGPT від першої сторони. Цей контекст також оновлюється автоматично, тому він залишається актуальним без ручного обслуговування.

• Агент може отримати доступ до Slack, Google Docs і Notion, які фіксують критично важливий контекст компанії, зокрема запуски, інциденти надійності, внутрішні кодові назви та інструменти, а також канонічні визначення та логіку обчислення ключових метрик.
• Ці документи завантажуються, вбудовуються та зберігаються разом з метаданими та дозволами. Служба отримання даних керує контролем доступу та кешуванням під час виконання, дозволяючи агенту ефективно та безпечно отримувати цю інформацію.

• Коли агент отримує виправлення або виявляє нюанси щодо певних запитань про дані, він може зберігати ці знання на майбутнє, що дозволяє йому постійно вдосконалюватися разом з користувачами. 
  • У результаті майбутні відповіді починаються з точнішої бази, а не знову стикаються з тими самими проблемами.
  • Мета пам’яті полягає в збереженні та повторному використанні неочевидних виправлень, фільтрів та обмежень, які є критично важливими для коректності даних, але які складно вивести лише з інших рівнів. 
  • Наприклад, в одному з випадків агент не знав, як відфільтрувати певний аналітичний експеримент (це залежало від зіставлення з конкретним рядком, визначеним у гейті експерименту). Памʼять була надзвичайно важливою для забезпечення правильної фільтрації, а не нечіткого зіставлення рядків.
• Коли ви надаєте агенту виправлення або коли він виявляє щось нове з вашої розмови, він надішле вам запит на збереження цієї пам'яті для наступного разу. 
  • Користувачі також можуть вручну створювати та редагувати спогади.
  • Спогади охоплюють глобальний та персональний рівні, а інструменти агента дозволяють легко їх редагувати.

• Якщо для таблиці немає попереднього контексту або наявна інформація застаріла, агент може виконувати запити в реальному часі до сховища даних, щоб перевірити та безпосередньо викликати таблицю. Це дозволяє перевіряти схеми, розуміти дані в реальному часі та реагувати відповідним чином.
• Агент також може за потреби взаємодіяти з іншими системами Data Platform (сервіс метаданих, Airflow, Spark), щоб отримати ширший контекст даних, що існує поза сховищем.

Ми щодня запускаємо офлайн-конвеєр, що об'єднує використання таблиць, людські анотації та збагачення на основі Codex в єдине, нормалізоване представлення. Цей збагачений контекст згодом перетворюється на вбудовувані дані за допомогою OpenAI embeddings API⁠(відкривається у новому вікні) і зберігається для подальшого пошуку. Під час виконання запиту агент отримує лише найрелевантніший вбудований контекст за допомогою генерації з доповненням пошуком⁠(відкривається у новому вікні) (RAG) замість сканування необроблених метаданих або журналів. Це забезпечує швидке та масштабоване розуміння навіть десятків тисяч таблиць, при цьому затримка під час виконання залишається передбачуваною та низькою. Запити в режимі реального часу надсилаються до нашого сховища даних за потреби.

Ці шари разом гарантують, що міркування агента базуються на даних, коді та інституційних знаннях OpenAI, що суттєво зменшує кількість помилок і покращує якість відповідей.

Відповіді з одним прикладом працюють, коли проблема зрозуміла, але для більшості запитань ситуація інакша. Найчастіше, щоб отримати правильний результат, потрібні ітеративні уточнення та певне коригування напряму.

Агент створений так, щоб поводитися як товариш по команді, з яким ви можете міркувати. Це розмовний інструмент, що завжди активний і забезпечує як швидкі відповіді, так і поступове дослідження.

Він зберігає повний контекст між взаємодіями, тому користувачі можуть ставити додаткові запитання, уточнювати свій намір або змінювати напрямок без необхідності повторювати все. Якщо агент починає рухатися неправильним шляхом, користувачі можуть перервати аналіз і змінити напрямок, так само як під час роботи з людським колегою, який слухає, а не вперто продовжує.

Коли інструкції нечіткі або неповні, агент ставитиме уточнювальні запитання. Якщо відповідь не буде надано, для продовження роботи будуть застосовані раціональні значення за замовчуванням. Наприклад, якщо користувач запитує про зростання бізнесу без зазначеного діапазону дат, система може припустити, що мова йде про останні 7 або 30 днів. Ці попередні припущення дозволяють системі залишатися чуйною та не блокуватися, водночас наближаючись до правильного результату.

Результат — агент, який добре працює як тоді, коли ви точно знаєте, чого хочете (наприклад, «Розкажи мені про цю таблицю»), так і так само ефективно, коли ви проводите дослідження (наприклад, «Я бачу тут спад: ми можемо виконати деталізацію за типом клієнта та часовими рамками?»). 

Після розгортання ми зауважили, що користувачі часто виконують ті самі аналізи для рутинної повторюваної роботи. Щоб прискорити це, робочі процеси агента об'єднують повторювані аналізи в набори інструкцій, які можна повторно використовувати. Приклади включають робочі процеси для щотижневих бізнес-звітів та перевірку таблиць. Одноразове кодування контексту та найкращих практик спрощує робочі процеси повторного аналізу та забезпечує узгоджені результати для всіх користувачів.

Створення завжди активного агента, що постійно розвивається, означає, що якість може легко покращуватися, і так само легко погіршуватися. Без тісного зворотного зв'язку регресії неминучі та непомітні. Єдиний спосіб масштабувати можливості, не підриваючи довіру, — це систематичне оцінювання.

У цьому розділі ми обговоримо, як ми використовуємо OpenAI Evals API⁠(відкривається у новому вікні) для вимірювання та захисту якості відповідей агента.

Оцінки базуються на ретельно відібраних наборах пар запитань і відповідей. Кожне питання націлене на важливу метрику або аналітичний шаблон, які для нас надзвичайно важливо правильно зрозуміти, у парі з вручну створеним «золотим» SQL-запитом, що дає очікуваний результат. Для кожної оцінки ми надсилаємо запитання природною мовою до кінцевої точки генерації запитів, виконуємо згенерований SQL і порівнюємо отримані дані з результатом очікуваного SQL.

Оцінювання не базується на простому порівнянні рядків. Згенерований SQL може відрізнятися синтаксично, але залишатися правильним, а результати можуть містити додаткові стовпці, які не впливають суттєво на відповідь. Щоб врахувати це, ми порівнюємо як SQL, так і отримані дані, і передаємо ці сигнали до оцінювача OpenAI Evals. Оцінювач формує остаточну оцінку разом із поясненням, охоплюючи як правильність, так і прийнятні варіації.

Ці evals подібні до модульних тестів, які безперервно виконуються під час розробки для виявлення регресій, подібно до «канарок» у продакшні; це дозволяє нам вчасно виявляти проблеми та впевнено вдосконалюватися в міру розширення можливостей агента.

Наш агент безпосередньо підключається до існуючої моделі безпеки та контролю доступу OpenAI. Він функціонує виключно як шар інтерфейсу, успадковуючи та забезпечуючи дотримання тих самих дозволів і засобів захисту, що регулюють дані OpenAI. 

Увесь доступ агента є суворо наскрізним, тобто користувачі можуть лише виконувати запити до таблиць, до яких вони вже мають дозвіл на доступ. Коли доступ відсутній, система позначає це або переходить до альтернативних наборів даних, які користувач має право використовувати.

Крім того, у роботі агента передбачено прозорість. Як і будь-яка система, він може робити помилки. Він розкриває свій процес міркування, підсумовуючи припущення та кроки виконання біля кожної відповіді. Коли запити виконуються, вони безпосередньо пов’язуються з базовими результатами, що дозволяє користувачам переглядати необроблені дані та перевіряти кожен крок аналізу.

Створення нашого агента з нуля дало нам практичні уроки про те, як агенти поводяться, де вони стикаються з труднощами та що насправді робить їх надійними в масштабах.

На початковому етапі ми надали агенту повний набір інструментів, і швидко зіткнулися з проблемами через дублювання функцій. Хоча ця надмірність може бути корисною для конкретних користувацьких випадків і є більш очевидною для людини під час ручного виклику, вона заплутує агентів. Щоб зменшити неоднозначність і підвищити надійність, ми обмежили та об’єднали певні виклики інструментів.

Ми також виявили, що надто детальні інструкції для запитів погіршували результати. Хоча багато запитань мають загальну аналітичну структуру, деталі настільки різняться, що жорсткі інструкції часто спрямовували агента на хибний шлях. Коли ми перейшли до рекомендацій вищого рівня та прийняли рішення покладатися на міркування GPT‑5 для вибору відповідного шляху виконання, агент став більш надійним і почав забезпечувати кращі результати.

Схеми та історія запитів описують форму та використання таблиці, але її справжнє значення міститься в коді, що її створює. Логіка конвеєра фіксує припущення, гарантії актуальності та бізнес-намір, які ніколи не відображаються в SQL або метаданих. Скануючи кодову базу за допомогою Codex, наш агент розуміє, як формуються набори даних, і може краще аналізувати вміст кожної таблиці. Він може відповідати на запитання «що тут є» і «коли я можу це використовувати» значно точніше, ніж лише на основі сигналів сховища. 

Ми постійно працюємо над удосконаленням нашого агента, підвищуючи його здатність обробляти неоднозначні запитання, покращуючи його надійність і точність завдяки більш суворим перевіркам, а також глибше інтегруючи його в робочі процеси. Ми вважаємо, що він має природно інтегруватися в робочий процес людей, а не функціонувати як окремий інструмент.

Хоча наші інструменти й надалі отримуватимуть користь від базових удосконалень у міркуваннях агентів, валідації та самокорекції, місія нашої команди залишається незмінною: безперебійно забезпечувати швидкий і надійний аналіз даних у всій екосистемі даних OpenAI.