بسیاری از مجموعه داده ها داده ها را در جداول (شبکه) ذخیره می کنند، به عنوان مثال، به عنوان مقادیر جدا شده با کاما (CSV) یا مستقیماً از صفحات گسترده یا جداول پایگاه داده. جداول یک قالب ورودی بصری برای مدل های یادگیری ماشین هستند. شما می توانید هر سطر از جدول را به عنوان مثال و هر ستون را به عنوان یک ویژگی یا برچسب بالقوه تصور کنید. گفته می شود، مجموعه داده ها همچنین ممکن است از فرمت های دیگر، از جمله فایل های گزارش و بافرهای پروتکل مشتق شوند.
صرف نظر از فرمت، مدل ML شما فقط به اندازه داده هایی است که روی آن آموزش می دهد. این بخش ویژگی های داده های کلیدی را بررسی می کند.
انواع داده ها
یک مجموعه داده می تواند شامل انواع مختلفی از انواع داده ها باشد، از جمله، اما مطمئناً به موارد زیر محدود نمی شود:
داده های عددی که در یک واحد جداگانه پوشش داده شده است
داده های طبقه بندی شده، که در یک واحد جداگانه پوشش داده شده است
زبان انسانی، از جمله کلمات و جملات جداگانه، تا کل اسناد متنی
چند رسانه ای (مانند تصاویر، فیلم ها و فایل های صوتی)
به عنوان یک قانون کلی، مدل شما باید حداقل بر اساس یک مرتبه بزرگی (یا دو) نمونه بیشتر از پارامترهای قابل آموزش تمرین کند. با این حال، مدل‌های خوب معمولاً بر روی نمونه‌های بسیار بیشتر از آن آموزش می‌بینند.
مدل‌هایی که روی مجموعه داده‌های بزرگ با ویژگی‌های کم آموزش داده می‌شوند، معمولاً از مدل‌هایی که بر روی مجموعه داده‌های کوچک با ویژگی‌های زیاد آموزش داده می‌شوند، بهتر عمل می‌کنند. گوگل در طول تاریخ موفقیت زیادی در آموزش مدل های ساده بر روی مجموعه داده های بزرگ داشته است.
مجموعه داده های مختلف برای برنامه های مختلف یادگیری ماشین ممکن است به مقادیر بسیار متفاوتی از مثال ها برای ساخت یک مدل مفید نیاز داشته باشد. برای برخی از مشکلات نسبتاً ساده، چند ده مثال ممکن است کافی باشد. برای مشکلات دیگر، یک تریلیون مثال ممکن است کافی نباشد.
اگر در حال تطبیق یک مدل موجود که قبلاً روی مقادیر زیادی داده از همان طرح آموزش دیده است، نتایج خوبی از یک مجموعه داده کوچک به دست آورید.
کیفیت و قابلیت اطمینان داده ها
همه کیفیت بالا را به کیفیت پایین ترجیح می دهند، اما کیفیت آنقدر مفهوم مبهم است که می توان آن را به روش های مختلف تعریف کرد. این دوره کیفیت را به صورت عملی تعریف می کند:
مجموعه داده با کیفیت بالا به مدل شما کمک می کند تا به هدف خود دست یابد. مجموعه داده با کیفیت پایین، مدل شما را از دستیابی به هدفش باز می دارد.
معمولاً یک مجموعه داده با کیفیت بالا نیز قابل اعتماد است. قابلیت اطمینان به میزان اعتماد شما به داده های خود اشاره دارد. مدلی که بر روی یک مجموعه داده قابل اعتماد آموزش داده شده است، احتمال بیشتری دارد که پیش‌بینی‌های مفیدی را نسبت به مدلی که بر روی داده‌های غیرقابل اعتماد آموزش دیده است، ارائه دهد.
در اندازه گیری قابلیت اطمینان، باید تعیین کنید:
خطاهای برچسب چقدر رایج است؟ برای مثال، اگر داده‌های شما توسط انسان‌ها برچسب‌گذاری شده باشد، رتبه‌دهندگان انسانی شما چند بار مرتکب اشتباه می‌شوند؟
آیا ویژگی های شما نویز دارد ؟ یعنی آیا مقادیر موجود در ویژگی های شما دارای خطا هستند؟ واقع بین باشید - نمی توانید مجموعه داده های خود را از همه نویزها پاک کنید. مقداری صدا طبیعی است. به عنوان مثال، اندازه‌گیری‌های GPS در هر مکانی همیشه هفته به هفته کمی نوسان دارند.
آیا داده ها به درستی برای مشکل شما فیلتر شده اند؟ به عنوان مثال، آیا مجموعه داده شما باید شامل پرس و جوهای جستجو از ربات ها باشد؟ اگر در حال ساختن یک سیستم تشخیص هرزنامه هستید، احتمالاً پاسخ مثبت است. با این حال، اگر در تلاش برای بهبود نتایج جستجو برای انسان هستید، خیر.
موارد زیر دلایل رایج داده های غیر قابل اعتماد در مجموعه داده ها هستند:
مقادیر حذف شده به عنوان مثال، شخصی فراموش کرده است مقداری را برای سن خانه وارد کند.
نمونه های تکراری به عنوان مثال، یک سرور به اشتباه همان ورودی های گزارش را دو بار آپلود کرد.
مقادیر بد ویژگی به عنوان مثال، شخصی یک رقم اضافی تایپ کرده است، یا یک دماسنج در زیر نور خورشید باقی مانده است.
برچسب های بد به عنوان مثال، شخصی به اشتباه تصویر یک درخت بلوط را به عنوان درخت افرا برچسب گذاری کرده است.
بخش های بد داده ها به عنوان مثال، یک ویژگی خاص بسیار قابل اعتماد است، به جز روزی که شبکه مدام خراب می شود.
توصیه می کنیم از اتوماسیون برای پرچم گذاری داده های غیرقابل اعتماد استفاده کنید. به عنوان مثال، آزمون‌های واحدی که طرح‌واره داده‌های رسمی خارجی را تعریف می‌کنند یا به آن تکیه می‌کنند، می‌توانند مقادیری را که خارج از محدوده تعریف‌شده قرار می‌گیرند پرچم‌گذاری کنند.
نمونه های کامل در مقابل نمونه های ناقص
در یک دنیای کامل، هر نمونه کامل است. یعنی هر مثال حاوی یک مقدار برای هر ویژگی است.
شکل 1. یک مثال کامل.
متأسفانه، نمونه های دنیای واقعی اغلب ناقص هستند، به این معنی که حداقل یک مقدار ویژگی از دست رفته است.
شکل 2. یک مثال ناقص.
مدل را بر روی نمونه های ناقص آموزش ندهید. در عوض، نمونه‌های ناقص را با انجام یکی از موارد زیر اصلاح یا حذف کنید:
نمونه های ناقص را حذف کنید.
مقادیر گمشده را وارد کنید . یعنی با ارائه حدس های مستدل برای مقادیر گمشده، مثال ناقص را به یک مثال کامل تبدیل کنید.
شکل 3. حذف نمونه های ناقص از مجموعه داده. شکل 4. وارد کردن مقادیر گمشده برای مثال های ناقص.
اگر مجموعه داده حاوی نمونه های کامل کافی برای آموزش یک مدل مفید است، نمونه های ناقص را حذف کنید. به طور مشابه، اگر فقط یک ویژگی مقدار قابل توجهی از داده را از دست داده است و آن یک ویژگی احتمالاً نمی تواند کمک زیادی به مدل کند، آن ویژگی را از ورودی های مدل حذف کنید و ببینید با حذف آن چقدر کیفیت از بین می رود. اگر مدل بدون آن فقط یا تقریباً به خوبی کار کند، عالی است. برعکس، اگر نمونه‌های کامل کافی برای آموزش یک مدل مفید ندارید، ممکن است مقادیر گمشده را در نظر بگیرید.
حذف مثال های بی فایده یا زائد خوب است، اما حذف نمونه های مهم بد است. متأسفانه، تمایز بین نمونه های بی فایده و مفید می تواند دشوار باشد. اگر نمی‌توانید تصمیم بگیرید که حذف کنید یا انباشته کنید، ساخت دو مجموعه داده را در نظر بگیرید: یکی از حذف نمونه‌های ناقص و دیگری با برگزیدن. سپس، تعیین کنید که کدام مجموعه داده مدل بهتری را آموزش می دهد.
برای کسب اطلاعات بیشتر در مورد رسیدگی به انتساب، روی نماد کلیک کنید.
الگوریتم های هوشمندانه می توانند مقادیر بسیار خوبی از دست رفته را نسبت دهند. با این حال، مقادیر نسبت داده شده به ندرت به خوبی مقادیر واقعی هستند. بنابراین، یک مجموعه داده خوب به مدل می‌گوید که کدام مقادیر وارد شده و کدام‌ها واقعی هستند. یکی از راه‌های انجام این کار، اضافه کردن یک ستون بولی اضافی به مجموعه داده است که نشان می‌دهد آیا مقدار یک ویژگی خاص منتسب است یا خیر. به عنوان مثال، با توجه به یک ویژگی به نام temperature ، می توانید یک ویژگی بولی اضافی به نام چیزی مانند temperature_is_imputed اضافه کنید. سپس، در طول آموزش، مدل احتمالاً به تدریج یاد می‌گیرد که به نمونه‌هایی که حاوی مقادیر منتسب برای temperature ویژگی کمتر از نمونه‌های حاوی مقادیر واقعی (غیر منتسب) هستند اعتماد کند.
یکی از الگوریتم های متداول استفاده از میانگین یا میانه به عنوان مقدار نسبت داده شده است. در نتیجه، هنگامی که شما یک ویژگی عددی را با امتیازهای Z نشان می‌دهید، مقدار انباشته معمولاً 0 است (زیرا 0 معمولاً میانگین امتیاز Z است).
تمرین: درک خود را بررسی کنید
در اینجا دو ستون از یک مجموعه داده است که بر اساس Timestamp مرتب شده اند.
مهر زمان
دما
8 ژوئن 2023 09:00
12
8 ژوئن 2023 ساعت 10:00
18
8 ژوئن 2023 ساعت 11:00
گم شده
8 ژوئن 2023 ساعت 12:00
24
8 ژوئن 2023 ساعت 13:00
38
کدام یک از موارد زیر یک مقدار معقول برای محاسبه مقدار از دست رفته دما است؟
23
احتمالا. 23 میانگین مقادیر مجاور (12، 18، 24 و 38) است. با این حال، ما بقیه مجموعه داده را نمی بینیم، بنابراین ممکن است که 23 برای ساعت 11:00 در روزهای دیگر پرت باشد.
31
بعید است. بخش محدودی از مجموعه داده که می‌توانیم ببینیم نشان می‌دهد که 31 برای دمای 11:00 بسیار زیاد است. با این حال، ما نمی‌توانیم بدون استناد به تعداد بیشتری از مثال‌ها مطمئن باشیم.
51
بسیار بعید است. 51 بسیار بالاتر از هر یک از مقادیر نمایش داده شده است (و بنابراین، بسیار بالاتر از میانگین).
تاریخ آخرین بهروزرسانی 2024-11-07 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2024-11-07 بهوقت ساعت هماهنگ جهانی."],[[["\u003cp\u003eA machine learning model's performance is heavily reliant on the quality and quantity of the dataset it's trained on, with larger, high-quality datasets generally leading to better results.\u003c/p\u003e\n"],["\u003cp\u003eDatasets can contain various data types, including numerical, categorical, text, multimedia, and embedding vectors, each requiring specific handling for optimal model training.\u003c/p\u003e\n"],["\u003cp\u003eMaintaining data quality involves addressing issues like label errors, noisy features, and proper filtering to ensure the reliability of the dataset for accurate predictions.\u003c/p\u003e\n"],["\u003cp\u003eIncomplete examples with missing feature values should be handled by either deletion or imputation to avoid negatively impacting model training.\u003c/p\u003e\n"],["\u003cp\u003eWhen imputing missing values, use reliable methods like mean/median imputation and consider adding an indicator column to signal imputed values to the model.\u003c/p\u003e\n"]]],[],null,["# Datasets: Data characteristics\n\nA [**dataset**](/machine-learning/glossary#dataset) is a collection of\n[**examples**](/machine-learning/glossary#example).\n\nMany datasets store data in tables (grids), for example, as\ncomma-separated values (CSV) or directly from spreadsheets or\ndatabase tables. Tables are an intuitive input format for machine\nlearning [**models**](/machine-learning/glossary#model).\nYou can imagine each row of the table as an example\nand each column as a potential feature or label.\nThat said, datasets may also be derived from other formats, including\nlog files and protocol buffers.\n\nRegardless of the format, your ML model is only as good as the\ndata it trains on. This section examines key data characteristics.\n\nTypes of data\n-------------\n\nA dataset could contain many kinds of datatypes, including but certainly\nnot limited to:\n\n- numerical data, which is covered in a [separate\n unit](/machine-learning/crash-course/numerical-data)\n- categorical data, which is covered in a [separate\n unit](/machine-learning/crash-course/categorical-data)\n- human language, including individual words and sentences, all the way up to entire text documents\n- multimedia (such as images, videos, and audio files)\n- outputs from other ML systems\n- [**embedding vectors**](/machine-learning/glossary#embedding-vector), which are covered in a later unit\n\nQuantity of data\n----------------\n\nAs a rough rule of thumb, your model should train on at least an order\nof magnitude (or two) more examples than trainable parameters. However, good\nmodels generally train on *substantially* more examples than that.\n\nModels trained on large datasets with few\n[**features**](/machine-learning/glossary#feature)\ngenerally outperform models trained on small datasets with\na lot of features.\nGoogle has historically had great success training simple models on\nlarge datasets.\n\nDifferent datasets for different machine learning programs may require wildly\ndifferent amounts of examples to build a useful model. For some relatively\nsimple problems, a few dozen examples might be sufficient. For other problems,\na trillion examples might be insufficient.\n\nIt's possible to get good results from a small dataset if you are adapting\nan existing model already trained on large quantities of data from the\nsame schema.\n\nQuality and reliability of data\n-------------------------------\n\nEveryone prefers high quality to low quality, but quality is such a vague\nconcept that it could be defined many different ways. This course defines\n**quality** pragmatically:\n\u003e A high-quality dataset helps your model accomplish its goal.\n\u003e A low quality dataset inhibits your model from accomplishing its goal.\n\nA high-quality dataset is usually also reliable.\n**Reliability** refers to the degree to which you can *trust* your data.\nA model trained on a reliable dataset is more likely to yield useful\npredictions than a model trained on unreliable data.\n\nIn *measuring* reliability, you must determine:\n\n- How common are label errors? For example, if your data is labeled by humans, how often did your human raters make mistakes?\n- Are your features *noisy*? That is, do the values in your features contain errors? Be realistic---you can't purge your dataset of all noise. Some noise is normal; for example, GPS measurements of any location always fluctuate a little, week to week.\n- Is the data properly filtered for your problem? For example, should your dataset include search queries from bots? If you're building a spam-detection system, then likely the answer is yes. However, if you're trying to improve search results for humans, then no.\n\nThe following are common causes of unreliable data in datasets:\n\n- Omitted values. For example, a person forgot to enter a value for a house's age.\n- Duplicate examples. For example, a server mistakenly uploaded the same log entries twice.\n- Bad feature values. For example, someone typed an extra digit, or a thermometer was left out in the sun.\n- Bad labels. For example, a person mistakenly labeled a picture of an oak tree as a maple tree.\n- Bad sections of data. For example, a certain feature is very reliable, except for that one day when the network kept crashing.\n\nWe recommend using automation to flag unreliable data. For example,\nunit tests that define or rely on an external formal data schema can\nflag values that fall outside of a defined range.\n| **Note:** Any sufficiently large or diverse dataset almost certainly contains [**outliers**](/machine-learning/glossary#outliers) that fall outside your data schema or unit test bands. Determining how to handle outliers is an important part of machine learning. The [**Numerical data\n| unit**](/machine-learning/crash-course/numerical-data) details how to handle numeric outliers.\n\nComplete vs. incomplete examples\n--------------------------------\n\nIn a perfect world, each example is **complete**; that is, each example contains\na value for each feature.\n**Figure 1.** A complete example.\n\nUnfortunately, real-world examples are often **incomplete**, meaning that at\nleast one feature value is missing.\n**Figure 2.** An incomplete example.\n\nDon't train a model on incomplete examples. Instead, fix or eliminate\nincomplete examples by doing one of the following:\n\n- Delete incomplete examples.\n- [**Impute**](/machine-learning/glossary#value-imputation) missing values; that is, convert the incomplete example to a complete example by providing well-reasoned guesses for the missing values.\n\n**Figure 3.** Deleting incomplete examples from the dataset.\n\n**Figure 4.** Imputing missing values for incomplete examples.\n\nIf the dataset contains enough complete examples to train a useful model,\nthen consider deleting the incomplete examples.\nSimilarly, if only one feature is missing a significant amount of data and that\none feature probably can't help the model much, then consider deleting\nthat feature from the model inputs and seeing how much quality is lost by its\nremoval. If the model works just or almost as well without it, that's great.\nConversely, if you don't have enough complete examples to train a useful model,\nthen you might consider imputing missing values.\n\nIt's fine to delete useless or redundant examples, but it's bad to delete\nimportant examples. Unfortunately, it can be difficult to differentiate\nbetween useless and useful examples. If you can't decide whether\nto delete or impute, consider building two datasets: one formed by deleting\nincomplete examples and the other by imputing.\nThen, determine which dataset trains the better model.\n\n#### Click the icon to learn more about imputation handling.\n\n\nClever algorithms can impute some pretty good missing values;\nhowever, imputed values are rarely as good as the actual values.\nTherefore, a good dataset tells the model which values are imputed and\nwhich are actual. One way to do this is to add an extra Boolean column\nto the dataset that indicates whether a particular feature's value\nis imputed. For example, given a feature named `temperature`,\nyou could add an extra Boolean feature named something like\n`temperature_is_imputed`. Then, during training, the model will\nprobably gradually learn to trust examples containing imputed values for\nfeature `temperature` *less* than examples containing\nactual (non-imputed) values.\n\n*** ** * ** ***\n\n| Imputation is the process of generating well-reasoned data, not random or deceptive data. Be careful: good imputation can improve your model; bad imputation can hurt your model.\n\nOne common algorithm is to use the mean or median as the imputed value.\nConsequently, when you represent a numerical feature with\n[**Z-scores**](/machine-learning/glossary#z-score-normalization), then\nthe imputed value is typically 0 (because 0 is generally the mean Z-score).\n\n### Exercise: Check your understanding\n\n| A sorted dataset, like the one in the following exercise, can sometimes simplify imputation. However, it is a bad idea to train on a sorted dataset. So, after imputation, randomize the order of examples in the training set.\n\nHere are two columns of a dataset sorted by `Timestamp`.\n\n| Timestamp | Temperature |\n|--------------------|-------------|\n| June 8, 2023 09:00 | 12 |\n| June 8, 2023 10:00 | 18 |\n| June 8, 2023 11:00 | missing |\n| June 8, 2023 12:00 | 24 |\n| June 8, 2023 13:00 | 38 |\n\nWhich of the following would be a reasonable value to impute\nfor the missing value of Temperature? \n23 \nProbably. 23 is the mean of the adjacent values (12, 18, 24, and 38). However, we aren't seeing the rest of the dataset, so it is possible that 23 would be an outlier for 11:00 on other days. \n31 \nUnlikely. The limited part of the dataset that we can see suggests that 31 is much too high for the 11:00 Temperature. However, we can't be sure without basing the imputation on a larger number of examples. \n51 \nVery unlikely. 51 is much higher than any of the displayed values (and, therefore, much higher than the mean).\n| **Key terms:**\n|\n| - [Dataset](/machine-learning/glossary#dataset)\n| - [Embedding vector](/machine-learning/glossary#embedding-vector)\n| - [Example](/machine-learning/glossary#example)\n| - [Feature](/machine-learning/glossary#feature)\n| - [Model](/machine-learning/glossary#model)\n| - [Value imputation](/machine-learning/glossary#value-imputation)\n- [Z-score normalization](/machine-learning/glossary#z-score-normalization) \n[Help Center](https://support.google.com/machinelearningeducation)"]]
