ИИ против рутины: автоматизируем Power BI от DAX до схемы данных

Почему Power BI до сих пор ручная работа

Представьте типичный день BI-разработчика. Вы тратите часы на написание похожих друг на друга DAX-формул. Переписываете SQL-запросы для Power Query. Вручную документируете связи между таблицами. И все это ради одного отчета. А потом их становится десять. Сто. И вы превращаетесь в машину по производству кода.

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

Три точки боли, где ИИ бьет точно в цель

Давайте отбросим маркетинговую шелуху про "умные дашборды". ИИ в Power BI полезен там, где он заменяет рутину. Вот три конкретные задачи, которые можно автоматизировать уже сегодня:

• Генерация DAX по описанию на русском — вместо того чтобы вспоминать синтаксис, вы говорите "посчитай нарастающий итог по месяцам" и получаете готовую формулу.
• Создание SQL-запросов из DAX-логики — когда нужно выгрузить те же данные, что считаются в отчете, но в сыром виде.
• Экспорт и анализ схемы данных — автоматическое документирование всех таблиц, мер и связей в проекте.

Звучит как фантастика? Это уже работает. И для этого не нужны дорогие плагины или серверные лицензии. Достаточно Python, .NET библиотек и любого современного LLM вроде GPT-4 или Claude.

Сначала испортьте — потом автоматизируйте

Прежде чем показывать, как делать правильно, давайте посмотрим на типичные ошибки. Вот как НЕ надо подходить к автоматизации Power BI:

Вот пример промпта, который гарантированно даст мусор:

# ПЛОХОЙ ПРОМПТ
Напиши полный Power BI отчет для анализа продаж

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

1Подготовка: достаем кишки Power BI

Power BI хранит всю свою магию в двух местах: в PBIX файле (это просто ZIP архив) и в Tabular Server (если используете серверную версию). Нам нужно научиться с этим разговаривать.

Для локальных файлов используем библиотеку Microsoft.AnalysisServices.Tabular. Она позволяет читать модель как объектную структуру:

using Microsoft.AnalysisServices.Tabular;
using System.IO;
using System.IO.Compression;

// PBIX - это ZIP. Достаем DataModelSchema из него
var tempPath = Path.GetTempFileName();
using (var archive = ZipFile.OpenRead("report.pbix"))
{
    var entry = archive.GetEntry("DataModelSchema");
    entry.ExtractToFile(tempPath, true);
}

// Загружаем схему
var database = JsonSerializer.Deserialize(File.ReadAllText(tempPath));

// Теперь у нас есть вся структура
foreach (var table in database.Model.Tables)
{
    Console.WriteLine($"Таблица: {table.Name}");
    Console.WriteLine($"Колонки: {table.Columns.Count}");
    Console.WriteLine($"Меры: {table.Measures.Count}");
}

Для серверных моделей подключаемся через AdomdConnection. Это тот же протокол, который использует Power BI Desktop для общения с сервером:

using Microsoft.AnalysisServices.AdomdClient;

var connectionString = "Data Source=powerbi://api.powerbi.com/v1.0/myorg/WorkspaceName;Initial Catalog=DatasetName";
using (var conn = new AdomdConnection(connectionString))
{
    conn.Open();
    
    // Получаем метаданные
    var cube = conn.Cubes[0];
    foreach (Microsoft.AnalysisServices.AdomdClient.Measure measure in cube.Measures)
    {
        Console.WriteLine($"Мера: {measure.Name}");
        Console.WriteLine($"Выражение: {measure.Expression}");
    }
}

2Генерация DAX: говорим по-русски, получаем код

Теперь у нас есть структура модели. Мы знаем имена таблиц, колонок, существующих мер. Это контекст, который нужен ИИ для генерации корректного DAX.

Вот как выглядит правильный промпт:

Ты эксперт по DAX и Power BI.

Структура модели:
Таблица "Продажи":
- Ключ_продажи (целое число)
- Дата_продажи (дата)
- Сумма (десятичное)
- Товар_ID (целое)

Таблица "Товары":
- Товар_ID (целое)
- Название_товара (текст)
- Категория (текст)

Существующие меры:
- [Общая сумма] = SUM('Продажи'[Сумма])

Задача: Создай меру "Продажи за текущий месяц" на русском языке.
Требования:
1. Используй только существующие таблицы и колонки
2. Учитывай фильтры по дате из срезов
3. Возвращай только DAX код без пояснений

ИИ с такой инструкцией выдаст что-то вроде:

