Розробка AI-системи автоматизації обробки звернень громадян

Ваше відомство отримує 10 000+ звернень на місяць — від запитів щодо ЖКГ до скарг на дії чиновників. Ручна обробка кожного займає 3–5 днів, а порушення строків за Федеральним законом № 59-ФЗ загрожує штрафами та скаргами до прокуратури. Ситуація ускладнюється зростанням кількості звернень на 20% щорічно та шаблонними запитами, що забирають 80% часу співробітників. Ми розробляємо AI-системи, які автоматизують прийом, класифікацію, маршрутизацію та підготовку відповідей, скорочуючи час обробки в 5–10 разів. Наш досвід — понад 10 років в AI та 50+ впроваджень у держсекторі. Отримайте аналіз вашого потоку за 2 дні — зв'яжіться з нами.

AI-система автоматизації обробки звернень громадян: як це працює

Ключові модулі системи

Прийом та інтеграція з держресурсами

Система інтегрується з ЄСІА, СМЕВ, email, порталом. Нормалізує дані в єдиний формат. Через ЄСІА отримує верифіковані дані заявника (ПІБ, СНІЛС, адреса). СМЕВ дозволяє автоматично направляти міжвідомчі запити — наприклад, відомості з Росреєстру для звернень щодо земельних ділянок. Також доступна інтеграція з ДІС ЖКГ та ЄПГУ (Держпослуги) для публікації статусів.

Класифікація та вилучення даних

from pydantic import BaseModel
from enum import Enum

class RequestCategory(str, Enum):
    HOUSING = "житлові питання"
    UTILITIES = "ЖКГ"
    LAND = "земельні відносини"
    SOCIAL = "соціальний захист"
    TRANSPORT = "транспорт і дороги"
    ECOLOGY = "екологія"
    PERMISSIONS = "дозволи та ліцензії"
    COMPLAINT = "скарга на дії посадових осіб"
    OTHER = "інше"

class CitizenRequest(BaseModel):
    applicant_name: str
    applicant_contact: str
    request_text: str
    attachments: list[str]

class ProcessedRequest(BaseModel):
    category: RequestCategory
    subcategory: str
    subject_summary: str          # короткий виклад в 1-2 реченнях
    responsible_department: str
    priority: str                 # routine / urgent / special_control
    deadline_days: int            # розрахунковий строк відповіді за 59-ФЗ
    requires_interdepartmental: bool  # чи потрібен міжвідомчий запит
    extracted_addresses: list[str]    # адреси з тексту звернення
    extracted_organizations: list[str]
    is_repeat: bool               # повторне звернення
    related_request_ids: list[str]

def process_citizen_request(request: CitizenRequest, db) -> ProcessedRequest:
    # Пошук схожих попередніх звернень
    similar = db.semantic_search(request.request_text, top_k=5)

    context = build_context(similar)
    return llm.parse(
        build_classification_prompt(request, context),
        response_format=ProcessedRequest
    )

Розрахунок строків за 59-ФЗ

Згідно з 59-ФЗ, базовий строк розгляду звернення — 30 днів, з можливістю продовження на 30 днів при міжвідомчому запиті. Розрахунок не тривіальний: є винятки — звернення у сфері ЖКГ можуть вимагати відповіді за 10 днів згідно з регіональними актами, термінові звернення — 15 днів. Міжвідомчий запит продовжує строк на 30 днів з повідомленням заявника.

def calculate_deadline(
    request: ProcessedRequest,
    received_date: date,
    holiday_calendar: HolidayCalendar
) -> DeadlineInfo:

    base_days = 30  # базовий строк за 59-ФЗ ст. 12

    if request.priority == "urgent":
        base_days = 15
    elif request.category == RequestCategory.UTILITIES:
        base_days = 10  # регіональні вимоги

    if request.requires_interdepartmental:
        base_days += 30  # ст. 10 ч. 2 59-ФЗ

    # Робочі дні з урахуванням виробничого календаря
    deadline = holiday_calendar.add_working_days(received_date, base_days)

    return DeadlineInfo(
        deadline=deadline,
        warning_date=holiday_calendar.add_working_days(received_date, base_days - 5),
        escalation_date=holiday_calendar.add_working_days(received_date, base_days - 2)
    )

