Как автоматизировать отчёты через ИИ на сервере

MAATRIX

Еженедельный отчёт по продажам, сводка по тикетам поддержки, ежемесячный дайджест метрик — руками на это уходит вечер: выгрузить цифры, вставить в ChatGPT, поправить формулировки, разослать. Этот процесс можно собрать в автоматический pipeline на своём сервере: n8n запускает workflow по расписанию, забирает данные из базы, отдаёт их модели и рассылает готовый текст — без браузерной вкладки и без человека, который должен не забыть. Разберём схему автоматизации отчётов через ИИ от триггера до доставки: конкретные ноды, промпт, который не разваливается на третьей неделе, и грабли первой.

Почему ChatGPT в браузере и Zapier с Make не решают задачу

Первый инстинкт — открыть ChatGPT или Claude и вставить туда выгрузку вручную. Работает один раз, а не как процесс: кто-то должен вспомнить об этом в понедельник, выгрузить цифры, вставить их в чат, дождаться ответа, скопировать текст и разослать. Человек в отпуске — отчёта нет. И в чат, даже платный, улетают реальные цифры выручки и имена клиентов: для отчёта, который уйдёт клиенту или инвестору, это почти никогда не приемлемо.

No-code конструкторы вроде Zapier и Make снимают часть ручной работы, но добавляют свои ограничения: тарифицируются по числу задач в месяц, оплата — только иностранной картой, данные идут через чужую инфраструктуру. Источник нестандартный — своя Postgres-база, внутренний API CRM — и это либо premium-коннектор за деньги, либо недоступно на нижних тарифах.

Self-hosted n8n на своём сервере закрывает оба вопроса разом: лицензия fair-code бесплатна, потолок — не число задач в месяц, а ресурсы вашего сервера:

Из чего состоит рабочий pipeline автоотчёта

Workflow в n8n — граф нод, каждая делает один шаг и передаёт результат дальше. Для автоотчёта граф почти всегда один и тот же:

• Триггер — Schedule Trigger, cron-выражение и таймзона.
• Извлечение данных — Postgres/MySQL, HTTP Request к внутреннему API, Google Sheets для ручных таблиц.
• Агрегация — нода Code: суммы и дельты к прошлому периоду, до того как данные увидит модель.
• Генерация текста — HTTP Request к API модели или готовая нода Basic LLM Chain.
• Форматирование — Set/Code: HTML-письмо или карточка для мессенджера из ответа модели.
• Доставка — Send Email, Telegram, Slack.
• Журнал — вставка в Postgres: что именно и когда ушло, для последующей сверки.

Для отчёта агентный узел AI Agent избыточен: он сам решает, что вызвать и сколько раз, — удобно для чат-бота, но непредсказуемо для процесса с фиксированным расписанием. Нужен пайплайн с заранее известным числом шагов: простой HTTP Request к API модели или Basic LLM Chain — один вызов без цикла решений.

Сам workflow — это JSON: Ctrl+A, Ctrl+C в редакторе копирует граф текстом, Download сохраняет файл. Так рабочие процессы держат в git рядом с остальной инфраструктурой и накатывают на новый сервер импортом, а не пересборкой руками.

Пошагово: собираем workflow «еженедельный отчёт по продажам»

Возьмём конкретный пример: каждый понедельник в 8:00 отчёт о продажах за неделю уходит в Telegram-канал команды.

1. Триггер. Нода Schedule Trigger, поле Cron Expression:

0 8 * * 1

Таймзона берётся из GENERIC_TIMEZONE (например, Europe/London); без неё n8n считает по UTC, и «8:00» окажется не тем часом.

2. Данные. Нода Postgres с отдельным read-only пользователем — отчётам незачем право на UPDATE/DELETE:

create role reports_ro login password '...';
grant select on orders to reports_ro;

Сам запрос — текущая и прошлая неделя одним обращением, через filter (where ...):

select
  sum(amount) filter (where created_at >= now() - interval '7 days') as revenue_cur,
  count(*) filter (where created_at >= now() - interval '7 days') as orders_cur,
  sum(amount) filter (where created_at >= now() - interval '14 days'
                       and created_at < now() - interval '7 days') as revenue_prev
from orders
where created_at >= now() - interval '14 days';

3. Агрегация. Нода Code считает дельту и собирает объект, который увидит модель, — готовые числа, без сырых строк:

