Data-to-Text без LLM: как генерировать тысячи описаний прямо в SQL

Проблема: 100k описаний и LLM-счёт на $1 250

Прикинем на пальцах. У меня было ~50 000 организаций. Для каждой нужен отчёт на ~5 000 токенов вывода (markdown-таблицы, интерпретация трендов, топ-10 закупок, скоринг). Берём актуальные цены Anthropic и OpenAI.

И это только output-токены. Если ещё забивать в input сами данные по организации — добавляем ещё 1-2 тыс. input-токенов на запрос. По реальной нагрузке — даже rate limits Tier 4 у OpenAI (1M TPM) не позволят пройти 50k запросов быстрее, чем за 5-10 часов. Ну и батч-обработка через Batch API режет цену вдвое, но всё равно — это не «бесплатно за 30 секунд».

Что такое Data-to-Text (и почему это не AI-новинка)

Data-to-Text generation (D2T) — подзадача Natural Language Generation (NLG): берём структурированные данные (таблицу, JSON, граф) и на выходе получаем человеческий текст. Задаче больше 30 лет — академический интерес начался ещё в 1990-х (Reiter & Dale, «Building Natural Language Generation Systems», 2000).

Подходов исторически три:

Огромный пласт ресёрча — например RotoWire dataset (NBA-отчёты) и Wiseman et al. (2017) — посвящены попыткам обучить нейронки писать про спорт по таблице со статистикой. Спойлер: они до сих пор делают фактологические ошибки. Шаблоны — нет.

Индустриальные D2T-движки — Arria NLG, Yseop, Automated Insights — десятилетиями зарабатывают деньги на финансовых отчётах и автомате новостей. Bloomberg, Forbes, Yahoo Finance долгое время использовали Wordsmith от Automated Insights для генерации квартальных отчётов. Никаких LLM — чистые правила и шаблоны.

LLM против SQL-шаблонов: честное сравнение

Я не говорю «D2T лучше LLM везде». Я говорю — у каждого свой кейс. Вот разрез, после которого выбор очевиден.

Реальный кейс: 50 000 отчётов по госзакупкам Казахстана

Контекст: я работаю с открытыми данными Госзакупок РК — там есть API и около миллиона лотов в год. Дата-стек: ClickHouse — потому что это самая быстрая колоночная БД для агрегаций и текстовых функций. Цель: для каждой организации-заказчика сделать markdown-отчёт с разделами:

• Главные показатели (объём, лотов, контрагентов)
• Характер закупок (категории, типичные коды)
• Динамика за 2 года + сезонность
• Топ-10 закупок по сумме
• Финансовые метрики (средний чек, экономия от стартовой цены)
• Скоринг 0–100 с интерпретацией

На выходе — ~5 000 символов markdown на организацию × 50 000 организаций = ~250 МБ текста, который генерится за 30 секунд одним SQL-запросом из таблицы метрик org_scoring_base в таблицу org_scoring_raw. Дальше — индексация в Postgres + поиск, и текст просто читается из таблицы. Никаких LLM-вызовов в рантайме.

Пример 1: Форматирование чисел человекочитаемо

Самая частая микрозадача в D2T — 1234567890 превратить в 1.23 млрд ₸. В ClickHouse есть multiIf — компактнее каскада CASE WHEN.

-- ClickHouse: форматирование объёма закупок
multiIf(
    org_total_volume >= 1000000000,
        concat(toString(ROUND(org_total_volume / 1000000000.0, 2)), ' млрд ₸'),
    org_total_volume >= 1000000,
        concat(toString(ROUND(org_total_volume / 1000000.0, 1)), ' млн ₸'),
    org_total_volume >= 1000,
        concat(toString(ROUND(org_total_volume / 1000.0, 0)), 'к ₸'),
    concat(toString(toUInt64(org_total_volume)), ' ₸')
) AS volume_human

Один проход по миллиарду строк — секунды. Без AI. Без галлюцинаций.

Пример 2: Интерпретация трендов через CASE WHEN

У меня посчитана Pearson-корреляция квартальных объёмов закупок с временем — число от -1 до 1. Хочу превратить его в человеческий текст.

-- Перевод корреляции в текстовое описание тренда
CASE
    WHEN org_volume_trend > 0.7  THEN
        concat('Сильный рост (корреляция: +',
               toString(ROUND(org_volume_trend, 2)), ')')
    WHEN org_volume_trend > 0.3  THEN 'Умеренный рост'
    WHEN org_volume_trend > -0.3 THEN 'Стабильный объём'
    WHEN org_volume_trend > -0.7 THEN 'Умеренное снижение'
    ELSE
        concat('Сильное снижение (корреляция: ',
               toString(ROUND(org_volume_trend, 2)), ')')
END AS trend_label

Статистика → текст за один JOIN. Никакого «model.generate()».

Пример 3: Markdown-таблица генерится прямо в SQL

