Penghijrahan Corak: Beralih dari AI v1 ke v2

Generasi pertama AI perusahaan sudah semakin tua. Pasukan yang melancarkan RAG Assistant pada 2022 membinanya pada text-embedding-ada-002. Pasukan yang melancarkan model pemarkahan pada 2023 melatihnya pada infrastruktur data pra-GPT4. Pasukan yang membina Workflow Copilot pada awal 2024 mereka bentuk prompt untuk model yang sejak itu telah digantikan oleh dua generasi.

Sistem ini masih berjalan. Itulah masalahnya. Mereka berjalan secara senyap, mengumpul hutang teknikal dan operasional, sementara seni bina yang lebih baik berada satu penghijrahan jauhnya. Pasukan yang berjalan pada infrastruktur yang ditamatkan tidak gagal. Mereka hanya meninggalkan keupayaan di atas meja sementara tunggakan penghijrahan mereka berkembang.

Penghijrahan adalah tidak pilihan. Tetapi ia juga tidak setara dengan naik taraf versi perisian. Tingkah laku AI adalah kebarangkalian. "Berfungsi seperti yang dimaksudkan" bukan keadaan binari. Anda tidak boleh hanya menukar model, menjalankan suite ujian, dan selesai. Perubahan tingkah laku dari kemas kini model adalah nyata, kadangkala halus, dan kadangkala ketara. Dan pengguna yang telah membina aliran kerja sekitar tingkah laku lama perlu tahu apa yang berubah.

Artikel ini adalah untuk pasukan yang membina sesuatu pada 2022-2024 dan perlu menaik tarafnya tanpa memecahkan pengeluaran.

Apa yang mencetuskan penghijrahan corak

Lima senario menolak corak kepada penghijrahan dan bukannya penyelenggaraan berterusan:

Penamatan model oleh vendor. Pencetus paling jelas. OpenAI, Anthropic, Google, dan Azure semuanya menerbitkan garis masa penamatan dengan tarikh tamat hayat. Apabila model yang bergantung corak Anda mencapai EOL, Anda berhijrah atau Anda rosak. Kebanyakan pasukan AI perusahaan telah mengalami ini sekurang-kurangnya sekali: API mengembalikan notis penamatan, dan tiba-tiba penghijrahan yang tidak ada dalam roadmap menjadi segera. Dokumentasi penamatan model Anthropic memberikan sekurang-kurangnya 60 hari notis sebelum persaraan, tetapi garis masa itu mengandaikan Anda memantau notis. Permintaan API kepada model yang bersara gagal secara senyap dari perspektif pemanggil melainkan pemantauan ada.

Implikasi operasional: mana-mana corak pengeluaran perlu mempunyai jawapan yang didokumenkan untuk "apa yang berlaku jika model ini ditamatkan pada suku hadapan?" Bukan semestinya rancangan penghijrahan yang lengkap, tetapi sekurang-kurangnya penilaian tentang apa skop penghijrahan itu.

Kemerosotan ketepatan yang ketara. Apabila semakan ketepatan suku tahunan menunjukkan penurunan yang konsisten, dan punca akar adalah keupayaan model dan bukannya kualiti data atau kualiti prompt, penghijrahan kepada model yang lebih baik adalah pembetulan. Diagnosis adalah penting: hanyut data memerlukan latihan semula atau kemas kini data; isu kualiti prompt memerlukan kejuruteraan prompt; jurang keupayaan model memerlukan penghijrahan model.

Keupayaan baharu yang menjadikan pendekatan sedia ada lapuk. Peralihan dari RAG carian vektor tulen kepada carian hibrid kata kunci-vektor-rerank adalah contoh terkini yang paling jelas. Pasukan yang membina RAG pada 2022 pada carian semantik tulen meninggalkan peningkatan kualiti pengambilan semula 20-40% berbanding pendekatan hibrid. Artikel risiko halusinasi mengikut corak menerangkan mengapa kualiti pengambilan semula sangat penting untuk ketepatan RAG. Sistem sedia ada tidak rosak. Ia hanya ketara mengatasi prestasi oleh seni bina v2 yang tidak wujud apabila v1 dibina.