const row = $input.first().json;
const delta = ((row.revenue_cur - row.revenue_prev) / row.revenue_prev * 100).toFixed(1);
return [{ json: { orders: row.orders_cur, revenue: row.revenue_cur, revenue_delta_pct: Number(delta) } }];

4. Модель. Нода HTTP Request на https://api.anthropic.com/v1/messages, заголовки x-api-key, anthropic-version: 2023-06-01, content-type: application/json. Промпт прямо запрещает модели считать самой — только описывать переданные цифры (подробнее — ниже).

5. Разбор ответа. Ещё один Code: снять обёртку в код-блок, если она есть, распарсить JSON, при ошибке — упасть с понятным текстом, а не молча разослать пустоту.

6. Доставка. Нода Telegram, поле chatId — числовой id канала от @userinfobot (не username), Bot Token — из @BotFather. Для email — Send Email, SMTP-хост, порт 587, STARTTLS.

7. Журнал. Postgres, insert в report_log(sent_at, channel, payload) — на «а мне не приходило» будет что проверить.

Собирая граф, запускайте его кнопкой Execute workflow — прогон идёт немедленно, не дожидаясь понедельника. Не тот пароль на шаге 2 — увидите сразу и честно: password authentication failed for user "reports_ro".

Промпт и парсинг: как получить стабильный текст, а не эссе

Главная ошибка в промпте для отчёта — просить модель «посчитай и опиши». Даже сильные модели время от времени домысливают округления и путают проценты, когда сами вычисляют их из массива чисел. Правило простое: суммы, дельты и проценты считает Code-нода до модели, ей достаётся только формулировка. Системный промпт стоит писать примерно так:

Ты — аналитик, который оформляет еженедельный отчёт по продажам.
Тебе дан JSON с готовыми числами: orders, revenue, revenue_delta_pct.
Не пересчитывай и не оценивай числа — используй ровно те, что даны.
Ответ — только валидный JSON без пояснений и без разметки кода:
{"summary": "...", "highlight": "..."}

