How should a team use a very small error-review set?
Case context: A product team has a manual review set with 12 recorded failures. The team cannot collect more labeled examples right now and wants to decide which failure types to fix first.
Question: Identify the limitation of the evidence and explain how the team should use the 12 failures when setting priorities.
Sample answer: The team should recognize that 12 failures provide only a very small review set. It should not assume that the observed mix of failure types gives an accurate estimate of their true prevalence, because the sample is too small. Even so, since no additional data can be added, the team should inspect the failures and use the observed categories as rough guidance for prioritization, while treating those conclusions as provisional.
Key points:
- The set of 12 failures is very small.
- It is hard to estimate category impact accurately from such a small sample.
- The team cannot add more data right now.
- The failures should still be examined.
- Priorities based on the sample should be viewed as tentative.
Rubric: Full credit requires noting the small-sample limitation, rejecting the idea that category impact can be estimated accurately, and recommending cautious use of the available failures for prioritization because they are still informative.
0
1
Tags
Machine Learning
Deep Learning
Machine Learning Strategy
Supervised Learning
Dive into Deep Learning @ D2L
Data Science
Machine Learning Yearning @ DeepLearning.AI
Related
Why is a small review set with only 10 mistakes too limited for judging where to focus improvement work?
A review of only ten dev-set errors can reliably estimate the impact of each error category.
With only ten observed mistakes, estimating the importance of each category is _____.
Match each small dev-set condition with the implication it supports.
Order the reasoning for working with only 12 review errors in a content-moderation dev set.
Explain why a tiny error sample is limited but still useful.
How should a team use a very small error-review set?
Why can a small set of manually inspected dev errors still be useful?
What should you do if a review of model mistakes turns up only 12 examples and no more labeled data can be collected?
Even when a dev subset is tiny, checking its errors can still help decide what to improve first.