Гайд · TNWS AI

Как выполнять вычисления через Code Execution в Gemini API и проверять результат

5 мин

Как подключить Code Execution в Gemini API для расчётов: постановка задачи, код, вывод и независимая контрольная проверка.

Что даст этот гайд

Задача — дать Gemini возможность выполнить код для вычисления или анализа данных и получить отдельно код, вывод и текстовое объяснение. Результатом должен стать воспроизводимый рабочий сценарий, который другой человек сможет повторить по тем же входным данным. Перед настройкой запишите критерий успеха: конкретный формат ответа, обязательные поля и ситуацию, в которой процесс обязан остановиться.

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

Что подготовить до начала

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

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

Пошаговая настройка

Подключите инструмент code execution в конфигурации запроса согласно текущему SDK Google. В пользовательском сообщении дайте данные в явном формате и попросите показать единицы измерения. Ответ может содержать отдельные части с исполняемым кодом и результатом выполнения — обработайте их отдельно от поясняющего текста.

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

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

Готовый промпт

Замените значения в квадратных скобках и сохраните получившуюся версию рядом с тестами:

Используй Code Execution для расчёта по данным ниже. Сначала проверь пропуски и типы, затем покажи код, таблицу промежуточных значений и итог. Не исправляй неизвестные значения догадкой. Данные: [CSV]. Задача: [ФОРМУЛА].

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

Практический пример

Вход

CSV: товар A — 3 шт. по 120; товар B — 2 шт. по 250; скидка 10% применяется только к товару A.

Ожидаемый результат

Код считает A: 3×120×0,9=324; B: 2×250=500; итог 824. В пояснении видны промежуточные суммы и правило скидки.

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

Проверка результата в три прохода

Технический проход: запрос завершился, формат читается, идентификаторы не потеряны, секреты не попали в ответ или лог. Смысловой проход: минимум три факта сверены с исходником; отдельно проверены числа, даты и отрицания. Процессный проход: повторный запуск не создаёт дубликат и корректно обрабатывает таймаут или недоступность сервиса.

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

Чек-лист

  • задача сформулирована через проверяемый результат;
  • границы и запрещённые действия указаны явно;
  • используются тестовые или разрешённые данные;
  • названия функций сверены с официальным источником;
  • секреты отсутствуют в коде, тексте запроса и открытом логе;
  • обычный сценарий проходит от начала до конца;
  • пустой вход обрабатывается предсказуемо;
  • отсутствие факта не превращается в догадку;
  • ключевые числа, даты, имена и URL сверены вручную;
  • повторный запуск не создаёт необратимый дубль;
  • сохранены инструкция, параметры и дата проверки.

Как сделать процесс полезнее

Назначьте владельца сценария. Он отвечает не за каждое нажатие, а за актуальность документации, тестов и критериев. В журнале фиксируйте найденный дефект и конкретное исправление: «добавили обязательное поле source», а не «улучшили промпт».

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

Минимальный журнал качества

Для каждой попытки сохраняйте пять значений: идентификатор входа, версия инструкции, итоговый статус, обнаруженная проблема и решение проверяющего. Полный текст чувствительного запроса в журнале не нужен — используйте обезличенный ID. Раз в неделю или после заметного обновления выберите десять записей разных типов и пересмотрите их вручную. Такой небольшой аудит показывает систематические ошибки: например, модель стабильно теряет единицы измерения или приложение повторно вызывает инструмент после таймаута. Исправляйте сначала процесс и валидацию, а уже затем формулировку промпта.

Ограничения

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

FAQ

Можно ли сразу подключать рабочие данные?

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

Почему недостаточно успешного статуса API?

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

Что делать, если ответ меняется между запусками?

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

Как обновлять такой процесс?

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

Первоисточник и дата проверки

Функции и названия параметров сверены 11 сентября 2026 года: официальное руководство Gemini API по Code Execution. Численные тарифы и лимиты намеренно не приведены: их следует проверять на официальной странице непосредственно перед использованием.

Частые вопросы

Можно ли использовать рабочие данные сразу?

Сначала проверьте сценарий на обезличенной копии и согласуйте обработку данных.

Достаточно ли статуса 200?

Нет. Он подтверждает обработку запроса, но не корректность фактов и действий.

Как тестировать обновления?

Повторяйте одинаковый набор обычных, пустых, противоречивых и запрещённых сценариев.

Где хранить ключ API?

В переменной окружения или менеджере секретов, но не в коде и промпте.

Читайте также

Комментарии

Пока тихо. Скажите первое слово