Saat Claude berubah, semuanya berubah: Mengelola radius ledakan AI dalam produksi
Sistem kami melakukan satu hal, dan berhasil dengan baik: Mengubah pertanyaan bahasa alami menjadi panggilan API. Penggunanya adalah analis, manajer akun, dan pemimpin operasi. Mereka tahu data apa yang mereka perlukan, namun mengumpulkannya secara manual berarti mengambil dari empat dasbor, dua alat BI, dan pembuat laporan Salesforce. Dengan sistem kami, mereka mengetik permintaan dalam bahasa Inggris. Permintaan seperti “Kompilasi laporan volume penjualan untuk bulan Januari hingga Maret 2026 untuk wilayah Timur Laut, dikelompokkan berdasarkan kota” diterjemahkan ke dalam panggilan API yang dapat ditindaklanjuti oleh sistem:json{ “description”: “Volume penjualan yang diminta pengguna untuk rentang tanggal tertentu, berikut adalah panggilan API untuk mendapatkan respons”, “api_call”: “/api/sales_volume”, “post_body”: { “tanggal_mulai”: “01-01-2026”, “tanggal_akhir”: “31-03-2026”, “region”: “northeast” }}Sisa jalur pipa adalah rekayasa konvensional. Sistem mengirimkan panggilan ke backend kanan — kami memiliki integrasi dengan portal pelaporan internal, Salesforce, dan beberapa layanan lokal — menerapkan model bahasa besar (LLM) (yang menghasilkan kueri JSON untuk memfilter dan membentuk respons, dan mengirimkannya melalui email, sebagai dokumen Drive, atau dirender sebagai bagan di browser. Pada pertengahan tahun 2025, sistem menghasilkan beberapa ratus laporan dalam sebulan. Laporan ini digunakan oleh pimpinan dan analis dan diedarkan ke pemangku kepentingan eksternal. Ini telah menjadi cara default yang dilakukan sebagian besar tim data ad-hoc.Kontrak antara LLM dan seluruh sistem adalah objek JSON terstruktur seperti yang dijelaskan dalam contoh di atas.json{ “description”: “Volume penjualan yang diminta pengguna untuk rentang tanggal tertentu, berikut adalah panggilan API untuk mendapatkan respons”, “api_call”: “/api/sales_volume”, “post_body”: { “start_date”: “2026-01-01”, “end_date”: “2026-03-31”, “region”: “northeast” }}Kami membangunnya di Claude Sonnet 3.5 pada awal tahun 2025. Kami meningkatkan ke 3.7 tanpa insiden, dan ke 4.0 tanpa insiden. Pada saat Sonnet 4.5 dikirimkan, kami sudah puas dengan stabilitas dan prediktabilitas LLM dalam memecahkan masalah yang kami yakini sebagai masalah sederhana. Peningkatan model sudah menjadi rutinitas, seperti membuat versi kecil dari perpustakaan yang berperilaku baik. Lalu kami meluncurkan 4.5 Untuk persentase yang berarti permintaan, model mulai melipat konten post_body ke dalam bidang deskripsi. Dua mode kegagalan diikuti. Pertama, parameter filter tidak pernah mencapai API. Sistem kami membaca post_body sebagai sumber kebenaran untuk payload permintaan, dan bidang tersebut kembali kosong. Panggilan API dilakukan tanpa filter rentang tanggal atau wilayah baru. Versi sebelumnya selalu mengambil pendekatan upaya terbaik untuk permintaan yang ambigu dan mengembalikan objek terstruktur. Sonnet 4.5, karena lebih berhati-hati, terkadang merespons dengan pertanyaan. Sistem kami tidak memiliki jalur untuk ini. Sistem kami dibangun dengan asumsi bahwa setiap pemanggilan model akan menghasilkan panggilan API telah: Antara penerapan 4.0 dan 4.5, tim kami telah menambahkan integrasi API baru, yang semuanya memenuhi syarat terhadap 4.5. Mengembalikan model berarti mengkualifikasi ulang semuanya terhadap 4.0 di bawah tekanan waktu. Mengapa disiplin teknik tradisional gagal di sini Rekayasa perangkat lunak bertumpu pada kemampuan untuk membatasi efek perubahan. Saat Anda meningkatkan versi driver atau pustaka, Anda membaca catatan rilis untuk melihat apakah akan terjadi perubahan yang dapat menyebabkan gangguan. Pengujian unit membatasi apa yang mungkin dapat dipindahkan. Sistem yang diubah cukup deterministik sehingga perilakunya dapat diprediksi, atau setidaknya diambil sampelnya dengan cukup padat untuk memberi Anda kepercayaan diri. Radius ledakan dibatasi oleh konstruksi. Sistem yang didukung LLM mematahkan asumsi ini. Komponen yang menghasilkan keluaran Anda tidak berada di bawah kendali Anda. Anda tidak dapat membedakan versi model dari 4.0 ke 4.5. Ini adalah penggantian besar-besaran dari fungsionalitas yang menjadi sandaran sistem Anda. Inilah yang kami maksud dengan radius ledakan tak terbatas: perubahan yang efek hilirnya tidak dapat dihitung sebelumnya karena ruang input (bahasa alami) dan mode kegagalan (apa pun yang mungkin dilakukan model secara berbeda) keduanya tidak dibatasi. Anatomi kegagalan Post-mortem mengungkapkan bahwa perintah kami selalu kurang ditentukan. Kami telah memberi tahu model untuk mengembalikan objek JSON dengan tiga bidang. Kami telah menjelaskan kegunaan setiap bidang. Kami tidak secara eksplisit menyatakan bahwa deskripsi harus berupa string bahasa alami dan tidak boleh berisi representasi serial dari bidang lain. Versi model sebelumnya menyimpulkan batasan ini dari konteks 4.5, jelas lebih baik dalam hal “membantu” dalam pilihan formatnya, memutuskan bahwa meminta klarifikasi atau memberikan isi permintaan dalam deskripsi membuat respons lebih berguna. Dari sudut pandang model, ini adalah interpretasi yang masuk akal atas instruksi yang ambigu. Namun, hal ini melanggar asumsi yang menjadi dasar pembuatan sistem kami. Bugnya tidak ada dalam model. Bugnya ada pada asumsi kami bahwa model akan terus mengisi kesenjangan spesifikasi kami seperti biasanya. Tiga peningkatan yang berhasil telah melatih kami untuk mempercayai kesenjangan tersebut aman.Mode keluaran terstruktur dan API penggunaan alat akan menangkap kegagalan spesifik ini di tingkat skema. Kami tidak menggunakannya untuk alasan teknis di luar cakupan artikel ini. Namun skema hanya membatasi sintaksis, bukan semantik. Skema tidak dapat menentukan bahwa pertanyaan klarifikasi tidak boleh muncul dalam sistem yang tidak memiliki jalur untuk klarifikasi, atau bahwa rentang tanggal tidak boleh default ke sepanjang waktu. Skema menyelesaikan separuh masalah yang lebih mudah.Arsitektur evals-firstDisiplin yang menutup kesenjangan ini adalah perlakukan rangkaian evaluasi – bukan prompt – sebagai spesifikasi formal sistem. Prompt adalah implementasi dari spesifikasi. Model adalah sebuah interpreter. Evals adalah spesifikasi itu sendiri, dan model atau perubahan prompt apa pun valid jika dan hanya jika melewatinya. Dalam praktiknya, eval adalah tripel: Sebuah input, sebuah properti yang harus dipenuhi oleh output, dan sebuah fungsi penilaian test_description_contains_no_serialized_payload(response): desc = respon(“description”).lower() banned = (“curl”, “post_body”, “{“, “http://”, “https://”) menyatakan tidak ada(token dalam desc untuk token dalam terlarang), \ f”description membocorkan konten terstruktur: {response(‘description’)}”Beberapa ratus properti seperti itu, beberapa ditulis dengan tangan untuk invarian yang diketahui penting, beberapa dihasilkan sebagai uji regresi dari lalu lintas produksi nyata, beberapa yang dinilai oleh LLM sebagai juri untuk kualitas yang lebih kabur seperti nada, menjadi sebuah gerbang. Peningkatan model dan perubahan yang cepat harus diperlakukan sebagai permintaan tarik yang harus mengubah rangkaian menjadi hijau sebelum digabungkan. Evaluasi memerlukan biaya yang mahal untuk dibuat dan dipelihara. Evaluasi tersebut akan berubah seiring dengan perubahan produk Anda. Penilaian LLM sebagai juri memperkenalkan variasi tersendiri dalam hasil pelajaran ini dengan cara yang sulit: Tidak ada seorang pun di tim kami yang pernah menulis pernyataan yang mengatakan “bidang deskripsi tidak boleh berisi perintah curl,” karena tidak ada yang berpikir model akan menempatkannya di sana. Eval bukanlah solusi yang tepat. Eval memberi Anda kemampuan untuk membatasi radius ledakan perubahan dengan satu-satunya cara yang tersedia ketika fungsi dasarnya adalah kotak hitam: Dengan mengambil sampel secara padat dari respons input-output yang benar-benar Anda pedulikan, dan menolak untuk diterapkan ketika perilaku tersebut bergerak. Peta jalan Komunitas teknik belum mengembangkan kumpulan pengetahuan untuk menulis evaluasi yang efektif. Tidak ada standar yang diterima secara luas tentang arti ‘cakupan’ dalam ruang masukan bahasa alami. Sistem CI/CD tidak dibangun untuk mengukur hasil pengujian probabilistik. Ketika agen melakukan pekerjaan yang lebih mandiri — menulis kode, memindahkan uang, menjadwalkan perubahan infrastruktur — kesenjangan antara “model lulus uji asap” dan “kita tahu apa yang akan dilakukan sistem ini dalam produksi” menjadi masalah rekayasa utama dalam beberapa tahun ke depan. Tim yang menutup kesenjangan tersebut adalah tim yang berhenti menganggap evaluasi sebagai renungan jaminan kualitas. dan mulai memperlakukannya sebagai spesifikasi sebenarnya dari sistem mereka.Vijay Sagar Gullapalli adalah Insinyur AI Pendiri di Adopt AI dan penemu yang dipatenkan USPTO.Sarat Mahavratayajula adalah Insinyur Perangkat Lunak Senior di Sherwin-Williams. Selamat datang di komunitas VentureBeat!Program posting tamu kami adalah tempat para pakar teknis berbagi wawasan dan memberikan penjelasan mendalam yang netral dan tidak terikat pada AI, infrastruktur data, keamanan siber, dan teknologi mutakhir lainnya yang membentuk masa depan perusahaan.Baca lebih banyak dari program kiriman tamu kami — dan lihat pedoman kami jika Anda tertarik untuk menyumbangkan artikel Anda sendiri!
Diterbitkan : 2026-06-06 04:00:00
sumber : venturebeat.com
