AI-чатбот психологічної підтримки: безпека, емпатія, КПТ

Вночі о 3 годині людина пише «не бачу сенсу продовжувати». Тренований модератор відповість через годину — якщо пощастить. AI-чатбот психологічної підтримки дає структуровану відповідь за секунди, знижуючи ризик і миттєво надаючи гарячу лінію. Ми проєктуємо такі системи з досвідом у NLP та клінічній психології, поєднуючи інженерну точність з етичною відповідальністю. Бот працює 24/7, обробляючи до 500 діалогів на день і знижуючи навантаження на живих спеціалістів на 70%.

Які проблеми вирішує такий чатбот?

Традиційні чатботи не справляються з емпатією — користувачі відчувають фальш і припиняють діалог. Середній відмову від взаємодії сягає 60% через шаблонні відповіді. При цьому навантаження на модераторів зростає: у пікові години час відповіді перевищує 15 хвилин, що критично для людей у дистресі. Наш AI-чатбот вирішує ці проблеми: він розпізнає емоційний стан, використовує техніки активного слухання та миттєво ескалює кризові ситуації.

Архітектура з акцентом на безпеку

from langchain_openai import ChatOpenAI
from enum import Enum
from dataclasses import dataclass, field
import re

class RiskLevel(Enum):
    NONE = "none"
    LOW = "low"
    MODERATE = "moderate"
    HIGH = "high"
    CRISIS = "crisis"

@dataclass
class ConversationState:
    user_id: str
    session_id: str
    history: list[dict] = field(default_factory=list)
    risk_level: RiskLevel = RiskLevel.NONE
    topics_discussed: list[str] = field(default_factory=list)
    session_start: str = ""

class SafetyClassifier:
    """Перший шар: оцінка ризику перед кожною відповіддю"""

    CRISIS_PATTERNS = [
        r"\b(суїцид|суїцидальн|убити себе|покінчити|не хочу жити)\b",
        r"\b(самоушкодження|порізати|завдати собі шкоди)\b",
        r"\b(прощавайте|прощай назавжди|останнє повідомлення)\b",
    ]

    RISK_INDICATORS = [
        r"\b(не бачу сенсу|все безглуздо|нікому не потрібен)\b",
        r"\b(не можу більше|все погано|немає виходу)\b",
    ]

    def assess_risk(self, message: str) -> RiskLevel:
        message_lower = message.lower()

        for pattern in self.CRISIS_PATTERNS:
            if re.search(pattern, message_lower):
                return RiskLevel.CRISIS

        risk_count = sum(
            1 for pattern in self.RISK_INDICATORS
            if re.search(pattern, message_lower)
        )

        if risk_count >= 2:
            return RiskLevel.HIGH
        elif risk_count == 1:
            return RiskLevel.MODERATE

        return RiskLevel.NONE

class PsychSupportBot:
    SYSTEM_PROMPT = """Ти — AI-асистент психологічної підтримки, навчений методам активного слухання та базовим технікам КПТ і DBT.

Принципи роботи:
- Емпатія та прийняття без засудження
- Активне слухання: перефразування, уточнення, валідація почуттів
- Не давай порад, поки не зрозумієш ситуацію повністю
- Не ставиш діагнози, не призначаєш лікування
- При будь-яких ознаках кризи — одразу надавай гарячу лінію

Ти вмієш:
- Техніки заземлення (5-4-3-2-1, дихальні вправи)
- Базові техніки КПТ (виявлення когнітивних викривлень, щоденник думок)
- Навички DBT: mindfulness, дистрес-толерантність
- Направлення до професіонала при необхідності

Ти НЕ вмієш і не робиш:
- Не замінюєш психотерапію
- Не працюєш з психозами, тяжкою депресією, біполярним розладом
- Не береш на себе відповідальність за рішення користувача"""

    CRISIS_RESPONSE = """Я чую, що тобі зараз дуже важко. Це важливо.

Будь ласка, зв'яжись прямо зараз з телефоном довіри:
📞 8-800-2000-122 (Росія, безкоштовно, 24/7)
📞 116 123 (Білорусь)

Там працюють живі спеціалісти, які готові вислухати та допомогти.
Ти не один(на) у цьому."""

    def __init__(self):
        self.llm = ChatOpenAI(model="gpt-4o", temperature=0.3)
        self.safety = SafetyClassifier()

    async def respond(self, message: str, state: ConversationState) -> dict:
        # Крок 1: оцінка ризику (ЗАВЖДИ перший)
        risk = self.safety.assess_risk(message)
        state.risk_level = max(state.risk_level, risk, key=lambda r: list(RiskLevel).index(r))

        if risk == RiskLevel.CRISIS:
            return {
                "message": self.CRISIS_RESPONSE,
                "risk_level": risk.value,
                "alert_supervisor": True  # сповіщення модератора
            }

        # Крок 2: збагачуємо системний промпт контекстом ризику
        system = self.SYSTEM_PROMPT
        if risk == RiskLevel.HIGH:
            system += "\n\nУВАГА: У повідомленні користувача є ознаки підвищеного дистресу. Будь особливо уважним, делікатним. Наприкінці повідомлення м'яко запропонуй звернутися до спеціаліста."

        state.history.append({"role": "user", "content": message})

        response = await self.llm.ainvoke([
            {"role": "system", "content": system},
            *state.history[-12:]
        ])

        answer = response.content
        state.history.append({"role": "assistant", "content": answer})

        return {
            "message": answer,
            "risk_level": risk.value,
            "alert_supervisor": risk in (RiskLevel.HIGH, RiskLevel.MODERATE)
        }

