- Архитектура AI-аналитика данных: загрузка, анализ, проверка
- Что выполняется внутри изолированной среды Python для анализа данных?
- Как должны работать загрузка CSV и проверка схемы?
- Как модель безопасно генерирует и выполняет Python?
- Контролируемый доступ к пакетам Python для AI-анализа данных
- Как проверять графики и выходные файлы
- Контрольные точки безопасности перед производством
- Использование Novita Agent Sandbox в качестве уровня выполнения
- Заключение
- Часто задаваемые вопросы
- Рекомендованные статьи
AI-аналитику данных требуется изолированный Python, когда наборы данных от пользователя, сгенерированный моделью код, установка пакетов, созданные графики и загружаемые результаты должны выполняться в изолированной, наблюдаемой среде. Практический поток реализации таков: загрузить файл, проверить схему с помощью доверенного кода, запросить у модели план, проверить сгенерированный Python, выполнить его в ограниченной изолированной среде, проверить выходные артефакты и показать пользователю, что произошло.
Архитектура AI-аналитика данных: загрузка, анализ, проверка
Шаблон продукта прост на поверхности: пользователь загружает CSV, задаёт вопрос на естественном языке и ожидает полезные таблицы, графики и загружаемые файлы. Под капотом приложение выполняет небольшой рабочий процесс агента с реальными побочными эффектами. Модель планирует анализ и пишет код на Python, в то время как приложение решает, какой код, пакеты, файлы, сетевой доступ и выходные данные разрешены.
Создайте первую версию вокруг одного чёткого пути:
- Принять загрузку CSV для одного задания анализа.
- Создать рабочее пространство в изолированной среде для задания.
- Запустить собственный код проверки схемы до того, как запросить у модели код Python.
- Запросить у модели план анализа, а затем скрипт, который следует вашим правилам для файлов и пакетов.
- Выполнить скрипт с ограничениями по времени, памяти, диску, пакетам и сети.
- Собрать только проверенные артефакты из заданного выходного каталога.
- Показать пользователю ответ, графики, предупреждения, журналы и файлы, выбранные для загрузки.
Такое разделение сохраняет ответственность чёткой. Модель предлагает и объясняет анализ. Бэкенд применяет политику продукта и оркестрацию. Изолированная среда выполняет код с ограничениями на файлы, пакеты, время, память, сетевой доступ и секреты.
Что выполняется внутри изолированной среды Python для анализа данных?
Поместите рабочее пространство анализа внутрь изолированной среды, а не на ваш основной сервер приложения. Изолированная среда должна получать узкий входной набор для одного задания анализа: загруженный файл, небольшой манифест, сгенерированный скрипт и любую одобренную конфигурацию выполнения. Бэкенд приложения должен хранить аутентификацию, биллинг, идентификацию пользователя, долгосрочное хранение и производственные секреты вне этого рабочего пространства.
Для AI-аналитика данных изолированная среда обычно выполняет следующие задачи:
| Задача изолированной среды | Почему она должна быть там |
|---|---|
| Размещение файлов | Загруженный CSV может быть просканирован и скопирован в изолированный рабочий каталог до того, как Python его коснётся. |
| Проверка схемы | Приложение может определить имена столбцов, типы, долю пропусков, количество строк и примеры значений без передачи полного файла модели. |
| Выполнение Python | Сгенерированный моделью код выполняется вдали от сервера приложения и может быть ограничен по времени. |
| Подготовка пакетов | Только одобренные зависимости устанавливаются или становятся доступными для задания. |
| Рендеринг графиков | Изображения графиков записываются в виде файлов и проверяются перед загрузкой. |
| Упаковка результатов | Итоговые артефакты могут быть собраны из известного выходного каталога. |
| Очистка | Временные файлы, сгенерированный код и состояние сессии могут быть удалены или им можно дать истечь. |
Делайте запрос модели меньше, чем данные. Отправляйте сводку схемы, несколько репрезентативных строк, если политика позволяет, описания столбцов, намерение пользователя и ограничения, такие как «не обучать модель» или «использовать только одобренные пакеты». Исходный набор данных должен оставаться в файловой системе изолированной среды, если только ваш продукт не имеет конкретной, проверенной причины раскрыть больше.
Как должны работать загрузка CSV и проверка схемы?
Начните с обработки каждой загрузки как ненадёжного ввода. Проверьте тип файла, размер, кодировку, разделитель, количество строк, количество столбцов и подозрительные формулы до того, как модель будет вовлечена. CSV всё ещё может содержать значения, которые запускают выполнение формул электронных таблиц при последующем открытии, поэтому экспортированные файлы должны быть очищены для целевого формата.
Практический поток загрузки выглядит так:
- Пользователь загружает CSV в приложение.
- Бэкенд сохраняет исходный файл под ключом объекта или путём размещения, привязанным к заданию.
- Бэкенд создаёт сессию изолированной среды для задания.
- Бэкенд копирует файл в рабочий каталог изолированной среды.
- Небольшой детерминированный скрипт проверки читает файл и создаёт сводку схемы.
- Модель получает сводку схемы, вопрос пользователя, разрешённые библиотеки и требования к выходным данным.
Шаг проверки должен быть детерминированным кодом, который вы контролируете, а не кодом, сгенерированным моделью. Он может создать компактную сводку в формате 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-аналитика данных эти примитивы напрямую отображаются на часть выполнения архитектуры: создание рабочего пространства задания, перемещение файлов внутрь, выполнение кода анализа, сбор артефактов и очистка или сохранение состояния в зависимости от дизайна сессии.
Документация по SDK и CLI Novita Agent Sandbox указывает на официальную поддержку SDK для Python и JavaScript/TypeScript, что соответствует распространённым бэкендам приложений. Документация по файловой системе изолированной среды описывает изолированную файловую систему с фиксированным пространством хранения 20 ГБ для изолированных сред, полезное для размещения CSV-файлов и сгенерированных артефактов в рамках рабочего пространства задания.
Сохраняйте различие чётким:
- Рекомендации по реализации в этой статье описывают общую архитектуру для приложений AI-аналитика данных.
- Novita Agent Sandbox может предоставить уровень выполнения изолированной среды для этих рабочих процессов.
- Ваше приложение по-прежнему отвечает за аутентификацию пользователей, политику хранения данных, утверждение пакетов, сетевую политику, проверку выходных данных и решения по публикации/развёртыванию.
Такое разделение помогает командам строить с чистой моделью ответственности. Модель предлагает и объясняет анализ. Приложение применяет политику продукта. Изолированная среда предоставляет контролируемую среду выполнения, где код, файлы, пакеты, графики и журналы могут обрабатываться вдали от основного сервера приложения.
Заключение
Сильнейший дизайн AI-аналитика данных — это не «пусть модель запускает Python». Это контролируемый цикл: проверьте набор данных, запросите у модели план, проверьте сгенерированный код, выполните его в изолированной среде, соберите проверенные артефакты, покажите пользователю, что произошло, и очистите состояние, когда задание завершено. Такая структура обеспечивает быстрый пользовательский опыт, одновременно давая командам разработки и безопасности конкретные контрольные точки для оценки перед запуском в производство.
Для команд, создающих такой шаблон, начинайте с малого: загрузка CSV, проверка схемы, короткий белый список пакетов, вывод графиков, строгие тайм-ауты и видимый экран проверки. Добавляйте более широкий доступ к пакетам, сетевые инструменты, сохранение состояния и автоматизацию только после того, как границы задокументированы и протестированы.
Часто задаваемые вопросы
Зачем AI-аналитику данных нужна изолированная среда?
Она ему нужна, поскольку рабочий процесс сочетает в себе ненадёжные файлы, сгенерированный моделью Python, запросы пакетов, создание графиков и загружаемые артефакты. Выполнение этой работы в отдельной среде даёт вашему приложению возможность применять контроль над файлами, ресурсами, пакетами, сетью, журналированием и очисткой.
Должна ли модель видеть полный CSV?
Обычно нет. Начните с отправки модели сводки схемы, безопасных образцов, описаний столбцов и вопроса пользователя. Храните исходный файл в изолированной среде, если только ваш продукт не имеет проверенной причины раскрыть больше данных модели.
Можно ли разрешить установку пакетов?
Да, но она должна контролироваться. Используйте предварительно собранный образ, белый список, фиксированные версии, частное зеркало или рабочий процесс утверждения. Не позволяйте сгенерированному моделью коду устанавливать произвольные пакеты из публичного интернета без проверки.
Какие файлы приложение должно возвращать пользователям?
Возвращайте только проверенные файлы из известного выходного каталога, такие как изображения графиков, сводка JSON и очищенные экспортированные CSV. Блокируйте неожиданные расширения, большие файлы, скрытые пути и артефакты, которые не были частью контракта на выходные данные.
Является ли это гарантией соответствия требованиям?
Нет. Изолированная среда — это одна часть архитектуры выполнения. Соответствие требованиям и одобрение безопасности зависят от ваших данных, модели угроз, мер контроля, журналирования, хранения, процесса проверки и среды развёртывания.
