DevOps dengan AI dan LLMOps: daripada saluran paip kepada model yang bersuara

Informatec Digital » Sumber » DevOps dengan AI dan LLMOps: daripada saluran paip kepada model yang bersuara

Ketibaan AI generatif dan model bahasa yang besar telah mengubah sepenuhnya cara perisian dibina, digunakan dan dikendalikan. Mempunyai saluran DevOps yang baik atau menggunakan MLOp klasik tidak lagi mencukupi : apabila anda memperkenalkan LLM ke dalam persamaan, anda memasuki alam di mana model tersebut bercakap, membuat penaakulan, berimprovisasi dan kadangkala bertindak dengan cara yang tidak dapat diramalkan.

Dalam landskap baharu ini, pasukan perlu menggabungkan DevOps, AI dan LLMOps untuk mengurus keseluruhan kitaran hayat aplikasi berasaskan LLM , daripada eksperimen dan kejuruteraan segera kepada penggunaan, pemantauan, keselamatan dan pengoptimuman kos. Artikel ini menjelaskan kerumitan dan membimbing anda melalui, langkah demi langkah, cara mengintegrasikan ChatOps, DevOps, MLOps, GenAIOps dan LLMOps ke dalam operasi moden.

Daripada DevOps dan MLOps kepada LLMOps: mengapa model tidak lagi statik

Selama bertahun-tahun, pasukan kejuruteraan mengutamakan pengautomasikan penyampaian perisian dan mengurangkan geseran antara pembangunan dan infrastruktur . Ini membawa kepada kelahiran DevOps: integrasi berterusan, penggunaan berterusan, infrastruktur sebagai kod, kebolehcerapan dan budaya kolaboratif yang menghapuskan penyerahan tanpa henti antara jabatan.

Apabila data menjadi sebahagian daripada produk, MLOp muncul sebagai tindak balas kepada keperluan untuk kebolehulangan dan kebolehkesanan model pembelajaran mesin . Amalan seperti versi set data, orkestrasi saluran latihan, pengesanan hanyutan dan penilaian berterusan model ramalan telah diseragamkan.

Masalahnya ialah LLM memecahkan banyak andaian tersirat dalam DevOps dan MLOps . Ia bukanlah API statik atau fungsi mudah yang mengembalikan nombor deterministik: ia bertindak balas dalam bahasa semula jadi, menggabungkan konteks, arahan, alatan dan data masa nyata dan boleh menghasilkan dua output berbeza untuk input yang sama.

Ini bermakna bahawa tidak mencukupi untuk mengubah versi model dan pemberatnya ; ia juga perlu untuk mengawal gesaan, templat, dasar keselamatan semantik, sekatan, alat yang disambungkan, konteks yang disuntik dan juga peraturan perniagaan yang mengkondisikan tingkah laku sistem.

Apakah LLMOps dan apakah yang sebenarnya diselesaikannya?

Kita boleh melihat LLMOps sebagai rangka kerja operasi yang membolehkan penggunaan, penyelenggaraan dan penskalaan aplikasi berasaskan LLM yang selamat, terkawal dan mampan . Ia merupakan payung di mana amalan DevOps, MLOps dan keupayaan baharu khusus untuk model generatif wujud bersama.

Pada dasarnya, LLMOps kurang menumpukan pada "melatih model yang sempurna" dan lebih kepada mengawal tingkah lakunya dalam pengeluaran . Ini termasuk cara aliran gesaan direka bentuk dan diversikan, cara LLM bersambung dengan sumber data dalaman, cara kos token dan kependaman dipantau dan cara risiko semantik (halusinasi, kebocoran maklumat, bias, tindak balas toksik, dll.) diuruskan.

Keperluan yang ditangani oleh LLMOps, dan yang tidak dapat dipenuhi oleh DevOps/MLOps sahaja, merangkumi aspek yang pelbagai seperti kebolehkesanan perbualan, penilaian automatik kualiti respons dan ujian A/B varian tingkah laku . Kita bukan sahaja bercakap tentang ketepatan klasik, tetapi juga konsistensi, penjajaran dengan perniagaan dan keselamatan.

Tambahan pula, kos tidak lagi terhad kepada latihan model dan pengehosan : setiap gesaan, setiap konteks lanjutan dan setiap panggilan serentak mencetuskan penggunaan GPU atau token pada API komersial. Tanpa lapisan LLMOps untuk menjadikan perbelanjaan ini kelihatan dan menghubungkannya dengan peralatan, perkhidmatan dan kes penggunaan, bil meningkat secara tidak dijangka.