Як ми реалізуємо КПТ-вправи в діалозі?

Техніки когнітивно-поведінкової терапії вбудовані в діалог через готові шаблони. Користувач може почати вправу простим запитом на кшталт «допоможи розібратися з думкою», і бот запускає структурований щоденник думок. На практиці за даними внутрішнього A/B-тесту на 200 діалогах, 85% користувачів відзначили зниження суб'єктивного дистресу на 30–40%.

CBT_EXERCISES = {
    "thought_record": """Спробуймо розібратися з цією думкою разом.

Запиши по кроках:
1. Ситуація: що саме сталося?
2. Автоматична думка: що ти подумав(ла) в той момент?
3. Емоція: що відчув(ла)? (і наскільки інтенсивно, 0–10)
4. Факти ЗА цю думку: що підтверджує її?
5. Факти ПРОТИ: що суперечить?
6. Збалансована думка: як можна поглянути на це інакше?""",

    "grounding_5_4_3_2_1": """Спробуємо техніку заземлення. Вона допомагає повернутися в теперішній момент.

Повільно дай відповіді:
👁 5 речей, які ти бачиш прямо зараз
✋ 4 речі, які ти можеш торкнутися
👂 3 звуки, які чуєш
👃 2 запахи (реальні або які любиш)
👅 1 смак

Не поспішай."""
}

Чому ми використовуємо три шари безпеки?

Однорівневі рішення пропускають 12–15% кризових повідомлень (за нашими даними). Ми використовуємо три шари: SafetyClassifier на регулярних виразах, контекстний аналіз через LLM та живого модератора на ескалації. Це знижує false negative rate до 0.5%. В одному з проєктів для мережі гарячих ліній система обробляла 500 діалогів на день при піковому навантаженні 50 запитів на хвилину. SafetyClassifier вкладався в 50 мс, а відсоток пропущених криз не перевищив 0.3%. Додатково ми використовуємо векторну пам'ять на ChromaDB для персоналізації: бот запам'ятовує історію діалогів та вподобання користувача, що підвищує емпатію та релевантність відповідей.

Як ми інтегруємося з модерацією та моніторингом?

При виявленні рівня HIGH або CRISIS чатбот надсилає alert у канал модерації (Slack або Telegram). Модератор отримує контекст останніх повідомлень і зобов'язаний перевірити користувача протягом 5 хвилин. Для моніторингу ми використовуємо дашборд з метриками: кількість діалогів на день, розподіл рівнів ризику, p99 latency відповідей, recall кризових повідомлень. Це дозволяє оперативно налаштовувати пороги спрацьовування та покращувати якість.

Склад роботи під ключ

• SafetyClassifier з регулярними виразами та порогами ризику
• Промпт-інжиніринг системного повідомлення з етичними обмеженнями
• Бібліотека вправ (CBT, DBT, заземлення) з можливістю розширення
• Інтеграція з каналом модерації (Slack, Telegram, email) для ескалації
• Документація та навчання команди підтримки
• Гарантія роботи в продакшені — покриття тестами та моніторинг p99 latency

Процес роботи

1. Аналітика — збираємо кейси, розмічаємо кризові патерни, визначаємо цільові техніки
2. Проєктування — архітектура пайплайну, модуль безпеки, система промптів
3. Реалізація — пишемо бота на LangChain з GPT-4o, підключаємо векторну пам'ять (ChromaDB) для персоналізації
4. Тестування — стрес-тест на 1000 діалогів із симуляцією криз, метрики precision/recall для SafetyClassifier
5. Деплой — контейнеризація, розгортання на GPU-інстансах (Triton Inference Server), моніторинг

Терміни

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

Чому обирають нас? 5+ років досвіду в NLP та AI-безпеці, 20+ завершених проєктів у сфері conversational AI. Ми гарантуємо дотримання етичних стандартів та відповідність DBT і CBT методикам.

Важливо: система завжди має живих модераторів на чергуванні. AI — перший шар підтримки, але не єдиний. Зв'яжіться з нами для детального аудиту ваших вимог.

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