많은 데이터 세트는 테이블(그리드)에 데이터를 저장합니다(예: 쉼표로 구분된 값(CSV)으로 저장하거나 스프레드시트 또는 데이터베이스 테이블에서 직접 가져옴). 테이블은 머신러닝 모델의 직관적인 입력 형식입니다.
표의 각 행을 예시로, 각 열을 잠재적 특성 또는 라벨로 생각할 수 있습니다.
하지만 데이터 세트는 로그 파일 및 프로토콜 버퍼를 비롯한 다른 형식에서 파생될 수도 있습니다.
형식과 관계없이 ML 모델의 성능은 학습에 사용되는 데이터의 품질을 뛰어넘을 수 없습니다. 이 섹션에서는 주요 데이터 특성을 살펴봅니다.
데이터 유형
데이터 세트에는 다음을 포함하되 이에 국한되지 않는 다양한 유형의 데이터 유형이 포함될 수 있습니다.
대략적인 경험 법칙으로, 모델은 학습 가능한 매개변수보다 최소 1~2배 더 많은 예시를 사용하여 학습해야 합니다. 하지만 좋은 모델은 일반적으로 그보다 훨씬 더 많은 예시를 사용하여 학습합니다.
특징이 적은 대규모 데이터 세트에서 학습된 모델은 일반적으로 특징이 많은 소규모 데이터 세트에서 학습된 모델보다 성능이 우수합니다.
Google은 대규모 데이터 세트에서 간단한 모델을 학습시키는 데 큰 성공을 거두었습니다.
머신러닝 프로그램에 따라 데이터 세트가 다르면 유용한 모델을 빌드하는 데 필요한 예시의 양이 크게 달라질 수 있습니다. 비교적 간단한 문제의 경우 수십 개의 예시로 충분할 수 있습니다. 다른 문제의 경우 1조 개 예시도 충분하지 않을 수 있습니다.
동일한 스키마의 대량 데이터로 이미 학습된 기존 모델을 조정하는 경우 소규모 데이터 세트에서 우수한 결과를 얻을 수 있습니다.
데이터의 품질 및 신뢰성
누구나 낮은 품질보다 높은 품질을 선호하지만 품질은 너무 모호한 개념이어서 여러 가지 방식으로 정의할 수 있습니다. 이 과정에서는 품질을 실용적으로 정의합니다.
고품질 데이터 세트는 모델이 목표를 달성하는 데 도움이 됩니다.
품질이 낮은 데이터 세트는 모델이 목표를 달성하는 데 방해가 됩니다.
고품질 데이터 세트는 일반적으로 신뢰할 수 있습니다.
신뢰성은 데이터를 신뢰할 수 있는 정도를 나타냅니다.
신뢰할 수 있는 데이터 세트에서 학습된 모델은 신뢰할 수 없는 데이터에서 학습된 모델보다 유용한 예측을 산출할 가능성이 높습니다.
안정성을 측정할 때는 다음을 결정해야 합니다.
라벨 오류는 얼마나 자주 발생하나요? 예를 들어 사람이 데이터에 라벨을 지정하는 경우, 사람 평가자가 실수를 하는 빈도는 얼마나 되나요?
지형지물에 노이즈가 있나요? 즉, 지형지물의 값에 오류가 있나요? 현실적으로 데이터 세트에서 모든 노이즈를 제거할 수는 없습니다. 약간의 노이즈는 정상입니다. 예를 들어 위치의 GPS 측정값은 매주 항상 약간 변동합니다.
문제에 맞게 데이터가 적절하게 필터링되었나요? 예를 들어 데이터 세트에 봇의 검색어를 포함해야 하나요? 스팸 감지 시스템을 빌드하는 경우 답변은 '예'일 가능성이 높습니다.
하지만 사람을 위한 검색 결과를 개선하려는 경우는 그렇지 않습니다.
다음은 데이터 세트에서 데이터가 신뢰할 수 없는 일반적인 원인입니다.
값 누락 예를 들어 사용자가 주택의 연령을 실수로 입력하지 않았을 수 있습니다.
중복 예시 예를 들어 서버에서 동일한 로그 항목을 실수로 두 번 업로드했을 수 있습니다.
잘못된 특성 값 예를 들어 사용자가 숫자를 실수로 입력했거나 온도계를 햇빛에 두었을 수 있습니다.
잘못된 라벨 예를 들어 사용자가 참나무 사진에 실수로 단풍나무 라벨을 지정했을 수 있습니다.
잘못된 데이터 섹션 예를 들어 특정 기능은 네트워크가 계속 비정상 종료된 하루를 제외하고는 매우 안정적입니다.
자동화를 사용하여 신뢰할 수 없는 데이터를 신고하는 것이 좋습니다. 예를 들어 외부 공식 데이터 스키마를 정의하거나 이를 사용하는 단위 테스트는 정의된 범위를 벗어나는 값에 플래그를 지정할 수 있습니다.
완전한 예시와 불완전한 예시
이상적인 경우 각 예시는 완전합니다. 즉, 각 예시에는 각 특성의 값이 포함됩니다.
그림 1. 전체 예시
안타깝게도 실제 예시에는 누락된 부분이 많습니다. 즉, 하나 이상의 특성 값이 누락되어 있습니다.
그림 2. 불완전한 예시
불완전한 예시로 모델을 학습시키지 마세요. 대신 다음 중 하나를 수행하여 불완전한 예시를 수정하거나 삭제하세요.
불완전한 예시를 삭제합니다.
누락된 값을 Impute합니다. 즉, 누락된 값에 대해 타당한 추측을 제공하여 불완전한 예시를 완전한 예시로 변환합니다.
그림 3. 데이터 세트에서 불완전한 예시를 삭제합니다.
그림 4. 불완전한 예시의 누락된 값을 넣습니다.
데이터 세트에 유용한 모델을 학습하는 데 충분한 완전한 예시가 포함되어 있으면 불완전한 예시를 삭제해 보세요.
마찬가지로 하나의 특성에서만 상당한 양의 데이터가 누락되고 이 특성이 모델에 큰 도움이 되지 않을 수 있는 경우 모델 입력에서 해당 특성을 삭제하고 삭제 시 품질이 얼마나 저하되는지 확인해 보세요. 이 기능 없이도 모델이 거의 또는 완전히 동일하게 작동하면 좋습니다.
반대로 유용한 모델을 학습하기에 충분한 완전한 예가 없는 경우 누락된 값을 보충하는 것이 좋습니다.
쓸모 없거나 중복된 예시를 삭제하는 것은 좋지만 중요한 예시를 삭제하는 것은 좋지 않습니다. 안타깝게도 쓸모없는 예와 유용한 예를 구분하기는 쉽지 않습니다. 삭제할지 아니면 보간할지 결정할 수 없는 경우 불완전한 예시를 삭제하여 생성된 데이터 세트와 보간하여 생성된 데이터 세트 두 개를 만드는 것이 좋습니다.
그런 다음 더 나은 모델을 학습시키는 데이터 세트를 결정합니다.
아이콘을 클릭하여 보정 처리에 대해 자세히 알아보세요.
영리한 알고리즘은 상당히 정확한 누락 값을 보정할 수 있지만, 보정된 값이 실제 값만큼 정확한 경우는 거의 없습니다.
따라서 좋은 데이터 세트는 모델에 어떤 값이 보간되고 어떤 값이 실제인지 알려줍니다. 이를 수행하는 한 가지 방법은 특정 지형지물 값이 보간되었는지 여부를 나타내는 불리언 열을 데이터 세트에 추가하는 것입니다. 예를 들어 temperature라는 지형지물이 있는 경우 temperature_is_imputed과 같은 이름의 불리언 지형지물을 추가할 수 있습니다. 그러면 학습 중에 모델은 실제 (임퓨트되지 않은) 값이 포함된 예시보다 temperature 특성에 대한 임퓨트 값이 포함된 예시를 더 적게 신뢰하도록 점진적으로 학습할 것입니다.
일반적인 알고리즘 중 하나는 평균 또는 중앙값을 대입된 값으로 사용하는 것입니다.
따라서 숫자형 특성을 Z 점수로 나타낼 때는 일반적으로 0이 삽입됩니다 (0이 일반적으로 평균 Z 점수이기 때문).
연습문제: 이해도 확인
다음은 Timestamp로 정렬된 데이터 세트의 두 열입니다.
타임스탬프
온도
2023년 6월 8일 9시
12
2023년 6월 8일 10시
18
2023년 6월 8일 11:00
결측치
2023년 6월 8일 12:00
24
2023년 6월 8일 13:00
38
다음 중 누락된 Temperature 값을 보충하는 데 적절한 값은 무엇인가요?
23
아마 그럴 거예요. 23은 인접한 값 (12, 18, 24, 38)의 평균입니다.
하지만 나머지 데이터 세트는 표시되지 않으므로 23이 다른 날의 11시에서 외부값일 수 있습니다.
31
가능성 낮음 데이터 세트에서 확인할 수 있는 제한된 부분을 보면 11시 온도에 31도가 너무 높다는 것을 알 수 있습니다. 하지만 더 많은 예시를 기반으로 대입하지 않으면 확신할 수 없습니다.
[null,null,["최종 업데이트: 2024-11-14(UTC)"],[[["\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)"]]
