AI-хакатон: как проверить решение до финального питча

Назначьте владельца контрольного набора. До фиксации решений он хранит отдельно входы и ожидаемые ответы. Сгруппируйте повторные объявления об одном событии, чтобы их варианты не оказались по разные стороны разделения. Для нашего примера включите заранее выбранные русские и казахские тексты, отсутствующие поля и неоднозначные даты.

Если преобразование учится по данным, обучайте его только на обучающей части. Документация scikit-learn отдельно предупреждает об утечке через предварительную обработку. Правило касается и этапов, которые выглядят как простая подготовка данных.

3. Подготовьте простое решение для сравнения

Соберите baseline: словарь городов, явные признаки формата и распознавание полностью указанных дат. Он также возвращает null, когда информации недостаточно. Версию словаря и правила зафиксируйте до контрольного запуска.

Проверяйте baseline и AI-решение на одинаковых входах и по одинаковым правилам. Тогда видно, где модель справляется лучше простого подхода и где добавляет ошибки. Рекомендации Google по ML предлагают начинать с простого решения и заранее определить измеряемый результат.

Проверяйте поля отдельно: правильность города, формата, срока и поведение при отсутствии данных. Сохраняйте количество верных ответов вместе с количеством проверенных полей. Не объединяйте их в одну «точность», если из числа нельзя понять, что именно считали. Вес этих проверок в общей оценке согласуйте через критерии для жюри.

4. Сохраните запись каждого запуска

До открытия контрольных данных зафиксируйте коммит решения и параметры проверки. Попросите команду предоставить короткий файл запуска с такими полями:

Версия API не всегда фиксирует внутреннее состояние внешнего сервиса. Запишите, что провайдер позволяет закрепить, и какие условия команда не контролирует. Не включайте в файл ключи, токены и реальные пользовательские данные.

Сохраняйте ответы до исправления формата. Иначе невозможно понять, модель вернула корректный JSON или приложение восстановило его после ошибки. Отдельно запишите преобразованный результат, который увидел пользователь.

Для недетерминированного решения заранее определите число повторов и сохраняйте каждый результат. Не выбирайте удачный прогон после проверки. Фиксированный seed сам по себе не гарантирует одинакового вывода: PyTorch предупреждает о различиях между версиями, платформами и CPU/GPU. Для внешнего API отдельно учитывайте ограничения его провайдера.

5. Разберите ошибки по примерам

Судье нужен журнал, где одна запись соответствует одному входу в конкретном запуске. Используйте шаблон: run_id, example_id, входной текст, ожидаемые поля, исходный ответ, обработанный ответ, тип ошибки, статус запуска, замечание проверяющего.

В нашем примере различайте пропущенную дату, выдуманный город, неверный формат JSON, корректный null и отсутствие ответа из-за сбоя. Корректный отказ от догадки отличается от ошибки извлечения. Проблема доступа к API тоже требует отдельного статуса.

Не удаляйте зависшие запросы и отсутствующие ответы из отчёта. Покажите число всех запланированных примеров, завершённых запусков и сбоев. Если разметка ошибочна, зафиксируйте исправление и пересчитайте оба решения по одному правилу. После настройки по контрольным ошибкам прежний набор уже не даёт независимой проверки следующей версии.

6. Дайте судье повторить проверку

Сначала проверьте, запускается ли пакет по инструкции. Для доступа, фиксированной версии и резервного демо используйте чек-лист технической приёмки. Непроверенный код запускайте в одноразовой изолированной среде без рабочих секретов, с отдельной тестовой учётной записью.

Затем судья выбирает примеры из согласованного контрольного набора и повторяет запуск с записанными параметрами. Сравните исходные ответы с сохранёнными. Если они различаются, запишите различие, условия и объяснение команды. Видео подтверждает показанный результат, но не заменяет этот запуск.

Перед питчем передайте жюри версию решения, протокол запуска, сравнение с baseline и журнал ошибок. В ограничениях укажите размер и состав проверки, непроверенные типы входов, зависимость от внешнего сервиса и необходимую проверку человеком. Судья сможет опираться на конкретные ответы и сбои, когда команда будет объяснять, что прототип уже умеет и какую проверку нужно провести дальше.