DevOps dengan AI dan LLMOps: dari pipeline ke model yang dapat berbicara.

Informatec Digital » Sumber daya » DevOps dengan AI dan LLMOps: dari pipeline ke model yang dapat berbicara.

Munculnya AI generatif dan model bahasa berskala besar telah sepenuhnya mengubah cara perangkat lunak dibangun, diterapkan, dan dioperasikan. Memiliki barang-barang bagus saja tidak lagi cukup. Pipeline DevOps juga bukan dengan menerapkan MLOps klasikKetika Anda memasukkan LLM ke dalam persamaan, Anda memasuki ranah di mana model tersebut berbicara, bernalar, berimprovisasi, dan terkadang berperilaku dengan cara yang tidak terduga.

Dalam skenario baru ini, Tim perlu menggabungkan DevOps, AI, dan LLMOps untuk mengatur seluruh siklus hidup aplikasi berbasis LLM.Mulai dari eksperimen dan rekayasa cepat hingga penerapan, pemantauan, keamanan, dan optimalisasi biaya, artikel ini menyederhanakan semua kerumitan tersebut dan memandu Anda langkah demi langkah tentang cara mengintegrasikan ChatOps, DevOps, MLOps, GenAIOps, dan LLMOps ke dalam operasi modern.

Dari DevOps dan MLOps ke LLMOps: mengapa modelnya tidak lagi statis

Selama bertahun-tahun, prioritas tim teknik adalah mengotomatiskan pengiriman perangkat lunak dan mengurangi gesekan antara pembangunan dan infrastruktur.Maka lahirlah DevOps: integrasi berkelanjutan, penerapan berkelanjutan, infrastruktur sebagai kode, observabilitas, dan budaya kolaboratif yang menghilangkan proses serah terima yang tak berujung antar departemen.

Ketika data menjadi bagian dari produk, hal itu muncul. MLOps sebagai respons terhadap kebutuhan akan reproduksibilitas dan ketertelusuran model pembelajaran mesin.Praktik-praktik seperti pembuatan versi dataset, orkestrasi pipeline pelatihan, deteksi pergeseran, dan evaluasi berkelanjutan model prediktif telah distandarisasi.

Masalahnya adalah itu LLM mematahkan banyak asumsi yang tersirat dalam DevOps dan MLOps.Ini bukan API statis atau fungsi sederhana yang mengembalikan angka deterministik: mereka merespons dalam bahasa alami, menggabungkan konteks, instruksi, alat, dan data secara real-time, dan dapat menghasilkan dua keluaran berbeda untuk masukan yang sama.

Ini menyiratkan itu Tidak cukup hanya mengubah model dan bobotnya.Selain itu, perlu juga untuk mengontrol perintah, templat, kebijakan keamanan semantik, pembatasan, alat yang terhubung, konteks yang disuntikkan, dan bahkan aturan bisnis yang memengaruhi perilaku sistem.

Apa itu LLMOps dan apa sebenarnya yang dipecahkan oleh LLMOps?

Kita dapat melihat LLMOps sebagai Kerangka kerja operasional yang memungkinkan penerapan, pemeliharaan, dan penskalaan aplikasi berbasis LLM secara aman, terkontrol, dan berkelanjutan.Ini adalah payung yang menaungi praktik DevOps, MLOps, dan kemampuan baru yang spesifik untuk model generatif.

Intinya, LLMOps lebih berfokus pada mengatur perilakunya di lingkungan produksi daripada "melatih model yang sempurna".Ini mencakup bagaimana alur permintaan dirancang dan dikelola versinya, bagaimana LLM terhubung ke sumber data internal, bagaimana biaya token dan latensi dipantau, dan bagaimana risiko semantik dikelola (halusinasi, kebocoran informasi, bias, respons negatif, dll.).

