Розробка автономної AI-системи листування з клієнтами

Як побудувати автономну AI-систему діалогів із клієнтами

Клієнти скаржаться на довге очікування відповіді, а FAQ-боти втрачають контекст уже на другому повідомленні. Традиційні рішення не можуть виконати дію — перенаправити платіж або змінити замовлення. Ми розробляємо автономні AI-системи, які ведуть повноцінний діалог, приймають рішення та здійснюють транзакції. Наша система керує повним циклом: ініціює комунікацію за тригерами, підтримує багатоходові розмови, адаптує тон під клієнта, виконує дії всередині діалогу та коректно передає розмову оператору при необхідності. Це не FAQ-бот — це інтелектуальний асистент, що розуміє наміри та зберігає історію. В основі лежить Large language model, яка обробляє природну мову та генерує відповіді.

Як автономна AI-система вирішує проблеми клієнтської переписки?

Втрата контексту. Клієнт повідомляє номер замовлення, потім уточнює дату, потім змінює адресу — звичайний бот не пов'язує ці повідомлення. Наша система зберігає історію в графі станів і будує профіль із CRM, замовлень та лояльності. Неможливість виконати дію зникає: ми надаємо системі доступ до API та виконуємо дії всередині діалогу з підтвердженням від клієнта. Неадаптивна тональність більше не проблема — динамічно підбираємо тон залежно від статусу (standard, premium, VIP). Високе навантаження на контакт-центр знижується: автономна система бере на себе 70% діалогів, залишаючи складні випадки людям.

Як ми будуємо діалогову систему: стек та конфігурації

Використовуємо перевірений стек: LangGraph для управління станами, OpenAI GPT-4o для генерації, PostgreSQL з pgvector для зберігання контексту та asyncio для паралельного завантаження профілю. Ключовий елемент — граф станів, де кожен вузол відповідає за частину діалогу. Ось покрокова інструкція.

Крок 1: Стан діалогу

from langgraph.graph import StateGraph, END
from langgraph.checkpoint.postgres import PostgresSaver
from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage, AIMessage, SystemMessage
from typing import TypedDict, Annotated, Optional
import operator

class ConversationState(TypedDict):
    session_id: str
    customer_id: str
    channel: str              # "whatsapp", "telegram", "web_chat", "sms"
    messages: Annotated[list, operator.add]
    customer_profile: Optional[dict]
    customer_tier: str        # "standard", "premium", "vip"
    preferred_language: str   # "ru", "en"
    current_intent: Optional[str]
    dialog_context: dict
    pending_confirmations: list[dict]
    completed_actions: Annotated[list, operator.add]
    escalated: bool
    escalation_reason: Optional[str]
    escalation_priority: Optional[str]

Крок 2: Контекстний менеджер клієнта

class CustomerContextManager:
    """Завантажує та оновлює профіль клієнта"""

    async def load_context(self, customer_id: str) -> dict:
        profile_task = crm.get_customer(customer_id)
        orders_task = orders_db.get_recent(customer_id, limit=10)
        preferences_task = preference_store.get(customer_id)
        loyalty_task = loyalty_service.get_status(customer_id)

        results = await asyncio.gather(
            profile_task, orders_task, preferences_task, loyalty_task,
            return_exceptions=True,
        )

        return {
            "profile": results[0] if not isinstance(results[0], Exception) else {},
            "recent_orders": results[1] if not isinstance(results[1], Exception) else [],
            "preferences": results[2] if not isinstance(results[2], Exception) else {},
            "loyalty": results[3] if not isinstance(results[3], Exception) else {},
        }

    def build_system_context(self, customer_context: dict) -> str:
        profile = customer_context.get("profile", {})
        loyalty = customer_context.get("loyalty", {})
        context_parts = [
            f"Клієнт: {profile.get('name', 'клієнт')}",
            f"Статус: {loyalty.get('tier', 'standard')}",
            f"Мова: {profile.get('preferred_language', 'ru')}",
        ]
        orders = customer_context.get("recent_orders", [])
        if orders:
            last_order = orders[0]
            context_parts.append(
                f"Останнє замовлення: #{last_order['id']} від {last_order['date']}, статус: {last_order['status']}"
            )
        return "\n".join(context_parts)

Крок 3: Виявлення намірів та динамічний промпт

from pydantic import BaseModel
from typing import Literal

class IntentDetection(BaseModel):
    intent: Literal[
        "order_status", "order_change", "order_cancel",
        "delivery_issue", "return_request", "payment_issue",
        "product_question", "complaint", "compliment",
        "account_management", "general_question", "farewell",
    ]
    confidence: float
    entities: dict
    requires_action: bool
    needs_clarification: bool

SYSTEM_PROMPT_TEMPLATE = """Ти — AI-асистент клієнтської служби компанії "{company_name}".

Інформація про клієнта:
{customer_context}

Правила спілкування:
- Звертайся до клієнта по імені
- Тон: {tone} (залежить від статусу клієнта)
- Мова: {language}
- Ніколи не обіцяй те, що не можеш виконати
- При помилках — визнавай і пропонуй рішення
- Не розкривай внутрішні системи і бази даних

Доступні дії:
- Статус замовлення
- Зміна адреси доставки (якщо замовлення не передане кур'єру)
- Ініціювання повернення
- Перенесення дати доставки
- Передача оператору

Якщо не знаєш відповіді — чесно скажи про це і запропонуй передати спеціалісту."""

def build_system_prompt(state: ConversationState) -> str:
    tone_map = {
        "standard": "професійний, дружній",
        "premium": "персональний, уважний",
        "vip": "ексклюзивний, максимально персоналізований",
    }
    return SYSTEM_PROMPT_TEMPLATE.format(
        company_name="RetailCo",
        customer_context=state.get("customer_profile", {}).get("context", ""),
        tone=tone_map.get(state["customer_tier"], "професійний"),
        language=state["preferred_language"],
    )