ChatOps + LLMOps + DevOps: operasi menjadi perbualan

Salah satu trend paling hebat ialah penyepaduan ChatOps dan LLMOps dalam budaya DevOps . Daripada terhad kepada papan pemuka, skrip dan saluran paip, pasukan mula mengendalikan sebahagian besar sistem melalui saluran sembang seperti Slack, Microsoft Teams atau Discord.

ChatOps mencadangkan agar operasi harian (pelaksanaan, pertanyaan log, but semula, perubahan konfigurasi) dilaksanakan oleh bot dalam saluran komunikasi itu sendiri , secara telus kepada seluruh pasukan. Setiap arahan, tindakan dan hasil direkodkan dalam perbualan.

Apabila LLM ditambah kepada pendekatan itu, lapisan kecerdasan baharu muncul: chatbot yang memahami bahasa semula jadi, mentafsir niat dan boleh mencetuskan arahan kompleks atau menganalisis situasi tanpa pengendali perlu mengingati setiap skrip atau bendera yang tepat.

Contoh tipikal penumpuan ini termasuk bot, yang dikuasakan oleh LLM, membaca metrik daripada Prometheus dan log daripada Loki apabila seseorang menaip "perkhidmatan kumpulan X perlahan" dan mencadangkan tindakan seperti penskalaan replika, melakukan pengembalian semula atau melancarkan ujian tertentu, semuanya dijelaskan dalam bahasa semula jadi.

Pada peringkat budaya dan operasi, ini diterjemahkan kepada keputusan yang lebih pantas, kurang campur tangan manual dalam tugasan berulang dan pengalaman yang lebih lancar untuk pasukan DevOps , yang beralih daripada sentiasa memadamkan kebakaran kepada berusaha untuk menambah baik strategik.

Prinsip utama kitaran hayat LLM dalam pengeluaran

Menjalankan program LLM yang serius bukanlah projek sekali sahaja; ia merupakan kitaran berulang di mana setiap perubahan boleh mengubah tingkah laku sistem . Walaupun setiap organisasi menyesuaikannya dengan realitinya sendiri, biasanya terdapat enam peringkat utama yang mengukuhkan diri.

Fasa pertama ialah latihan atau penyesuaian model , yang boleh terdiri daripada penggunaan model asas hinggalah kepada penggunaan penalaan halus, LoRa atau teknik penalaan lain dengan data anda sendiri. Di sini, perkara penting bukan sahaja prestasi, tetapi juga meninggalkan rekod lengkap: set data, penapis yang digunakan, hiperparameter, versi tokenizer, seni bina yang diuji, dsb.

Jika fasa ini dibuat secara improvisasi dan tidak didokumenkan, model tersebut akan lahir tanpa tadbir urus . Selepas itu, hampir mustahil untuk menjelaskan mengapa ia bertindak balas sedemikian atau untuk meniru keputusan tertentu apabila diperlukan dalam audit.

Peringkat kedua ialah penggunaan, di mana model meninggalkan makmal dan memasuki pengeluaran. Dalam LLMOps, ini bukan sekadar "memasukkannya ke dalam bekas": anda perlu memutuskan perkakasan yang hendak digunakan , cara mengurus memori untuk konteks jangka panjang, topologi kluster yang hendak digunakan dan cara mensklaj mengikut trafik tanpa latensi yang melambung tinggi atau kos menjadi tidak terurus.

Dari situ, pemantauan berorientasikan tingkah laku berterusan akan memainkan peranan . Tidak cukup hanya dengan melihat penggunaan CPU dan RAM; adalah perlu untuk memantau kualiti semantik respons, kestabilan gaya, kadar ralat, evolusi kos setiap token, kemunculan respons berbahaya atau tidak konsisten dan perubahan dalam masa respons di bawah corak penggunaan yang berbeza.

Dalam fasa-fasa seterusnya, tugas pengoptimuman dan penalaan halus dilakukan: pengubahsuaian gesaan, melaraskan RAG, menguji varian model, pengkuantitian, menjalankan ujian A/B, mengubah dasar keselamatan semantik atau memperhalusi peraturan perniagaan . Ia merupakan proses yang hampir seperti kerja tangan, di mana data, kejuruteraan dan perniagaan bergabung untuk menentukan keutamaan.

Akhir sekali, semua ini dibingkai dalam lapisan keselamatan dan tadbir urus (kawalan akses, pengauditan, pencegahan kebocoran, had penggunaan, pematuhan peraturan) dan dalam logik pengemaskinian berterusan, di mana model dan ekosistemnya disesuaikan dengan perubahan dalam data, peraturan dan keperluan dalaman.