Kebutuhan yang ditangani oleh LLMOps, dan yang tidak dapat dipenuhi oleh DevOps/MLOps saja, meliputi: berbagai aspek seperti keterlacakan percakapan, evaluasi otomatis kualitas respons, atau perbandingan A/B dari varian perilaku.Kita tidak hanya berbicara tentang akurasi klasik, tetapi juga konsistensi, keselarasan dengan bisnis, dan keamanan.

Selain itu, Biaya tidak lagi terbatas pada pelatihan dan hosting model tersebut.Setiap perintah, setiap konteks yang diperluas, dan setiap panggilan bersamaan memicu konsumsi GPU atau token dalam API komersial. Tanpa lapisan LLMOps untuk membuat konsumsi ini terlihat dan menghubungkannya dengan peralatan, layanan, dan kasus penggunaan, tagihan akan meningkat secara tidak terduga.

ChatOps + LLMOps + DevOps: operasi menjadi percakapan

Salah satu tren yang paling berpengaruh adalah Integrasi ChatOps dan LLMOps dalam budaya DevOps.Alih-alih terbatas pada dasbor, skrip, dan alur kerja, tim mulai mengoperasikan sebagian besar sistem dari saluran obrolan seperti Slack, Microsoft Teams, atau Discord.

ChatOps mengusulkan agar operasi harian (deployment, kueri log, reboot, perubahan konfigurasi) dieksekusi oleh bot di dalam saluran komunikasi itu sendiriSecara transparan kepada seluruh tim. Setiap perintah, tindakan, dan hasil dicatat dalam percakapan.

Ketika LLM ditambahkan ke pendekatan tersebut, lapisan kecerdasan baru pun muncul: Chatbot yang memahami bahasa alami, menafsirkan maksud, dan dapat mengeksekusi perintah kompleks atau menganalisis situasi. tanpa operator perlu mengingat setiap skrip atau flag secara tepat.

Contoh umum dari konvergensi ini meliputi bahwa Sebuah bot, yang didukung oleh LLM, membaca metrik Prometheus dan log Loki. Ketika seseorang menulis "layanan grup X lambat" dan menyarankan tindakan seperti meningkatkan replika, melakukan rollback, atau meluncurkan pengujian spesifik, semuanya dijelaskan dalam bahasa alami.

Pada tingkat budaya dan operasional, hal ini diterjemahkan menjadi Pengambilan keputusan yang lebih cepat, pengurangan intervensi manual dalam tugas-tugas berulang, dan pengalaman yang lebih lancar bagi tim DevOps.yang beralih dari terus-menerus memadamkan masalah mendesak menjadi mengerjakan peningkatan strategis.

Prinsip-prinsip utama siklus hidup LLM dalam produksi

Menjalankan program LLM yang serius bukanlah proyek sekali jalan, melainkan sebuah proses berkelanjutan. sebuah siklus yang berulang dan di mana setiap perubahan dapat mengubah perilaku sistem.Meskipun setiap organisasi menyesuaikannya dengan realitasnya sendiri, biasanya ada enam tahapan utama yang saling berkaitan.

Yang pertama adalah fase pelatihan atau adaptasi modelHal ini dapat berkisar dari menggunakan model dasar apa adanya hingga menerapkan fine-tuning, LoRa, atau teknik tuning lainnya dengan data Anda sendiri. Yang penting di sini bukan hanya performa, tetapi juga meninggalkan catatan lengkap: dataset, filter yang diterapkan, hyperparameter, versi tokenizer, arsitektur yang diuji, dll.

Jika fase ini dilakukan secara improvisasi dan tidak didokumentasikan, Model ini lahir tanpa tata kelola.Setelah itu, akan hampir tidak mungkin untuk menjelaskan mengapa sistem tersebut merespons seperti itu atau untuk mengulangi hasil tertentu ketika dibutuhkan dalam audit.