Perubahan kos yang memihak kepada pendekatan baharu. Corak yang dibina pada GPT-4 pada harga 2023 mungkin kini boleh digantikan secara ekonomi dengan model yang lebih kecil, lebih pantas, lebih murah yang telah mengejar keupayaan. Sebagai alternatif, corak yang dibina pada perkakas vendor proprietari mungkin boleh digantikan dengan infrastruktur sumber terbuka pada sebahagian kecil kos. Lihat artikel kos berlebihan untuk perbandingan model kos.

Perubahan hubungan vendor. Pengambilalihan, penstrukturan semula harga, dan penutupan produk berlaku. Corak yang dibina pada API AI syarikat permulaan yang kemudian ditutup oleh syarikat permulaan itu adalah senario terburuk: penghijrahan paksa pada garis masa kecemasan. Penilaian risiko kepekatan vendor perlu menjadi sebahagian daripada semakan tadbir urus AI Anda.

Key Facts: Realiti Penghijrahan Corak AI

• Generasi pertama AI perusahaan (yang dilancarkan 2022-2024) sudah mencapai pencetus penghijrahan: penamatan model, jurang keupayaan dari seni bina baharu (RAG hibrid berbanding carian vektor naif menunjukkan peningkatan kualiti pengambilan semula 20-40%), dan hutang data yang terkumpul.
• Pengujian bayangan diikuti dengan pelancaran kenari pada 1-10% trafik kini merupakan amalan standard untuk pelancaran model AI perusahaan, dengan pendekatan empat fasa: POC (2-4 minggu), Percubaan pada trafik 5-10% (4-8 minggu), dan pelancaran skala penuh (8-12 minggu). (MLOps Deployment Research, 2026)
• Penghijrahan yang dipacu AI dengan penjujukan kenari yang betul meningkatkan kecekapan operasional sebanyak 20-25% dan mengurangkan masa kitaran pelancaran sebanyak 70% berbanding pendekatan pemotongan terus. (QualityKiosk Migration Analysis, 2026)

Tiga jenis penghijrahan dengan profil risiko berbeza

Jenis 1: Penghijrahan model-dalam-tempat. Tukar model asas sambil mengekalkan seni bina. Saluran pengambilan semula yang sama, struktur prompt yang sama, lapisan integrasi yang sama. Hanya panggilan model yang berbeza. Ini adalah jenis penghijrahan risiko terendah dari segi infrastruktur, tetapi ia masih memerlukan ujian regresi tingkah laku kerana model baharu mungkin bertindak balas secara berbeza terhadap prompt yang sama, walaupun dengan arahan yang sama.

Contoh: menggantikan GPT-3.5 Turbo dengan GPT-4o Mini untuk RAG Assistant. Seni bina sama, model lebih baik. Tetapi GPT-4o Mini mengikuti arahan dengan lebih tepat daripada GPT-3.5 Turbo, yang bermakna prompt yang bergantung pada kecenderungan model lama untuk sedikit longgar dengan format mungkin kini menghasilkan output dalam format yang tidak dijangka.

Jenis 2: Penghijrahan seni bina. Bina semula corak dengan pendekatan yang berbeza. Kes penggunaan adalah sama; pelaksanaannya berbeza secara asas. RAG dari carian vektor tunggal naif kepada carian hibrid kata kunci-vektor-rerank adalah penghijrahan seni bina. Meeting Intelligence dari saluran transkripsi sahaja kepada saluran transkripsi-tambah-diarisasi-penutur-tambah-pengesanan-topik adalah penghijrahan seni bina.

Penghijrahan seni bina membawa kerumitan tertinggi dan potensi peningkatan kualiti tertinggi. Ia lebih hampir kepada membina sistem baharu daripada menaik taraf yang sedia ada, yang bermakna ia memerlukan rangka kerja penghijrahan penuh.

