Как сократить повторные запуски кода при анализе данных в Jupyter

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

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

Такие инструменты, как RunCell, помогают сократить объем ручной работы в рамках этого повторяющегося цикла. Цель состоит не в том, чтобы отказаться от итераций, поскольку именно они помогают улучшать анализ. Важно сделать каждый повторный запуск осмысленным, понятным и связанным с конкретными данными, которые стали причиной изменения, а не просто добавлять очередную правку поверх предыдущей.

Цикл, стоящий за каждым повторным запуском

Большая часть работы в ноутбуке следует одной и той же пятиэтапной схеме: Наблюдение → Изменение → Запуск → Сравнение → Решение.

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

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

Пять этапов внутри цикла

Шаг 1 — Наблюдение: изменение должно иметь конкретную причину

Каждое изменение должно быть связано с чем-то конкретным в предыдущем результате: числом, которое не сходится, подозрительной формой графика или категорией, которая неожиданно оказалась пустой.

Мысль «возможно, это будет выглядеть аккуратнее, если сделать по-другому» сама по себе недостаточна. Изменения, сделанные из любопытства, а не из-за конкретного несоответствия, быстро накапливаются. Уже после третьей правки может быть трудно понять, какое именно изменение проверяло ту или иную гипотезу.

Шаг 2 — Изменение: одна правка, одна причина

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

Полезная правка должна быть минимальной и помогать отличить одну возможную причину от другой. Тогда следующий этап даст конкретный результат, который можно проверить.

Шаг 3 — Запуск: автоматизируйте механическую работу, но не принятие решений

Переписывание фильтра, повторное создание операции groupby, поиск причины ошибки в трассировке стека — именно здесь обычно сосредоточена наиболее повторяющаяся работа. Здесь Jupyter AI agent может взять на себя значительную часть механических действий.

RunCell работает непосредственно в JupyterLab с существующими ноутбуками .ipynb, без необходимости использовать отдельный API-ключ. Он может внести изменение, выполнить код и, поскольку учитывает полученный вывод, проанализировать таблицу или сообщение об ошибке, а не просто подтвердить, что ячейка была запущена. Это позволяет исправлять ошибки, не покидая ноутбук для ручной отладки.

Однако такой инструмент не решает, было ли выбранное изменение правильным способом проверки гипотезы. Это решение аналитик уже должен был принять на втором этапе.

Шаг 4 — Сравнение: воспринимайте новый результат как доказательство

Если ячейка выполнилась без ошибки, это лишь означает, что код был принят средой выполнения. Это еще не доказывает, что внесенное изменение решило проблему.

Количество строк, итоговые значения и проблемную категорию необходимо сравнить с предыдущим результатом. Например, если скачок полностью исчез после удаления лишь нескольких дублирующихся строк, это само по себе становится важным наблюдением. Возможно, правило дедупликации удалило не только дубликаты, но и корректные записи.

Шаг 5 — Решение: остановиться, сузить или расширить исследование

Одного сравнения не всегда достаточно, чтобы полностью закрыть вопрос. Если оно объясняет первоначальное наблюдение, цикл можно завершить.

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

Где цикл чаще всего нарушается

Большинство ненужных повторных запусков возникает не из-за середины процесса, а из-за пропуска одного из двух его крайних этапов.

Пропуск первого шага означает, что аналитик меняет код просто потому, что ему кажется, будто «что-то не так», а не потому, что конкретное число или график указывает на проблему. В результате можно получить пять измененных ячеек и при этом не понимать, какая именно правка действительно повлияла на результат.

Пропуск пятого шага означает, что после правдоподобного исправления аналитик по привычке запускает код еще раз, не проверяя, дал ли предыдущий результат достаточный ответ.

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

Когда становится непонятно, какое из нескольких последовательных изменений привело к текущему результату, приходится отменять правки по одной и снова выполнять код.

Как AI-агент помогает на протяжении всего цикла

Польза AI agent for Jupyter Notebook не ограничивается только третьим этапом.

Поскольку RunCell позволяет сохранять связь между вопросами, результатами и предыдущими решениями в рамках нескольких итераций, сравнение на четвертом этапе может учитывать не только новое значение, но и то, что именно было изменено и зачем.

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

Выполнение кода становится быстрее, но еще важнее то, что сохраняется связь между отдельными итерациями. Именно эта связь часто первой теряется при обычном повторном запуске скриптов и становится одной из причин, почему к старым ноутбукам бывает трудно вернуться спустя некоторое время.

Полный цикл от начала до конца

Полный рабочий процесс состоит из тех же пяти этапов, которые последовательно повторяются: Наблюдение → Изменение → Запуск → Сравнение → Решение.

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

Быстрый ноутбук — это не тот, в котором нет правок. Это ноутбук, где каждая правка имеет конкретное основание на первом этапе, аккуратно проверяется на этапах со второго по четвертый и действительно завершает цикл на пятом этапе, когда имеющихся данных уже достаточно для принятия решения.