Создание AI-аналитика данных с изолированным Python и контролируемым доступом к пакетам

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

Архитектура AI-аналитика данных: загрузка, анализ, проверка

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

Создайте первую версию вокруг одного четкого пути:

1. Принять загрузку одного CSV для одного задания анализа.
2. Создать рабочее пространство песочницы, привязанное к заданию.
3. Запустить собственный код проверки схемы до запроса к модели на Python.
4. Запросить у модели план анализа, затем скрипт, который соблюдает ваши правила для файлов и пакетов.
5. Выполнить скрипт с ограничениями по времени, памяти, диску, пакетам и сети.
6. Собрать только проверенные артефакты из известной выходной директории.
7. Показать пользователю ответ, диаграммы, предупреждения, журналы и файлы, выбранные для загрузки.

Такое разделение сохраняет четкость обязанностей. Модель предлагает и объясняет анализ. Бэкенд применяет политику продукта и оркестрацию. Песочница выполняет код с ограниченными файлами, пакетами, временем, памятью, сетевым доступом и секретами.

Что выполняется внутри Python-песочницы для анализа данных?

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

Для AI-аналитика данных песочница обычно отвечает за следующие задачи:

Задача песочницы	Почему это относится к ней
Размещение файлов	Загруженный CSV можно отсканировать и скопировать в изолированную рабочую директорию до того, как Python его коснется.
Проверка схемы	Приложение может вывести имена столбцов, типы, долю пустых значений, количество строк и образцы значений, не передавая модели полный файл.
Выполнение Python	Сгенерированный моделью код выполняется вдали от сервера приложения и может быть ограничен по времени.
Подготовка пакетов	Задание получает только одобренные зависимости.
Рендеринг диаграмм	Изображения графиков записываются в файлы и проверяются перед загрузкой.
Упаковка результатов	Финальные артефакты собираются из известной выходной директории.
Очистка	Временные файлы, сгенерированный код и состояние сессии удаляются или истекают.

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

Как должна работать загрузка CSV и проверка схемы?

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

Практический поток загрузки выглядит так:

1. Пользователь загружает CSV в приложение.
2. Бэкенд сохраняет исходный файл под ключом объекта или путем размещения, привязанным к заданию.
3. Бэкенд создает сессию песочницы для задания.
4. Бэкенд копирует файл в рабочую директорию песочницы.
5. Небольшой детерминированный скрипт проверки читает файл и создает сводку схемы.
6. Модель получает сводку схемы, вопрос пользователя, разрешенные библиотеки и требования к выводу.

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

{
  "file": "sales.csv",
  "rows": 84231,
  "columns": [
    {"name": "order_date", "type": "date", "null_rate": 0.01},
    {"name": "region", "type": "string", "sample_values": ["NA", "EMEA", "APAC"]},
    {"name": "revenue", "type": "number", "null_rate": 0.0}
  ],
  "safe_sample_rows": 5
}

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

Как модель генерирует и выполняет Python безопасно?

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

После того как план принят, запросите Python, который следует узкому контракту:

• Читать входные файлы только из директории input/.
• Записывать артефакты только в директорию output/.
• Использовать только одобренные пакеты.
• Избегать сетевых вызовов, если политика задания явно их не разрешает.
• Выводить структурированную сводку в конце.
• Явно завершаться с ошибкой при отсутствии обязательных столбцов.

На концептуальном уровне цикл оркестрации выглядит так:

job = create_analysis_job(user_id, uploaded_file)
sandbox = create_sandbox(job_id=job.id, timeout_seconds=300)

copy_file_to_sandbox(uploaded_file, sandbox_path="/work/input/data.csv")
schema = run_owned_schema_inspector(sandbox, "/work/input/data.csv")

plan = ask_model_for_analysis_plan(
    user_question=job.question,
    schema=schema,
    allowed_packages=["pandas", "numpy", "matplotlib"],
    output_contract={"directory": "/work/output", "formats": ["png", "csv", "json"]},
)

review_policy(plan)

script = ask_model_for_python(plan=plan, schema=schema)
review_static_code_policy(script)

result = run_python_in_sandbox(
    sandbox=sandbox,
    script=script,
    working_dir="/work",
    timeout_seconds=120,
    memory_limit_mb=1024,
)

artifacts = collect_outputs(sandbox, "/work/output")
review_outputs(artifacts)
return_answer_to_user(result.summary, artifacts)

Это псевдокод, а не контракт SDK продукта. Смысл в границе: сгенерированный код проверяется, выполняется с тайм-аутом, ограничивается известными директориями, после чего следует сбор выходных данных и проверка.

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

Контролируемый доступ к пакетам Python для AI-анализа данных

Доступ к пакетам — это то, где многие демо-версии AI-аналитиков данных становятся рискованными. Модель может запросить библиотеку, потому что видела ее в учебнике, потому что имя пакета кажется правдоподобным или потому что промпт пользователя на это намекнул. Ваше приложение не должно превращать такие предложения в неограниченные установки пакетов.

Используйте политику, соответствующую чувствительности данных:

Политика пакетов	Лучшее применение	Компромисс
Только предварительно собранный образ	Производственные нагрузки с предсказуемыми потребностями анализа	Минимальная гибкость, простейшая поверхность проверки
Список разрешенных пакетов	Большинство помощников по анализу CSV	Хороший баланс для pandas, построения графиков и распространенных статистических пакетов
Установки с фиксированными версиями	Воспроизводимые задания анализа	Требует поддержки пакетов и проверки уязвимостей
Кэшированный внутренний зеркальный сервер	Корпоративные или регулируемые рабочие процессы с данными	Больше операционной работы, лучший контроль цепочки поставок
Установки, одобренные пользователем	Исследовательские инструменты для доверенных пользователей	Более гибко, но медленнее и требует четких предупреждений