Самое красивое — markdown собирается concat из колонок. Пользователь увидит готовую таблицу без preprocessing на бэкенде.

-- Генерация markdown-таблицы прямо в строку
concat(
    '## Главные показатели\n\n',
    '| Метрика       | Значение            |\n',
    '|---------------|---------------------|\n',
    '| Объём закупок | ', volume_human,           ' |\n',
    '| Лотов         | ', toString(lots_count),    ' |\n',
    '| Контрагентов  | ', toString(suppliers),     ' |\n',
    '| Средний чек   | ', avg_check_human,         ' |\n',
    '| Скоринг       | ', toString(total_score),  '/100 |\n\n'
) AS markdown_table

В колонке БД у меня лежит готовый markdown-кусок. Никаких Jinja-шаблонов на бэкенде, никакой логики в API — отрендерил и отдал.

Пример 4: Числа → слова (месяц, день недели, регион)

Сезонность — топ-1 или топ-2 по числу закупок месяц. Для читаемости показываем словами.

-- Месяц-пик в виде слова
CASE peak_month
    WHEN 1  THEN 'Январь'   WHEN 2  THEN 'Февраль'
    WHEN 3  THEN 'Март'     WHEN 4  THEN 'Апрель'
    WHEN 5  THEN 'Май'      WHEN 6  THEN 'Июнь'
    WHEN 7  THEN 'Июль'     WHEN 8  THEN 'Август'
    WHEN 9  THEN 'Сентябрь' WHEN 10 THEN 'Октябрь'
    WHEN 11 THEN 'Ноябрь'   WHEN 12 THEN 'Декабрь'
END AS peak_month_label

Пример 5: Полный отчёт — сборка всего вместе

Финал — гигантский concat всех частей в одну колонку. Это и есть итоговое поле org_report_md в таблице org_scoring_raw.

INSERT INTO org_scoring_raw
SELECT
    org_id,
    org_name,
    concat(
        '# ', org_name, '\n\n',
        '> Скоринг: **', toString(total_score), '/100**',
        ' • ', score_grade, '\n\n',
        markdown_table,
        '## Динамика закупок\n\n',
        'Тренд за 2 года: **', trend_label, '**.\n',
        'Пик активности — **', peak_month_label, '**.\n\n',
        '## Рекомендации\n\n',
        recommendations_md
    ) AS org_report_md
FROM org_scoring_base
WHERE org_total_volume > 0;

Архитектура решения

Главная идея — текст хранится в БД как готовое поле. Никаких генераций на лету, никаких prompt-кэшей, никаких inference-серверов. Изменился шаблон — пересчитал таблицу за 30 секунд. Это в чистом виде ELT-подход (extract → load → transform), как его проповедуют dbt и современные дата-стеки.

Стоимость: реальные цифры

Считаем стоимость генерации 100 000 описаний по 5 000 output-токенов = 500M output-токенов суммарно. Цены input я опускаю для простоты — они меньше output, но добавили бы ещё 10–30% к итоговому счёту.

Даже самая дешёвая модель — GPT-4o mini — обойдётся в ~$45 за прогон. SQL D2T — 0.01 цента (это даже не доллар). Разница в ~5 000–125 000 раз. И это без учёта rate limits, retry-логики, fallback на другую модель и стоимости разработки prompt-инфры.

Когда D2T работает идеально

Любая задача с фиксированной структурой и преобладанием цифр над эмоциями. Вот реальные индустриальные кейсы — большинство этих систем работают на template-based подходе годами.

Ещё один индустриальный пример — Yseop делает финотчёты для Société Générale и Crédit Agricole с 2007 года. Все эти годы — никаких LLM. Просто очень умные rule-based движки.

Когда D2T не подойдёт (и я честно говорю)

Простое правило: если ты можешь нарисовать дерево решений для текста на одной А4 — D2T справится. Если нет — нужен LLM.

Гибридный подход: лучшее из двух миров

В реальной жизни я не выбираю «или–или». Я делаю D2T для фактологии + LLM для оживления раз в N запросов. Схема:

Альтернативно — если нужен интерактивный чат «расскажи мне про эту организацию подробнее», я не гоню весь отчёт в контекст. Делаю RAG по pgvector / Qdrant — с эмбеддингами по тем же D2T-сгенерированным кускам. Получается быстро и дёшево: D2T-куски как factual ground truth, LLM как переводчик в диалоговый формат.

Чеклист: когда я выбираю D2T

Если у тебя >=5 пунктов из этого списка — даже не думай, бери template-based. LLM добавишь потом точечно.

Я давно перестал подходить к таким задачам через «давайте натренируем модель» или «давайте промпт сделаем». Сначала всегда вопрос: «это можно решить SQL-ом?» — и в 9 случаях из 10 ответ да. LLM остаётся для оставшегося 1 случая, где нужна творческая работа с текстом. И это не отступление от AI-эпохи — это инженерная зрелость.