Tahap kedua adalah penerapan, di mana model meninggalkan laboratorium dan memasuki produksi. Di LLMOps, ini bukan hanya tentang "memasukkannya ke dalam kontainer": Kita harus memutuskan perangkat keras apa yang harus digunakanBagaimana mengelola memori untuk konteks yang berjalan lama, topologi klaster mana yang harus diterapkan, dan bagaimana melakukan penskalaan berdasarkan lalu lintas. tanpa peningkatan latensi yang drastis atau biaya yang menjadi tidak terjangkau.

Di situlah segala sesuatunya mulai berperan. pemantauan berkelanjutan yang berorientasi pada perilakuTidak cukup hanya melihat CPU dan RAM; perlu juga memantau kualitas semantik respons, stabilitas gaya, tingkat kesalahan, evolusi biaya per token, munculnya respons yang berbahaya atau tidak koheren, dan perubahan waktu respons di bawah pola penggunaan yang berbeda.

Pada fase selanjutnya, dilakukan tugas optimasi dan penyempurnaan: perintah sentuh, sesuaikan RAG, uji varian model, kuantisasi, lakukan pengujian A/B, ubah kebijakan keamanan semantik, atau perbaiki aturan bisnis.Ini adalah proses yang hampir seperti kerajinan tangan, di mana data, teknik, dan bisnis duduk bersama untuk memutuskan apa yang harus diprioritaskan.

Pada akhirnya, semua ini termasuk dalam lapisan keamanan dan tata kelola (kontrol akses, audit, pencegahan kebocoran, batasan penggunaan, kepatuhan terhadap peraturan) dan dalam logika pembaruan berkelanjutan, di mana model dan ekosistemnya disesuaikan dengan perubahan data, peraturan, dan kebutuhan internal.

GenAIOps dan pendekatan alur notifikasi di Azure

Dalam lingkup LLMOps, terdapat proposal yang sangat spesifik untuk menyusun siklus hidup ini. Salah satu yang paling maju di lingkungan korporat adalah GenAIOps dengan alur kerja yang cepat pada Azure Machine Learning yang terintegrasi dengan Azure DevOpsyang mengusulkan pendekatan yang sangat sistematis untuk membangun aplikasi berbasis LLM.

Alur perintah bukan hanya editor perintah; ini adalah Platform lengkap untuk mendesain, menguji, membuat versi, dan menerapkan alur interaksi LLM.Mulai dari kasus sederhana (satu perintah) hingga orkestrasi kompleks dengan banyak node, alat eksternal, kontrol, dan evaluasi otomatis.

Salah satu fitur pentingnya adalah... repositori terpusat untuk aliran datayang berfungsi sebagai perpustakaan perusahaan. Alih-alih setiap tim memiliki petunjuk mereka dalam dokumen terpisah atau repositori mereka sendiri, semuanya dikonsolidasikan ke dalam satu repositori terkelola, dengan cabang, revisi, dan riwayat yang jelas.

Selain itu, platform ini menambahkan kemampuan eksperimen varian dan hyperparameter: Dimungkinkan untuk menguji berbagai kombinasi perintah, model, pengaturan suhu, atau kebijakan keamanan. pada beberapa titik dalam alur dan bandingkan hasilnya dengan metrik yang jelas.

Terkait penerapan, GenAIOps dengan alur notifikasi. Ini menghasilkan image Docker yang mencakup alur kerja dan sesi proses.Ini siap dijalankan di lingkungan seperti Azure App Services, Kubernetes, atau proses terkelola. Dari dasar ini, penerapan A/B diaktifkan untuk membandingkan versi alur kerja di lingkungan dunia nyata.

Keunggulan lainnya adalah pengelolaan hubungan antara kumpulan data dan alur kerja. Setiap alur evaluasi dapat bekerja dengan beberapa dataset standar dan dataset uji.Hal ini memungkinkan validasi perilaku dalam berbagai skenario sebelum menyerahkan sesuatu kepada pengguna akhir.

