Yapay Zeka ve LLMOps ile DevOps: İşlem hattından konuşan modele

Informatec Dijital » Ücretsiz Destekler » Yapay Zeka ve LLMOps ile DevOps: İşlem hattından konuşan modele

Üretken yapay zekanın ve büyük dil modellerinin ortaya çıkışı, yazılımın geliştirilme, dağıtılma ve işletilme biçimini tamamen değiştirdi. İyi şeylere sahip olmak artık yeterli değil. DevOps işlem hatları ne de klasik MLOps'u uygulayarakBir LLM'yi denkleme dahil ettiğinizde, modelin konuştuğu, akıl yürüttüğü, doğaçlama yaptığı ve bazen tahmin edilemez şekillerde davrandığı bir alana girmiş olursunuz.

Bu yeni senaryoda, Ekiplerin, LLM tabanlı uygulamaların tüm yaşam döngüsünü yönetmek için DevOps, yapay zeka ve LLMOps'u birleştirmesi gerekiyor.Deneylerden ve hızlı mühendislik çalışmalarından dağıtıma, izlemeye, güvenliğe ve maliyet optimizasyonuna kadar, bu makale tüm bu karmaşayı anlaşılır hale getiriyor ve ChatOps, DevOps, MLOps, GenAIOps ve LLMOps'u modern bir operasyona nasıl entegre edeceğinizi adım adım açıklıyor.

DevOps ve MLOps'tan LLMOps'a: Model neden artık statik değil?

Yıllarca mühendislik ekiplerinin önceliği şuydu: yazılım teslimatını otomatikleştirmek ve kalkınma ile altyapı arasındaki sürtüşmeyi azaltmakBöylece DevOps doğdu: sürekli entegrasyon, sürekli dağıtım, kod olarak altyapı, gözlemlenebilirlik ve departmanlar arasındaki sonsuz el değiştirmeleri ortadan kaldıran işbirlikçi bir kültür.

Veriler ürünün bir parçası haline geldiğinde, ortaya çıktı. MLOps, makine öğrenimi modellerinin tekrarlanabilirliği ve izlenebilirliği ihtiyacına bir yanıt olarak ortaya çıkmıştır.Veri seti sürümleme, eğitim hattı düzenlemesi, sapma tespiti ve tahmin modellerinin sürekli değerlendirilmesi gibi uygulamalar standartlaştırıldı.

Sorun şu ki LLM'ler, DevOps ve MLOps'ta örtük olarak bulunan birçok varsayımı yıkıyor.Bunlar statik API'ler veya deterministik bir sayı döndüren basit fonksiyonlar değildir: doğal dilde yanıt verirler, bağlamı, talimatları, araçları ve verileri gerçek zamanlı olarak bir araya getirirler ve aynı girdi için iki farklı çıktı üretebilirler.

Bu şunu ima eder: Sadece modeli ve ağırlıklarını değiştirmek yeterli değildir.Sistem davranışını belirleyen uyarıları, şablonları, anlamsal güvenlik politikalarını, kısıtlamaları, bağlantılı araçları, enjekte edilen bağlamı ve hatta iş kurallarını da kontrol etmek gereklidir.

LLMOps nedir ve aslında neyi çözer?

LLMOps'u şu şekilde görebiliriz: LLM tabanlı uygulamaların güvenli, kontrollü ve sürdürülebilir bir şekilde dağıtımını, bakımını ve ölçeklendirilmesini sağlayan operasyonel çerçeve.Bu, DevOps uygulamalarının, MLOps'un ve üretken modellere özgü yeni yeteneklerin bir arada bulunduğu bir şemsiye kavramdır.

Özünde, LLMOps, "mükemmel modeli eğitmek"ten ziyade, üretim ortamında modelin davranışını yönetmeye odaklanır.Bu, istem akışlarının nasıl tasarlandığını ve sürümlendirildiğini, LLM'lerin dahili veri kaynaklarına nasıl bağlandığını, belirteç maliyetlerinin ve gecikmenin nasıl izlendiğini ve anlamsal riskin (halüsinasyonlar, bilgi sızıntıları, önyargılar, toksik yanıtlar vb.) nasıl yönetildiğini içerir.

