- OpenAI membangun sendiri agen data AI kustom untuk menganalisis secara efisien lebih dari 3.500 pengguna internal dan data skala 600 PB
- Hanya dengan pertanyaan dalam bahasa alami, agen ini otomatis menangani workflow analisis end-to-end mulai dari penjelajahan tabel, eksekusi SQL, hingga publikasi notebook dan laporan
- Akurasi dijaga dengan menggabungkan 6 lapisan konteks: penggunaan tabel, anotasi manusia, analisis kode berbasis Codex, pengetahuan organisasi, memori, dan konteks runtime
- Sistem dijalankan dengan struktur closed loop pembelajaran mandiri yang menyelidiki sendiri penyebab kesalahan hasil perantara dan memperbaiki pendekatannya
- Dengan sistem evaluasi terstruktur berbasis Evals API, OpenAI dapat mendeteksi regresi kualitas lebih awal sambil tetap mempertahankan keandalan melalui model keamanan dan perizinan yang sudah ada
Mengapa agen data kustom dibutuhkan
- Platform data OpenAI memiliki lebih dari 3.500 pengguna internal, data skala 600 petabyte, dan lebih dari 70 ribu dataset; bahkan menemukan tabel yang tepat saja sudah menjadi pekerjaan paling menyita waktu dalam analisis
- Banyak tabel yang mirip sehingga sulit memahami perbedaan antartabel, seperti apakah pengguna logout ikut dihitung atau apakah ada duplikasi field
- Bahkan setelah memilih tabel yang benar, many-to-many join, kesalahan filter pushdown, dan null yang tidak ditangani dapat membuat hasil menjadi tidak valid
- Analis seharusnya fokus pada definisi metrik, verifikasi asumsi, dan pengambilan keputusan berbasis data, bukan debugging SQL
Cara kerja agen
- Ditenagai oleh GPT-5.2
- Dapat diakses dari lingkungan yang sudah digunakan karyawan, seperti agen Slack, antarmuka web, IDE, Codex CLI (integrasi MCP), dan aplikasi ChatGPT internal
- Mampu menangani pertanyaan yang kompleks dan terbuka
- Memahami pertanyaan
- Menjelajahi data
- Menjalankan SQL
- Menganalisis dan merangkum hasil secara end-to-end
- Contoh: menganalisis kombinasi pasangan ZIP pickup-dropoff dengan variabilitas waktu perjalanan tertinggi pada dataset taksi NYC
- Tidak mengikuti skrip tetap; agen mengevaluasi progresnya sendiri, dan jika hasil perantara salah (misalnya hasil 0 baris akibat join atau filter yang keliru), agen menyelidiki penyebabnya, memperbaiki pendekatannya, lalu mencoba lagi
- Mencakup seluruh workflow analisis: penemuan data, eksekusi SQL, publikasi notebook dan laporan, referensi pengetahuan internal, pencarian web, dan pembelajaran berbasis memori
Struktur lapisan konteks
-
Layer 1: Penggunaan Tabel (Table Usage)
- Metadata grounding: memanfaatkan metadata skema (nama kolom, tipe data) untuk menulis SQL, serta memahami relasi antartabel melalui lineage tabel (hubungan tabel upstream dan downstream)
- Inferensi kueri: mengumpulkan kueri masa lalu agar agen mempelajari cara menyusun kueri sendiri dan kombinasi tabel yang umumnya di-join
-
Layer 2: Anotasi Manusia (Human Annotations)
- Pakar domain menulis deskripsi yang dikurasi untuk tabel dan kolom, menangkap informasi yang sulit disimpulkan dari skema atau kueri lama seperti tujuan, semantik, konteks bisnis, dan catatan penting yang sudah diketahui
- Karena metadata saja sulit membedakan tabel, pemahaman tentang cara data dibuat dan asalnya menjadi sangat penting
-
Layer 3: Analisis Kode Berbasis Codex (Codex Enrichment)
- Menurunkan definisi level kode dari tabel untuk memahami isi data yang sebenarnya secara mendalam
- Memberikan nuansa berbasis event analitik seperti keunikan nilai, frekuensi pembaruan data tabel, dan cakupan data (apakah field tertentu dikecualikan, tingkat granularitas, dan sebagainya)
- Selain SQL, juga dapat memahami konteks penggunaan di berbagai sistem data seperti Spark dan Python
- Dapat membedakan tabel yang tampak mirip tetapi berbeda secara krusial (misalnya, apakah sebuah tabel hanya berisi traffic ChatGPT 1st-party)
- Konteks ini diperbarui secara otomatis, sehingga tidak memerlukan pemeliharaan manual
-
Layer 4: Pengetahuan Organisasi (Institutional Knowledge)
- Mengumpulkan konteks perusahaan dari Slack, Google Docs, Notion, dan lain-lain, termasuk peluncuran, insiden, codename internal, serta definisi formal dan logika perhitungan untuk metrik inti
- Menjalankan layanan pencarian yang mengumpulkan dokumen, membuat embedding, menyimpannya bersama metadata dan izin, lalu menangani kontrol akses dan caching saat runtime
-
Layer 5: Memori (Memory)
- Saat agen menerima koreksi atau menemukan nuansa dalam pertanyaan data, informasi itu disimpan agar analisis berikutnya dimulai dari baseline yang lebih akurat
- Tujuan memori adalah menyimpan dan menggunakan kembali koreksi, filter, dan batasan yang tidak jelas secara kasatmata serta sulit diinferensikan dari lapisan lain
- Contoh: saat memfilter eksperimen analitik tertentu, ternyata dibutuhkan pencocokan string spesifik yang didefinisikan dalam experiment gate; tanpa memori, agen bisa keliru mencoba fuzzy string matching
- Saat menemukan koreksi atau pembelajaran baru, agen mendorong penyimpanan ke memori, dan pengguna juga bisa membuat serta mengeditnya secara manual
- Cakupan memori dibedakan antara level global dan level personal
-
Layer 6: Konteks Runtime (Runtime Context)
- Jika tidak ada konteks awal untuk tabel atau informasinya sudah usang, agen mengirim live query ke data warehouse untuk memverifikasi skema dan memahami data secara real-time
- Agen juga berkomunikasi dengan sistem lain di Data Platform seperti layanan metadata, Airflow, dan Spark untuk memperoleh konteks data di luar warehouse
-
Pipeline offline harian dan RAG
- Menjalankan pipeline offline harian yang mengagregasikan penggunaan tabel, anotasi manusia, dan pengayaan berbasis Codex ke dalam satu representasi ternormalisasi
- Setelah konteks yang diperkaya diubah menjadi embedding dengan OpenAI Embeddings API dan disimpan, saat kueri masuk sistem menggunakan RAG (Retrieval-Augmented Generation) untuk hanya mengambil konteks yang relevan
- Ini menjaga pemahaman tabel tetap cepat dan skalabel di puluhan ribu tabel, sekaligus mempertahankan latensi runtime yang rendah dan dapat diprediksi
Desain yang berpikir dan berkolaborasi seperti rekan tim
- Mendukung eksplorasi iteratif berbasis percakapan, bukan jawaban sekali jadi, serta mempertahankan konteks lengkap antarturn sehingga tidak perlu menjelaskan ulang dari awal saat ada pertanyaan lanjutan atau perubahan arah
- Jika agen bergerak ke arah yang salah, pengguna dapat turut campur di tengah analisis untuk mengarahkan ulang
- Jika instruksi tidak jelas, agen akan secara proaktif mengajukan pertanyaan klarifikasi, dan bila tidak ada respons, agen melanjutkan dengan default yang masuk akal (misalnya 7 atau 30 hari terakhir)
- Setelah mengamati pola analisis yang dilakukan berulang kali, analisis berulang itu dikemas menjadi workflow (instruction set) yang dapat digunakan kembali
- Contohnya laporan bisnis mingguan dan validasi tabel
- Dengan sekali mengenkode konteks dan best practice, sistem menjamin hasil yang konsisten antar pengguna
Kerangka evaluasi untuk meningkatkan sistem dengan cepat sambil menjaga kepercayaan
- Karena agen selalu berkembang, quality drift dapat dengan mudah terjadi, dan tanpa evaluasi yang sistematis regresi bisa berlangsung tanpa terlihat
- OpenAI membangun kumpulan terkurasi pasangan pertanyaan-jawaban berbasis OpenAI Evals API, dan untuk setiap pertanyaan disiapkan kueri SQL "golden" yang ditulis manual
- Pertanyaan bahasa alami dikirim ke endpoint pembangkitan kueri, SQL yang dihasilkan dijalankan, lalu dibandingkan dengan hasil SQL yang diharapkan
- Bukan sekadar pencocokan string; SQL dan data hasilnya sama-sama dibandingkan lalu dimasukkan ke grader Evals untuk menghasilkan skor akhir dan penjelasan yang mencerminkan akurasi serta variasi yang dapat ditoleransi
- Evaluasi ini berperan sebagai unit test yang terus dijalankan selama pengembangan, sekaligus sebagai canary di production untuk menangkap regresi lebih awal
Keamanan agen
- Terhubung langsung ke model keamanan dan kontrol akses OpenAI yang sudah ada, lalu mewarisi dan menerapkan izin serta guardrail yang sama pada lapisan antarmuka
- Semua akses dilakukan dengan mekanisme pass-through, sehingga pengguna hanya dapat mengueri tabel yang memang sudah mereka miliki izinnya; jika tidak punya akses, agen akan memberi tahu atau fallback ke dataset alternatif
- Demi transparansi, agen membuka proses penalarannya: asumsi dan langkah eksekusi diringkas bersama jawaban, dan hasil mentah dari kueri yang dijalankan ditautkan langsung agar pengguna dapat memverifikasi setiap tahap analisis
Pelajaran dari proses pembangunan
-
Lesson 1: Lebih Sedikit Itu Lebih Baik (Less is More)
- Pada awalnya seluruh set alat diekspos ke agen, tetapi hal ini menimbulkan kebingungan akibat tumpang tindih fungsi
- Fitur redundan yang berguna saat dipanggil manual oleh manusia justru menimbulkan ambiguitas bagi agen, sehingga dengan membatasi dan menyatukan pemanggilan alat tertentu, keandalan meningkat
-
Lesson 2: Pandu Tujuan, Bukan Jalurnya (Guide the Goal, Not the Path)
- Prompting yang terlalu direktif justru menurunkan hasil
- Karena detail tiap pertanyaan berbeda, instruksi yang kaku dapat menyesatkan agen ke jalur yang salah; memberi panduan tingkat tinggi dan menyerahkan pemilihan jalur eksekusi pada penalaran GPT-5 terbukti lebih baik
-
Lesson 3: Makna Ada di Dalam Kode (Meaning Lives in Code)
- Skema dan riwayat kueri hanya menjelaskan bentuk tabel dan cara tabel digunakan, sedangkan makna sebenarnya ada di kode yang membangun tabel tersebut
- Logika pipeline menangkap asumsi, jaminan freshness, dan maksud bisnis yang tidak terlihat di SQL maupun metadata
- Dengan Codex yang merayapi codebase untuk memahami bagaimana dataset benar-benar dibangun, agen dapat menjawab secara akurat "apa isinya" dan "kapan bisa digunakan" dengan cara yang tidak mungkin dicapai hanya dari sinyal warehouse
Arah ke depan
- OpenAI terus mendorong peningkatan kemampuan menangani pertanyaan ambigu, meningkatkan keandalan dan akurasi lewat validasi yang lebih kuat, serta memperdalam integrasi workflow
- Tujuannya adalah bentuk yang menyatu secara alami dengan cara orang sudah bekerja, bukan alat yang terpisah
- Seiring peningkatan teknologi dasar untuk penalaran, validasi, dan koreksi diri agen, sistem ini akan terus berkembang, dan
misi tim adalah menghadirkan analisis data yang cepat dan dapat diandalkan secara mulus di seluruh ekosistem data OpenAI
1 komentar
Komentar Hacker News
Keandalan dan explainability adalah masalah terbesar
Kami sudah 10 tahun mengembangkan analitik bahasa alami di Veezoo, tetapi pendekatan Text-to-SQL yang sederhana tidak skalabel
Saat CFO menanyakan pendapatan, angka yang benar hanya 99% itu tidak ada artinya, dan CFO juga tidak bisa memverifikasi SQL secara langsung
Karena itu kami menambahkan lapisan abstraksi bernama Knowledge Graph, sehingga AI mengubah bahasa alami menjadi bahasa kueri berbasis makna lalu mengompilasikannya secara deterministik ke SQL
Sebaliknya, kueri semantik itu juga bisa diubah kembali menjadi penjelasan bahasa alami agar pengguna mudah memverifikasi apakah hasilnya sesuai dengan maksud mereka
Logika bisnis berada di Knowledge Graph, dan compiler menjamin semua kueri mematuhinya 100%
Struktur lengkapnya dirangkum dalam dokumentasi Arsitektur Veezoo
Yang membuat saya penasaran adalah bagaimana mengelola ledakan kardinalitas, dan bagaimana menangani permintaan multi-kueri yang bergantung pada hasil kueri sebelumnya
Harus bisa dilacak kueri mana yang dipakai pada tanggal tertentu dan bagaimana kueri itu divalidasi
(tentu saja prompt juga harus masuk version control)
Saya terkejut contoh pertama benar-benar tidak logis
Jika ini lolos tinjauan manusia, mungkin itu ditulis AI, dan kalau begitu keandalan sistem ini jadi dipertanyakan
Tautan gambar yang dimaksud
Desktop memakai prompt yang benar,
sedangkan mobile memakai prompt yang salah
Dari pengalaman memakai berbagai sistem BI, menurut saya AI agent seperti ini adalah use case yang sangat pas
BI pada dasarnya memang penuh error di berbagai lapisan — kuerinya sendiri bisa salah, atau cara menafsirkan datanya yang salah
Kalau dua hal itu digabung, kita sebenarnya sudah masuk ke ‘dunia khayalan’, jadi lebih baik AI saja yang menangani tahap pertama
Saya sempat berharap OpenAI sudah memecahkan masalah keandalan ini, tapi sayangnya belum
Tahap 0: datanya disimpan dengan salah
Tahap -1: modelnya sendiri dipahami dengan salah
Tahap -2: proses bisnisnya sudah salah sejak awal
Karena itu saya menyebutnya bukan ‘single source of truth’, melainkan ‘single source of falsehood’
Memperluas kepercayaan adalah bagian yang paling sulit
Kami juga sedang membangun sesuatu yang mirip, dan sebaik apa pun agent loop-nya, pada akhirnya tetap perlu metrik standar yang dikurasi manusia (canonical metrics)
Kalau tidak, pengguna nonteknis akan mengambil keputusan berisiko berdasarkan SQL yang tidak bisa mereka verifikasi
Pendekatan kami adalah
Seiring waktu, sebagian besar kueri akan memakai metrik standar, dan agent berubah dari sekadar generator SQL menjadi smart router dari intent → metrik tervalidasi
Sistem evaluasi golden SQL di bagian “bergerak cepat tanpa merusak kepercayaan” juga memuat insight yang sama
Tulisan terkait dirangkum di postingan blog ini
Jika ada banyak jalur menuju jawaban, hasilnya akan berbeda-beda
LLM sering mengarang metrik tak bermakna seperti ‘xyz_index’, lalu pengguna menganggapnya masuk akal dan langsung memakainya
Menurut saya dampak nyata AI terhadap pekerjaan developer adalah pada kualitas data dan dokumentasi
Seberapa rapi data perusahaan ditata akan menentukan efisiensi pemanfaatan AI
Data publik sudah hampir habis, dan sumber berikutnya adalah dokumentasi internal, repositori kode, dan data lake
Perusahaan yang fondasinya rapi akan bisa membangun dan memelihara layanan baru dengan AI secara cepat dan murah
Sebaliknya, perusahaan dengan dokumentasi dan pengelolaan kode yang berantakan tidak akan bisa membuat AI bekerja dengan baik
Pada akhirnya mereka akan kehilangan pasar ke pesaing
Karena itu saat mencari kerja ke depan, saya berencana selalu menanyakan tingkat pengelolaan dokumentasi, data, dan repositori
Di Amplitude mereka membuat sistem serupa bernama Moda
Beberapa bulan lalu Wade menunjukkan video demo kepada Claire Vo, dan hasilnya benar-benar luar biasa
Saya memakainya setiap hari untuk melempar berbagai pertanyaan
Kami juga menyediakan fungsi serupa di Definite.app dan bisa aktif dalam 5 menit
Tidak perlu Spark atau Snowflake
Data lake, pipeline, semantic layer, dan data agent kami sediakan dalam satu aplikasi
Sebenarnya yang jauh lebih sulit daripada agent itu sendiri adalah membangun infrastruktur data
Kalau agent hanya bisa menulis SQL, batasannya besar, tetapi kami membuat titik balik besar dengan memungkinkan agent mengelola infrastrukturnya sendiri
Isinya sangat bagus
Hanya saja, sepertinya bagian menjelaskan bagaimana hasil itu dihitung masih kurang
Karena ini untuk penggunaan internal OpenAI, asumsi bahwa pengguna bisa membaca SQL mungkin masih masuk akal, tetapi bagi pengguna nonteknis ini adalah tantangan desain yang besar
Begitu pernah menangani sistem data, Anda cepat menyadari bahwa yang penting bukan hanya ‘jawabannya’, tetapi juga ‘bagaimana jawaban itu diperoleh’
Secara pribadi, In-House Data Agent milik Kimi lebih menarik bagi saya
Masalah data bukan masalah teknis, melainkan masalah organisasi
Dalam pengalaman saya, penyebab masalah data bukan ‘pilihan teknologi yang salah’, melainkan keputusan tentang governance dan ownership
Pada akhirnya semuanya bermuara pada Hukum Conway