Розробка AI-системи автоматизації кадрового діловодства
При ручному складанні кадрових документів помилки виникають у 5–10% випадків: невірні паспортні дані, пропущені підписи, порушення строків. Кожен такий дефект загрожує штрафом до 50 000 рублів при перевірці ДІТ. Збитки компанії через несвоєчасне оновлення документів можуть бути суттєвими. Ми розробили AI-систему, яка автоматизує підготовку, контроль та архів кадрових документів, знижуючи помилки до <0.1% та економлячи до 80% часу HR-відділу. Накази, трудові договори, особові картки, довідки — кожен документ коректно оформлюється та своєчасно підписується.
Які процеси автоматизує AI-система?
Онбординг: генерація повного пакета документів при прийнятті — трудовий договір, наказ про прийняття, ознайомлення з ПВТР, угода про конфіденційність. Усі документи створюються з даних заявки на найм через шаблони. Час підготовки скорочується з 2–3 годин до 15–20 хвилин.
Кадрові зміни: накази про переведення, зміну окладу, відпустку. AI формує проєкт наказу, керівник підписує в електронному вигляді.
Звільнення: повідомлення, наказ про звільнення, розрахунковий листок, трудова книжка — координація всього пакета.
Регулярні документи: графіки відпусток, табелі обліку робочого часу, кадрові звіти до Росстату/ПФР/СФР.
| Процес |
Ручне введення |
AI-автоматизація |
| Підготовка договору |
40–60 хв |
2–5 хв |
| Наказ про прийняття |
20–30 хв |
1–2 хв |
| Контроль строків |
щоденно |
автоматично |
| Помилки в даних |
5–10% |
<0.1% |
AI-генерація документів виконується в 10 разів швидше за ручне введення, а кількість помилок знижується з 8% до менше ніж 0.1%.
Як генерація документів забезпечує юридичну чистоту?
def generate_employment_contract(candidate: Candidate, position: Position) -> Document:
template = template_library.get("employment_contract", version="current")
data = {
"employee_name": candidate.full_name,
"employee_passport": candidate.passport_data,
"position": position.title,
"department": position.department,
"salary": position.salary,
"start_date": position.start_date,
# ... інші поля
}
# Детермінована генерація (не LLM)
doc = template.render(data)
# LLM для нестандартних умов (якщо потрібні)
if position.special_conditions:
additional_clauses = llm.generate_employment_clauses(position.special_conditions)
doc.add_section("Додаткові умови", additional_clauses)
return doc
Базові документи генеруються детерміновано за шаблонами — це гарантує відповідність Трудовому кодексу РФ. Для нестандартних умов залучається LLM, яка доопрацьовує формулювання з урахуванням контексту. Всі версії документів зберігаються в архіві — забезпечується повна прозорість.
Чому детермінована генерація надійніша за чисто LLM-підхід?
LLM можуть генерувати галюцинації — некоректні або неіснуючі пункти. Детермінований підхід виключає це для стандартних полів. LLM використовується лише для додаткових умов, де потрібна гнучкість, але результат завжди проходить автоматичну валідацію. Таке поєднання гарантує юридичну точність без втрати швидкості.
Чому важливо контролювати compliance?
Кадровий compliance — жорсткі строки за ТК РФ:
- Ознайомлення з ПВТР до підписання трудового договору
- Наказ про прийняття — у 3 дні
- Повідомлення про звільнення за скороченням — за 2 місяці
- Строки виплати розрахункових — в останній робочий день
Система контролює всі дедлайни та автоматично створює завдання HR-спеціалісту. При наближенні критичного строку виставляється червоний прапорець. Досвід нашої команди — тривалий досвід та численні реалізовані проєкти — гарантує дотримання всіх нормативних вимог. Наші інженери сертифіковані за 1С та NLP-моделями, що додатково підтверджує якість впровадження.
Приклади контрольованих строків
- Ознайомлення з ПВТР: до підписання трудового договору
- Наказ про прийняття: не пізніше 3 робочих днів
- Повідомлення про скорочення: за 2 місяці
- Виплата розрахункових при звільненні: в останній робочий день
Економія на штрафах за порушення трудового законодавства досягає 80%.
| Тип документа |
Ручний час |
AI-час |
| Трудовий договір |
60 хв |
5 хв |
| Наказ про переведення |
30 хв |
2 хв |
| Довідка 2-ПДФО |
15 хв |
1 хв |
Як ми впроваджуємо AI-автоматизацію?
- Аналіз — вивчаємо поточні кадрові процеси, виявляємо вузькі місця.
- Проектування — створюємо архітектуру системи, обираємо LLM та шаблони.
- Реалізація — налаштовуємо генерацію, інтеграцію, контролі.
- Тестування — перевіряємо на 100+ тестових сценаріїв.
- Деплой — розгортаємо у вашій інфраструктурі, навчаємо співробітників.
Цей процес займає від 3 до 6 тижнів.
Інтеграція з 1С:ЗУП
Двостороння інтеграція: дані із заявок → документи в системі → проводки в 1С. Виключає ручне дублювання даних та пов'язані помилки. Час підготовки пакета документів на нового співробітника скорочується з 2–3 годин до 15–20 хвилин.
Що входить в роботу
- Аудит поточних кадрових процесів та шаблонів документів
- Налаштування AI-генерації під ваші регламенти (до 50 шаблонів)
- Інтеграція з 1С:ЗУП та іншими HR-системами
- Розробка панелі моніторингу compliance
- Навчання співробітників (2–3 години)
- Технічна підтримка на 3 місяці
Детермінований підхід використовує шаблони зі змінними, що заповнюються з бази даних. Для рідкісних умов застосовується LLM, але результат завжди перевіряється автоматичними правилами. Це поєднання швидкості та точності.
Замовте впровадження AI-системи. Отримайте консультацію інженера по вашому проекту. Оцінимо можливості за один день — пишіть.
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. Оцінимо проект — розрахуємо економію на інфраструктурі.
| Модель |
F1 macro |
Latency (CPU) |
Розмір |
| BERT-large |
0.89 |
180 ms |
1.3 GB |
| DistilBERT |
0.84 |
25 ms |
250 MB |
| ruBERT-tiny2 |
0.81 |
12 ms |
120 MB |
| DistilBERT + ONNX |
0.84 |
14 ms |
150 MB |
Як вибрати модель класифікації під ваш датасет?
Для малих датасетів (до 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 — ще компактніше, але з втратами. Входить у наші рекомендації по деплою.
Вилучення інформації
Структуроване вилучення — одна з частих задач. Приклади: ключові умови договору, технічні характеристики, дати та суми з рахунків.
-
Regex + rule-based. Для ІПН, ЄДРПОУ, сум, дат — надійніше нейромережі. Не потребує даних.
-
NER + постобробка. Для варіативних форматів.
-
LLM з structured output. GPT‑4 / Claude з JSON schema — для складних документів. Вартість: залежить від обсягу документів. Для 10k+ документів/день — рахуємо економіку.
Гарантуємо гібрид: regex/NER для типових полів + LLM для edge cases. Сертифікат довіри: 5 років на ринку, >30 проектів.
Етапи роботи
| Етап |
Тривалість |
Що входить |
| Аналіз даних і метрик |
3‑5 днів |
Розподіл класів, довжина текстів, baseline |
| Baseline (TF‑IDF + LogReg) |
1 день |
Швидка оцінка розриву з глибокими моделями |
| Навчання та валідація |
1‑2 тижні |
k‑fold, early stopping, аналіз помилок |
| Деплой (ONNX + FastAPI) |
1‑2 тижні |
REST API, батчинг, моніторинг |
| Документація та навчання |
2‑3 дні |
Model card, API docs, навчання команди |
Прототип на існуючих даних — 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 дні.