Продажи за текущий месяц = 
CALCULATE(
    [Общая сумма],
    FILTER(
        ALL('Продажи'[Дата_продажи]),
        YEAR('Продажи'[Дата_продажи]) = YEAR(TODAY()) &&
        MONTH('Продажи'[Дата_продажи]) = MONTH(TODAY())
    )
)

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

import openai
from typing import List
from dataclasses import dataclass

@dataclass
class TableSchema:
    name: str
    columns: List[str]
    measures: List[str]

def generate_dax_prompt(table_schemas: List[TableSchema], 
                        existing_measures: List[str],
                        task_description: str) -> str:
    """Генерирует промпт для создания DAX меры"""
    
    schema_text = "\n".join([
        f"Таблица '{t.name}':\n" + 
        "\n".join([f"  - {col}" for col in t.columns]) + 
        (f"\n  Меры: {', '.join(t.measures)}" if t.measures else "")
        for t in table_schemas
    ])
    
    return f"""Ты эксперт по DAX. Используй только эти таблицы и колонки:

{schema_text}

Существующие меры:
{"\n".join(existing_measures)}

Задача: {task_description}

Требования:
1. Используй только указанные таблицы и колонки
2. Учитывай контекст фильтров
3. Возвращай только DAX код
"""

# Использование
schemas = [
    TableSchema("Продажи", ["Ключ_продажи", "Дата_продажи", "Сумма", "Товар_ID"], []),
    TableSchema("Товары", ["Товар_ID", "Название_товара", "Категория"], [])
]

existing = ["[Общая сумма] = SUM('Продажи'[Сумма])"]
task = "Создай меру 'Средний чек по категориям'"

prompt = generate_dax_prompt(schemas, existing, task)
# Отправляем prompt в GPT-4 или другой LLM

3От DAX к SQL: когда данные нужно выгрузить, а не визуализировать

Ситуация: у вас есть сложный отчет в Power BI с десятками мер. Бизнес просит: "Дай мне те же цифры, но в Excel". Вы начинаете копировать DAX, пытаться понять, как это перевести в SQL... И тратите полдня.

ИИ может сделать это за минуты. Но есть нюанс: DAX и SQL работают с разными парадигмами. DAX вычисляет агрегаты в контексте фильтров, SQL просто выбирает данные. Нужно объяснить эту разницу модели.

Вот промпт, который учитывает эту разницу:

Переведи эту DAX меру в SQL запрос для PostgreSQL.

DAX мера:
[Продажи по категориям] = 
CALCULATE(
    SUM('Продажи'[Сумма]),
    VALUES('Товары'[Категория])
)

Структура таблиц:
Таблица sales (продажи):
- sale_id (bigint)
- sale_date (date)
- amount (decimal)
- product_id (bigint)

Таблица products (товары):
- product_id (bigint)
- product_name (varchar)
- category (varchar)

Примечания:
1. DAX VALUES() возвращает уникальные значения в текущем контексте
2. В SQL нужно явно группировать по категориям
3. Добавь комментарии о том, какие фильтры нужно добавить вручную

Хороший ИИ даст примерно такой результат:

-- Эквивалент DAX меры [Продажи по категориям]
-- Внимание: DAX автоматически применяет фильтры из отчета
-- В SQL эти фильтры нужно добавить вручную в WHERE

SELECT 
    p.category,
    SUM(s.amount) as total_sales
FROM 
    sales s
JOIN 
    products p ON s.product_id = p.product_id
-- Добавь фильтры здесь, например:
-- WHERE s.sale_date >= '2024-01-01'
GROUP BY 
    p.category
ORDER BY 
    total_sales DESC;

Можно автоматизировать и это. Создайте скрипт, который:

1. Читает DAX меры из Power BI модели
2. Читает схему SQL базы (из Information Schema)
3. Генерирует промпт для перевода
4. Запускает через LLM API
5. Сохраняет результат в .sql файлы

Получается конвейер: обновили меру в Power BI → запустили скрипт → получили SQL для выгрузки данных.

4Экспорт метаданных: когда нужно понять, что вообще происходит

У вас есть Power BI отчет с 50 таблицами, 200 мерами и кучей связей. Новый разработчик присоединяется к проекту. Он спрашивает: "Где считается выручка?" Вы пожимаете плечами — нужно искать.

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

Используем TOM (Tabular Object Model) для экспорта:

using Microsoft.AnalysisServices.Tabular;
using System.Text.Json;

// Загружаем модель из PBIX или сервера
var database = LoadModelFromPBIX("report.pbix");

