RPA Bots with LLM Integration for Unstructured Data Processing

Development of RPA Bots with LLM Integration for Unstructured Data Processing

Classical RPA tools — UiPath, Automation Anywhere, Blue Prism — handle structured data and deterministic scenarios well. Problems arise when unstructured text appears in the process: emails, PDF scans, free forms, chats. Here RPA without AI either requires rigid templates or breaks on slightest deviation. LLM integration in RPA pipeline closes this gap.

Where LLM is Actually Needed in RPA

Not every process step requires language model. Rational architecture divides tasks: RPA engine manages navigation, clicks, data transfer between systems. LLM connects pointwise — where text understanding, entity extraction, or fuzzy-logic decision is needed.

Typical integration points:

• Data extraction from incoming emails — request type determination, requisite extraction, routing
• PDF document processing — delivery notes, acts, contracts with variable structure
• Request classification — support, claims, information requests
• Form filling — based on free user description or document

Technical Architecture

Standard scheme includes three layers:

RPA Layer — process orchestrator. Depending on platform: UiPath Orchestrator, Robocorp, n8n, or custom Python scheduler. Manages triggers, task queues, result logging.

AI Processing Layer — microservice or lambda receiving unstructured content and returning structured JSON. Inside: text preprocessing (pytesseract/pdfminer for extraction, langchain/llama-index for LLM request orchestration). Model — GPT-4o, Claude 3.5 Sonnet, or local Mistral/LLaMA via Ollama, depending on confidentiality requirements.

Validation Layer — checks model confidence, fallback to human on low confidence score. Implemented via structured output (JSON Schema in prompt or OpenAI function calling) + postprocessing rules.

[Event Trigger] → [RPA Agent]
    → [Text/Image Extraction]
    → [LLM Microservice] → {extracted_data: {...}, confidence: 0.94}
    → [Validation] → [Write to CRM/ERP/DB]
    → [Orchestrator Logging]

Input Formats and Processing Strategies

Prompt Design for Reliable Extraction

Key point — prompts should return strictly typed JSON, not free text. Use Pydantic schemas for output validation:

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 from OpenAI or similar mode in Claude (tool_use) guarantee valid JSON without postprocessing regex.

Edge Case Handling and Confidence Routing

Model isn't always confident. Confidence routing strategy:

• confidence > 0.9 — automatic processing, logging
• 0.7–0.9 — processing + flag for spot check
• < 0.7 — send to manual review queue + notification

Confidence can be obtained several ways: token log probabilities (available via OpenAI API), separate verification prompt, or ensemble of two models with voting.

UiPath Integration

In UiPath, LLM call is wrapped in Custom Activity on C# or called via Invoke Python Activity. Alternative — UiPath Document Understanding with AI Center, but this vendor lock-in has significant cost. Custom integration via REST gives more flexibility:

1. HTTP Request Activity → POST to LLM microservice
2. Deserialize JSON → UiPath DataTable
3. Assign activities → process variable filling

For Robocorp, similar scheme via rpaframework + requests.

Metrics and Monitoring

After production launch, track:

• Extraction accuracy — % of fields extracted correctly (reference sample)
• Human escalation rate — goal: reduce from 30–40% (manual processing) to 5–10%
• Processing latency — p95 on LLM call time, target < 3s for synchronous processes
• Token cost per document — for budgeting, usually $0.001–0.01 per document with gpt-4o-mini

Typical results after implementation: processing time per document reduced from 3–5 minutes (manual) to 15–30 seconds, accuracy on structured fields reaches 92–96%.

Implementation Timeline

• Prototype (1 document type, 1 process): 2–3 weeks
• MVP (3–5 document types, CRM/ERP integration): 6–8 weeks
• Scalable solution (queue, monitoring, fallback): 10–14 weeks