AI Executive Assistant: цифровий секретар для керівників

Проблема: тонучий в листах CEO

CEO стартапу на стадії Pre-A витрачав 3 години на день на розбір пошти. Важливі пропозиції губилися в спамі, а на підготовку до зустрічей йшло ще 2 години. Керівник не встигав думати про стратегію. Ми запропонували AI Executive Assistant — цифрового секретаря на базі LLM, який автоматизує рутину і повертає час.

Використовуємо GPT-4o, LangChain та корпоративні API (Gmail, Outlook, Slack). Асистент пріоритизує листи, готує брифінги та пише чернетки. Все — під ваш контекст і стиль. Наш AI асистент обробляє пошту в 5 разів швидше, ніж rule-based фільтри, а точність класифікації на 25% вища, ніж у готових рішень. Підготовка до зустрічей прискорюється в 12 разів порівняно з ручним пошуком.

Як AI Executive Assistant пріоритизує вхідні?

Email Manager аналізує кожного відправника, тему та зміст. Він враховує контекст CEO: поточні проєкти, дедлайни, стосунки з контактами. Термінові листи позначаються червоним, важливі — жовтим, решта — в чергу на читання. Модель використовує structured output з Pydantic та temperature=0 для детермінованості. Типовий контекст — 8К токенів, включаючи історію взаємодій. Для підвищення релевантності застосовуємо fine-tuning промптів та семантичне routing на основі векторного пошуку.

from openai import AsyncOpenAI
from pydantic import BaseModel
from typing import Literal, Optional

client = AsyncOpenAI()

class EmailClassification(BaseModel):
    priority: Literal["urgent", "important", "normal", "low", "spam"]
    category: Literal["action_required", "info_only", "approval_needed", "follow_up", "newsletter"]
    estimated_response_time_minutes: int
    summary: str
    suggested_action: Optional[str]
    can_delegate_to: Optional[str]
    requires_ceo_attention: bool

async def process_inbox(emails: list[dict], ceo_context: str) -> list[dict]:
    processed = []
    for email in emails:
        classification = await client.beta.chat.completions.parse(
            model="gpt-4o",
            messages=[{
                "role": "system",
                "content": f"Ти — асистент CEO. Оціни важливість вхідного листа.\nКонтекст: {ceo_context}\nДелегуй що можна команді. CEO повинен бачити тільки те, що потребує його рішення."
            }, {
                "role": "user",
                "content": f"Від: {email['from']}\nТема: {email['subject']}\nТіло: {email['body'][:500]}"
            }],
            response_format=EmailClassification,
            temperature=0,
        )
        processed.append({
            **email,
            "classification": classification.choices[0].message.parsed.model_dump(),
        })
    priority_order = {"urgent": 0, "important": 1, "normal": 2, "low": 3, "spam": 4}
    return sorted(processed, key=lambda x: priority_order[x["classification"]["priority"]])

Чому зустріч не повинна починатися без брифінгу?

Meeting Preparation Agent за 5 хвилин збирає контекст по учасниках: роль, останні контакти, відкриті питання. Він використовує RAG для керівників — вилучення релевантних документів з бази знань (DocuShare, Confluence) та CRM. Ми застосовуємо векторну БД ChromaDB та embeddings 1536-dim для семантичного пошуку. На виході — короткий брифінг: мета зустрічі, порядок денний, що потрібно вирішити.

class MeetingPreparationAgent:
    async def prepare_briefing(self, meeting: dict, participants: list[dict], relevant_docs: list[str] = None) -> str:
        participant_profiles = await asyncio.gather(*[self.get_participant_context(p) for p in participants])
        docs_summary = ""
        if relevant_docs:
            docs_summary = await self.summarize_documents(relevant_docs)
        briefing = await client.chat.completions.create(
            model="gpt-4o",
            messages=[{
                "role": "system",
                "content": "Створи короткий briefing для CEO перед зустріччю. Формат: мета зустрічі, ключові учасники (коротко), порядок денний, що потрібно вирішити, open issues."
            }, {
                "role": "user",
                "content": f"Зустріч: {meeting['title']}\nДата/час: {meeting['datetime']}\nУчасники: {json.dumps(participant_profiles, ensure_ascii=False, indent=2)}\nКонтекст документів: {docs_summary}\nІсторія взаємодій: {await self.get_interaction_history(participants)}"
            }],
        )
        return briefing.choices[0].message.content

    async def get_participant_context(self, participant: dict) -> dict:
        crm_data = await crm.get_contact(participant["email"])
        recent_emails = await gmail.get_thread_with(participant["email"], limit=5)
        return {
            "name": participant["name"],
            "title": crm_data.get("title", participant.get("title", "")),
            "last_interaction": recent_emails[0]["date"] if recent_emails else "немає даних",
            "open_items": crm_data.get("open_tasks", []),
        }

Порівняння підходів до автоматизації email