Platform ini juga secara otomatis mendaftarkan versi baru dari dataset dan alur kerja hanya ketika ada perubahan aktual, dan Aplikasi ini menghasilkan laporan komprehensif dalam format seperti CSV dan HTML. untuk mendukung keputusan yang didasarkan pada data, bukan intuisi.

Empat fase GenAIOps dengan alur notifikasi.

Pendekatan GenAIOps membagi siklus hidup menjadi empat tahap yang jelas berbeda, yang membantu menghindari kekacauan umum "kita mencoba berbagai hal dengan AI dan melihat apa yang terjadi".

Fase pertama, inisialisasi, berfokus pada Definisikan tujuan bisnis secara tepat dan kumpulkan contoh data yang representatif.Di sini, struktur dasar alur prompt diuraikan dan arsitekturnya dirancang, yang kemudian akan disempurnakan.

Pada fase eksperimen, alur tersebut diterapkan pada data sampel tersebut dan Berbagai varian perintah, model, dan konfigurasi dievaluasi.Proses ini diulang terus menerus hingga ditemukan kombinasi yang dapat diterima yang memenuhi standar kualitas dan konsistensi minimum.

Selanjutnya adalah fase evaluasi dan penyempurnaan, di mana Kumpulan data yang lebih besar dan lebih beragam digunakan untuk melakukan uji perbandingan yang ketat.Hanya ketika alur kerja menunjukkan kinerja yang konsisten sesuai dengan standar yang telah ditetapkan, barulah alur kerja tersebut dianggap siap untuk langkah selanjutnya.

Terakhir, pada fase implementasi, alur dioptimalkan agar efisien dan diterapkan di lingkungan produksi. termasuk opsi penerapan A/B, pemantauan, pengumpulan umpan balik pengguna, dan siklus peningkatan berkelanjutan.Tidak ada yang pasti: alur kerja terus disesuaikan berdasarkan apa yang diamati dalam penggunaan nyata.

Metodologi ini dikemas dalam templat repositori GenAIOps, dengan pipeline yang sudah dibangun sebelumnya dan berbasis kode, serta Alat eksekusi berbasis lokal dan cloud untuk mengembangkan, mengevaluasi, dan menyebarkan aplikasi berbasis LLM. tanpa harus menciptakan kembali hal yang sudah ada di setiap proyek.

Integrasi dengan Azure DevOps: repositori, pipeline, dan autentikasi

Untuk mewujudkan GenAIOps dari teori ke organisasi nyata, mengintegrasikannya dengan Azure DevOps adalah kuncinya. Templat tipikal dimulai dengan Repositori di Azure Repos dengan dua cabang utama, main dan development.yang mencerminkan lingkungan dan strategi promosi kode yang berbeda.

Repositori sampel dikloning dari GitHub, dikaitkan dengan Azure Repos, dan Kami biasanya bekerja dengan membuat feature branch dari pengembangan.Perubahan dikirim melalui pull request, yang secara otomatis memicu alur kerja validasi dan eksperimen.

Agar Azure DevOps dapat berinteraksi dengan Azure Machine Learning dan layanan lainnya, maka perlu dikonfigurasi. entitas layanan di Azure sebagai identitas teknisIdentitas ini digunakan dalam koneksi layanan Azure DevOps, sehingga pipeline diautentikasi tanpa mengekspos kunci dalam bentuk teks biasa.

Biasanya, entitas ini memiliki izin Pemilik pada langganan ML atau sumber daya kerja, sehingga Pipeline dapat menyediakan titik akhir, mendaftarkan model, dan memperbarui kebijakan di penyimpanan kunci.Jika Anda ingin memperkuat keamanan, Anda dapat menyesuaikan peran menjadi Kontributor dengan mengadaptasi langkah-langkah YAML yang menangani izin.

Selain itu, sekelompok variabel dibuat di Azure DevOps yang Sistem ini menyimpan data sensitif seperti nama koneksi layanan atau pengidentifikasi sumber daya.Variabel-variabel ini diekspos sebagai lingkungan ke dalam pipeline, sehingga menghindari penulisan informasi penting secara langsung dalam kode.