Jenis 3: Penghijrahan vendor. Memindahkan pelaksanaan corak yang sama kepada vendor berbeza. Menukar RAG Assistant dari Azure OpenAI kepada Anthropic Claude. Menukar Meeting Intelligence dari AssemblyAI kepada Deepgram. Corak kekal sama; tumpukan vendor berubah.

Penghijrahan vendor sering kelihatan lebih mudah daripada yang sebenarnya. Vendor berbeza mempunyai konvensyen API yang berbeza, ciri kelewatan yang berbeza, lalai format output yang berbeza, dan tingkah laku model yang berbeza pada prompt yang sama. Apa yang berfungsi pada Vendor A mungkin memerlukan pelarasan prompt pada Vendor B walaupun kedua-dua vendor mendakwa keupayaan yang setara.

Cara risiko penghijrahan berbeza mengikut corak

Tidak semua penghijrahan corak membawa risiko yang sama. Memahami di mana risiko tertumpu membantu Anda mengutamakan masa pengujian dan pementasan.

Corak risiko penghijrahan tinggi:

Scoring and Routing: Model pemarkahan baharu bukan sahaja menghasilkan skor yang berbeza. Ia menghasilkan taburan yang berbeza. Jika model lama menilai petunjuk berkualiti tinggi pada 70-90 dan model baharu menilai mereka pada 80-95, ambang penghalaan Anda salah dari hari pertama. Logik penghalaan yang dibina pada "hala ke pasukan perusahaan jika skor > 75" kini menghalakan secara berbeza, berpotensi salah menetapkan sebahagian besar isipadu petunjuk Anda. Kalibrasi semula ambang diperlukan selepas setiap pertukaran model, bukan pilihan.

Autonomous Agent: Setiap API alat dalam repertoir ejen memerlukan pengesahan keserasian sebelum penghijrahan. Versi ejen baharu mungkin memanggil API yang sama tetapi menghurai respons secara berbeza, atau mungkin memanggil alat dalam urutan yang berbeza, menghasilkan tingkah laku Execute yang berbeza walaupun untuk input yang sama. Ujian regresi tingkah laku penuh diperlukan.

Personalization Engine: Representasi profil pengguna dari sistem lama mungkin tidak dipindahkan dengan bermakna kepada seni bina baharu. Jika model baharu membina profil pengguna secara berbeza, beberapa minggu pertama pengeluaran akan mempunyai kualiti pemperibadian yang dikurangkan apabila profil dibina semula.

Corak risiko penghijrahan sederhana:

RAG Assistant: Perubahan model embedding memerlukan pengindeksan semula penuh. Model embedding yang berbeza menghasilkan representasi vektor yang berbeza untuk dokumen yang sama, jadi Anda tidak boleh mencampurkan embeddings dari model berbeza dalam indeks yang sama. Pengindeksan semula penuh pada pangkalan pengetahuan 500,000 dokumen adalah peristiwa pengiraan yang ketara yang perlu dirancang, bukan ditemui.

Workflow Copilot: Tingkah laku prompt berubah antara model. Arahan yang menghasilkan cadangan ringkas pada model lama mungkin menghasilkan cadangan yang panjang pada yang baharu. Semakan kualiti nada, panjang, dan ketepatan cadangan diperlukan sebelum promosi.

Document Review: Keserasian skema pengekstrakan. Model baharu mungkin mengekstrak maklumat klausa dalam format yang sedikit berbeza yang memecahkan integrasi aliran kerja undang-undang hiliran.

Corak risiko penghijrahan lebih rendah:

Meeting Intelligence: Menukar kepada vendor transkripsi yang berbeza adalah risiko yang agak rendah kerana output transkripsi adalah standard (teks dengan cap masa). Analisis peringkat lebih tinggi (ringkasan, item tindakan) membawa lebih banyak risiko tingkah laku.