Крок 4: Виконання дій та управління підтвердженнями

async def execute_dialog_action(action_name: str, params: dict, state: ConversationState) -> dict:
    """Виконує дію та повертає результат для включення в діалог"""
    action_handlers = {
        "get_order_status": lambda p: orders_api.get_status(p["order_id"]),
        "change_delivery_address": lambda p: orders_api.update_address(p["order_id"], p["new_address"]),
        "initiate_return": lambda p: returns_service.create_request(order_id=p["order_id"], reason=p["reason"], customer_id=state["customer_id"]),
        "reschedule_delivery": lambda p: delivery_api.reschedule(p["order_id"], p["new_date"]),
    }
    handler = action_handlers.get(action_name)
    if not handler:
        return {"success": False, "error": f"Невідома дія: {action_name}"}
    try:
        result = await handler(params)
        return {"success": True, "data": result}
    except Exception as e:
        return {"success": False, "error": str(e)}

def needs_confirmation(action_name: str) -> bool:
    """Дії, що вимагають підтвердження клієнта"""
    return action_name in {"cancel_order", "initiate_return", "change_payment_method"}

async def handle_pending_confirmation(state: ConversationState) -> ConversationState:
    """Обробляє відповідь клієнта на запит підтвердження"""
    if not state["pending_confirmations"]:
        return state
    last_message = state["messages"][-1].content.lower()
    confirmation_words = {"так", "yes", "підтверджую", "згоден", "ок", "ok"}
    rejection_words = {"ні", "no", "скасувати", "відмовляюсь", "стоп"}
    if any(word in last_message for word in confirmation_words):
        pending = state["pending_confirmations"][0]
        result = await execute_dialog_action(pending["action"], pending["params"], state)
        return {
            **state,
            "pending_confirmations": state["pending_confirmations"][1:],
            "completed_actions": [{"action": pending["action"], "result": result}],
        }
    elif any(word in last_message for word in rejection_words):
        return {
            **state,
            "pending_confirmations": [],
            "messages": [AIMessage("Добре, дія скасована. Чим ще можу допомогти?")],
        }
    return {
        **state,
        "messages": [AIMessage("Будь ласка, дайте відповідь 'так' для підтвердження або 'ні' для скасування.")],
    }

Крок 5: Тригерна комунікація

class OutboundCommunicationEngine:
    """Ініціює вихідну комунікацію за бізнес-тригерами"""

    TRIGGER_TEMPLATES = {
        "order_shipped": {
            "message": "Ваше замовлення #{order_id} відправлено! Трекінг: {tracking_url}. Очікувана доставка: {eta}.",
            "channel_priority": ["sms", "whatsapp", "email"],
        },
        "delivery_delay": {
            "message": "Повідомляємо про затримку доставки замовлення #{order_id}. Нова дата: {new_eta}. Вибачте за незручності.",
            "channel_priority": ["whatsapp", "telegram", "sms"],
        },
        "return_approved": {
            "message": "Ваше повернення за замовленням #{order_id} схвалено. Кошти повернуться протягом {refund_days} днів.",
            "channel_priority": ["email", "whatsapp"],
        },
    }

    async def send_trigger_message(self, customer_id: str, trigger: str, params: dict):
        template_config = self.TRIGGER_TEMPLATES.get(trigger)
        if not template_config:
            return
        customer = await crm.get_customer(customer_id)
        base_message = template_config["message"].format(**params)
        if customer.get("tier") in ("premium", "vip"):
            personalized = await personalize_message(base_message, customer)
        else:
            personalized = base_message
        channel = await self.get_preferred_channel(customer_id, template_config["channel_priority"])
        await channel_dispatcher.send(customer_id, channel, personalized)

Яких результатів дає впровадження автономної AI-системи?

З нашої практики: впровадили систему для регіонального телекому з 850 000 абонентів та 120 операторами. Реалізували сценарії перевірки балансу, підключення послуг, розблокування номера, діагностики та обробки скарг. Результати: автономне закриття 67% діалогів, середній час відповіді знизився з 4,5 хвилин до 8 секунд, CSAT виріс з 3,8 до 4,2. Оператори зосередилися на складних випадках, NPS збільшився на 7 пунктів. Складність: налаштування тональності для angry customers зайняло 4 тижні, VIP-клієнти отримали опцію негайної передачі людині. Система окупається в середньому за 6 місяців за рахунок скорочення штату операторів.

Що входить у роботу

1. Аудит поточних сценаріїв та точок інтеграції
2. Проектування архітектури діалогового двигуна
3. Реалізація базових сценаріїв (5–10 штук)
4. Інтеграція з каналами зв'язку та CRM/ERP
5. Налаштування моделей LLM та векторизація контенту
6. Навчання системи на історії діалогів
7. Тестування та запуск у продакшн
8. Документація та навчання вашої команди
9. Підтримка на етапі стабілізації

Вартість розраховується індивідуально. Оцінимо ваш проєкт за 1–2 дні. Замовте розробку під ключ — гарантуємо якість та сертифікованих інженерів з досвідом роботи з LLM.

Порівняння автономної AI-системи та FAQ-бота

Автономна система на базі LLM вирішує завдання, які не під силу простому боту. Вона розуміє наміри, запам'ятовує контекст та виконує дії. Порівняйте самі:

Наші системи протестовані на пікових навантаженнях до 18 000 діалогів на день. Сертифіковані рішення, повна документація та гарантія результату. Зв'яжіться з нами для консультації — оцінимо ваш проєкт і запропонуємо оптимальне рішення.

Практичний розбір 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 або гібрид — розповімо, що підійде саме вам.