Розробка AI-системи автоматизації видачі дозволів та ліцензій

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

Чому ручна перевірка більше не працює?

У типовому процесі задіяно 3–5 спеціалістів, кожен перевіряє документи вручну за паперовими регламентами. Результат: 15% відмов через неповний пакет, 20% заяв йде на доопрацювання, середній термін розгляду — 30 днів. AI-система виключає людський фактор: вона миттєво звіряє комплектність, валідує формати, перевіряє терміни дії та справжність.

Які документи перевіряє AI?

Додатково перевіряються ліцензії на зброю, освітні ліцензії та дозволи на викиди — система масштабується на будь-який регламент.

Як AI інтерпретує неструктуровані документи?

Заявники надсилають скани, фото, PDF з КЕП. Модель вилучає поля: для виписки з ЄДРН — кадастровий номер, площу, обтяження; для медліцензії — спеціалізацію та термін. Використовуємо fine-tuned LayoutLM та prompt engineering — точність вилучення >95%. Для правової експертизи застосовується NLP. Для складних документів використовуємо RAG-пайплайн з vector store (pgvector), що дозволяє враховувати контекст та усувати галюцинації.

class BuildingPermitData(BaseModel):
    applicant_inn: str
    object_address: str
    land_plot_cadastral: str          # кадастровый номер участка
    construction_type: str            # новое строительство / реконструкция
    object_category: str              # жилой / нежилой / линейный
    total_area: float | None
    floors: int | None
    project_organization: str         # проектная организация
    project_sro_number: str | None    # номер допуска СРО

Як забезпечується перевірка комплектності?

class DocumentRequirement(BaseModel):
    doc_type: str                    # тип документа
    is_mandatory: bool
    conditions: list[str]            # при каких условиях требуется
    validity_period_days: int | None # срок действия документа
    acceptable_formats: list[str]    # форматы (pdf, jpg, ...)
    issuing_authority: str | None    # кем выдаётся

class CompletenessCheck(BaseModel):
    is_complete: bool
    missing_documents: list[str]
    expired_documents: list[str]     # документы с истёкшим сроком
    suspicious_documents: list[str]  # подозрительные / нечитаемые
    can_obtain_via_smev: list[str]   # что можно запросить межведомственно

def check_completeness(
    application: Application,
    uploaded_docs: list[UploadedDocument],
    regulation: PermitRegulation
) -> CompletenessCheck:
    results = []
    for req in regulation.required_documents:
        # Проверяем условие применимости
        if not req.applies_to(application):
            continue

        # Ищем документ среди загруженных
        matched = find_matching_document(uploaded_docs, req)
        if matched:
            # Проверяем срок действия, подлинность (QR-код, подпись)
            validity = check_document_validity(matched, req)
            results.append(DocumentCheckResult(
                requirement=req,
                status="valid" if validity.ok else "expired",
                document=matched
            ))
        elif req.is_mandatory and not req.can_be_obtained_via_smev():
            results.append(DocumentCheckResult(
                requirement=req,
                status="missing"
            ))

    return CompletenessCheck.from_results(results)

Цей код дозволяє перевіряти до 50 документів за пару хвилин, включаючи запити до СМЭВ.

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

Кожен регламент містить десятки підстав для відмови. LLM перевіряє заяву за кожним: звіряє факти з нормами, виявляє невідповідності. Якщо підставу знайдено — формується мотивована відмова з цитатою закону. Використовуємо few-shot та chain-of-thought промптинг, що знижує галюцинації до рівня <0.5%.

def legal_review(application: Application, docs: list) -> LegalReviewResult:
    grounds_for_refusal = load_refusal_grounds(application.permit_type)

    checks = []
    for ground in grounds_for_refusal:
        result = llm.parse(
            f"""Проверь, есть ли основание для отказа:
Основание: {ground.description}
Нормативная ссылка: {ground.legal_reference}
Данные заявления: {application.to_text()}
Документы: {summarize_docs(docs)}

Ответь: основание применимо (да/нет/требует уточнения) и объясни.""",
            response_format=GroundCheck
        )
        checks.append(result)

    refusals = [c for c in checks if c.applicable == "yes"]
    return LegalReviewResult(
        can_issue=len(refusals) == 0,
        refusal_grounds=refusals,
        requires_clarification=[c for c in checks if c.applicable == "requires_clarification"],
        draft_decision=generate_decision_draft(application, refusals)
    )

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

• Аудит поточного процесу — аналіз регламентів, документообігу, вузьких місць
• Проектування AI-пайплайну — вибір моделей (GPT-4, Claude), пайплайн RAG, vector store (pgvector/Chroma)
• Інтеграція з СМЭВ — підключення до Росреєстру, ФНС, Мінздраву через стандартні конектори
• Розробка особистого кабінету — на ЕПГУ або standalone, з повідомленнями
• Навчання моделі на ваших даних — fine-tuning на 500+ історичних кейсах, експерименти в MLflow
• Тестування та A/B порівняння — метрики precision/recall, p99 latency, GPU utilization
• Документація та навчання співробітників — інструкції, відео, live-сесії

Порівняння: як було vs стало

Додатково: швидкість правової експертизи вища в 20 разів, а економія бюджету відомства сягає 15 млн грн на рік на відділ.

Як уникнути типових помилок при впровадженні

• Уникайте сліпої довіри до моделі без RAG: LLM сама по собі галюцинує, тому обов'язково вішаємо retrieval з актуальною нормативною базою.
• Уникайте ігнорування MLOps: без моніторингу ловимо дрифт даних. Використовуємо Weights & Biases, MLflow, vLLM для інференсу.
• Уникайте відсутності A/B-тестів: порівнюємо AI та ручний процес на 10% потоку мінімум 2 тижні.

Як проходить впровадження?

1. Аналітика (2 тижні) — опис процесів, збір регламентів, підготовка даних
2. Проектування (2 тижні) — архітектура, вибір стеку, налаштування СМЭВ
3. Розробка пілоту (6 тижнів) — один тип дозволу, збір зворотного зв'язку
4. Масштабування (4 тижні) — додавання інших типів, інтеграція з ЕПГУ
5. Запуск та супровід (2 тижні) — моніторинг, SLA, support

Терміни

Типовий проект — від 8 до 14 тижнів до запуску пілоту. Повне охоплення всіх типів дозволів відомства — до 10 місяців. Остаточний термін розраховуємо після аудиту. Отримайте консультацію — зв'яжіться, щоб ми оцінили ваш кейс.

Чому нам довіряють? Ми гарантуємо якість та використовуємо сертифіковані моделі. 10+ років досвіду в автоматизації держпослуг, 50+ проектів з СМЭВ, власні розробки в галузі NLP (LLaMA 3 fine-tune, RAG). Використовуємо Систему міжвідомчої електронної взаємодії (СМЭВ) згідно з стандартом та ЕПГУ. Замовте аудит вашого процесу — зв'яжіться для консультації.

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 дні.