Розробка RPA-ботів з інтеграцією LLM для обробки неструктурованих даних

Розробка RPA-ботів з інтеграцією LLM для обробки неструктурованих даних

Класичні RPA-інструменти — UiPath, Automation Anywhere, Blue Prism — добре справляються зі структурованими даними та детермінованими сценаріями. Проблема виникає, коли в процесі з'являється неструктурований текст: листи, PDF-скани, вільні форми, чати. Тут RPA без AI або вимагає жорстких шаблонів, або ломається при найменшому відхиленні. Інтеграція LLM у RPA-пайплайн закриває цей розрив.

Де LLM дійсно потрібен у RPA

Не кожен крок процесу вимагає мовної моделі. Раціональна архітектура розділяє завдання: 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, залежно від вимог до конфіденційності.

Validation-слой — перевірка впевненості моделі, fallback на людину при низькому confidence score. Реалізується через structured output (JSON Schema у промпті або OpenAI function calling) + правила постобробки.

[Тригер подіїі] → [RPA-агент]
    → [Витяг тексту/зображення]
    → [LLM-мікросервіс] → {extracted_data: {...}, confidence: 0.94}
    → [Валідація] → [Запис у CRM/ERP/БД]
    → [Логування в Orchestrator]

Формати вхідних даних та стратегії обробки

Проектування промптів для надійного витягу

Ключовий момент — промпти мають повертати строго типізований 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"Витягни дані рахунку:\n{text}"}],
    response_format=InvoiceData,
)

Structured outputs від OpenAI або аналогічний режим у Claude (tool_use) гарантують валідний JSON без постобробки regex.

Обробка edge cases та confidence routing

Модель не завжди впевнена. Стратегія confidence routing:

• confidence > 0.9 — автоматична обробка, логування
• 0.7–0.9 — обробка + флаг для вибіркової перевірки
• < 0.7 — відправка в чергу ручної перевірки + сповіщення

Confidence можна отримати кількома способами: логпробабілітети токенів (доступні через API OpenAI), окремий verification-промпт, або ensemble з двох моделей з голосуванням.

Інтеграція з UiPath

В UiPath LLM-виклик оборачується в Custom Activity на C# або викликається через Invoke Python Activity. Альтернатива — UiPath Document Understanding з AI Center, але це vendor lock-in зі значною вартістю. Кастомна інтеграція через REST дає більше гнучкості:

1. HTTP Request Activity → POST до LLM-мікросервісу
2. Deserialize JSON → UiPath DataTable
3. Assign активності → заповнення змінних процесу

Для Robocorp аналогічна схема через rpaframework + requests.

Метрики та моніторинг

Після запуску в prod стежте за:

• Extraction accuracy — відсоток полів, витягнутих коректно (еталонна вибірка)
• Human escalation rate — ціль: знизити з 30–40% (ручна обробка) до 5–10%
• Processing latency — p95 по часу LLM-виклику, ціль < 3s для синхронних процесів
• Token cost per document — для бюджетування, зазвичай $0.001–0.01 на документ з gpt-4o-mini

Типові результати після впровадження: час обробки одного документа знижується з 3–5 хвилин (ручна) до 15–30 секунд, точність на структурованих полях досягає 92–96%.

Терміни реалізації

• Прототип (1 тип документа, 1 процес): 2–3 тижні
• MVP (3–5 типів документів, інтеграція з CRM/ERP): 6–8 тижнів
• Масштабовне рішення (черга, моніторинг, fallback): 10–14 тижнів