Vision Extract: Selagi skema pengekstrakan dikekalkan, perubahan model mempunyai risiko lebih rendah kerana output terhad kepada medan tertentu. Hanyut format adalah risiko utama, bukan ketidakbolehramalan tingkah laku.

Anomaly Agent: Penghijrahan kepada model pengesanan anomali yang lebih baik memerlukan pembinaan semula garis dasar, tetapi logik amaran asas biasanya bebas model.

Rangka kerja penghijrahan

Langkah 1: Tetapkan garis dasar sistem semasa.

Sebelum menyentuh apa-apa dalam penghijrahan, tangkap garis dasar tingkah laku sistem semasa yang komprehensif. Ini adalah set perbandingan regresi Anda.

Untuk RAG Assistant: jalankan 200 pertanyaan representatif terhadap sistem semasa. Rekodkan pertanyaan, dokumen yang diambil semula, dan respons yang dijana. Klasifikasikan setiap respons sebagai tepat, separa tepat, atau tidak tepat terhadap kebenaran asas. Ini menjadi suite ujian penerimaan Anda.

Untuk model Scoring+Routing: tarik 90 hari terakhir keputusan pemarkahan. Rekodkan ciri input dan skor untuk 500 rekod representatif. Perhatikan hasil sebenar (adakah petunjuk skor tinggi ditutup? adakah anomali yang ditandakan ternyata nyata?). Ini adalah garis dasar kalibrasi Anda.

Jangan mulakan penghijrahan tanpa garis dasar. Jika Anda tidak dapat membandingkan tingkah laku sistem baharu dengan tingkah laku sistem lama pada input yang sama, Anda tidak mempunyai kriteria penghijrahan. Hanya perasaan.

Langkah 2: Jalankan sistem baharu dalam mod bayangan.

Lancarkan sistem baharu secara selari dengan yang lama. Kedua-dua sistem memproses input yang sama. Hanya output sistem lama yang digunakan dalam pengeluaran. Output sistem baharu dicatat tetapi tidak ditindaklanjuti.

Mod bayangan adalah tidak pilihan untuk pelancaran trafik tinggi atau berhadapan pelanggan. Kos menjalankan secara selari selama 30 hari jauh lebih rendah daripada kos pemotongan yang buruk. RAG Assistant yang melayan 10,000 pertanyaan/bulan dalam mod bayangan menambah mungkin 50% kepada kos API untuk tempoh bayangan. Insiden dari pemotongan yang buruk menelan kos jauh lebih banyak dalam kepercayaan pengguna, remediasi kecemasan, dan keyakinan pihak berkepentingan.

Tempoh mod bayangan: minimum 14 hari. Pilihan: 30 hari dengan trafik yang cukup untuk menghasilkan data perbandingan yang bermakna secara statistik.

Langkah 3: Bandingkan output antara sistem.

Untuk setiap input dalam tempoh bayangan, bandingkan output sistem lama dengan output sistem baharu. Kenal pasti kategori:

• Persetujuan: kedua-dua sistem menghasilkan output yang setara
• Peningkatan sistem baharu: sistem baharu jelas lebih baik (ketepatan lebih tinggi, format lebih baik, respons lebih lengkap)
• Regresi sistem baharu: sistem lama lebih baik (sistem baharu menghasilkan jawapan yang lebih buruk atau salah)
• Tingkah laku novel: sistem baharu menghasilkan output yang tidak pernah dihasilkan sistem lama (positif atau negatif)

Regresi adalah kategori kritikal. Sebarang regresi mesti disiasat dan ditangani sebelum promosi.

Langkah 4: Takrifkan kriteria penerimaan.

Sebelum memulakan penghijrahan, takrifkan apa yang dimaksudkan "cukup baik untuk dipromosikan." Jangan takrifkannya selepas Anda melihat keputusan mod bayangan. Itu adalah rasionalisasi, bukan penerimaan.

Contoh kriteria penerimaan untuk penghijrahan RAG Assistant:

• Ketepatan sistem baharu pada set ujian garis dasar: sama atau lebih baik daripada sistem lama pada 95% pertanyaan
• Kadar regresi pada pertanyaan garis dasar: kurang daripada 3%
• Kelewatan respons sistem baharu: dalam 20% kelewatan sistem lama
• Isyarat kepuasan pengguna mod bayangan (apabila boleh diukur): tiada penurunan berbanding sistem lama

Langkah 5: Peralihan trafik beransur-ansur.

"Model pemarkahan baharu bukan sahaja menghasilkan skor yang berbeza. Ia menghasilkan taburan yang berbeza. Jika model lama menilai petunjuk berkualiti tinggi pada 70-90 dan model baharu menilai mereka pada 80-95, ambang penghalaan Anda salah dari hari pertama. Halakan 10% trafik dahulu. Semak penjajaran taburan sebelum mempromosikan kepada 50%. Semak semula sebelum 100%. Kalibrasi semula ambang tidak pilihan selepas setiap pertukaran model." (Rework Scoring Model Migration Analysis, 2026)

Jangan potong terus 100% sekaligus. Halakan 10% trafik pengeluaran kepada sistem baharu terlebih dahulu. Pantau ralat, isu kelewatan, dan isyarat kualiti. Tahan selama 48-72 jam. Jika bersih, naikkan kepada 25%, kemudian 50%, kemudian 100%. Ini dipanggil pelancaran kenari dalam kejuruteraan perisian, dan ia memetakan terus kepada apa yang Martin Fowler huraikan sebagai corak Strangler Fig untuk pemodenan warisan: secara beransur-ansur mengalihkan trafik dari lama ke baru sehingga sistem lama boleh ditamatkan dengan selamat. Ia terpakai terus kepada penghijrahan AI.

Jika pada mana-mana peringkat Anda melihat isyarat kualiti menyimpang dari jangkaan mod bayangan, hentikan peralihan trafik dan siasat sebelum meneruskan.

Langkah 6: Rancangan rollback ditakrifkan sebelum beroperasi.

Sebelum Anda mempromosikan sebarang trafik kepada sistem baharu, ketahui dengan tepat cara Anda kembali kepada sistem lama. Konfigurasi mana untuk dipulihkan. Berapa lama rollback mengambil masa. Siapa yang mempunyai kuasa untuk mencetuskan rollback. Apakah kriteria pencetus rollback.

Rancangan rollback perlu ditulis dan boleh diakses oleh sesiapa dalam pasukan operasi. "Fikirkan semula sekiranya berlaku insiden" bukan rancangan rollback.

Tempoh mod bayangan secara terperinci

Mod bayangan memerlukan trafik yang mencukupi untuk mengesan perbezaan tingkah laku yang bermakna. Saiz sampel yang diperlukan bergantung pada ambang pengesanan yang Anda pedulikan.

Untuk mengesan perbezaan 5% dalam kualiti output antara sistem lama dan baharu dengan kuasa statistik 90%: lebih kurang 500-700 pasangan yang setanding. Pada 10,000 pertanyaan/bulan, itu 2-3 hari trafik. Pada 1,000 pertanyaan/bulan, ia 2-3 minggu.

Untuk Scoring+Routing: Anda memerlukan rekod yang mencukupi untuk mengesahkan bahawa taburan skor dikalibrasi dengan betul. Jika ambang penghalaan biasa Anda adalah 70, Anda mahukan rekod yang mencukupi pada kedua-dua belah ambang itu untuk mengesahkan bahawa 70 model baharu bermakna perkara yang sama dengan 70 model lama. Biasanya memerlukan 100-200 rekod setiap desil skor.

Apa yang mod bayangan tidak tangkap: hanyut tingkah laku pada kes tepi. Set data perbandingan dari mod bayangan mencerminkan taburan trafik sebenar Anda, yang condong ke arah kes biasa. Kes yang jarang tetapi berisiko tinggi (jenis kontrak yang tidak biasa, anomali kes tepi, pertanyaan berbilang lompatan yang kompleks) diwakili dengan kurang. Reka bentuk kes ujian eksplisit untuk kes tepi dan jalankannya secara langsung, bukan hanya melalui trafik mod bayangan.

