AI-аналіз даних з Text-to-Code: генерація SQL та Python за секунди

Чому ad-hoc запити гальмують аналітику

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

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

Як Text-to-Code прискорює роботу з даними

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

Чому безпека коду — головний ризик?

Головний ризик 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:

Типові помилки при впровадженні Text-to-Code

• Відсутність sandbox-ізоляції: виконання згенерованого коду без обмежень може призвести до витоків даних або пошкодження системи.
• Ігнорування контексту даних: без передачі схеми (таблиці, типи, приклади) LLM може згенерувати некоректний код.
• Недостатнє тестування латентності: при високих навантаженнях час відповіді може зрости, тому обов'язкове навантажувальне тестування.
• Відсутність логування: без логів неможливо аудитувати запити та виправляти помилки.

Етапи роботи та орієнтовні терміни

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

Орієнтовний термін — від 17 до 26 днів. Вартість розраховується індивідуально після аудиту даних та вимог. Гарантуємо безпеку виконання коду та конфіденційність даних. Досвід роботи з чутливими даними підтверджено сертифікатами. Отримайте консультацію — зв'яжіться з нами для оцінки вашого проекту. Замовте безкоштовний аудит ваших даних.

Чому дата-інжиніринг визначає успіх ML-моделі

Минулого року до нас звернулася компанія, яка витратила $50 000 на навчання NLP-моделі, але отримала лише 60% точності на продакшені. Причина — data leakage через випадковий split часових даних. Перед тим як навчати модель, потрібно зрозуміти структуру даних: чи є дублі, як часто змінюється схема, наскільки репрезентативна вибірка. Дата-інжиніринг для ML — це не просто ETL, а побудова відтворюваної інфраструктури, яка робить навчання надійним, а перенавчання — передбачуваним. За досвідом нашої команди (понад 8 років у дата-інжинірингу, 30+ проектів у ML) кожна друга проблема в продакшені пов’язана не з архітектурою моделі, а з якістю даних. Замовте аудит ваших даних — оцінимо поточний пайплайн безкоштовно.

Як ETL-пайплайни для ML відрізняються від BI

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

Інструменти. Apache Spark для великих обсягів (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% якості моделі на валідації. Temporal split best practices (scikit-learn docs)

Інкрементальні пайплайни. Модель перенавчається щотижня на нових даних. Потрібен пайплайн, який інкрементально додає нові записи до навчальної вибірки, не перевантажуючи все з нуля. 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 — економія склала $15 000 на 100 000 розмічених прикладів.

Синтетичні дані. Коли реальних даних мало або отримати їх дорого. Для 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.

Типові помилки при побудові пайплайнів

• Пропуск перевірки свіжості даних. Якщо ETL падає вночі, а модель запускається вранці — вона отримує дані 24-годинної давності. Рішення: алерт при затримці > 30 хвилин.
• Відсутність версіонування даних. Не можна відтворити експеримент, бо дані змінилися. DVC або Delta Lake time travel виправляють це.
• Забувають про schema evolution. Нове поле з’являється, а пайплайн падає. Автоматичне виявлення змін схеми через Great Expectations.

Active learning дозволяє скоротити бюджет на розмітку до 50–70%. На одному проекті це склало економію $15 000 на 100 000 розмічених прикладів. Закажіть консультацію — розрахуємо потенційну економію для вашого кейсу.

Що входить у проект з дата-інжинірингу для ML

Ми надаємо повний цикл:

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

Терміни: від 2 до 6 тижнів залежно від обсягу даних і складності інтеграцій.

Як ми будуємо пайплайн: покроково

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

Чому варто довірити це нам

Ми займаємося дата-інжинірингом та ML з понад 8-річним досвідом. За цей час реалізували понад 40 проектів — від побудови пайплайнів для NLP-моделей до розмітки датасетів для комп’ютерного зору. Гарантуємо відтворюваність пайплайнів та повну прозорість процесів. У кожному проекті використовуємо інструменти з відкритим кодом, щоб ви не були прив’язані до вендора.

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