Генерація проектів відповідей

Для типових звернень (80–90% вхідного потоку) система генерує проект відповіді автоматично. Відповідь містить посилання на НПА та конкретні роз'яснення, а не загальні фрази. Порівняйте: ручна підготовка займає 2–4 години, AI-генерація — 10–15 хвилин з точністю до 95%.

def generate_draft_response(
    request: ProcessedRequest,
    original_text: str,
    knowledge_base: KnowledgeBase
) -> DraftResponse:

    # Пошук релевантних НПА, постанов, регламентів
    relevant_docs = knowledge_base.search(
        query=original_text,
        doc_types=["law", "regulation", "instruction", "precedent"],
        top_k=10
    )

    # Генерація відповіді з посиланнями
    prompt = f"""Підготуй офіційну відповідь на звернення громадянина.

Звернення: {original_text}
Тематика: {request.category}

Релевантні НПА:
{format_documents(relevant_docs)}

Вимоги:
- Офіційний діловий стиль
- Конкретні посилання на статті нормативних актів
- Опис порядку дій для заявника
- Без загальних фраз і відписок"""

    draft = llm.generate(prompt, max_tokens=800)

    return DraftResponse(
        text=draft,
        referenced_documents=[d.id for d in relevant_docs[:5]],
        confidence=estimate_confidence(request, relevant_docs),
        requires_human_review=request.priority == "urgent" or request.category == RequestCategory.COMPLAINT
    )

Чому HDBSCAN використовується для кластеризації?

Виявлення системних проблем потребує стійкого до шуму алгоритму. HDBSCAN не вимагає вказівки кількості кластерів і виділяє викиди, що критично для реальних даних. Приклад:

def detect_systemic_issues(
    requests: list[ProcessedRequest],
    period_days: int = 30
) -> list[SystemicIssue]:

    # Кластеризація за тематикою та адресами
    clusterer = HDBSCANClusterer(min_cluster_size=10)
    clusters = clusterer.fit(requests)

    issues = []
    for cluster in clusters:
        if cluster.growth_rate > 2.0:  # зростання кількості звернень у 2+ рази
            issues.append(SystemicIssue(
                category=cluster.dominant_category,
                location=cluster.most_common_address,
                request_count=len(cluster.requests),
                sample_texts=cluster.get_samples(n=3),
                trend="growing",
                recommended_action=generate_action_recommendation(cluster)
            ))

    return sorted(issues, key=lambda x: x.request_count, reverse=True)

Порівняння ручної та AI-обробки

AI-класифікація точніша за ручну на 15–25 процентних пунктів, а швидкість генерації відповідей вища в 12–16 разів. Отримайте детальний розрахунок для вашого відомства.

Як AI скорочує час обробки звернень в 5–10 разів?

Завдяки автоматичній класифікації та генерації відповідей для 80–90% типових запитів. Співробітники займаються тільки складними та нестандартними зверненнями. Система автоматично відстежує строки та ескалює прострочення.

Що входить у пілотне впровадження?

Що входить у результат роботи

• Документація: технічна документація, інструкції для операторів, керівництво адміністратора.
• Доступи: до API системи, дашбордів, логів.
• Навчання: тренінг для 10–15 співробітників, матеріали для самопідготовки.
• Підтримка: 3 місяці гарантійного супроводу, SLA по інцидентах.
• Вихідний код: модулі класифікації та генерації відповідей (опціонально).

Наш досвід та гарантії

Ми працюємо з AI-рішеннями більше 10 років, впровадили 50+ систем у держсекторі. Ключові проекти:

• Автоматизація обробки звернень для регіонального міністерства (скорочення часу на 70%, економія бюджетних коштів).
• Система контролю строків для федерального відомства (зниження штрафів на 95%).

Гарантуємо: відповідність 59-ФЗ, сертифіковану безпеку, поетапне впровадження без зупинки поточної роботи. Замовте консультацію — проаналізуємо ваш потік за 2 дні безкоштовно.