LLMOps'un ele aldığı ve DevOps/MLOps'un tek başına karşılamadığı ihtiyaçlar şunlardır: Konuşmaların izlenebilirliği, yanıt kalitesinin otomatik değerlendirilmesi veya davranışsal varyantların A/B karşılaştırması gibi çeşitli yönler.Sadece klasik doğruluktan bahsetmiyoruz, aynı zamanda tutarlılıktan, işletmeyle uyumdan ve güvenlikten de bahsediyoruz.

Buna ek olarak, Maliyetler artık sadece modelin eğitimi ve barındırılmasıyla sınırlı değil.Her komut istemi, her genişletilmiş bağlam ve her eşzamanlı çağrı, ticari API'lerde GPU veya token tüketimini tetikler. Bu tüketimi görünür kılan ve ekipman, hizmetler ve kullanım durumlarıyla ilişkilendiren bir LLMOps katmanı olmadan, fatura öngörülemeyen bir şekilde artar.

ChatOps + LLMOps + DevOps: Operasyonlar konuşmaya dönüşüyor

En güçlü trendlerden biri şudur: ChatOps ve LLMOps'un DevOps kültürü içine entegrasyonuEkipler artık gösterge panelleri, komut dosyaları ve işlem hatlarıyla sınırlı kalmak yerine, sistemin büyük bir bölümünü Slack, Microsoft Teams veya Discord gibi sohbet kanalları üzerinden yönetmeye başlıyor.

ChatOps, günlük işlemlerin (dağıtımlar, günlük sorguları, yeniden başlatmalar, yapılandırma değişiklikleri) Bu işlemler, iletişim kanalının içinde botlar tarafından gerçekleştirilir.Tüm ekibe şeffaf bir şekilde iletilir. Her komut, eylem ve sonuç konuşmada kaydedilir.

Bu yaklaşıma bir LLM (Yoğunluk Tabanlı Öğrenme) eklendiğinde, yeni bir zeka katmanı ortaya çıkar: Doğal dili anlayabilen, niyetleri yorumlayabilen ve karmaşık komutları yerine getirebilen veya durumları analiz edebilen sohbet botları. Operatörün her bir komut dosyasını veya bayrağı tam olarak hatırlamasına gerek kalmadan.

Bu yakınlaşmanın tipik örnekleri şunlardır: LLM tarafından desteklenen bir bot, Prometheus metriklerini ve Loki günlüklerini okuyor. Birisi "X grubunun hizmeti yavaş" diye yazıp, çoğaltma işlemlerini artırmak, geri alma işlemi yapmak veya belirli testler başlatmak gibi eylemler önerdiğinde, bunların hepsi doğal bir dille açıklanmış oluyor.

Kültürel ve operasyonel düzeyde bu, şu anlama gelir: Daha hızlı kararlar, tekrarlayan görevlerde daha az manuel müdahale ve DevOps ekipleri için daha sorunsuz bir deneyim.Sürekli olarak acil durumlarla uğraşmaktan stratejik iyileştirmeler üzerinde çalışmaya geçiş yapan kişiler.

Üretimde LLM yaşam döngüsünün temel prensipleri

Ciddi bir Hukuk Yüksek Lisansı (LLM) programı yürütmek tek seferlik bir proje değildir, aksine sürekli bir süreçtir. Kendini tekrar eden ve her değişikliğin sistemin davranışını değiştirebildiği bir döngü.Her kuruluş bunu kendi gerçekliğine uyarlasa da, genellikle birbirini besleyen altı ana aşama vardır.

İlk olarak modelin eğitim veya adaptasyon aşamasıBu, temel bir modeli olduğu gibi kullanmaktan, kendi verilerinizle ince ayar, LoRa veya diğer ayarlama tekniklerini uygulamaya kadar değişebilir. Burada önemli olan sadece performans değil, eksiksiz bir kayıt bırakmaktır: veri kümeleri, uygulanan filtreler, hiperparametreler, belirteçleyici sürümleri, test edilen mimariler vb.

Bu aşama doğaçlama yapılır ve belgelenmezse, Model, yönetim olmadan doğuyor.Sonrasında, sistemin neden bu şekilde tepki verdiğini açıklamak veya bir denetim sırasında gerektiğinde belirli bir sonucu tekrarlamak neredeyse imkansız olacaktır.