// Создаем структурированный JSON
var modelInfo = new
{
    LastUpdated = DateTime.UtcNow,
    Tables = database.Model.Tables.Select(t => new
    {
        Name = t.Name,
        Description = t.Description,
        Columns = t.Columns.Select(c => new 
        {
            Name = c.Name,
            DataType = c.DataType.ToString(),
            IsHidden = c.IsHidden
        }),
        Measures = t.Measures.Select(m => new
        {
            Name = m.Name,
            Expression = m.Expression,
            Description = m.Description
        }),
        Relationships = t.GetRelationships().Select(r => new
        {
            FromTable = r.FromTable.Name,
            FromColumn = r.FromColumn.Name,
            ToTable = r.ToTable.Name,
            ToColumn = r.ToColumn.Name
        })
    })
};

// Сохраняем
File.WriteAllText("model-metadata.json", 
    JsonSerializer.Serialize(modelInfo, new JsonSerializerOptions
    {
        WriteIndented = true
    }));

Теперь у вас есть JSON со всей структурой. Можно скормить его ИИ с таким промптом:

Проанализируй эту схему Power BI и ответь на вопросы:

1. Какие меры используют таблицу 'Продажи'?
2. Есть ли скрытые колонки?
3. Какие связи выглядят подозрительно (например, many-to-many без мостовой таблицы)?
4. Предложи оптимизации: какие вычисления можно перенести в Power Query?

Схема:
{вставить JSON}

ИИ проанализирует зависимости, найдет потенциальные проблемы и даже предложит оптимизации. Например: "Мера 'Сумма с НДС' вычисляет SUM([Сумма]) * 1.2 в DAX. Это можно вычислить в Power Query один раз для каждой строки."

Собираем все вместе: система автоматизации для команды

Одно дело — сделать скрипт для себя. Другое — внедрить процесс для всей команды. Вот архитектура системы, которая работает:

Ключевой момент: валидация. ИИ иногда генерирует синтаксически корректный, но логически неверный код. Нужно проверять.

Вот как выглядит простая проверка через AdomdConnection:

using Microsoft.AnalysisServices.AdomdClient;

bool ValidateDax(string daxExpression, string connectionString)
{
    try
    {
        using (var conn = new AdomdConnection(connectionString))
        {
            conn.Open();
            
            // Пытаемся выполнить простой запрос с этой мерой
            var cmd = new AdomdCommand("EVALUATE ROW(\"Test\", " + daxExpression + ")", conn);
            var reader = cmd.ExecuteReader();
            
            // Если выполнилось без ошибок - синтаксис правильный
            return true;
        }
    }
    catch (AdomdErrorResponseException ex)
    {
        Console.WriteLine($"DAX ошибка: {ex.Message}");
        return false;
    }
}

Ошибки, которые все совершают (и как их избежать)

Я видел десятки попыток автоматизировать Power BI. Вот самые частые провалы:

1. Игнорирование контекста фильтров
DAX без контекста — как машина без дороги. Она есть, но ехать некуда. Всегда передавайте ИИ информацию о том, какие фильтры могут быть применены.

2. Попытка заменить аналитика, а не помочь ему
ИИ не понимает бизнес-логику. Он не знает, что "выручка" — это сумма минус возвраты. Он знает только синтаксис. Всегда проверяйте логику сгенерированного кода.

3. Работа с устаревшей схемой
Power BI модель меняется каждый день. Если ваш скрипт использует JSON недельной давности, он сгенерирует код для несуществующих полей. Интегрируйте экспорт метаданных в CI/CD пайплайн.

4. Неучет производительности
ИИ может сгенерировать корректный DAX, который будет тормозить на миллионе строк. Например, использовать FILTER(ALL(...)) вместо CALCULATE с модификаторами. Всегда тестируйте производительность.

Что будет дальше? (Спойлер: Microsoft уже в игре)

Microsoft не стоит на месте. В Power BI Desktop уже есть Copilot, который умеет генерировать DAX по описанию. Но он работает только с облачными моделями и требует лицензии Premium.

Мой прогноз: через год-два появятся open-source альтернативы, которые можно будет развернуть локально. И они будут использовать те же подходы, что я описал выше — TOM для чтения схемы, LLM для генерации кода, AdomdConnection для валидации.

Пока этого не случилось, вы можете собрать свою систему. Это не rocket science. Нужно лишь понять, как Power BI хранит метаданные и как с ними работать.

Самая большая ошибка — ждать, когда Microsoft или кто-то еще сделает идеальный инструмент. Начните сегодня с простого скрипта, который экспортирует вашу модель в JSON. Посмотрите на нее свежим взглядом. Возможно, вы найдете связи, о которых забыли. Или меры-дубликаты.

Power BI — это не черный ящик. Это структурированные данные о ваших данных. И с ними можно работать.