NLP розробка: чому accuracy не підходить для рідкісних класів?

До нас приходить задача: обробляти 50 тисяч звернень до служби підтримки — зараз все вручну. Датасет — 3000 розмічених прикладів, 12 категорій, дисбаланс: одна категорія займає 40% вибірки, три по 1‑2%. Baseline accuracy — 78%. Звучить непогано, поки не дивишся на recall по рідкісних класах: 0.31, 0.44, 0.28. Саме ці класи — скарги та загрози відтоку — найважливіші для бізнесу.

Це типовий проект NLP розробки. Проблема не в алгоритмі, а в тому, що accuracy — не та метрика. Наш досвід показує: у понад 30 проектах ми починаємо з аналізу бізнес‑метрик і лише потім обираємо модель.

Чому accuracy — не та метрика для рідкісних класів?

Accuracy ігнорує дисбаланс. Якщо клас «відтік» зустрічається у 2% випадків, модель може передбачати «все добре» і отримати 98% accuracy — але бізнес втрачає клієнтів. Рішення: F1 macro (усереднення за всіма класами) або weighted F1. Для NER — strict entity F1 (лише точні збіги). Гарантуємо: після вибору правильної метрики якість моделі стає вимірною та прогнозованою.

Класифікація тексту: від BERT до дистиляції

BERT-подібні моделі — стандарт для класифікації. ruBERT-base або ruBERT-large від DeepPavlov для російської мови. multilingual‑e5‑large — якщо потрібно працювати з кількома мовами в одному пайплайні. XLM‑RoBERTa‑large — сильний multilingual backbone.

Fine‑tuning для класифікації: додаємо classification head поверх [CLS]‑токена, навчаємо 3‑5 епох з lr=2e‑5, weight decay=0.01. При дисбалансі — weighted CrossEntropyLoss або focal loss з gamma=2.0. Пишіть — покажемо code snippet.

Кейс з дисбалансом. Датасет — 3000 прикладів, дисбаланс 1:20. Рішення: class_weight через sklearn + CrossEntropyLoss. Додатково — augmentation редкісних класів через backtranslation (ru→en→ru через MarianMT). Recall по рідкісних класах виріс з 0.31 до 0.67 при незначному падінні accuracy (76%→74%). Повна NLP розробка під ключ зайняла 3 тижні.

Дистиляція для production. BERT‑large дає F1 0.89, але inference на CPU — 180ms. Дистиляція в DistilBERT або ruBERT‑tiny2 знижує latency до 25ms при F1 0.84. DistilBERT працює в 7 разів швидше за BERT‑large при падінні F1 лише на 5%. Експорт в ONNX Runtime з int8 quantization дає додатковий 1.5‑2x. Оцінимо проект — розрахуємо економію на інфраструктурі.

Як вибрати модель класифікації під ваш датасет?

Для малих датасетів (до 5000 прикладів) достатньо fine‑tuned DistilBERT. Якщо потрібна багатомовність — XLM‑RoBERTa. При жорстких обмеженнях latency — дистильована модель з ONNX Runtime. Ми допомагаємо обрати оптимальний трейдофф якість/швидкість/вартість інфраструктури.

NER: розпізнавання іменованих сутностей

NER — вилучення персон, організацій, локацій, дат, сум, номерів документів. Для загальних категорій (PER, ORG, LOC) переднавчені моделі працюють добре. Для спеціалізованих (медичні терміни, юридичні поняття) — потрібен fine‑tuning.

Розмітка даних. Основна вартість NER‑проекту. Для якісної моделі — 500‑2000 розмічених речень на кожен тип сутності. Інструменти: Label Studio (open source) або Prodigy (від творців spaCy). Формат IOB2 — стандарт.

Архітектура. Token classification поверх BERT: кожному токену мітка (B‑PER, I‑PER, O). spaCy 3.x з transformer pipeline — зручний production‑вибір.

Вкладені сутності. Стандартні IOB‑моделі не обробляють вкладені сутності (організація всередині адреси). Для таких задач — span‑based NER: SpanBERT або SpERT. Складніше, але правильно.