İkinci aşama, modelin laboratuvardan çıkıp üretime girdiği dağıtım aşamasıdır. LLMOps'ta bu, sadece "onu bir konteynere koymak"tan ibaret değildir: Karar vermemiz gerekiyor. hangi donanımı kullanmalıUzun süreli çalışan bağlamlar için bellek yönetiminin nasıl yapılacağı, hangi küme topolojisinin uygulanacağı ve trafiğe göre ölçeklendirmenin nasıl gerçekleştirileceği konuları ele alınacaktır. Gecikme sürelerinin aşırı artmasına veya maliyetlerin karşılanamaz hale gelmesine neden olmadan.

İşte tam bu noktada işler devreye giriyor. sürekli davranış odaklı izlemeSadece CPU ve RAM'e bakmak yeterli değildir; yanıtların anlamsal kalitesini, stilin istikrarlılığını, hata oranını, belirteç başına maliyetin gelişimini, tehlikeli veya tutarsız yanıtların ortaya çıkışını ve farklı kullanım modelleri altında yanıt sürelerindeki değişiklikleri izlemek gereklidir.

Sonraki aşamalarda optimizasyon ve ince ayar işlemleri gerçekleştirilir: Dokunmatik istemleri görüntüleyin, RAG'ı ayarlayın, model varyantlarını test edin, nicelleştirme yapın, A/B testleri gerçekleştirin, anlamsal güvenlik politikalarını değiştirin veya iş kurallarını iyileştirin.Bu, veri, mühendislik ve işletme ekiplerinin bir araya gelerek önceliklerin belirlenmesinde nelerin esas alınacağına karar verdiği, neredeyse el işçiliğine dayalı bir süreç.

Sonuç olarak, tüm bunlar şu kapsamda yer alıyor: güvenlik ve yönetişim katmanları (erişim kontrolü, denetim, sızıntı önleme, kullanım limitleri, mevzuata uyum) ve sürekli güncelleme mantığı içinde, model ve ekosistemi veri, düzenlemeler ve iç ihtiyaçlardaki değişikliklere uyarlanır.

GenAIOps ve Azure'daki bildirim akışı yaklaşımı

LLMOps evreninde, bu yaşam döngüsünü yapılandırmak için çok özel öneriler bulunmaktadır. Kurumsal ortamda en gelişmiş olanlardan biri şudur: Azure Machine Learning üzerinde GenAIOps'un Azure DevOps ile entegrasyonunda kullanılan hızlı akış özelliğiBu çalışma, LLM tabanlı uygulamalar oluşturmak için oldukça sistematik bir yaklaşım öneriyor.

Komut istemi akışı sadece bir komut istemi düzenleyici değil; aynı zamanda LLM etkileşim akışlarının tasarlanması, test edilmesi, sürümlendirilmesi ve dağıtılması için eksiksiz bir platform.Basit durumlardan (tek bir komut istemi) çok sayıda düğüm, harici araçlar, kontroller ve otomatik değerlendirmeler içeren karmaşık düzenlemelere kadar.

Kritik bir özellik şudur: akışların merkezi deposuBu, kurumsal bir kütüphane görevi görür. Her ekibin kendi talimatlarını ayrı belgelerde veya kendi depolarında tutması yerine, bunlar net dallanmalar, revizyonlar ve geçmiş kayıtlarıyla tek bir yönetilen depoda birleştirilir.

Ayrıca platform, varyant ve hiperparametre deneme yetenekleri de ekliyor: Farklı komut istemi, model, sıcaklık ayarı veya güvenlik politikası kombinasyonlarını test etmek mümkündür. Akışın birden fazla düğümünde sonuçları net ölçütlerle karşılaştırın.

Dağıtım konusunda, bildirim akışına sahip GenAIOps kullanılıyor. Bu, hem iş akışını hem de işlem oturumunu kapsayan Docker imajları oluşturur.Bunlar Azure App Services, Kubernetes veya yönetilen süreçler gibi ortamlarda çalışmaya hazır haldedir. Bu temelden yola çıkarak, gerçek dünya ortamlarında akış sürümlerini karşılaştırmak için A/B dağıtımları mümkün hale gelir.

Bir diğer güçlü yönü ise veri kümeleri ve akışlar arasındaki ilişkilerin yönetimidir. Her değerlendirme akışı, birden fazla standart ve test veri kümesiyle çalışabilir.Bu, bir ürünü son kullanıcılara sunmadan önce farklı senaryolardaki davranışları doğrulamayı mümkün kılar.