GenAIOps dan pendekatan aliran pemberitahuan dalam Azure

Dalam dunia LLMOps, terdapat cadangan yang sangat spesifik untuk menstrukturkan kitaran hayat ini. Salah satu yang paling maju dalam persekitaran korporat ialah GenAIOps dengan aliran pantas pada Azure Machine Learning yang disepadukan dengan Azure DevOps , yang menawarkan pendekatan yang sangat sistematik untuk membina aplikasi berasaskan LLM.

Aliran gesaan bukan sekadar editor gesaan; ia merupakan platform lengkap untuk mereka bentuk, menguji, membuat versi dan menggunakan aliran interaksi LLM , daripada kes mudah (gesaan tunggal) kepada orkestrasi kompleks dengan berbilang nod, alatan luaran, kawalan dan penilaian automatik.

Satu ciri penting ialah repositori aliran kerja berpusat , yang bertindak sebagai perpustakaan korporat. Daripada setiap pasukan mempunyai gesaan mereka dalam dokumen berasingan atau repositori mereka sendiri, ia disatukan menjadi satu repositori terurus, dengan cawangan, semakan dan sejarah yang jelas.

Di samping itu, platform ini menambah keupayaan eksperimen varian dan hiperparameter: adalah mungkin untuk menguji kombinasi gesaan, model, tetapan suhu atau dasar keselamatan yang berbeza pada berbilang nod aliran dan membandingkan keputusan dengan metrik yang jelas.

Dari segi penggunaan, GenAIOps dengan aliran pemberitahuan menjana imej Docker yang merangkumi kedua-dua aliran dan sesi proses , sedia untuk dijalankan dalam persekitaran seperti Azure App Services, Kubernetes atau proses terurus. Daripada asas ini, penggunaan A/B diaktifkan untuk membandingkan versi aliran dalam persekitaran dunia sebenar.

Satu lagi kekuatan ialah pengurusan hubungan antara set data dan aliran. Setiap aliran penilaian boleh berfungsi dengan beberapa set data standard dan ujian , yang membolehkan pengesahan tingkah laku dalam senario yang berbeza sebelum meletakkan sesuatu ke tangan pengguna akhir.

Platform ini juga mendaftarkan versi set data baharu secara automatik dan mengalir hanya apabila terdapat perubahan sebenar, dan menjana laporan komprehensif dalam format seperti CSV dan HTML untuk menyokong keputusan berasaskan data, bukan intuisi.

Empat fasa GenAIOps dengan aliran pemberitahuan

Pendekatan GenAIOps memecahkan kitaran hayat kepada empat peringkat yang jelas berbeza, yang membantu mengelakkan huru-hara tipikal "kita mencuba sesuatu dengan AI dan melihat apa yang berlaku".

Fasa pertama, permulaan, memberi tumpuan kepada penentuan objektif perniagaan dengan tepat dan pengumpulan contoh data yang mewakili . Di sini, struktur asas aliran gesaan digariskan dan seni bina direka bentuk, yang kemudiannya akan diperhalusi.

Dalam fasa eksperimen, aliran digunakan pada data sampel ini dan variasi gesaan, model dan konfigurasi yang berbeza dinilai . Pengulangan berterusan sehingga kombinasi yang boleh diterima ditemui yang memenuhi keperluan kualiti dan konsistensi minimum.

Seterusnya ialah fasa penilaian dan penghalusan, di mana set data yang lebih besar dan lebih pelbagai digunakan untuk penanda aras yang ketat . Hanya apabila aliran menunjukkan prestasi yang konsisten sejajar dengan piawaian yang ditetapkan, barulah ia dianggap bersedia untuk langkah seterusnya.

Akhir sekali, dalam fasa pelaksanaan, aliran kerja dioptimumkan untuk kecekapan dan digunakan untuk pengeluaran, termasuk pengujian A/B, pemantauan, maklum balas pengguna dan kitaran penambahbaikan berterusan . Tiada apa yang benar-benar selesai: aliran kerja terus diselaraskan berdasarkan pemerhatian penggunaan dunia sebenar.

Metodologi ini dipaketkan dalam templat repositori GenAIOps, dengan saluran paip pra-binaan yang didahulukan kod dan alat pelaksanaan tempatan dan berasaskan awan untuk membangun, menilai dan melancarkan aplikasi berasaskan LLM tanpa mencipta semula roda untuk setiap projek.

Integrasi dengan Azure DevOps: repositori, saluran paip dan pengesahan