Mengonfigurasi repositori lokal dan jarak jauh memungkinkan Anda untuk Cabang pengembangan dilindungi dengan kebijakan cabang. yang memerlukan eksekusi pipeline pull request sebelum mengizinkan penggabungan. Pipeline ini menangani validasi build dan alur eksperimen, mencegah perubahan yang merusak agar tidak dimasukkan.

Begitu kode memasuki tahap pengembangan, sebuah pipeline pengembangan akan dipicu. Ini mencakup fase lengkap CI dan CD.Melakukan eksperimen dan evaluasi, merekam alur kerja di registri model Azure ML, menerapkan endpoint dan smoke test, serta mengintegrasikan pada endpoint yang baru dibuat.

Pola yang sama terulang di seluruh versi atau cabang rilis, yang terhubung ke lingkungan produksi. Di sana, Pipeline CI/CD untuk produksi mengulangi siklus eksperimen, evaluasi, dan penerapan.tetapi pada data tingkat infrastruktur dan produksi, dengan kontrol yang lebih besar dan tinjauan manual tambahan jika diperlukan.

Detail penting yang perlu diperhatikan adalah "peninjauan oleh manusia" yang termasuk dalam alur kerja ini: Setelah fase CI, CD tetap terkunci hingga seseorang menyetujuinya secara manual. Kelanjutan proses berasal dari antarmuka Azure Pipelines. Jika tidak disetujui dalam waktu tertentu (misalnya, 60 menit), eksekusi akan ditolak.

Implementasi lokal dan koneksi dengan penyedia LLM

Tidak semuanya berpusat pada pipeline: GenAIOps juga mendukung eksekusi lokal untuk eksperimen cepatAnda dapat mengklon repositori templat, membuat file .env di direktori root, dan menentukan koneksi ke Azure OpenAI atau titik akhir kompatibel lainnya di dalamnya.

Koneksi ini mencakup parameter seperti api_key, api_base, api_type, dan api_version, dan Mereka dirujuk berdasarkan nama di dalam alur. (misalnya, koneksi bernama "aoai" dengan versi API tertentu). Dengan cara ini, alur yang sama dapat dieksekusi secara lokal dan di cloud tanpa perubahan pada kode.

Untuk menggunakan mode ini, cukup Buat lingkungan virtual atau gunakan conda dan instal dependensi yang diperlukan. (promptflow, promptflow-tools, promptflow-sdk, openai, jinja2, python-dotenv, dll.). Dari sana, Anda dapat menulis skrip pengujian di folder eksekusi lokal dan menjalankan eksperimen pada alur yang telah ditentukan.

Dualitas cloud/on-premises ini sangat cocok dengan pola pikir DevOps yang matang: Ini diuji dalam skala kecil secara lokal, divalidasi secara formal dalam alur kerja, dan kemudian dipromosikan ke lingkungan tingkat yang lebih tinggi dengan kontrol dan audit.Semua kontrol versi dilakukan di Git dan terhubung ke Azure DevOps.

Alat-alat umum dalam ekosistem DevOps dengan AI dan LLMOps

Di luar penawaran spesifik Azure, ekosistem DevOps modern dengan AI dan LLMOps biasanya bergantung pada seperangkat alat yang mencakup ChatOps, orkestrasi model, pemantauan, dan observabilitas..

Pada lapisan ChatOps, hal yang umum dilakukan adalah menggabungkan Gunakan Slack dengan bot seperti Hubot.Microsoft Teams dengan agen berbasis Power Virtual Agents, atau Discord bersama dengan kerangka kerja seperti Botpress atau Rasa untuk membangun asisten khusus yang terhubung dengan alur kerja, sistem pemantauan, dan layanan internal.