Platform ayrıca, veri kümelerinin ve akışların yeni sürümlerini yalnızca gerçek değişiklikler olduğunda otomatik olarak kaydeder ve CSV ve HTML gibi formatlarda kapsamlı raporlar oluşturur. Verilere dayalı kararları desteklemek, sezgiye değil.

GenAIOps'un bildirim akışıyla birlikte dört aşaması

GenAIOps yaklaşımı, yaşam döngüsünü dört net şekilde farklılaştırılmış aşamaya ayırarak, "yapay zeka ile denemeler yapıp neler olacağını görüyoruz" şeklindeki tipik kaostan kaçınmaya yardımcı olur.

İlk aşama olan başlatma, şunlara odaklanır: İş hedefini kesin olarak tanımlayın ve temsili veri örnekleri toplayın.Burada, istem akışının temel yapısı özetlenmiş ve mimarisi tasarlanmıştır; bu mimari daha sonra iyileştirilecektir.

Deney aşamasında, bu akış örnek verilere uygulanır ve İstemlerin, modellerin ve yapılandırmaların farklı varyantları değerlendirilir.Minimum kalite ve tutarlılık standartlarını karşılayan kabul edilebilir bir kombinasyon bulunana kadar süreç aralıksız olarak tekrarlanır.

Sonraki aşama, değerlendirme ve iyileştirme aşamasıdır; bu aşamada Daha büyük ve daha çeşitli veri kümeleri, titiz karşılaştırmalı testler yürütmek için kullanılır.Akış, tanımlanmış standartlarla uyumlu, tutarlı bir performans sergilediğinde ancak bir sonraki adıma geçmeye hazır kabul edilir.

Son olarak, uygulama aşamasında, akış verimli hale getirilmek üzere optimize edilir ve üretim ortamına dağıtılır. A/B test uygulama seçenekleri, izleme, kullanıcı geri bildirimi toplama ve sürekli iyileştirme döngüleri dahil.Hiçbir şey kesinleşmiş değil: akış, gerçek kullanımda gözlemlenenlere göre sürekli olarak ayarlanıyor.

Bu metodoloji, kod öncelikli, önceden oluşturulmuş işlem hatları içeren bir GenAIOps depo şablonunda paketlenmiştir ve LLM tabanlı uygulamaların geliştirilmesi, değerlendirilmesi ve dağıtımı için yerel ve bulut tabanlı yürütme araçları. Her projede tekerleği yeniden icat etmeden.

Azure DevOps ile entegrasyon: depolar, işlem hatları ve kimlik doğrulama

GenAIOps'u teoriden gerçek bir organizasyona taşımak için Azure DevOps ile entegre etmek çok önemlidir. Tipik şablon şu şekilde başlar: Azure Repos'ta main ve development olmak üzere iki ana dalı olan bir depo.Bu durum, farklı ortamları ve kod tanıtım stratejilerini yansıtmaktadır.

Örnek depo GitHub'dan klonlanır, Azure Repos ile ilişkilendirilir ve Genellikle geliştirme aşamasından özellik dalları oluşturarak çalışırız.Değişiklikler, otomatik olarak doğrulama ve deneme süreçlerini tetikleyen çekme istekleri aracılığıyla gönderilir.

Azure DevOps'un Azure Machine Learning ve diğer hizmetlerle etkileşim kurabilmesi için yapılandırılması gerekmektedir. Azure'da teknik kimlik olarak bir hizmet varlığıBu kimlik, Azure DevOps hizmet bağlantısında kullanılır, böylece işlem hatları, anahtarlar düz metin olarak ifşa edilmeden kimlik doğrulaması yapılır.

Genellikle bu varlık, ML aboneliği veya çalışma kaynağı üzerinde Sahip izinlerine sahiptir, böylece İşlem hatları, uç noktaları sağlayabilir, modelleri kaydedebilir ve anahtar depolarındaki politikaları güncelleyebilir.Güvenliği artırmak istiyorsanız, izinleri işleyen YAML adımlarını uyarlayarak rolü Katkıda Bulunan (Contributor) olarak değiştirebilirsiniz.

Ek olarak, Azure DevOps'ta bir değişken grubu oluşturulur. Hizmet bağlantı adı veya kaynak tanımlayıcıları gibi hassas verileri saklar.Bu değişkenler, kritik bilgilerin kodda sabit olarak yazılmasını önleyerek, işlem hatlarına bir ortam olarak sunulur.