Untuk membawa GenAIOps daripada teori kepada organisasi sebenar, penyepaduannya dengan Azure DevOps adalah kuncinya. Templat biasa bermula dengan repositori dalam Azure Repos dengan dua cabang utama, utama dan pembangunan , yang mencerminkan persekitaran dan strategi promosi kod yang berbeza.

Repositori sampel diklon daripada GitHub, yang dikaitkan dengan Azure Repos dan aliran kerja biasa melibatkan penciptaan cabang ciri daripada direktori pembangunan . Perubahan kemudiannya ditolak melalui permintaan tarik, yang secara automatik mencetuskan saluran paip pengesahan dan eksperimen.

Untuk mendayakan Azure DevOps berinteraksi dengan Azure Machine Learning dan perkhidmatan lain, prinsipal perkhidmatan dikonfigurasikan dalam Azure sebagai identiti teknikal . Identiti ini digunakan dalam sambungan perkhidmatan Azure DevOps, yang membolehkan saluran paip mengesahkan tanpa mendedahkan kunci yang jelas.

Biasanya, entiti ini mempunyai kebenaran Pemilik pada langganan ML atau sumber pekerja, yang membolehkan saluran paip menyediakan titik akhir, mendaftarkan model dan mengemas kini dasar dalam stor kunci . Untuk keselamatan yang lebih baik, ia boleh ditukar kepada peranan Penyumbang dengan mengubah suai langkah YAML yang mengendalikan kebenaran.

Di samping itu, sekumpulan pembolehubah dicipta dalam Azure DevOps yang menyimpan data sensitif seperti nama sambungan perkhidmatan atau pengecam sumber . Pembolehubah ini didedahkan kepada saluran paip sebagai persekitaran, mengelakkan keperluan untuk mengekod maklumat penting ke dalam kod.

Mengkonfigurasi repositori tempatan dan jauh membolehkan cabang pembangunan dilindungi dengan dasar cabang yang memerlukan saluran paip permintaan tarik untuk dijalankan sebelum penggabungan. Saluran paip ini mengendalikan pengesahan binaan dan aliran eksperimen, menghalang perubahan yang rosak daripada diperkenalkan.

Sebaik sahaja kod memasuki pembangunan, saluran pembangunan akan dicetuskan yang merangkumi fasa CI dan CD yang lengkap : menjalankan eksperimen dan penilaian, mendaftarkan aliran dalam pendaftaran model Azure ML, menggunakan titik akhir dan ujian asap dan mengintegrasikan pada titik akhir yang baru dibuat.

Corak yang sama direplikasi pada cabang versi atau keluaran, yang disambungkan ke persekitaran pengeluaran. Di sana, saluran paip CI/CD untuk pengeluaran mengulangi kitaran eksperimen, penilaian dan penggunaan , tetapi pada infrastruktur dan data peringkat pengeluaran, dengan kawalan yang lebih besar dan semakan manual tambahan jika perlu.

Ciri utama ialah "semakan manusia gelung" yang disertakan dalam saluran paip ini: selepas fasa CI, CD disekat sehingga seseorang meluluskan penerusan daripada antara muka Azure Pipelines secara manual. Jika ia tidak diluluskan dalam masa yang ditetapkan (contohnya, 60 minit), pelaksanaan akan ditolak.

Pelaksanaan tempatan dan hubungan dengan penyedia LLM

Bukan semuanya berlaku melalui saluran paip: GenAIOps juga menyokong pelaksanaan setempat untuk eksperimen pantas . Anda boleh mengklon repositori templat, mencipta fail .env dalam direktori root dan menentukan sambungan ke Azure OpenAI atau titik akhir serasi lain di dalamnya.

Sambungan ini merangkumi parameter seperti api_key, api_base, api_type dan api_version, dan dirujuk mengikut nama dalam aliran (contohnya, sambungan bernama "aoai" dengan versi API tertentu). Ini membolehkan aliran yang sama dijalankan secara setempat dan dalam awan tanpa perubahan kod.

Untuk menggunakan kaedah ini, hanya cipta persekitaran maya atau konda dan pasang kebergantungan yang diperlukan (promptflow, promptflow-tools, promptflow-sdk, openai, jinja2, python-dotenv, dll.). Dari situ, anda boleh menulis skrip ujian dalam folder pelaksanaan setempat dan menjalankan eksperimen pada aliran yang ditakrifkan.

Dualiti awan/di premis ini sejajar dengan pemikiran DevOps yang matang: ujian berskala kecil dilakukan secara tempatan, pengesahan formal dilakukan dalam saluran paip, dan kemudian penggunaan dibuat ke persekitaran yang lebih besar dengan kawalan dan pengauditan . Semuanya diversikan dalam Git dan disambungkan ke Azure DevOps.

