Koleksiyonlar ile düzeninizi koruyun İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Denemeler, projenin uygulanabilirliğini artırır. Bunlar test edilebilir ve yeniden üretilebilir hipotezlerdir. Deneme yaparken amaç, çeşitli model mimarilerini ve özelliklerini değerlendirerek sürekli ve artımlı iyileştirmeler yapmaktır. Deneme yaparken aşağıdakileri yapmanız gerekir:
Referans performansı belirleyin.Referans metriği oluşturarak başlayın. Referans değer, denemeleri karşılaştırmak için bir ölçüm çubuğu görevi görür.
Bazı durumlarda, mevcut makine öğrenimi dışı çözüm ilk temel metriği sağlayabilir. Şu anda mevcut bir çözüm yoksa basit bir mimariye ve birkaç özelliğe sahip bir makine öğrenimi modeli oluşturun ve bu modelin metriklerini referans olarak kullanın.
Tek ve küçük değişiklikler yapın. Tek seferde yalnızca tek bir küçük değişiklik yapın (ör. hiper parametreler, mimari veya özellikler). Değişiklik modeli iyileştirirse söz konusu modelin metrikleri, gelecekteki denemelerle karşılaştırılacak yeni referans olur.
Aşağıda, tek bir küçük değişiklik yapan deneme örnekleri verilmiştir:
X özelliğini içerir.
İlk gizli katmanda 0,5 bırakma oranı kullanın.
Y özelliğinin doğal logaritma dönüşümünü alır.
öğrenme hızını 0,001 olarak değiştirin.
Denemelerin ilerleme durumunu kaydedin. Büyük olasılıkla çok sayıda deneme yapmanız gerekir. Referans değere kıyasla düşük (veya nötr) tahmin kalitesine sahip denemeler izlemek için yine de yararlıdır. Hangi yaklaşımların işe yaramayacağını gösterirler. İlerleme genellikle doğrusal olmadığından, temel kaliteyi artırma konusundaki ilerlemenizin yanı sıra işe yaramadığını tespit ettiğiniz tüm yöntemleri vurgulayarak sorun üzerinde çalıştığınızı göstermeniz önemlidir.
Gerçek dünyadaki bir veri kümesinde her tam eğitim saatler (veya günler) sürebileceğinden, alanı hızlıca keşfetmek için aynı anda birden fazla bağımsız deneme çalıştırabilirsiniz. İterasyona devam ettikçe, üretim için ihtiyaç duyacağınız kalite seviyesine yaklaşırsınız.
Deneysel sonuçlarda gürültü
Deneme sonuçlarında, modelde veya verilerde yapılan değişikliklerden kaynaklanmayan ve yaptığınız bir değişikliğin modeli gerçekten iyileştirip iyileştirmediğini belirlemeyi zorlaştıran gürültülerle karşılaşabileceğinizi unutmayın. Aşağıda, deneysel sonuçlarda gürültü oluşturabilecek durumlara örnekler verilmiştir:
Değişken başlatma: Modelin değişkenlerinin başlatılma şekli de performansını etkileyebilir.
Asenkron paralellik: Model, asenkron paralellik kullanılarak eğitildiyse modelin farklı bölümlerinin güncellenme sırası da performansını etkileyebilir.
Küçük değerlendirme grupları: Değerlendirme grubu çok küçükse modelin genel performansını temsil etmeyebilir ve modelin kalitesinde eşit olmayan varyasyonlar oluşabilir.
Bir denemeyi birden çok kez çalıştırmak, deneme sonuçlarını doğrulamaya yardımcı olur.
Deneme uygulamaları konusunda uyumlu olun
Ekibiniz, "deneme"nin tam olarak ne olduğunu net bir şekilde anlamalı ve belirli bir uygulama ve yapı grubuna sahip olmalıdır. Aşağıdakileri özetleyen dokümanlar sağlamanız gerekir:
Yapılar. Bir denemenin yapıları nedir? Çoğu durumda deneme, genellikle denemeler arasındaki değişiklikleri ve bunların model kalitesini nasıl etkilediğini gösteren meta verileri (özellikler ve hiper parametreler gibi) günlüğe kaydederek yeniden üretilebilecek test edilmiş bir hipotezdir.
Kodlama uygulamaları. Herkes kendi deneme ortamlarını mı kullanacak? Herkesin çalışmalarını ortak kitaplıklarda birleştirmek ne kadar mümkün (veya kolay) olacak?
Yinelenebilirlik ve izleme. Yinelenebilirlik standartları nelerdir? Örneğin, ekibin aynı veri ardışık düzenini ve sürüm oluşturma uygulamalarını kullanması gerekir mi yoksa yalnızca grafiklerin gösterilmesi uygun mu? Deneysel veriler nasıl kaydedilecek: SQL sorgusu olarak mı yoksa model anlık görüntüleri olarak mı? Her denemeden gelen günlükler nerede belgelenecek: dokümanda, e-tabloda veya denemeleri yönetmek için bir içerik yönetim sisteminde mi?
Yanlış tahminler
Gerçek hayattan hiçbir model mükemmel değildir. Sisteminiz yanlış tahminleri nasıl ele alacak? Bu sorunlarla nasıl başa çıkacağınızı erkenden düşünmeye başlayın.
En iyi uygulamalar stratejisi, kullanıcıları yanlış tahminleri doğru şekilde etiketlemeye teşvik eder. Örneğin, posta uygulamaları, kullanıcıların spam klasörüne taşıdıkları e-postaları ve bunun tam tersini günlüğe kaydederek yanlış sınıflandırılmış e-postaları yakalar. Kullanıcılardan kesin referans etiketleri toplayarak veri toplama ve model yeniden eğitimi için otomatik geri bildirim döngüleri tasarlayabilirsiniz.
Kullanıcı arayüzüne yerleştirilmiş anketler kullanıcı geri bildirimlerini yakalasa da verilerin genellikle niteliksel olduğunu ve yeniden eğitim verilerine dahil edilemeyeceğini unutmayın.
Uçtan uca bir çözüm uygulama
Ekibiniz model üzerinde deneme yaparken nihai ardışık düzenin bazı bölümlerini oluşturmaya başlamak iyi bir fikirdir (bunu yapacak kaynaklara sahipseniz).
Veri girişi ve modelin yeniden eğitilmesi gibi ardışık düzenin farklı parçalarını oluşturmak, nihai modeli üretime taşımayı kolaylaştırır. Örneğin, verileri beslemek ve tahminleri sunmak için uçtan uca bir ardışık düzen elde etmek, ekibin modeli ürüne entegre etmeye ve erken aşamada kullanıcı testi yapmaya başlamasına yardımcı olabilir.
Durdurulan projelerle ilgili sorunları giderme
Projenin ilerlemesinin durduğu senaryolarla karşılaşabilirsiniz. Ekibiniz, umut verici bir deneme üzerinde çalışıyor olabilir ancak modelin iyileştirilmesi konusunda haftalardır başarılı olamamaktadır. Bu durumda ne yapmanız gerekir? Aşağıda, olası bazı yaklaşımlar belirtilmiştir:
Stratejik. Sorunu yeniden çerçevelendirmeniz gerekebilir. Deneme aşamasında zaman geçirdikten sonra sorunu, verileri ve olası çözümleri daha iyi anlamış olabilirsiniz. Alan hakkında daha fazla bilgi sahibi olarak sorunu daha net bir şekilde tanımlayabilirsiniz.
Örneğin, başlangıçta bir sayısal değeri tahmin etmek için doğrusal regresyon kullanmak isteyebilirsiniz. Maalesef veriler, uygulanabilir bir doğrusal regresyon modeli eğitmek için yeterince iyi değildi. Daha ayrıntılı bir analiz, sorunun bir örneğin belirli bir değerin üzerinde mi yoksa altında mı olduğunu tahmin ederek çözülebileceğini gösterebilir. Bu sayede sorunu ikili sınıflandırma problemi olarak yeniden çerçevelendirebilirsiniz.
İlerleme beklenenden yavaşsa pes etmeyin. Sorunu çözmenin tek yolu zaman içinde kademeli iyileştirmeler yapmak olabilir. Daha önce de belirtildiği gibi, haftadan haftaya aynı miktarda ilerleme elde edemeyeceğinizi unutmayın. Bir modelin üretime hazır sürümünü elde etmek genellikle çok zaman alır. Model iyileştirmesi düzensiz ve öngörülemez olabilir. Yavaş ilerleme dönemlerinin ardından ani iyileştirmeler görülebilir veya bunun tam tersi de olabilir.
Teknik. Yanlış tahminleri teşhis edip analiz etmek için zaman harcamayın. Bazı durumlarda, birkaç yanlış tahmini ayırıp bu örneklerde modelin davranışını teşhis ederek sorunu bulabilirsiniz. Örneğin, mimari veya verilerle ilgili sorunları tespit edebilirsiniz. Diğer durumlarda ise daha fazla veri elde etmek yardımcı olabilir. Doğru yolda olduğunuzu gösteren daha net bir sinyal alabilirsiniz veya yaklaşımda başka sorunlar olduğunu gösteren daha fazla gürültü oluşabilir.
İnsan tarafından etiketlenmiş veri kümeleri gerektiren bir sorun üzerinde çalışıyorsanız model değerlendirmesi için etiketli bir veri kümesi elde etmek zor olabilir. Değerlendirme için ihtiyaç duyacağınız veri kümelerini edinmek üzere kaynaklar bulun.
Çözüm olmayabilir. Yaklaşımınızı zamana göre planlayın ve zaman aralığı içinde ilerleme kaydedemezseniz durdurun. Ancak güçlü bir sorun beyanınız varsa muhtemelen bir çözüme ihtiyaç vardır.
Öğrendiklerinizi test etme
Bir ekip üyesi, temel model metriğini iyileştiren bir hiper parametre kombinasyonu buldu. Ekibin diğer üyeleri ne yapmalı?
Belki bir hiper parametre ekleyin ancak denemelerinize devam edin.
Doğru. Hiperparametrelerinden biri makul bir seçim gibi görünüyorsa deneyin. Ancak tüm hiper parametre seçimleri her deneme bağlamında anlamlı olmayabilir.
Mevcut denemelerindeki tüm hiper parametreleri, iş arkadaşlarınınkilerle eşleşecek şekilde değiştirir.
Bir modeli iyileştiren hiperparametrelerin farklı bir modeli de iyileştirdiği anlamına gelmez. Diğer ekip üyeleri de denemelerine devam etmelidir. Bu sayede, temel değer daha da iyileştirilebilir.
Modeli uygulamak için kullanılacak uçtan uca bir ardışık düzen oluşturmaya başlayın.
Referans değeri iyileştiren bir modelin, nihayetinde üretimde kullanılacağı anlamına gelmez. Denemelerine devam etmeleri gerekiyor. Bu sayede, temel değer daha da iyileştirilebilir.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 2025-07-27 UTC."],[[["\u003cp\u003eExperiments involve making single, small, iterative changes to model features, architecture, or hyperparameters to improve performance compared to a baseline.\u003c/p\u003e\n"],["\u003cp\u003eIt's crucial to track all experimental results, including unsuccessful ones, to understand which approaches work and which don't.\u003c/p\u003e\n"],["\u003cp\u003eTeams should establish clear experimentation practices, including defining artifacts, coding standards, reproducibility measures, and tracking methods.\u003c/p\u003e\n"],["\u003cp\u003ePlan for handling wrong predictions early on, potentially by incorporating user feedback for model improvement.\u003c/p\u003e\n"],["\u003cp\u003eConsider building parts of the final pipeline alongside experimentation to facilitate a smoother transition to production.\u003c/p\u003e\n"]]],[],null,["Experiments drive a project toward viability. They are testable and\nreproducible hypotheses. When running experiments, the\ngoal is to make continual, incremental improvements by evaluating a variety of\nmodel architectures and features. When experimenting, you'll want to do\nthe following:\n\n- **Determine baseline performance.** Start by establishing a\n [baseline](/machine-learning/glossary#baseline) metric. The baseline\n acts as a measuring stick to compare experiments against.\n\n In some cases, the current non-ML solution can provide the first baseline\n metric. If no solution currently exists, create a ML model with a simple\n architecture, a few features, and use its metrics as the baseline.\n- **Make single, small changes.** Make only a single, small change at a time,\n for example, to the hyperparameters, architecture, or features. If the\n change improves the model, that model's metrics become the new baseline to\n compare future experiments against.\n\n The following are examples of experiments that make a single, small change:\n - include feature *X*.\n - use 0.5 dropout on the first hidden layer.\n - take the log transform of feature *Y*.\n - change the learning rate to 0.001.\n- **Record the progress of the experiments.** You'll most likely need to do\n lots of experiments. Experiments with poor (or neutral) prediction quality\n compared to the baseline are still useful to track. They signal which\n approaches won't work. Because progress is typically non-linear, it's\n important to show that you're working on the problem by highlighting all\n the ways you found that don't work---in addition to your progress at\n increasing the baseline quality.\n\nBecause each full training on a real-world dataset can take hours (or days),\nconsider running multiple independent experiments concurrently to explore the\nspace quickly. As you continue to iterate, you'll hopefully get closer and\ncloser to the level of quality you'll need for production.\n\nNoise in experimental results\n\nNote that you might encounter noise in experimental results that aren't from\nchanges to the model or the data, making it difficult to determine if a change\nyou made actually improved the model. The following are examples of things that\ncan produce noise in experimental results:\n\n- Data shuffling: The order in which the data is presented to the model can\n affect the model's performance.\n\n- Variable initialization: The way in which the model's\n variables are initialized can also affect its performance.\n\n- Asynchronous parallelism: If the model is trained using asynchronous\n parallelism, the order in which the different parts of the model are updated\n can also affect its performance.\n\n- Small evaluation sets: If the evaluation set is too small, it may\n not be representative of the overall performance of the model, producing\n uneven variations in the model's quality.\n\nRunning an experiment multiple times helps confirm experimental results.\n\nAlign on experimentation practices\n\nYour team should have a clear understanding of what exactly an \"experiment\" is,\nwith a defined set of practices and artifacts. You'll want documentation that\noutlines the following:\n\n- **Artifacts.** What are the artifacts for an experiment? In most cases, an\n experiment is a tested hypothesis that can be reproduced, typically by\n logging the metadata (like the features and hyperparameters) that indicate\n the changes between experiments and how they affect model quality.\n\n- **Coding practices.** Will everyone use their own experimental environments?\n How possible (or easy) will it be to unify everyone's work into shared\n libraries?\n\n- **Reproducibility and tracking.** What are the standards for\n reproducibility? For instance, should the team use the same data pipeline\n and versioning practices, or is it OK to show only plots? How will\n experimental data be saved: as SQL queries or as model snapshots? Where will\n the logs from each experiment be documented: in a doc, a spreadsheet, or a\n CMS for managing experiments?\n\nWrong predictions\n\nNo real-world model is perfect. How will your system handle wrong predictions?\nBegin thinking early on about how to deal with them.\n\nA best-practices strategy encourages users to correctly label wrong predictions.\nFor example, mail apps capture misclassified email by logging the mail users\nmove into their spam folder, as well as the reverse. By capturing ground truth\nlabels from users, you can design automated feedback loops for data collection\nand model retraining.\n\nNote that although UI-embedded surveys capture user feedback, the data is\ntypically qualitative and can't be incorporated into the retraining data.\n\nImplement an end-to-end solution\n\nWhile your team is experimenting on the model, it's a good idea to start\nbuilding out parts of the final pipeline (if you have the resources to do so).\n\nEstablishing different pieces of the pipeline---like data intake and model\nretraining---makes it easier to move the final model to production. For\nexample, getting an end-to-end pipeline for ingesting data and serving\npredictions can help the team start integrating the model into the product and\nto begin conducting early-stage user testing.\n\nTroubleshooting stalled projects\n\nYou might be in scenarios where a project's progress stalls. Maybe your\nteam has been working on a promising experiment but hasn't had success\nimproving the model for weeks. What should you do? The following are some\npossible approaches:\n\n- **Strategic.** You might need to reframe the problem. After spending time in\n the experimentation phase, you probably understand the problem, the data,\n and the possible solutions better. With a deeper knowledge of the domain,\n you can probably frame the problem more precisely.\n\n For instance, maybe you initially wanted to use linear regression to predict\n a numeric value. Unfortunately, the data wasn't good enough to train a\n viable linear regression model. Maybe further analysis reveals the problem\n can be solved by predicting whether an example is above or below a specific\n value. This lets you reframe the problem as a binary classification one.\n\n If progress is slower than expected, don't give up. Incremental improvements\n over time might be the only way to solve the problem. As noted earlier,\n don't expect the same amount of progress week over week. Often, getting a\n production-ready version of a model requires substantial amounts of time.\n Model improvement can be irregular and unpredictable. Periods of slow\n progress can be followed by spikes in improvement, or the reverse.\n- **Technical.** Spend time diagnosing and analyzing wrong predictions. In\n some cases, you can find the issue by isolating a few wrong predictions and\n diagnosing the model's behavior in those instances. For example, you might\n uncover problems with the architecture or the data. In other cases,\n getting more data can help. You might get a clearer signal that suggests\n you're on the right path, or it might produce more noise, indicating other\n issues exist in the approach.\n\n If you're working on a problem that requires human-labeled datasets,\n getting a labeled dataset for model evaluation might be hard to obtain. Find\n resources to get the datasets you'll need for evaluation.\n\nMaybe no solution is possible. Time-box your approach, stopping if you haven't\nmade progress within the timeframe. However, if you have a strong problem\nstatement, then it probably warrants a solution.\n\nCheck Your Understanding \nA team member found a combination of hyperparameters that improves the baseline model metric. What should the other members of the team do? \nMaybe incorporate one hyperparameter, but continue with their experiments. \nCorrect. If one of their hyperparameters seems like a reasonable choice, try it. However, not all hyperparameter choices make sense in every experimental context. \nChange all their hyperparameters in their current experiment to match their co-worker's. \nHyperparameters that improved one model doesn't mean they'll also improve a different model. The other teammates should continue with their experiments, which might actually improve the baseline even more later on. \nStart building an end-to-end pipeline that will be used to implement the model. \nA model that improves the baseline doesn't mean it's the model that will ultimately be used in production. They should continue with their experiments, which might actually improve the baseline even more later on.\n| **Key Terms:**\n|\n| - [baseline](/machine-learning/glossary#baseline)"]]
