Разработка 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, в зависимости от требований к конфиденциальности.

Слой валидации — проверка уверенности модели, 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"Extract invoice data:\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 секунд, accuracy на структурированных полях достигает 92–96%.

Сроки реализации

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