Alat tipikal dalam ekosistem DevOps dengan AI dan LLMOps

Di luar cadangan khusus Azure, ekosistem DevOps moden dengan AI dan LLMOps biasanya bergantung pada satu set alatan yang merangkumi ChatOps, orkestrasi model, pemantauan dan kebolehcerapan.

Dalam lapisan ChatOps, adalah perkara biasa untuk menggabungkan Slack dengan bot seperti Hubot , Microsoft Teams dengan ejen berdasarkan Power Virtual Agents atau Discord berserta rangka kerja seperti Botpress atau Rasa untuk membina pembantu tersuai yang berhubung dengan saluran paip, sistem pemantauan dan perkhidmatan dalaman.

Dalam bidang LLMOps/MLOps, platform seperti Kubeflow dan MLflow adalah perkara biasa untuk mengurus saluran paip, rekod model dan eksperimen, selain alat khusus seperti Weights & Biases (W&B) untuk penjejakan metrik lanjutan, perbandingan larian atau visualisasi mendalam.

Pembinaan aplikasi pada LLM biasanya melibatkan penggunaan rangka kerja seperti LangChain atau perpustakaan seperti OpenLLM , yang memudahkan pemasangan rantai gesaan, penyambung kepada data luaran, alatan dan ejen berbilang langkah. Pada masa yang sama, penyelesaian untuk kebolehcerapan khusus LLM sedang muncul, yang membolehkan pemantauan gesaan, respons, kos dan kualiti.

Dalam penyepaduan dengan DevOps klasik, alatan seperti Jenkins atau GitLab CI kekal relevan untuk bahagian CI/CD, Kubernetes dan ArgoCD untuk penggunaan awan natif berterusan dan susunan kebolehcerapan seperti Prometheus, Grafana dan Loki untuk metrik, papan pemuka dan log.

Cabaran, batasan dan penerimaan progresif

Semua penggunaan amalan dan alatan ini tidak datang tanpa harga. Kerumitan mengurus gesaan, versi model dan varian aliran kerja adalah besar, terutamanya apabila berbilang pasukan bekerja secara serentak — satu senario di mana strategi seperti GitOps berguna untuk menyelaraskan perubahan dan penggunaan.

Tambahan pula, bot ChatOps dan LLM dengan keupayaan yang boleh diambil tindakan memperkenalkan risiko keselamatan yang besar jika ia mempunyai kebenaran yang berlebihan dalam persekitaran pengeluaran atau jika permukaan pendedahan data tidak dikawal dengan betul.

Tambahan pula, pergantungan pada model sumber terbuka dengan pelesenan sensitif atau API komersial yang boleh mengubah terma, harga atau had. Dan, untuk memburukkan lagi keadaan, penilaian LLM yang mantap dalam pengeluaran masih menjadi ruang terbuka, dengan banyak persoalan masih belum terjawab.

Oleh itu, adalah masuk akal untuk mendekati penggunaan LLMOps dan ChatOps dalam DevOps secara progresif dan terkawal , bermula dengan mengautomasikan tugas berulang dengan bot mudah (but semula, pertanyaan log, penandaan binaan, dll.).

Kemudian, LLM boleh diperkenalkan untuk tugasan sokongan, pengelasan insiden atau bantuan penyahpepijatan , contohnya, menjelaskan ralat daripada log atau mencadangkan mitigasi berdasarkan dokumentasi dalaman.

Setelah operasi ML klasik stabil, tiba masanya untuk menangani LLMOp dengan model bahasa khusus untuk domain seperti khidmat pelanggan, DevSecOps atau QA, memanfaatkan semua yang dipelajari dalam fasa sebelumnya.

Ufuk yang dituju oleh semua amalan ini ialah persekitaran kejuruteraan perbualan, ramalan dan semakin autonomi , di mana sebahagian besar pembangunan dan operasi dinyatakan dalam bahasa semula jadi dan AI membantu membuat keputusan proaktif tentang penggunaan, penskalaan atau pengembalian.

Dengan adanya teka-teki ini —DevOps, ChatOps, MLOps, GenAIOps dan LLMOps — organisasi mempunyai rangka kerja yang kukuh untuk membina dan mengekalkan sistem berasaskan LLM yang benar-benar memberikan nilai , mengekalkan kawalan ke atas kualiti, kos, keselamatan dan penjajaran dengan perniagaan, dan bukannya hanya tinggal pada prototaip atau ujian terpencil yang gagal sebaik sahaja ia mencapai pengeluaran.