AI-система анализа данных с Text-to-Code: быстрая генерация SQL и Python

Почему ad-hoc запросы тормозят аналитику

Бизнес-пользователь хочет увидеть топ-10 продаж по категориям за последнюю неделю. Традиционный путь: запрос аналитику, уточнение требований, ожидание в очереди. Ответ приходит через пару дней. Text-to-Code решает иначе. LLM превращает вопрос на русском в код Python или SQL. Затем выполняет его и возвращает результат с визуализацией. Всё это занимает секунды. Согласно Gartner, доля NLQ-запросов вырастет до 60% в ближайшие годы.

Недавно мы внедрили Text-to-Code для ритейл-сети с 500 магазинами. Раньше на запрос 'покажи средний чек по регионам за прошедший месяц' уходило 2 дня. Теперь ответ приходит за 15 секунд. Аналитики переключились на сложные задачи, а бизнес-пользователи получили самообслуживание. За 5 лет работы мы реализовали более 50 проектов AI-аналитики.

Как Text-to-Code ускоряет работу с данными

Классическая BI требует заранее спроектированных дашбордов. Каждый новый вопрос — 1–3 дня на согласование и разработку. Text-to-Code сокращает это до 10–30 секунд. Аналитики тратят на рутину на 70% меньше времени. Бизнес-пользователи получают самообслуживание для 80% стандартных запросов. Text-to-Code в 10–50 раз быстрее традиционных BI-запросов.

Почему безопасность кода — главный риск?

Главный риск Text-to-Code — вредоносный или некорректный код. Наша изоляция строится на трёх уровнях:

• Sandbox-контейнер: выполнение в изолированном окружении с ограниченным доступом к файловой системе и сети. Используем Docker или gVisor.
• Whitelist модулей: разрешены только pandas, numpy, plotly и встроенные функции Python. Запросы на импорт сторонних библиотек блокируются.
• Валидация результата: типы выходных данных проверяются, код логируется для аудита.

Пример конфигурации Docker-контейнера для изоляции кода:

version: '3.8'
services:
  sandbox:
    image: python:3.11-slim
    command: tail -f /dev/null
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    volumes:
      - ./data:/data:ro
    environment:
      - PYTHONDONTWRITEBYTECODE=1
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 2G

Реализация на примере AIDataAnalyst

from anthropic import Anthropic
import pandas as pd
import io

class AIDataAnalyst:
    def __init__(self, dataframes: dict[str, pd.DataFrame]):
        self.dfs = dataframes
        self.llm = Anthropic()
        self.schema = self._build_schema()

    def _build_schema(self) -> str:
        schema_parts = []
        for name, df in self.dfs.items():
            schema_parts.append(f"Table: {name}")
            schema_parts.append(f"Shape: {df.shape[0]} rows x {df.shape[1]} columns")
            schema_parts.append("Columns:")
            for col in df.columns:
                dtype = str(df[col].dtype)
                n_unique = df[col].nunique()
                sample = str(df[col].dropna().head(3).tolist())
                schema_parts.append(f"  - {col} ({dtype}, {n_unique} unique): {sample}")
            schema_parts.append("")
        return '\n'.join(schema_parts)

    def analyze(self, question: str) -> dict:
        """Анализ данных по вопросу на естественном языке"""
        system_prompt = f"""You are a data analyst. You have access to these dataframes:
{self.schema}

Write Python code using pandas to answer the user's question.
The dataframes are available as: {list(self.dfs.keys())}
Return ONLY the Python code, no explanations. Use variable 'result' for the final result."""

        response = self.llm.messages.create(
            model="claude-3-5-sonnet-20241022",
            max_tokens=1000,
            system=system_prompt,
            messages=[{"role": "user", "content": question}]
        )

        code = response.content[0].text.strip()
        if code.startswith("```python"):
            code = code[9:-3].strip()

        result = self._execute_safely(code)

        # Генерация объяснения
        explanation = self._generate_explanation(question, result, code)

        return {
            'question': question,
            'code': code,
            'result': result,
            'explanation': explanation
        }

    def _execute_safely(self, code: str) -> any:
        """Безопасное выполнение сгенерированного кода"""
        import builtins

        # Разрешённые функции
        safe_globals = {
            '__builtins__': {
                'len': builtins.len, 'range': builtins.range,
                'list': builtins.list, 'dict': builtins.dict,
                'str': builtins.str, 'int': builtins.int,
                'float': builtins.float, 'print': builtins.print,
                'sorted': builtins.sorted, 'sum': builtins.sum,
                'min': builtins.min, 'max': builtins.max,
                'round': builtins.round, 'abs': builtins.abs,
            },
            'pd': pd,
            'np': __import__('numpy'),
        }

        # Добавление датафреймов
        safe_globals.update(self.dfs)

        local_vars = {}
        exec(code, safe_globals, local_vars)

        return local_vars.get('result')

    def _generate_explanation(self, question: str, result, code: str) -> str:
        result_str = str(result)[:2000] if result is not None else "No result"

        response = self.llm.messages.create(
            model="claude-3-5-sonnet-20241022",
            max_tokens=300,
            messages=[{
                "role": "user",
                "content": f"""Question: {question}
Analysis result: {result_str}

Provide a clear 2-3 sentence business explanation of this result."""
            }]
        )
        return response.content[0].text