Yerel ve uzak depoları yapılandırmak size şunları sağlar: Geliştirme dalı, dal politikalarıyla korunmaktadır. Birleştirme işlemine izin verilmeden önce bir çekme isteği işlem hattının yürütülmesini gerektiren bu işlem hattı, derleme doğrulamalarını ve deneme akışlarını yöneterek hatalı değişikliklerin ortaya çıkmasını önler.

Kod geliştirme aşamasına girdiğinde, bir geliştirme işlem hattı tetiklenir. Bu, CI ve CD'nin tüm aşamalarını içerir.Deneyler ve değerlendirmeler yürütmek, Azure ML model kayıt defterinde akışları kaydetmek, uç noktaları ve temel testleri dağıtmak ve yeni oluşturulan uç noktalara entegrasyon yapmak.

Aynı model, üretim ortamlarına bağlı bir sürüm veya yayın dalı boyunca tekrarlanır. Orada, Üretim ortamı için CI/CD işlem hatları, deneme, değerlendirme ve dağıtım döngüsünü tekrarlar.Ancak altyapı ve üretim seviyesindeki verilerde, daha fazla kontrol ve gerekirse ek manuel incelemeler yapılacaktır.

Bu süreçlere dahil edilen önemli bir ayrıntı da "insan döngüsü incelemesi"dir: CI aşamasından sonra, CD, bir kişi tarafından manuel olarak onaylanana kadar kilitli kalır. Devam işlemi Azure Pipelines arayüzünden gerçekleşir. Belirli bir süre içinde (örneğin, 60 dakika) onaylanmazsa, işlem reddedilir.

Yerel uygulama ve LLM sağlayıcılarıyla bağlantı

Her şey işlem hatları etrafında dönmüyor: GenAIOps ayrıca şunları da destekliyor: hızlı deneyler için yerel yürütmeŞablon deposunu klonlayabilir, kök dizinde bir .env dosyası oluşturabilir ve bu dosya içinde Azure OpenAI veya diğer uyumlu uç noktalara olan bağlantıları tanımlayabilirsiniz.

Bu bağlantılar, api_key, api_base, api_type ve api_version gibi parametreleri içerir ve Akışlar içinde isimleriyle anılırlar. (Örneğin, belirli bir API sürümüne sahip "aoai" adlı bir bağlantı). Bu şekilde, kodda değişiklik yapılmadan aynı akış hem yerel olarak hem de bulutta yürütülebilir.

Bu modu kullanmak için yapmanız gerekenler şunlardır: Sanal bir ortam veya conda oluşturun ve gerekli bağımlılıkları yükleyin. (promptflow, promptflow-tools, promptflow-sdk, openai, jinja2, python-dotenv, vb.). Buradan, yerel bir yürütme klasöründe test komut dosyaları yazabilir ve tanımlanmış akışlar üzerinde deneyler çalıştırabilirsiniz.

Bulut/yerel sunucu ikiliği, olgun bir DevOps zihniyetiyle çok iyi örtüşüyor: Öncelikle yerel olarak küçük ölçekte test edilir, resmi olarak süreçlerde doğrulanır ve ardından kontroller ve denetimlerle daha üst düzey ortamlara aktarılır.Her şey Git'te sürümlendiriliyor ve Azure DevOps'a bağlanıyor.

Yapay zeka ve LLMOps içeren bir DevOps ekosisteminde tipik araçlar

Azure'ın sunduğu özel özelliklerin ötesinde, yapay zeka ve LLMOps içeren modern bir DevOps ekosistemi genellikle şunlara dayanır: ChatOps, model düzenleme, izleme ve gözlemlenebilirlik konularını kapsayan bir dizi araç..

ChatOps katmanında, genellikle birleştirme işlemi yapılır. Hubot gibi botlarla SlackMicrosoft Teams'i Power Virtual Agents tabanlı aracılarla veya Discord'u Botpress veya Rasa gibi çerçevelerle birlikte kullanarak, işlem hatlarına, izleme sistemlerine ve dahili hizmetlere bağlanan özel asistanlar oluşturabilirsiniz.