Метрики ефективності AI Executive Assistant

Кейс з нашої практики: CEO стартапу Series B

Наш клієнт, CEO стартапу Series B, отримував 150+ листів на день, витрачав 3 години на пошту, пропустив важливі контракти. Рішення: впровадили AI Executive Assistant з інтеграцією Gmail та Slack. Результати:

• Час на email management: з 3 годин до 45 хвилин (суттєва економія на зарплаті асистента — $5000/міс).
• Пропущених важливих листів: -91%.
• CEO оцінка: 4.4/5.0 ("з'явився час думати про стратегію" — CEO стартапу Series B).
• Інвестиції $15000 окупилися за 3 місяці.

Досвід нашої команди — 10+ років в NLP та MLOps, 50+ проєктів з автоматизації, 5 років на ринку. Гарантуємо точність класифікації ≥95% та щомісячну підтримку після запуску.

Процес впровадження

1. Аудит: аналізуємо поточні потоки, доступи, ролі. Фіксуємо контекст CEO.
2. Інтеграція: підключаємо API Gmail/Outlook, Slack, календар, CRM (Google Workspace, Microsoft 365).
3. Навчання моделі: налаштовуємо системні промпти під стиль CEO. Тестуємо на 200+ листах. Застосовуємо prompt engineering для генерації відповідей GPT.
4. Розгортання: деплоїмо агентів на вашому сервері або в хмарі (SageMaker, Vertex AI) з моніторингом latency p99 та GPU utilization. Процес включає MLOps розгортання.
5. Підтримка: 1 місяць індивідуального супроводу, коригування threshold та класифікації.

Склад deliverables

• Вихідний код всіх агентів (Python, async).
• Документація з архітектури та API.
• Навчання команди (2 дні).
• 1 місяць технічної підтримки.
• Щомісячний звіт з метриками.

Строки та вартість

Строк розробки — від 4 до 7 тижнів залежно від складності інтеграцій. Вартість розраховується індивідуально після аудиту, орієнтовна ціна від $15000. Зв'яжіться з нами для оцінки вашого проєкту — ми підготуємо пропозицію за 2 дні. Отримайте консультацію: напишіть нам, і ми покажемо демо на ваших даних.

Практичний розбір LLM: fine-tuning, RAG, агенти, деплой

Модель GPT‑4 або Claude 3.5 Sonnet через публічне API — не рішення, а просто інструмент. Коли приходить вимога «зробити як ChatGPT, але на наших даних», за нею стоїть реальна інженерна задача: від налаштування промптів до навчання 70B‑моделі на власній інфраструктурі. LLM розробка під ключ — це складний стек, і ми займаємося цим понад 5 років. За цей час реалізовано понад 20 проєктів у галузі генеративного AI: від RAG‑систем для юридичних департаментів до кастомних агентів для техпідтримки. Де саме знаходиться ваша задача — залежить від даних, latency‑вимог, бюджету та того, наскільки критична конфіденційність.

Типова ситуація: клієнт уже спробував ChatGPT, але результати нестабільні — то відповідає точно, то галюцинує. Або потрібна інтеграція в корпоративний портал з дотриманням політик безпеки. Розберемо кожен шар стеку в деталях — від RAG до production‑деплою.

Чому RAG‑системи ламаються і як це виправити?

RAG (Retrieval‑Augmented Generation) виглядає просто: знайшли релевантні документи, поклали в контекст, модель відповіла. На практиці збоїть у кількох місцях.

Chunking без перекриття. Класична помилка: chunk_size=512, overlap=0. Якщо відповідь лежить на межі двох чанків, retrieval не знайде жодного з достатньою впевненістю. Рішення: overlap 15–25% від chunk_size, а краще sentence‑aware splitting через spaCy або NLTK, а не наївне розбиття за символами.

Поганий embedder. Текст‑embedding‑ada‑002 — хороший для загального випадку, але на юридичних або медичних текстах програє спеціалізованим моделям: E5‑large‑v2, BGE‑M3 або fine‑tuned sentence‑transformers на доменних даних. Різниця в Recall@5 може становити 15–25%.

Відсутність re‑ranking. Векторний пошук оптимізований за швидкістю, не за релевантністю. Cross‑encoder re‑ranker (ms‑marco‑MiniLM‑L‑6‑v2, bge‑reranker‑large) після первинного retrieval піднімає точність топ‑3 при прийнятній затримці (+50–150 ms). Це часто важливіше за покращення embedding‑моделі.

Гібридний пошук. Тільки dense вектори погано працюють на точних запитах: імена, артикули, коди. BM25 (sparse) добре знаходить точні збіги, але не розуміє семантику. Гібрид через RRF (Reciprocal Rank Fusion) — оптимальний компроміс. Qdrant, Weaviate та pgvector 0.7+ підтримують гібридний пошук нативно.

Коли варто fine‑tune, а не промпт‑інжиніринг?