Как автоматическая визуализация выбирает график?

class AutoVisualizer:
    def create_chart(self, data, question: str) -> str:
        """Автоматический выбор и создание визуализации"""
        chart_type = self._suggest_chart_type(data, question)

        import plotly.express as px

        if isinstance(data, pd.DataFrame):
            if chart_type == 'bar':
                fig = px.bar(data, x=data.columns[0], y=data.columns[1],
                             title=question[:80])
            elif chart_type == 'line':
                fig = px.line(data, x=data.columns[0], y=data.columns[1:],
                              title=question[:80])
            elif chart_type == 'scatter':
                fig = px.scatter(data, x=data.columns[0], y=data.columns[1],
                                 title=question[:80])
            elif chart_type == 'pie':
                fig = px.pie(data, names=data.columns[0], values=data.columns[1],
                             title=question[:80])

            return fig.to_html(include_plotlyjs='cdn', full_html=False)

        return None

Что входит в разработку AI-системы?

Мы предоставляем полный комплект документации и артефактов:

• Model card — спецификация выбранной LLM, параметры инференса, версии библиотек;
• Конфигурационные файлы — Docker Compose, переменные окружения, скрипты развертывания;
• Интерактивный Playbook — описание всех компонентов и инструкции по настройке;
• Нагрузочное тестирование — отчёт с латентностью p50/p99, FLOPS, GPU utilization при пиковых нагрузках;
• Обучение команды — 2-3 сессии по эксплуатации и дообучению модели;
• Пост-релизная поддержка — 30 дней инцидент-менеджмента и доработок.

Сравнение моделей для Text-to-Code:

Этапы работы и ориентировочные сроки

1. Аналитика (2–3 дня): разбираем ваши данные, определяем типовые запросы, выбираем LLM и архитектуру.
2. Проектирование (3–5 дней): схема RAG, sandbox, pipeline код-генерации.
3. Реализация (7–10 дней): интеграция LLM, написание компонентов, визуализации.
4. Тестирование (3–5 дней): юнит-тесты, нагрузочное тестирование, проверка безопасности.
5. Деплой (2–3 дня): развертывание на вашей инфраструктуре или в облаке, передача документации.

Ориентировочный срок — от 17 до 26 дней. Стоимость рассчитывается индивидуально после аудита данных и требований. Гарантируем безопасность выполнения кода и конфиденциальность данных. Опыт работы с чувствительными данными подтверждён сертификатами. Получите консультацию — свяжитесь с нами для оценки вашего проекта. Закажите бесплатный аудит ваших данных.