Urutan Bayangan-Selari-Pemotongan

Urutan Bayangan-Selari-Pemotongan adalah rangka kerja penghijrahan tiga fasa untuk naik taraf corak AI. Fasa 1 (Bayangan): lancarkan sistem baharu secara selari; kedua-dua sistem memproses input yang sama tetapi hanya output sistem lama yang digunakan dalam pengeluaran; catat dan bandingkan. Fasa 2 (Selari): halakan peratusan trafik yang ditakrifkan (bermula pada 1-10%) kepada sistem baharu; pantau isyarat kualiti dan pencetus pembalikan selama 48-72 jam sebelum menaikkan; takrifkan kriteria penerimaan sebelum memulakan. Fasa 3 (Pemotongan): promosikan 100% trafik hanya selepas peralihan trafik beransur-ansur merentas sekurang-kurangnya tiga kenaikan memenuhi semua kriteria penerimaan; kekalkan keupayaan rollback selama 30 hari selepas pemotongan. Jangan sekali-kali meneruskan dari bayangan kepada pemotongan tanpa fasa selari.

Rework Analysis: Berdasarkan penyelidikan pelancaran MLOps yang menunjukkan pelancaran kenari mengurangkan kadar insiden penghijrahan sebanyak 70% berbanding pemotongan terus, dan data penghijrahan dalaman dari naik taraf corak AI sendiri Rework, Urutan Bayangan-Selari-Pemotongan menghasilkan purata 0.4 insiden penghijrahan setiap kitaran naik taraf berbanding 2.3 insiden untuk pasukan yang menggunakan pertukaran model terus. Fasa selari adalah langkah yang paling kerap dilangkau dalam penghijrahan AI perusahaan, biasanya dijustifikasikan sebagai "kami tidak mempunyai masa" dalam pasukan yang akan menghabiskan 10x lebih banyak masa untuk tindak balas insiden jika mereka melangkauinya.

Penerimaan semula pengguna selepas penghijrahan

Bahagian ini dilangkau dalam hampir setiap projek penghijrahan. Ia mewujudkan hutang kepercayaan walaupun apabila penghijrahan teknikal adalah bersih.

Apabila tingkah laku AI berubah (walaupun menjadi lebih baik), pengguna yang telah membina model mental sekitar tingkah laku lama perlu memahami apa yang berubah. Workflow Copilot yang kini menjana cadangan yang lebih panjang dan lebih terperinci daripada sebelumnya menghasilkan perubahan tingkah laku yang perlu diketahui wakil. RAG Assistant yang kini memetik sumber dengan lebih khusus daripada versi lama menghasilkan output yang kelihatan berbeza, dan pengguna yang telah belajar untuk mengimbas mungkin kini terlepas atribusi yang ditingkatkan.

Penerimaan semula tidak memerlukan program latihan. Ia memerlukan:

1. Nota perubahan: "Sistem kini melakukan X secara berbeza. Inilah rupa penampilannya."
2. Saluran maklum balas: "Jika tingkah laku baharu lebih buruk untuk aliran kerja Anda, beritahu kami di sini."
3. Contoh peningkatan yang kelihatan: "Inilah perbandingan output lama berbanding output baharu pada pertanyaan sebenar."

Langkau penerimaan semula dan Anda akan melihat penurunan penggunaan dalam metrik penggunaan Anda 2-4 minggu selepas penghijrahan, apabila pengguna menghadapi tingkah laku yang tidak dijangka dan secara senyap tidak melibatkan diri. Sistem baharu mungkin lebih baik. Pengguna yang tidak mengetahuinya tidak dapat mendapat manfaat daripadanya.

Pertimbangan utama penghijrahan setiap corak

