AI-інтеграція в СЕД: автоматизація вхідних документів

Вхідні документи — вузьке горло будь-якої організації

Скан договору надходить на пошту → оператор відкриває → вручну вбиває реквізити в 1С → обирає тип → запускає погодження. На один документ у середньому 8 хвилин. При 500 документах на місяць це 67 годин чисто механічної роботи. Наша AI-інтеграція скорочує це до 45 секунд на документ — у 10 разів швидше за оператора, причому 89% обробляються без участі людини. Проблема посилюється різноманіттям форматів: PDF, скани, DOCX, email-вкладення. Кожен потребує попередньої обробки, а помилки ручного введення призводять до збоїв у погодженні. Ми будуємо AI-шар, який розуміє вміст будь-якого документа, вилучає ключові реквізити, класифікує та автоматично запускає workflow у вашій СЕД. Використовуємо трансформерні архітектури (BERT, RoBERTa) для класифікації та sequence labeling для NER. Жодних шаблонів — лише навчені моделі під ваш документообіг. Досвід нашої команди — понад 20 успішних впроваджень, 5+ років у NLP та MLOps. Компанія на ринку з 2019 року, сертифіковані партнери Directum та 1С. Впровадження від $5000, окупність за 6 місяців.

Як AI обробляє документи швидше за оператора?

AI обробляє вхідний документ у 10–15 разів швидше за людину: 45 секунд проти 8 хвилин. При цьому точність вилучення реквізитів досягає 94% (проти 85% при ручному введенні). Система працює цілодобово, не потребує перерв і не допускає помилок через втому.

Інвестиції в AI-інтеграцію окупаються в середньому за 6 місяців.

Чому дообучення BERT критичне для точності?

Базова модель класифікації документів (cointegrated/rubert-tiny2) дає точність близько 80% на типових документах. Однак кожна компанія використовує унікальні шаблони договорів, рахунків та актів. Дообучення BERT на вашому корпусі (від 500 розмічених екземплярів) підвищує точність до 94% і вище. Ми використовуємо Hugging Face Transformers для дообучення та інференсу. Нижче приклад реалізації класифікатора.

from transformers import pipeline, AutoTokenizer, AutoModelForSequenceClassification
import torch

class DocumentClassifier:
    DOCUMENT_TYPES = [
        "договор", "счёт-фактура", "накладная", "акт",
        "приказ", "служебная записка", "коммерческое предложение",
        "доверенность", "устав", "протокол", "письмо входящее"
    ]

    def __init__(self, model_path: str = "cointegrated/rubert-tiny2"):
        # Для production — дообученный BERT на корпусе документов компании
        self.tokenizer = AutoTokenizer.from_pretrained(model_path)
        self.model = AutoModelForSequenceClassification.from_pretrained(
            model_path,
            num_labels=len(self.DOCUMENT_TYPES)
        )
        self.model.eval()

    def classify(self, text: str) -> dict:
        # Берём первые 512 токенов (шапка документа несёт основную семантику)
        inputs = self.tokenizer(
            text[:2000],
            return_tensors="pt",
            truncation=True,
            max_length=512,
            padding=True
        )
        with torch.no_grad():
            logits = self.model(**inputs).logits

        probs = torch.softmax(logits, dim=-1)[0]
        top_idx = probs.argmax().item()

        return {
            "type": self.DOCUMENT_TYPES[top_idx],
            "confidence": float(probs[top_idx]),
            "alternatives": [
                {"type": self.DOCUMENT_TYPES[i], "score": float(probs[i])}
                for i in probs.topk(3).indices.tolist()
                if i != top_idx
            ]
        }

[Входящий документ]
PDF/scan/DOCX/email
         ↓
[Document Preprocessor]
OCR (Tesseract/Google Cloud Vision) → нормализованный текст
         ↓
[AI Processing Pipeline]
  ├── Classification: тип документа
  ├── NER: контрагент, даты, суммы, реквизиты
  ├── Summary: краткое содержание
  └── Routing: определение маршрута согласования
         ↓
[СЭД API]
Создание карточки + запуск workflow

Вилучення реквізитів: комбінація NER та LLM

Для швидкого вилучення стандартних полів (ІПН, дати, суми) використовуємо regex та NER. Для складних випадків — LLM (GPT-4o-mini або локальна LLaMA через LangChain). Комбінація дає точність 94% на реальних документах. Для нестандартних запитів застосовуємо RAG з векторними БД (ChromaDB, pgvector), що дозволяє шукати по базі раніше оброблених документів.

from langchain_openai import ChatOpenAI
import re
from datetime import datetime

