Metra AI — Production-SaaS для автоматизації контенту в Telegram
Побудували під ключ SaaS-платформу з мультиагентною LLM-оркестрацією. Від архітектури до запуску за 3 місяці.
01Парсер структурирозбір анатомії, збереження посилань
02Рерайтер контентупо абзацах, ізольовані виклики
03Стилізаціяемодзі та форматування каналу
04Валідатор правилправила конкретного каналу
Бізнес-задача
Власники Telegram-каналів і контент-команди витрачають величезну кількість часу на ручне створення постів. Стандартні рішення або не підходять під специфіку Telegram (Buffer, Hootsuite заточені під Instagram/Twitter), або спираються на сирий вивід ChatGPT, який видає шаблонний контент низької якості, що потребує тривалого ручного правлення.
Головний біль: контент-команди витрачають 60–80% часу на продакшен замість стратегії, а якість страждає, бо згенерованому ШІ контенту зазвичай бракує голосу бренду, контексту каналу та актуальності в реальному часі.
Що ми побудували
Повноцінну SaaS-платформу, що автоматизує весь процес роботи з контентом у Telegram:
- Генерація постів на ШІ зі збереженням голосу бренду та лору каналу
- Система планування з багаторазовими тижневими пресетами
- Інтеграція даних у реальному часі для новинного контенту
- Вбудована Telegram-CRM для роботи з лідами без розкриття даних акаунта власника
- Мультиакаунтна інфраструктура з кількома операторами для агенцій із безліччю каналів
Архітектура: чому мультиагентність, а не один виклик LLM
Ключова технічна інновація — багатоступеневий пайплайн LLM-оркестрації замість одиничних викликів API. Це усвідомлений архітектурний вибір, заснований на важливому інсайті:
LLM погано працюють, коли їм дають забагато одночасних обмежень. Один промпт на 3000 токенів із запитом «перепиши пост у голосі X, з лором Y, у форматі Z, за правилами A/B/C» дає нестабільний результат, бо увага розмивається між вимогами.
Рішення: розкласти генерацію поста на спеціалізовані етапи, у кожного — одна чітка зона відповідальності.
Стандартний пайплайн постингу
- Парсер структури — видобуває анатомію поста і зберігає посилання (які преміум-LLM за замовчуванням вирізають)
- Рерайтер контенту — обробляє кожен абзац ізольованими викликами, зберігаючи структурну цілісність
- Стилізація — додає емодзі та форматування під персону каналу
- Валідатор правил — застосовує правила конкретного каналу (наприклад, прибрати пунктуацію, обмежити довжину)
Розширений пайплайн (генерація з нуля)
- Селектор архетипу — обирає структуру поста за типом контенту та параметрами довжини
- Поблоковий генератор — пише кожну секцію з фокусним контекстом
- Застосування стилю та форматування
- Валідація за авто-правилами
Така архітектура усуває типові збої ШІ — галюцинації посеред тексту, розповзання структури, надмірне застосування лору, поломку формату — які дають одиничні виклики LLM.
Ключові технічні знахідки
1. Шар нормалізації промптів
Модель зображень надто часто відхиляла легітимні промпти — хибні спрацювання на звичайних запитах на кшталт генерації людей. Замість переходу на дорожчу модель ми побудували шар нормалізації промптів, який переформульовує безневинний ввід користувача так, щоб він не блокувався помилково, зберігаючи вихідний сенс. Це дало змогу тримати якість високою без хостингу дорожчих альтернатив.
2. Стиснення і переклад лору
Лор каналу від користувача (часто 3000+ токенів неструктурованого тексту) стискається і перекладається мовою постингу каналу ще під час завантаження. ШІ отримує структуроване саме на потрібній мові замість сирого лору — це різко підвищує релевантність контенту і знижує витрати на токени.
3. Лор як контекст, а не обмеження
У ході ітерацій виявили, що ШІ надмірно застосовує лор, якщо давати його як пряму інструкцію. Спроєктували лор як м'який контекст, який впливає, але не домінує над генерацією — контент виходить природніше.
4. Стратегія вибору преміум-LLM
Обирали конкретні LLM під конкретні задачі:
- Менше хибних відмов на легітимних межових випадках
- Краща інтеграція новин у реальному часі через API в дусі Perplexity
- Оптимізація витрат на масштабі
Інфраструктура
- Кілька серверів Ubuntu у продакшені (основний сервіс, CRM, стейджинг)
- 16 Docker-контейнерів із грамотним розділенням відповідальності
- Бекенд як єдине джерело істини — усі запити клієнта йдуть через бекенд, ніколи напряму до ШІ-провайдерів або БД
- Стек моніторингу: Prometheus, Grafana, Sentry для помилок, Uptime Kuma для здоров'я сервісів
- Шифрування: усі чутливі дані (номери телефонів, повідомлення, паролі) зашифровані з коректним salt+pepper і GPU-стійким хешуванням. Ключі розшифрування зберігаються поза сервером.
- Безпека: 2FA, ротація JWT, фінгерпринтинг сесій, проксування доменів
Результат
3 міс
Від розробки до запуску
16
Docker-контейнерів у продакшені
1-й тиждень
Перші платні користувачі
25/день
Авто-постів на канал на платному тарифі
Запустили в продакшен у межах 3-місячного вікна розробки. Мультиакаунтна CRM дає змогу агенціям керувати операторами без розкриття даних власника каналу. Активна рання тяга зі зростаючою базою користувачів.
Технологічний стек
| Бекенд | FastAPI · Python · Celery |
| Фронтенд | React · TypeScript · Next.js |
| База даних | PostgreSQL · Redis |
| Інфраструктура | Docker · Nginx · Multiple Ubuntu servers |
| Моніторинг | Prometheus · Grafana · Sentry · Uptime Kuma |
| ШІ / LLM | Мультипровайдерний стек (пропрієтарний + опенсорс) |
Що це демонструє
- Уміння спроєктувати і побудувати production-SaaS під ключ
- Глибоке розуміння обмежень LLM і як обійти їх архітектурою
- Безпека та інфраструктура production-рівня
- Прагматична оптимізація витрат на рівні архітектури
- Наскрізне продуктове мислення: бізнес-задача → технічне рішення → деплой → експлуатація