Для первой производственной версии начните с предварительно собранной среды или короткого списка разрешенных пакетов. Большинство вопросов по CSV можно решить с помощью небольшого набора библиотек: pandas, numpy, matplotlib, seaborn, scipy, а иногда и scikit-learn. Если заданию нужен другой пакет, пусть модель объяснит почему, затем направьте этот запрос через одобрение человека или рабочий процесс проверки пакетов.

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

Как проверять диаграммы и выходные файлы

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

Определите простой контракт вывода:

{
  "required_files": ["summary.json"],
  "optional_files": ["chart-*.png", "filtered-data.csv"],
  "blocked_extensions": [".exe", ".sh", ".bat", ".html"],
  "max_total_size_mb": 25
}

Для каждого завершенного задания собирайте файлы только из ожидаемой выходной директории. Проверяйте MIME-тип, расширение, размер и путь. Для изображений создавайте миниатюры для предварительного просмотра. Для CSV-экспортов экранируйте формулы электронных таблиц, если файл может быть открыт в Excel или Google Sheets. Для JSON-сводок проверяйте соответствие схеме перед использованием в пользовательском интерфейсе.

Предоставьте пользователю этап проверки перед загрузкой или публикацией результатов. Экран проверки должен показывать:

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

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

Контрольные точки безопасности перед выходом в продакшн

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

Используйте этот контрольный список перед выходом за пределы прототипа:

Контрольная точка	Вопрос для ответа
Граница изоляции	Что отделяет код и файлы одного пользователя от хоста и других пользователей?
Доступ к файлам	Может ли сгенерированный код читать только директорию задания или он может видеть более широкое хранилище?
Ограничения ресурсов	Какие ограничения на время ЦП, память, диск, количество процессов и реальное время?
Сетевая политика	Выключен ли исходящий сетевой доступ, разрешен по списку, проксирован или полностью открыт?
Политика пакетов	Какие пакеты можно устанавливать, откуда и с каким контролем версий?
Граница секретов	Хранятся ли ключи API, учетные данные базы данных и токены сервисов вне песочницы, если явно не заданы?
Журналы	Регистрируются ли команды, установки пакетов, ошибки, чтение/запись файлов и выходные артефакты?
Проверка человеком	Какие планы, фрагменты кода, запросы пакетов и выходные данные требуют одобрения?
Очистка	Когда удаляются состояние песочницы, загруженные файлы, сгенерированные скрипты, журналы и выходные данные?

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

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

Использование Novita Agent Sandbox в качестве уровня выполнения

Novita Agent Sandbox предоставляет изолированные, сохраняющие состояние среды выполнения для AI-агентов. Текущая документация Novita описывает поддержку запуска кода, установки зависимостей, доступа к файлам, использования браузеров и сохранения состояния выполнения между сессиями. Для AI-аналитика данных эти примитивы напрямую отображаются на часть выполнения архитектуры: создать рабочее пространство задания, переместить файлы, выполнить код анализа, собрать артефакты и очистить или сохранить состояние в зависимости от дизайна сессии.

Документация Novita Agent Sandbox SDK и CLI перечисляет официальную поддержку SDK для Python и JavaScript/TypeScript, что подходит для общих бэкендов приложений. Документация файловой системы песочницы описывает изолированную файловую систему с фиксированным пространством хранения 20 ГБ для песочниц, что полезно для размещения CSV-файлов и сгенерированных артефактов в рабочем пространстве, привязанном к заданию.

Помните о различии:

• Рекомендации по реализации в этой статье описывают общую архитектуру для приложений AI-аналитика данных.
• Novita Agent Sandbox может предоставить уровень выполнения песочницы для этих рабочих процессов.
• Ваше приложение по-прежнему отвечает за аутентификацию пользователя, политику хранения данных, одобрение пакетов, сетевую политику, проверку вывода и решения по публикации/развертыванию.

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

Заключение

Сильнейший дизайн AI-аналитика данных — это не «пусть модель запускает Python». Это управляемый цикл: проверить набор данных, запросить у модели план, просмотреть сгенерированный код, выполнить его в песочнице, собрать проверенные артефакты, показать пользователю, что произошло, и очистить состояние после завершения задания. Такая структура обеспечивает быстрый пользовательский опыт, одновременно предоставляя командам разработки и безопасности конкретные контрольные точки для оценки перед выходом в продакшн.

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

Часто задаваемые вопросы

Почему AI-аналитику данных нужна песочница?

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

Должна ли модель видеть полный CSV?

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

Можно ли разрешать установку пакетов?

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

Какие файлы приложение должно возвращать пользователям?

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

Является ли это гарантией соответствия требованиям?

Нет. Песочница — это одна часть архитектуры выполнения. Одобрение соответствия и безопасности зависит от ваших данных, модели угроз, средств контроля, регистрации, хранения, процесса проверки и среды развертывания.

Рекомендуемые статьи

• Как песочницы агентов обеспечивают безопасные, масштабируемые AI-инновации
• Создание агента-программиста с помощью Agent Sandbox от Novita
• Запуск оценок Harbour Agent на Novita Agent Sandbox