Класичні RPA-інструменти — UiPath, Automation Anywhere, Blue Prism — чудово справляються зі структурованими даними та детермінованими сценаріями. Проблема виникає, коли в процесі з'являється неструктурований текст: листи, PDF-скани, вільні форми, чати. Тут RPA без AI або потребує жорстких шаблонів, або ламається при найменшому відхиленні. Інтеграція LLM в RPA-пайплайн закриває цей розрив, і ми пропонуємо рішення під ключ.
Типовий сценарій: вхідні рахунки від 50 різних постачальників — кожен зі своєю структурою. Ручна обробка займає 3–5 хвилин на документ. Після впровадження LLM-модуля час скорочується до 15–30 секунд, точність вилучення ключових полів — 92–96%. Порівняння з традиційними методами: LLM-підхід у 4 рази ефективніший за шаблонні парсери і не потребує перенавчання при зміні формату. Замовте пілотний проект — ми за один тиждень оцінимо придатність LLM на ваших документах.
Як архітектура RPA-LLM виглядає в production?
Не кожен крок процесу потребує мовної моделі. Розумна архітектура розділяє завдання: RPA-двигун керує навігацією, кліками, передачею даних між системами. LLM підключається точково — там, де потрібно зрозуміти текст, вилучити сутності або прийняти рішення за нечіткою умовою.
Типові точки інтеграції:
- Вилучення даних із вхідних листів — визначення типу запиту, вилучення реквізитів, маршрутизація
- Обробка PDF-документів — накладні, акти, договори з варіативною структурою
- Класифікація звернень — підтримка, рекламації, запити на інформацію
- Заповнення форм — на основі вільного опису від користувача або документа
Стандартна схема включає три шари:
Шар RPA — оркестратор процесу. Залежно від платформи це може бути UiPath Orchestrator, Robocorp, n8n або самописний планувальник на Python. Відповідає за тригери, черги завдань, логування результатів.
Шар AI-обробки — мікросервіс або лямбда, що приймає неструктурований контент і повертає структурований JSON. Всередині: передобробка тексту (pytesseract/pdfminer для вилучення, langchain/llama-index для оркестрації запитів до LLM). Модель — GPT-4o, Claude 3.5 Sonnet або локальний Mistral/LLaMA через Ollama, залежно від вимог до конфіденційності.
Шар валідації — перевірка впевненості моделі, fallback на людину при низькому confidence score. Реалізується через structured output (JSON Schema у промпті або OpenAI function calling) + правила постобробки.
Що входить у роботу
- Документація архітектури та API-специфікацій
- Доступи до LLM-мікросервісу через REST API
- Навчання команди RPA-розробників
- Підтримка протягом місяця після запуску
Чому confidence routing критичний для production?
Модель не завжди впевнена. Стратегія confidence routing:
- confidence > 0.9 — автоматична обробка, логування
- 0.7–0.9 — обробка + прапорець для вибіркової перевірки
- < 0.7 — відправлення в чергу ручної перевірки + сповіщення
Confidence можна отримати кількома способами: логпробабіліті токенів (доступні через API OpenAI), окремий verification-промпт, або ensemble з двох моделей з голосуванням. Наша архітектура confidence routing знижує human escalation на 80% порівняно з пороговими правилами.
Які LLM краще підходять для RPA?
Вибір моделі залежить від вимог до латенсі, точності та конфіденційності. Типова вартість LLM-виклику — від $0.001 до $0.01 на документ при використанні gpt-4o-mini, що становить менше 5% від економії на ручній обробці. Порівняння популярних моделей:
| Модель | Латенсі (p50) | Точність вилучення | Ціна за 1K токенів |
|---|---|---|---|
| GPT-4o | 1.2 сек | 96% | $0.01 |
| Claude 3.5 | 1.5 сек | 94% | $0.008 |
| Mistral Large | 0.8 сек | 92% | $0.004 |
| LLaMA 3 70B (локально) | 2.0 сек | 91% | місцеві ресурси |
Технічні деталі інтеграції
Ключовий момент — промпти повинні повертати строго типізований JSON, а не вільний текст. Використовуйте Pydantic-схеми для валідації виходу:
from pydantic import BaseModel from openai import OpenAI class InvoiceData(BaseModel): vendor_name: str invoice_number: str total_amount: float currency: str due_date: str | None client = OpenAI() response = client.beta.chat.completions.parse( model="gpt-4o-mini", messages=[{"role": "user", "content": f"Extract invoice data:\n{text}"}], response_format=InvoiceData, ) Structured outputs від OpenAI або аналогічний режим в Claude (tool_use) гарантують валідний JSON без постобробки regex.
| Тип документа | Інструмент вилучення | Стратегія LLM |
|---|---|---|
| PDF (текстовий) | pdfminer.six, pypdf | Прямий промптинг з Few-shot |
| PDF (скан) | pytesseract + OpenCV | OCR → LLM extraction |
| Email (.eml, .msg) | email (Python stdlib) | Structured extraction prompt |
| Веб-форма | Selenium/Playwright скрапінг | Класифікація + нормалізація |
| Word/Excel | python-docx, openpyxl | Таблиця → JSON → LLM |
Метрики та моніторинг
Після запуску в prod відстежуйте:
- Extraction accuracy — відсоток полів, вилучених коректно (еталонна вибірка)
- Human escalation rate — ціль: знизити з 30–40% (ручна обробка) до 5–10%
- Processing latency — p95 за часом LLM-виклику, ціль < 3 с для синхронних процесів
- Token cost per document — для бюджетування, зазвичай $0.001–0.01 на документ з gpt-4o-mini
Типові результати після впровадження: час обробки одного документа знижується з 3–5 хвилин (ручна) до 15–30 секунд, accuracy на структурованих полях досягає 92–96%. Наш досвід — понад 10 років в AI/ML, виконано 50+ проектів з інтеграції RPA та LLM. Оцінимо ваш проект за один день — зв'яжіться для консультації. Отримайте консультацію з архітектури та вибору моделі.
Терміни реалізації
- Прототип (1 тип документа, 1 процес): 2–3 тижні
- MVP (3–5 типів документів, інтеграція з CRM/ERP): 6–8 тижнів
- Масштабоване рішення (черга, моніторинг, fallback): 10–14 тижнів