Результат проверки должен иметь понятный смысл
Начните с разделения трёх понятий: входная запись, сигнал программы и подтверждённая метка в учебном наборе. Сигнал означает, что сработало выбранное правило или модель. Он ещё не доказывает мошенничество. Для проекта удобно отдельно описать чтение данных, проверку их корректности, вычисление результата и подготовку отчёта. Это учебная структура, допускающая другие решения. Если обязательное поле отсутствует, запись нельзя молча объявлять безопасной. Ошибка входа и отрицательный результат проверки означают разное. Предусмотрите отдельный исход для данных, которые невозможно оценить корректно. Каждой вымышленной записи дайте стабильный идентификатор. Он поможет сопоставить результат программы с ожидаемой меткой и найти конкретную ошибку. При этом для упражнения не нужны имена, реальные счета и другие сведения о людях.
Разберите четыре возможных исхода
Если подозрительный по учебной разметке случай отмечен, это верное срабатывание. Если обычная запись ошибочно отмечена, возникает ложная тревога. Подозрительный случай без сигнала является пропуском, а обычная запись без сигнала верным отрицательным результатом. Представим двести записей, из которых только четыре помечены в учебном наборе как подозрительные. Программа, называющая все записи обычными, окажется права в ста девяноста шести случаях. Общая доля правильных ответов составит девяносто восемь процентов, хотя ни один нужный случай не найден. Теперь другая версия отметила восемь записей. Три из них действительно относятся к четырём подозрительным, пять оказались ложными тревогами, а один подозрительный случай пропущен. Здесь можно отдельно спросить, сколько сигналов подтвердилось и какую часть нужных случаев удалось найти. Такие вопросы показывают разные стороны качества. Одно общее число скрывает различие между лишними тревогами и пропусками.
Проверяйте программу и смысл разметки отдельно
Для второй версии из примера подтвердились три сигнала из восьми, то есть тридцать семь с половиной процентов. Найдены три случая из четырёх, то есть семьдесят пять процентов. Эти показатели используют разные знаменатели. В отчёте подпишите каждый знаменатель словами. Тогда процент найденных случаев не будет случайно представлен как процент подтверждённых сигналов. Сохраните количества: одна запись может заметно изменить долю. Тесты проекта должны проверять обычные, подозрительные и некорректные записи. Полезно также убедиться, что перестановка независимых входных строк не меняет итоговый подсчёт, если порядок не входит в условие задачи. Но успешный тест не доказывает правильности исходной разметки. В реальной работе подтверждение случая требует отдельного процесса и соответствующих полномочий. Учебная метка задаётся автором набора, поэтому выводы ограничены этим примером. Название детектора не должно превращать вероятностный или условный сигнал в обвинение. В учебном интерфейсе точнее показывать результат проверки и его основание, сохраняя возможность разбора ошибок.
Попробуйте на практике
Проверьте вымышленный отчёт детектора без реальных операций и программного развёртывания.
- Запишите размер набора: двести записей, четыре из них условно подозрительные. Посчитайте долю верных ответов у версии, которая не отмечает ничего.
- Для второй версии укажите восемь сигналов: три подтверждённых и пять ложных. Отдельно отметьте один пропущенный случай.
- Посчитайте долю подтверждённых сигналов и долю найденных подозрительных случаев. Подпишите разные знаменатели.
- Составьте список проверок Java-проекта: корректность входа, отдельный исход ошибки, сопоставление идентификаторов и правильность итоговых количеств.
Как проверить результат. Получены девяносто восемь процентов для бесполезного первого правила, тридцать семь с половиной и семьдесят пять процентов для разных показателей второго. Сигнал не назван доказанным мошенничеством.
Частые вопросы
Почему нельзя выбрать лучший детектор по одному проценту?
Показатели отражают разные ошибки и зависят от состава набора. Сначала нужно понять задачу и последствия пропусков и ложных тревог.
Некорректную запись можно считать обычной, чтобы не останавливать обработку?
Нет, это смешивает отсутствие возможности проверить с отрицательным результатом. Для учебного проекта такой случай лучше явно выделить и отразить в отчёте.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.