Dalam bidang LLMOps/MLOps, hal tersebut sering terjadi. platform seperti Kubeflow dan MLflow untuk mengelola pipeline, catatan model, dan eksperimen, serta alat-alat khusus seperti Weights & Biases (W&B) untuk pelacakan metrik tingkat lanjut, perbandingan hasil, atau visualisasi mendalam.

Untuk membangun aplikasi di LLM, hal yang umum digunakan adalah... kerangka kerja seperti LangChain atau pustaka tipe OpenLLM.Solusi-solusi ini memfasilitasi perakitan rantai perintah, konektor ke data eksternal, alat, dan agen multi-langkah. Secara bersamaan, solusi untuk observabilitas khusus LLM sedang muncul, memungkinkan pemantauan perintah, respons, biaya, dan kualitas.

Dalam integrasi dengan DevOps klasik, alat-alat seperti Jenkins atau GitLab CI tetap relevan untuk bagian CI/CD, Kubernetes dan ArgoCD untuk penerapan cloud-native berkelanjutan.dan platform pengamatan seperti Prometheus, Grafana, dan Loki untuk metrik, dasbor, dan log.

Tantangan, keterbatasan, dan adopsi progresif

Semua penerapan praktik dan alat ini tidak gratis. Kompleksitas dalam mengelola perintah, versi model, dan varian alur. cukup besar, terutama ketika beberapa tim bekerja secara bersamaan —skenario di mana disarankan untuk menerapkan strategi seperti GitOps untuk mengkoordinasikan perubahan dan penerapan.

Selain itu, bot ChatOps dan LLM itu sendiri memiliki kemampuan untuk bertindak. Hal itu menimbulkan risiko keamanan yang cukup besar. jika mereka memiliki izin yang berlebihan di lingkungan produksi atau jika permukaan paparan data tidak dikontrol dengan benar.

Ditambah dengan hal ini adalah ketergantungan pada model sumber terbuka dengan lisensi sensitif atau API komersial yang dapat mengubah kondisi, harga, atau batasan. Dan, yang lebih buruk lagi, evaluasi yang kuat terhadap LLM dalam produksi masih merupakan area terbuka, dengan banyak pertanyaan yang masih belum terjawab.

Oleh karena itu, masuk akal untuk membahas penerapan LLMOps dan ChatOps dalam DevOps. dengan cara yang progresif dan terkontrol., dimulai dengan mengotomatiskan tugas-tugas berulang dengan bot sederhana (reboot, kueri log, pemberian tag pada build, dll.).

Nantinya, mereka bisa diperkenalkan. LLM untuk tugas dukungan, klasifikasi insiden, atau bantuan debugging.Sebagai contoh, dengan menjelaskan kesalahan berdasarkan log atau mengusulkan solusi berdasarkan dokumentasi internal.

Setelah operasi ML klasik stabil, saatnya untuk mengatasi LLMOps dengan model bahasa khusus untuk domain seperti layanan pelanggan, DevSecOps, atau QA, memanfaatkan semua yang telah dipelajari pada fase-fase sebelumnya.

Cakrawala yang dituju oleh semua praktik ini adalah lingkungan rekayasa yang bersifat percakapan, prediktif, dan semakin otonom.di mana sebagian besar pengembangan dan pengoperasian diungkapkan dalam bahasa alami dan AI membantu membuat keputusan proaktif tentang penerapan, penskalaan, atau pengembalian versi sebelumnya.

Dengan adanya konsep-konsep ini—DevOps, ChatOps, MLOps, GenAIOps, dan LLMOps—organisasi memiliki Kerangka kerja yang solid untuk membangun dan mempertahankan sistem berbasis LLM yang benar-benar memberikan nilai.Mempertahankan kendali atas kualitas, biaya, keselamatan, dan keselarasan dengan bisnis, alih-alih hanya menggunakan prototipe sederhana atau pengujian terisolasi yang langsung gagal begitu memasuki tahap produksi.