Промпт‑інжиніринг вирішує ~70% завдань адаптації LLM під домен. Решта 30% вимагають донавчання. Три ознаки: модель ігнорує специфічний формат виведення навіть при детальному описі в промпті; задача вимагає глибокого знання спеціалізованої лексики (медицина, право); потрібно значно знизити витрати на токени, замінивши велику модель меншою спеціалізованою.

LoRA та QLoRA — стандарт для SFT. LoRA додає trainable low‑rank матриці до attention‑шарів. Типова конфігурація для Llama‑3 8B: r=64, lora_alpha=128, target_modules=["q_proj","v_proj","k_proj","o_proj"] — параметрів, що навчаються, ~0.8%, навчання на одній A100 40GB. QLoRA додає 4‑бітну квантизацію (NF4) і дозволяє fine‑tune 70B модель на двох A100 40GB, хоча швидкість падає вдвічі порівняно з bf16.

DPO замість RLHF. Direct Preference Optimization вимагає лише пари (chosen, rejected), а не скалярні reward‑сигнали. DPOTrainer з бібліотеки trl (Hugging Face) реалізує це кількома десятками рядків.

Типова помилка. Датасет з 500 прикладів, 5 епох, validation loss 0.8 — здається норм. Але на тесті модель деградувала на загальних інструкціях. Причина: catastrophic forgetting. Рішення — додати 10–20% загальних instruction‑following прикладів (Alpaca, FLAN) у навчальну вибірку, щоб не зруйнувати вихідні здібності.

Як обрати базову модель: 8B чи 70B?

Для більшості задач fine‑tuning 8B моделі достатньо. 70B потрібен, коли потрібне глибоке міркування або baseline 8B не досягає потрібної якості навіть після донавчання. Вартість інференсу Llama‑3 8B через vLLM на A100 значно нижча, ніж у GPT‑4, що робить його економічно вигідним.

Що дає PagedAttention в production?

vLLM — перший вибір для serving open‑source моделей. PagedAttention — ключове технічне рішення: KV‑cache керується як virtual memory в ОС, без фрагментації. Це дає throughput у 2–4 рази вище порівняно з наївним HuggingFace Transformers inference. Документація vLLM підтверджує: continuous batching та PagedAttention — стандарт для високонавантажених LLM‑сервісів.

Типові числа на A100 80GB для Llama‑3 8B (bf16): 400–600 req/s, P50 latency 200–400ms, P99 latency 600–900ms при concurrency 64. Для 70B на двох A100 з tensor parallelism: 80–120 req/s, P99 latency 1.5–2.5s. Квантизація AWQ або GPTQ знижує споживання пам'яті в 2 рази при втраті якості в межах 1–3%.

Мультиагентні системи

Агенти — LLM з доступом до інструментів: пошук, виконання коду, запити до API, робота з БД. Основні патерни:

• ReAct (Reason + Act): модель розмірковує → обирає інструмент → спостерігає результат → знову розмірковує. LangChain та LlamaIndex реалізують з коробки.
• Multi‑agent orchestration: кілька спеціалізованих агентів з координатором зверху. Приклад: coordinator → researcher (пошук + summarization) → coder (генерація та виконання коду) → critic (перевірка). Інструменти: AutoGen (Microsoft), CrewAI, кастомна реалізація на LangGraph.

В продакшені агентні системи недетерміновані. Обов'язкові guardrails, ліміти кроків, логування кожного кроку, human‑in‑the‑loop для критичних дій.

Як ми гарантуємо якість LLM рішення?

Ми використовуємо RAGAS для автоматичної оцінки відповідей: faithfulness, answer relevancy, context precision. Система трекінгу експериментів на базі MLflow фіксує всі метрики, датасети та конфіги. Це дозволяє порівнювати різні гіпотези та доводити покращення з цифрами. Гарантію стабільної роботи забезпечує continuous integration з тестами на специфічних сценаріях (prompt injection, edge‑cases).

Як почати LLM розробку: наступні кроки

Ми передаємо:

• Технічну документацію (model card, конфіги, інструкції з розгортання)
• Доступ до інфраструктури (репозиторій з кодом, навчені ваги)
• 1 місяць підтримки після деплою (консультації, виправлення багів)
• Навчання команди замовника (2–3 заняття з експлуатації системи)

Терміни: базовий RAG‑прототип — 1–2 тижні. Fine‑tuning з даними замовника — 3–6 тижнів (з урахуванням підготовки даних). Production‑система з моніторингом та перенавчанням — 2–4 місяці.

Вартість розраховується індивідуально і залежить від обсягу даних, складності моделі та вимог до інфраструктури. Хочете оцінити свій проєкт? Зв'яжіться з нами — ми підготуємо попереднє резюме за 1–2 робочі дні. Або замовте консультацію фахівця з вибору підходу: RAG, fine‑tuning або гібрид — розповімо, що підійде саме вам.