class DocumentExtractor:
    EXTRACTION_PROMPT = """Извлеки реквизиты из документа.

Текст документа:
{text}

Тип документа: {doc_type}

Извлеки (верни null если не найдено):
- contractor_name: название контрагента
- contractor_inn: ИНН контрагента
- contract_number: номер договора/счёта
- contract_date: дата документа (ISO 8601)
- total_amount: сумма (число)
- currency: валюта (RUB/USD/EUR)
- payment_deadline: срок оплаты (если есть)
- subject: предмет договора (1-2 предложения)
- signatory: подписант со стороны контрагента

Верни JSON."""

    def __init__(self):
        self.llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

    def extract_requisites(self, text: str, doc_type: str) -> dict:
        # Сначала быстрое regex-извлечение
        fast_extract = self._regex_extract(text)

        # LLM для пропущенных полей и валидации
        llm_result = self.llm.invoke(
            self.EXTRACTION_PROMPT.format(
                text=text[:3000],
                doc_type=doc_type
            )
        )

        import json
        llm_data = json.loads(llm_result.content)

        # Мерджим: regex имеет приоритет для числовых полей (точнее)
        return {**llm_data, **fast_extract}

    def _regex_extract(self, text: str) -> dict:
        result = {}

        # ИНН: 10 или 12 цифр
        inn_match = re.search(r'\bИНН[:\s]*(\d{10,12})\b', text)
        if inn_match:
            result["contractor_inn"] = inn_match.group(1)

        # Суммы с валютой
        amount_match = re.search(
            r'(\d[\d\s,]*\.?\d*)\s*(руб|рублей|RUB|USD|EUR)',
            text, re.IGNORECASE
        )
        if amount_match:
            amount_str = amount_match.group(1).replace(' ', '').replace(',', '.')
            result["total_amount"] = float(amount_str)

        return result

Інтеграція з СЕД: Directum, 1С, DocsVision

Інтеграція будується через офіційні REST API. Приклад для Directum: завантажуємо файл, заповнюємо картку, запускаємо workflow. Аналогічна логіка для 1С:Документообіг та DocsVision.

class SEDIntegration:
    """Интеграция с 1С:Документооборот, Directum, DocsVision"""

    def push_to_directum(self, extracted: dict, original_file: bytes) -> dict:
        """Создаёт карточку документа в Directum"""
        import requests

        # Загружаем файл
        upload_response = requests.post(
            f"{self.directum_url}/api/v1/documents",
            headers={"Authorization": f"Bearer {self.token}"},
            files={"file": original_file}
        )
        doc_id = upload_response.json()["id"]

        # Заполняем карточку
        card_response = requests.patch(
            f"{self.directum_url}/api/v1/documents/{doc_id}/properties",
            headers={"Authorization": f"Bearer {self.token}"},
            json={
                "DocumentType": extracted["type"],
                "Counterparty": extracted.get("contractor_name"),
                "INN": extracted.get("contractor_inn"),
                "Amount": extracted.get("total_amount"),
                "DocumentDate": extracted.get("contract_date"),
                "Subject": extracted.get("subject")
            }
        )

        # Запускаем маршрут согласования
        route = self._determine_route(extracted)
        requests.post(
            f"{self.directum_url}/api/v1/documents/{doc_id}/workflow/{route}",
            headers={"Authorization": f"Bearer {self.token}"}
        )

        return {"doc_id": doc_id, "route": route}

    def _determine_route(self, extracted: dict) -> str:
        """Определяет маршрут согласования по параметрам документа"""
        amount = extracted.get("total_amount", 0)
        doc_type = extracted.get("type", "")

        if doc_type == "договор":
            if amount > 1_000_000:
                return "contract_large"      # директор + юрист + финансы
            elif amount > 100_000:
                return "contract_medium"     # руководитель + юрист
            else:
                return "contract_standard"   # только руководитель
        elif doc_type == "счёт-фактура":
            return "invoice_approval"
        return "standard"

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

Ми надаємо повний цикл впровадження:

1. Аналіз документообігу — схеми маршрутів, типи документів, обсяг.
2. Розробка моделей — дообучення класифікатора та NER.
3. Інтеграція з СЕД — REST API, налаштування workflow.
4. Тестування на реальних документах — до 1000 екземплярів.
5. Запуск та навчання операторів.

Deliverables:

• Документація з архітектури та API.
• Доступ до навчених моделей та коду.
• Навчання операторів роботі з системою.
• Технічна підтримка протягом року.

Типові помилки при AI-інтеграції в документообіг

• Ігнорування якості OCR. Якщо скани погані (роздільна здатність <150 DPI, заломи), точність падає. Рішення: попередня обробка зображень — дескьюїнг, бінаризація.
• Одна модель для всього. Класифікація та NER потребують різних архітектур. Поєднання в одній моделі знижує точність обох завдань.
• Відсутність human-in-the-loop. Документи з впевненістю <0.8 мають перевірятися оператором. Інакше помилки множаться в системі.

Результати впровадження: кейс та метрики компанії

Кейс: виробнича компанія, 500 вхідних документів на місяць. До впровадження: 2 оператори витрачали 40% робочого часу на ручне введення реквізитів. Після: точність автоматичного вилучення реквізитів 94% (перевірка на 1000 документах), 89% документів обробляються без участі оператора, оператори займаються лише винятками (confidence < 0.8) та перевіркою спірних маршрутів. Час обробки вхідного документа скоротився з 8 хвилин до 45 секунд — у 10 разів швидше. Економія часу — понад 60 годин на місяць, що еквівалентно витратам на двох операторів. Вартість впровадження стартує від $5000, і завдяки економії інвестиція окупається за 6 місяців. Ми гарантуємо точність не нижче 90% на вашому тестовому корпусі.

Ми реалізували понад 20 інтеграцій AI в СЕД для компаній з обсягом документообігу від 200 до 5000 документів на місяць. Досвід команди — 5+ років у NLP та MLOps. Ми маємо сертифікацію партнера Directum та 1С. Використовуємо лише ліцензійні рішення та офіційні API.

Зв'яжіться з нами для безкоштовної оцінки вашого проєкту. Замовте пілотну обробку 100 документів — ми покажемо точність на ваших даних.

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