Постобробка обов’язкова. Модель передбачає токени — потрібні нормалізовані сутності. Дата — dateparser. Суми — regex + валідація. Імена — дедуплікація через rapidfuzz. Входить у нашу стандартну поставку.

Sentiment Analysis та opinion mining

Бінарна класифікація positive/negative працює з BERT з коробки. Складність — аспектна тональність (ABSA): «у ресторані хороша кухня, але жахливий сервіс». Для ABSA: aspect extraction (NER) + sentiment за кожним аспектом. Joint моделі BERT‑for‑ABSA — якість на російських даних нижча через дефіцит датасетів. RuSentiment, SentiRuEval — основні ресурси.

Для продакшену з простим позитив/негатив/нейтраль: distil‑моделі достатньо. Три класи, balanced датасет, 2000+ прикладів — F1 macro 0.82‑0.87 за 1‑2 дні.

Сумарізація тексту

Екстрактивна сумарізація (обираємо речення) — TextRank або BM25 без навчання. Швидко, не галюцинує. Добре для довгих документів.

Абстрактивна (генерує новий текст) — seq2seq: mT5, mBART, FRED‑T5, ruT5‑large. Для production через LLM API (GPT‑4, Claude) — часто найкращий трейдофф вартість/якість/швидкість. Звертайте увагу на context window моделі: для документів > 4k токенів використовуйте chunking.

Ембеддинги: векторні представлення тексту

Ембеддинги — основа семантичного пошуку, дедуплікації, кластеризації, RAG. Якість критично впливає на downstream задачі.

Моделі. E5‑large‑v2, BGE‑M3, multilingual‑e5‑large — сильні multilingua embedders. sentence‑transformers/paraphrase‑multilingual‑mpnet‑base‑v2 — швидкий варіант. Для російської: ru‑en‑RoSBERTa (Skoltech) хороший на semantic textual similarity.

Як оцінити якість ембеддингів? MTEB benchmark — стандарт. Але топові результати на MTEB не гарантують успіх на доменному датасеті — будуємо домен‑специфічний eval.

Fine‑tuning ембеддингів. Якщо стандартні моделі не дають потрібного Recall@k — contrastive learning на доменних парах з MultipleNegativesRankingLoss. 500‑2000 пар, 1‑3 епохи — 5‑15% приріст Recall@k.

Розмірність та зберігання. E5‑large: 1024 dim, float32 — 4KB на вектор. При 10M документів — 40GB. INT8 quantization знижує до 10GB. FAISS IVF_PQ — ще компактніше, але з втратами. Входить у наші рекомендації по деплою.

Вилучення інформації

Структуроване вилучення — одна з частих задач. Приклади: ключові умови договору, технічні характеристики, дати та суми з рахунків.

1. Regex + rule-based. Для ІПН, ЄДРПОУ, сум, дат — надійніше нейромережі. Не потребує даних.
2. NER + постобробка. Для варіативних форматів.
3. LLM з structured output. GPT‑4 / Claude з JSON schema — для складних документів. Вартість: залежить від обсягу документів. Для 10k+ документів/день — рахуємо економіку.

Гарантуємо гібрид: regex/NER для типових полів + LLM для edge cases. Сертифікат довіри: 5 років на ринку, >30 проектів.

Етапи роботи

Прототип на існуючих даних — 1‑3 тижні. Production‑система з CI/CD — 1.5‑2.5 місяця. Вартість розраховується індивідуально — зв'яжіться з нами для консультації та оцінки.

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

• Документація з архітектури моделі та пайплайну
• Доступи до моделі через REST API (FastAPI + ONNX)
• Навчання команди замовника (2 години вебінару + Q&A)
• Гарантія на точність моделі на обумовленій тестовій вибірці
• Підтримка 3 місяці після здачі (багфікс, адаптація під нові дані)

Наш досвід

Понад 5 років у NLP, 30+ проектів від класифікації до RAG‑систем. Команда включає ML‑інженерів з досвідом у Hugging Face, spaCy, LangChain, MLOps. Використовуємо vLLM, Kubeflow, Weights & Biases — продакшен‑стек, а не іграшки. Замовте консультацію — оцінимо проект за 2 дні.