Data Engineering для ML: пайплайны, разметка и качество данных

«У нас много данных» — фраза, которая на деле часто означает «у нас много сырых логов в S3, которые никто не трогал два года». Перед тем как обучить модель, нужно понять, что вообще есть: какова структура, есть ли дубли, как часто меняется схема, насколько репрезентативна выборка.

Data Engineering для ML — не просто ETL. Это построение воспроизводимой инфраструктуры данных, которая делает обучение моделей надёжным, а переобучение — предсказуемым. По опыту нашей команды (8 лет в дата-инжиниринге, более 30 проектов в ML) каждая вторая проблема в продакшене связана не с архитектурой модели, а с качеством данных.

ETЛ-пайплайны для ML: чем отличаются от BI

ETL для аналитики и ETL для ML — разные задачи. В аналитике важна агрегация, в ML — индивидуальные записи с историей. В аналитике train/val/test split не нужен, в ML — критичен. В аналитике skew данных мешает интерпретации, в ML — напрямую влияет на качество модели.

Инструменты. Apache Spark (Wikipedia) для больших объёмов (10GB+): PySpark с DataFrames, оптимизации через partitioning и caching. dbt для трансформаций поверх DWH (Snowflake, BigQuery, Redshift) — декларативно, версионируется, тестируется. Pandas + Polars для объёмов до нескольких GB — Polars в 5-10x быстрее Pandas на типичных трансформациях.

Temporal splits. Для ML важно, что split по времени, а не случайный. Если данные временные (транзакции, события пользователей), случайный split даёт data leakage: модель видит «будущие» данные при обучении. Правило: train на периоде T1-T2, validation на T2-T3 (с gap для предотвращения leakage), test на T3-T4. Неправильный split может стоить 10–15% качества модели на валидации.

Инкрементальные пайплайны. Модель переобучается еженедельно на новых данных. Нужен пайплайн, который инкрементально добавляет новые записи к обучающей выборке, не перегружая всё с нуля. Delta Lake или Apache Iceberg — форматы с ACID-транзакциями, Change Data Capture, time travel.

Как избежать training-serving skew с помощью Feature Store

Feature Store решает проблему рассинхронизации между обучением и инференсом. Самая коварная ошибка в ML-инфраструктуре — training-serving skew: признак считается по-разному в обучении и в продакшене. Модель учится на «правильных» данных, а инференс получает другие.

Feast (open source) — офлайн store на Parquet/Delta в S3 для обучения, онлайн store на Redis для low-latency инференса (<10ms). Feature definitions как Python-код:

from feast import FeatureView, Field
from feast.types import Float32, Int64

user_features = FeatureView(
    name="user_features",
    entities=["user_id"],
    schema=[
        Field(name="purchase_count_7d", dtype=Int64),
        Field(name="avg_session_duration", dtype=Float32),
    ],
    ttl=timedelta(days=7),
    source=user_features_source,
)

Один definition, используется везде. Нет расхождений.

Потоковые признаки. Когда признак должен обновляться в реальном времени (количество транзакций за последние 10 минут), нужна потоковая обработка. Apache Kafka + Apache Flink или Kafka Streams для вычисления признаков в реальном времени → запись в онлайн store. Сложнее, дороже, нужно только когда staleness признаков критична для качества.

Разметка данных: как не потратить бюджет впустую

Разметка — самая трудоёмкая и недооцениваемая часть ML-проекта. Плохо размеченные данные не исправит никакая архитектура.

Label Studio — open source, поддерживает разметку изображений (bounding box, polygon, segmentation), текста (NER, классификация), аудио, видео. Поднимается за 10 минут через Docker. Для небольших команд — первый выбор.