LLMOps/MLOps düzleminde sıkça görülürler. Kubeflow ve MLflow gibi platformlar İşlem hatlarını, model kayıtlarını ve deneyleri yönetmenin yanı sıra, gelişmiş metrik takibi, çalışma karşılaştırmaları veya ayrıntılı görselleştirmeler için Ağırlıklar ve Sapmalar (W&B) gibi özel araçlar da mevcuttur.

LLM üzerinde uygulama geliştirmek için genellikle şu yöntem kullanılır: LangChain veya OpenLLM tipi kütüphaneler gibi çerçevelerBu çözümler, istem zincirlerinin, harici verilere bağlantıların, araçların ve çok adımlı ajanların bir araya getirilmesini kolaylaştırır. Eş zamanlı olarak, istemlerin, yanıtların, maliyetlerin ve kalitenin izlenmesini sağlayan LLM'ye özgü gözlemlenebilirlik çözümleri ortaya çıkmaktadır.

Klasik DevOps ile entegre edildiğinde, Jenkins veya GitLab CI gibi araçlar CI/CD kısmı için önemini korumaktadır. Kubernetes ve ArgoCD ile bulut tabanlı sürekli dağıtımÖlçümler, gösterge panelleri ve kayıtlar için Prometheus, Grafana ve Loki gibi gözlemlenebilirlik yığınları.

Zorluklar, sınırlamalar ve aşamalı benimseme

Bu uygulamaların ve araçların kullanımı bedavaya gelmiyor. İstemleri, model sürümlerini ve akış varyantlarını yönetmenin karmaşıklığı özellikle oldukça büyüktür. birden fazla ekip aynı anda çalıştığında —uygulamanın tavsiye edildiği bir senaryo GitOps gibi stratejiler Değişiklikleri ve uygulamaları koordine etmek.

Ek olarak, ChatOps botları ve eylem kapasitesine sahip LLM'lerin kendileri de mevcuttur. Bunlar önemli güvenlik riskleri oluşturmaktadır. Üretim ortamlarında aşırı yetkilere sahip olmaları veya veri erişim yüzeylerinin düzgün bir şekilde kontrol edilmemesi durumunda sorun oluşabilir.

Buna eklenen Hassas lisanslara veya ticari API'lere sahip açık kaynak modellerine bağımlılık Bu durum koşulları, fiyatları veya sınırları değiştirebilir. Dahası, üretimde LLM'lerin sağlam bir şekilde değerlendirilmesi hala açık bir alan olup, birçok soru hâlâ cevapsız kalmaktadır.

Bu nedenle, DevOps içinde LLMOps ve ChatOps'un benimsenmesini ele almak mantıklıdır. aşamalı ve kontrollü bir şekildeBasit botlar kullanarak tekrarlayan görevleri otomatikleştirmekle başlayarak (yeniden başlatmalar, günlük sorguları, derleme etiketleme vb.).

Daha sonra tanıtılabilirler. LLM, destek görevleri, olay sınıflandırması veya hata ayıklama yardımı için kullanılır.Örneğin, hataları log kayıtlarına dayanarak açıklayarak veya iç dokümantasyona dayanarak çözüm önerileri sunarak.

Klasik ML operasyonu istikrara kavuştuktan sonra, sıra şunlara gelir: LLMOps'u özel dil modelleriyle ele almak Müşteri hizmetleri, DevSecOps veya QA gibi alanlarda, önceki aşamalarda öğrenilen her şeyden faydalanmak.

Tüm bu uygulamaların işaret ettiği ufuk şudur: diyalog odaklı, tahmine dayalı ve giderek daha otonom hale gelen bir mühendislik ortamıGeliştirme ve işletmenin büyük bir kısmının doğal dilde ifade edildiği ve yapay zekanın dağıtımlar, ölçeklendirme veya geri alma işlemleri hakkında proaktif kararlar alınmasına yardımcı olduğu bir ortam.

DevOps, ChatOps, MLOps, GenAIOps ve LLMOps'tan oluşan bu yapboz tamamlandığında, kuruluşlar şunlara sahip olur: LLM tabanlı sistemlerin oluşturulması ve sürdürülmesi için, gerçek anlamda değer sağlayan sağlam bir çerçeve.Üretime geçer geçmez dağılan basit prototipler veya izole testlerle yetinmek yerine, kalite, maliyet, güvenlik ve işletmeyle uyum üzerinde kontrolü sürdürmek.