AI merusak tumpukan data. Sebagian besar perusahaan menghabiskan dekade terakhir untuk membangun tumpukan data yang canggih. Alur ETL memindahkan data ke gudang. Lapisan transformasi membersihkan data untuk analitik. Alat BI menampilkan wawasan kepada pengguna. Arsitektur ini berfungsi untuk analitik tradisional. Tetapi AI menuntut sesuatu yang berbeda. Itu membutuhkan loop umpan balik yang berkelanjutan. Ini membutuhkan penyematan real-time & pengambilan konteks. Pertimbangkan pelanggan di ATM yang menarik uang saku. Agen AI di aplikasi seluler mereka perlu mengetahui tentang transaksi $40 itu dalam hitungan detik. Akurasi & kecepatan data bukanlah opsional. Netflix membangun kembali seluruh infrastruktur rekomendasi mereka untuk mendukung pembaruan model real-time1. Stripe menciptakan pipeline terpadu tempat data pembayaran mengalir ke model penipuan dalam milidetik2. Tumpukan AI modern membutuhkan arsitektur yang berbeda secara fundamental. Data mengalir dari beragam sistem ke dalam database vektor, di mana penyematan & data dimensi tinggi hidup bersama data terstruktur tradisional. Basis data konteks menyimpan pengetahuan kelembagaan yang menginformasikan keputusan AI. Sistem AI mengonsumsi data ini, lalu memasuki loop eksperimen. GEPA & DSPy memungkinkan pengoptimalan evolusioner di berbagai dimensi kualitas. Evaluasi mengukur kinerja. Pembelajaran penguatan melatih agen untuk menavigasi lingkungan perusahaan yang kompleks. Mendasari semuanya adalah lapisan observabilitas. Seluruh sistem membutuhkan data yang akurat & cepat. Itu sebabnya observabilitas data juga akan menyatu dengan observabilitas AI untuk memberikan insinyur data & insinyur AI pemahaman menyeluruh tentang kesehatan saluran mereka. Infrastruktur data & AI tidak konvergen. Mereka sudah menyatu. Referensi Blog Teknologi Netflix. (2025, Agustus). "Dari Fakta & Metrik hingga Pembelajaran Mesin Media: Mengembangkan Fungsi Rekayasa Data di Netflix." ↩︎ Stripe. (2025). "Bagaimana Kami Membangunnya: Radar Garis." ↩︎

Tentang bagaimana kami menggunakan AI & @lancedb secara internal!

Saya menemukan bahwa saya mendesain alat AI saya secara terbalik. Berikut contohnya. Ini adalah rantai pemrosesan buletin saya: membaca email, memanggil pemroses buletin, mengekstrak perusahaan, dan kemudian menambahkannya ke CRM. Ini melibatkan empat langkah berbeda, dengan biaya $3.69 untuk setiap seribu buletin yang diproses. Sebelum: Rantai Pemrosesan Buletin (gambar pertama) Kemudian saya membuat alat buletin terpadu yang menggabungkan semuanya menggunakan Google Agent Development Kit, kerangka kerja Google untuk membangun alat agen AI tingkat produksi: (gambar kedua) Mengapa alat buletin terpadu lebih rumit? Ini mencakup beberapa tindakan dalam satu antarmuka (proses, pencarian, ekstrak, validasi), mengimplementasikan manajemen status yang melacak pola penggunaan & hasil cache, memiliki pembatasan kecepatan bawaan, & menghasilkan output JSON terstruktur dengan metadata alih-alih teks biasa. Tapi inilah bagian yang berlawanan dengan intuisi: meskipun lebih kompleks secara internal, alat terpadu lebih mudah digunakan oleh LLM karena memberikan output yang konsisten dan terstruktur yang lebih mudah diuraikan, meskipun output tersebut lebih panjang. Untuk memahami dampaknya, kami menjalankan pengujian 30 iterasi per skenario pengujian. Hasilnya menunjukkan dampak arsitektur baru : (gambar ketiga) Kami dapat mengurangi token sebesar 41% (p=0,01, signifikan secara statistik), yang diterjemahkan secara linier menjadi penghematan biaya. Tingkat keberhasilan meningkat sebesar 8% (p = 0,03), & kami dapat mencapai cache 30% dari waktu, yang merupakan penghematan biaya lainnya. Sementara alat individu menghasilkan respons yang lebih pendek dan "lebih bersih", mereka memaksa LLM untuk bekerja lebih keras mengurai format yang tidak konsisten. Output terstruktur dan komprehensif dari alat terpadu memungkinkan pemrosesan LLM yang lebih efisien, meskipun lebih lama. Alur kerja saya mengandalkan lusinan alat Ruby khusus untuk email, penelitian, & manajemen tugas. Setiap alat memiliki antarmuka, penanganan kesalahan, & format keluarannya sendiri. Dengan menggulungnya menjadi alat meta, kinerja akhir lebih baik, & ada penghematan biaya yang luar biasa. Anda dapat menemukan arsitektur lengkap di GitHub.