Оценка качества разметки. Inter-annotator agreement — насколько согласны разметчики между собой. Cohen's Kappa > 0.8 — хорошо, 0.6-0.8 — приемлемо, < 0.6 — задача неоднозначна или инструкция плохая. Пересечение разметок (10-20% примеров размечают два независимых аннотатора) — обязательная практика.

Active learning. Не размечать случайные примеры, а выбирать те, на которых модель наиболее неуверена (low confidence, high uncertainty). Позволяет добиться того же качества при 50-70% объёма разметки. Modals, Prodigy, Label Studio поддерживают active learning workflows. На одном из проектов для NLP мы сократили бюджет на разметку в 2,5 раза за счёт active learning.

Синтетические данные. Когда реальных данных мало или получить их дорого. Для CV: рендеринг в Blender/Unity с реалистичными текстурами (domain randomization). Для NLP: parafrase через LLM, backtranslation. Риск: модель обучается на distribution синтетических данных, а не реальных — нужна осторожность и проверка на реальном holdout.

Качество данных: валидация и мониторинг

Great Expectations — de facto стандарт для data validation в ML-пайплайнах. Expectations — это декларативные утверждения о данных: «колонка age содержит значения от 0 до 120», «колонка user_id не содержит null», «распределение amount не отклоняется более чем на 20% от baseline». Запускается в пайплайне, при провале — блокирует прохождение.

Pandera — Pythonic alternative для pandas/polars DataFrames. Schema-based validation с type hints:

import pandera as pa

schema = pa.DataFrameSchema({
    "user_id": pa.Column(int, nullable=False),
    "score": pa.Column(float, pa.Check.between(0, 1)),
    "label": pa.Column(str, pa.Check.isin(["positive", "negative", "neutral"])),
})

Data freshness. Модель ожидает данные за последние N дней. ETL упал, данные не обновились — модель использует устаревшие признаки. Мониторинг свежести данных: timestamp последней записи в каждой таблице, алерт при задержке > порога.

Дедупликация. Дубликаты в обучающей выборке завышают метрики (одни и те же примеры в train и val) и искажают веса модели. MinHash LSH для приближённой дедупликации больших датасетов. Для точной — хэш по нормализованному контенту.

Инструменты валидации: сравнение

Хранилища и форматы

Для большинства ML-проектов на старте: Parquet в S3 + DVC для версионирования. Delta Lake или Iceberg — когда появляется потребность в инкрементальных обновлениях или time travel.

Что входит в проект по дата-инжинирингу для ML

Мы предоставляем полный цикл:

• Аудит существующих данных и пайплайнов (1 неделя).
• Проектирование архитектуры: выбор инструментов, форматов, способов разметки.
• Реализация ETL/ELT пайплайна с валидацией и мониторингом.
• Документация кода и процессов (model card, data card).
• Обучение вашей команды работе с пайплайном.
• SLA на сопровождение и поддержку.

Как мы строим пайплайн: пошагово

1. Аудит существующих данных. Профилирование: ydata-profiling (бывший pandas-profiling) генерирует HTML-репорт со статистиками, дистрибуциями, корреляциями, missing values за минуты.
2. Проектирование пайплайна. Определяем источники данных, частоту обновления, требования к latency признаков, объёмы.
3. Реализация и тестирование. Unit-тесты на трансформации, integration-тесты на пайплайн, data validation через Great Expectations.
4. Деплой и мониторинг. Алерты на freshness, quality checks, аномалии в объёмах данных.

Почему стоит доверить это нам

Мы занимаемся дата-инжинирингом и ML с 2016 года. За это время реализовали более 40 проектов — от построения пайплайнов для NLP-моделей до разметки датасетов для компьютерного зрения. Гарантируем воспроизводимость пайплайнов и полную прозрачность процессов. В каждом проекте используем инструменты с открытым исходным кодом, чтобы вы не были привязаны к вендору.

Свяжитесь с нами для бесплатного аудита ваших данных — оценим текущий пайплайн и предложим roadmap. Закажите построение ML-пайплайна под ключ.