ИИ на хакатоне: как использовать, проверять и раскрывать
Как применять ИИ на хакатоне в рамках правил: проверять сгенерированный код, контролировать данные и объяснять вклад команды.
·4 мин чтения
Использовать ИИ на хакатоне следует по правилам конкретного события и с проверкой результата. Генерация кода, помощь с текстом и модель внутри продукта относятся к разным способам применения. Регламент может разрешать один и ограничивать другой. Уточните это до того, как выбранный инструмент станет обязательной частью проекта.
Команда отвечает за то, что сдаёт и показывает. Если модель написала функцию, участникам всё равно нужно понимать её поведение, зависимости и ограничения. Убедительный ответ в чате не подтверждает, что код работает в вашей среде или безопасно обрабатывает входные данные.
Разделите помощника и функцию продукта
ИИ может помогать разработчику объяснять ошибку, готовить тестовые примеры или писать черновик документации. В этом случае он участвует в процессе работы. Другая ситуация возникает, когда пользовательское действие вызывает модель внутри вашего приложения.
Во втором случае проект зависит от доступности сервиса, времени ответа, стоимости запросов и качества результата. Эти зависимости нужно показать в архитектуре и проверить. Название популярной модели в презентации не объясняет, зачем она нужна именно этой задаче.
Составьте короткий список применений. Для каждого укажите инструмент, задачу, передаваемые данные и способ проверки. Этот журнал пригодится и для раскрытия использования ИИ, и для разбора ошибок, когда разные участники применяли разные сервисы.
Давайте инструменту ограниченную задачу
Просьба «сделай весь сервис» оставляет слишком много решений без контроля. Разделите работу на небольшие изменения с ожидаемым поведением. Опишите вход, выход, ограничения и уже существующий код, который нужно сохранить.
После генерации прочитайте изменение и запустите его. Проверьте обычный случай, ошибочный ввод и границу доступа. Если вы не можете объяснить ключевую часть, попросите разбор и сократите решение. Не объединяйте непонятный блок только потому, что он длинный и выглядит профессионально.
Сравнивайте предложенные API и параметры с официальной документацией используемой версии. Модель может смешать разные версии библиотеки или придумать метод. На коротком событии ранняя проверка маленького примера экономит время на последующей переделке.
Не отправляйте закрытые данные без разрешения
Узнайте, какие данные разрешено передавать внешним сервисам. Это касается конкурсных наборов, клиентских документов, исходного кода организации и персональных сведений. Общая доступность чат-инструмента не означает разрешения загрузить в него всё, что вы получили на хакатоне.
Для разработки используйте минимальные безопасные примеры. Уберите секреты и сведения, которые не нужны для объяснения задачи. Если замена реальных данных искусственными меняет результат эксперимента, зафиксируйте это ограничение.
Ключ API храните на сервере или в другой предусмотренной для секрета среде. Не размещайте его в браузерном коде, публичном репозитории или видеозаписи. Перед показом проверьте экран терминала, переменные окружения и историю открытых вкладок.
Подготовьте проверочный набор заранее
Если модель является частью продукта, выберите примеры с известным ожидаемым результатом. Добавьте неудобные случаи: пустой документ, противоречивые данные, вопрос вне доступного материала. Проверяйте, что приложение делает при отсутствии ответа.
Для помощника по регламенту полезно требовать ссылку на исходный фрагмент и проверять, что он действительно поддерживает ответ. Само наличие ссылки не доказывает правильность. Если в документе нет нужного условия, система должна сообщать об этом, а не достраивать правило.
Не используйте одни и те же примеры одновременно для постоянной настройки и финального заявления о качестве без оговорки. Команда может незаметно подогнать решение под знакомый набор. Сохраните отдельные случаи для проверки после изменения.
Проверьте ограничения сервиса
Пройдите сценарий при медленном ответе и временной недоступности API. Сообщайте пользователю о состоянии и не запускайте бесконечные повторные запросы. Определите допустимое время ожидания и понятный выход из ошибки.
Оцените, сколько запросов делает один показ. Настройте доступные лимиты и следите за расходом. Не обещайте, что проект продолжит работать бесплатно после окончания выданных кредитов. Если стоимость ещё не посчитана, укажите это среди нерешённых вопросов.
Подготовьте честный запасной способ демонстрации. Запись предыдущего запуска можно использовать как запись, если регламент допускает такой материал. Нельзя показывать заранее сохранённый ответ и называть его новой генерацией в реальном времени.
Раскройте применение ИИ в заявке
Опишите, где использована модель, что команда разработала самостоятельно и что проверила. Если правила требуют список запросов, инструментов или внешних компонентов, подготовьте его в указанном формате. Не заменяйте содержательное описание общей фразой «использовали ИИ для ускорения».
В исследовании Quick Build, Careful Check? Generative AI Use in Hackathons авторы изучают использование генеративного ИИ через интервью участников одного двухдневного события. Это разведочное исследование; оно не даёт универсального процента прироста продуктивности для любой команды.
Для текстов заявки проверяйте имена, цифры, ссылки и соответствие реальному проекту. Не добавляйте вымышленные пользовательские отзывы и результаты тестирования. Финальный рассказ должен совпадать с тем, что команда может показать и объяснить. Перед отправкой пройдите проверку материалов сдачи и сохраните версию проекта, к которой относится описание.
Организаторам стоит закрепить требования к ИИ до старта. В шаблоне регламента Stavleak можно подготовить правила использования внешних инструментов и раскрытия их вклада.