Даже с прямым запретом модель иногда оборачивает ответ в блок кода — строку из тройных обратных кавычек с меткой json перед JSON и такую же после. Отправить это в JSON.parse напрямую — получить `SyntaxError: Unexpected token in JSON at position 0``, читаемую ошибку, но её проще предотвратить, чем каждый раз ловить:

const raw = $input.first().json.message.content.trim();
const cleaned = raw.replace(/^`{3}json\s*/i, '').replace(/`{3}\s*$/, '');
let report;
try {
  report = JSON.parse(cleaned);
} catch (e) {
  throw new Error(`Модель вернула невалидный JSON: ${e.message}`);
}
return [{ json: report }];

Бросить ошибку здесь осознанно: Code-нода без try/catch уронит весь workflow невнятным стеком, а понятное сообщение видно в истории executions и уходит в Error Workflow (раздел ниже).

Ещё два параметра стоит зафиксировать явно: temperature в районе 0.2–0.3 — отчёту нужна предсказуемость, а не разнообразие, и max_tokens с запасом, но не «в бесконечность» (например, 800) — так модель реже уходит в рассуждения вместо сухого summary, а расход токенов предсказуем.

Локальная модель или облачный API: что выбрать для отчётов

Тот же HTTP Request можно направить не в облако, а на http://127.0.0.1:11434/api/chat — локальный Ollama на этом же сервере. Разница не только в адресе.

Данные при локальной модели не покидают сервер — для отчёта с выручкой и именами клиентов это снимает вопрос «куда уходят цифры» сам по себе. Стоимость запроса не зависит от числа отчётов: не токены по счётчику провайдера, а место на диске под веса и электричество. Честно про обратную сторону: локальная модель среднего размера заметно слабее держит формат, чем GPT-4o или Claude, и промпт из раздела выше потребует больше итераций, чтобы модель не съезжала на пересказ своими словами.

Мы прогнали qwen2.5:7b в кванте Q4_K_M на Ollama 0.33.1 на тестовом сервере с AMD EPYC 9554 (16 vCPU = 8 физических ядер с HT), меняя число потоков:

Вывод пригождается напрямую: генерация выходит на полку уже на 4 потоках — дальше упирается не в CPU, а в память, — а num_thread, выставленный в 32 (по числу всех логических ядер), не ускоряет, а даёт провал в двадцать раз: планировщик начинает конкурировать сам с собой за физические ядра. На том же стенде при 16 потоках: llama3.1:8b — 12,8 ток/с, mistral:7b — 12,1, gemma2:9b — 8,8, qwen2.5:3b — 34,1. Веса в памяти: qwen2.5:3b — 2,2 ГБ, mistral:7b — 5,0 ГБ, qwen2.5:7b — 5,1 ГБ, llama3.1:8b — 5,6 ГБ. Практический вывод: начинайте с num_thread 4–8, а не «побольше — быстрее», и считайте память отдельно от Postgres и n8n — 7B в Q4 занимает около 5 ГБ весами, поверх нужен запас под контекст.

Разумный компромисс — гибрид: черновики и отчёты с чувствительными цифрами уходят через локальную qwen2.5:7b, версии для внешних получателей — через облачный API. Оба пути живут в одном workflow как два HTTP Request с переключением по параметру.

Надёжность: что проверить, прежде чем доверить отчёт расписанию

Молчаливый сбой — главный риск именно для отчётов. Интерактивный сценарий падает на глазах у пользователя, а workflow по расписанию — в пустоту: о сбое вы узнаете от получателя, который спросит, где дайджест. В настройках workflow есть поле Error Workflow — отдельный граф с Error Trigger, срабатывающий при падении основного и уходящий сообщением в служебный чат. Настраивается один раз для всех workflow сразу — для отчётов это не опция, а обязательный шаг.

Журнал отправленного — тот самый report_log из раздела со сборкой workflow: без него любой спор «а мне не приходило» превращается в гадание.

Плюс batch-сценария, которого нет у интерактивных. Раз триггер — расписание, а не браузерная сессия, можно не возиться с proxy_read_timeout и SSE ради долгих ответов модели — это боль чат-ботов и AI-агентов, которых кто-то ждёт вживую. Отчёт может генерироваться и три минуты — снаружи никто не смотрит на спиннер.

Если запускаете отчёт вручную, кнопкой «сформировать сейчас» через Webhook-ноду — включите на ней Header Auth или Basic Auth: без этого либо честный отказ {"code":403,"message":"Authorization data is wrong!"} при ошибке в заголовке, либо, хуже, открытый вебхук, сжигающий бюджет на токены чужими руками.

Три классические боли self-hosted n8n — блокировка SQLite при параллельных запусках, потеря ключа шифрования credentials и открытый порт 5678 — для отчётов не специфичны, но обходить их молчанием нечестно: рано или поздно они найдут ваш инстанс. Точные тексты ошибок и команды — в статье про частые ошибки n8n.

Какой сервер под n8n и ИИ-отчёты брать в MAATRIX

n8n для этой схемы — лёгкий линейный workflow: раз в день или в неделю дёргает Postgres, передаёт компактный JSON модели и отправляет текст. Вес добавляет не пайплайн отчёта, а то, что рядом.

Минимум: 1 vCPU, 2 ГБ RAM, 20–30 ГБ NVMe. Хватает на несколько workflow в день на SQLite и обращения к облачному API без локальной модели. Если план — растить число сценариев, общая методика расчёта памяти — в отдельном разборе, сколько RAM нужно для n8n.

Комфортный вариант: 4 vCPU, 8 ГБ RAM, 60–80 ГБ NVMe. Держит n8n, Postgres под данные отчётов и, если не хотите гонять чувствительные цифры через внешний API, — локальную qwen2.5:7b в Q4 через Ollama: около 5,1 ГБ весов (раздел выше), поверх — контекст. Развернуть Ollama с нуля — по отдельной инструкции для локального запуска LLM.

Локация — Великобритания, Лондон. Важна не только скорость доступа к API моделей — она в Лондоне ровная, без региональных отказов, которые ловит российский IP, — но и то, куда физически летит письмо с отчётом: лондонский адрес не удивляет партнёра в Европе так, как российский, и не попадает под те же блок-листы, что IP из RU-подсетей. Общая логика выбора локации — в сравнении локаций для доступа к ИИ.

Оплата — картой российского банка, СБП, криптой или токеном MAAT. n8n — в каталоге apps.maatrix.io: разворачивается автоматически при заказе, работает на Ubuntu и Debian, логин и пароль от панели приходят в личный кабинет сразу после установки — ставить руками не нужно, остаётся собрать workflow и подключить credentials. Заказать сервер можно здесь.

Частые вопросы