RAG Assistant: Pilihan model embedding adalah kebergantungan untuk keseluruhan indeks Anda. Menukar model embedding memerlukan penyematan semula setiap dokumen dalam pangkalan pengetahuan Anda. Ini bukan operasi pantas pada skala perusahaan. Rancang pengiraan pengindeksan semula sebagai langkah penghijrahan, bukan renungan kemudian. Juga: prompt untuk penjanaan augmented pengambilan semula sering mempunyai arahan khusus model. Semak dan kemas kini prompt untuk konvensyen mengikut arahan model baharu.

Scoring + Routing: Kalibrasi semula ambang diperlukan. Jangan anggap ambang lama diterjemahkan kepada model baharu. Jalankan model baharu terhadap 6 bulan terakhir rekod berlabel Anda, plot taburan skor, dan kalibrasi semula ambang penghalaan berdasarkan taburan baharu sebelum mana-mana trafik pengeluaran.

Autonomous Agent: Semakan keserasian API alat sebelum penghijrahan bermula. Senaraikan setiap API luaran yang dipanggil ejen, semak keperluan pengesahan semasa dan format respons mereka, dan sahkan keserasian dengan versi ejen baharu. Satu panggilan alat yang rosak dalam gelung berbilang langkah menghasilkan kegagalan lata yang tidak boleh diramal.

Bila hendak berhijrah berbanding terus menyelenggara

Keputusan bergantung pada perbandingan kos: apakah kos menyelenggara corak warisan setiap tahun (masa kejuruteraan, kualiti output yang merosot, impak kepercayaan pengguna), berbanding apakah kos penghijrahan (kerja seni bina, pengujian, risiko rollback, penerimaan semula pengguna)?

Apabila kos penyelenggaraan melebihi kos penghijrahan, berhijrah. Pengiraan menjadi jelas apabila Anda meletakkan nombor padanya.

RAG Assistant warisan yang menyelenggara kitaran kemas kini pangkalan pengetahuan manual: 8 jam/bulan masa kejuruteraan. Penghijrahan kepada seni bina carian hibrid dengan kemas kini indeks automatik: 80 jam kerja seni bina. Titik pulang modal: 10 bulan. Jika sistem warisan mempunyai 24+ bulan hayat yang tersisa, penghijrahan dijustifikasikan secara ekonomi pada tahun 1.

Apabila beban penyelenggaraan telah terkumpul ke titik di mana corak secara aktif tidak boleh dipercayai, kos penyelenggaraan itu bukan lagi masa kejuruteraan sahaja. Ia adalah kepercayaan pengguna dan impak perniagaan. Penghijrahan kemudian adalah segera, bukan hanya dijustifikasikan secara ekonomi.

Lihat artikel hutang teknikal untuk petunjuk hutang yang menandakan apabila penyelenggaraan telah melepasi ambang ke wilayah penghijrahan. Lihat rangka kerja tadbir urus untuk jejak audit yang menjadikan pengumpulan garis dasar penghijrahan mungkin. Dan lihat artikel risiko halusinasi untuk mod kegagalan untuk ujian regresi secara khusus semasa mod bayangan.

Penghijrahan adalah remedi untuk hutang yang terkumpul. Dilakukan dengan baik, dengan mod bayangan, kriteria penerimaan, dan pelancaran beransur-ansur, ia adalah operasi rutin. Dilakukan dengan buruk (pemotongan penuh, tiada rancangan rollback, tiada komunikasi pengguna), ia adalah insiden yang menunggu untuk berlaku.

Pasukan yang berhijrah dengan baik adalah pasukan yang memperlakukan pelancaran pertama mereka sebagai v1, bukan jawapan akhir.

---

Ketahui lebih lanjut

• Apabila Corak AI Menjadi Hutang Teknikal
• Keperluan Tadbir Urus mengikut Corak AI
• Risiko Halusinasi mengikut Corak AI
• RAG Assistant: Corak Retrieval Augmented Generation
• Apabila Corak AI Menjadi Mahal pada Skala